LAG

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

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

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

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.

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

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.

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:

• Selection of the common system ID, system-priority, and administrative-key are used in LACP messages to ensure that partner systems consider all links part of the same LAG.

• The selection algorithm is extended to allow the selection of the active subgroup.

  • The subgroup definition in the LAG context is still local to the single box. Consequently, even when subgroups configured on two different systems have the same subgroup-id, they are still considered two separate subgroups within the specific LAG.

  • The configuration of multiple subgroups per PE in an MC-LAG is supported.

  • If there is a tie in the selection algorithm, for example, two subgroups with identical aggregate weight (or number of active links), the group that is local to the system with lower system LACP priority and LAG system ID is selected.

• Providing an inter-chassis communication channel allows the inter-chassis communication to support LACP on both systems. The communication channel enables the following functionality:

  • It supports connections at the IP level that do not require a direct link between two nodes. The IP address configured at the neighbor system is one of the addresses of the system (interface or loop-back IP address).

  • The communication protocol provides heartbeat mechanism to enhance robustness of the MC-LAG operation and detect node failures.

  • It supports operator actions that force an operational change on nodes.

  • The LAG group-ids do not have to match between neighbor systems. At the same time, multiple LAG groups between the same pair of neighbors is also allowed.

  • It verifies that the physical characteristics, such as speed and auto-negotiation are configured and initiates operator notifications (traps) if errors exist. Consistency of MC-LAG configuration (system-id, administrative-key and system-priority) is provided. Load-balancing must be consistently configured on both nodes.

  • Traffic over the signaling link is encrypted using a user-configurable message digest key.

• The MC-LAG function provides active/standby status to other software applications to build reliable solutions.

MC-LAG L2 dual homing to remote PE pairs and MC-LAG L2 dual homing to local PE-pairs show different combinations of supported MC-LAG attachments. The supported configurations can be divided into the following subgroups:

• dual-homing to remote PE pairs

  • both end-points attached with MC-LAG

  • one end-point attached

• dual-homing to local PE pair

  • both end-points attached with MC-LAG

  • one end-point attached with MC-LAG

  • both end-points attached with MC-LAG to two overlapping pairs

The following figure shows dual homing to remote PE pairs.

The following figure shows 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.

• Packets received from the network will be forwarded to all local active links of the specific destination-sap based on conversation hashing. If there are no local active links, the packets will be cross-connected to the inter-chassis pseudowire.

• Packets received from the MC-LAG sap will be forwarded to the active destination pseudowire or active local links of destination-sap. If no such objects are available at the local node, the packets will be cross-connected to inter-chassis pseudowire.

The following figure shows the connection between two CPE/access nodes across network based on Layer 2/3 VPN pseudowires. 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:

• both ends of the same VLL connections are local to the same redundant-pair

• one end of the VLL endpoint is on a redundant-pair and the other on a single (local or remote) node

The following guidelines apply to MC-LAG configurations:

• MC-LAG peer nodes must be of the same platform type. For example, 7210 SAS-K 2F6C4T can only peer with another 7210 SAS-K 2F6C4T, and 7210 SAS-K 3SFP+ 8C can only peer with another 7210 SAS-K 3SFP+ 8C. 7210 SAS-K 2F6C4T cannot be configured with 7210 SAS-K 3SFP+ 8C as its MC-LAG peer.

• MC-LAG is only supported when using MPLS uplinks with network ports. It is not supported with access-uplink ports.

• The 7210 SAS-K 2F6C4T and 7210 SAS-K 3SFP+ 8C can also be MC-LAG clients, with an active/standby LAG configuration used to dual-home to access-aggregation routers when using access-uplink ports. In this scenario the user has an option to provision the uplinks as access-uplink ports to dual-home into two aggregation PE routers that are configured as MC-LAG peers.

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

config>redundancy
  multi-chassis
     peer ip-address
        authentication-key [authentication-key | hash-key][hash | hash2]
        description description-string
        mc-lag
           hold-on-neighbor-failure duration
           keep-alive-interval interval
           lag lag-id lacp-key admin-key system-id system-id [remotelag lag-
id] system-priority system-priority
           no shutdown
        no shutdown
        source-address ip-address
        sync
           igmp-snooping
           port [port-id | lag-id] [sync-tag]range encap-range sync-tag
           no shutdown

config>redundancy# multi-chassis
config>redundancy>multi-chassis# peer 10.10.10.2 create
config>redundancy>multi-chassis>peer# description "Mc-Lag peer 10.10.10.2"
config>redundancy>multi-chassis>peer# mc-lag
config>redundancy>mc>peer>mc-lag# lag 1 lacp-key 32666 system-
id 00:00:00:33:33:33 system-priority 32888
config>redundancy>mc>peer>mc-lag# no shutdown
config>redundancy>mc>peer>mc-lag# exit
config>redundancy>multi-chassis>peer# no shutdown
config>redundancy>multi-chassis>peer# exit
config>redundancy>multi-chassis# exit
config>redundancy#

*7210-SAS>config>redundancy# info
----------------------------------------------
        multi-chassis
            peer 1.1.1.1 create
                shutdown
                sync
                    shutdown
                    port 1/1/1 create
                    exit
                exit
            peer 10.20.1.3 create
                mc-lag
                    lag 3 lacp-key 1 system-id 00:00:00:aa:bb:cc remote-
lag 1 system-priority 1
                    no shutdown
                exit
                no shutdown
            exit
        exit
----------------------------------------------
*7210-SAS>config>redundancy#

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.

The Nokia 7210 SAS supports network access control of client devices (PCs, STBs, and so on) 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.

• The supplicant — This is the end-user device that requests access to the network.

• The authenticator — Controls access to the network. Both the supplicant and the authenticator are referred to as PAEs.

• The authentication server — Performs the actual processing of the user information.

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 does not 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.

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:

• transit-period

  Indicates how many seconds the Authenticator will listen for an EAP-Response/ID frame. If the timer expires, a new EAP-Request/ID frame will be sent and the timer restarted. The default value is 60. The range is 1 to 3600 seconds.

• supplicant-timeout

  This timer is started at the beginning of a new authentication procedure (transmission of first EAP-Request/ID frame). If the timer expires before an EAP-Response/ID frame is received, the 802.1x authentication session is considered as having failed. The default value is 30. The range is 1 to 300.

• quiet-period

  Indicates number of seconds between authentication sessions. It is started after logout, after sending an EAP-Failure message or after expiry of the supplicant-timeout timer. The default value is 60. The range is 1 to 3600.

RADIUS timer and scaler:

• max-auth-req

  Indicates the maximum number of times that the router will send an authentication request to the RADIUS server before the procedure is considered as having failed. The default value is value 2. The range is 1 to 10.

• server-timeout

  Indicates how many seconds the authenticator will wait for a RADIUS response message. If the timer expires, the access request message is sent again, up to max-auth-req times. The default value is 60. The range is 1 to 3600 seconds.

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.

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

• Generic parameters, which are configured under config>security>dot1x

• Port-specific parameters, which are configured under config>port>ethernet>dot1x

801.x authentication:

• Provides access to the port for any device, even if only a single client has been authenticated.

• Can only be used to gain access to a predefined Service Access Point (SAP). It is not possible to dynamically select a service (such as a VPLS service) depending on the 802.1x authentication information.

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.

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.