5.1.1. System Information

System information components include the following:

5.1.2. System Time

The 7210 SAS routers are equipped with a real-time system clock for time-keeping purposes. When set, the system clock always operates on Coordinated Universal Time (UTC), but the software has options for local time translation and system clock synchronization.

System time parameters include the following:

5.1.2.2. Network Time Protocol (NTP)

The Network Time Protocol (NTP) is defined in RFC 1305, Network Time Protocol (Version 3) Specification, Implementation and Analysis. It allows participating network nodes to keep time more accurately and maintain time in a more synchronized manner between the participating network nodes.

NTP uses stratum levels to define the number of hops from a reference clock. The reference clock is treated as a stratum-0 device that is assumed to be accurate with little or no delay. Stratum-0 servers cannot be used in a network. However, they can be directly connected to devices that operate as stratum-1 servers. A stratum-1 server is an NTP server with a directly-connected device that provides Coordinated Universal Time (UTC), such as a GPS or atomic clock.

The 7210 SAS devices cannot act as stratum-1 servers but can act as stratum-2 devices because a network connection to an NTP server is required.

The higher stratum levels are separated from the stratum-1 server over a network path, thus a stratum-2 server receives its time over a network link from a stratum-1 server. A stratum-3 server receives its time over a network link from a stratum-2 server.

If the internal PTP process is used as a time source for System Time and OAM, it must be specified as a server for NTP. If PTP is specified, the prefer parameter must also be specified. After PTP has established a UTC traceable time from an external grandmaster source, that clock will always be the time source into NTP, even if PTP goes into time holdover.

Note: Use of the internal PTP time source for NTP will promote the internal NTP server to stratum-1 level. This may impact the NTP network topology.

The following NTP elements are supported:

1. server mode
   In this mode, the node advertises the ability to act as a clock source for other network elements. By default, the node will, by default, transmits NTP packets in NTP version 4 mode.
2. authentication keys
   These keys implement increased security support in carrier and other networks. Both DES and MD5 authentication are supported, as well as multiple keys.
3. symmetric active mode
   In this mode, the NTP is synchronized with a specific node that is considered more trustworthy or accurate than other nodes carrying NTP in the system. This mode requires that a specific peer is set.
4. broadcast
   In this mode, the node receives or sends using a broadcast address.
5. alert when NTP server is not available
   When none of the configured servers are reachable on the node, the system reverts to manual timekeeping and issues a critical alarm. When a server becomes available, a trap is issued indicating that standard operation has resumed.
6. NTP and SNTP
   If both NTP and SNTP are enabled on the node, SNTP transitions to an operationally down state. If NTP is removed from the configuration or shut down, SNTP resumes an operationally up state.
7. gradual clock adjustment
   Because several applications (such as Service Assurance Agent (SAA)) can use the clock, if a major adjustment (128 ms or more) is needed, it is performed by programmatically stepping the clock. If a minor (less than 128 ms) adjustment is needed, it is performed by either speeding up or slowing down the clock.
8. rate limit events and traps
   To avoid the generation of excessive events and traps the NTP module rate limits the generation of events and traps to three per second. At that point, a single trap is generated to indicate that event and trap squashing is taking place.

5.2.1. HA Features

This section describes high availability features for devices.

5.4.1. Central Synchronization Subsystem

The timing subsystem has a central clock located on the CPM. The timing subsystem performs several functions of the network element clock as defined by Telcordia (GR-1244-CORE) and ITU-T G.781 standards.

The central clock uses the available timing inputs to train its local oscillator. The number of timing inputs available to train the local oscillator varies per platform. The priority order of these references must be specified. This is an ordered list of inputs: (ref1, ref2). The CPM clock output can drive the clocking for all line cards in the system. The routers support selection of the node reference using Quality Level (QL) indications. The recovered clock will be able to derive its timing from one of the references available on that platform.

Figure 23 shows how on 7210 SAS devices, the recovered clock is able to derive the timing from any of the following references:

See Synchronization Options Available on 7210 SAS Platforms for information about the synchronization options supported by each 7210 SAS platform.

