2.3.1.1. Port modes

On 7210 SAS devices, a port must be configured as one of the following: access, access uplink, network, or hybrid. The following list describes the significance of the different port modes and the support available on different platforms:

The following table describes supported port modes on the 7210 SAS platforms.

2.3.1.2. Port dot1q VLAN Etype on 7210 SAS-D, 7210 SAS-Dxp, 7210 SAS-K 2F1C2T, 7210 SAS-K 2F6C4T, and 7210 SAS-K 3SFP+ 8C

The 7210 SAS supports an option to allow the user to use a different dot1q VLAN Ethernet Type (Etype). It allows for interoperability with third-party switches that use some non-standard (other than 0x8100) dot1q VLAN Etype.

2.3.1.3. Configuration guidelines for dot1q-Etype for 7210 SAS-D and 7210 SAS-Dxp

The following are the configuration guidelines for Dot1q-Etype configured for dot1q encap port on 7210 SAS-D and 7210 SAS-Dxp.

2.3.2.1. PoE configuration notes

The following configuration notes apply for PoE.

2.3.3.1. MACsec 802.1AE header (SecTAG)

The 802.1AE header has a security tag (SecTAG) which includes:

The SecTAG is identified by the MACsec EtherType and includes the following fields:

The following figure shows the format of the SecTAG.

Figure 2:  SecTAG format 

2.3.3.2. MACsec encryption mode

MACsec uses the following main modes of encryption:

The 802.1AE standard requires that the 802.1Q VLAN is encrypted. Some vendors provide the option of configuring MACsec on a port with VLAN in clear text. The 7210 SAS-K 2F6C4T and 7210 SAS-K 3SFP+ 8C support both modes on both 1GE and 10GE ports.

The following figure shows VLAN encrypted and VLAN in clear text.

Figure 3:  802.1 AE LAN/WAN modes and VLAN encrypted/clear 

2.3.3.3. MACsec key management modes

The following table describes the key management modes in MACsec.

2.3.3.4. MACsec terminology

The following figure shows the main concepts used in MACsec for the static-CAK scenario.

Figure 4:  MACsec concepts for static-CAK 

The following table describes MACsec terminology.

2.3.3.5. MACsec static CAK

MACsec uses SAs to encrypt packets. Each SA has a single SAK that contains the cryptographic operations used to encrypt the datapath PDUs.

SAK is the secret key used by an SA to encrypt the channel.

When enabled, MACsec uses a static CAK security mode, which has two security keys: a CAK that secures control plane traffic and a randomly generated SAK that secures data plane traffic. Both keys are used to secure the point-to-point or point-to-multipoint Ethernet link and are regularly exchanged between devices on each end of the Ethernet link.

The following figure shows MACsec generating the CAK.

Figure 5:  MACsec generating the CAK 

The node initially needs to secure the control plane communication to distribute the SAKs between two or more members of a CA domain.

The control plane is secured using CAK, which is generated using one of the following methods:

The following figure shows MACsec control plane authentication and encryption.

Figure 6:  MACsec control plane 

After the CAK is generated, it can obtain the following additional keys:

The key server then creates a SAK and shares it with the CAs of the security domain, and that SAK secures all data traffic traversing the link. The key server periodically creates and shares a randomly created SAK over the point-to-point link for as long as MACsec is enabled.

The SAK is encrypted using the AES-CMAC, the KEK as the encryption key, and ICK as the integration key.

2.3.3.6. SAK rollover

The SAK is regenerated after the following events:

2.3.3.7. MKA

Each MACsec peer operates the MKA. Each node can operate multiple MKAs based on the number of CAs that it belongs to. Each instance of MKA is protected by a distinct secure CAK, that allows each Port Access Entity (PAE), or port, to ensure that information for a specific MKA instance is accepted only from other peers that also possess that CAK, therefore identifying themselves as members or potential members of the same CA. For a description of how the CAK identification is performed using CKN, see MACsec static CAK.

2.3.3.8.  PSK

A peer may support the use of one or more pre-shared keys (PSKs). An instance of MKA operates for each PSK that is administratively configured as active.

A pre-shared key is either created by NSP or configured using the CLI. Each PSK is configured using the following fields:

The CKN must be unique for each port among the configured sub-ports, and can be used to identify the key in subsequent management operations.

Each static CAK configuration can have two pre-shared key entries for rollover. The active PSK index dictates which CAK is being used for encrypting the MKA PDUs.

