Application Assurance — Asymmetry Removal
This chapter describes Application Assurance asymmetry removal configurations.
Topics in this chapter include:
Applicability
This chapter was originally written for and configured on SR OS Release 11.0.R1. The CLI in the current edition corresponds to SR OS Release 14.0.R4.
The prerequisites for this chapter are a base understanding of AA configuration and operation for single homed deployments. This chapter applies to dual-homed SAPs and spoke SDPs configurations, in a business or residential AA context. AARP is not used for ESM AA subscribers.
Overview
This chapter is intended for Application Assurance (AA) network architects and engineers. It provides best practices recommendations to configure AA asymmetry removal.
Asymmetry means that the two directions of a traffic flow (to-sub and from-sub) take different paths through the network. Asymmetry removal is a means of eliminating traffic asymmetry between a set of dual-homed SAP or spoke SDP endpoints. This can be across endpoints within a single node or across a pair of inter-chassis link connected routers, which is the topology explained in this chapter. Asymmetry removal ensures all packets of a dual-homed AA subscriber are diverted to an AA ISA in order to achieve accurate per subscriber traffic identification and policy enforcement.
Traffic asymmetry is created when there are dual-homed links for a service, and the links are simultaneously carrying traffic. Asymmetry removal for transit subscribers must be implemented in the first routed hop on the network side of the subscriber management point, so there will be a deterministic and fixed SAP/spoke SDP representing the downstream subscriber management node. This ensures there are no more than two paths that the flows can take, both covered by the asymmetry removal solution.
Configuration
Application Assurance Redundancy Protocol (AARP) provides the data plane connectivity for dynamically keeping a dual-homed AA subscriber’s traffic on the same ISA-AA for AA processing. An AARP instance is configured between the dual-homed routers to establish connectivity with the same AARP instance number on each node.
When asymmetry exists between dual-chassis redundant systems, Ipipe spoke SDPs are used to interconnect these services between peer nodes over an Inter-Chassis Link (ICL). The following sections explain the configuration and operation of the services for use with the Application Assurance Redundancy Protocol.
AARP service configuration
The following services must be configured to establish communications between the AARP instances in each of the paired nodes.
Network topology is a VPRN (or IES) service configured in each node, with a dual-homed SAP from each node to a downstream access element.
Assumes starting point with AA ISAs installed with identical AA policy and divert enabled in each node.
Also, the system needs basic routing and LDP configuration for the SDP and the spoke SDPs to be established.
Table 1. AA asymmetry removal topology On PE-2
On PE-1
system ip: 192.0.2.2
system ip: 192.0.2.1
dual-homed service: 200
dual-homed service: 200
dual-homed sap: 1/1/4:200
dual-homed sap: 1/1/4:200
app-profile diverting: yes
app-profile diverting: yes
Configuration commands for AARP
To enable AARP, AARP instances and AARP interfaces on both nodes must be configured. AARP operation has the following dependencies between the nodes:
Shunt links configured and operationally up, both subscriber side shunt and network side shunt.
Peer communications established between nodes, AARP instance operational status will be up when peers are communicating.
Dual-homed sap/spoke SDP configured with a unique AARP instance (matched by dual-homed interface).
App-profile configured against sap/spoke SDP with divert enabled (making the sub an aa-sub). The app-profile is the trigger to divert the traffic in the node with the active AARP instance to one of the ISAs in that node, per normal AA divert behavior.
Begin with PE-2:
configure
application-assurance
aarp 200 create
description "aarp protecting a dual-homed sap"
priority 100
peer 192.0.2.1
no shutdown
exit
exit
exit
Ipipe shunt configuration
configure
service
sdp 21 mpls create
far-end 192.0.2.1
ldp
keep-alive
shutdown
exit
no shutdown
exit
ipipe 210 customer 1 vc-switching create
service-mtu 1556
spoke-sdp 21:200 create
aarp 200 type subscriber-side-shunt
no shutdown
exit
spoke-sdp 21:201 create
aarp 200 type network-side-shunt
no shutdown
exit
no shutdown
exit
exit
exit
Dual-homed and interface shunt configuration
configure
service
vprn 200 customer 1 create
description "VPRN 200 Dual Homed Routed Service"
aarp-interface "subside_1" create
spoke-sdp 21:212 create
aarp 200 type subscriber-side-shunt
no shutdown
exit
exit
aarp-interface "netside_1" create
spoke-sdp 21:213 create
aarp 200 type network-side-shunt
no shutdown
exit
exit
interface "int-BRAS-1" create
sap 1/1/4:200 create
aarp 200 type dual-homed
app-profile "app-prof-1"
exit
exit
no shutdown
exit
exit
exit
Then similarly configure the associated AARP configuration on PE-1:
configure
application-assurance
aarp 200 create
description "aarp protecting a dual-homed sap"
priority 200
peer 192.0.2.2
no shutdown
exit
exit
exit
Ipipe shunt configuration
configure
service
sdp 12 mpls create
far-end 192.0.2.2
ldp
keep-alive
shutdown
exit
no shutdown
exit
ipipe 210 customer 1 vc-switching create
service-mtu 1556
spoke-sdp 12:212 create
aarp 200 type subscriber-side-shunt
no shutdown
exit
spoke-sdp 12:213 create
aarp 200 type network-side-shunt
no shutdown
exit
no shutdown
exit
exit
exit
Dual-homed and interface shunt configuration
configure
service
vprn 200 customer 1 create
aarp-interface "subside_1" create
spoke-sdp 12:200 create
aarp 200 type subscriber-side-shunt
no shutdown
exit
exit
aarp-interface "netside_1" create
spoke-sdp 12:201 create
aarp 200 type network-side-shunt
no shutdown
exit
exit
interface "int-BRAS-1" create
sap 1/1/4:200 create
description "AA enabled SAP"
aarp 200 type dual-homed
app-profile "app-prof-1"
exit
exit
no shutdown
exit
exit
exit
Show commands for AARP
Verify correct configuration on each node. The following output displays the example configuration for PE-1.
Starting with the AARP instance in each node, verify that the AARP instance operational state is up (if everything is properly configured as intended):
*A:PE-1# show application-assurance aarp 200
===============================================================================
AARP Instance 200
===============================================================================
Description : aarp protecting a dual-homed sap
Admin State : Up Oper State : Up
Local IP : 192.0.2.1 Peer IP : 192.0.2.2
Local State : master Peer State : backup
Local Priority : 200 Peer Priority : 100
Local Flags : none
Peer Flags : none
Peer End-Point : none
Master Selection Mode : minimizeSwitchovers
-------------------------------------------------------------------------------
Service References
-------------------------------------------------------------------------------
Service Reference Reference Type
-------------------------------------------------------------------------------
VPRN 200 1/1/4:200 Dual-Homed
Ipipe 210 12:212 Subscriber-Side Pipe Shunt
Ipipe 210 12:213 Network-Side Pipe Shunt
VPRN 200 12:200 Subscriber-Side AARP-Interface Shunt
VPRN 200 12:201 Network-Side AARP-Interface Shunt
-------------------------------------------------------------------------------
No. of service references: 5
-------------------------------------------------------------------------------
===============================================================================
*A:PE-1#
Verifying that the AARP instance is up is an indication that the dual-node communications for AARP is working (instance, shunts, etc.). In addition, in the preceding output, verify on both PE nodes that the intended SAPs are dual-homed for that instance.
Now a detailed review of the configured AARP shunt infrastructure services can be shown to make sure they are all properly configured with intended AARP parameters (such as AARP ID and Type on the network and subscriber side shunts) as displayed in the following output:
*A:PE-1# show service id 210 all
===============================================================================
Service Detailed Information
===============================================================================
Service Id : 210 Vpn Id : 0
Service Type : Ipipe
Name : (Not Specified)
Description : (Not Specified)
Customer Id : 1 Creation Origin : manual
Last Status Change: 10/03/2016 11:45:51
Last Mgmt Change : 10/03/2016 11:45:51
Admin State : Up Oper State : Up
MTU : 1556
Vc Switching : True
SAP Count : 0 SDP Bind Count : 2
CE IPv4 Discovery : n/a Keep address : No
CE IPv6 Discovery : n/a Stack Cap Sig : n/a
Eth Legacy Fault Notification
-------------------------------------------------------------------------------
Recovery Timer : 10.0 secs Admin State : outOfService
-------------------------------------------------------------------------------
ETH-CFM service specifics
-------------------------------------------------------------------------------
Tunnel Faults : ignore
-------------------------------------------------------------------------------
Service Destination Points(SDPs)
-------------------------------------------------------------------------------
-------------------------------------------------------------------------------
Sdp Id 12:212 -(192.0.2.2)
-------------------------------------------------------------------------------
Description : (Not Specified)
SDP Id : 12:212 Type : Spoke
Spoke Descr : (Not Specified)
Split Horiz Grp : (Not Specified)
VC Type : Ipipe VC Tag : 0
Admin Path MTU : 0 Oper Path MTU : 1556
Delivery : MPLS
Far End : 192.0.2.2
Tunnel Far End : 192.0.2.2 LSP Types : LDP
Hash Label : Disabled Hash Lbl Sig Cap : Disabled
Oper Hash Label : Disabled
Entropy Label : Disabled
Admin State : Up Oper State : Up
MinReqd SdpOperMTU : 1556
Acct. Pol : None Collect Stats : Disabled
Ingress Label : 262141 Egress Label : 262139
---snip---
Application Profile: None
Transit Policy : None
AARP Id : 200
AARP Type : subscriber-side-shunt
---snip---
-------------------------------------------------------------------------------
IPIPE Service Destination Point specifics
-------------------------------------------------------------------------------
Configured CE IPv4 Addr: n/a Peer CE IPv4 Addr : 0.0.0.0
-------------------------------------------------------------------------------
Sdp Id 12:213 -(192.0.2.2)
-------------------------------------------------------------------------------
Description : (Not Specified)
SDP Id : 12:213 Type : Spoke
Spoke Descr : (Not Specified)
Split Horiz Grp : (Not Specified)
VC Type : Ipipe VC Tag : 0
Admin Path MTU : 0 Oper Path MTU : 1556
Delivery : MPLS
Far End : 192.0.2.2
Tunnel Far End : 192.0.2.2 LSP Types : LDP
Hash Label : Disabled Hash Lbl Sig Cap : Disabled
Oper Hash Label : Disabled
Entropy Label : Disabled
Admin State : Up Oper State : Up
MinReqd SdpOperMTU : 1556
Acct. Pol : None Collect Stats : Disabled
Ingress Label : 262140 Egress Label : 262138
---snip---
Application Profile: None
Transit Policy : None
AARP Id : 200
AARP Type : network-side-shunt
---snip---
===============================================================================
Next, the configuration of the VPRN service of the dual-homed SAP can be reviewed to ensure it reflects the attached endpoints for the shunt Ipipe spoke SDPs:
*A:PE-1# show service id 200 all
===============================================================================
Service Detailed Information
===============================================================================
Service Id : 200 Vpn Id : 0
Service Type : VPRN
Name : (Not Specified)
Description : (Not Specified)
Customer Id : 1 Creation Origin : manual
Last Status Change: 10/03/2016 11:45:51
Last Mgmt Change : 10/03/2016 11:45:51
Admin State : Up Oper State : Up
Route Dist. : 64496:200 VPRN Type : regular
Oper Route Dist : 64496:200
Oper RD Type : configured
AS Number : None Router Id : 192.0.2.1
ECMP : Enabled ECMP Max Routes : 1
Max IPv4 Routes : No Limit
Auto Bind Tunnel
Resolution : disabled
Max IPv6 Routes : No Limit
Ignore NH Metric : Disabled
Hash Label : Disabled
Entropy Label : Disabled
Vrf Target : target:64496:200
Vrf Import : None
Vrf Export : None
MVPN Vrf Target : None
MVPN Vrf Import : None
MVPN Vrf Export : None
Car. Sup C-VPN : Disabled
Label mode : vrf
BGP VPN Backup : Disabled
BGP Export Inactv : Disabled
SAP Count : 1 SDP Bind Count : 2
VSD Domain : <none>
---snip---
-------------------------------------------------------------------------------
Service Destination Points(SDPs)
-------------------------------------------------------------------------------
-------------------------------------------------------------------------------
Sdp Id 12:200 -(192.0.2.2)
-------------------------------------------------------------------------------
Description : (Not Specified)
SDP Id : 12:200 Type : Spoke
Spoke Descr : (Not Specified)
VC Type : n/a VC Tag : n/a
Admin Path MTU : 0 Oper Path MTU : 1556
Delivery : MPLS
Far End : 192.0.2.2
Tunnel Far End : 192.0.2.2 LSP Types : LDP
Hash Label : Disabled Hash Lbl Sig Cap : Disabled
Oper Hash Label : Disabled
Entropy Label : Disabled
Admin State : Up Oper State : Up
---snip---
Application Profile: None
Transit Policy : None
AARP Id : 200
AARP Type : subscriber-side-shunt
---snip---
-------------------------------------------------------------------------------
IPIPE Service Destination Point specifics
-------------------------------------------------------------------------------
Configured CE IPv4 Addr: n/a Peer CE IPv4 Addr : 0.0.0.0
-------------------------------------------------------------------------------
Sdp Id 12:201 -(192.0.2.2)
-------------------------------------------------------------------------------
Description : (Not Specified)
SDP Id : 12:201 Type : Spoke
Spoke Descr : (Not Specified)
VC Type : n/a VC Tag : n/a
Admin Path MTU : 0 Oper Path MTU : 1556
Delivery : MPLS
Far End : 192.0.2.2
Tunnel Far End : 192.0.2.2 LSP Types : LDP
Hash Label : Disabled Hash Lbl Sig Cap : Disabled
Oper Hash Label : Disabled
Entropy Label : Disabled
Admin State : Up Oper State : Up
---snip---
Application Profile: None
Transit Policy : None
AARP Id : 200
AARP Type : network-side-shunt
---snip---
Continuing deeper into the same VPRN service show output, or using the following show command, it can be verified that the dual-homed SAP itself is properly configured and associated with that service and AARP instance:
*A:PE-1# show service id 200 sap 1/1/4:200 detail
===============================================================================
Service Access Points(SAP)
===============================================================================
Service Id : 200
SAP : 1/1/4:200 Encap : q-tag
Description : AA enabled SAP
Admin State : Up Oper State : Up
Flags : None
Multi Svc Site : None
Last Status Change : 10/03/2016 11:45:51
Last Mgmt Change : 10/03/2016 11:45:51
Sub Type : regular
Dot1Q Ethertype : 0x8100 QinQ Ethertype : 0x8100
Split Horizon Group: (Not Specified)
Admin MTU : 1518 Oper MTU : 1518
Ingr IP Fltr-Id : n/a Egr IP Fltr-Id : n/a
Ingr Mac Fltr-Id : n/a Egr Mac Fltr-Id : n/a
Ingr IPv6 Fltr-Id : n/a Egr IPv6 Fltr-Id : n/a
qinq-pbit-marking : both
Egr Agg Rate Limit: max
Q Frame-Based Acct : Disabled Limit Unused BW : Disabled
Acct. Pol : None Collect Stats : Disabled
Anti Spoofing : None Dynamic Hosts : Enabled
Avl Static Hosts : 0 Tot Static Hosts : 0
Calling-Station-Id : n/a
Application Profile: app-prof-1
Transit Policy : None
AARP Id : 200
AARP Type : dual-homed
Oper Group : (none) Monitor Oper Grp : (none)
Host Lockout Plcy : n/a
Lag Link Map Prof : (none)
Bandwidth : Not-Applicable
---snip---
===============================================================================
Network to subscriber traffic flow
When the AARP is operationally up, AARP tracks which ISA is the master ISA for each dual-homed AARP instance and uses the inter-chassis services (spoke SDP AARP shunts) to move all traffic for each instance traffic to the node with the Master ISA.
Looking at traffic in the network to subscriber direction (Network to subscriber traffic flow):
Traffic arriving on PE-1 is diverted to the local master ISA, processed, then proceeds to the egress SAP.
Traffic arriving on PE-2 with the backup AARP interface is sent to the master node for AA processing. The ingress FP forwards packets to network-side-shunt AARP interface for remote AA divert.
Arriving on PE-1, the packets on the AARP Ipipe are diverted to the master ISA where the packets are processed as if this traffic was traveling in the to-sub direction towards the dual-homed endpoint on PE-1, then returned to PE-2.
Entering PE-2, the traffic from the subscriber side shunt interface is not diverted to ISAs in that node and egresses on the AARP instance SAP.
With this behavior, traffic always returns to the original ingress node before egressing toward the subscriber (network path for the flows are not modified).
Subscriber to network traffic flow
Looking at traffic in the subscriber to network direction (Subscriber to network traffic flow):
Traffic arriving on PE-1 is diverted to the local master ISA, processed, then proceeds to the egress SAP.
Traffic arriving on PE-2 with the backup AARP ISA is sent to the master node for AA processing (not diverted to an ISA in PE-2). The ingress FP forwards packets to subscriber-side-shunt AARP interface for remote AA divert.
Arriving on PE-1, the packets on the AARP Ipipe are diverted to the master ISA where the packets are processed as if the traffic was flowing in the from-sub direction on the dual-homed endpoint, then returned to PE-2 over the Ipipe’s AARP subscriber-side-shunt.
Entering PE-2, the traffic from the network side shunt interface is forwarded by the IES/VPRN service to its destination.
Typical configuration mistakes
Operators configuring AARP can make some typical mistakes listed below that will keep the AARP instance in operational state down:
The spoke SDP AARP shunt instances’ IDs must be aligned with the respective spoke SDP on the peer node: if not, it will result in a flag indicating shunt mismatch in the show output.
Ipipe service MTU alignment — The Ipipe service MTU values must be the same in both nodes, otherwise it will result in the services be in operational status UP, but the AARP instance will remain down.
Conclusion
This chapter is intended for Application Assurance (AA) network architects and engineers to provide the information required to understand and configure dual-node asymmetry removal following the intended service configuration as used by the AARP implementation.