ABF on Cisco ASR9K with 5.3.3 SW seems to does't work

[mcagiola]

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.

[Aleksandar Vidakovic]

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

[mcagiola]

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

[Aleksandar Vidakovic]

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

[mcagiola]

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 ?

[Aleksandar Vidakovic]

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

[Aleksandar Vidakovic]

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.

[mcagiola]

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)

RP/0/RSP0/CPU0:9k10-RGA-512#sh cef vrf CUSTOMER_A exact-route 192.168.0.25 192.168.1.23 location 0/1/cPU0
Wed Jan 18 17:20:00.199 CET
0.0.0.0/0, version 0, proxy default, default route handler, drop adjacency, internal 0x1001011 0x0 (ptr 0x859ba864) [1], 0x0 (0x855aaa7c), 0x0 (0x0)
 Updated Jan 12 12:03:14.409
 Prefix Len 0, traffic index 0, precedence n/a, priority 15
   via NULLIFHNDL
   via 0.0.0.0/32, 13 dependencies, weight 0, class 0 [flags 0x0]
    path-idx 0 NHID 0x0 [0x847b8398 0x0]
    next hop 0.0.0.0/32
     drop adjacency

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

[Aleksandar Vidakovic · Accepted solution]

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