NSP has additional functionality to rollover and configure the PSK. The rollover using NSP can be based on a configured timer.

2.3.3.9. MKA hello timer

MKA uses a member identifier (MI) to identify each node in the CA domain.

A participant proves liveness to each of its peers by including the MI, together with an acceptably recent message number (MN), in an MKPDU.

To avoid a new participant having to respond to each MKPDU from each partner as it is received, or trying to delay its reply until it is likely that MI MN tuples have been received from all potential partners, each participant maintains and advertises both a live peers list and a potential peers list.

The live peers list includes peers that have included the participant MI and a recent MN in a recent MKPDU. The potential peers list includes all other peers that have transmitted an MKPDU that has been directly received by the participant or that were included in the live peers list of a MKPDU transmitted by a peer that has proved liveness. Peers are removed from each list when an interval of between MKA lifetime and MKA lifetime plus MKA Hello Time has elapsed since the participant's recent MN was transmitted. This time is sufficient to ensure that two or more MKPDUs will have been lost or delayed prior to the incorrect removal of a live peer.

Note: The specified use of the live peers and potential peers lists permits rapid removal of participants that are no longer active or attached to the LAN, while reducing the number of MKPDUs transmitted during group formation; for example, a new participant will be admitted to an established group after receiving, then transmitting, one MKPDU. MKA Hello packets are sent once every 2 seconds with a timeout interval of 3 packets or 6 seconds. These values are not configurable.

The following table lists the MKA participant timer values.

2.3.3.10. MACsec capability, desire, and encryption offset

The IEEE 802.1x-2010 standard identifies the following fields in the MKA PDU:

MACsec capability signals whether MACsec is capable of integrity and confidentiality. For information about the basic settings for MACsec capability, see the encryption-offset command description.

Encryption offset of 0, 30, or 50 starts from the byte after the SecTAG (802.1AE header). Ideally, the encryption offset should be configured for IPv4 (offset 30) and IPv6 (offset 50) to leave the IP header in clear text. This allows routers and switches to use the IP header for LAG or ECMP hashing.

2.3.3.11. Key server

The participants in an MKA instance that agree on a key server are responsible for the following:

Each participant in an MKA instance uses the key server priority (an 8-bit integer) encoded in each MKPDU to agree on the key server. Each participant selects the live participant advertising the highest priority as its key server whenever the live peers list changes, provided that highest priority participant has not selected another as its key server or is unwilling to act as the key server.

If a key server cannot be selected, SAKs are not distributed. In the event of a tie for highest priority key server, the member with the highest priority SCI is chosen. For consistency with other uses of the SCI MAC address component as a priority, numerically lower values of the key server priority and SCI receive the highest priority.

Note: Each SC is identified by an SCI that comprises a globally unique MAC address, and a port identifier unique within the system that has been allocated that address.

2.3.3.12. SA limits and network design

Each MACsec device supports 64 Tx-SAs and 64 Rx-SAs. An SA (Security Association) is the key to encrypt or decrypt the data.

As defined in IEEE 802.1AE, each SecY contains an SC. An SC is a unidirectional concept; for example, Rx-SC or Tx-SC. Each SC contains at least one SA for encryption on Tx-SC and decryption on Rx-SC. Also, for extra security, each SC should be able to roll over the SA, therefore, Nokia recommends for each SC to have two SAs for rollover purposes.

MACsec PHY is known as a MACsec security zone. Each MACsec security zone supports 64 Tx-SAs and 64 Rx-SAs. Assuming two SAs for each SC for SA rollover, each zone supports 32 Rx-SCs and 32 Tx-SCs.

The following table describes the port mapping to security zones.

2.3.3.13. P2P (switch-to-switch) topology

In a point-to-point topology, each router needs a single security zone, a single Tx-SC for encryption, and a single Rx-SC for decryption. Each SC has two SAs. In total, for point-to-point topology, four SAs are needed: two Rx-SAs for Rx-SC1 and two Tx-SAs for Tx-SC1.

The following figure shows the P2P topology.

Figure 7:  P2P (switch-to-switch) topology 

2.3.3.14. P2MP (switch to switch) topology

In a multi-point topology with N nodes, each node needs a single Tx-SC and N Rx-SC, one for each one of the peers. As such, 64 maximum Rx-SAs for each security zone translates to 32 Rx-SCs, which breaks down to only 32 peers; for example, only 33 nodes in the multipoint topology for each security zone. So from the perspective of each node, there is one Tx-SC and 32 Rx-SCs.

