Multi-Chassis Ring Layer 2 with Enhanced Subscriber Management
This chapter provides information about MC-ring layer 2 with enhanced subscriber management (ESM).
Topics in this chapter include:
Applicability
The information and configuration in this chapter is based on SR OS Release 7.0.R5.
Overview
Multi-Chassis Ring (MC-ring) is an extension for dual homing support in TPSDA (Triple Play Service Delivery Architecture) networks based on Layer 2 CO (Layer 2 Central Office) model. The extension addresses networks where multiple access nodes (for example, DSLAMs, GPON OLT) are connected in a single ring.
MC Ring Layer 2 ESM is considered an extension or evolution for ring topologies of the Multi-Chassis LAG dual-homing solution used for directly connected access nodes.
MC Ring Layer 2 CO is documented in the Triple Play Enhanced Subscriber Management / Dual Homing section of the 7450 ESS, 7750 SR, and VSR Triple Play Service Delivery Architecture Guide.
MC-Ring
MC-Ring Layer 2 CO Dual Homing shows a typical ring-based configuration of network model based on the Layer 2 CO model.
Individual rings of access nodes are aggregated at the Broadband Service Aggregator (BSA) level in one (or multiple) Virtual Private LAN Service (VPLS) service(s). At higher aggregation levels, Broadband Service Router (BSR) individual BSAs are connected to a Layer 3 interface (Internet Enhanced Service (IES) or Virtual Private Routed Network (VPRN)) by means of a spoke SDP (service destination point) termination. Every Layer 3 interface at the BSR level aggregates all subscribers in one or more subnets. ESM is performed in the BSAs.
The key functional components of the MC-Ring Layer 2 CO dual-homing redundancy solution are:
Mirroring of the subscriber state between the two BSAs performing subscriber management using the multi-chassis synchronization (MCS) protocol (BSA-1 and BSA-2 in MC-Ring Layer 2 CO Dual Homing).
Ring control between the two BSAs, using the following mechanisms:
In-band bi-directional forwarding detection (BFD) between the BSAs over the ring to monitor ring integrity and detect failures. A BFD session between BSA-1 and BSA-2 runs through the access ring using a dedicated IES/VPRN interface configured on both BSAs. This connection uses a separate VLAN throughout the ring (access nodes provide transparent bridging for this VLAN).
Out-of-band communication between the BSA nodes to exchange information about the reachability of individual access nodes, and to verify the configuration consistency of the ring. The information on configuration is synchronized through MCS (this use of MCS is related to, but independent to, MCS for subscriber-state synchronization mentioned above).
Ring Node Connectivity Verification (RNCV). Each BSA uses RNCV to detect the reachability of individual Access Nodes. It is used after a ring failure to determine which BSA should handle the traffic of each Access Node. RNCV uses ARP requests to ‟ping” individual ANs, which must be configured with an IP address for this purpose.
Per-subscriber attribute (intermediate destination ID) for the BSA to know the Access Node each subscriber is connected to (assigned through RADIUS or DHCP/Python).
VRRP in the BSRs to provide a redundant default gateway to the CPEs/Home Gateways. BSRs do not perform any subscriber management functions.
The operation of dual homing at the BSA level will be covered based on two underlying mechanisms.
MC-Ring Layer 2 CO Operation
To describe the functional behavior and operation of the dual-homing concept in a ring, it is best to sub-divide the description into the following three parts:
Steady-state operation with ring fully closed
Transition to ring-broken state
Transition from ring-broken to steady state operation
Steady-State Operation of Dual-Homed Ring
Dual homing Under Steady-State Condition illustrates the detailed operation of the dual-homed ring. The steady-state is achieved under following conditions:
Both nodes are configured in a consistent way
The MCS peering relation is up
In-Band Ring Control Connection (IB-RCC) is in an operationally UP state.
Note:This connection is set-up using BFD session between IP interfaces on BSA-1 and BSA-2
Figure 2. Dual homing Under Steady-State Condition 
Under the above conditions, the ring is fully closed and every access node (the ring-node) has two possible paths toward the VPLS core. Dual homing Under Steady-State Condition refers to them as path-a and path-b. In order to avoid the loop created by the ring, only one of the paths may be used by any given ring-node for any given VLAN. The assignment of the individual VLANs to path-a or path-b, respectively, has to be provisioned on both BSAs in a consistent manner. The BSA with a lower IP address in the interface used for BFD will be the master for the VLANs associated with path-a and standby for the VLANs associated with path-b.
The following summarizes the behavior of the master and standby BSA for a given path (a or b) and the VLANs configured for that path:
Master BSA for the VLANs/SAPs associated with a given path (a or b):
SAPs associated with the path are operationally up and FDB entries for sub-hosts point to the corresponding SAP
Master BSA for a path performs RNCV checks to all ring nodes. RNCV failures trigger an alarm but do not trigger a switchover
The ARP reply agent replies to ARP requests for subscriber-hosts associated with ring-nodes for which the BSA is master
Standby BSA:
All SAPs associated with the path for which the BSA is standby will be operationally down and all FDB entries of subscriber hosts associated with those SAPs will point towards an SDP connecting to the master BSA.
Broken-Ring Operation and the Transition to this State
Broken Ring State illustrates the scenario with the broken ring (link failure or ring-node failure). This state is reached under following conditions:
Both nodes are configured in a consistent way
The MCS peering relation is up
IB-RCC is in operationally down state
In this situation, every ring node has only one access path towards the VPLS core and hence the path-a and path-b notion has no real meaning in this situation.
From a functional point of view, both BSAs are now the master for the ring-nodes they can reach. For all hosts behind unreachable ring-nodes, the corresponding subscriber host FDB (Forwarding DataBase) entries will point to SDP pointing to the other head-end ring PE.
Transition from Broken to Closed Ring State
MC-ring operates in a revertive mode. This means that whenever the ring connectivity is restored, the BSA with the lower IP address in the IB-RCC communication channel will become master of path-a and slave for ring-b with vice versa operations on the other BSA.
The actions in this case are straightforward. After restoration of BFD session, the master functionality is assumed by respective BSAs. The FDB tables are updated according to the master/standby role of the given BSA and FDB population messages will be sent accordingly.
Configuration
The network topology is displayed in Network Topology. The setup consists of two BSA nodes (PE-1 and PE-2), two BSR nodes (PE-3, PE-4) and another PE router (PE-5). A setup with one BSR node and two BSA nodes can also be used, but in this example, two (2) BSR nodes were used to show the typical Layer 2-CO setup with VRRP and Protocol Independent Multicast (PIM) on the BSRs. The access ring consists of four CE nodes.
Base Topology
This section assumes that the following base configuration has been implemented on the PE:
Cards, MDAs and ports configured
Interfaces configured
IGP (Interior Gateway Protocol) configured and converged LDP (Label Distribution Protocol) configured on the interfaces between PE-3-PE-1, PE-1-PE-2 and PE-2-PE-4
T-LDP (Targeted-LDP) configured on PE-1, PE-2, PE-3, PE-4
SDPs configured between PE-3-PE-1, PE-1-PE-2 and PE-2-PE-4
You can choose between OSPF and IS-IS as the IGP. Both LDP and RSVP (Resource Reservation Protocol) can be used for signaling the transport MPLS labels. Alternatively, GRE (Generic Routing Encapsulation) can be used for the transport tunnels. In this example, OSPF is configured and LDP SDPs are used.
7750 SR routers are used as ring-nodes to simulate Access Nodes. Ring-nodes can be any L2 device that support VLANs and have the ability to connect an IP interface to one VLAN (required for RNCV).
NTP Configuration
Time must be the same on the redundant NSAs (PE-1 and PE-2); otherwise, the lease times will be different on both nodes. NTP can be used:
configure system time
ntp
server 10.30.30.30 prefer
no shutdown
exit
exit all
MC-Ring Configuration
Configure a VPLS service on the CE routers for the In-Band Ring Control connection (BFD packets between PE-1 and PE-2 traversing the ring). This VPLS service will also be used for RNCV.
An Epipe service can also be used in case the service is only used for BFD. In that case, a separate service is required for the RNCV.
In this example, QinQ encapsulation is used and BFD and RNCV packets will use VLAN tag 1. Note that dot1q encapsulation can also be used.
The configuration of CE-1 is shown below. A similar configuration is required on the other CE routers.
configure
port 1/1/1
ethernet
mode access
encap-type qinq
exit
no shutdown
exit
port 1/1/2
ethernet
mode access
encap-type qinq
exit
no shutdown
exit
service
vpls 1 customer 1 create
interface "lo1" create
address 172.16.0.1/24
exit
sap 1/1/1:1.0 create
exit
sap 1/1/2:1.0 create
exit
no shutdown
exit
exit all
An interface lo1 is created in the VPLS. This interface will be used for RNCV.
On the BSA nodes (PE-1 and PE-2), configure an IES services that will originate BFD and RNCV messages. On PE-1:
configure
port 1/1/1
ethernet
mode access
encap-type qinq
exit
no shutdown
exit
service
ies 1 customer 1 create
interface "bfd-rncv1" create
address 172.16.0.251/24
bfd 100 receive 100 multiplier 3
sap 1/1/1:1.0 create
exit
exit
no shutdown
exit
exit all
On PE-2:
configure
port 1/1/2
ethernet
mode access
encap-type qinq
exit
no shutdown
exit
service
ies 1 customer 1 create
interface "bfd-rncv1" create
address 172.16.0.252/24
bfd 100 receive 100 multiplier 3
sap 1/1/2:1.0 create
exit
exit
no shutdown
exit
exit all
In-Band Ring Control Connection BFD is always originated on an IES or VPRN service on the BSA nodes. RNCV messages can be originated from the same IES/VPRN service or from a separate service.
Configure Multi-Chassis Synchronization (MCS) on the BSA nodes. Enable MCS for igmp-snooping, mc-ring and sub-mgmt. The configuration of PE-1 is shown below. The configuration of PE-2 is similar.
configure redundancy multi-chassis peer 192.0.2.2 create
sync
igmp-snooping
mc-ring
sub-mgmt
port 1/1/1 sync-tag "l2ring1" create
exit
no shutdown
exit
no shutdown
exit all
Add the MC-ring configuration on the BSA nodes and link the Ring Control Connection BFD session to the IES service created before.
configure redundancy multi-chassis peer 192.0.2.2 create
mc-ring
ring "l2ring1" create
in-band-control-path
service-id 1
interface "bfd-rncv1"
dst-ip 172.16.0.252
exit
no shutdown
exit
exit
no shutdown
exit all
Note that the ring name is exactly the same as the sync-tag already configured.
At this moment, the MC-ring should be up:
A:PE-1# show redundancy multi-chassis mc-ring peer 192.0.2.2 ring l2ring1 detail
===============================================================================
Multi-Chassis MC-Ring Detailed Information
===============================================================================
Peer : 192.0.2.2
Ring Type : Layer 2
Sync Tag : l2ring1
Port ID : 1/1/1
Admin State : inService
Oper State : connected
Admin Change : 11/05/2009 21:17:54
Oper Change : 11/05/2009 21:17:54
Failure Reason : None
Control B Path : No
-------------------------------------------------------------------------------
In Band Control Path
-------------------------------------------------------------------------------
Service ID : 1
Interface Name : bfd-rncv1
Oper State : connected
Dest IP : 172.16.0.252
Src IP : 172.16.0.251
...
Next, configure under MCS the ring nodes on PE-1 and PE-2. This configuration will be used for the RNCV. The ring node configuration for CE-1 is shown below:
configure redundancy multi-chassis peer 192.0.2.2 mc-ring ring l2ring1
ring-node "CE-1" create
connectivity-verify
dst-ip 172.16.0.1
interval 1
service-id 1
vlan 1
no shutdown
exit
exit
exit all
The interval parameter is the interval used to check the reachability of the CE nodes (configurable from 1 to 6000 minutes). A BFD failure will also be a trigger for a reachability check.
The configuration on PE-2 is identical and the configuration of the other ring nodes is similar.
Configure VLAN 3 to take path-b (default is path-a).
configure redundancy multi-chassis peer 192.0.2.2 mc-ring ring l2ring1
path-b
range 3-3
exit
exit all
MC-Ring Verification
Verify that MCS is up and running:
A:PE-1# show redundancy multi-chassis all
===============================================================================
Multi-Chassis Peers
===============================================================================
Peer IP Src IP Auth Peer Admin MC-Ring Oper MC-EP Adm
MCS Admin MCS Oper MCS State MC-LAG Adm MC-LAG Oper
-------------------------------------------------------------------------------
192.0.2.2 192.0.2.1 None Enabled inService --
Enabled Enabled inSync Disabled Disabled
===============================================================================
The output shows that MCS is administrative and operational up and that both peers are synchronized. MC-ring is operational in service.
The following output shows more detailed information about the configured ring:
A:PE-1# show redundancy multi-chassis mc-ring peer 192.0.2.2 ring l2ring1 detail
===============================================================================
Multi-Chassis MC-Ring Detailed Information
===============================================================================
Peer : 192.0.2.2
Ring Type : Layer 2
Sync Tag : l2ring1
Port ID : 1/1/1
Admin State : inService
Oper State : connected
Admin Change : 11/05/2009 21:22:29
Oper Change : 11/05/2009 21:22:29
Failure Reason : None
Control B Path : No
-------------------------------------------------------------------------------
In Band Control Path
-------------------------------------------------------------------------------
Service ID : 1
Interface Name : bfd-rncv1
Oper State : connected
Dest IP : 172.16.0.252
Src IP : 172.16.0.251
Debounce State : inService
Debounce Max : 10 s
Debounce Guard : 60 s
-------------------------------------------------------------------------------
VLAN Managed Range
-------------------------------------------------------------------------------
full range
-------------------------------------------------------------------------------
VLAN Map B Path Provisioned
-------------------------------------------------------------------------------
range 3-3
-------------------------------------------------------------------------------
VLAN Map Excluded Path Provisioned
-------------------------------------------------------------------------------
no range
-------------------------------------------------------------------------------
VLAN Map B Path Operational
-------------------------------------------------------------------------------
range 3-3
-------------------------------------------------------------------------------
VLAN Map Excluded Path Operational
-------------------------------------------------------------------------------
no range
The output above shows that the ring l2ring1 on port 1/1/1 is in service and connected. Ring-node Connectivity Check (BFD) is running on interface bfd-rncv1 in service 1. All VLANs on port 1/1/1 use path-a (default) except VLAN 3, which uses path-b.
The BSA peer with the lower IP address (the master) will put the SAPs configured for path-a in operational up state while the SAPs configured in path-b will be put in operational down state. The other BSA peer will do the reverse. This is done to prevent loops in the ring.
No VLANs are configured to be excluded from the paths. If a VLAN is configured to be excluded from the paths, the respective SAPs of this VLAN on both BSA nodes will be operationally up.
Check which ring-nodes are configured and connected:
A:PE-1# show redundancy multi-chassis mc-ring peer 192.0.2.2 ring l2ring1 ring-node
==============================================================================
MC-Ring Node entries
==============================================================================
Name Loc Oper St. Failure Reason
In Use Rem Oper St.
------------------------------------------------------------------------------
CE-1 connected None
No notTested
CE-2 connected None
No notTested
CE-3 connected None
No notTested
CE-4 connected None
No notTested
------------------------------------------------------------------------------
No. of MC-Ring Node entries: 4
==============================================================================
A:PE-1#
The output above shows that four ring-nodes are connected. Only the master will send RNCV messages to the ring-nodes. As soon as a ring failure occurs, the BFD session goes down and both BSA nodes send out RNCV messages to see which ring-nodes are connected.
When the reachability of the CE nodes is determined, the RNCV messages will be sent at a continuous interval (see above).
More detail about each ring-node can be provided with following command:
A:PE-1# show redundancy multi-chassis mc-ring peer 192.0.2.2 ring l2ring1 ring-node CE-1 detail
===============================================================================
Multi-Chassis MC-Ring Node Detailed Information
===============================================================================
Peer : 192.0.2.2
Sync Tag : l2ring1
Node Name : CE-1
Oper State Loc : connected
Oper State Rem : notTested
In Use : False
Admin Change : 11/05/2009 21:21:30
Oper Change : 11/05/2009 21:22:32
Failure Reason : None
-------------------------------------------------------------------------------
Ring Node Connectivity Verification
-------------------------------------------------------------------------------
Admin State : inService
Service ID : 1
Encap Value : 1
Dest IP : 172.16.0.1
Src IP : None
Interval : 1 minutes
Src MAC : None
===============================================================================
A:PE-1#
Unicast Services Configuration
Unicast Services — Logical Topology shows the logical setup of the services that will be created. A mesh SDP is used between PE-1 and PE-2. A spoke SDP could also be used.
In this setup, two unicast services (VPLS 2 and VPLS 3) are created. VPLS 2 uses path-a and VPLS 3 uses path-b.
The services use a mesh SDP between PE-1 and PE-2 and a spoke-SDP between PE-1/PE-3 and another spoke SDP between PE-2/PE-4. On PE-3 and PE-4 a spoke SDP terminated IES is configured with a VRRP default gateway address. The VRRP packets are switched through the BSAs.
IGMP snooping and ESM are configured on both services. ESM is required since the BSA node must know which ring-node each subscriber is connected to. In this setup, the intermediate destination identifier (int_dest_id) will be returned by Option 254 in x Dynamic Host Control Protocol (DHCP). ESM configuration details are outside the scope of this document. Refer to the 7450 ESS, 7750 SR, and VSR Triple Play Service Delivery Architecture Guide.
The following output shows the configuration of VPLS 2 on PE-1:
configure service
vpls 2 customer 1 create
description "VLAN_2"
split-horizon-group "RSHG" residential-group create
exit
sap 1/1/1:2.* split-horizon-group "RSHG" create
dhcp
snoop
lease-populate 10
no shutdown
exit
anti-spoof ip-mac
sub-sla-mgmt
def-sub-profile "initial"
def-sla-profile "initial"
sub-ident-policy "speedy"
multi-sub-sap 10
no shutdown
exit
exit
mesh-sdp 12:2 create
dhcp
snoop
exit
exit
spoke-sdp 13:2 create
dhcp
snoop
exit
exit
no shutdown
exit
exit all
The configuration of VPLS 3 is similar. The configuration of VPLS 2 and 3 are similar on PE-2.
The output below shows the subscriber management configuration on PE-1. Similar configuration is required on PE-2.
configure subscriber-mgmt
sla-profile "initial" create
exit
sub-profile "initial" create
exit
sub-ident-policy "speedy" create
strings-from-option 254
exit
exit all
Also, configure VLAN 2 and 3 on all the ring-nodes. This configuration is straightforward. Below is an example of the VLAN 2 configuration on CE-1. In this example, the client is connect to port 1/1/3 and should send packets with an outer tag of 2:
configure service
vpls 2 customer 1 create
sap 1/1/1:2.* create
exit
sap 1/1/2:2.* create
exit
sap 1/1/3:2.* create
exit
no shutdown
exit
exit all
In the example, VLAN 2.* and 3.* is used to allow for transparent transport of the customer VLAN.
The IES service where VPLS 2 terminates looks like this on BSR PE-3:
configure service
ies 2 customer 1 create
interface "VLAN_2" create
address 10.0.2.3/24
dhcp
server 10.10.10.10
trusted
no shutdown
exit
ip-mtu 1500
vrrp 2
backup 10.0.2.254
ping-reply
exit
local-proxy-arp
spoke-sdp 31:2 create
exit
exit
no shutdown
exit
exit all
And on PE-4:
configure service
ies 2 customer 1 create
interface "VLAN_2" create
address 10.0.2.4/24
dhcp
server 10.10.10.10
trusted
no shutdown
exit
ip-mtu 1500
vrrp 2
backup 10.0.2.254
ping-reply
exit
local-proxy-arp
spoke-sdp 42:2 create
exit
exit
no shutdown
exit
exit all
Notice that the ip-mtu must be set to match the vc-mtu signaled by the other side of the spoke-SDP. Otherwise, the service will be operationally down with a ServiceMTUMismatch.
Note also in the configuration that DHCP relay is done by configuring a DHCP server under the IES interface.
The configuration of IES 3 on PE-3 and PE-4 is similar..
On PE-5 an IES interface is configured to the DHCP-server. The interface is configured with a Dot1Q encapsulated port because this port will be also be used for an interface to the multicast server.
configure service
ies 2 customer 1 create
interface "dhcp-server" create
address 192.168.6.1/30
sap 1/1/3:2 create
exit
exit
no shutdown
exit
exit all
Unicast Services Verification
Request an IP address on VLAN 2 on CE-1. On BSA routers PE-1 and PE-2 following DHCP info can be checked:
A:PE-1# show service id 2 dhcp lease-state
===============================================================================
DHCP lease state table, service 2
===============================================================================
IP Address Mac Address Sap/Sdp Id Remaining Lease MC
LifeTime Origin Stdby
-------------------------------------------------------------------------------
10.0.2.107 00:00:64:01:01:02 1/1/1:2.* 09d07h38m DHCP
-------------------------------------------------------------------------------
Number of lease states : 1
===============================================================================
ESM show commands can be used to obtain the subscriber identity, IP address, MAC address and SLA-profile:
A:PE-1# show service active-subscribers
===============================================================================
Active Subscribers
===============================================================================
-------------------------------------------------------------------------------
Subscriber subscriber_1_vlan_2 (initial)
-------------------------------------------------------------------------------
-------------------------------------------------------------------------------
(1) SLA Profile Instance sap:1/1/1:2.* - sla:initial
-------------------------------------------------------------------------------
IP Address MAC Address PPPoE-SID Origin
-------------------------------------------------------
10.0.2.107 00:00:64:01:01:02 N/A DHCP
-------------------------------------------------------------------------------
Number of active subscribers : 1
===============================================================================
The following command gives more information about a specific subscriber:
A:PE-1# show service active-subscribers subscriber subscriber_1_vlan_2 detail
===============================================================================
Active Subscribers
===============================================================================
-------------------------------------------------------------------------------
Subscriber subscriber_1_vlan_2 (initial)
-------------------------------------------------------------------------------
I. Sched. Policy : N/A
E. Sched. Policy : N/A E. Agg Rate Limit: Max
Q Frame-Based Ac*: Disabled
Acct. Policy : N/A Collect Stats : Disabled
Rad. Acct. Pol. : N/A
Dupl. Acct. Pol. : N/A
ANCP Pol. : N/A
HostTrk Pol. : N/A
Sub. ANCP-String : "subscriber_1_vlan_2"
Sub. Int Dest Id : "CE-1"
Host Trk Rate Adj: N/A
-------------------------------------------------------------------------------
(1) SLA Profile Instance
- sap:1/1/1:2.* (VPLS 2)
- sla:initial
-------------------------------------------------------------------------------
Description : (Not Specified)
Host Limit : No Limit
Ingress Qos-Policy : 1 Egress Qos-Policy : 1
Ingress Queuing Type : Service-queuing
Ingress Filter-Id : N/A Egress Filter-Id : N/A
Ingress Report-Rate : N/A
Egress Report-Rate : N/A
Egress Remarking : from Sap Qos
Credit Control Pol. : N/A
-------------------------------------------------------------------------------
-------------------------------------------------------------------------------
IP Address MAC Address PPPoE-SID Origin
-------------------------------------------------------
10.0.2.107 00:00:64:01:01:02 N/A DHCP
The output above gives more details about which ring-node the customer is connected to (Sub. Int Dest Id : CE-1), which QoS policies are applied, statistics of each queue,
MCS Verification
Check if the two redundant peers are in sync and check the detailed MCS info:
A:PE-1# show redundancy multi-chassis sync peer 192.0.2.2
===============================================================================
Multi-chassis Peer Table
===============================================================================
Peer
-------------------------------------------------------------------------------
Peer IP Address : 192.0.2.2
Description : (Not Specified)
Authentication : Disabled
Source IP Address : 192.0.2.1
Admin State : Enabled
-------------------------------------------------------------------------------
Sync-status
-------------------------------------------------------------------------------
Client Applications : IGMPSnooping SUBMGMT RING
Sync Admin State : Up
Sync Oper State : Up
DB Sync State : inSync
Num Entries : 11
Lcl Deleted Entries : 0
Alarm Entries : 0
Rem Num Entries : 11
Rem Lcl Deleted Entries : 0
Rem Alarm Entries : 0
===============================================================================
MCS Application Stats
===============================================================================
Application : igmp
Num Entries : 0
Lcl Deleted Entries : 0
Alarm Entries : 0
-------------------------------------------------------------------------------
Rem Num Entries : 0
Rem Lcl Deleted Entries : 0
Rem Alarm Entries : 0
-------------------------------------------------------------------------------
Application : igmpSnooping
Num Entries : 0
Lcl Deleted Entries : 0
Alarm Entries : 0
-------------------------------------------------------------------------------
Rem Num Entries : 0
Rem Lcl Deleted Entries : 0
Rem Alarm Entries : 0
-------------------------------------------------------------------------------
Application : subMgmt
Num Entries : 1
Lcl Deleted Entries : 0
Alarm Entries : 0
-------------------------------------------------------------------------------
Rem Num Entries : 1
Rem Lcl Deleted Entries : 0
Rem Alarm Entries : 0
-------------------------------------------------------------------------------
Application : srrp
Num Entries : 0
Lcl Deleted Entries : 0
Alarm Entries : 0
-------------------------------------------------------------------------------
Rem Num Entries : 0
Rem Lcl Deleted Entries : 0
Rem Alarm Entries : 0
-------------------------------------------------------------------------------
Application : mcRing
Num Entries : 10
Lcl Deleted Entries : 0
Alarm Entries : 0
-------------------------------------------------------------------------------
Rem Num Entries : 10
Rem Lcl Deleted Entries : 0
Rem Alarm Entries : 0
-------------------------------------------------------------------------------
Application : mldSnooping
Num Entries : 0
Lcl Deleted Entries : 0
Alarm Entries : 0
-------------------------------------------------------------------------------
Rem Num Entries : 0
Rem Lcl Deleted Entries : 0
Rem Alarm Entries : 0
-------------------------------------------------------------------------------
Application : dhcpServer
Num Entries : 0
Lcl Deleted Entries : 0
Alarm Entries : 0
-------------------------------------------------------------------------------
Rem Num Entries : 0
Rem Lcl Deleted Entries : 0
Rem Alarm Entries : 0
-------------------------------------------------------------------------------
Application : subHostTrk
Num Entries : 0
Lcl Deleted Entries : 0
Alarm Entries : 0
-------------------------------------------------------------------------------
Rem Num Entries : 0
Rem Lcl Deleted Entries : 0
Rem Alarm Entries : 0
-------------------------------------------------------------------------------
===============================================================================
A:PE-1#
The output shows that both MCS peers are in sync and that entries are populated for MC-ring and Subscriber Management (DHCP lease states).
Notice that the lease states are also populated on PE-2:
A:PE-2# show service id 2 dhcp lease-state
===============================================================================
DHCP lease state table, service 2
===============================================================================
IP Address Mac Address Sap/Sdp Id Remaining Lease MC
LifeTime Origin Stdby
-------------------------------------------------------------------------------
10.0.2.107 00:00:64:01:01:02 1/1/2:2.* 09d06h16m DHCP Yes
-------------------------------------------------------------------------------
Number of lease states : 1
===============================================================================
A:PE-2#
The output is similar to the output on PE-1 except that on PE-2 the flag MC-Stdby is set to yes, which implies that this node is in standby mode for this VLAN.
This can be verified by looking at the status of the SAP on PE-1 and PE-2. On PE-1 the SAP is operationally up:
A:PE-1# show service id 2 sap 1/1/1:2.*
===============================================================================
Service Access Points(SAP)
===============================================================================
Service Id : 2
SAP : 1/1/1:2.* Encap : qinq
QinQ Dot1p : Default
Description : (Not Specified)
Admin State : Up Oper State : Up
Flags : None
Multi Svc Site : None
Last Status Change : 11/06/2009 17:17:26
Last Mgmt Change : 11/04/2009 22:51:15
===============================================================================
On PE-2 the situation is different:
A:PE-2# show service id 2 sap 1/1/2:2.*
===============================================================================
Service Access Points(SAP)
===============================================================================
Service Id : 2
SAP : 1/1/2:2.* Encap : qinq
QinQ Dot1p : Default
Description : (Not Specified)
Admin State : Up Oper State : Down
Flags : StandByForMcRing
Multi Svc Site : None
Last Status Change : 11/06/2009 18:07:30
Last Mgmt Change : 11/04/2009 23:43:16
===============================================================================
Notice that the SAP on PE-2 is operationally down and that a flag is set: StandByForMcRing.
The situation is reversed for VLAN 3 since it was configured for path-b; here the SAP on PE-1 is operationally down and the SAP on PE-2 is operationally up.
Ring Failure Verification
In case a ring failure occurs (either ring link failure or ring-node failure), the IB-RCC BFD session between PE-1 and PE-2 will go down and both nodes will put the SAP in operational up state.
Break the link between CE-2 and CE-1.
Observe that the ring is now in a broken state:
A:PE-1# show redundancy multi-chassis mc-ring peer 192.0.2.2
==============================================================================
MC-Ring entries
==============================================================================
Sync Tag Oper State Failure Reason
------------------------------------------------------------------------------
l2ring1 broken None
------------------------------------------------------------------------------
No. of MC-Ring entries: 1
==============================================================================
The following command shows the BSA to ring nodes connections:
A:PE-1# show redundancy multi-chassis mc-ring peer 192.0.2.2 ring l2ring1 ring-node
==============================================================================
MC-Ring Node entries
==============================================================================
Name Loc Oper St. Failure Reason
In Use Rem Oper St.
------------------------------------------------------------------------------
CE-1 connected None
Yes disconnected
CE-2 disconnected None
No connected
CE-3 disconnected None
No connected
CE-4 disconnected None
No connected
------------------------------------------------------------------------------
No. of MC-Ring Node entries: 4
==============================================================================
The output shows that CE-1 is connected to PE-1. CE-2, CE-3 and CE4 are connected to PE-2.
Notice that the SAPs on both PE-1 and PE-2 are now operationally up. This can be checked with the show service id 2 sap 1/1/1:2.* command on PE1 and the show service id 2 sap 1/1/2:2.* command on PE2.
Following the ring failure, the BSA nodes send a MAC address withdrawal message to all the SDP peers configured in the VPLS.
Multicast Service Configuration
In general, BTV (Broadcast TV) services are delivered to the DSLAM on a different VLAN using a different VPLS service. The DSLAM can send/relay IGMP group membership messages if it wants to receive a multicast stream. At the BSA level (PE-1 and PE-2), IGMP snooping is configured. At the BSR level (PE-3, PE-4) and the PE where the video source is located, PIM is configured and IGMP is configured on the IES service facing the BSA ring. The BSA ring consists of concatenated spoke SDPs. The spoke SDP ring is not closed between PE-3 and PE-4 to avoid a loop. Multicast Service — Logical Setup shows the logical setup for the multicast service with a MC-ring.
Configure an interface to the multicast server on PE-5:
configure service
ies 3 customer 1 create
interface "mcast-server" create
address 192.168.7.1/30
sap 1/1/3:3 create
exit
exit
no shutdown
exit
exit all
Configure a VPLS service on PE-1 and PE-2. The configuration on PE-1 is shown below. The VPLS configuration on PE-2 is similar.
configure service
vpls 4 customer 1 create
description "Multicast VLAN"
igmp-snooping
no shutdown
exit
sap 1/1/1:4.* create
exit
spoke-sdp 12:4 create
igmp-snooping
mrouter-port
exit
exit
spoke-sdp 13:4 create
igmp-snooping
mrouter-port
exit
exit
no shutdown
exit
exit all
Notice that igmp-snooping has been enabled and that the spoke SDPs are configured as mrouter-ports in order to forward the IGMP joins to the BSRs.
Configure a spoke SDP terminated IES service on PE-3:
configure service
ies 4 customer 1 create
interface "btv-dst" create
address 10.0.4.3/24
ip-mtu 1500
spoke-sdp 31:4 create
exit
exit
no shutdown
exit
exit all
On PE-4:
configure service
ies 4 customer 1 create
interface "btv-dst" create
address 10.0.4.4/24
ip-mtu 1500
spoke-sdp 42:4 create
exit
exit
no shutdown
exit
exit all
Notice that also here the ip-mtu must be configured to bring the service up. The ip-mtu is required to have an MTU match on the spoke SDP between the IES service and the VPLS service.
Configure PIM on PE-3, PE-4 and PE-5. The configuration on PE-3 is shown below. The PIM configuration on PE-4 and PE-5 is similar.
configure router pim
interface "system"
exit
interface "int-PE-3-PE-4"
priority 10
exit
interface "int-PE-3-PE-5"
exit
interface "btv-dst"
exit
rp
static
address 192.0.2.5
group-prefix 224.0.0.0/4
exit
exit
exit
exit all
PE-5 is statically configured as the RP. This is just an example. Different configurations can be used.
Configure IGMP on PE-3/PE-4:
configure router igmp interface btv-dst no shutdown
The service should also be configured on all ring nodes. Below, the configuration on CE-2 is shown. Similar configurations are required on the other ring-nodes.
configure service
vpls 4 customer 1 create
sap 1/1/1:4.* create
exit
sap 1/1/2:4.* create
exit
sap 1/1/3:4.* create
exit
no shutdown
exit
exit all
Multicast Service Verification
Configure the multicast server to send one or more multicast streams. Have the BTV client connected to CE-2 send an IGMP join message for this multicast stream.
On the BSA routers (PE-1/PE-2), IGMP snooping can be checked:
A:PE-1# show service id 4 mfib
===============================================================================
Multicast FIB, Service 4
===============================================================================
Source Address Group Address Sap/Sdp Id Svc Id Fwd/Blk
-------------------------------------------------------------------------------
* * sdp:12:4 Local Fwd
sdp:13:4 Local Fwd
* 225.1.1.1 sap:1/1/1:4.* Local Fwd
sdp:12:4 Local Fwd
sdp:13:4 Local Fwd
-------------------------------------------------------------------------------
Number of entries: 2
===============================================================================
On PE-3/PE-4 the IGMP groups can be checked:
A:PE-3# show router igmp group
===============================================================================
IGMP Groups
===============================================================================
(*,225.1.1.1) Up Time : 0d 00:01:03
Fwd List : btv-dst
-------------------------------------------------------------------------------
(*,G)/(S,G) Entries : 1
===============================================================================
Following command shows that the MCS peers are synchronized and that there is one IGMP entry on both peers:
A:PE-1# show redundancy multi-chassis sync peer 192.0.2.2 detail
===============================================================================
Multi-chassis Peer Table
===============================================================================
Peer
-------------------------------------------------------------------------------
Peer IP Address : 192.0.2.2
Description : (Not Specified)
Authentication : Disabled
Source IP Address : 192.0.2.1
Admin State : Enabled
-------------------------------------------------------------------------------
Sync-status
-------------------------------------------------------------------------------
Client Applications : IGMPSnooping SUBMGMT RING
Sync Admin State : Up
Sync Oper State : Up
DB Sync State : inSync
Num Entries : 12
Lcl Deleted Entries : 0
Alarm Entries : 0
Rem Num Entries : 12
Rem Lcl Deleted Entries : 0
Rem Alarm Entries : 0
===============================================================================
MCS Application Stats
===============================================================================
Application : igmp
Num Entries : 1
Lcl Deleted Entries : 0
Alarm Entries : 0
-------------------------------------------------------------------------------
Rem Num Entries : 1
Rem Lcl Deleted Entries : 0
Rem Alarm Entries : 0
Notice that the MFIB on PE-2 has also been updated:
A:PE-2# show service id 4 mfib
===============================================================================
Multicast FIB, Service 4
===============================================================================
Source Address Group Address Sap/Sdp Id Svc Id Fwd/Blk
-------------------------------------------------------------------------------
* * sdp:21:4 Local Fwd
sdp:24:4 Local Fwd
* 225.1.1.1 sap:1/1/2:4.* Local Fwd
sdp:21:4 Local Fwd
sdp:24:4 Local Fwd
-------------------------------------------------------------------------------
Number of entries: 2
===============================================================================
A:PE-2#
The SAP on PE-2 is down to avoid duplicated traffic and loops:
A:PE-2# show service id 4 sap 1/1/2:4.*
===============================================================================
Service Access Points(SAP)
===============================================================================
Service Id : 4
SAP : 1/1/2:4.* Encap : qinq
QinQ Dot1p : Default
Description : (Not Specified)
Admin State : Up Oper State : Down
Flags : StandByForMcRing
Multi Svc Site : None
Last Status Change : 11/06/2009 18:56:25
Last Mgmt Change : 11/04/2009 23:43:16
===============================================================================
If a failure occurs in the ring-node, the IB-RCC BFD session between PE-1 and PE-2 will go down and the SAP on both PE-1 and PE-2 will be put in operational up state.
Configuration Notes
RNCV (used for ring-node connectivity check) and BFD (used for ring control connection) can either run on the same VLAN in the same IES or VPRN service or can run on different VLAN.
MCS for IGMP or DHCP states on a MC-ring requires ESM since the BSA nodes must know which ring node a subscriber is connected to in case a ring failure occurs. The ring-node name is returned through a Python script, a RADIUS server or through a local user database. This string (int_dest_id) must match one of the ring nodes defined in the redundancy configuration.
Convergence time after a ring failure should be 3 * BFD timer + MCS convergence time. Convergence time after a BSA failure should be likewise.
Note that a debounce timer runs on the MC-ring peers. After a ring failure, the MC-ring converges immediately (after the BFD session times out) and the debounce timer is started. After the ring is fixed and the BFD session is up the MC-ring converges immediately again. If another ring failure occurs before the debounce timer expires, convergence will be slowed down by two (2) seconds. If a third ring failure occurs before the debounce timer expires, four second delays are introduced. In case of a fourth failure, an eight second delay is introduced. 200 seconds of delay is the maximum. The debounce timer can be configured under the MC-ring.
Conclusion
This chapter covers an extension of dual homing support in TPSDA networks based on Layer 2 CO model. The extension addresses networks where multiple access nodes (for example, DSLAMs) are connected in a single ring. The examples show the use of a ring with four access nodes in a ring. The behavior is described in normal operation and in case a failure occurs in the access ring.