Hi guysNo probs - here you go

Leon Brierley · ‎07-13-2015

Hi all

I am trying to resolve an issue with some PBR on a Cisco 3850. Basically, i want to route internet traffic for one specific vlan to a new firewall

I have created a test SVI (vlan 888 - 10.77.88.254/24) and i am matching traffic with a souce IP of 10.77.88.0/24 (ip default next-hop - new firewall ip) All other SVIs should route via the old firewall and the switch has a route to this (10.0.0.0/8 via old firewall ip)

I have a client PC in the test vlan 888, when i apply the policy to the SVI and turn on Policy Routing debugging i see the below messages

198391: Jul 13 11:06:05: IP: route map INTERNET, item 10, permit
198392: Jul 13 11:06:05: IP: s=10.77.88.1 (Vlan888), d=10.77.88.255, len 78, policy rejected -- normal forwarding
198393: Jul 13 11:06:06: IP: s=10.77.88.1 (Vlan888), d=10.77.88.255, len 78, policy match
198394: Jul 13 11:06:06: IP: route map INTERNET, item 10, permit
198395: Jul 13 11:06:06: IP: s=10.77.88.1 (Vlan888), d=10.77.88.255, len 78, policy rejected -- normal forwarding
198396: Jul 13 11:06:07: IP: s=10.77.88.1 (Vlan888), d=10.77.88.255, len 78, policy match
198397: Jul 13 11:06:07: IP: route map INTERNET, item 10, permit
198398: Jul 13 11:06:07: IP: s=10.77.88.1 (Vlan888), d=10.77.88.255, len 78, policy rejected -- normal forwarding
198399: Jul 13 11:06:20: IP: s=10.77.88.1 (Vlan888), d=10.77.88.255, len 78, policy match
198400: Jul 13 11:06:20: IP: route map INTERNET, item 10, permit
198401: Jul 13 11:06:20: IP: s=10.77.88.1 (Vlan888), d=10.77.88.255, len 78, policy rejected -- normal forwarding
198402: Jul 13 11:06:20: IP: s=10.77.88.1 (Vlan888), d=10.77.88.255, len 236, policy match
198403: Jul 13 11:06:20: IP: route map INTERNET, item 10, permit
198404: Jul 13 11:06:20: IP: s=10.77.88.1 (Vlan888), d=10.77.88.255, len 236, policy rejected -- normal forwarding
198405: Jul 13 11:06:20: IP: s=10.77.88.1 (Vlan888), d=10.77.88.255, len 78, policy match

It seems the policy is rejected and then matched, over and over. I believe what should happen is that if a route exists, then normal forwarding should take place, but if no route exists then the packet should be policy-routed

Can anyone help decipher what is going on with this?

Many thanks

Leon

Reza Sharifi · ‎07-13-2015

Hi,

Can you post your config?

Leon Brierley · ‎07-13-2015

Hi Reza

Any bit in particular? Bit reluctant to post it all as its massive

thanks

Peter Paluch · ‎07-13-2015

Leon,

Please follow Reza's advice - I would personally suppose that the information Reza needs is:

The complete route-map you have applied to interface Vlan888
The complete ACL that this route-map refers to
The complete configuration of interface Vlan888

However, I have a small observation - why do the debugs show the broadcast address 10.77.88.255 as the destination address? Surely you haven't pinged the broadcast address, have you?

Best regards,
Peter

Leon Brierley · ‎07-13-2015

Hi guys

No probs - here you go..

route-map INTERNET permit 10
match ip address Policy-Based-Routing
set ip default next-hop 10.77.7.249

Extended IP access list Policy-Based-Routing
10 permit ip 10.77.88.0 0.0.0.255 any log (424 matches)

interface Vlan888
description TEST-ROUTING
ip address 10.77.88.254 255.255.255.0
ip policy route-map INTERNET
end

Yes, i spotted that too. No i havent pinged anything at all. This is what is in the log without me generating any traffic

Thanks

Reza Sharifi · ‎07-13-2015

Hi Leon,

Can you try changing

set ip default next-hop 10.77.7.249

to

set ip next-hop 10.77.7.249

and test again?

HTH

Leon Brierley · ‎07-13-2015

Thanks- ok i've tried that but no joy i'm afraid

416820: 000311: Jul 13 15:05:51: %PLATFORM_PBR-3-UNSUPPORTED_RMAP: Route-map INTERNET not supported for Policy-Based Routing (BRICORESTK01-2)
416821: Jul 13 15:06:28: PBR Nexthop: Unregister tracking for 10.77.7.249, handle: 0

