PBR NOT WORKING ON ASR920 IOS XE 16.09.04

[1980asanz]

I have a problem with the policy based routing (PBR) functionality on the ASR920 router. I'm starting to think the router has a problem because apparently I have the settings OK and also de TSHOOT is OK.

To start I have the license OK and the SDM TEMPLATE configured as "video":

EDC1#show sdm prefer current
The current sdm template is "video"

The source interface where I have the route-map configured is a tunnel interface and the next hop is the firewall:

EDC1#sh run intertunn1
interface Tunnel1
ip policy route-map PBR

I have an acl matching between private ranges (any any is not possible). This is:

Origin Class A - Destination A-B-C (three sentences)
Origin Class B - Destination A-B-C (three sentences)
Origin Class C - Destination A-B-C (three sentences)

The route-map is like this:

route-map PBR permit 10
match ip address 161
set ip next-hop 172.16.1.1

Now we go with the troubleshooting:

If I do a sh route-map, I see the packets increase:

EDC1#show route-map PBR
route-map PBR, permit, sequence 10
Match clauses:
ip address (access-lists): 161
Set clauses:
next-hop ip 172.16.1.1
Policy routing matches: 25 packets, 2100 bytes

I have even gone so far as to create an exclusive ACL to debug the packet at source and destination. And this is the result:

Aug 1 14:17:21.508 METDST: IP: s=192.168.19.65 (Tunnel1), d=192.168.99.1 (BDI905), len 84, input feature
Aug 1 14:17:21.508 METDST: ICMP type=8, code=0, Policy Routing(103), rtype 2, forus FALSE, sendself FALSE, mtu 0, fwdchk FALSE
Aug 1 14:17:21.509 METDST: IP: s=192.168.19.65 (Tunnel1), d=192.168.99.1 (BDI905), len 84, input feature
Aug 1 14:17:21.509 METDST: ICMP type=8, code=0, MCI Check(109), rtype 2, forus FALSE, sendself FALSE, mtu 0, fwdchk FALSE
Aug 1 14:17:21.509 METDST: IP: s=192.168.19.65 (Tunnel1), d=192.168.99.1 (BDI905), len 84, input feature
Aug 1 14:17:21.510 METDST: ICMP type=8, code=0, TCP Adjust MSS(111), rtype 2, forus FALSE, sendself FALSE, mtu 0, fwdchk FALSE
Aug 1 14:17:21.510 METDST: IP: s=192.168.19.65 (Tunnel1), d=192.168.99.1 (BDI905), g=172.16.1.1, len 84, forward
Aug 1 14:17:21.510 METDST: ICMP type=8, code=0

With all these tests it "seems" that the router is sending the packet to the next-hop as i configured. But not. Searching up on the FW, traffic is sending through the WAN interface to the destination host 192.168.99.1 in another location.

For more information, I have a scenario in HA with an ASR1001 router. If I apply THE SAME THE SAME IDENTICAL configuration in this ASR1001 router IT DOES WORK. There is something that does differ, which is this but that I DO NOT know how to understand:

EDC2#sh route-map PBR
route-map PBR, permit, sequence 10
Match clauses:
ip address (access-lists): 161
Set clauses:
next-hop ip 172.16.1.1
Nexthop tracking current: 172.16.1.1 ***ONLY ON ASR1001***
10.75.2.145, fib_nh:7F50604B5DA0,oce:7F506D68E460,status:1 ***ONLY ON ASR1001***

Thank you I hope you can help me find the solution.

Kind regards,

[MHM Cisco World]

set ip next-hop 172.16.1.1 recursive 

Add this word and check 

[1980asanz]

Tried and not working

[paul driver]

Hello
Do all the "Origin Class x"  originate from Tunnel, otherwise PBR will not work, as a test dont use any acl , just PBR all traffic off that interface

[1980asanz]

Hi,

Yes that's how it is. The scenario is:

ALL the traffic that comes from the tunnel interface (in EDC origin I also have PBR) has to be sent to the next hop by the FW. The PBR of this headquarters, headquarters "is easier" since it is simply EVERYTHING that comes from the tunnel interface to the FW.

Also tried with no match in route-map and still not working:

route-map PBR permit 10
set ip next-hop 172.16.1.1

So confused...

[Ramblin Tech]

Since the config works on the ASR1K but not on the ASR920, my first suspicion is the major forwarding difference between them: their NPUs, which are completely different.  The PBR policy is applied to int tun1, which I assume is GRE or some other encap on top of the native IP header. Both PBR and GRE feature support in platforms that forward in h/w (ie, NPUs) is entirely dependent on the capabilities of their NPUs, with the 920/RSP2 being far more limited than the ASR1K due to the deployment scenarios it is targeted for (SP access networks needing environmental hardening).

