PBR no worky

[sterdnotshaken]

Hey all,

I have a 6509 running 12.2(33)SXH7 and that has the following config:

ip access-list extended PBR-206

deny   udp any any eq bootps

deny   udp any any eq bootpc

deny   ip any 10.0.0.0 0.255.255.255

deny   ip any 172.0.0.0 0.31.255.255

deny   ip any 192.168.0.0 0.0.255.255

deny   ip any 0.0.0.0 255.0.0.0

permit ip host 10.0.206.45 any

permit ip host 10.0.206.47 any

permit ip host 10.0.206.44 any

permit ip host 10.0.206.17 any

permit ip host 10.0.206.175 any

!

ip access-list extended PBR-206-WebSense

deny   udp any any eq bootps

deny   udp any any eq bootpc

deny   ip any 10.0.0.0 0.255.255.255

deny   ip any 172.0.0.0 0.31.255.255

deny   ip any 192.168.0.0 0.0.255.255

deny   ip any 0.0.0.0 255.0.0.0

permit ip host 10.0.206.20 any

permit ip host 10.0.206.142 any

!

route-map PBR-206 permit 10

match ip address PBR-206

set ip next-hop 10.0.206.200

!

route-map PBR-206 permit 20

match ip address PBR-206-WebSense

set ip next-hop 10.0.16.174

!

interface Vlan206

ip policy route-map PBR-206

Anything in PBR-206 gets proper treatment and is either policy routed or droped out to the RIB as it should be, but hosts that are indicated in PBR-206-WebSense almost never get matched... If I take one of the host IP's from PBR-206-WebSense and put it in the ACL PBR-206, then all of that traffic get's matched properly... I am rather confused by this behavior. The separate sequences in the route-map are considered in a OR logic right? It is almost behaving like if it doesn't find a match on sequence 10 then it doesn't check sequence 20... Oh and also, the deny's ensure that we are only Policy routing for external web traffic...

Any ideas?

Thanks in advance!

[jawad-mukhtar]

ip access-list extended PBR-206

permit ip host 10.0.206.45 any

permit ip host 10.0.206.47 any

permit ip host 10.0.206.44 any

permit ip host 10.0.206.17 any

permit ip host 10.0.206.175 any

!

ip access-list extended PBR-206-WebSense

permit ip host 10.0.206.20 any

permit ip host 10.0.206.142 any

change it to this and then check.

Jawad

[jawad-mukhtar]

Also

10.0.16.174 this should be next hope ip ....

Jawad

[sterdnotshaken]

Thanks for the reply Jawad,

I have tried that, but our desire is to only forward Internet bound traffic through PBR... so to remove the previous ACL entries would force all traffic to be PBR routed...

Am I missing something?

[jawad-mukhtar]

i dont think so

IP that u have mentioned in ACL will be forced to internet like that

permist ip host x.x.x.x any

Others are denied

Kindly confirm does it work wat i told you above.

Jawad

[jawad-mukhtar]

If you want on x.x.x.x to route for internet only and it should not route for local ip

apply acl in this way

deny ip host x.x.x.x 192.168.1.0 0.0.0.255

deny ip host x.x.x.x 192.168.2.0 0.0.0.255

then for Internet apply this on last sequence

permist ip host x.x.x.x any

***DO RATE ALL HELPFUL POSTS***

Jawad

[sterdnotshaken]

Thanks again for your response Jawad,

So in the below ACL, if traffic is destined to UDP bootps\pc ports or to RFC1918 addresses as well as any destination address that is [0-255].0.0.0 from ANY internal address, then it will be denied from being policy routed and would thus pop out to the RIB for normal routing. This ensures that we can then add single hosts to the end of this ACL that we want to forward to policy forward to the next hop address of 10.0.16.174 without having to define all of those deny's (bootps/c, rfc1918, etc...) for every single host we are wanting to policy route this way. The first sequence (10) in this Route-Map is working great. The single hosts that are indicated in the PBR-206 ACL are effectively PBR forwarded to 10.0.206.200, it is sequence 20 that is the issue... The 2 hosts indicated don't seem to be matching properly. I can move one of the host IP's up to sequence 10 ACL and then I get all kinds of matching, only when it is in sequence 20 do I have issues with it...

