02-04-2013 02:51 PM
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.
Solved! Go to Solution.
02-04-2013 06:37 PM
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
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
02-04-2013 06:37 PM
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
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
02-06-2013 05:56 AM
Understood. Thanks for the quick reply, explanation, and proposed solution.
05-30-2013 09:09 AM
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
05-30-2013 10:02 AM
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
06-03-2013 12:14 AM
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.
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide