01-13-2017 02:57 AM
Hi Folks,
I'm facing on a issue that impact an ABF (ACL Based Forwarding) on a ASR9K.
The topology that I'm using is very simple, and is a l3vpn with only one VRF.
This is the ABF configured on:
ipv4 access-list abf-test1
10 permit ipv4 host 192.168.0.25 host 192.168.0.23 default nexthop1 vrf CUSTOMER_A ipv4 10.10.20.23
20 permit ipv4 any any
this acl is configured on the interface where the customer is attached:
interface TenGigE0/1/0/1
vrf CUSTOMER_A
ipv4 address 10.0.0.125 255.255.255.252
ipv4 access-group abf-test1 ingress
So when the customer send traffic to the address 192.168.0.23 from the 192.168.0.25 the results is that:
ASR903-4-525-AC302#traceroute 192.168.0.23 source 192.168.0.25
Type escape sequence to abort.
Tracing the route to 192.168.0.23
VRF info: (vrf in name/id, vrf out name/id)
1 10.0.0.125 0 msec 4 msec 0 msec
2 10.0.0.14 [MPLS: Labels 55/116 Exp 0] 0 msec 4 msec 0 msec
3 10.10.20.32 [MPLS: Label 116 Exp 0] 4 msec
10.10.10.32 [MPLS: Label 116 Exp 0] 0 msec
10.10.20.32 [MPLS: Label 116 Exp 0] 0 msec
4 10.10.20.23 4 msec * 4 msec
Tha ABF seems to not work!
The acl seems to work properly but the real traffic is not... steared on the nexthop1:
RP/0/RSP0/CPU0:9k10-RGA-512#sh access-lists abf-test1 hardware ingress locatio$
Fri Jan 13 10:47:06.887 CET
ipv4 access-list abf-test1
10 permit ipv4 host 192.168.0.25 host 192.168.0.23 (39685 hw matches) (default next-hop: addr=10.10.20.23, vrf name=CUSTOMER_A)
20 permit ipv4 any any (51 hw matches)
Please Help!
Marco.
Solved! Go to Solution.
01-19-2017 09:38 AM
hi Marco,
I'm glad to hear the ABF works now as you expected.
drop adjacency is expected in this case. When a specific prefix is not available in the routing table, CEF falls back to the default route 0.0.0.0/0, as you can see in the command output. If the default route 0.0.0.0/0 is not present in the routing table, it's expected to see a drop adjacency against this entry in the CEF table.
regards,
/Aleksandar
01-13-2017 04:34 AM
hi Marco,
this is somewhat difficult to triage without topology and the routing table entry for the destination prefix. One think I see is that the ABF configuration states that the first choice for the routing should be the default route. Are you sure this is the action you wanted to take? Also, since the interface where ABF is applied is already in vrf customer_a, you don't have to specify the same vrf in the abf configuration. You only have to specify the vrf if you want to leak the traffic to another vrf.
See this doc for more on ABF: https://supportforums.cisco.com/document/145271/abf-acl-based-forwarding-asr9k.
hope this helps,
/Aleksandar
01-13-2017 06:47 AM
Hi Aleks, thanks for your answer, here the topology that I'm using (in attachment).
Now it seems to work, the acl now is that:
RP/0/RSP0/CPU0:9k10-RGA-512#sh run ipv4 access-list abf-test1
Fri Jan 13 15:39:12.118 CET
ipv4 access-list abf-test1
10 permit ipv4 host 192.168.0.25 host 192.168.1.23 nexthop1 vrf CUSTOMER_A ipv4 10.10.20.23
20 permit ipv4 any any
The counters are good:
RP/0/RSP0/CPU0:9k10-RGA-512# sh access-lists abf-test1 hardware ingress location 0/1/cPU0
Fri Jan 13 15:45:42.948 CET
ipv4 access-list abf-test1
10 permit ipv4 host 192.168.0.25 host 192.168.1.23 (3182 hw matches) (next-hop: addr=10.10.20.23, vrf name=CUSTOMER_A)
20 permit ipv4 any any (352 hw matches)
Even if the traceroute is not right, because it indicate on the entry 3 the next hop that we don't want to use (We want to use 10.10.20.32);
ASR903-4-525#traceroute 192.168.1.23 source 192.168.0.25
Type escape sequence to abort.
Tracing the route to 192.168.1.23
VRF info: (vrf in name/id, vrf out name/id)
1 10.0.0.125 0 msec 4 msec 0 msec
2 10.0.0.14 [MPLS: Labels 55/152 Exp 0] 0 msec 0 msec 0 msec
3 10.10.10.32 0 msec 0 msec 4 msec
4 10.10.10.23 4 msec
10.10.20.23 4 msec *
The counters on the interfaces on the remote PE indicate that the traffic path is correct:
(Remote PE)
7606-4-532-RF#sh ip int bri | in 2/6
GigabitEthernet2/6 10.10.10.32 YES manual up up
7606-4-532-RF#sh ip int bri | in 2/7
GigabitEthernet2/7 10.10.20.32 YES manual up up
7606-4-532-RF#sh int gi 2/7 | in out
input flow-control is off, output flow-control is off
ARP type: ARPA, ARP Timeout 04:00:00
Last input 00:00:08, output 00:00:01, output hang never
Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0
5 minute output rate 1000 bits/sec, 2 packets/sec
L3 out Switched: ucast: 390 pkt, 46020 bytes mcast: 0 pkt, 0 bytes
444 packets output, 53027 bytes, 0 underruns
0 output errors, 0 collisions, 1 interface resets
0 lost carrier, 0 no carrier, 0 pause output
0 output buffer failures, 0 output buffers swapped out
!
7606-4-532-RF#sh int gi 2/6 | in out
input flow-control is off, output flow-control is off
ARP type: ARPA, ARP Timeout 04:00:00
Last input 00:00:09, output 00:00:03, output hang never
Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0
5 minute output rate 0 bits/sec, 0 packets/sec
L3 out Switched: ucast: 100 pkt, 11800 bytes mcast: 0 pkt, 0 bytes
119 packets output, 14207 bytes, 0 underruns
0 output errors, 0 collisions, 0 interface resets
0 lost carrier, 0 no carrier, 0 pause output
0 output buffer failures, 0 output buffers swapped out
Any advice on that?
Thanks for your help!
Marco
01-16-2017 09:23 AM
hi Marco,
your diagram implies that both 10.10.10.32 and 10.10.20.32 are behind the same remote PE. Is this correct?
/Aleksandar
01-17-2017 12:38 AM
Yes is correct. The PE on the right advertise both networks to the other PE (ASR9K-512):
This is the vpnv4 table of the PE on the right:
7606-4-532-RF#sh bgp vpnv4 unicast all
BGP table version is 86, local router ID is 192.168.0.32
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale, m multipath, b backup-path, x best-external, f RT-Filter, a additional-path
Origin codes: i - IGP, e - EGP, ? - incomplete
Network Next Hop Metric LocPrf Weight Path
Route Distinguisher: 100:100 (default for vrf CUSTOMER_A)
*>i10.0.0.124/30 192.168.0.12 0 100 0 ?
*> 10.10.10.0/24 0.0.0.0 0 32768 ?
*> 10.10.20.0/24 0.0.0.0 0 32768 ?
*>i192.168.0.25/32 192.168.0.12 2 100 0 ?
*> 192.168.1.23/32 10.10.10.23 2 32768 ?
01-17-2017 06:21 AM
In that case ABF on ASR9K-512 is not sufficient to do the trick because the result of the ABF on ASR9K-512 is that the packets are sent towards 7606-4-532-RF, but there is no way that the ASR9K-512 can influence the forwarding decision on 7606-4-532-RF.
One way to make this work would be static MPLS label allocation.
Another is to evaluate the feasibility of per-CE label allocation mode on 7606-4-532-RF. This is how you would configure it on IOS XR:
router bgp 1
vrf VRF1
address-family ipv4 unicast
label mode per-ce
01-17-2017 06:24 AM
actually, with per-prefix mode it should work as well because the label that ASR9K-512 imposes must correspond to 10.10.20.23. You should be able to verify on 7606-4-532-RF which label was imposed by ASR9K-512. You can use the 'elam' capture on 7606-4-532-RF for that purpose.
01-19-2017 07:41 AM
Hi Aleks, yesterday we did some other tests and now the ABF works: the main difference from the scenario that I shared with you is that, the destination customer's network (192.168.1.23) is not advertised by BGP anymore, so the ABF is actually used.
I have one more question for you:
Looking the follow issue, on the ingress PE (ASR9K) we noted DROP ADJACENCY on the FIB Table for the customer's destination (192.168.1.23)
Is that the expected behavior? Because the PE1 (ASR9K) doesn't have a route for the destination in routing table, but now is using the ABF.
Thanks for your support.
Marco
01-19-2017 09:38 AM
hi Marco,
I'm glad to hear the ABF works now as you expected.
drop adjacency is expected in this case. When a specific prefix is not available in the routing table, CEF falls back to the default route 0.0.0.0/0, as you can see in the command output. If the default route 0.0.0.0/0 is not present in the routing table, it's expected to see a drop adjacency against this entry in the CEF table.
regards,
/Aleksandar
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