ip access-list extended PBR-206

deny udp any any eq bootps

deny udp any any eq bootpc

deny ip any 10.0.0.0 0.255.255.255

deny ip any 172.0.0.0 0.31.255.255

deny ip any 192.168.0.0 0.0.255.255

deny ip any 0.0.0.0 255.0.0.0

permit ip host 10.0.206.45 any

permit ip host 10.0.206.47 any

permit ip host 10.0.206.44 any

permit ip host 10.0.206.17 any

permit ip host 10.0.206.175 any

!

ip access-list extended PBR-206-WebSense

deny   udp any any eq bootps

deny   udp any any eq bootpc

deny   ip any 10.0.0.0 0.255.255.255

deny   ip any 172.0.0.0 0.31.255.255

deny   ip any 192.168.0.0 0.0.255.255

deny   ip any 0.0.0.0 255.0.0.0

permit ip host 10.0.206.20 any

permit ip host 10.0.206.142 any

!

route-map PBR-206 permit 10

match ip address PBR-206

set ip next-hop 10.0.206.200

!

route-map PBR-206 permit 20

match ip address PBR-206-WebSense

set ip next-hop 10.0.16.174

!

interface Vlan206

ip policy route-map PBR-206

ip address 10.0.206.2 255.255.254.0

Thanks!

[jawad-mukhtar]

10.0.206.200 this must be next hope ip.  If its two or three hop away it will not work

change route map sequence

route-map PBR-206 permit 10

match ip address PBR-206-WebSense

set ip next-hop 10.0.16.174

route-map PBR-206 permit 20

match ip address PBR-206

set ip next-hop 10.0.206.200

Jawad

[jawad-mukhtar]

sorry

10.0.206.200 and 10.0.16.174 must be next hope ips as i mentioned above.

Jawad

[sterdnotshaken]

Hey Jawad,

that is a good idea, but if I re-arrange the order of the sequences, won't I then have the exact same issue with what is now sequence 10 being moved to sequence 20?

Thanks!

[jawad-mukhtar]

you can first check that then we will move forwared.  if seq 20 will not work with seq 10 then there is next hope issue.

Jawad

[sterdnotshaken]

Per your last point, the traffic flow should be (correct me if I am wrong):

Internet-bound traffic from host in vlan 206 is sent to default gw, when frame hits the SVI for vlan 206 the PBR config parses the packet header and finds a match on the source IP address and it then routes that packet from vlan 206 across to vlan 16 (like said before, both are locally connected routes) where it sends that frame onto its new destination of 10.0.16.174… ? Here is a sample of the config on this switch:

6509_Switch

!

interface Vlan206

ip policy route-map PBR-206

ip address 10.0.206.2 255.255.254.0

!

interface Vlan16

ip address 10.0.16.2 255.255.254.0

6509_Switch#ping 10.0.16.174

Sending 5, 100-byte ICMP Echos to 10.0.16.174, timeout is 2 seconds:

!!!!!

Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/4 ms

6509_Switch#sh ip arp | in 10.0.16.174

Internet 10.0.16.174             0   0050.56b3.7b27 ARPA   Vlan16

6509_Switch#ping 10.0.206.200        

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 10.0.206.200, timeout is 2 seconds:

!!!!!

Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/4 ms

6509_Switch#sh ip arp | in 10.0.206.200

Internet 10.0.206.200           12   0017.c5e1.0fec ARPA   Vlan206

So hummm… the next hop may be the issue your saying? Any idea’s how to verify that?

FYI, The next hop for sequence 20 that is having issues is a VMWare host running WebSense…

Thanks a lot!!

[jawad-mukhtar · Accepted solution]

check and post  traceroute result  from hosts of route-map seq 10 and seq 20.

check in traceroute traffic is going proper.

Jawad

[sterdnotshaken]

You were right Jawad. The next hop for PBR wasn't accepting the traffic... We ended up needing to enable WCCP on the device we were using for next-hop for it to work.

Thanks for your help!