PBR through an SVI from trunked linkd

[kev]

Hi All,

I need to apply a policy to traffic coming in from a WAN link to a Cisco 4948 switch. At the last minute I discovered my WAN connection was going to be delivered as a trunk link from the provider, so I reconfigured my routing interface as a trunk and applied my policy to the SVI for the VLAN being used.
Unfortunately the PBR is not seeing any hits, I think it may be something to do with what the SVI sees as inbound traffic, it's sometimes trickier to visualise what an SVI treats as inbound.
Any assistance gratefully received!

Sent from Cisco Technical Support iPad App

[Peter Paluch · Accepted solution]

Hello Kev,

On multilayer switches, you will not see the policy routing matches counter in the show route-map output as increasing - this is a software counter while on multilayer switches, PBR is done in hardware and the number of PBR-ed packets is not reflected into software counters. It is thus possible that your PBR works, just the counters do not increase. Debugging that, sadly, can be tricky.

In general, there is no difference to PBR on SVIs to any other interface. Traffic inbound to an SVI is a traffic that will be subsequently routed through the multilayer switch, so if the SVI terminates a VLAN from your WAN connection through which data comes in then you have applied your route-map properly.

Are you actually able to perform a traceroute from outside to see if the traceroute follows the intended PBR path?

Best regards,

Peter

[kev]

Hi Peter,

Thanks for the quick reply. It helps to have a sanity check if nothing else.

I'm not sure if what you say is entirely correct as I have other policies on this device for which the counters do increment, though these other policies are on routed interfaces.
Its hard to trace the traffic as the destination only responds to particular subnets, but I have used an ACL log my 'interesting' traffic and ensure it is being routed to this interface.
I think I may re-apply the policy, if that doesn't work I will post the config but there isn't much too it.

Keep the suggestions coming :-)

[Peter Paluch]

Hello Kev,

Let me lab this and I will get back to you with the results. In my personal opinion, you are seeing the PBR counter increased only by packets which were not eligible for CEF switching.

Best regards,

Peter

[Peter Paluch]

Hi Kev,

I have labbed a simple scenario: A PC connected to a Catalyst 3560, and then two routers behind the 3560, both having a loopback configured with 1.1.1.1/32 (call them R1 and R2). Depending on the IP address of the PC, the 3560 PBR-ed the packets for 1.1.1.1 to either R1 or R2.

I have verified the PBR both on SVI and on a routed port. In both cases, the policy routed packet counters in the route-map did not increase for normal traffic, confirming my suspicion that CEF-switched packets in hardware will not cause the counters to increase. I was able to cause the counters in the route-map to increase by, for example,

• tracerouting towards 1.1.1.1 (the TTL expiry and ICMP Unreachable handling had to be processed in IOS; such packets cannot be CEF-switched)
• having the PBR resolve the MAC address of the next hop in the set ip next-hop via ARP repeatedly (this is basically a glean adjacency handling, again requiring IOS processing without the capability of CEF-switching the packets)

So the fact you see your counters increasing on other route-maps is actually caused by your PBR handling packets that can not be immediately CEF-switched in hardware. Counters staying on the same value are absolutely not a cause for concern. On the contrary, if your PBR counters on other route-maps increase significantly, I would be worried about that because it means your multilayer switch is incapable of PBR switching lots of packets in hardware and has to resort to process switching.

Best regards,

Peter

[kev]

Wow Peter,

I feel a little guilty that you went to so much trouble!

I think you are correct so please accept my apologies. The route-map that I saw registering counters was on a second switch in our set-up, I am guessing maybe I need to check this as CEF may be disabled.
With your clue that PBR may in fact be working, I discovered that the next-hop router in my config (which is managed by a third party) had been configured incorrectly so I am waiting for that to be corrected.
I will mark your first reply as correct as I believe you have essentially diagnosed my problem, i.e. I was relying on counters that would never go up.
This is the first time I have used the Cisco support app so thanks very much for making it such a good experience!

Regards,
Kevin.





Sent from Cisco Technical Support iPad App

[Peter Paluch]

Hello Kevin,

No worries, it was a pleasure. There is absolutely no need to apologize. I was myself glad to have labbed this up, as I have explicitly confirmed some of the behavior I implicitly knew should be right but never actually verified that on real gear.

The route-map that I saw registering counters was on a second switch in  our set-up, I am guessing maybe I need to check this as CEF may be  disabled.

I do not think the CEF is disabled on that switch - on multilayer switches, you can not disable CEF as it is the fundamental mechanism on which Cisco multilayer switches are based. But as I explained, one possibility of actually seeing the counter increase is to discard packets because of TTL expiry (traceroute et al.), and another possibility is receiving packets for an IP address that is located in a directly connected network but is currently unused (e.g. the station is disconnected or shut down, or IP scans over the entire network range).

Anyway, it was a pleasure assisting you! Please feel welcome to join the discussion here anytime.

Best regards,

Peter