Figure 23 shows the synchronization reference selection available for the 7210 SAS platforms.

Figure 23:  A Logical Model of the Synchronization Reference Selection on 7210 SAS Platforms 

When Quality Level (QL) selection mode is disabled, the reversion setting controls when the central clock can reselect a previously failed reference.

Table 24 describes the selection followed for two references in both revertive and non-revertive modes.

5.4.2. Synchronization Options Available on 7210 SAS Platforms

Table 25 lists the supported synchronization options supported on 7210 SAS platforms.

5.4.3. Synchronization Status Messages (SSM)

Note: Synchronous status messages are supported on devices that support Synchronous Ethernet.

SSM allows the synchronization distribution network to determine the quality level of the clock sourcing a specific synchronization trail and also allows a network element to select the best of multiple input synchronization trails. SSMs are defined for various transport protocols (including SONET/SDH, T1/E1, and Synchronous Ethernet), for interaction with office clocks (such as BITS or SSUs) and embedded network element clocks.

SSM allows equipment to autonomously provision and reconfigure (by reference switching) their synchronization references, while helping to avoid the creation of timing loops. These messages are particularly useful for synchronization re-configurations when timing is distributed in both directions around a ring.

5.4.4. Synchronous Ethernet

Traditionally, Ethernet-based networks employ a physical layer transmitter clock derived from an inexpensive +/-100ppm crystal oscillator and the receiver locks onto it. Because data is packetized and can be buffered, there is no need for long-term frequency stability or for consistency between frequencies of different links.

Synchronous Ethernet is a variant of the line timing that derives the physical layer transmitter clock from a high-quality frequency reference, replacing the crystal oscillator with a frequency source traceable to a primary reference clock. This change is transparent to the other Ethernet layers and does not affect their operation. The receiver at the far end of the link is locked to the physical layer clock of the received signal, and ensures access to a highly accurate and stable frequency reference. In a manner analogous to conventional hierarchical master-slave network synchronization, this receiver can lock the transmission clock of other ports to this frequency reference, and establish a fully time-synchronous network.

Unlike methods that rely on sending timing information in packets over an unclocked physical layer, Synchronous Ethernet is not affected by impairments introduced by higher levels of networking technology (packet loss, packet delay variation). The frequency accuracy and stability in Synchronous Ethernet typically exceeds networks with unsynchronized physical layers.

Synchronous Ethernet allows operators to gracefully integrate existing systems and future deployments into a conventional industry-standard synchronization hierarchy. The concept is analogous to SONET/SDH system timing capabilities. The operator can select any (optical) Ethernet port as a candidate timing reference. The recovered timing from this port is used to time the system (for example, the CPM will lock to this provisioned reference selection). The operator then can ensure that all system output is locked to a stable traceable frequency source.

The use of synchronous Ethernet as a candidate reference and for distribution of recovered reference is supported on the 7210 SAS-K 2F1C2T, 7210 SAS-K 2F6C4T, 7210 SAS-K 3SFP+ 8C, and 7210 SAS-D ETR platforms. It is not supported on the 7210 SAS-D.

Synchronous Ethernet using fiber Ethernet ports, including 10G ports (if available), is supported on the 7210 SAS-K 2F1C2T, 7210 SAS-K 2F6C4T, 7210 SAS-K 3SFP+ 8C, and 7210 SAS-D ETR platforms.

Note: The SFP, XFP or SFP+ transceivers used with the SFP, XFP, and SFP+ ports must support Synchronous Ethernet. See Synchronization Options Available on 7210 SAS Platforms for information about Synchronous Ethernet support for each 7210 SAS platform.

Fixed copper ports using Synchronous Ethernet can be used as a candidate reference (Master) or for distribution of recovered reference (Slave). If the port is a fixed copper Ethernet port and in 1000BASE-T mode of operation, there is a dependency on the 802.3 link timing for the synchronous Ethernet functionality (refer to ITU-T G.8262). The 802.3 standard link master-slave timing states must align with the desired direction of synchronous Ethernet timing flow. When a fixed copper Ethernet port is specified as an input reference for the node or when it is removed as an input reference for the node, 802.3 link autonegotiation is triggered to ensure that the link timing aligns correctly.

