Are there any hardware or software limitation?

I seems that it depends on traffic type.

The following is just the output to match the PBR.

In case of ping

route-map PBR, permit, sequence 10

  Match clauses:

    ip address (access-lists): 100

  Set clauses:

    ip next-hop 10.0.30.3

  Policy routing matches: 0 packets, 0 bytes

In case of traceroute

route-map PBR, permit, sequence 10

  Match clauses:

    ip address (access-lists): 100

  Set clauses:

    ip next-hop 10.0.30.3

  Policy routing matches: 3 packets, 180 bytes

The link below is related to PBR however it does not show about this notice.

http://www.cisco.com/en/US/docs/switches/lan/catalyst3750x_3560x/software/release/12.2_55_se/configuration/guide/swiprout.html#wp1210866

Hi mhiyoshi

Have you ever been able to solve your problem? It seems that I'm facing a similar issue. Thanks if you could give a short update about your issue.

Erich

Hello Erich,

On multilayer switches, the PBR is compiled into TCAM and executed in hardware whenever possible. Only packets that cannot be switched in hardware will be processed on the CPU. Counters in the show route-map commands, on the other hand, are maintained in software and are therefore incremented only for process-switched PBR-handled packets. Therefore, the fact that the counters in the route-maps do not increase is not an indication of any error; in fact, it would be a cause for concern if they were increasing rapidly because it would indicate that lots of packets are process-switched. This is the same, for example, with ACLs - while they have counters shown in the show access-lists command, these counters do not increase for hardware-switched packets.

Best regards,

Peter

Hi Peter

Thanks for your reply and explanation. For my issue I also worked with "debug ip policy". Do I see there the same like with "show route map" and "show access-lists". Enclosed the debug from my tests:

! Traceroute from Access Switch 192.168.33.12

000543: Feb  2 14:37:49.825 CET: IP: s=192.168.33.12 (Vlan33), d=10.10.140.20, len 28, policy match

000544: Feb  2 14:37:49.825 CET: IP: route map route-map-test, item 199, permit

000545: Feb  2 14:37:49.825 CET: IP: s=192.168.33.12 (Vlan33), d=10.10.140.20 (Vlan2), len 28, policy routed

000546: Feb  2 14:37:49.825 CET: IP: Vlan33 to Vlan2 192.168.32.30

000547: Feb  2 14:37:49.825 CET: IP: s=192.168.33.12 (Vlan33), d=10.10.140.20, len 28, policy match

000548: Feb  2 14:37:49.825 CET: IP: route map route-map-test, item 199, permit

000549: Feb  2 14:37:49.825 CET: IP: s=192.168.33.12 (Vlan33), d=10.10.140.20 (Vlan2), len 28, policy routed

000550: Feb  2 14:37:49.825 CET: IP: Vlan33 to Vlan2 192.168.32.30

000551: Feb  2 14:37:49.833 CET: IP: s=192.168.33.12 (Vlan33), d=10.10.140.20, len 28, policy match

000552: Feb  2 14:37:49.833 CET: IP: route map route-map-test, item 199, permit

000553: Feb  2 14:37:49.833 CET: IP: s=192.168.33.12 (Vlan33), d=10.10.140.20 (Vlan2), len 28, policy routed

000554: Feb  2 14:37:49.833 CET: IP: Vlan33 to Vlan2 192.168.32.30

! Ping Broadcast 255.255.255.255 from Access Switch 192.168.33.12

00558: Feb  2 14:38:24.328 CET: IP: s=192.168.33.12 (Vlan33), d=255.255.255.255, len 100, policy rejected -- normal forwarding

000559: Feb  2 14:38:26.333 CET: IP: s=192.168.33.12 (Vlan33), d=255.255.255.255, len 100, policy rejected -- normal forwarding

000560: Feb  2 14:38:28.346 CET: IP: s=192.168.33.12 (Vlan33), d=255.255.255.255, len 100, policy rejected -- normal forwarding

! Ping ZH-C3560-B1015-02#ping 10.10.140.20  

! Telnet ZH-C3560-B1015-02#telnet 10.10.140.20 5061

For Ping and Telnet no output received from "debug ip policy".

Erich

Hello Erich,

For Ping and Telnet no output received from "debug ip policy".

Am I correct in assuming that the ping/telnet commands were issued on the same switch that also has PBR configured? If yes then you have to keep in mind that if a PBR route-map is applied onto an interface, it affects only traffic that comes in through that interface. Locally originated traffic like pings or telnet connections from the PBR box are not affected by the PBR configuration because these packets do not really have an ingress interface. Instead, if locally originated packets are to be PBR-routed, you need to apply the PBR route-map using the ip local policy route-map command. Please be careful here, though, as this command may apply to potentially vital communication originated from your PBR box.

Best regards,

Peter

No, that is not correct. I'm doing the ping and telnet from a Access Switch which is connected over a Trunk to the L3 Switch.

- Access Switch Mgmt VLAN 192.168.33.12

- Config on Core L3: (Attached Route map to SVI VLAN 33, so inbound).

interface Vlan33

ip address 192.168.33.1 255.255.255.0

no ip proxy-arp

ip policy route-map route-map-test

access-list 199 remark * PBR LAN *

access-list 199 remark * PBR Lync *

access-list 199 permit udp any range 5350 5389 any

access-list 199 remark * PBR Lync Video *

access-list 199 permit udp any range 5390 5429 any

access-list 199 remark * PBR Lync Desktop Sharing Traffic *

access-list 199 permit tcp any range 5350 5429 any

access-list 199 remark * Lync SIP *

access-list 199 permit tcp any host 10.10.140.60 range 5060 5076

access-list 199 permit tcp any host 10.10.140.61 range 5060 5076

