You are on page 1of 32

T E C H N O L O G Y

I N F O R M A T I O N

G U I D E

Subscriber Redundancy for Routed-Central Office


DeLiveRiNg NeT WORk SeRviCe ReDuNDANCy TO The SubSCRibeR uSiNg AN eNhANCeD SubSCRibeR mANAgemeNT ROuTeD -CO eNviRONmeNT

Abstract
Alcatel-Lucents Triple Play Service Delivery Architecture (TPSDA) delivers voice, video and data services to residential customers. This technical information guide focuses on one part of the TPSDA, the delivery of redundant network services in an enhanced subscriber management (ESM) routed-co environment. This environment applies to the delivery of high-speed Internet (HSI), voice-over-IP (VoIP) and video-on-demand (VoD). The goal of subscriber redundancy in an ESM routed-co environment is to minimize outages due to failure. This technical information guide provides an overview of the features required for network redundancy to function; it discusses the details of the configuration, and the operational aspects involved.

Table of Contents
1 1 2 3 4 5 5 5 7 8 9 24 1. Introduction 2. Overview 3. Subscriber Router Redundancy Protocol 3.1 Redundant default gateway 3.2 Monitoring the in-band communications path 3.3 Synchronizing the SRRP peer states 4. Multi-chassis synchronization 4.1 Subscriber management synchronization 4.2 Subscriber router redundancy protocol synchronization 5. Redundant interface 6. Configuration and operational aspects 7. Conclusion

1. Introduction
Redundancy is provided at the system level and at the network level. System redundancy is based on the high availability features of the Alcatel-Lucent 7750/7710 Service Routers (SRs), such as component redundancy (power, fans and control processor modules) and software redundancy (service and protocol redundancy, and non-stop-routing). Network redundancy involves each multi-service access node (MSAN) being dual-homed to two 7750/7710 SRs (either directly or using Layer 2 aggregation), with the subscriber management performed on an Internet Protocol (IP) interface on the 7750/7710 SRs. The 7750/7710 SRs operate in a master-slave relationship providing both link and system redundancy for the subscribers on the MSAN when accessing the services configured. The focus of this technical information guide is network redundancy.

2. Overview
Network redundancy for subscriber access in an enhanced subscriber management (ESM) routedco environment requires that each MSAN is dual-homed to two 7750/7710 SRs in a point-to-point fashion. The MSANs can have direct physical connectivity or there can be Layer 2 aggregation between the MSANs and the 7750/7710 SRs; the MSANs themselves must not be connected in a logical ring. Note that an alternative delivery mechanism within Triple Play Service Delivery Architecture (TPSDA) is the bridged-co environment where the ESM is performed on a 7750 SR/7450 ESS/7710 SR at Layer 2. It is not discussed further in this technical information guide, but it requires the same system redundancy and some of the network redundancy features presented, specifically, multichassis synchronization (MCS) is used but a Multi-chassis Link Aggregation Group (MC-LAG) replaces the Subscriber Router Redundancy Protocol (SRRP) and the redundant interface. On the 7750/7710 SRs, network redundancy is implemented in three parts: 1. Providing redundant access from the MSANs to the two 7750/7710 SRs (this is provided by the SRRP). 2. Mirroring the subscriber state between the two 7750/7710 SRs (this is achieved using the MCS Protocol). 3. Configuring a backup traffic path between the two 7750/7710 SRs (this path is a spoke-service distribution path [SDP] between the two peers). The three aspects of implementing network redundancy are illustrated in Figure 1. The SRRP protocol operates on a specific service access point (SAP) within the group-interface under the subscriber-interface command of an Internet enhanced service (IES)/virtual private routed network (VPRN). Through an operation similar to the Virtual Router Redundancy Protocol (VRRP), it provides a set of default gateways to the subscribers on the MSAN; these being active on the 7750/7710 SR in the master state and standby on the 7750/7710 SR in the backup state. Traffic is forwarded upstream and downstream through the master; if the backup loses connectivity to the master (that is, it fails to receive SRRP messages from the master) it transitions to the master state, takes ownership of the default gateways and assumes responsibility for forwarding traffic to/from the subscriber. This provides redundancy from the MSAN toward the provider network.

Subscriber Redundancy for Routed-Central Office | Technology information guide

Figure 1. Network redundancy for ESM routed-co


7750/7710

IES/VPRN

grp-int

sub-int

SRRP

Active/ Master

MCS

Red-int SRRP MSAN Red-int IES/VPRN MCS Provider Network

grp-int

Standby/ Backup

7750/7710

If an SRRP failover occurs, it is important that the subscriber state (IP/media access control [MAC] addresses, quality of service [QoS] profiles) be immediately available on the new SRRP master 7750/7710 SR; otherwise subscriber traffic is dropped due to anti-spoofing security. The subscriber state is synchronized using the MCS protocol, which mirrors the subscriber state between the two peers. This allows both peers to know the details of the active subscribers and forward traffic on their behalf with the correct QoS actions, both to and from the MSAN, if that peer is the SRRP master. The final aspect of this scenario relates to forwarding from the provider network to the subscribers. If natural IP routing causes traffic to be forwarded using the SRRP master, it is automatically forwarded to the subscriber. However, if the provider routing scheme causes traffic destined to a subscriber to arrive at the 7750/7710 SR in the SRRP backup state for that subscriber, it is dropped because the backup does not forward traffic out of the subscriber SAPs. To avoid this, a redundant interface is configured between the two 7750/7710 SRs under the subscriber/group-interfaces command. Any traffic arriving on the 7750/7710 SR for an active subscriber, where its associated SRRP instance is in the backup state, is forwarded using the redundant interface to the SRRP master, which in turn forwards it to the subscriber. In addition to successfully forwarding the traffic, this operation also maintains the subscriber QoS compliance as all traffic for a given subscriber enters and exits the routed-co interface by a single SAP, allowing the associated input/output module (IOM) hardware to perform the correct QoS actions.

3. Subscriber router redundancy protocol


The SRRP provides redundant access from the MSAN to the 7750/7710 SRs and is based on the VRRP (RFC3768). The function of SRRP is similar to VRRP in that it presents subscribers on the MSAN with a set of logical default gateways (IP and MAC addresses), which are accessible through one of the 7750/7710 SRs. The protocol works in a master/slave relationship with one of the 7750/7710 SRs being master and the other being slave (based on a configured priority). As of TIMOS Release 5.0, SRRP is only supported on the 7750 SR-12, the 7750 SR-7 and the 7710 SR.