The SSM of synchronous Ethernet uses an Ethernet OAM PDU that uses the slow protocol subtype. For a complete description of the format and processing, refer to ITU-T G.8264.

5.4.5. IEEE 1588v2 PTP

Note: Precision Time Protocol (PTP) is only supported on the 7210 SAS-D ETR, 7210 SAS-K 2F1C2T, 7210 SAS-K 2F6C4T, and 7210 SAS-K 3SFP+ 8C. References to G.8275.1 and Ethernet encapsulation apply only to the 7210 SAS-K 2F6C4T and 7210 SAS-K 3SFP+ 8C.

PTP is a timing-over-packet protocol defined in the IEEE 1588v2 standard 1588 PTP 2008.

PTP may be deployed as an alternative timing-over-packet option to ACR. PTP provides the capability to synchronize network elements to a Stratum-1 clock or primary reference clock (PRC) traceable source over a network that may or may not be PTP-aware. PTP has several advantages over ACR. It is a standards-based protocol, has lower bandwidth requirements, can transport both frequency and time, and can potentially provide better performance.

The following is a list of the four basic types of PTP devices:

The 7210 SAS supports the ordinary clock in slave mode and the boundary clock. The boundary clock and ordinary clock slave can be used for both frequency and time distribution. The 7210 SAS does not support ordinary clock in master mode, end-to-end transparent clock, or peer-to-peer transparent clock.

Figure 24 shows how the 7210 SAS communicates with peer 1588v2 clocks.These peers can be ordinary clock slaves or boundary clocks. The communication can be based on either unicast IPv4 sessions transported through IP interfaces or Ethernet multicast PTP packets transported through an Ethernet port.

Table 28 describes IP/UDP unicast and multicast support for the 7210 SAS platforms.

For unicast IP sessions, there are two types of peers: configured and discovered. The 7210 SAS operating as an ordinary clock slave or as a boundary clock must have configured peers for each PTP neighbor clock from which it might accept synchronization information. The 7210 SAS initiates unicast sessions with all configured peers. A 7210 SAS operating as a boundary clock will accept unicast session requests from external peers. If the peer is not a configured peer, it is considered a discovered peer. The 7210 SAS can deliver synchronization information toward discovered peers (that is, slaves).

For Ethernet multicast operation, the node listens for and transmits PTP messages using the configured multicast MAC address. Neighbor clocks are discovered via the reception of messages through an enabled Ethernet port. Figure 25 shows how the 7210 SAS supports only one neighbor PTP clock connecting into a single port.

The 7210 SAS does not allow for simultaneous PTP operations using both unicast IPv4 and Ethernet multicast. A change of profile to G.8275.1 or from G.8275.1 to another profile requires a reboot of the node.

Figure 24 shows the relationship of various neighbor clocks using unicast IP sessions to communicate with a 7210 SAS configured as a boundary clock with two configured peers.

Figure 24:  Peer Clocks 

Figure 25 shows the relationship of various neighbor clocks using multicast Ethernet sessions to a 7210 SAS configured as a boundary clock.

Figure 25:  Ethernet Multicast Ports 

Note: 7210 SAS platforms do not support the ordinary clock master configuration.

The IEEE 1588v2 standard includes the concept of PTP profiles. These profiles are defined by industry groups or standards bodies that define the use of IEEE 1588v2 for specific applications.

The 7210 SAS currently supports three profiles:

When a 7210 SAS receives Announce messages from one or more configured peers or multicast neighbors, it executes a Best Master Clock Algorithm (BMCA) to determine the state of communication between itself and the peers. The system uses the BMCA to create a hierarchical topology, allowing the flow of synchronization information from the best source (the grandmaster clock) out through the network to all boundary and slave clocks. Each profile has a dedicated BMCA.

If the profile setting for the clock is ieee1588-2008, the precedence order for the best master selection algorithm is as follows:

Table 29 describes how the 7210 SAS sets its local parameters.

If the profile setting for the clock is itu-telecom-freq (ITU G.8265.1 profile), the precedence order for the best master selection algorithm is the following:

