When VSM services part fails, the failure will not propagate to ABF, which will result in black holing of the traffic instead of switching the traffic to backup VSM, if one exists
To track the reach-ability between Ingress service App interface and Egress traffic port using IPSLA and trigger the ABF when this reach-ability breaks.
Consider a router with VSM and CGN services running on both of them. We have applied an ABF on Ingress port with first next hop pointing to Ingress service App in VSM1 and second next hop pointing to Ingress service App in VSM 2. At any instance, when next hop 1 becomes unreachable, the ABF will start diverting the traffic to service App in VSM2. Hence black holing of traffic will be avoided.
Each VSM has service and Infra part. There are situations where a service part of the VSM will not get propagated to infra part of VSM, which results in ABF been not notified of the next hop failure. So ABF will not switch the traffic to next hop, instead will continue to forward traffic to VSM1 which will result in traffic dropped as service part is no longer in running state to process the traffic.
To mitigate this scenario, one of the approach it to implement IPSLA which will track the path from Ingress service App to Egress traffic port. IPSLA used ICMP to track the path. If any failure happens in service part, this path will break and IP reachability goes down. Hence when service part of VSM fails, the IPSLA catches the failure. The failure will be propagated to ABF from then on and action will be taken accordingly which will be switchover of traffic from nexthop1 to next hop 2. Even after the failure, the IPSLA continues to track the path and once it comes back again, ABF will switch traffic back to nexthop1. Thus the traffic black holing due to services part failure is mitigated.
Following figures give a clear explanation on packet flow when VSM1 is active and when VSM1 fails. Also it gives explanation where the IPSLA is triggered. After these figures, the configuration examples are provided, which will help in implementing the solution without any hick ups.
This solution is verified on ASR9K routers with VSM running CGN services. We need to define one IPSLA track per VSM card using any one service App. The same can be used for tracking all ABFs associated with that card
Note: Please refer to following cisco support forum page for detailed explanation on CGN on VSM with HA scenarios.
Hey folks, backgroundI am merging two ASes, AS100 and AS300. AS100 runs ISIS level-2-only and has SR enabled. AS300 runs ospf and ospfv3 and has LDP enabled. I have interconnected iosxr-9k-3 in AS100 to iosxrv-5 AS300 using a physical link and r...
I routinely have to lifecycle 50+ from a site. One of the longest parts of this process is documenting and transferring specifics onto the new phone profile IE. Extension, Identifying name, ECT.Is there anyway to transfer a phone profile to a different ty...
Hello,during SMU installation on NCS5501-SE, IOS XR 7.1.2 I almost run out of a disk space. Here is the warning%HA-HA_WD-3-DISK_ALARM_ALERT : A monitored device / ( rootfs:/ ) is above 80% utilization. Current utilization = 85. Please remove unwanted user...
Hi, Guys, There are multiple IS-IS instances which are both running with Level-2 only in the network, and I do not want to leak the routes between these IS-IS instances, how to implement this stuff? Appreciate!