Subscriber Redundancy for Routed-Central Office | Technology information guide

sub-int

SRRP

The SRRP involves three functions: 1. Providing the redundant default gateway for subscriber access. 2. Monitoring the in-band communications path between the subscribers and the two 7750/7710 SRs, thereby ensuring at least one of the 7750/7710 SRs is in the master state and forwarding traffic to/from subscribers. 3. Synchronizing the states of the two SRRP peers. In SRRP, these functions are configured and work separately; that is, the redundant default gateway is in a separate SAP than the monitoring protocol, and the synchronization is provided by MCS. 3.1 Redundant default gateway The redundant default gateway IP addresses must be configured under the subscriber-interface command (within the IES/VPRN service) for each subnet defined; Figure 2 shows an example.

Figure 2. Subscriber interface command

subscriber-interface sub-int create address 10.0.255.253/16 gw-ip-address 10.0.255.254 address 10.1.0.253/24 gw-ip-address 10.1.0.254 address 20.0.0.1/24 gw-ip-address 20.0.0.2

Note that the gateway IP address could be a virtual (unused) address in this subnet or the address of one of the actual subscriber interfaces on the two 7750/7710 SRs. It must not be assigned as a subscriber address. If Dynamic Host Configuration Protocol (DHCP) is used, the associated subscriber interface address should be used for the gi-address configured for DHCP under the group-interface command. This ensures that if the offer returned from the DHCP server arrives at the SRRP backup (rather than the master) it will be forwarded by the SRRP backup to the master using the redundant interface. In order for the redundant gateway information to be used by subscribers through SAPs belonging to a particular group interface, an SRRP instance must be added under the group-interface command; see Figure 3.
Figure 3. Group-interface command At this point, any subscriber using Address Resolution Protocol (ARP) for the gateway IP address will get a group-interface dslam-01 create response from the SRRP master with srrp 10 create keep-alive-interval 1 a source MAC of 00-00-5E-01-<-xx>, message-path 1/2/4:10 where <xx> is the first byte of the priority 200 SRRP identifier in hexadecimal, in no shutdown this case 00-00-5E-00-01-0A. Note exit that SRRP 266, for example, would use the same source MAC address. The redundant default gateway MAC address could be explicitly configured, if desired, using the gw-mac parameter (not shown here). There can only be one SRRP instance per group interface and all SRRP identifiers must be unique.

Subscriber Redundancy for Routed-Central Office | Technology information guide

When an SRRP instance is enabled, or when there is an SRRP failover from one device to another, gratuitous ARPs are sent on all virtual local area networks (VLANs) associated with this instance for all gateway IP addresses (on all subscriber SAPs and on the SRRP message path SAP in the associated group interface). This allows all downstream devices to relearn the path to the new master. The gateway IP addresses are accessible by active subscribers; regardless of which peer is the master, an active subscriber can ping or telnet to its associated gateway IP address (filters can be configured to control this). 3.2 Monitoring the in-band communications path In order to monitor the in-band communications path between the subscribers and two 7750/7710 SRs, SRRP uses a slightly modified VRRP advertisement message. The SRRP message destination IP address (224.0.0.18) and IP protocol number (112) are the same as for VRRP but there are changes in the following areas: The source IP address of the message is the system IP address, as opposed to the interface IP address. The protocol version has been set to 8 (the current version of VRRP is 2). The virtual router identifier has been extended from one byte (maximum 255) to four bytes (maximum 4294967295, though a maximum of 232 can be defined). The source MAC address is included instead of the virtual router IP address (this being 00-00-5E-00-01-<xx>, where <xx> is the first byte of the SRRP identifier in hexadecimal). These messages are normally forwarded by the MSAN, thereby verifying the connectivity from one 7750/7710 SR through the MSAN to the other 7750/7710 SR. In order to achieve this, a nonsubscriber SAP must be configured under the group-interface command, which is referenced in the SRRP configuration by the message-path parameter. This not only selects the SAP to be used for the SRRP messages, but also keeps the subscriber anti-spoofing from automatically dropping the received messages (as there would be no subscriber IP/MAC entry corresponding to the received information) causing both peers to become master. The message path SAP configuration effectively disables IP/MAC anti-spoofing on that SAP. Note that the SRRP messages are not sent within the same SAP as the subscriber data traffic; it is assumed that the path traversed by the SRRP messages is the same as that used for the subscriber data, if this is not the case then the SRRP state would not necessarily reflect a failure in the data path. The master of the SRRP instance generates advertisement messages at a keep-alive interval (which is encoded in the message) ranging from 1 to 100, in multiples of 100 ms, with a default of 10 (1 second). When using sub-second timers, the maximum number of SRRP (plus VRRP) messages supported per second is 200 and consequently, with the minimum keep-alive interval of 100 ms, a maximum of 20 SRRP (plus VRRP) instances can be supported. The SRRP backup monitors the reception of these messages and if three consecutive messages are not received, it assumes the role of the master. The keep-alive interval of the master is always used. Only two devices can participate in an SRRP protocol exchange for a given SRRP instance (this being another difference from VRRP, which allows more potential backup devices). This is a consequence of the direct relationship among the SRRP instance, the associated redundant interface and MCS peering.

Subscriber Redundancy for Routed-Central Office | Technology information guide

The protocol exchange is also used for the master/backup election, based on the priority (1 to 254) configured in the SRRP instance. The device with the highest priority becomes the master, with the message source IP address (system IP address) being used as a tie breaker when the priorities are the same (the lower IP address becomes the master). The master/backup status is per SRRP instance (not per IP address), that is, the master is the active gateway for all gateway IP addresses under the subscriber interface for the associated group interface (this is true even if the backup is the IP address owner for one of the gateway IP addresses). Priority 0 is sent by the master when it is transitioning to the backup role due to the appearance of a high priority peer. Higher priority backups always pre-empt a lower priority master. The SRRP messages are sent by default with differentiated service code point (DSCP) of nc1 and with 802.1p bits of 0. A basic form of load distribution can be achieved by having the master SRRP for some group interfaces on one peer and the master for other group interfaces on the other peer. A failure may cause all masters to be active on a single peer, which must be taken into account when designing the network. A VRRP policy statement can be added to the SRRP instance definition in order to dynamically adjust the SRRP priority based on the occurrence of certain non-SRRP related events, for example, a port down event or the change in status of a particular IP route. 3.3 Synchronizing the SRRP peer states In order to troubleshoot an SRRP environment, the states of all peers are synchronized through MCS. For more information, see section 4.2.

4. Multi-chassis synchronization
MCS is a proprietary protocol used to synchronize information between two 7750 SR/7450 ESS/7710 SR peers. Of relevance to this technical information guide, it is used for: Subscriber management Subscriber Router Redundancy Protocol The MCS protocol provides the mechanism for mirroring application information; it uses a Transmission Control Protocol (TCP) connection (port 45067) between the two peers and can use Message Digest 5 (MD5) authentication. The messages use a DSCP of nc1. Each 7750/7710 SR supports the configuration of up to 4 peers, with information only being synchronized between pairs of peers. 4.1 Subscriber management synchronization MCS is used to synchronize the subscriber state in a TPSDA environment, when used with either bridge-co or routed-co. In bridged-co, the ESM is performed at Layer 2 with redundancy from a dual-homed MSAN provided by an MC-LAG. For routed-co (the focus of this technical information guide) the subscriber state information in ESM is derived from the DHCP exchange between a subscriber device and the DHCP server (can be in conjunction with a Remote Access Dial-In User Server [RADIUS]). The state includes information about the connectivity to the device and its QoS provisioning. The main components are the subscriber identifier, IP and MAC addresses and the sub-profile/service level agreement (SLA) profile. To ensure that the QoS defined for a subscriber is adhered to, all traffic for a given subscriber needs to be forward using a single port. When an MSAN is dual-homed to two 7750/7710 SRs, this is achieved using the SRRP protocol and the redundant interface. Specifically, the traffic is forwarded through the SRRP master of the related group interface.

Subscriber Redundancy for Routed-Central Office | Technology information guide

It is critical that an outage caused by a failover of the SRRP master from one 7750/7710 SR to the other is minimal. To achieve this, any subscriber state created on the master SRRP 7750/7710 SR needs to be mirrored to the backup SRRP peer so that it is available immediately if a failover occurs. Note that DHCP packets received on the backup SRRP group interface are dropped; they are not processed as it is assumed that they are processed on the master SRRP and the state is mirrored to the SRRP backup by MCS subscriber management. Static hosts are not mirrored. To link information being mirrored between two 7750/7710 SRs, a sync tag is configured to correspond to either an entire port/LAG or under a port/LAG for a VLAN range. This allows each 7750/7710 SR to know exactly which information should be in sync on each device. The sync tag must be unique on the two peers involved. Figure 4 shows an example.
Figure 4. Example sync tag

redundancy multi-chassis peer 1.1.1.2 create sync sub-mgmt port 1/2/4 create range 11-11 sync-tag dslam-01 range 12-12 sync-tag dslam-02 range 13-13 sync-tag dslam-03 exit no shutdown exit no shutdown exit exit exit

Alternatively, if the information needs to be synchronized on port 1/2/4 for all VLANs, then the port command shown in Figure 5 can be used instead of the port plus ranges shown in Figure 4.

Figure 5. Port command

srrp sub-mgmt port 1/2/4 sync-tag port124 create exit

Note that the VLANs used within the group-interfaces must match between the two peers; the physical ports identifiers may differ. It is essential for the MCS synchronization of subscriber information (specifically DHCP information) to function correctly and that the two peers are also in time synchronization (normally by Network Time Protocol [NTP]). If the two peers are not in time synchronization, a subscribers information can be removed (on lease-time expiry) from the backup while still existing on the master. This asymmetry would eliminate the subscriber redundancy if a failover were to occur. In environments where there are many subscribers, it takes time to synchronize the subscriber state between the peers when the subscriber interface is enabled (such as, after a reboot). In order to ensure that the state has time to be synchronized, a delayed-enable timer can be specified under the subscriber-interface command. The init-only parameter (optional) can be added to use this timer only after a reboot.

Subscriber Redundancy for Routed-Central Office | Technology information guide

4.2 Subscriber router redundancy protocol synchronization MCS is used to synchronize the application state between two peers. SRRP can function without synchronizing its state, but synchronization allows the current state of both the local and the remote peers to be displayed and appropriate error messages to be reported when the peer state is not correct. Figure 6 is an example configuration that shows only the SRRP aspects. Three SRRP instances have been configured for MCS peer 1.1.1.2 using VLANs 10, 266 and 400 on port 1/2/4. Here, a separate sync tag is associated with each SRRP instance.

Figure 6. Configuration example SRRP aspects

redundancy multi-chassis peer 1.1.1.2 create sync srrp port 1/2/4 create range 10-10 sync-tag srrp10 range 266-266 sync-tag srrp266 range 400-400 sync-tag srrp400 exit no shutdown exit no shutdown exit exit exit

Figure 7 shows an example of the error messages available when synchronization is applied; without synchronization, these messages would not be available.
Figure 7. Error messages

1 2007/10/08 05:52:30.88 PDT WARNING: MC _ REDUNDANCY #2012 Base SRRP/MCS: Peer Re d i/f no addr SRRP ID 10: Redundant interface srrp-ies500-SR7-1 on peer 1.1.1.2 / interface d slam-01 does not match local 1.1.1.1 / interface dslam-01. 2 2007/10/08 05:52:30.88 PDT WARNING: MC _ REDUNDANCY #2012 Base SRRP/MCS: Peer Re d i/f down SRRP ID 10: Redundant interface srrp-ies500-SR7-1 on peer 1.1.1.2 / interface d slam-01 does not match local 1.1.1.1 / interface dslam-01.

To generate the messages shown in Figure 7, the IP address was removed from the redundant interface on the remote peer.

Subscriber Redundancy for Routed-Central Office | Technology information guide

5. Redundant interface
The requirement for the redundant interface comes from a situation where traffic destined to a subscriber arrives on the 7750/7710 SR but the associated SRRP state is not master. When the SRRP state is backup for a particular group interface, subscriber traffic is not normally forwarded in/out of the associated subscriber SAPs. Also, traffic could arrive but the specific group interface for that subscriber could be down. These situations can occur due to the natural routing within the provider network, or temporarily during an SRRP failover. Note that as the subscriber subnets are configured under the subscriber-interface command, it is not possible to stop advertising these subnets into the provider core when only a subset of the group interfaces are down or the associated SRRP instances are in the backup state. The advertisement of the subscriber subnet could therefore attract traffic to the 7750/7710 SR that is not the SRRP master. In these cases, traffic must be sent to the SRRP active 7750/7710 SR in order to be forwarded to the subscriber. This is achieved by the configuration of a redundant interface between two SRRP peers, which protects against failures of the related group interfaces. The redundant interface is configured under the IES/VRPN service. It must use a single pseudowire, configured as a spoke-SDP, to provide connectivity to the peer 7750/7710 SR. This is essential as it avoids any possibility of the traffic being misrouted by any other system between the two peers. It can use either a /31 IP subnet mask or a longer mask with the remote IP being explicitly specified. Figure 8 shows the commands required to configure a redundant interface.