Table 30 describes how the 7210 SAS sets its local parameters.

The ITU-T profile is for use in environments with only ordinary clock masters and slaves for frequency distribution. The default profile should be used for all other cases.

If the profile setting for the clock is g8275dot1-2014, the precedence order for the best master selection algorithm is very similar to that used for the default profile. It ignores the priority1 parameter, includes a localPriority parameter, and includes the ability to force a port to never enter the slave state (master-only). The precedence is as follows:

Table 31 describes how the 7210 SAS sets its local parameters.

The 7210 SAS can support a limited number of configured peers (possible master or neighbor boundary clocks) and a limited number of discovered peers (slaves).These peers use the unicast negotiation procedures to request service from the 7210 SAS clock. A neighbor boundary clock counts for two peers (both a configured and a discovered peer) toward the maximum limit.

On the 7210 SAS-D ETR, 7210 SAS-K 2F1C2T, 7210 SAS-K 2F6C4T, and 7210 SAS-K 3SFP+ 8C there are limits on the number of slaves enforced in the implementation for unicast and multicast PTP slaves. Contact your Nokia technical support representative for information about the specific unicast message limits related to PTP.

When PTP is configured, the PTP load must be monitored to ensure that the load does not exceed the capabilities (configured values) to ensure that sufficient CPU processing cycles are available for PTP. There are several commands that can be used for this monitoring, including:

Because the user cannot control the number of PTP messages received by the 7210 SAS over its Ethernet ports, the following statistics commands can be used to identify the source of the message load:

Figure 26 shows the unicast negotiation procedure performed between a slave and a peer clock that is selected to be the master clock. The slave clock will request Announce messages from all peer clocks but only request Sync and Delay_Resp messages from the clock selected to be the master clock.

Figure 26:  Messaging Sequence Between the PTP Slave Clock and PTP Master Clocks 

5.4.5.1. PTP Clock Synchronization

The IEEE 1588v2 standard synchronizes the frequency and time from a master clock to one or more slave clocks over a packet stream. This packet-based synchronization can be over unicast IP/UDP unicast or Ethernet multicast.

As part of the basic synchronization timing computation, event messages are defined for synchronization messaging between the PTP slave clock and PTP master clock. A one-step or two-step synchronization operation can be used; the two-step operation requires a follow-up message after each synchronization message.

Note: The 7210 SAS-D ETR supports only two-step master port operation. All platforms can operate slave ports that receive from a one-step or two-step master port.

During startup, the PTP slave clock receives synchronization messages from the PTP master clock before a network delay calculation is made. Prior to any delay calculation, the delay is assumed to be zero. A drift compensation is activated after a number of synchronization message intervals occur. The expected interval between the reception of synchronization messages is user-configurable.

Figure 27 shows the basic synchronization timing computation between the PTP slave clock and PTP best master, as well as the offset of the slave clock referenced to the best master signal during startup.

Figure 27:  PTP Slave Clock and Master Clock Synchronization Timing Computation 

When the IEEE 1588v2 standard is used for distribution of a frequency reference, the slave calculates a message delay from the master to the slave based on the timestamps exchanged. A sequence of these calculated delays contains information about the relative frequencies of the master clock and slave clock, but also includes a noise component related to the PDV experienced across the network. The slave must filter the PDV effects to extract the relative frequency data and then adjust the slave frequency to align with the master frequency.

When the IEEE 1588v2 standard is used for distribution of time, the 7210 SAS calculates the offset between the 7210 SAS time base and the external master clock time base based on the four timestamps exchanged. The 7210 SAS determines the offset adjustment, and between these adjustments, it maintains the progression of time using the frequency from the central clock of the node. This allows time to be maintained using a Synchronous Ethernet input source even if the IEEE 1588v2 communications fail. When using IEEE 1588v2 for time distribution, the central clock should, at a minimum, have the PTP input reference enabled.

Figure 28 shows the logical model for using PTP/1588 for network synchronization.

Figure 28:  Logical Model for Using PTP/1588 for Network Synchronization on 7210 SAS Platforms 

5.4.5.4. PTP Ordinary Slave Clock for Frequency

