Multi-chassis datapath shunts

When traffic needs to be remotely diverted it flows over shunts that are provisioned as sdp-id:vc-id between the dual-homed AA subscriber local service and a remote vc-switching Ipipe.

• subscriber to network direction

  The traffic is either handled locally (diverted to a local ISA when the AARP state is Master) or at the peer 7750 SR (redirect over the shunt Ipipe when the local AARP state is Backup or Remote). When traffic arrives on the subscriber side spoke SDP of the shunt-Ipipe, the system uses the AARP ID of the Ipipe to associate with an app-profile, therefore triggering Ipipe divert. It is diverted to the same ISA used to service the dual-homed SAP or spoke SDP. The ISA then treats this traffic the same as if it was received locally on the dual-homed SAP or spoke SDP context. After ISA processing, the traffic returns on the network side of the Ipipe to the peer. When the traffic returns to the original 7750 SR, the shunt Ipipe terminates into the routed service and it makes a new routing decision.

• network to subscriber direction

  The traffic is either handled locally (diverted to a local ISA when the AARP state is Master) or at the peer 7750 SR (remote divert over the shunt Ipipe when the local AARP state is Backup or Remote). When traffic arrives on the shunt Ipipe from the peer with an AARP ID and associated app-profile, it is diverted through AA on the way to the subscriber-side spoke SDP. After AA processing, the traffic returns on the subscriber side of the Ipipe to the peer. When the traffic returns to the original 7750 SR, the shunt Ipipe terminates into the routed service and it makes a new routing decision to go out the dual-homed SAP or spoke SDP.

• AARP operational states

  In single node operation, there are two operational states, Master or Standalone. A single node AARP instance is Master when all these conditions are met, otherwise AARP is in the standalone state with is no asymmetry removal occurring:

  • Dual-homed (primary) and dual-homed-secondary endpoints are configured.

  • Divert capability is up.

  • App profile is diverting.

  • AA subscriber is configured.

With multi-chassis operation there are 4 operational states for an AARP instance: master, backup, remote and standalone:

• master

  In multi-chassis operation, an AARP instance can only become operationally master when the inter-chassis link datapath is operational and the control path is or was up, the received peer node status indicating the peer’s AARP instance and similar dependencies is or was up, and the AARP priority is higher than the peer. When the priority is equal then higher system interface IP address is used as a tiebreak.

  The master state is immediately switched to remote for AARP related failures that result in the instance being not ready. ICL datapath shunt SDP failures cause the peer AARP go standalone. A shunt/Ipipe SDP failure is determined by the failure detection protocol used (BFD on routes, keep-alive on SDPs, LDP/RSVP, and so on).

  When a SAP or spoke SDP with an AARP instance is shut down nothing changes for AARP, as packets can still use the AARP interface. When the SAP or spoke SDP is deleted, AARP is disassociated from the spoke SDP/SAP before deleting. The AARP instance still exists after deleting the SAP or spoke but without an association to an AA subscriber, the AARP state goes standalone.

• backup

  Backup is the AARP state when all required conditions of the AARP instance are met except the master/backup priority evaluation.

• remote

  When an AARP instance is operating with remote divert set for the protecting SAP or spoke AA subscriber. The peer AARP instance is the Master, there is no backup as the local system is not ready. This state is entered as a result of a failure in a local resource on the AARP instance, which triggers the divert traffic to the remote peer, such as a ISA failure without ISA backup). AA subscriber traffic is diverted over shunts to the peer.

• standalone

  AARP is not operational between the multi-chassis pair, with AA operating with local AA divert to the ISAs within that node. There is no master or backup. This is the starting initial state for the AARP instance, or as a result of a failure in a dependent ICL resource (MC-CTL communication link or shut down).

An AARP instance activity switch is when one node moves from master to remote or backup mode, with the peer node becoming master. This can occur on a per-instance basis using the re-evaluate tool, or for all instances on an ISA that fails. On an AARP activity switch, AA divert changes from local to remote or remote to local, such that any packet is not seen by both nodes, resulting in no missed packet counts or double counts against the AA subscriber.

AARP activity is non-revertive to maximize the ID accuracy of flows. When an AARP instance toggles activity, packets are diverted to the newly active divert ISA and are processed as new flows, which for mid-session flows, often results in ‟unknown” traffic ID until those flows terminate. When the condition that triggered the AARP activity switch is resolved and the instance remains in backup state to not cause an additional application ID impacting event. This is consistent with AA N+1 ISA activity switches.

Because AA ISA availability is a criteria for AARP switches, any ISA failure or shutdown moves all AARP instance activity to ISAs in the master peer nodes, such as during software upgrades of ISAs. Depending on the nature of the failure or sequence of an upgrade procedure, all AA traffic may be processed by ISAs in one of the peers with no traffic being processed by ISAs on the other node.

If rebalancing the ISA load between the peer nodes is necessary, the tools> perform>application-assurance>aarp aarp-id>force-evaluate command re-runs AARP activity evaluation on a per-ISA basis to determine master/backup AARP based on configured priority.

Table: Interaction and dependencies between AARP states shows the interaction and dependencies between AARP states between a local node and its peer.