Figure 8. Redundant interface configuration

redundant-interface srrp-ies500-SR7-2 create description srrp redundant interface to SR7-2 for ies 500 address 192.168.1.0/31 spoke-sdp 1:100 create exit exit

Each group interface must then be associated with the redundant interface. Figure 9 shows the configuration of the redundant interface under a group interface. Only one redundant interface is required for a given IES/VPRN service on each peer, though it is possible to create multiple redundant interfaces and assign group interfaces to each individually. Each redundant interface needs to terminate on a matching redundant interface in the corresponding peer service.
Figure 9. Redundant interface configuration under a group interface

group-interface dslam-01 create redundant-interface srrp-ies500-SR7-2

Subscriber Redundancy for Routed-Central Office | Technology information guide

When traffic arrives for an active subscriber on a SAP in group interface dslam-01, if the associated SRRP instance is in the backup state, this traffic is forwarded over the redundant interface srrp-ies500-SR7-2 to the peer 7750/7710 SR. It is then forwarded to the subscriber as the associated SRRP instance will be in the master state. The information about the redundant-interfaces is mirrored by MCS as part of the SRRP synchronization. To preserve the service as much as possible in the case of a redundant interface failure, traffic can be forwarded out of the subscriber even when the SRRP state is backup. At this point, the group interface MAC address is used as the traffic source MAC address (when in SRRP master state, the source MAC address is 00-00-5E-01-<-xx>), and the QoS enforcement for the subscriber is reduced as it could then receive traffic by both of the dual-homed 7750/7710 SRs.

6. Configuration and operational aspects


This section covers the operational aspects of the subscriber redundancy for routed-co. It brings together the configurations of the individual components shown earlier and presents various show output and debugging information. Note that although the console/syslog messages are not shown, they should be monitored at all times as they are very important for understanding the operational state. It should also be noted that this document focuses on the configuration of routed-co, SRRP and MCS from a 7750/7710 SR perspective, that is, the command line interface (CLI). However, most service providers require more comprehensive management tools. The Alcatel-Lucent 5620 Service Aware Manager (SAM) converges element, network and service management into an integrated and service-oriented solution that manages network devices as a single virtual node. The 5620 SAM can provision and manage all aspects of routed-co, SRRP and MCS, and is therefore the ideal management tool in a provider environment. A routed-co service is created between two 7750 SRs (SR-7s) with three MSANs (dslam-01, dslam-02 and dslam-03) connected to a single port on each 7750 SR. The aim of the configuration is to have each MSAN using a specific VLAN on that port, together with its own IP subnet and associated gateway IP address. There are three steps for MCS configuration: 1. Create a peer to 1.1.1.2 under the redundancy multi-chassis command, which uses MD5 authentication. 2. Enable MCS using the sync parameter; for synchronization, enable the srrp and sub-mgmt applications. 3. Define the sync tags at the VLAN level under port 1/2/4, which is used to connect to the MSANs. There are three MSANs to address dslam-01, dslam-02 and dslam-03 on VLANs 11, 12 and 13 respectively; there are an additional three for the SRRP instances 10, 266 and 400 on VLANs 10, 266 and 400, respectively. A single sync tag can be used at the port level, or ranges of VLANs can be entered under the port. The choice of approach depends on the network involved, although this configuration allows the most flexibility in terms of adding and removing sync tags, as each individual sync tag can be removed without touching any others.

Subscriber Redundancy for Routed-Central Office | Technology information guide

Figure 10 shows an example of the MCS configuration.


Figure 10. MCS configuration

redundancy multi-chassis peer 1.1.1.2 create authentication-key JCb.NtkUapNrlyS.LM9f.X3pv3UO4c4F hash2 sync srrp sub-mgmt port 1/2/4 create range 10-10 sync-tag srrp10 range 11-11 sync-tag dslam-01 range 12-12 sync-tag dslam-02 range 13-13 sync-tag dslam-03 range 266-266 sync-tag srrp266 range 400-400 sync-tag srrp400 exit no shutdown exit no shutdown exit exit exit

There are eight steps for IES service configuration (for clarity, only the group interface for dslam-01 is included): 1. Connect the redundant interface srrp-ies500-SR7-2 to the peer 7750 SR using spoke-SDP 1:100 and reference it under group interface dslam-01 (and other group interfaces) 2. Configure three subnets under the subscriber-interface sub-int command, each with a gateway IP address (the first two being unused addresses and the third being owned by the peer 7750 SR). 3. Configure the group interface dslam-01 to connect dslam-01; configure two other group interfaces (not shown) for dslam-02 and dslam-03. 4. Configure the DHCP server under the group interface dslam-01 with the gi-address set to the subscriber interface address of the first subnet. The intention is that the DHCP service will respond with addresses in the subnet 10.0.0.0/16 for subscribers on this interface (this is configured in the DHCP server configuration file). 5. Establish RADIUS authentication; reference the authentication policy radius-auth under the group-interface command. 6. Establish SAP 1/2/4:11 as the subscriber SAP (the SAP on which subscribers access the routedco and where the ESM [specifically the DHCP processing] occurs). Traffic to/from the subscriber uses this SAP. The other group interfaces each have one subscriber SAP configured on this port on different VLANs. 7. Establish SAP 1/2/4:10 as the SAP used solely for the SRRP protocol exchange between the two peers for this group interface. By virtue of this being referenced by the message path in the SRRP instance definition, it does not have IP/MAC anti-spoofing enabled. Again, each group interface must have its own SAP configured for the SRRP protocol exchange. 8. Define the SRRP definition instance as SRRP 10 on the group interface. Configure a minimum keep-alive timer of 1, together with the message path giving the SAP to be used for the SRRP messages. The priority is set to 200 (default is 100) in order to force this peer to be the SRRP master when both peers are active. SRRP instances 400 and 266 are configured on group interfaces dslam-02 and dslam-03, respectively.
10 Subscriber Redundancy for Routed-Central Office | Technology information guide

Figure 11 shows the IES service configuration.


Figure 11. IES service configuration

