Cisco Support Community
cancel
Showing results for 
Search instead for 
Did you mean: 

ASR9000/XR ABF (ACL Based Forwarding)

 

Introduction

 

In today’s high performance internetworks, organizations need the freedom to implement packet forwarding and routing according to their own defined polices in a way that goes beyond traditional routing protocol concerns. In XR platform this is achieved by using ACL Based Forwarding (ABF). ABF is a subset of PBR (Policy Based Routing) infrastructure in the XR platform. In summary this features allows traffic matching specific ACL rule to be forwarded to user specified nexthop instead of route selected by a routing protocol.  ASR9K supports ABF v4 and ABF v6 for forwarding IPv4 and IPv6 traffic respectively using ABF rules. Note that ABF is an ingress only feature, i.e., traffic matching ingress ACL can be forwarded using ABF.

 

The Benefits of ACL Based Forwarding

 

  • Source-Based Transit Provider Selection – Internet service providers and other organizations can use ABF to route traffic originating from different sets of users through different internet connections across the policy routers.
  • Cost Savings – Organizations can achieve cost savings by distributing interactive and batch traffic among low-bandwidth, low-cost permanent paths and high-bandwidth, high-cost, switched paths.
  • Load Sharing – In addition to the dynamic load-sharing capabilities offered by destination-based routing that the Cisco IOS-XR software provides network manager can implement policies to distribute traffic among multiple paths based on the traffic characteristics.

ABF Configuration

 

In XR platforms ABF is supported using ACL infrastructure. Enhancements are done to allow specification of ABF nexthop in the ACE rule. There are different variants of specifying ABF nexthop in a ACE. Following illustrates different options for specifying ABF nexthops.

 

ABF Nexthop:

We can specify list of specified IP addresses (up to 3 IP addresses will be supported for ABF along with VRF) in the ACE rule. In this case each nexthop IP address can specify the next hop router in the path towards the destination to which the packets must be forwarded. The first IP address associated with a currently “up” connected interface will be used to route the packets. Following is the example

ABFv4 Example :

 

ipv4 access-list abf-1

10 permit ipv4 any 100.100.100.0/24 nexthop1 VRF RED ipv4 1.1.1.1 nexthop2 VRF BLUE ipv4 2.2.2.2 nexthop3 ipv4 3.3.3.3

 

ABFv6 Example :

 

Ipv6 access-list abf-2

10 permit ipv4 any 2010::1/64 nexthop1 VRF A ipv6 2020::1 nexthop2 VRF B ipv6 2030::1 nexthop3 VRF C ipv6 2040::1

 

In the above example, there are 3 nexthops specified in the ACE rule. nexthop1 has the highest priority and nexthop3 has the lowest priority. if nexthop1 is reachable, i.e, there exist a route for the nexthop1 then it will be selected for forwarding the traffic matching the ACE. Nexthop2 is only selected if nexthop 1 is not reachable, i.e., there is no route present for the nexthop1 and nexthop2 is reachable, i.e., nexthop2 has a route and so on.

 

ABF Default Route

 

List of default IP addresses (up to 3 IP addresses will be supported for ABF) – IP address can specify the next hop router in the path towards the destination to which the packets must be forwarded, if there is no explicit route for the destination address of the packet in the routing table. The packet DA lookup should result in default-route. Under this condition ABF will be used to select the nexthop. The first IP address associated with a currently “up” connected interface will be used to route the packets. Following is the example for the same.  Please note “default” keyword in the ACE rule.

 

           ABFv4 Example:

 

     ipv4 access-list abf-1      

10 permit ipv4 any 100.100.100.0/24 default nexthop1 VRF RED ipv4 1.1.1.1 nexthop2 VRF BLUE 2.2.2.2 nexthop3 VRF GREEN 3.3.3.3

 

           ABFv6 Example:

 

           ipv6 access-list abf-2

     10 permit ipv4 any 2010::1/64 default nexthop1 VRF A ipv6 2020::1

 

In the above example if matching traffic does not have any route present for the packet DA and it has only default route, in that case ABF nexthop1 is selected for forwarding. If None of the  ABF nexthops are UP then packet is routed using  default route as expected. Note that if Packet DA has route learnt by routing protocol in that case ABF default Nexthop are not selected, instead packet is forwarded using route for packet DA and incoming interface VRF. Lets illustrate this with an example:

 

In the above example for ABFv4, lets says incoming packet DA is 100.100.100.100

 

  • If 100.100.100.100 lookup results in default path, then ABF nexthop is selected in the order of priority when UP, where nexthop1 has highest priority and nexthop3 has lowest priority.

 

  • If 100.100.100.100 has a non-default route, then packet will be forwarded using packet DA lookup, ABF path is not taken in this case.

 

 

  • If 100.100.100.100 has default route and none of the ABF nexthops are UP then packet will be forwarded to the default route.

 

ABF VRF select

 

This allows to specify only nexthop VRF instead of specific IP address for the nexthop. With this packet DA lookup will be performed in the ABF Nexthop VRF. If route is present then packet is forwarded otherwise dropped. This allows packet arriving on ingrsss VRF to get routed on egress interface which is in different VRF.

 

ABFv4 VRF select Example: Ingress vrf BLUE , Egress vrf RED

 

     ipv4 access-list abf-1  

     10 permit ipv4 any 100.100.100.0/24 nexthop1 VRF RED

 

Int Ten Gig 0/1/0/0

Vrf BLUE

Ipv4 addres 30.30.30.1/24

ipv4 access-list abf-1 ingress

 

In this case packet arriving in VRF BLUE will be forwarded to nexthop in VRF RED. Note that, VRF select feature can be used to send packet arriving on default VRF ton non-default VRF nexthop. Similarly, packet arriving on non-default VRF interface can be forwarded to nexthop in default VRF. Please see following example

 

Example: Ingress vrf BLUE, and egress vrf DEFAULT.

 

ipv4 access-list abf-default

10 permit ipv4 any 100.100.100.0/24 nexthop1  

 

Int Ten Gig 0/1/0/0

vrf BLUE

Ipv4 addres 30.30.30.1/24

ipv4 access-list abf-default ingress

 

In the above case, packet arriving on VRF BLUE will be forwarded to nexthop in default route. Packet DA lookup will be performed in the default vrf table for forwarding.

ABF with track option

 

Track option in ABF enables track object to be specified along with nexthop VRF and IP address. Status of track object is used along with reachability of the ABF Nexthop to determine if corresponding nexthop should be selected or not for forwarding.  At present ABFv4 is supported with track option. ABFv6 track option will be supported from 5.1.0 release onwards.

 

The following simple topology will be used to show this interaction:

 

Untitled.png

 

Description

 

From the above diagram the requirement is to have traffic coming into the RED interfaces/VLANs/VRFs on A9K-PE1 to be forwarded with ABF to IGW1, if IGW1 is to fail or not become reachable, the traffic should then get forwarded to IGW2, the same requirement is present on A9K-PE2. There might be multiple Internet gateways in this network, so it’s important to associate each PE with the primary and secondary IGW. In the examples below we will use the loopback addresses of the IGWs, equally one can use any IP address on the GW. It some designs it might be more suitable to use the IP address of the internet facing interface.

 

Solution

 

 

 

Configuring IPSLA

 

Pre-requisite for IPSLA is the MGBL pie, without this pie the IPSLA CLI will not be available, this is only required on the PEs, as the IGW is acting as a responder. Step one is to configure IPSLA tracking towards the IGWs from the PEs, this is an example from A9K-PE1.

 

RP/0/RSP0/CPU0:A9K-PE1#sh run ipsla

 

Thu Mar 28 21:54:21.934 UTC

 

ipsla

 

operation 1

 

type icmp echo

 

   destination address 10.10.10.10

 

   frequency 5

 

!

 

!

 

operation 2

 

type icmp echo

 

   destination address 10.20.20.20

 

   frequency 5

 

!

 

!

 

reaction operation 1

 

react timeout

 

   action logging

 

!

 

!

 

reaction operation 2

 

react timeout

 

action logging

 

!

 

!

 

schedule operation 1

 

start-time now

 

life forever

 

!

 

schedule operation 2

 