I do not see any restrictions noted in the 920's docs regarding support, or lack thereof, for PBR over GRE, but those kind of things don't always make it into the docs. PBR on the 920 requires the video SDM template to provide TCAM for it, which you have configured, but all SDM templates are tradeoffs: they rob one class of features of TCAM resources to enrich another. Perhaps there is a lack of TCAM resources to support PBR over GRE?  If you have the time, you might try PBR on the 920 using an interface with native IP encap, just to ensure that PBR works on the 920 for you. If it does, then the issue might be narrowed down to its application on a tunnel interface.

[1980asanz]

Hi,

Could be. Is one of possible causes i thought. But i can't change the interface. Must be int tunnel because is where the traffic comes (input) and frome this interface i have to apply PBR.

Sorry i did not understand this:

If you have the time, you might try PBR on the 920 using an interface with native IP encap, just to ensure that PBR works on the 920 for you. If it does, then the issue might be narrowed down to its application on a tunnel interface.

What do you mean? Do you mean to configure on interface tunn with native encap? Another interface?

Thanks anyway...

[1980asanz]

Hi guys,

I tried with this @Ramblin Tech:

The scenario is EDC1-EDC2-EDC3 are directly connected. EDC1-EDC2 vlan95 (tagged). EDC1-EDC3 vlan93 (tagged) (sorry for the picture looks like a baby working on it)

So, i did this:

1. Configure on EDC2 interface loopback999 - 2.2.2.2

* If i ping from EDC3 to EDC2 lo999 - 2.2.2.2 does not work. Is normal because 2.2.2.2 is not on route table on EDC3.

So:

2. Configure on EDC3 static route 2.2.2.2 towards EDC1 next-hop vlan93.

3. Configure on EDC1 on BDI903 policy route-map PBR and route-map PBR - set next-hop --> EDC2 vlan95.

* PING WORKS!

And also, to continue troubleshooting:

4. Configure inter tunnel10 between EDC1 and REMOTE EDC.

* If i ping from REMOTE EDC to EDC2 lo999 - 2.2.2.2 does not work. Is normal because 2.2.2.2 is not on route table on REMOTE EDC.

So:

5. Configure on EDC1 on inter tunn10, policy route-map PBR and route-map PBR - set nhop --> EDC2 vlan95.

* PING DOES NOT WORK!

Then, thinking that interface tunnel + PBR on Cisco ASR920 = NO WAY, but do not have the reason...

Any ideas?

[Ramblin Tech]

Previously, I looked for GRE limitations under the 920's PBR docs, but should have looked for PBR limitations under the GRE docs. Here is the unfortunate situation:

https://www.cisco.com/c/en/us/td/docs/routers/asr920/configuration/guide/iproute/17-1-1/b-gre-xe-17-1-asr920/m-gre-asr900.html#Cisco_Concept.dita_674c985f-7e6c-4148-b495-a41294f383f7

"Netflow and Policy-Based Routing (PBR) are not supported over the GRE tunnel."

This is almost certainly a limitation with support on the NPU, possibly due to a need for recirculation of the packet header because of the additional encap (GRE). Does that mean you are SOL if you must use both the 920 and a GRE tunnel? Not necessarily, if you can come up with a clever way to separate PBR from the tunnel interface. I have long thought that you can do darn near anything you want as long as you are willing to hang an external loopback cable on the front of your router and that might be the case here too. Just thinking out loud here and have definitely not thought this through... but can you L2 x-connect the GRE tunnel to a front panel port and loop that port (via a cable) back in a native IP interface where you apply the PBR? Back in the days of the Cisco 7600, people were often forced into thinking about harebrained schemes like that to overcome ASIC limitations.

Anyway... cleanest, least-ridiculous solution appears to be to eliminate of one of these three, as they are incompatible: ASR920, PBR, or GRE tunnel. Good luck!

[paul driver]

Hello

---

@1980asanz wrote:

@Ramblin Tech:

nfigure inter tunnel10 between EDC1 and REMOTE EDC.

* If i ping from REMOTE EDC to EDC2 lo999 - 2.2.2.2 does not work. Is normal because 2.2.2.2 is not on route table on REMOTE EDC.

5. Configure on EDC1 on inter tunn10, policy route-map PBR and route-map PBR - set nhop --> EDC2 vlan95.* PING DOES NOT WORK!

---

Is REMOTE EDC routing OVER the tunnel so EDC1 receives traffic from the tunnel where the PBR policy is applied, if not PBR wont work, and for the return traffic EDC1 needs know to route over the tunnel back towads REMOTE-EDC

[1980asanz]

Hi guys,

Thanks for the answer @Ramblin Tech.

As the router ASR920 makes impossible the scenario PBR+TUNNEL, i have an idea i would like to check tomorrow when i arrive at the office:

@MHM Cisco World said to configure the route-map adding the word recursive. I understand this word recursive to have the possibility to point to a host who is not directly connected. Am i right? Is that possible? Is possible to point as next-hop a host is not directly connected or even is in another router? Did i understand right the function of the word recursive @MHM Cisco World 

Because if this is possible i think i could solve this...

Thanks anyway guys.

Many many thanks anyway guys.