ies 500 customer 1 create description routed-co interface redundant-interface srrp-ies500-SR7-2 create description srrp redundant interface to SR7-2 for ies 500 address 192.168.1.0/31 spoke-sdp 1:100 create exit exit subscriber-interface sub-int create address 10.0.255.253/16 gw-ip-address 10.0.255.254 address 10.1.0.253/24 gw-ip-address 10.1.0.254 address 20.0.0.1/24 gw-ip-address 20.0.0.2 group-interface dslam-01 create arp-populate dhcp server 193.168.2.2 trusted lease-populate 200 gi-address 10.0.255.253 no shutdown exit authentication-policy radius-auth redundant-interface srrp-ies500-SR7-2 sap 1/2/4:10 create exit sap 1/2/4:11 create sub-sla-mgmt def-sub-profile basic-sub def-sla-profile basic-sla sub-ident-policy sub-map multi-sub-sap 200 no shutdown exit exit srrp 10 create keep-alive-interval 1 message-path 1/2/4:10 priority 200 no shutdown exit exit

With the configuration shown in Figure 11, two subscribers are enabled to dslam-01 and dslam-02, as can be seen from their SAPs and the IP addresses assigned to each, respectively (see Figure 12).

Subscriber Redundancy for Routed-Central Office | Technology information guide

11

Figure 12. Active subscriber show output

A:SR7-1# show service active-subscribers ========================================================== Active Subscribers ========================================================== -------------------------------------------------------------Subscriber r1-sub1-default-data (basic-sub) --------------------------------------------------------------------------------------------------------------------------(1) SLA Profile Instance sap:1/2/4:11 - sla:basic-sla -------------------------------------------------------------IP Address MAC Address Origin(*) ------------------------------------------10.0.0.1 00:00:00:00:00:01 -/D/-------------------------------------------------------------Subscriber r1-sub9-default-data (basic-sub) --------------------------------------------------------------------------------------------------------------------------(1) SLA Profile Instance sap:1/2/4:12 - sla:basic-sla -------------------------------------------------------------IP Address MAC Address Origin(*) ------------------------------------------10.1.0.9 00:00:00:00:00:09 -/D/-------------------------------------------------------------Number of active subscribers : 2 ========================================================== (*) S=Static Host, D=DHCP Lease, N=Non-Sub-Traffic A:SR7-1#

The same command on the peer shows the same information except for the port identifier part of the SAP, which is specific to the peer and may differ. The high-level state of MCS can be seen using the show redundancy multi-chassis all command, as shown in Figure 13.

Figure 13. High-level state of MCS

A:SR7-1# show redundancy multi-chassis all =============================================================================== Multi-Chassis Peers =============================================================================== Peer IP Src IP Auth Peer Admin MCS Admin MCS Oper MCS State MC-LAG Admin MC-LAG Oper ------------------------------------------------------------------------------1.1.1.2 1.1.1.1 hash2 Enabled Enabled Enabled inSync Disabled Disabled =============================================================================== A:SR7-1#

This command shows information about the peering, the use of authentication, the state of MCS (Enabled) and the fact that MCS is inSync.

12

Subscriber Redundancy for Routed-Central Office | Technology information guide

To see the sync state specifically, use the show redundancy multi-chassis sync command as shown in Figure 14.
Figure 14. Synch state

A:SR7-1# show redundancy multi-chassis sync ============================================================================ Multi-chassis Peer Table ============================================================================ Peer --------------------------------------------------------------------------------Peer IP Address : 1.1.1.2 Authentication : Enabled Source IP Address : 1.1.1.1 Admin State : Enabled --------------------------------------------------------------------------------Sync-status --------------------------------------------------------------------------------Client Applications : SUBMGMT SRRP Sync Admin State : Up Sync Oper State : Up DB Sync State : inSync Num Entries : 20 Lcl Deleted Entries : 0 Alarm Entries : 0 Rem Num Entries : 20 Rem Lcl Deleted Entries : 0 Rem Alarm Entries : 0 ============================================================================ ============================================================================ A:SR7-1#

In this case, it shows that SUBMGMT and SRRP are the client applications and they are inSync with 20 database entries, both on this peer and the remote peer. If the show redundancy multi-chassis sync command included the detailed output for peer 1.1.1.2, the information shown in Figure 15 would be added.

Subscriber Redundancy for Routed-Central Office | Technology information guide

13

Figure 15. Sync state detailed output for peer 1.1.1.2

A:SR7-1# show redundancy multi-chassis sync peer 1.1.1.2 detail ========================================================================== 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 : 2 Lcl Deleted Entries : 0 Alarm Entries : 0 ------------------------------------------------------------------------------Rem Num Entries : 2 Rem Lcl Deleted Entries : 0 Rem Alarm Entries : 0 ------------------------------------------------------------------------------Application : srrp Num Entries : 18 Lcl Deleted Entries : 0 Alarm Entries : 0 ------------------------------------------------------------------------------Rem Num Entries : 18 Rem Lcl Deleted Entries : 0 Rem Alarm Entries : 0 ------------------------------------------------------------------------------========================================================================== ========================================================================== Ports synced on peer 1.1.1.2 ========================================================================== Port/Encap Tag ------------------------------------------------------------------------------1/2/4 10-10 srrp10 11-11 dslam-01 12-12 dslam-02 13-13 dslam-03 266-266 srrp266 400-400 srrp400 ========================================================================== ========================================================================== A:SR7-1#

14

Subscriber Redundancy for Routed-Central Office | Technology information guide

This shows that there are two database entries on both peers for subscriber management, (for the two active subscribers) and there are 18 entries on both peers for SRRP (six entries each for the three SRRP instances). The database entries can be viewed in more detail using the tools dump redundancy multi-chassis command, see Figure 20 (also shown are the port/VLANs synchronized with their respective sync tags). The SRRP instances can be viewed using the show srrp command, as shown in Figure 16.

Figure 16. SRRP instances

A:SR7-1# show srrp ============================================================================ SRRP Table ============================================================================ ID Service Group Interface Admin Oper --------------------------------------------------------------------------------10 500 dslam-01 Up master 400 500 dslam-02 Up master 266 500 dslam-03 Up backupShunt --------------------------------------------------------------------------------No. of SRRP Entries: 3 ============================================================================ A:SR7-1#

The three SRRP instances are shown with their related group interfaces and their operational state. As indicated in Figure 16, SRRP instances 10 and 400 are mastered on this peer, while SRRP instance 266 is backup and so mastered on the remote peer (this was achieved by setting the priority to 220 on the remote peer).