start-time now

 

life forever

 

!

 

!

 

 

 

RP/0/RSP0/CPU0:A9K-PE1#

 

 

 

Verify the IPSLA operation with show ipsla statistics

 

 

 

RP/0/RSP0/CPU0:A9K-PE1#show ipsla statistics

 

Thu Mar 28 21:54:53.052 UTC

 

Entry number: 1

 

   Modification time: 21:19:42.937 UTC Thu Mar 28 2013

 

   Start time       : 21:16:55.158 UTC Thu Mar 28 2013

 

   Number of operations attempted: 456

 

   Number of operations skipped : 0

 

   Current seconds left in Life : Forever

 

   Operational state of entry   : Active

 

   Operational frequency(seconds): 5

 

   Connection loss occurred     : FALSE

 

   Timeout occurred             : FALSE

 

   Latest RTT (milliseconds)     : 2

 

   Latest operation start time   : 21:54:50.367 UTC Thu Mar 28 2013

 

   Next operation start time     : 21:54:55.367 UTC Thu Mar 28 2013

 

   Latest operation return code : OK

 

   RTT Values:

 

     RTTAvg : 2         RTTMin: 2         RTTMax : 2        

 

     NumOfRTT: 1         RTTSum: 2         RTTSum2: 4

 

 

 

Entry number: 2

 

   Modification time: 21:46:26.132 UTC Thu Mar 28 2013

 

   Start time       : 21:46:26.116 UTC Thu Mar 28 2013

 

   Number of operations attempted: 102

 

   Number of operations skipped : 0

 

   Current seconds left in Life : Forever

 

   Operational state of entry   : Active

 

   Operational frequency(seconds): 5

 

   Connection loss occurred     : FALSE

 

   Timeout occurred             : FALSE

 

   Latest RTT (milliseconds)     : 5

 

   Latest operation start time   : 21:54:51.325 UTC Thu Mar 28 2013

 

   Next operation start time     : 21:54:56.325 UTC Thu Mar 28 2013

 

   Latest operation return code : OK

 

   RTT Values:

 

     RTTAvg : 5         RTTMin: 5         RTTMax : 5        

 

     NumOfRTT: 1         RTTSum: 5         RTTSum2: 25

 

RP/0/RSP0/CPU0:A9K-PE1#

 

Configuring Tracking

 

 

 

The next step is to configure tracking , so to have IPSLA associated with the tracker. Tracked objects could be Line protocol, Routes, IPSLA reachability, lists etc.. In below configuration we are associating the above IPSLA operation 1 through rtr 1.

 

 

 

RP/0/RSP0/CPU0:A9K-PE1#sh run track

 

Thu Mar 28 21:33:44.466 UTC

 

track IGW1

 

type rtr 1 reachability

 

!

 

track IGW2

 

type rtr 2 reachability

 

!

 

 

 

RP/0/RSP0/CPU0:A9K-PE1#

 

 

 

Verify the track operation status:

 

 

 

RP/0/RSP0/CPU0:A9K-PE1#show track brief

 

Thu Mar 28 21:55:53.004 UTC

 

Track                           Object                                   Parameter       Value              

 

--------------------------------------------------------------------------------------------------------

 

IGW2                             IPSLA Operation 2                         reachability     Up  

 

IGW1                             IPSLA Operation 1                         reachability     Up  

 

RP/0/RSP0/CPU0:A9K-PE1#

 

Configuring ABF on IOS XR

 

 

 

The next step is to associate the Tracker with the ABF statement; it’s done through the standard ABF CLI. The nexthop ip address does not need to be the same as the tracked ip address, as showing in this example.

 

 

 

RP/0/RSP0/CPU0:A9K-PE1#sh run ipv4 access-list

 

Thu Mar 28 21:50:23.672 UTC

 

ipv4 access-list ABF_IGW

 

10 permit ipv4 any any nexthop1 track IGW1 ipv4 10.10.10.1 nexthop2 track IGW2 ipv4 10.20.20.2

 

!

 

Bind the ABF statement to an ingress interface.

 

 

 

RP/0/RSP0/CPU0:A9K-PE1#sh run int bundle-e1

 