access-list 199 permit tcp any host 10.10.140.62 range 5060 5076

access-list 199 remark * AD Synchronisation *

access-list 199 permit ip any host 10.10.140.20

access-list 199 permit icmp any host 10.10.140.20

access-list 199 remark * Temporary Box *

access-list 199 permit ip host 192.168.39.18 any

access-list 199 permit ip host 192.168.39.19 any

access-list 199 permit ip host 172.22.128.8 any

access-list 199 permit ip host 172.22.128.9 any

route-map test-route-map permit 199

match ip address 199

set ip next-hop 192.168.32.30.

Hi Erich,

Oh, I see. Thank you. In that case, I believe you see an output from the debug ip policy merely because the "traceroute" packets that hit your PBR box had to be process switched. The reason is that their IP TTL value was set to 1 and their further routing would necessitate decreasing the IP TTL to 0 which is not allowed. Because for such packets, an ICMP Unreachable message has to be generated, these packets are punted to process switching, hence the debug output you saw. This actually corresponds to the three occurences of "IP: route map route-map-test, item 199, permit" message caused by all "traceroute" packets being sent in threes.

So once again, even the debugging of PBR causes only packets from process switching to be printed. Packet forwarding that is done in hardware runs independent of CPU and IOS and will not show up in debugs.

Best regards,

Peter

Hi Peter

Thanks once more for your detail explanatation. I will build the whole szenario up in our lab and verify with Wireshark or debug ip packet on the next hop to see if my pbr works or not. According to your information everything works as described. So if yes, it seems that I have a problem on the ohter side (next hop WAN Infrastructure ISP).

Will make a update as soon I have new information from my test in the lab.

Hello Peter and Erich

Thank you for your precious infomation.

I can understand that "traceroute" itself needs response from the switch such as ICMP Time to Exceeded message.

So specifically the switch needs to execute on the process switching mode.

Other packet like ICMP ping messages itself the switch only processes to execute PBR on the hardware.

So it does not count up on the "show route-map" and "show ip access-lists".

I appreciate if you can confirm it.

Best Regards,

Masanobu Hiyoshi

Hi Masanobu, Peter

Have build the whole environment of my customer in my lab. And I can confirm everything what Peter as mentioned. As well for show commands, acl and debug, I have no hits. But it works like described from Peter.

The following I have tested:

- Access Switch Source IP 192.168.33.12 Telnet to 10.10.140.20 Port 5061

- L3 has default GW set to 192.168.32.1

- PBR routes telnet port 5061 to 192.168.32.30 instead default gw

- Configuration PBR see the following post of this thread: Feb 4, 2013 7:43 AM (in response to Peter Paluch)

Here a few show commands and the result on the router 192.168.32.30:

Routing Table L3 Switch with PBR active

C3750#show ip route

Gateway of last resort is 192.168.32.1 to network 0.0.0.0

     192.168.32.0/27 is subnetted, 1 subnets

C       192.168.32.0 is directly connected, Vlan2

C    192.168.33.0/24 is directly connected, Vlan33

S*   0.0.0.0/0 [1/0] via 192.168.32.1

show route-map

route-map test-route-map, permit, sequence 199

  Match clauses:

    ip address (access-lists): 199

  Set clauses:

    ip next-hop 192.168.32.30

  Policy routing matches: 0 packets, 0 bytes

show ip access-lists

Extended IP access list 199

    10 permit udp any range 5350 5389 any

    20 permit udp any range 5390 5429 any

    30 permit tcp any range 5350 5429 any

    40 permit tcp any host 10.10.140.60 range 5060 5076

    50 permit tcp any host 10.10.140.61 range 5060 5076

    60 permit tcp any host 10.10.140.62 range 5060 5076

    70 permit ip any host 10.10.140.20

    80 permit ip host 192.168.39.18 any

    90 permit ip host 192.168.39.19 any

    100 permit ip host 172.22.128.8 any

    110 permit ip host 172.22.128.9 any

debug ip policy

Policy routing debugging is on

C3750#ter

C3750#terminal monitor

C3750#

*Mar  1 00:28:07.863: IP: s=0.0.0.0 (Vlan33), d=255.255.255.255, len 604, policy rejected -- normal forwarding

*Mar  1 00:28:11.688: IP: s=0.0.0.0 (Vlan33), d=255.255.255.255, len 604, policy rejected -- normal forwarding

*Mar  1 00:28:15.681: IP: s=0.0.0.0 (Vlan33), d=255.255.255.255, len 604, policy rejected -- normal forwarding

Test Router which simulates next Hop 192.168.32.30

Router#show debugging

Generic IP:

  IP packet debugging is on

*Mar  1 04:45:39.590: IP: s=192.168.33.12 (FastEthernet0/0), d=10.10.140.20, len 44, unroutable

*Mar  1 04:45:39.590: IP: s=192.168.32.30 (local), d=192.168.33.12, len 56, unroutable

*Mar  1 04:45:41.590: IP: s=192.168.33.12 (FastEthernet0/0), d=10.10.140.20, len 44, unroutable

*Mar  1 04:45:41.590: IP: s=192.168.32.30 (local), d=192.168.33.12, len 56, unroutable

*Mar  1 04:45:45.590: IP: s=192.168.33.12 (FastEthernet0/0), d=10.10.140.20, len 44, unroutable

*Mar  1 04:45:45.590: IP: s=192.168.32.30 (local), d=192.168.33.12, len 56, unroutable

*Mar  1 04:45:53.594: IP: s=192.168.33.12 (FastEthernet0/0), d=10.10.140.20, len 44, unroutable

*Mar  1 04:45:53.594: IP: s=192.168.32.30 (local), d=192.168.33.12, len 56, unroutable

So it works like it should, except the limited possiblity to verify things on Cat3750.