Subscriber Redundancy for Routed-Central Office | Technology information guide

15

Figure 17 shows SRRP 10 in detail.


Figure 17. SRRP 10 - detail

A:SR7-1# show srrp 10 detail ========================================================================== SRRP Instance 10 ========================================================================== Admin State : Up Oper State : master System IP : 1.1.1.1 Service ID : IES 500 Group If : dslam-01 MAC Address : 00:16:4d:b2:d9:c3 Grp If Admin State : Up Grp If Oper State : Up Subscriber If : sub-int Sub If Admin State : Up Sub If Oper State : Up Address : 10.0.255.253/16 Gateway IP : 10.0.255.254 Address : 10.1.0.253/24 Gateway IP : 10.1.0.254 Address : 20.0.0.1/24 Gateway IP : 20.0.0.2 Redundant If : srrp-ies500-SR7-2 Red If Admin State : Up Red If Oper State : Up Address : 192.168.1.0/31 Red Spoke-sdp : 1:100 Msg Path SAP : 1/2/4:10 Admin Gateway MAC : Oper Gateway MAC : 00:00:5e:00:01:0a Config Priority : 200 In-use Priority : 200 Master Priority : 200 Keep-alive Interval : 1 deci-seconds Master Since : 10/05/2007 00:01:10 VRRP Policy 1 : None VRRP Policy 2 : None ------------------------------------------------------------------------------Statistics ------------------------------------------------------------------------------Become Master : 1 Master Changes :1 Become Bkup Routing : 1 Become Bkup Shunt : 0 Become Non-Master : 0 Adv Sent : 112852 Adv Received :4 Pri 0 Pkts Sent : 0 Pri 0 Pkts Rcvd : 0 Preempt Events : 1 Preempted Events : 0 Mesg Intvl Discards : 0 Mesg Intvl Errors : 0 ========================================================================== A:SR7-1#

In this case the SRRP instance is up and the state is master. It is associated with group interface dslam-01 under subscriber-interface sub-int, which has the addresses and gateway IP addresses shown. The redundant interface srrp-ies500-SR7-2 is in use and is up. The message path is 1/2/4:10 and the source MAC address is 00:00:5e:00:01:0a (this is because the SRRP identifier is 10 [hex: 0a]). The configured and in-use priority is 200, as is the master priority (this peer is the master). If this output were shown on the SRRP backup, an extra line would appear after the keep-alive interval, for example:
Master Down Interval: 0.300 sec (Expires in 0.300 sec)

16

Subscriber Redundancy for Routed-Central Office | Technology information guide

This shows the interval during which the receipt of no SRRP messages would cause the master to be considered down; it indicates when the interval will expire and how much time within the interval remains (this is the second 0.300sec). The operational state (Oper state) reflects both the state of the SRRP instance and its action with respect to the redundant interface. Specifically, when the peer is SRRP master, the Oper state is always master traffic is sent directly to the subscriber over its associated SAP. If the peer is SRRP backup and the redundant interface is up then the Oper state will be backupShunt; if the redundant interface is down then the Oper state is backupRouting. In the backupShunt state, traffic to the subscriber is shunted (forwarded) across the redundant interface to the peer (to the master) in order to be forwarded to the subscriber. A useful command to see the traffic on the redundant interface (in this configuration) is monitor service id 500 sdp 1:100 rate interval 11 repeat 3. When in the backupRouting state, the SRRP instance is in backup but the redundant interface is down, so the traffic is forwarded directly to the subscriber using its associated SAP. If the delayed-enable parameter is configured under the subscriber-interface command, to allow time for the MCS to fully synchronize, its setting and current expiry time would appear as shown in Figure 18.

Figure 18. Subscriber interface detail

A:SR7-1# show service id 500 interface sub-int detail ============================================================================ Interface Table ============================================================================ --------------------------------------------------------------------------------Interface --------------------------------------------------------------------------------If Name : sub-int Admin State : Up Oper (v4/v6) : Down/- --------------------------------------------------------------------------------Details --------------------------------------------------------------------------------If Index :5 Virt. If Index : 5 Last Oper Chg : 10/10/2007 07:25:54 Global If Index : 124 Delay IfUp : 1200 init-only Time to IfUp : 559 If Type : IES Sub ============================================================================

Subscriber Redundancy for Routed-Central Office | Technology information guide

17

If there were a Layer 2 device between the MSANs and the two 7750 SRs, when in a steady state of sending traffic to/from the two active subscribers, its MAC table would appear as shown in Figure 19.
Figure 19. MAC table Layer 2 device between MSAN and 7750 SRs

A:ESS# show service fdb-mac =============================================================================== Service Forwarding Database =============================================================================== ServId MAC Source-Identifier Type/Age Last Change ------------------------------------------------------------------------------10 00:00:5e:00:01:0a sap:1/8/4:10 L/0 10/05/2007 10:46:11 11 00:00:00:00:00:01 sap:1/8/2:11 L/0 10/05/2007 11:23:59 11 00:00:5e:00:01:0a sap:1/8/4:11 L/0 10/05/2007 11:24:23 12 00:00:00:00:00:09 sap:1/8/2:12 L/0 10/05/2007 11:00:33 12 00:00:5e:00:01:90 sap:1/8/4:12 L/0 10/05/2007 11:17:06 266 00:00:5e:00:01:0a sap:1/8/4:266 L/0 10/05/2007 10:45:53 400 00:00:5e:00:01:90 sap:1/8/4:400 L/0 10/05/2007 10:46:00 ------------------------------------------------------------------------------No. of Entries: 7 =============================================================================== A:ESS#

The first entry shows the source MAC address of SRRP 10, which is learned from the SRRP messages received from the SRRP master for that instance. The next two entries relate to the subscriber traffic, to and from r1-sub1-default-data, with the subsequent two being the traffic to and from r1-sub9-default-data; note that the 7750/7710 SR source MAC address is that of the SRRP instance in each case. The last two entries are the source MAC address of SRRP instances 266 and 400, respectively, again due to receiving SRRP messages from the SRRP master. To further troubleshoot and debug this configuration, there are commands to both dump the sync and SRRP MCS information, and to dump the SRRP database. The command tools dump redundancy multi-chassis sync-database [application {sub-mgmt|srrp}] provides the same information as the equivalent show commands. However, the detailed version gives more information about the contents of the sync database (see Figure 20). In the case of subscriber management, the SAP ID, sync tag and IP addresses of the subscribers can be seen, together with the timestamp of the database entry. This should correspond to the subscribers being mirrored between the two peers.