Thu Mar 28 21:50:28.751 UTC

 

interface Bundle-Ether1.100

 

ipv4 address 192.168.100.1 255.255.255.0

 

ipv4 access-group ABF_IGW ingress

 

!

 

 

 

RP/0/RSP0/CPU0:A9K-PE1#

 

Notes, the above configuration can be applied to an interface in a VRF or a global routing table.

 

 

Null0 to drop traffic

 

The  current functionality of ABF does not allow us to use recursive static routes to blackhole traffic locally. In the example given below  if nexthop1 fails the suitability criteria then packet is forwarded  based on the DA (normal forwarding) rather than using the recursive  route pointing to null.

 

RP/0/RSP0/CPU0:asr9010-e11-1#sh access-list ABF-TEST

ipv4 access-list ABF-TEST

10 permit ipv4 host 109.159.249.66 host 10.10.10.10 nexthop1 ipv4 109.159.249.74 track NH1 nexthop2 ipv4 169.254.0.254

20 permit ipv4 any any

RP/0/RSP0/CPU0:asr9010-e11-1#

 

RP/0/RSP0/CPU0:asr9010-e11-1#sh route 169.254.0.254

Routing entry for 169.254.0.254/32

  Known via "static", distance 1, metric 0 (connected)

  Installed Oct 10 13:28:57.613 for 01:35:15

  Routing Descriptor Blocks

    directly connected, via Null0

      Route metric is 0

  No advertising protos.

 

RP/0/RSP0/CPU0:asr9010-e11-1#sh track

Track NH1

        Response Time Reporter 61 reachability

        7 changes, last change 14:57:09 BST Thu Oct 10 2013

        Latest operation return code: TimeOut

        Latest RTT (millisecs) : 0

 

RP/0/RSP0/CPU0:asr9010-e11-1#sh access-lists ABF-TEST hardware ingress location 0/0/CPU0

ipv4 access-list ABF-TEST

10 permit ipv4 host 109.159.249.66 host 10.10.10.10 (50 hw matches)

20 permit ipv4 any any (23559 hw matches)

 

A  possible workaround for this is to set a next hop VRF instead of  specific IP address and configure fixed default route (or destination  prefix itself) pointing to null0 within that VRF.

 

ipv4 access-list ABF-TEST

10 permit ipv4 host 109.159.249.66 host 10.10.10.10 nexthop1 ipv4 109.159.249.74 track NH1 nexthop2 vrf DROP_VRF

!

router static

vrf DROP_VRF

address-family ipv4 unicast

  0.0.0.0/0 Null0

 

RP/0/RSP0/CPU0:asr9010-e11-1#sh track                                                     

Track NH1

        Response Time Reporter 61 reachability

        16 changes, last change 21:30:59 BST Thu Oct 10 2013

        Latest operation return code: TimeOut

        Latest RTT (millisecs) : 0

 

RP/0/RSP0/CPU0:asr9010-e11-1#sh access-lists ABF-TEST hardware ingress location 0/0/CPU0  

ipv4 access-list ABF-TEST

10 permit ipv4 host 109.159.249.66 host 10.10.10.10 (20 hw matches) (next-hop: addr=0.0.0.0, vrf name=DROP_VRF)

20 permit ipv4 any any (146412 hw matches)

RP/0/RSP0/CPU0:asr9010-e11-1#

 

ABF Support Matrix

 

 

Following provide the support matrix for ABF IPv4 and ABF IPv6 on different linecards on the ASR9k platform. Classification is done based on combination  of different interface types on ingress and egress linecards for ABFv4 and ABFv6. Aforementioned, ABF is ingress only feature, i.e., ABF rule is always applied on the ingress interface. TCAM resources are only allocated on line ingress cards where ABF is configured which is used for classification of incoming traffic. For virtual interface such as GRE TCAM resources will be allocated on all LCs where virtual interface is present.  In the following figure ingress LC determines that packet will be routed using ABF rule. Packet will be sent to egress LC with ABF type in the fabric header, which will be used by Egress LC to route packet based on ABF nexthop instead of packet DA. As a result both ingress and egress LCs need to be aware of the ABF feature that can be supported on a particular LC.

 