As shown in the following figure, when the 34th node joins the multi-point topology, the other 33 nodes that are already part of this domain do not have SAs to create an Rx-SC for this 34th node; however, the 34th node has a Tx-SC and can accept 32 peers. The 34th node starts to transmit and encrypt the PDUs based on its Tx-SC. However, because all other nodes do not have as SC for this SAI, all Rx PDUs are dropped.

Figure 8:  P2MP topology 

Nokia recommends that a multicast domain, for a single security zone, should not exceed 32 peers, or the summation of all the nodes in a security zone CA domain should not exceed 33. This is the same as if a security zone has four CAs; the summation of all nodes in the four CAs should be 33 or less.

2.3.3.15. SA exhaustion behavior

A security zone has 64 Rx-SAs and 64 Tx-SAs, as described in SA limits and network design. Two Rx-SAs are used for each Rx-SC for rollover purposes, and two Tx-SAs are used for Tx-SC for rollover purposes. This translates to 32 peers for each security zone.

Under each port, you can configure a max-peer parameter to assign the number of peers allowed on that port.

Note: You must ensure that the number of peers does not exceed the limit of maximum peers per security zone or maximum peers per port; for example, exceeds the port max-peer parameter.

If the maximum peer is exceeded, the peer connectivity becomes random. In the case of a node failure or packet loss, peers join the CA randomly, on a first-come-first-served basis.

Caution: Nokia strongly recommends that the maximum peer value is not exceeded per-security zone or port.

2.3.3.16. Clear tag mode

In most Layer 2 networks, MAC forwarding is done using a destination MAC address. The 802.1AE standard requires that any field after source and destination MAC address and after the SecTAG must be encrypted. This includes the 802.1Q tags. In some VLAN switching networks, it might be desired to leave the 802.1Q tag in clear text.

7210 SAS allows the configuration of 802.1Q tag in clear text by placing the 802.1Q tag before the SecTAG, or encrypts it by placing it after the SecTAG.

The following table lists the MACsec encryption of 802.1Q tags when the clear-tag is configured.

2.3.3.17. 802.1X tunneling and multihop MACsec

MACsec is an Ethernet packet and, as with any Ethernet packet, can be forwarded through multiple switches using Layer 2 forwarding. The encryption and decryption of the packets is done using the 802.1x (MKA) capable ports.

To ensure that MKA is not terminated on an intermediate switch or router, you can enable 802.1x tunneling on the corresponding port.

Check to see if tunneling is enabled using the following command:

By enabling tunneling, the 802.1x MKA packets transit that port without being terminated, because such MKA negotiation does not occur on a port that has 802.1x tunneling enabled.

2.3.3.18. EAPoL destination address

The MKA packets are transported over EAPoL with a multicast destination MAC address.

In cases where a point-to-point connection from the MKA to a peer node over a Layer 2 multihop cloud is required, you can set the EAPoL destination MAC address to the peer MAC address. This forces the MKA to traverse multiple nodes and establish an MKA session with the specific peer.

2.3.3.19. Mirroring consideration

Mirroring is performed prior to MACsec encryption. Therefore, if a port is MACsec-enabled and is also being mirrored, all the mirror packets are in clear text.

2.4.3.1. LLDP-MED reference model

LLDP-MED devices are composed of two primary device types: network connectivity devices and endpoint devices.

The LLDP-MED network connectivity devices provide access to the IEEE 802 LAN infrastructure for LLDP-MED endpoint devices. An LLDP-MED network connectivity device is a LAN access device based on any of the following technologies:

The LLDP-MED endpoint devices are composed of three subtypes, as defined in ANSI/TIA-1057:

The following figure shows the LLDP-MED reference model.

Note: Acting as the network connectivity device, the 7210 SAS only supports the configuration of LLDP-MED communication device endpoints (Class III), such as VoIP phone, using the Network Policy TLV.

Figure 11:  LLDP-MED reference model 

2.4.3.2. LLDP-MED network connectivity device functions

To enable LLDP-MED network connectivity device functions, configure the config port ethernet lldp dest-mac lldp-med admin-status command. When this command is configured, the behavior of the node is as follows.

Note: The configure port ethernet lldp admin-status command must be enabled for LLDP-MED TLV processing. The admin-status configuration in the lldp context must not conflict with the admin-status configuration in the lldp-med context.

When LLDP-MED is enabled on the port, the Network Policy TLV is sent out of the port using the parameters configured for the network policy that is associated with the port.