18

Subscriber Redundancy for Routed-Central Office | Technology information guide

Figure 20. Synchronization database entries for subscriber management

A:SR7-1# tools dump redundancy multi-chassis sync-database application sub-mgmt detail If no entries are present for an application, no detail will be displayed. FLAGS LEGEND: ld - local delete; da - delete alarm Peer Ip 1.1.1.2 Application SUBMGMT Sap-id Client Key SyncTag DLen Flags timeStamp deleteReason code and description -------------------------------------------------------------------------------1/2/4:12 10.1.0.9 dslam-02 134 -- -- 10/08/2007 06:05:24 0x0 1/2/4:11 10.0.0.1 dslam-01 134 -- -- 10/08/2007 06:05:21 0x0 The following totals are for: peer ip ALL, port/lag ALL, sync-tag ALL, application SUBMGMT Valid Entries: 2 Locally Deleted Entries: 0 Locally Deleted Alarmed Entries: 0 A:SR7-1#

For the SRRP case, there are entries for the base configuration, group interface and subnet information for each of the SRRP instances. Figure 21 shows corresponding entries for the local and remote peer. Specifying the sync-tag srrp10 parameter shows only the information for SRRP instance 10.

Subscriber Redundancy for Routed-Central Office | Technology information guide

19

Figure 21. Synchronization database entries for SRRP

A:SR7-1# tools dump redundancy multi-chassis sync-database application srrp synctag srrp10 detail If no entries are present for an application, no detail will be displayed. FLAGS LEGEND: ld - local delete; da - delete alarm Peer Ip 1.1.1.2 Application SRRP Sap-id Client Key SyncTag DLen Flags timeStamp deleteReason code and description ------------------------------------------------------------------------------1/2/4:10 SMK _ BASE _ CONFIG / 1.1.1.1 srrp10 88 -- -- 10/08/2007 01:52:55 0x0 1/2/4:10 SMK _ BASE _ CONFIG / 1.1.1.2 srrp10 88 -- -- 10/08/2007 01:52:58 0x0 1/2/4:10 SMK _ GRP _ IF / 1.1.1.1 srrp10 296 -- -- 10/08/2007 04:50:22 0x0 1/2/4:10 SMK _ GRP _ IF / 1.1.1.2 srrp10 296 -- -- 10/08/2007 05:56:13 0x0 1/2/4:10 SMK _ SUBNET _ INFO / 1.1.1.1 vRtrId 1, ifIdx 5 srrp10 40 -- -- 10/08/2007 01:51:53 0x0 1/2/4:10 SMK _ SUBNET _ INFO / 1.1.1.2 vRtrId 1, ifIdx 5 srrp10 40 -- -- 10/08/2007 01:52:58 0x0 The following totals are for: peer ip ALL, port/lag ALL, sync-tag ALL, application SRRP Valid Entries: 6 Locally Deleted Entries: 0 Locally Deleted Alarmed Entries: 0 *A:SR7-1#

This same information can be seen in more useful detail by dumping the SRRP database. This output is for SRRP instance 10, and shows the detailed information for each peer. This should clearly reflect the configuration and current state of the SRRP instances. Again, there are two entries (one for the local peer and the other for the remote peer) for the BASE_CONFIG, GRP_IF and SUBNET_INFO entries.

20

Subscriber Redundancy for Routed-Central Office | Technology information guide

Figure 22 shows a Dump of synchronization database entries for SRRP.


Figure 22. Dump of synchronization database entries for SRRP

A:SR7-1# tools dump redundancy multi-chassis srrp-sync-database instance 10 Tag Key: sap = 1/2/4:10 Key Info: (Type/Owner) SMK _ BASE _ CONFIG / 1.1.1.1 Data Info: srrpId: 10 svcId: 500 svcType: IES system IP: 0x1010101 Group interface MAC: 00:16:4d:b2:d9:c3 Gateway MAC: 00:00:5e:00:01:0a Subscriber interface name: sub-int Tag Key: sap = 1/2/4:10 Key Info: (Type/Owner) SMK _ BASE _ CONFIG / 1.1.1.2 Data Info: srrpId: 10 svcId: 500 svcType: IES system IP: 0x1010102 Group interface MAC: Gateway MAC: 00:00:5e:00:01:0a Subscriber interface name: sub-int Tag Key: sap = 1/2/4:10 Key Info: (Type/Owner) SMK _ GRP _ IF / 1.1.1.1 Data Info: Group interface name: dslam-01 Group Interface Sap (Tag/Encap): srrp10/10 Group Interface Sap (Tag/Encap): dslam-01/11 Redundant interface name: srrp-ies500-SR7-2 Redundant Interface IP/Mask: IP: 0xc0a80100 Mask: 0xfffffffe AdminUp: Up, OperState: SRRP _ STATE _ MASTER, InUsePriority: 200, Red-If OK: Yes, MessageSap OK: Yes Tag Key: sap = 1/2/4:10 Key Info: (Type/Owner) SMK _ GRP _ IF / 1.1.1.2 Data Info: Group interface name: dslam-01 Group Interface Sap (Tag/Encap): srrp10/10 Group Interface Sap (Tag/Encap): dslam-01/11 Redundant interface name: srrp-ies500-SR7-1 Redundant Interface IP/Mask: IP: 0xc0a80101 Mask: 0xfffffffe AdminUp: Up, OperState: SRRP _ STATE _ BACKUP _ SHUNT, InUsePriority: 100, Red-If OK: Yes, MessageSap OK: Yes Tag Key: sap = 1/2/4:10 Key Info: (Type/Owner) SMK _ SUBNET _ INFO / 1.1.1.1 vRtrId 1, ifIdx 5 Data Info: Subscriber IP Addr: 10.0.255.253 Mask: 0xffff0000 Gateway: 10.0.255.254 Subscriber IP Addr: 10.1.0.253 Mask: 0xffffff00 Gateway: 10.1.0.254 Subscriber IP Addr: 20.0.0.1 Mask: 0xffffff00 Gateway: 20.0.0.2 Tag Key: sap = 1/2/4:10 Key Info: (Type/Owner) SMK _ SUBNET _ INFO / 1.1.1.2 vRtrId 1, ifIdx 5 Data Info: Subscriber IP Addr: 10.0.255.252 Mask: 0xffff0000 Gateway: 10.0.255.254 Subscriber IP Addr: 10.1.0.252 Mask: 0xffffff00 Gateway: 10.1.0.254 Subscriber IP Addr: 20.0.0.2 Mask: 0xffffff00 Gateway: 20.0.0.2 A:SR7-1#