416822: Jul 13 15:06:28: PBR Nexthop: Unregister tracking for 10.77.7.249, handle: 0

416823: Jul 13 15:07:49: PBR Nexthop Callback invoked: 3AE3B458, (10.77.7.249) tableid 0, status: 2,type: SET NEXTHOP

416824: Jul 13 15:07:49: map: INTERNET, sequence: 10

416825: Jul 13 15:07:49: PBR Control Plane Notification: 10.77.7.249 PBR_CP_SET_NEXTHOP

416826: Jul 13 15:07:49: PBR CP Notification sent: Type:SET NEXTHOP, 10.77.7.249SW_OBJ_TYPE: 1D, SW_HANDLE: 3C1C8370
PBR Nexthop: Register tracking for 10.77.7.249, handle: 375EEABC

416827: Jul 13 15:07:49: PR-RP: Set Vlan888 policy_routemap=INTERNET; cached_map=INTERNET

416827: Jul 13 15:07:49: PR-RP: Set Vlan888 policy_routemap=INTERNET; cached_map=INTERNET
416828: Jul 13 15:08:15: %SYS-5-CONFIG_I: Configured from console by lbrierley2 on vty0 (10.20.1.93)
416829: Jul 13 15:11:45: IP: s=10.77.88.1 (Vlan888), d=10.77.88.255, len 78, policy match
416830: Jul 13 15:11:45: IP: route map INTERNET, item 10, permit
416831: Jul 13 15:11:45: IP: s=10.77.88.1 (Vlan888), d=10.77.88.255 (Vlan7), len 78, policy routed
416832: Jul 13 15:11:45: IP: Vlan888 to Vlan7 10.77.7.249
416833: Jul 13 15:11:45: IP: s=10.77.88.1 (Vlan888), d=10.77.88.255, len 78, policy match
416834: Jul 13 15:11:45: IP: route map INTERNET, item 10, permit
416835: Jul 13 15:11:45: IP: s=10.77.88.1 (Vlan888), d=10.77.88.255 (Vlan7), len 78, policy routed
416836: Jul 13 15:11:45: IP: Vlan888 to Vlan7 10.77.7.249
416837: Jul 13 15:11:46: IP: s=10.77.88.1 (Vlan888), d=10.77.88.255, len 78, policy match
416838: Jul 13 15:11:46: IP: route map INTERNET, item 10, permit
416839: Jul 13 15:11:46: IP: s=10.77.88.1 (Vlan888), d=10.77.88.255 (Vlan7), len 78, policy routed
416840: Jul 13 15:11:46: IP: Vlan888 to Vlan7 10.77.7.249
416841: Jul 13 15:11:52: %SEC-6-IPACCESSLOGP: list Policy-Based-Routing permitted udp 10.77.88.1(0) -> 10.77.88.255(0), 6 packets

Peter Paluch · ‎07-13-2015

Leon,

Your ACL entry uses the log keyword. With many applications of ACL outside of normal filtering, the log keyword is generally unsupported and is either ignored, or it causes the entire application to misbehave (for example, NAT using ACLs that use the log keyword will not work at all). It would be best to try removing that keyword from the ACL entry (this will require removing it and entering it again without log) and test your PBR again.

Best regards,
Peter

Leon Brierley · ‎07-13-2015

Hi Peter

Thanks for your help. i did orginially not have the keyword log in there and put it on to try and troubleshoot. I've removed this now and reapplied the policy to SVI 888. However i'm still seeing these messages in the log. It appears that now it is routing unconditionally - i think that is becuase i have ip next-hop and not ip default next-hop. Strange how its always broadcast traffic??

Jul 14 06:49:50: IP: route map INTERNET, item 10, permit
426597: Jul 14 06:49:50: IP: s=10.77.88.1 (Vlan888), d=10.77.88.255 (Vlan7), len 78, policy routed
426598: Jul 14 06:49:50: IP: Vlan888 to Vlan7 10.77.7.249
426599: Jul 14 06:49:50: IP: s=10.77.88.1 (Vlan888), d=10.77.88.255, len 78, policy match
426600: Jul 14 06:49:50: IP: route map INTERNET, item 10, permit
426601: Jul 14 06:49:50: IP: s=10.77.88.1 (Vlan888), d=10.77.88.255 (Vlan7), len 78, policy routed
426602: Jul 14 06:49:50: IP: Vlan888 to Vlan7 10.77.7.249
426603: Jul 14 06:50:20: IP: s=10.77.88.1 (Vlan888), d=10.77.88.255, len 78, policy match
426604: Jul 14 06:50:20: IP: route map INTERNET, item 10, permit
426605: Jul 14 06:50:20: IP: s=10.77.88.1 (Vlan888), d=10.77.88.255 (Vlan7), len 78, policy routed
426606: Jul 14 06:50:20: IP: Vlan888 to Vlan7 10.77.7.249
426607: Jul 14 06:50:21: IP: s=10.77.88.1 (Vlan888), d=10.77.88.255, len 78, policy match