Note: Refer to the 7210 SAS-D, Dxp, K 2F1C2T, K 2F6C4T, K 3SFP+ 8C Basic System Configuration Guide for more information about configuring network policy parameters using commands in the config>system>lldp>lldp-med context.

2.4.3.3. LLDP-MED endpoint device move notification

The endpoint move detection notification enables VoIP management systems to track the movement of VoIP phones. On the 7210 SAS, the user has the option to generate the lldpXMedTopologyChangeDetected event on detection of movement of the endpoint device. By default, this event is disabled. To enable the event, configure the config>log>event-control lldp generate and config>port>ethernet>lldp> dest-mac>nearest-bridge>notification commands.

2.4.3.4. Modified use of TLVs defined in LLDP

LLDP-MED modifies the usage of some LLDP base TLVs for network connectivity devices. Specifically, the 7210 SAS supports the transmission of the MAC/PHY Configuration Status TLV when LLDP-MED is enabled. The transmission of this TLV is enabled using the config>port>ethernet>lldp>dest-mac>lldp-med>tx-tlvs mac-phy-config-status CLI command option.

2.6.7.1. LAG hashing algorithm for the 7210 SAS-D

The following table describes the packet fields used for hashing for services configured on the 7210 SAS-D.

Note: The following notes apply to Table 16: The term “learned” corresponds to the Destination MAC. the term “Source and Destination MAC” refers to customer source and destination MACs unless otherwise specified. The VLAN ID is considered for learned PBB and non-IP traffic in the VPLS service only for traffic ingressing at dot1q, Q.*, Q1.Q2 SAPs. Only the outer VLAN tag is used for hashing.

2.6.7.2. LAG hashing algorithm for the 7210 SAS-Dxp

The following table describes the packet fields used for hashing for services configured on the 7210 SAS-Dxp.

Note: The following notes apply to Table 17: The term “learned” corresponds to the Destination MAC. The term “Source and Destination MAC” refers to customer source and destination MACs unless otherwise specified. The VLAN ID is considered for learned PBB and non-IP traffic in the VPLS service only for traffic ingressing at dot1q, Q.*, Q1.Q2 SAPs. Only the outer VLAN tag is used for hashing.

2.6.7.3. LAG hashing algorithm for the 7210 SAS-K 2F1C2T

The following table describes the packet fields used for hashing for services configured on the 7210 SAS-K 2F1C2T.

Note: The following notes apply to Table 18: The term “learned” corresponds to the Destination MAC. The term “Source and Destination MAC” refers to customer source and destination MACs unless otherwise specified.

2.6.7.4. LAG hashing algorithm for the 7210 SAS-K 2F6C4T and 7210 SAS-K 3SFP+ 8C

The following table describes the packet fields used for hashing for services configured on the 7210 SAS-K 2F6C4T and 7210 SAS-K 3SFP+ 8C.

Note: The following notes apply to Table 19: The term “learned” corresponds to the destination MAC. The term “Source and Destination MAC” refers to customer source an destination MACs unless otherwise specified. SAP to SAP and SAP to SDP: Packet fields for IP traffic are used for hashing only if the number of VLAN tags is two or fewer. IP packets with more than two tags use the same hashing parameters as non-IP traffic. SDP to SAP and SDP to SDP: Packet fields for IP traffic are used for hashing only if the number of VLAN tags is 1 or 0. IP packets with more than one tag use the same hashing parameters as non-IP traffic. RVPLS routed traffic uses the same parameters as traffic in IES service. For IPv6 packets, the source and destination IP addresses are XORed and collapsed into a 32-bit value.

2.6.7.5. Packet fields used for pseudowire hash-label generation on the 7210 SAS-K 2F6C4T and 7210 SAS-K 3SFP+ 8C

The following table describes the packet fields used by different services and traffic types to generate the PW hash label.

2.6.7.6. LDP ECMP hashing algorithm for the 7210 SAS-K 2F6C4T and 7210 SAS-K 3SFP+ 8C

The following table describes the packet fields used for LDP ECMP hashing for label edge router (LER) and label switching router (LSR) devices on the 7210 SAS-K 2F6C4T and 7210 SAS-K 3SFP+ 8C.

2.6.8.1. Overview

MC-LAG is a method of providing redundant Layer 2/3 access connectivity that extends beyond link level protection by allowing two systems to share a common LAG end point.