Subscriber Redundancy for Routed-Central Office | Technology information guide

21

There are two debug commands to show the SRRP events and the SRRP packets: debug router srrp events debug router srrp packets Figure 23 shows that this peer is the SRRP master for instance 10 and is sending SRRP messages, it then receives an SRRP message with a higher priority (220) from its peer. This causes the event Become Pending-Backup Shunt where it prepares to transition to the backup state. To achieve this, it sends an SRRP message with priority 0. It continues to receive SRRP messages (with priority 220) from its peer then passes into the backup state with the event Become Backup Shunt.

Figure 23. SRRP packet debug output

31 2007/10/02 05:00:50.30 PDT MINOR: DEBUG #2001 Base SRRP SRRP: Sending Pkt Version (SRRP) Type Vr Id Priority Count Ip Addresses Advertise Interval Checksum Raw Pkt: 81 00 c8 00 00 00 00 0a 00 00 5e 00 01 0a 03 e8 00 03 53 ff 32 2007/10/02 05:00:50.94 PDT MINOR: DEBUG #2001 Base SRRP SRRP: Receiving Pkt Version (SRRP) Type Vr Id Priority Count Ip Addresses Advertise Interval Checksum Raw Pkt: 81 01 dc 00 00 00 00 0a 00 00 5e 00 01 0a 03 e8 00 03 3f fe 33 2007/10/02 05:00:50.94 PDT MINOR: DEBUG #2001 Base SRRP SRRP: Event Become Pending-Backup Shunt: vRtrId 1, ifIdx 6, vr _ id 10, Master Ip: 1.1.1.2 34 2007/10/02 05:00:50.94 PDT MINOR: DEBUG #2001 Base SRRP SRRP: Sending Pkt Version (SRRP) Type Vr Id Priority Count Ip Addresses Advertise Interval Checksum :8 : Advertisement (1) :10 :0 :3 :1000 centi-second :0x1c00
...contd on next page

:8 :Advertisement (1) :10 :200 :3 :1000 centi-second :0x53ff

:8 :Advertisement (1) :10 :220 :3 :1000 centi-second :0x3ffe

22

Subscriber Redundancy for Routed-Central Office | Technology information guide

Raw Pkt: 81 00 00 00 00 00 00 0a 00 00 5e 00 01 0a 03 e8 00 03 1c 00 35 2007/10/02 05:00:50.95 PDT MINOR: DEBUG #2001 Base SRRP SRRP: Receiving Pkt Version (SRRP) Type Vr Id Priority Count Ip Addresses Advertise Interval Checksum Raw Pkt: 81 00 dc 00 00 00 00 0a 00 00 5e 00 01 0a 03 e8 00 03 3f ff 36 2007/10/02 05:00:50.95 PDT MINOR: DEBUG #2001 Base SRRP SRRP: Event Become Backup Shunt: vRtrId 1, ifIdx 6, vr _ id 10, Master Ip: 1.1.1.2 :8 :Advertisement (1) :10 :220 :3 :1000 centi-second :0x3fff

Another useful debug command of note is used for DHCP: debug router ip dhcp. This command, with the detail-level medium parameter shows all DHCP packets in the base router (see Figure 24). It can be used to verify that DHCP packets are dropped on the group interface when its associated SRRP instance is in the backup state.

Figure 24. DHCP packet debug output

A:SR7-2# debug router ip dhcp detail-level medium A:SR7-2# 1 2007/10/05 09:20:01.79 PDT MINOR: DEBUG #2001 Base PIP PIP: DHCP instance 1 (Base), interface index 6, DROPPED DHCP Boot Request on Interface dslam-01 (1/1/2:11) Port 67 Problem: DHCP ignored on SRRP backup interface H/W Type: Ethernet(10Mb) H/W Address Length: 6 ciaddr: 0.0.0.0 yiaddr: 0.0.0.0 siaddr: 0.0.0.0 giaddr: 0.0.0.0 chaddr: 00:00:00:00:00:01 DHCP options: [53] Message type: Discover [55] Param request list: len = 4 1 Subnet mask 3 Router 58 Renew timeout 59 Rebind timeout [61] Client id: (hex) 01 00 00 00 00 00 01 [82] Relay agent information: len = 6 [1] Circuit-id: d1p1 [255] End

A:SR7-2#

Subscriber Redundancy for Routed-Central Office | Technology information guide

23

7. Conclusion
The aim of subscriber redundancy in an ESM routed-co environment is to minimize outages due to failure. This was tested using a traffic generator, the configuration described in this technical information guide, and some simple failover and recovery tests that simulate a subscriber sending and receiving Internet traffic. An SRRP keep-alive time of 1 and ISIS spf-wait 1 10 500 were used to minimize the outage. Traffic was sent bi-directionally at a rate of 3% of a 100 Mb link (2535 pps), with a packet size of 128 bytes. Table 1 shows the results of the outages when the port to the MSANs (port 1/2/4) on SR7-1 was shutdown and brought back up.

Table 1. Test results


TEST TRAFFIC DIRECTIoN FAILovER ouTAGE (MS) RECovERy

1 2 3

internet Subscriber internet Subscriber internet Subscriber

subscriber internet subscriber internet subscriber internet

0 244 0 255 0 259

0 242 0 250 0 259

The results listed in Table 1 show that no traffic is lost in the direction from the Internet to the subscriber. The loss from the subscriber to the Internet can be attributed to the SRRP protocol failover timer/mechanism. In conclusion, an ESM routed-co environment with MSANs dual-homed to 7750/7710 SRs (either directly or using a Layer 2 aggregation) and subscriber management performed on an IP interface on the 7750/7710 SR, successfully delivers reliable redundant network services. This enables service providers to deliver triple play services to their customers with minimal impact due to network infrastructure failures, thereby enhancing customer satisfaction.

24

Subscriber Redundancy for Routed-Central Office | Technology information guide

www.alcatel-lucent.com

Alcatel, Lucent, Alcatel-Lucent and the Alcatel-Lucent logo are trademarks of Alcatel-Lucent. All other trademarks are the property of their respective owners. The information presented is subject to change without notice. Alcatel-Lucent assumes no responsibility for inaccuracies contained herein. 2008 Alcatel-Lucent. All rights reserved. WLN2468071225 (04)

You might also like