For feedback and comments:
documentation.feedback@alcatel-lucent.com

Table of Contents Previous Next Index PDF

Subscriber Redundancy for Routed-CO
In This Chapter
This section provides information about Subscriber Redundancy for Routed-CO (SRRP).
Topics in this section include:
•
Applicability
•
Summary
•
Overview
•
Configuration
•
Conclusion
 
Applicability
These configuration notes are applicable for the 7750 SR-c12, SR-7/12 and 7710 series and was tested on SR-OS 7.0 R5. This is supported on 7450 ESS-7 or ESS-12 in mixed-mode since 8.0R1. The 7750 SR-c4 is supported from 8.0R4 and higher.
This note is related only to the use of IPv4.
Configuration and troubleshooting commands were taken from a 7750 SR-7.
Summary
This section focuses on the delivery of redundant services in an Enhanced Subscriber management (ESM) Routed-CO environment using IES (Internet Enhanced Service) or VPRN (Virtual Private Routed Network).
It is applicable to delivering high speed Internet (HSI), voice-over-IP (VoIP) and video-on-demand (VoD) to subscribers.
Redundancy is provided at two levels:
•
system redundancy
•
network redundancy
The system redundancy is based on the high availability features of the 7750/7710 SRs, such as component redundancy (power, fans, control processor modules etc.) and software redundancy (service and protocol redundancy and non-stop-routing), which are not discussed here.
The network redundancy for subscriber access in an ESM Routed-CO environment requires that each BSAN (Broadband Service Access Node) is dual-homed to two 7750/7710 SRs either in a point-to-point fashion with the BSANs having direct physical connectivity to the 7750/7710 SRs, or by having Layer 2 aggregation between the BSANs and the 7750/7710 SRs.
This connection will operate in a master-slave relationship providing both link and system redundancy for the subscribers on the BSAN when accessing the configured services.
Subscriber redundancy for Routed-CO aims to minimize the outage due to a failure.
This chapter provides configuration and troubleshooting commands for SRRP with static-host ip-mac.
Knowledge of the TPSDA (Triple Play Service Delivery Architecture) concepts is assumed throughout this document.
Overview
There are three components on the 7750/7710 SRs to implement network redundancy:
1.
Redundant access from the BSANs to the two 7750/7710 SRs provided by the SRRP.
2.
Mirroring of subscriber state between the two 7750/7710 SRs achieved through the Multi-Chassis Synchronization (MCS) protocol.
3.
Backup spoke SDP traffic path between the two 7750/7710 SRs peers.
These components are shown in Figure 411.
Figure 411: Network Redundancy Components for ESM Routed-CO
The following configuration tasks should be done first and are not explained in detail in these configuration notes:
•
Basic service router configuration (system interface, IGP, MPLS, BGP)
•
Routed CO service topology: VPRN or IES service with subscriber and group interface on BNGs (Broadband Network Gateway)
•
ESM configuration
•
Static host configuration
This chapter will focus on SRRP in a VPRN service subscriber-interface on BNG (Routed-CO). Note that in case of Routed-CO, it is also possible to configure SRRP in the base routing instance using an IES service.
 
The SRRP Protocol
The SRRP protocol operates on a specific SAP within the group interface under the subscriber-interface of an IES/VPRN service. Through a method similar to the VRRP (Virtual Router Redundancy Protocol), it provides a set of default gateways to the subscribers on the BSAN. These are active on the 7750 SR in a master state and inactive on the 7750 SR in the backup state. Traffic is forwarded upstream and downstream through the master. If the backup loses connectivity to the master (for example, fails to receive SRRP messages from the master), it transitions to the master state and takes over the ownership of the default gateways and the responsibility for forwarding traffic to/from the subscriber. This provides redundancy from the BSAN toward the provider network.
If an SRRP failover were to occur, it is important that the subscriber state (IP/MAC addresses, QOS profiles, etc.) be immediately available on the new SRRP master 7750 SR; otherwise, subscriber traffic will be dropped due to the anti-spoofing security. The subscriber state is synchronized through 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 therefore forward traffic on their behalf with the correct QOS actions both to and from the BSAN if that peer is the SRRP master.
The last scenario relates to the forwarding from the provider network to the subscribers. If the natural IP routing causes this traffic to forward through the SRRP master, then it will automatically be forwarded to the subscriber. However, if the provider routing scheme causes traffic destined to a subscriber to arrive at the 7750 SR in the SRRP backup state for that subscriber, it will be dropped as the backup does not forward traffic out of the subscriber SAPs.
To avoid this, a redundant interface is configured between the two 7750 SRs under the subscriber/group-interfaces. Any traffic arriving on the 7750 SR for an active subscriber, where its associated SRRP instance is in the backup state, will be forwarded through the redundant interface to the SRRP master, which in turn forwards it to the subscriber.
In addition to successful 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 through a single SAP, allowing the associated IOM hardware to perform the correct QOS actions.
Configuration
 
Subscriber Interface Configuration
 