Line Cards Support

 

ABFv4 is supported on   Ethernet, Enhanced Ethernet, and SIP-700 Linecards. ABFv6 is supported only on Enhanced Ethernet and SIP-700. Following support matrix provide the different combinations of ingress and egress LCs that can be supported for ABFv4 and ABFv6 with different interface types.

  • Ethernet: ETH
  • Enhanced Ethernet: E-ETH
  • SIP-700: SI

 

 

Untitled1.png

 

Untitled3.png

 

Ethernet as Ingress LC

ABFv4

 

abfv4.jpg

 

 

ABFv6

Untitled5.png

 

SIP-700 as Ingress LC

ABFv4

 

Untitled6.png

 

ABFv6

 

Untitled7.png

 

Scale Support

 

We have tested 1000 unique ABF nexthop (IPv4 and IPv6 combined). Note that this does not include duplicate nexthops, we can use same nexthops across multiple ACLs, ACEs and it will be counted once towards the supported scale. System does not enforce this limitation through configuration, user can configure more than 1000 unique nexthops but any such use-case should be tested thoroughly by the customer before the deployment.

Load Balancing

 

If ABF nexthop has multiple ECMP path then multiple streams matching the corresponding ACE rule will get load balanced across the ECMP paths. The raw-hash will be computed on the ingress LC based on the incoming packet and that will be used to select the outgoing path for the ABF nexthop like regular IPv4 or IPv6 forwarding. This will ensure that all the packets from a given stream will always take the same path when packet is routed using ABF. As a result for multiple streams using same ABF nexthop we should expect to see load balancing across multiple ECMP paths.  Figure 2 shows load balancing for 3 incoming streams matching same ACE rule with ABF nexthop.

 

Untitled8.png

 

Troubleshooting

 

Verify ABF is programmed correctly in the hardware.

 

RP/0/RSP0/CPU0:ios#show access-lists ipv4 abf-1 hardware ingress location 0/1/cpu0

Mon May 13 06:06:58.609 UTC

ipv4 access-list abf-1

10 permit ipv4 any 20.20.20.20 (next-hop: addr=40.40.40.2, vrf name=default)

If nexthop is programmed in the hardware then verify that nexthop is resolved, you can confirm that by pinging nexthop.

Verify that traffic is matching the ACL for which ABF rule need to be applied.

 

ABF rule is applied if the traffic matches corresponding ACE entry

RP/0/RSP0/CPU0:ios#show access-lists ipv4 abf-perf-1 hardware ingress location$

Mon May 13 06:12:16.203 UTC

ipv4 access-list abf-perf-1

10 permit ipv4 any 20.20.20.20 (294096734 hw matches) (next-hop: addr=40.40.40.2, vrf name=default)

Note that if incoming traffic is IPv4 or IPv6 then that will be only matched with ACL rules. However, if incoming traffic is labeled traffic then that traffic won’t match ACL rules and hence no ABF forwarding will take place for that scenario.

  • Verify that Ingress and Egress interface and line card are supported as per support matrix given in Section 2

 

For e.g. ABFv6 is not supported on Ethernet Linecard. Ingress and Egress cannot be Ethernet LC for ABF v6.

 

  • Verify that ABF NH is pingable and is in resolved state.

 

If ABF is programmed correctly in the hardware and traffic is also matching the ACE. Verify that ABF NH is in resolved state. Confirm that you are able to ping ABF nexthop which is programmed

in the hardware.

 

  • Verify path using traceroute

 

Traceroute can be used to determine the end-to-end path taken by the packet stream. If ABF match happen for the traceroute probe packet then you should expect to see ABF nexthop in the traceroute output.

 

Author: Tarun Banka

Comments
New Member

Hi

I would like to understand the part of LoadBalancing with ABF as it is not very clear, when I setup an ACL with match condition and multiple NH1 , NH2 , it will not do ECMP between them!?

Example:

ipv4 access-list TEST-ABF

10 permit tcp any any eq www nexthop1 ipv4 30.239.241.6 nexthop2 ipv4 11.81.54.81

20 permit ipv4 any any

Result:

Wed Oct  9 10:46:42.962 GMT

ipv4 access-list TEST-ABF

10 permit tcp any any eq www (next-hop: addr=30.239.241.6, vrf name=default)

20 permit ipv4 any any

RP/0/RP1/CPU0:CRS#

I can tweek the ACL to have multiple match conditions to make some sort of ECMP or I can see nexthop that is resolved by 3 or more nexthops

Am I missing somthing here?

Cisco Employee

Hello,

ABF nexthop has its priority and cannot be load-balanced, in your case ECMP. The load-balancing part in this document is the load balance of one ABF nexthop. If NH1 is up and it has multiple path same cost (ECMP) to reach NH1, then packet will be forwarded toward NH1 in load-balanced scheme. So, load balance is not between NH of ABF, but within the particular NH.

HTH,

Rivalino

New Member

Hi, Tarun:

 

A quick question about ABF. Say you have an MPLS network with a bunch of P-routers in between PE-routers.

Say at some point in the network, before I get to an exit PE-router, I need to catch some traffic and re-route it vía ABF statically. I would have to apply ABF on a P-router interface. Is this supported? That is, is a router able to 'catch' mpls-tagged traffic and re-route it via ABF to an exit NH or interface?

Are there any restrictions?

 

Thanks,

c.

Cisco Employee

Hi Carlos,

 

ABF is not supported for incoming labelled/MPLS packets.

 

thanks,

rivalino

New Member

Hi, Rivalino:

 