Thanks

Leon

Leon Brierley · ‎07-14-2015

.. some additional info.

I now have a ping running from a PC in vlan 888 to another PC in our subnet and i can see the policy routing matches increasing on every ping. Looks like everything is being policy routed - even traffic that the switch has a route for..

route-map INTERNET, permit, sequence 10
Match clauses:
ip address (access-lists): Policy-Based-Routing
Set clauses:
ip default next-hop 10.77.7.249
Policy routing matches: 32 packets, 3271 bytes

Peter Paluch · ‎07-14-2015

Hi Leon,

I suggest ignoring the debug reports for the broadcast address. That traffic is not going to be routed anywhere anyway so it's just a clutter.

As this is a switch, your debug ip policy can be expected to display only process-switched packets. Packets that are switched in hardware (CEF) will be generally processed away from CPU and so the debug will not be displaying them. Broadcast traffic obviously needs to be processed by CPU as well so that is why you are seeing it in your outputs.

However, why the PBR is matching even those destinations for which you have a matching route - I do not know. How do you determine that it is matching those packets? Do not look at counters - look at traceroute outputs. However, just to make sure: What is a matching route in your understanding? It must be a route more specific than 0.0.0.0/0. This route is ignored as a "match" for set ip default next-hop.

Best regards,
Peter

Leon Brierley · ‎07-14-2015

Understood, thanks Peter.

I know its matching everything because i have a ping running from my PC to the test PC in vlan 888 and as soon as i apply the policy the ping drops. My PC is in another subnet. 10.20.1.0/24. If i do show ip route 10.20.1.0 on the switch i get

Routing entry for 10.0.0.0/8
Known via "static", distance 1, metric 0
Routing Descriptor Blocks:
* 10.10.7.250
Route metric is 0, traffic share count is 1

So the switch has a route to my PCs subnet but it is still ignoring this and policy routing the packet to 10.77.7.249 instead

I have even added a static route to my PC 10.20.1.93 255.255.255.255 10.10.7.250 but still no luck

Very strange!

Thanks

Leon

Peter Paluch · ‎07-14-2015

Leon,

It appears that on Catalyst 3850 switches, the use of set ip default next-hop is not supported - in fact, the only supported command mentioned explicitly by the documentation is the set ip next-hop - check for yourself:

http://www.cisco.com/c/en/us/td/docs/ios-xml/ios/iproute_pi/configuration/xe-3se/3850/iri-xe-3se-3850-book/iri-pbr.html#GUID-5CDCF70B-8D30-48E0-893A-1361A9EFDEB7

It says, in particular:

Only set ip next-hop command can be used under route-map configuration mode when you configure policy-based routing.

Do you actually need the "default route override" by your PBR? What exactly are you trying to achieve? Perhaps we could construct a workaround.

Best regards,
Peter

Leon Brierley · ‎07-14-2015

Ah - thats a pain.

Ok, so i need to route internet traffic for one specific PC to our new firewall, 10.77.7.249. The reason for this is because theres 300 or so PCs in production using a different gateway for their internet traffic, if i change the last resort hop it will change all of these. I'm unsure of any other way to do this without PBR?

Thanks

Leon

Peter Paluch · ‎07-14-2015

Leon,

For what you need to accomplish by your latest description, you should be absolutely fine with set ip next-hop and not the set ip default next-hop. Let's make sure we both understand the difference between these two:

set ip next-hop X.X.X.X always forwards the traffic to the specified next hop X.X.X.X, skipping the routing table lookup altogether. Only if the next hop IP address is on an interface that is inoperable, the packet will be routed according to the normal routing table.
set ip default next-hop will first try to find a matching route for the packet's destination in the routing table. This matching route must be more specific than a default route. Only if the routing table provides no match, or the only match is a default route, the packet will be forwarded to the specified next hop X.X.X.X.

Best regards,
Peter

Policy Based Routing Issue