Redundant Default Gateway
•
The redundant default gateway IP addresses must be configured under the subscriber-interface (within the IES/VPRN service) for each subnet defined.
•
Three subnets are configured under the subscriber-interface sub-int-1, each with a gw-ip-address which is uses as the default gateway by the subscribers in that subnet.
*A:BNG-2>configure
service
vprn 1 customer 1 create
- - - snip - - -
subscriber-interface "sub-int-1" create
address 10.2.0.2/16 gw-ip-address 10.2.0.254
address 10.3.0.2/16 gw-ip-address 10.3.0.254
address 10.4.0.2/16 gw-ip-address 10.4.0.254
•
Note that the gw-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 DHCP were to be used, the associated subscriber-interface address should be used for the gi-address configured for DHCP under the group-interface (will not be covered here as static host is used). This ensures that if the offer returned from the DHCP server arrives at the SRRP backup (rather than master) it will be forwarded by the SRRP backup to the master through the redundant interface.
In environments where there are many subscribers, it will take time to synchronize the subscriber state between the peers when the subscriber-interface is enabled (perhaps, 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. The optional init-only parameter can be added to use this timer only after a reboot.
*A:BNG-2>config>service>vprn>sub-if# delayed-enable
- delayed-enable <seconds> [init-only]
- no delayed-enable
 
<seconds> : [1..1200]
<init-only> : keyword
*A:BNG-2>config>service>vprn>sub-if# info
----------------------------------------------
---snip---
delayed-enable 1200 init-only
Group Interface Configuration
The group interface group-int-1 to connect BSAN is configured under the subscriber interface
*A:BNG-2>config>service>vprn# info
----------------------------------------------
---snip---
subscriber-interface "sub-int-1" create
address 10.2.0.2/16 gw-ip-address 10.2.0.254
address 10.3.0.2/16 gw-ip-address 10.3.0.254
address 10.4.0.2/16 gw-ip-address 10.4.0.254
group-interface "group-int-1" create
---snip---
 
Static Host Configuration
Enable the sub-sla-mgmt and sub-ident-policy sub-id-default under sap 1/1/3:1 and define static host (ip-mac) with sla-profile sla-profile-1, sub-profile sla-profile-1 and subscriber static-host-routed-10.2.0.3.
*A:BNG-2>configure service vprn 1 customer 1 create
---snip---
subscriber-interface "sub-int-1" create
---snip---
group-interface "group-int-1" create
---snip---
sap 1/1/3:1 create
sub-sla-mgmt
sub-ident-policy "sub-id-default"
no shutdown
exit
static-host ip 10.2.0.3 mac 00:00:00:00:00:01 create
sla-profile "sla-profile-1"
sub-profile "sub-profile-1"
subscriber "static-host-routed-10.2.0.3"
 
SRRP Configuration
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 in the group interface context.
*A:BNG-2>configure service vprn 1 customer 1 create
- - - snip - - -
group-interface "g1" create
- - - snip- - -
srrp 1 create
---snip---
At this point, any subscriber ARPing for the gw-ip-address will receive a response from the SRRP master with a source MAC of 00-00-5E-00-01-<xx>, where <xx> is the first byte of the SRRP identifier in hexadecimal, so in this case for SRRP=1 the source MAC will be 00-00-5E-00-01-01.
The redundant default gateway MAC address could be explicitly configured, if desired, by use of the gw-mac parameter.
*A:BNG-2>config>service>vprn>sub-if>grp-if>srrp# gw-mac
- gw-mac <mac-address>
- no gw-mac
 
<mac-address> : xx:xx:xx:xx:xx:xx or xx-xx-xx-xx-xx-xx
There can be only one SRRP instance per group-interface and all SRRP identifiers must be unique per system.
When an SRRP instance is enabled, or when there is an SRRP failover from one device to another, gratuitous ARPs are sent on all VLANs associated with this instance for all gw-ip-addresses (for example, 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 SRRP messages are normally forwarded through the BSAN, thereby verifying the connectivity from one 7750/7710 SR through the BSAN to the other 7750/7710 SR. In order to achieve this, a non-subscriber SAP must be configured under the group-interface 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 avoids the subscriber anti-spoofing from automatically dropping the received messages (as there would be no subscriber IP-to-MAC entry corresponding to the received information) and causing both peers to become master.
The message-path SAP configuration effectively disables IP-MAC anti-spoofing on that SAP.
*A:BNG-2>configure service vprn 1 customer 1 create
- - - snip - - -
group-interface "group-int-1" create
sap 1/1/3:2 create
exit
---snip---
srrp 1 create
message-path 1/1/3:2
---snip---
Note that the SRRP messages are then not sent within the same SAP as the subscriber data traffic, but it is assumed that the path traversed by the SRRP messages is same as would be 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 the keep-alive-interval (which is encoded in the message) ranging from one (1) to 100 in multiples of 100ms with a default of 10 (for example, 1 second). The SRRP backup will monitor the reception of these messages and assume the role of the master if three consecutive messages are not received.
The keep-alive-interval of the master is always used.
*A:BNG-2>config>service>vprn>sub-if>grp-if>srrp# keep-alive-interval
- keep-alive-interval <interval>
- no keep-alive-interval
 
<interval> : [1..100] tenths of a second
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 between the SRRP instance and the associated redundant interface and MCS peering.
This 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 will become master.
*A:BNG-2>config>service>vprn>sub-if>grp-if>srrp# info
----------------------------------------------
---snip---
priority 250
With the message source IP address (system IP address) being used as a tie break 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). For example, the master is the active gateway for all gw-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 gw-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 preempt a lower priority master.
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. Clearly, a failure may cause all masters to be active on a single peer, which must be taken into account when designing the network.
The minimum keepalive-timer of 1 is configured, together with the message-path giving the SAP to be used for the SRRP messages. The priority is set to 250 (default is 100) in order to force this peer to be the SRRP master when both peers are active.
srrp 1 create
keep-alive-interval 1
----snip---
 
SRRP Configuration Notes
•
A VRRP policy statement can be added to the SRRP instance definition in order to dynamically adjust the SRRP priority based on certain non-SRRP related events occurring (for example, port down, LAG degrade, host unreachable or route unknown).
•
The gw-ip-addresses are accessible by active subscribers, for example, regardless which peer is the master, an active subscriber can ping or telnet to its associated gw-ip-address (clearly, filters can be configured to control this).
 
BFD (Bi-directional Forwarding Detection)
BFD can be configured with SRRP to speed up the convergence.
srrp 1 create
---snip---
bfd-enable 2 interface "bfd-1" dst-ip 10.1.1.1
An IES service needs to be created for the BFD session.
*A:BNG-2# configure service ies 2
interface "bfd-1" create
address 10.1.1.0/31
bfd 100 receive 100 multiplier 3
sap 1/1/3:3 create
exit
exit
no shutdown
 
Monitoring 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 eight (8) (the current version of VRRP is two (2)).
•
The virtual router identifier has been extended from one byte (maximum 255) to four bytes (maximum 4294967295) though the maximum number of SRRPs that can be defined is 255.
•
The source MAC address is included instead of the virtual router IP addresses (this being 00-00-5E-00-01-<xx>, where <xx> is the first byte of the SRRP identifier in hexadecimal).
 
Synchronizing the SRRP Peer State
In order to troubleshoot an SRRP environment, the state of each peer is synchronized with the other peer through the Multi-Chassis Synchronization (MCS). MCS is a proprietary protocol used for synchronizing application state between two peers. SRRP will function without synchronizing its state but this synchronization allows for current state of both the local and remote peers to be displayed and appropriate error messages to be reported when the peer state is not correct. It also allows the master SRRP subscriber-interface to be pinged through the backup peer (through the redundant interface).
To link information being mirrored between two 7750/7710 SRs, a sync-tag value 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.
This example configuration shows only the SRRP aspects. SRRP instance has been configured for MCS peer 192.0.2.1 using VLANs 1-2 on port 1/1/3. Here, a sync-tag is associated with the SRRP instance. 
*A:BNG-2>config>redundancy>multi-chassis# info
----------------------------------------------
peer 192.0.2.1 create
authentication-key "441dO/0RgDg2CA0JlyzVNPuH6Fy2512w" hash2
sync
srrp
sub-mgmt
port 1/1/3 create
range 1-2 sync-tag "srrp1"
exit
no shutdown
Alternatively, if the information needs to be synchronized on port 1/1/3 for all VLANs, then the following port command could be used instead of the port-plus-ranges shown above.
srrp
sub-mgmt
port 1/1/3 sync-tag "srrp1" create
exit
Note: the VLANs used within the group interfaces must match between the two peers, clearly the physical ports identifiers may differ.
 
Multi-Chassis Synchronization
Multi-chassis synchronization (MCS) is a general propriety protocol used to synchronize information between two 7x50/7710 SR peers. It can be used for the following applications:
•
IGMP
•
IGMP Snooping
•
Subscriber Management
•
Subscriber Router Redundancy Protocol
IGMP and IGMP snooping are out of the scope of this document.
 
Subscriber Management Synchronization
In order to ensure that the QOS defined for a subscriber is adhered to, all traffic for a given subscriber needs to be forward by a single port. When an MSAN is dual-homed to two 7750/7710 SRs this is achieved using the SRRP protocol (described above) and the redundant interface (described below); specifically, the traffic is forwarded through the SRRP master of the related group-interface.
When a subscriber is created on the master SRRP, a host route (/32) for its IP address is inserted in the IP FIB pointing towards the appropriate group-interface.
The same subscriber on the backup peer will have a host route in the IP FIB pointing to the redundant interface. Note that on the backup peer this requires the subscriber subnet to also be present in the IP FIB, which in turn requires one of the following:
•
The local subscriber-interface is up.
•
The subscriber subnets are learned from active BNG (Broadband Network Gateway) through routing protocol.
•
Forcing the subscriber-interface to stay up by creating a dummy group interface with the oper-up-when-empty command.
 
*A:BNG-2>config>service>vprn# info
----------------------------------------------
---snip---
subscriber-interface "sub-int-1" create
--snip--
group-interface "group-int-1" create
---snip---
oper-up-while-empty
sap 1/1/3:1 create
exit
Redundant Interface
The requirement for the redundant interface comes from the 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 is down. These situations could 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, it is not possible to stop advertising these subnets into the provider core in the case where only a subset of the group interfaces are down or the associated SRRP instances are in backup. The advertisement of the subscriber subnet could therefore attract traffic to the 7750/7710 SR, which 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 through the configuration of a redundant interface between to 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 either use a /31 IP subnet mask or a longer mask with the remote IP being explicitly specified.
*A:BNG-2>config>service>vprn# info
----------------------------------------------
----snip----
redundant-interface "bng-2-bng-1-vprn-1" create
address 192.168.4.1/31
spoke-sdp 21:1 create
exit
exit
If non /31 address is used, the remote IP address will be required.
*A:BNG-2>config>service>vprn# redundant-interface "bng-2-bng-1-vprn-1"
*A:BNG-2>config>service>vprn>red-if# address 192.168.4.1/30
INFO: PIP #1399 Invalid or unspecified remote IP address - Non /31 address requires remote IP address
The remote-ip address can be defined by the following command:
*A:BNG-2>config>service>vprn>red-if# address 192.168.4.1/30 remote-ip 192.4.1.2
Each group-interface must then be associated with a redundant interface.
group-interface "group-int-1" create
---snip---
redundant-interface "bng-2-bng-1-vprn-1"
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. Clearly, each redundant interface needs to terminate on a matching redundant interface in the corresponding peer service.
When traffic arrives from the core network for an active subscriber on a SAP in group-interface group-int-1, and if the associated SRRP instance is in the backup state, then this traffic will be forwarded over the redundant-interface bng-2-bng-1-vprn-1 to the peer 7750/7710 SR. It will then be forward to the subscriber as the associated SRRP instance will be in the master state.
The information about the redundant interfaces is mirrored through MCS as part of the SRRP synchronization.
 
Show and Debug Commands
 
Routing Table Related Information
A host route (/32) for its IP address is inserted in the IP FIB pointing toward the appropriate group-interface.
*A:BNG-2# show router 1 route-table
===============================================================================
Route Table (Service: 1)
===============================================================================
Dest Prefix Type Proto Age Pref
Next Hop[Interface Name] Metric
-------------------------------------------------------------------------------
10.2.0.3/32 Remote Sub Mgmt 22h56m34s 0
[group-int-1] 0
---snip---
The same subscriber on the backup peer will have a host route in the IP FIB pointing to the redundant interface.
*B:BNG-1# show router 1 route-table
===============================================================================
Route Table (Service: 1)
===============================================================================
Dest Prefix Type Proto Age Pref
Next Hop[Interface Name] Metric
-------------------------------------------------------------------------------
0
10.2.0.3/32 Remote Sub Mgmt 22h51m06s 0
[bng-1-bng-2-vprn-1] 0
---snip---
 
Subscriber Related Information
To check the subscriber information: 
*A:BNG-2# show service id 1 subscriber-hosts
===============================================================================
Subscriber Host table
===============================================================================
Sap IP Address MAC Address PPPoE-SID Origin
Subscriber Fwding state
-------------------------------------------------------------------------------
1/1/3:1 10.2.0.3 00:00:00:00:00:01 N/A Static
static-host-routed-* Fwding
 
To check the subscriber details:
*A:BNG-2# show service id 1 subscriber-hosts detail
===============================================================================
Subscriber Host table
===============================================================================
Sap IP Address MAC Address PPPoE-SID Origin
Subscriber Fwding state
-------------------------------------------------------------------------------
1/1/3:1 10.2.0.3 00:00:00:00:00:01 N/A Static
static-host-routed-* Fwding
-------------------------------------------------------------------------------
Subscriber-interface : sub-int-1
Group-interface : group-int-1
Sub Profile : sub-profile-1
SLA Profile : sla-profile-1
App Profile : N/A
-------------------------------------------------------------------------------
The same command on the peer would show the same information except for the port identifier part of the SAP, which is specific to the peer and may differ.
 
MCS Redundancy Related Information
The high-level state of MCS can be seen in the following output:
*A:BNG-2# 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.1 192.0.2.2 hash2 Enabled unknown --
Enabled Enabled inSync Disabled Disabled
===============================================================================
*A:BNG-2#
 
Information about the peering, the use of authentication, the state of MCS (Enabled) and the fact that MCS is inSync is shown.
*A:BNG-2# show redundancy multi-chassis sync
===============================================================================
Multi-chassis Peer Table
===============================================================================
Peer
-------------------------------------------------------------------------------
Peer IP Address : 192.0.2.1
Description : (Not Specified)
Authentication : Enabled
Source IP Address : 192.0.2.2
Admin State : Enabled
-------------------------------------------------------------------------------
Sync-status
-------------------------------------------------------------------------------
Client Applications : SUBMGMT SRRP
Sync Admin State : Up
Sync Oper State : Up
DB Sync State : inSync
Num Entries : 6
Lcl Deleted Entries : 0
Alarm Entries : 0
Rem Num Entries : 6
Rem Lcl Deleted Entries : 0
Rem Alarm Entries : 0
===============================================================================
*A:BNG-2#
 
In the output, it can be seen that SUBMGMT and SRRP are the client applications and they are inSync with six database entries both on this peer and the remote peer.
If the above command included the detailed output for peer 192.0.2.1, the following additional information would be shown.
*A:BNG-2# show redundancy multi-chassis sync peer 192.0.2.1 detail
===============================================================================
Multi-chassis Peer Table
===============================================================================
Peer
-------------------------------------------------------------------------------
Peer IP Address : 192.0.2.1
Description : (Not Specified)
Authentication : Enabled
Source IP Address : 192.0.2.2
Admin State : Enabled
-------------------------------------------------------------------------------
Sync-status
-------------------------------------------------------------------------------
---snip---
Application : srrp
Num Entries : 6
Lcl Deleted Entries : 0
Alarm Entries : 0
-------------------------------------------------------------------------------
Rem Num Entries : 6
Rem Lcl Deleted Entries : 0
Rem Alarm Entries : 0
-------------------------------------------------------------------------------
---snip---
===============================================================================
Ports synced on peer 192.0.2.1
===============================================================================
Port/Encap Tag
-------------------------------------------------------------------------------
1/1/3
1-2 srrp1
===============================================================================
---snip--
 
This shows that there are six entries on both peers for SRRP.
If the delayed-enable parameter is configured under the subscriber-interface, in order to allow time for the MCS to fully synchronize, its setting and current expiry time can be seen as follows:
*A:BNG-2# show service id 1 interface sub-int-1 detail
===============================================================================
Interface Table
===============================================================================
Interface
-------------------------------------------------------------------------------
If Name : sub-int-1
Admin State : Up Oper (v4/v6) : Up/--
Protocols : None
IP Addr/mask : 10.2.0.2/16
IP Addr/mask : 10.3.0.2/16
IP Addr/mask : 10.4.0.2/16
-------------------------------------------------------------------------------
Details
-------------------------------------------------------------------------------
Description : (Not Specified)
If Index : 2 Virt. If Index : 2
Last Oper Chg: 12/15/2009 15:14:43 Global If Index : 125
Delay IfUp : 1200 init-only
If Type : VPRN Sub
DHCP Details
Gi-Addr : Not configured Gi-Addr as Src Ip: Disabled
===============================================================================
Interface sub-int-1 group-interfaces
===============================================================================
Interface-Name Adm Opr(v4/v6) Mode Port/SapId
IP-Address PfxState
-------------------------------------------------------------------------------
group-int-1 Up Up/-- VPRN G* 1/1/3
 
Tool Dump Commands Related Information
The database entries can be view in more detail with the tools dump redundancy multi-chassis command.
*A:BNG-2# tools dump redundancy multi-chassis sync-database ?
The following totals are for:
peer ip ALL, port/lag ALL, sync-tag ALL, application ALL
Valid Entries: 6
Locally Deleted Entries: 0
Locally Deleted Alarmed Entries: 0
The output of the “tool dump redundancy multi-chassis” command.
*A:BNG-2# tools dump redundancy multi-chassis srrp-sync-database
Tag Key: sap = 1/1/3:2
Key Info: (Type/Owner)
SMK_BASE_CONFIG / 192.0.2.1
Data Info:
srrpId: 1 svcId: 1 svcType: VPRN
system IP: 0xc0000201 Group interface MAC: 00:03:fa:90:f8:6a
Gateway MAC: 00:00:5e:00:01:01
Subscriber interface name: sub-int-1
 
Tag Key: sap = 1/1/3:2
Key Info: (Type/Owner)
SMK_BASE_CONFIG / 192.0.2.2
Data Info:
srrpId: 1 svcId: 1 svcType: VPRN
system IP: 0xc0000202 Group interface MAC: 00:03:fa:56:9e:96
Gateway MAC: 00:00:5e:00:01:01
Subscriber interface name: sub-int-1
 
Tag Key: sap = 1/1/3:2
Key Info: (Type/Owner)
SMK_GRP_IF / 192.0.2.1
Data Info:
Group interface name: group-int-1
Group Interface Sap (Tag/Encap): srrp1/2
Group Interface Sap (Tag/Encap): srrp1/1
Redundant interface name: bng-1-bng-2-vprn-1
Redundant Interface IP/Mask:
IP: 0xc0a80400 Mask: 0xfffffffe
AdminUp: Up, OperState: SRRP_STATE_BACKUP_SHUNT, InUsePriority: 200, Red-If OK: Yes, MessageSap OK: Yes
Tag Key: sap = 1/1/3:2
Key Info: (Type/Owner)
SMK_GRP_IF / 192.0.2.2
Data Info:
Group interface name: group-int-1
Group Interface Sap (Tag/Encap): srrp1/2
Group Interface Sap (Tag/Encap): srrp1/1
Redundant interface name: bng-2-bng-1-vprn-1
Redundant Interface IP/Mask:
IP: 0xc0a80401 Mask: 0xfffffffe
AdminUp: Up, OperState: SRRP_STATE_MASTER, InUsePriority: 250, Red-If OK: Yes, MessageSap OK: Yes
Tag Key: sap = 1/1/3:2
Key Info: (Type/Owner)
SMK_SUBNET_INFO / 192.0.2.1 vRtrId 2, ifIdx 2
Data Info:
Subscriber IP Addr: 10.2.0.1 Mask: 0xffff0000 Gateway: 10.2.0.254
Subscriber IP Addr: 10.3.0.1 Mask: 0xffff0000 Gateway: 10.3.0.254
Subscriber IP Addr: 10.4.0.1 Mask: 0xffff0000 Gateway: 10.4.0.254
Tag Key: sap = 1/1/3:2
Key Info: (Type/Owner)
SMK_SUBNET_INFO / 192.0.2.2 vRtrId 2, ifIdx 2
Data Info:
Subscriber IP Addr: 10.2.0.2 Mask: 0xffff0000 Gateway: 10.2.0.254
Subscriber IP Addr: 10.3.0.2 Mask: 0xffff0000 Gateway: 10.3.0.254
Subscriber IP Addr: 10.4.0.2 Mask: 0xffff0000 Gateway: 10.4.0.254
Also shown are the port/VLANs synchronized with their respective sync-tags.
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:
 
tools dump redundancy multi-chassis sync-database [application {sub-mgmt|srrp}]
 
The command provides the same information as the equivalent show commands. However, the detailed version gives more information about the contents of the sync-database.
For SRRP, there are entries for the base configuration, group interface and subnet information for each of the SRRP instances. This should show corresponding entries for the local and remote peer. Specifying the sync-tag srrp1 shows only the information for SRRP instance 1.
*A:BNG-2# tools dump redundancy multi-chassis sync-database application srrp sync-tag srrp1 detail
 
If no entries are present for an application, no detail will be displayed.
 
FLAGS LEGEND: ld - local delete; da - delete alarm
 
Peer Ip 192.0.2.1
 
 
Application SRRP
Sap-id Client Key
SyncTag DLen Flags timeStamp
deleteReason code and description
-------------------------------------------------------------------------------
1/1/3:2 SMK_BASE_CONFIG / 192.0.2.1
srrp1 88 -- -- 12/15/2009 15:52:18
0x0
1/1/3:2 SMK_BASE_CONFIG / 192.0.2.2
srrp1 88 -- -- 12/15/2009 15:51:57
0x0
1/1/3:2 SMK_GRP_IF / 192.0.2.1
srrp1 260 -- -- 12/16/2009 16:10:50
0x0
1/1/3:2 SMK_GRP_IF / 192.0.2.2
srrp1 260 -- -- 12/16/2009 16:10:50
0x0
1/1/3:2 SMK_SUBNET_INFO / 192.0.2.1 vRtrId 2, ifIdx 2
srrp1 40 -- -- 12/15/2009 15:52:18
0x0
1/1/3:2 SMK_SUBNET_INFO / 192.0.2.2 vRtrId 2, ifIdx 2
srrp1 40 -- -- 12/15/2009 15:51:57
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
This same information can be seen in more detail by dumping the SRRP database. This output is for SRRP instance 1, 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.
*A:BNG-2# tools dump redundancy multi-chassis srrp-sync-database instance 1
Tag Key: sap = 1/1/3:2
Key Info: (Type/Owner)
SMK_BASE_CONFIG / 192.0.2.1
Data Info:
srrpId: 1 svcId: 1 svcType: VPRN
system IP: 0xc0000201 Group interface MAC: 00:03:fa:90:f8:6a
Gateway MAC: 00:00:5e:00:01:01
Subscriber interface name: sub-int-1
 
Tag Key: sap = 1/1/3:2
Key Info: (Type/Owner)
SMK_BASE_CONFIG / 192.0.2.2
Data Info:
srrpId: 1 svcId: 1 svcType: VPRN
system IP: 0xc0000202 Group interface MAC: 00:03:fa:56:9e:96
Gateway MAC: 00:00:5e:00:01:01
Subscriber interface name: sub-int-1
 
Tag Key: sap = 1/1/3:2
Key Info: (Type/Owner)
SMK_GRP_IF / 192.0.2.1
Data Info:
Group interface name: group-int-1
Group Interface Sap (Tag/Encap): srrp1/2
Group Interface Sap (Tag/Encap): srrp1/1
Redundant interface name: bng-1-bng-2-vprn-1
Redundant Interface IP/Mask:
IP: 0xc0a80400 Mask: 0xfffffffe
AdminUp: Up, OperState: SRRP_STATE_BACKUP_SHUNT, InUsePriority: 200, Red-If OK: Yes, MessageSap OK: Yes
Tag Key: sap = 1/1/3:2
Key Info: (Type/Owner)
SMK_GRP_IF / 192.0.2.2
Data Info:
Group interface name: group-int-1
Group Interface Sap (Tag/Encap): srrp1/2
Group Interface Sap (Tag/Encap): srrp1/1
Redundant interface name: bng-2-bng-1-vprn-1
Redundant Interface IP/Mask:
IP: 0xc0a80401 Mask: 0xfffffffe
AdminUp: Up, OperState: SRRP_STATE_MASTER, InUsePriority: 250, Red-If OK: Yes, MessageSap OK: Yes
Tag Key: sap = 1/1/3:2
Key Info: (Type/Owner)
SMK_SUBNET_INFO / 192.0.2.1 vRtrId 2, ifIdx 2
Data Info:
Subscriber IP Addr: 10.2.0.1 Mask: 0xffff0000 Gateway: 10.2.0.254
Subscriber IP Addr: 10.3.0.1 Mask: 0xffff0000 Gateway: 10.3.0.254
Subscriber IP Addr: 10.4.0.1 Mask: 0xffff0000 Gateway: 10.4.0.254
Tag Key: sap = 1/1/3:2
Key Info: (Type/Owner)
SMK_SUBNET_INFO / 192.0.2.2 vRtrId 2, ifIdx 2
Data Info:
Subscriber IP Addr: 10.2.0.2 Mask: 0xffff0000 Gateway: 10.2.0.254
Subscriber IP Addr: 10.3.0.2 Mask: 0xffff0000 Gateway: 10.3.0.254
Subscriber IP Addr: 10.4.0.2 Mask: 0xffff0000 Gateway: 10.4.0.254
The following is an example of error messages that could be seen due to this synchronization which otherwise without it would not be available.
An event will be generated in log 99, if the IP address was removed from the redundant interface on the remote peer.
10 2009/12/16 16:08:50.55 UTC WARNING: MC_REDUNDANCY #2012 vprn1 SRRP/MCS: Peer Red i/f down
"SRRP ID 1: Redundant interface bng-2-bng-1-vprn-1 on peer 192.0.2.2 / interface group-int-1 does not match local 192.0.2.1 / interface group-int-1."
9 2009/12/16 16:08:50.54 UTC MINOR: MC_REDUNDANCY #2024 vprn1 Become Backup-Route
"SRRP instance 1 on interface group-int-1 changed state to backup - current master is 192.0.2.2"
 
8 2009/12/16 16:08:50.53 UTC WARNING: MC_REDUNDANCY #2012 vprn1 SRRP/MCS: Peer Red i/f no addr
"SRRP ID 1: Redundant interface bng-2-bng-1-vprn-1 on peer 192.0.2.2 / interface group-int-1 does not match local 192.0.2.1 / interface group-int-
 
The SRRP Instance Related Information
The SRRP instance information can be displayed by the following commands:
The master BNS shows the master in the operation status.
*A:BNG-2# show srrp
===============================================================================
SRRP Table
===============================================================================
ID Service Group Interface Admin Oper
-------------------------------------------------------------------------------
1 1 group-int-1 Up master
-------------------------------------------------------------------------------
No. of SRRP Entries: 1
===============================================================================
*A:BNG-2#
 
The backup BNG shows a backupShunt in the operation status.
*B:BNG-1# show srrp
===============================================================================
SRRP Table
===============================================================================
ID Service Group Interface Admin Oper
-------------------------------------------------------------------------------
1 1 group-int-1 Up backupShunt
-------------------------------------------------------------------------------
...
===============================================================================
*B:BNG-1#
 
To check detailed information:
*A:BNG-2# show srrp  1 detail
===============================================================================
SRRP Instance 1
===============================================================================
Description : (Not Specified)
Admin State : Up Oper State : master
System IP : 192.0.2.2
Service ID : VPRN 1
Group If : group-int-1 MAC Address : 00:03:fa:56:9e:96
Grp If Description:N/A
Grp If Admin State : Up Grp If Oper State: Up
Subscriber If : sub-int-1
Sub If Admin State : Up Sub If Oper State: Up
Address : 10.2.0.2/16 Gateway IP : 10.2.0.254
Address : 10.3.0.2/16 Gateway IP : 10.3.0.254
Address : 10.4.0.2/16 Gateway IP : 10.4.0.254
Redundant If : bng-2-bng-1-vprn-1
Red If Admin State : Up Red If Oper State: Up
Address : 192.168.4.1/31
Red Spoke-sdp : 21:1
Msg Path SAP : 1/1/3:2
Admin Gateway MAC : Oper Gateway MAC : 00:00:5e:00:01:01
Config Priority : 250 In-use Priority : 250
Master Priority : 250
Keep-alive Interval : 1 deci-seconds Master Since : 12/16/2009 10:42:31
VRRP Policy 1 : None VRRP Policy 2 : None
-------------------------------------------------------------------------------
BFD interface
-------------------------------------------------------------------------------
Service ID : 2
Interface Name : bfd-1
Src IP : 10.1.1.0
Dst IP : 10.1.1.1
Session Oper State : connected
-------------------------------------------------------------------------------
Statistics
-------------------------------------------------------------------------------
Become Master : 1 Master Changes : 1
Become Bkup Routing : 0 Become Bkup Shunt: 1
Become Non-Master : 0
Adv Sent : 197854 Adv Received : 685948
Pri 0 Pkts Sent : 0 Pri 0 Pkts Rcvd : 0
Preempt Events : 1 Preempted Events : 0
Mesg Intvl Discards : 0 Mesg Intvl Errors: 0
If this output is shown on the SRRP backup, an extra line appears after the keep-alive-interval showing the interval during which the receipt of no SRRP messages would cause the master to be considered down, together with the instantaneous time to this interval expiring.
Master Down Interval: 0.300 sec (Expires in 0.250 sec)
 
Monitoring the Traffic on Redundant Interface
The 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 operational 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 (for example, forwarded) across the redundant interface to the peer (to the master) in order to be forwarded to the subscriber.
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 through its associated SAP.
A useful command to see the traffic on the redundant interface is:
*A:BNG-2# monitor service id 1 sdp 21:1 rate interval 11 repeat 3
===============================================================================
Monitor statistics for Service 1 SDP binding 21:1
===============================================================================
-------------------------------------------------------------------------------
At time t = 0 sec (Base Statistics)
-------------------------------------------------------------------------------
I. Fwd. Pkts. : 19517656 I. Dro. Pkts. : 13
E. Fwd. Pkts. : 14 E. Fwd. Octets : 1090
 
-------------------------------------------------------------------------------
At time t = 11 sec (Mode: Rate)
-------------------------------------------------------------------------------
I. Fwd. Pkts. : 1000 I. Dro. Pkts. : 0
E. Fwd. Pkts. : 0 E. Fwd. Octets : 0
 
---snip---
 
BFD-Related Information
To check the BFD session state.
*A:BNG-2# show router bfd session
===============================================================================
BFD Session
===============================================================================
Interface State Tx Intvl Rx Intvl Mult
Remote Address Protocol Tx Pkts Rx Pkts
-------------------------------------------------------------------------------
bfd-1 Up (3) 100 100 3
10.1.1.1 srrp 875616 874287
-------------------------------------------------------------------------------
No. of BFD sessions: 1
===============================================================================
*A:BNG-2#
To check the MAC addresses of the SRRP, this is can be done by checking the MACs table in the BSAN.
*A:dslam# show service fdb-mac
===============================================================================
Service Forwarding Database
===============================================================================
ServId MAC Source-Identifier Type/Age Last Change
-------------------------------------------------------------------------------
1 00:00:00:00:00:01 sap:1/1/4:1 L/0 12/16/2009 17:35:29
1 00:00:5e:00:01:01 sap:1/1/1:1 L/0 12/16/2009 17:35:29
2 00:00:5e:00:01:01 sap:1/1/1:2 L/0 12/16/2009 16:45:17
3 00:03:fa:56:9e:96 sap:1/1/1:3 L/0 12/16/2009 16:04:00
3 00:03:fa:90:f8:6a sap:1/1/2:3 L/0 12/16/2009 16:04:05
-------------------------------------------------------------------------------
No. of Entries: 5
===============================================================================
*A:dslam# 
 
The first entry shows the source MAC address of SRRP 1 which is learned through the SRRP messages received from the SRRP master for that instance. The next two entries relate to the subscriber traffic to and from sub1. Note that the 7750/7710 SR source MAC address is that of the SRRP instance.
The last two entries are the source MAC address BFD received from each BNG.
 
SRRP Debug Commands
There are debug command to show the SRRP protocol events and packets.
*A:BNG-2# debug router 1 srrp events
*A:BNG-2# debug router 1 srrp packets
To display the debugging information, a dedicated log should be created:
*A:BNG-2# configure log
log-id 1
from debug-trace
to session
exit
The following output displays a sample SRRP debug log:
109 2009/12/16 16:21:57.87 UTC MINOR: DEBUG #2001 vprn1 SRRP
"SRRP: Sending Pkt
 
Version (SRRP) : 8
Type : Advertisement (1)
Vr Id : 1
Priority : 250
Count Ip Addresses : 3
Advertise Interval : 10 centi-second
Checksum : 0x25ef
 
Raw Pkt:
 
81 00 fa 00 00 00 00 01 00 00 5e 00 01 01 00 0a
00 03 25 ef "
Example:
Change the state of BNG-1 by receiving a higher SRRP priority from BNG-2 if the SRRP priority in BNG-1 is higher than the configured one in BNG-2.
In the following output, this peer is the SRRP master for instance one 1 and is sending SRRP messages, it then receives an SRRP message with a higher priority (254) from its peer. This causes an event Become Pending-Backup Shunt where it prepares to transition to the backup state. To achieve this, it sends and SRRP message with priority 0. If it continues to receive SRRP messages (with priority 254) from its peer, then passes into the backup state with the event Become Backup Shunt.
646 2009/12/16 18:06:47.77 UTC MINOR: DEBUG #2001 vprn1 SRRP
"SRRP: Sending Pkt
 
Version (SRRP) : 8
Type : Advertisement (1)
Vr Id : 1
Priority : 250
Count Ip Addresses : 3
Advertise Interval : 10 centi-second
Checksum : 0x25ef
 
Raw Pkt:
 
81 00 fa 00 00 00 00 01 00 00 5e 00 01 01 00 0a
00 03 25 ef "
 
 
647 2009/12/16 18:06:47.77 UTC MINOR: DEBUG #2001 vprn1 SRRP
"SRRP: Receiving Pkt
 
Version (SRRP) : 8
Type : Advertisement (1)
Vr Id : 1
Priority : 254
Count Ip Addresses : 3
Advertise Interval : 10 centi-second
Checksum : 0x21ee
 
Raw Pkt:
 
81 01 fe 00 00 00 00 01 00 00 5e 00 01 01 00 0a
00 03 21 ee "
 
 
648 2009/12/16 18:06:47.77 UTC MINOR: DEBUG #2001 vprn1 SRRP
"SRRP: Event
Become Pending-Backup Shunt: vRtrId 2, ifIdx 3, IPv4 vr_id 1, Master IP 192.0.2.
1"
 
 
649 2009/12/16 18:06:47.78 UTC MINOR: DEBUG #2001 vprn1 SRRP
"SRRP: Sending Pkt
 
Version (SRRP) : 8
Type : Advertisement (1)
Vr Id : 1
Priority : 0
Count Ip Addresses : 3
Advertise Interval : 10 centi-second
Checksum : 0x1ff0
 
Raw Pkt:
 
81 00 00 00 00 00 00 01 00 00 5e 00 01 01 00 0a
00 03 1f f0 "
 
 
650 2009/12/16 18:06:47.78 UTC MINOR: DEBUG #2001 vprn1 SRRP
"SRRP: Receiving Pkt
 
Version (SRRP) : 8
Type : Advertisement (1)
Vr Id : 1
Priority : 254
Count Ip Addresses : 3
Advertise Interval : 10 centi-second
Checksum : 0x21ef
 
Raw Pkt:
 
81 00 fe 00 00 00 00 01 00 00 5e 00 01 01 00 0a
00 03 21 ef "
 
 
651 2009/12/16 18:06:47.78 UTC MINOR: DEBUG #2001 vprn1 SRRP
"SRRP: Event
Become Backup Shunt: vRtrId 2, ifIdx 3, IPv4 vr_id 1, Master IP 192.0.2.1"
 
 
652 2009/12/16 18:06:47.78 UTC MINOR: DEBUG #2001 vprn1 SRRP
"SRRP: Receiving Pkt
 
Version (SRRP) : 8
Type : Advertisement (1)
Vr Id : 1
Priority : 254
Count Ip Addresses : 3
Advertise Interval : 10 centi-second
Checksum : 0x21ef
 
Raw Pkt:
 
81 00 fe 00 00 00 00 01 00 00 5e 00 01 01 00 0a
00 03 21 ef "
 
The output for the SRRP message captured with wireshark .
No. Time Source Destination Protocol Info
1 0.000000 192.0.2.2 224.0.0.18 VRRP Announcement (v8)
 
Frame 1 (68 bytes on wire, 68 bytes captured)
Ethernet II, Src: IETF-VRRP-virtual-router-VRID_01 (00:00:5e:00:01:01), Dst: IPv4mcast_00:00:12 (01:00:5e:00:00:12)
Destination: IPv4mcast_00:00:12 (01:00:5e:00:00:12)
Address: IPv4mcast_00:00:12 (01:00:5e:00:00:12)
.... ...1 .... .... .... .... = IG bit: Group address (multicast/broadcast)
.... ..0. .... .... .... .... = LG bit: Globally unique address (factory default)
Source: IETF-VRRP-virtual-router-VRID_01 (00:00:5e:00:01:01)
Address: IETF-VRRP-virtual-router-VRID_01 (00:00:5e:00:01:01)
.... ...0 .... .... .... .... = IG bit: Individual address (unicast)
.... ..0. .... .... .... .... = LG bit: Globally unique address (factory default)
Type: 802.1Q Virtual LAN (0x8100)
802.1Q Virtual LAN, PRI: 0, CFI: 0, ID: 2
000. .... .... .... = Priority: 0
...0 .... .... .... = CFI: 0
.... 0000 0000 0010 = ID: 2
Type: 802.1Q Virtual LAN (0x8100)
802.1Q Virtual LAN, PRI: 0, CFI: 0, ID: 2
000. .... .... .... = Priority: 0
...0 .... .... .... = CFI: 0
.... 0000 0000 0010 = ID: 2
Type: IP (0x0800)
Trailer: 000066BD5035
Internet Protocol, Src: 192.0.2.2 (192.0.2.2), Dst: 224.0.0.18 (224.0.0.18)
Version: 4
Header length: 20 bytes
Differentiated Services Field: 0xc0 (DSCP 0x30: Class Selector 6; ECN: 0x00)
Total Length: 40
Identification: 0x0139 (313)
Flags: 0x00
Fragment offset: 0
Time to live: 255
Protocol: VRRP (0x70)
Header checksum: 0x1758 [correct]
[Good: True]
[Bad : False]
Source: 192.0.2.2 (192.0.2.2)
Destination: 224.0.0.18 (224.0.0.18)
Virtual Router Redundancy Protocol
Version 8, Packet type 1 (Advertisement)
1000 .... = VRRP protocol version: 8
.... 0001 = VRRP packet type: Advertisement (1)
Virtual Rtr ID: 0
Priority: 250 (Non-default backup priority)
Count IP Addrs: 0
Auth Type: No Authentication (0)
Adver Int: 0
Checksum: 0x0001 [correct]
 
SRRP Traffic Marking
The SRRP messages are sent by default with DSCP of nc1 and with 802.1p bits of 0.
802.1Q Virtual LAN, PRI: 0, CFI: 0, ID: 100
000. .... .... .... = Priority: 0
...0.... .... .... = CFI: 0
.... 0000 0110 0100 = ID: 100
Type: 802.1Q Virtual LAN (0x8100)
 
Internet Protocol, Src: 10.10.10.3 (10.10.10.3), Dst: 224.0.0.18 (224.0.0.18)
Version: 4
Header length: 20 bytes
Differentiated Services Field: 0xc0 (DSCP 0x30: Class Selector 6; ECN: 0x00)
 
*A:BNG-2# show qos dscp-table
===========================================================
DSCP Mapping
===========================================================
DSCP Name DSCP Value TOS (bin) TOS (hex)
-----------------------------------------------------------
nc1 48 1100 0000 C0
Where DSCP 0x30=48 (DSCP value). This can be changed to EF, for example, using the following command:
*A:BNG-2# configure service vprn 1 sgt-qos application srrp dscp ef
Conclusion
This section provides configuration and troubleshooting commands for SRRP with static (IP-MAC) host in a Layer 3 Routed-CO (IES/VPRN subscriber interface) context.