Traditionally, only clock frequency is required to ensure smooth transmission in a synchronous network. The PTP ordinary clock with slave capability on the 7210 SAS provides another option to reference a Stratum-1 traceable clock across a packet switched network. The recovered clock can be referenced by the internal SSU and distributed to all slots and ports.

Figure 29 shows a PTP ordinary slave clock network configuration.

Figure 29:  Slave Clock 

5.4.6. PTP Boundary Clock for Frequency and Time

Although IEEE 1588v2 can function across a packet network that is not PTP-aware, performance may be unsatisfactory and unpredictable. PDV across the packet network varies with the number of hops, link speeds, utilization rates, and the inherent behavior of routers. By using routers with boundary clock functionality in the path between the grandmaster clock and the slave clock, one long path over many hops is split into multiple shorter segments, allowing better PDV control and improved slave performance. This allows PTP to function as a valid timing option in more network deployments and allows for better scalability and increased robustness in certain topologies, such as rings.

Boundary clocks can simultaneously function as a PTP slave of an upstream grandmaster (ordinary clock) or boundary clock, and as a PTP master of downstream slaves (ordinary clock) and/or boundary clocks. The time scale recovered in the slave side of the boundary clock is used by the master side of the boundary clock. This allows time across the boundary clock.

Figure 30 shows routers with boundary clock functionality in the path between grandmaster and the slave clock.

Figure 30:  Boundary Clock 

5.4.7. Configuration Guidelines and Restrictions for PTP

5.4.8. Configuration to Change Reference from SyncE to PTP on 7210 SAS-D ETR

The following are the configuration steps to change reference from SyncE to PTP. This procedure is required only on 7210 SAS-D ETR nodes.

5.6.1. Allocation of Ingress Internal TCAM resources

The system statically allocates ingress TCAM resources for use by SAP ingress QoS classification, SAP ingress access control lists (ACLs), identifying and sending CFM OAM packets to CPU for local processing, and so on. The resource allocation is not user-configurable. With the introduction of new capabilities such as IPv6 classification, UP MEP support, and G8032-fast-flood, the static allocation of resources by software does not meet requirements of customer who need to use different features.

The user can allocate a fixed amount of resources per system for QoS, ACLs, CFM/Y.1731 MEPs, and other features. Of these, some parameters are boot-time and others are run-time. A change in the current value of the parameter that is designated boot-time needs a reboot of the node before the new value takes effect. Change in the current value of the parameter that is designated run-time takes effect immediately if the software determines resources are available for use to accommodate the change.

During bootup, the system reads the resource profile parameters and allocates resources to features in the order they appear in the configuration file.

Because resources are shared, the user must ensure that the sum total of such resources does not exceed the limit supported by the IMM or node. If the system determines that it cannot allocate the requested resources, the feature is disabled. For example, if the system determines that it cannot allocate resources for g8032-fast-flood, it disables the feature from use and G8032 eth-rings will not be able to use fast-flood mechanisms). Another example is the case where the system determines that it cannot allocate resources for IPv4-based SAP Ingress ACL classification, the system will not allow users to use IPv4-based SAP ingress ACL classification feature and fails the configuration when it comes upon the first SAP in the configuration file that uses an IPv4-based SAP ingress ACL policy.

For boot-time parameters, such as g8032-fast-flood-enable, the user must ensure that the configured services match the resources allocated. If the system determines that it cannot allocate resources to services, it fails the configuration file at the first instance where it encounters a command to which resources cannot be allocated. The available resources can be allocated to different features.

For ACL and QoS resources, the user has the option to allocate resources to limit usage per feature, regardless of the match criteria used. The sum of all resources used for different SAP ingress classification match-criteria is limited by the amount of resources allocated for SAP ingress classification. The user can also allocate resources by specific match criteria. The user can enable any supported match criteria and associate a fixed amount of resources with each match criteria in fixed sizes; the chunk size is dependent on the platform.