The CPE/access node is connected with multiple links toward a redundant pair of Layer 2/3 access aggregation nodes such that both link and node level redundancy is provided. By using a multi-chassis LAG protocol, the paired Layer 2/3 aggregation nodes (referred to as the redundant-pair) appear to be a single node that is utilizing LACP toward the access node. The multi-chassis LAG protocol between the redundant-pair ensures a synchronized forwarding plane to and from the CPE/access node. It is used to synchronize the link state information between the redundant-pair nodes and provide correct LACP messaging to the CPE/access node from both redundant-pair nodes.

To ensure SLAs and deterministic forwarding characteristics between the CPE/access and the redundant-pair node, the multi-chassis LAG function provides an active/standby operation toward/from the CPE/access node. LACP is used to manage the available LAG links into active and standby states so that only links from one aggregation node are active at a time to and from the CPE/access node.

MC-LAG has the following characteristics.

Figure 13 and Figure 14 show different combinations of supported MC-LAG attachments. The supported configurations can be divided into the following subgroups:

The following figure shows dual homing to remote PE pairs.

Figure 13:  MC-LAG L2 dual homing to remote PE pairs 

The following figure shows dual homing to local PE pairs.

Figure 14:  MC-LAG L2 dual homing to local PE-pairs 

The forwarding behavior of the nodes is governed by the following principles. Note that the logical destination (actual forwarding decision) is primarily determined by the service (VPLS or VLL), and the following principle apply only if the destination or source is based on MC-LAG.

2.6.8.2. Point-to-point redundant connection across Layer 2/3 VPN network

The following figure shows the connection between two CPE/access nodes across network based on Layer 2/3 VPN pseudo-wires. The connection between a CPE/access node and a pair of access aggregation PE routers is realized by MC-LAG. From the CPE/access node perspective, a redundant pair of access aggregation PE routers acts as a single partner in LACP negotiation. At any point in time, only one of the routers has active links in a specific LAG. The status of LAG links is reflected in the status signaling of pseudowires set between all participating PEs. The combination of active and standby states across LAG links and pseudowires give only one unique path between a pair of MSANs.

Note that the configuration in the following figure shows an example configuration of VLL connections based on MC-LAG. Specifically, it shows a VLL connection where the two ends (SAPs) are located on two different redundant-pairs. However, additional configurations are possible, for example:

Figure 15:  P2P redundant connection through a Layer 2 VPN network 

2.6.8.3.  Configuration guidelines

The following guidelines apply to MC-LAG configurations.

2.6.8.4. Configuring multi-chassis redundancy

Note: When configuring associated LAG ID parameters, the LAG must be in access mode and LACP must be enabled.

Use the following syntax to configure multi-chassis redundancy features.

The following is a sample configuration output.

2.6.8.5. MC-LAG support on 7210 SAS-D and 7210 SAS-K 2F1C2T

Multi-Chassis LAG (MC-LAG) is an extension of a LAG concept that provides node-level redundancy in addition to the link-level redundancy provided by “regular LAG”. Typically, MC-LAG is deployed network-wide, along with IP/MPLS, providing redundant connections between different access end points. In a typical MC-LAG deployment, a pair of nodes are configured to be MC-LAG peers (also referred to as MC-LAG servers), and access devices are connected to the MC-LAG peers using LAGs with active/standby LAG groups.

The 7210 SAS-D, 7210 SAS-K 2F1C2T, 7210 SAS-K 2F6C4T, and 7210 SAS-K 3SFP+ 8C platforms can be connected to an MC-LAG-enabled node, such as an MC-LAG server. In particular, these platforms allow for provisioning of links into subgroups in a LAG and support active/standby links. The MC-LAG solution can be achieved with or without subgroups configured.

2.6.9.1. 802.1x network access control

The Nokia 7210 SAS supports network access control of client devices (PCs, STBs, etc.) on an Ethernet network using the IEEE. 802.1x standard. 802.1x is known as Extensible Authentication Protocol (EAP) over a LAN network or EAPOL.

2.6.9.2. 802.1x basics

The authentication exchange is carried out between the supplicant and the authentication server, the authenticator acts only as a bridge. The communication between the supplicant and the authenticator is done through the Extended Authentication Protocol (EAP) over LANs (EAPOL). On the back end, the communication between the authenticator and the authentication server is done with the RADIUS protocol. The authenticator is therefore a RADIUS client, and the authentication server a RADIUS server.

The router initiates the procedure when the Ethernet port becomes operationally up, by sending a special PDU called EAP-Request/ID to the client. The client can also initiate the exchange by sending an EAPOL-start PDU, if it doesn't receive the EAP-Request/ID frame during bootup. The client responds on the EAP-Request/ID with a EAP-Response/ID frame, containing its identity (typically username + password).

