IOS-XR ABF Behavior

[tcalvin2006]

Need some assistance in configuring ABF on IOS-XR 4.1.2 for the ASR 9000's.

ipv4 access-list EXAMPLE

10 permit ipv4 any any nexthop1 ipv4 192.168.0.1 nexthop2 ipv4 192.168.0.2

20 permit ipv4 any any

What I would like is to send traffic to nexthop1 (192.168.0.1) under normal circumstances and send traffic to nexthop2 (192.168.0.2) only if nexthop1 becomes unavailable. Also, I would like the traffic to revert back to using nexthop1 once it is restored.

Using the above config, the access-list properly sends traffic to nexthop2 when nexthop1 becomes unavailable. It does not, however, revert back to usign nexthop1 once it becomes available again. When nexthop1 is restored, traffic continues to be sent to nexthop2.

Removing and re-applying the configuration forces it back to using nexthop1.

Is there anythign I need to change in order for it to revert back to using nexthop1 after it is restored? Is that supported?

Thanks in advance.

[xthuijs · Accepted solution]

As lame as it sounds, but you could make next hop 2 unavailable to make it switch back.

you require some sort of EOT in order to make it more dynamic.

Here is some more detail:

The current functionality of ABF considers whether the nexthop is “UP” based on CEF lookup (longest prefix match) results in a hit (excluding the default route).  This method has some shortcomings:

·         If nexthop is directly L3 connected but not at L2/L1 level. In this case the problem at L1 level may end up black holing the traffic. BFD (keep alive mechanism between two EFPs) can overcome this issue in Ethernet based deployment but put a requirement on other end device to support this.

·         Does not address a usage where user wants to restrict the nexthop path to be taken is directly connected to the nexthop (same subnet).

·         Does not address a usage where the nexthop chosen based on multiple criteria (requiring some logical operation and, or).

Object tracking module is also enhanced to introduce the third criteria (ipsla). This module will interact with IPSLA module to get reachability information. With IPSLA routers performs periodic measurements. Here we are interested in “ICMP Echo” operation.

Following is the proposed CLI syntax to achieve this:

[sequence number] permit [default] nexthop [track ] [track ] [track ]

The track keyword is optional. If this is not specified by the user then ABF will use FIB ECD in determining whether nexthop is “UP”. Otherwise it will use track state as well as FIB ECD state to determine whether nexthop is “UP”.

ABF CLI example

ipsla

operation 61

  type icmp echo

   source address x.x.x.x

   destination address y.y.y.y

   timeout 1000

   frequency 1

  !

!

schedule operation 1

  start-time now

  life forever

!

!

track 161

type rtr 61 reachability

delay up 5

delay down 30

!

ipv4 access-list abf

10 permit 10.0.0.0 255.255.255.0 any nexthop track 161 y.y.y.y z.z.z.z

Here tracker icmp is using ipsla 61 to determine the object state (“UP” or “DOWN”). IPSLA module sends the icmp echo to y.y.y.y via interface having ip address as x.x.x.x

at interval of 1 second. If the icmp reply is not received then tracker comes to know via polling method. Tracker starts the 30 second down timer before changing the state of object to “DOWN”. If ipsla timeout condition is removed then the down timer is stopped. After 30 second time is over than the object state is changed to “DOWN”. This is notified to ABF and marks the nexthop y.y.y.y to “DOWN” and selects a new nexthop. For nexthop z.z.z.z (there is no track for this nexthop) it uses FIB information to consider whether it is “UP” or not. When the track icmpstate changes to “UP” due to ipsla is able to receive icmp reply then ABF reverts back to y.y.y.y for redirecting the traffic.

xander

---

Xander Thuijs CCIE#6775

Principal Engineer ASR9000

[tcalvin2006]

Understood. Thanks for the quick reply, explanation, and proposed solution.

[ip_noc_fm]

Hi Alex,

I need some help for configuring ABF.

we have to bundle ether channel towards Juno Firewall & Secondary ASR chassis.

Config of the same mentioned below.

interface Bundle-Ether1

description *** Connected to FW1 ***

!

interface Bundle-Ether1.42 l2transport

encapsulation dot1q 42

rewrite ingress tag pop 1 symmetric

!

interface Bundle-Ether2

description *** Connected to ASR2 ***

!

interface Bundle-Ether2.42 l2transport

encapsulation dot1q 42

rewrite ingress tag pop 1 symmetric

one of Bundle member's config:

interface TenGigE0/0/0/0

description *** Connected to FW1 ***

bundle id 1 mode passive

!

Now Config of BVI Port:

interface BVI42

ipv4 address 10.168.36.42 255.255.255.248

l2vpn

bridge group VODAFONE

  bridge-domain VLAN42

   interface Bundle-Ether1.42

   !

   interface Bundle-Ether2.42

   !

   routed interface BVI42

  !

!

!

Now, For ABF, I have configured:

RP/0/RSP0/CPU0:MUMMLDEIG01#sh running-config ipv4 access-list CGNAT-PBR

ipv4 access-list CGNAT-PBR

10 permit ipv4 10.18.50.0/24 any nexthop1 ipv4 192.168.0.6

20 permit ipv4 any any

!

RP/0/RSP0/CPU0:MUMMLDEIG01#sh running-con interface Bundle-Ether1.42 l2transport

interface Bundle-Ether1.42 l2transport

ipv4 access-group CGNAT-PBR ingress                

encapsulation dot1q 42

rewrite ingress tag pop 1 symmetric

Issue:

Now how can we check whether the ABF is working or not? Is there any command to check in CLI ?

Thanks & Regards,

Soumik

[xthuijs]

Hi Soumik,

in a normal filtering scenario you can apply the ACL to the EFP's no problem.

However your ABF ACL can be applied to the BVI, which is an L3 interface.

Note however that acl's applied to the BVI are "replicated" to the EFP's in fact, but since this ABF acl requires

L3, which are not on your EFP's, you can only do this by attaching that abf acl to the bvi.

regards

xander

[ip_noc_fm]

Hi Xander,

Thanks for your quick response. Really appriciate.

We have implemented the same and it is working fine now.

Thanks for your support.

For any further query, I will get back to you.

Rgrds,

Soumik.