The system allocates resources based on the order of appearance in the configuration file, and fails any match criteria if the system does not have any more resources to allocate. In addition, the max keyword can be used to indicate that the system needs to allocate resources when they are first required, as long as the maximum amount of resources allocated for that feature is not exceeded or the maximum amount of resources available in the system is not exceeded. The 7210 SAS platforms allocate resources to each feature and match-criteria in fixed-size chunks.

The no form of the command disables the use of corresponding match criteria. During runtime, the command succeeds, if no SAPs are currently using the criteria. Similarly, reduction of resources from the current value to a lower value succeeds, if no SAPs are currently using the criteria.

If the system successfully runs the no command, it frees up resources used by the chunk or slice and make the resources, or the entire chunk/slice, available for use by other features. Before deallocating resources, the software checks if a service object is using the resource and fails the command if the object is in use. If resources are in use, they can be freed up by deleting a SAP, removing a policy association with a SAP, deleting a MEP, and so on. Some commands under the system resource-profile context do not take effect immediately and require a system reboot before the change occurs and resources are freed. The following is the handling of freed resources.

The no form of the commands that are designated as boot-time does not take effect immediately. It takes effect after the reboot. Before reboot, it is the user’s responsibility to free up resources required for use by the feature that has been enabled to take effect after the reboot. Not doing so results in failure when the configuration file is executed on boot up.

Refer to the CLI and feature description chapters in the appropriate 7210 SAS platform user guide for more information about CLI commands and features that use system resource allocation.

5.6.2. Allocation of Egress Internal TCAM Resources

Before the introduction of new capabilities, such as IPv6 match criteria, the system allocated egress TCAM resources on bootup for use by different criteria in SAP egress access control lists (ACLs) and other purposes; the resource allocation was not user configurable. With the introduction of new capabilities, such as IPv6 match criteria in egress, the static allocation of resources by software may not meet customer requirements if they want to use different features. Therefore, to facilitate user configuration and resource allocation in accordance with user needs, the ingress internal TCAM resource allocation capabilities have been extended to include the egress internal TCAM resources.

For information about specific CLI commands and features that use system resource allocation, refer to the CLI command and feature descriptions in the appropriate 7210 SAS software user manuals.

Note: The commands in the config>system>resource-profile context, which require a reboot to take effect, are read and implemented by the system only during bootup. These commands do not take effect if the exec command is used to run the configuration file.

5.6.2.1. System Resource Allocation Examples

Note: On the 7210 SAS-K 2F1C2T, 7210 SAS-K 2F6C4T, and 7210 SAS-K 3SFP+ 8C, resources must be allocated among SAP ingress QoS and ingress ACLs. Users do not need to further allocate resources individually for MAC and IPv4 or IPv6 criteria. The qos-sap-ingress-resource and acl-sap ingress commands under the system>resource-profile>ingress-internal-tcam context allocate resources to ingress QoS and ingress ACLs. On the 7210 SAS-D and 7210 SAS-Dxp, resources are allocated in slices with 256 entries per slice. On the 7210 SAS-K 2F1C2T and 7210 SAS-K 2F6C4T, resources are allocated with 510 entries per slice. On the 7210 SAS-K 3SFP+ 8C, resources are allocated with 192 entries per slice. The acl-sap egress command in the system>resource-profile>egress-internal-tcam context allocates resources to egress ACLs. On the 7210 SAS-D and 7210 SAS-Dxp, resources are allocated in slices with 128 entries per slice. On the 7210 SAS-K 2F1C2T and 7210 SAS-K 2F6C4T, resources are allocated with 510 entries per slice. On the 7210 SAS-K 3SFP+ 8C, resources are allocated with 180 entries per slice.

Example one:

config> system> resource-profile...

...

   acl-sap-ingress 3

      mac-match-enable max

      ipv4-match-enable 1

      no ipv6_128-ipv4-match-enable

      no ipv6_64-only-match-enable

   exit

...

In the preceding CLI example, the system performs the following actions.