I wonder if you could comment on the following captures. NPE01 is the router where traffic initiantes and P-03 is the P router next to it. As you can see, traffic for a specific network is set to leave NPE01 labeled (19723/19734). P router is configured to catch it and actually (at least that's what i can tell) does.

 

RP/0/RSP0/CPU0:NPE01#show mpls forwarding prefix 148.X.Y.0/29
Thu May  1 16:12:08.503 CST
Local  Outgoing    Prefix             Outgoing     Next Hop        Bytes       
Label  Label       or ID              Interface                    Switched    
------ ----------- ------------------ ------------ --------------- ------------
18825  19723       148.X.Y.0/29   BE1          148.A.B.37  0           
       19734       148.X.Y.0/29   BE2          148.A.B.33  0           
RP/0/RSP0/CPU0:NPE01#

RP/0/RSP0/CPU0:P-03#show access-lists ABF-IPTV hardware ingress location 0/0/CPU0 | i 148.X.Y.0
Thu May  1 08:17:40.901 CST
 190 permit ipv4 10.85.128.0 0.0.31.255 148.X.Y.0 0.0.0.255 (709 hw matches) (next-hop: addr=148.A.B.45, vrf name=default)
 200 permit ipv4 10.85.160.0 0.0.31.255 148.X.Y.0 0.0.0.255 (135 hw matches) (next-hop: addr=148.A.B.45, vrf name=default)
 210 permit ipv4 10.83.128.0 0.0.31.255 148.X.Y.0 0.0.0.255 (next-hop: addr=148.A.B.45, vrf name=default)
RP/0/RSP0/CPU0:P-03#

 

Am i reading this right?

 

Thanks,

c.

 

 

 

Cisco Employee

There is known issue where hardware counter of ACL matches with ingress mpls packets. However, the packets is not forwarded according to ABF. I guess that is the case in your scenario, that the traffic is not forwarded to next hop by ABF, but the ACL shows matches. 

 

rivalino

New Member

Hi Tarun, a question regarding the vrf select feature in ABF, does it works in mpls vpn scenarios? I mean, the next hop in a vrf could be an interface in a remote PE?

Thanks,

Mario

Cisco Employee

Mario,

With VRF select ABF, you can only select the next hop VRF, not a next hop address in the VRF. So you vector the packet to that VRF, the routing inside that VRF will then have to forward the packet based on the best forwarding decision. 

Regards

Eddie. 

New Member

Thanks Eddie,

I got confused with this "This allows packet arriving on ingress VRF to get routed on egress interface which is in different VRF. ".

So, just to be sure, according to your comments vrf select should works with MPLS VRF, am I correct?

Mario

Cisco Employee

Yes it will work with MPLS VPN. 

Cisco Employee

Eddie,

In case of VRF select with redundancy in a remote PE (with multiple nexthops and VRFs in the entry), is the nexthop ip address used only to check the availability of the nexthop in the VRF routing table?

Regards,

Gonzalo

Cisco Employee

As you can see with the VRF select the next hop is a VRF name.

New Member

Hi Eddie, in vrf select can we use a different vrf as a nexthop2?

For example,

  ipv4 access-list abf-1  

     10 permit ipv4 any 100.100.100.0/24 nexthop1 VRF RED nexthop2 VRF BLUE

Thanks

Mario

Cisco Employee

I haven't tried it, but it should work as you posted.

Eddie.

New Member

Thanks Eddie,

Suppose I have,

ipv4 access-list abf-1  

     10 permit ipv4 100.100.100.0/24 any nexthop1 VRF RED nexthop2 VRF BLUE

what is the trigger to take VRF BLUE routing table as an option?

NH2 should be taken in case there is not a default route in VRF RED?

Thanks again

Cisco Employee

It would have to be an address like this:

10 permit ipv4 100.100.100.0/24 any nexthop1 vrf red ipv4 1.1.1.1 nexthop2 vhf blue ipv4 2.2.2.2

You'll have to try if it works. 

Regards

Eddie. 

New Member

Dear all,

I want to configure an ABF in an ingress interface such this:

interface Bundle-Ether100
mtu 9114
load-interval 30
!

interface Bundle-Ether100.7381361 l2transport
encapsulation dot1q 1361 second-dot1q 532
rewrite ingress tag pop 2 symmetric

The next-hop eggress interface would be an standard L3 Bundle-ether interface

Regarding the above qinq, is this piece of configuration  in combination with ABF supported an Trident-based linecard. Can you help me please?

Regards

Eduard

Cisco Employee

Hi Eduard,

ABF is not supported on L2VPN Interface, as there is no RT associated with the interface, you can put it on a BVI if the L2 interface is terminated as BVI/IRB on the 9k. 

Eddie.

New Member

Thank you for your fast response Eddie,

In fact, the complete configuration is the following:

interface Bundle-Ether100
mtu 9114
load-interval 30
!

interface Bundle-Ether100.7381361 l2transport
encapsulation dot1q 1361 second-dot1q 532
rewrite ingress tag pop 2 symmetric

!

interface BVI532
vrf vrf-738
ipv4 address 10.13.32.1 255.255.255.0

!

l2vpn 

 bridge-domain vrf-738

     interface Bundle-Ether100.7381361

     routed interface BVI532

As you said before I would configure ABF in a BVI interface, however is ABF supported in a BVI interface assuming that I have a Trident NP Linecard?? If I undertood the above matrix I would say no, is it right?

Thanks in advance!

eduard

 

Cisco Employee

your correct its not supported with a Trident LC.

Eddie.

New Member

I would like to set up remotely triggered ABF.

Suppose I have a router connected to a "washing machine" server.  I do not know what the IP will be I need to clean in advance.  That /32 IP can be fed to me dynamically by BGP from another router with any community attached that I decide upon.  How can I setup my router such that the community string can be matched, which will trigger an ABF on that specific dynamic IP address to my "washing machine"?

Cisco Employee

hi Hank,

have you considered the 'standard' RTBH solution (http://www.cisco.com/c/en/us/support/docs/routers/asr-9000-series-aggregation-services-routers/116386-configure-asr9000-00.html)? It gives you the flexibility that you need and it's easy to set up. The challenge with the ABF approach that you are considering is that you can't match an ACE on a BGP community.

hth,

/Aleksandar

New Member

Thanks but that doesn't help me in my scenario.

-Hank

New Member

Probably you can use flowspec (rfc5575 if i recall correctly) for this purpose.

Asr9k should support flowspec since 5.2.

Bronze

Hi,

is it safe to use ABF on an interface with around 7-8 Gbps input traffic?

HW is Tomahawk.

Cisco Employee

hi Smail,

With that small traffic rate per Tomahawk NP, you shouldn't see any issues.

If traffic is clear IPv4, you will hardly notice the performance impact. In more complex scenarios (e.g. L3VPN), you can expect worst case scenario performance drop of ~50%.

hth,

/Aleksandar

Bronze

Thank you Aleks.

New Member

Hi,

In case a nexthop in the ACE is not reachable and no other nexthop is specified, will the traffic be dropped for that source/destination combination ?

 

For example:

 

ipv4 access-list abf-1

10 permit ipv4 host 1.1.1.1 host 2.2.2.2 nexthop1 track IGW1 ipv4 10.10.10.1

 

In case the tracker IGW1 fails, traffic from 1.1.1.1 to 2.2.2.2 is simply dropped ? Or does it fail over to Dynamic Routing ?

New Member

I am encountering an issue with ABF and VRF and I hope one of you can clear up the issue.

My network looks like this:

 

1.1.1.2 <----------ASR9K-------->2.2.2.2

On the ASR9K I have on the left interface defined 1.1.1.1 and on the right interface I have defined 2.2.2.1

 

vrf my_vrf

address-family ipv4 unicast

!

ipv4 access-list 101

   10 permit ipv4 host 1.1.1.2 any nexthop1 vrf my_vrf

   20 permit ipv4 any any

!

interface TenGigE0/5/0/3.100

     ipv4 address 1.1.1.1 255.255.255.0

     encapsulation dot1q 100

     ipv4 access-group 101 ingress

!

interface TenGigE0/5/0/3.200

   vrf my_vrf

   ipv4 address 2.2.2.1 255.255.255.0

   encapsulation dot1q 200

 

A ping packet from 1.1.1.2 to 2.2.2.2 was routed correctly to 2.2.2.2

 

But a ping from 1.1.1.2 to 2.2.2.1 disappears. Not only disappears but when running “debug punt-inject l3-packets icmpv4…” nothing appears. Could this be LPTS interference?

Cisco Employee

hi Hank,

as the new user interface doesn't allow a reply on a comment, this is in response to your comment from "10-19-2017 10:06 AM".

I don't think that pinging a local IP address will work this way. To understand what really happened, can you run the pings with timeout zero and see which NP counter on the ingress NP matches the pings.

/Aleks

Cisco Employee

hi Khaled,

as the new user interface doesn't allow a reply on a comment, this is in response to your comment from "09-19-2017 01:40 PM".

Your expectation is correct. If none of the next-hop address is “UP”, packets go through the standard routing path based on destination address.  

/Aleks

New Member

Aleks wrote: I don't think that pinging a local IP address will work this way. To understand what really happened, can you run the pings with timeout zero and see which NP counter on the ingress NP matches the pings.

 

I ran pings with timeout=0 and what I saw with

show cef ipv4 drops location

was that “No route drops” was the only counter incrementing.

 

I also checked

show controller np counters

for the ingress NP and found the following fields incrementing continuously based on the number of ping pkts:

PARSE_ENET_RECEIVE_CNT

PARSE_LOOPBACK_RECEIVE_CNT

PARSE_SVC_LPBK_RECEIVE_CNT

PARSE_ABF_LPBK_RECEIVE_CNT

RESOLVE_INGRESS_DROP_CNT

MODIFY_SVC_LOOPBACK_CNT

RESOLVE_INGRESS_L3_PUNT_CNT

IPV4_PLU_DROP_PKT

 

In addition for every 10 increase in the counters logged above, the following two counters increased by one:

PARSE_INGRESS_DROP_CNT

UNKNOWN_L2_ON_L3_DISCARD

 

Thanks,

Hank

Cisco Employee

hi Hank,

 

yes, the "RESOLVE_INGRESS_DROP_CNT" indicates that the NP (happens to be Trident in this case) couldn't resolve the destination. I did some verification in the background and confirmed that ABF is not supported for for-us packets.

/Aleks

New Member

Thanks Aleks.  This just proves the value of this forum which gives us insight to features that are not documented.

 

Regards,

Hank

Cisco Employee

hi Hank,

that goal is not exactly what we had in mind when we started the forum. ;) I will take the neccessary steps to update the configuration guide on CCO.

/Aleks

18726
Views
19
Helpful
35
Comments