After receiving the EAP-Response/ID frame, the router will encapsulate the identity information into a RADIUS AccessRequest packet, and send it off to the configured RADIUS server.

The RADIUS server checks the supplied credentials, and if approved will return an Access Accept message to the router. The router notifies the client with an EAP-Success PDU and puts the port in authorized state.

2.6.9.3. 802.1x timers

The 802.1x authentication procedure is controlled by a number of configurable timers and scalars. There are two separate sets, one for the EAPOL message exchange and one for the RADIUS message exchange.

EAPOL timers:

RADIUS timer and scaler:

The router can also be configured to periodically trigger the authentication procedure automatically. This is controlled by the enable re-authentication and reauth-period parameters. Reauth-period indicates the period in seconds (since the last time that the authorization state was confirmed) before a new authentication procedure is started. The range of reauth-period is 1 to 9000 seconds (the default is 3600 seconds, one hour). Note that the port stays in an authorized state during the re-authentication procedure.

2.6.9.4. 802.1x configuration and limitations

Configuration of 802.1x network access control on the router consists of two parts:

801.x authentication:

2.6.9.5. 802.1x tunneling for Epipe service

Customers who subscribe to Epipe service considers the Epipe as a wire, and run 802.1x between their devices which are located at each end of the Epipe.

Note: This feature applies only to port-based Epipe SAPs because 802.1x runs at the port level not the VLAN level. Therefore such ports must be configured as null encapsulated SAPs.

When 802.1x tunneling is enabled, the 802.1x messages received at one end of an Epipe are forwarded through the Epipe. When 802.1x tunneling is disabled (by default), 802.1x messages are dropped or processed locally according to the 802.1x configuration (shutdown or no shutdown).

Enabling 802.1x tunneling requires the 802.1x mode to be set to force-auth. Enforcement is performed at the CLI level.

2.7.4.1. Default MTU values

The following table describes the default MTU values that are dependent upon the (sub-) port type, mode, and encapsulation.

2.7.4.2. Modifying MTU defaults on 7210 SAS-D and 7210 SAS-Dxp

On the 7210 SAS-D and 7210 SAS-Dxp, MTU parameters can be modified only on the port level.

The default MTU values should be modified to ensure that packets are not dropped due to frame size limitations.

2.7.4.3. Modifying MTU defaults on the 7210 SAS-K 2F1C2T, 7210 SAS-K 2F6C4T, and 7210 SAS-K 3SFP+ 8C

MTU parameters can be modified on the port level and at the service level.

The default MTU values should be modified to ensure that packets are not dropped due to frame size limitations.

The service MTU must be less than or equal to both the access SAP port MTU and the access-uplink port MTU values. If the service from the 7210 SAS-K 2F1C2T is transported over an SDP in the IP/MPLS network (the SDP is not originating or terminating on the node), the operational path MTU can be less than the service MTU. In this case, user might need to modify the MTU value accordingly.

2.7.4.4. Configuration example for 7210 SAS-K 2F1C2T, 7210 SAS-K 2F6C4T, and 7210 SAS-K 3SFP+ 8C using SAPs in the service

In order for the maximum length service frame to successfully travel from a local ingress SAP to a remote egress SAP, the MTU values configured on the port on which the local ingress SAP is provisioned and the port on which the egress SAP is provisioned must be coordinated to accept the maximum frame size the service can forward.

The following figure shows an example of the targeted MTU values to configure for an Epipe service (ALA-A and ALA-B).

Figure 16:  MTU configuration example 

Since ALA-A uses Dot1q encapsulation, the port 1/1/1 MTU must be set to 1518 to be able to accept a 1514-byte service frame (see the following table for MTU default values). Each of the access uplink port MTU must be set to at least 1518 as well. Finally, the MTU of ALA-B SAP (access port 1/1/2) must be at least 1514, as it uses null encapsulation.

The following table describes sample MTU configuration values.

Instead, if ALA-A uses a dot1q-preserve SAP on port 1/1/1, then port 1/1/1 MTU must be set to 1518 to be able to accept a 1514-byte service frame (see the following table for MTU default values). Each of the access uplink port MTU must be set to at least 1522 as well. Finally, the MTU of ALA-B SAP (access port 1/1/2) must be at least 1518, as it uses Dot1q encapsulation.

The following table describes sample MTU configuration values.