1. 3 chunks are allocated for use by the SAP ingress ACL entries.
2. 1 chunk is allocated for use by SAP ingress ACL entries that use ipv4-criteria. The system fails the configuration when the number of ACL entries using ipv4-criteria exceeds the configured limit (that is, the system does not allocate in excess of the configured limit of 1 chunk).
3. A chunk is allocated for use by SAP ingress ACL entries that use mac-criteria. After the max keyword is specified, the system allocates 1 chunk for use when an ingress ACL policy (with mac-criteria entries defined) is associated with a SAP. The system can allocate up to 2 chunks because the max keyword is used. More chunks are allocated when the user configures a SAP that uses mac-criteria and all entries in the allocated chunks are used up. The system fails the configuration if the number of ACL entries with mac-criteria exceeds the limit of 2 chunks allocated to SAP ingress ACL match (that is, the system does not allocate in excess of the configured limit of 3; up to 2 chunks of the configured 3 chunk limit are allocated to mac-criteria and 1 chunk is allocated to ipv4-criteria).
4. The system fails a user attempt to use SAP ingress ACLs with IPv6 match criteria (and other combinations listed in the preceding list items), because the user has disabled these criteria.

Example 2:

config> system> resource-profile>ingress-internal-tcam> 

...

acl-sap-ingress  3

mac-match-enable max

ipv4-match-enable 1

no ipv6_128-ipv4-match-enable

ipv6_64-only-match-enable max

exit

...

In the preceding CLI example, the system performs the following actions.

1. 3 chunks are allocated for use by the SAP ingress ACL entries. These resources are available for use with mac-criteria, ipv4-criteria and ipv6-64-bit match criteria.
2. 1 chunk is allocated for use by SAP ingress ACL entries that use ipv4-criteria. The system fails the configuration if the number of ACL entries using ipv4-criteria exceeds the configured limit (that is, the system does not allocate more than the configured limit of 1 chunk).
3. 1 chunk is allocated for use by SAP ingress ACL entries that use mac-criteria when the user associates an ingress ACL policy (with mac-criteria entries defined) with a SAP. Because the max keyword is used, the system can allocate more chunks, if a chunk is available for use.
   In this example, (assuming a SAP with an ingress ACL policy that uses ipv6-64-bit criteria is configured), as no additional chunks are available, mac-criteria cannot allocate more than 1 chunk (even if the max keyword is specified). The system fails the configuration if the number of ACL entries with mac-criteria exceeds the limit of 1 chunk allocated to SAP ingress ACL mac-criteria (that is, the system does not allocate more than the configured limit of 3 chunks = 1 for mac-criteria + for ipv4-criteria + 1 for ipv6-criteria).
4. A chunk is allocated for use by SAP ingress ACL entries that use ipv6-64-bit criteria when the user associates an ingress ACL policy (with ipv6-64-bit-criteria entries defined) with a SAP. Because the max keyword is specified, the system can allocate more chunks, if a chunk is available for use.
   In this example, as there are no more chunks available, ipv6-64-bit criteria cannot allocate more than 1 chunk (even if the max keyword is specified). The system fails the configuration when the number of ACL entries with ipv6-64-bit criteria exceeds the limit of one chunk allocated to SAP ingress ACL match (that is, the system does not allocate more than the configured limit of 3 chunks = 1 for mac-criteria + 1 for ipv4-criteria + 1 for ipv6-64-bit criteria).
5. The system fails any attempt to use SAP ingress ACLs with ipv6-128 bit match criteria (and the other combinations listed above), because the user has disabled these criteria.

In Example 2, the user can run no ipv4-match-enable command to disable the use of ipv4-criteria. The system checks for SAPs that use ipv4-criteria and if found, fails the command; otherwise, the chunk freed for use with either mac-criteria or ipv6-64-bit criteria. The entire chunk is allocated to mac-criteria if the first SAP that needs resources requests for mac-criteria and no entries in the chunk are already allocated to mac-criteria, which leaves no resources for use by ipv6-64-bit criteria. In the same way, the entire chunk is allocated to ipv6-64-bit criteria, if the first SAP that needs resources requests for ipv6-64-bit criteria and no entries in the chunk are already allocated to ipv6-64-bit criteria, which leaves no resources for use by mac-criteria.

5.8.1. General

To access the CLI, ensure that the 7210 SAS device is correctly initialized and the boot loader and BOFs have successfully executed.