Catalyst 4500 Sup. Engine IV, PBR problem

[plepesant]

On a Catalyst 4507R with redundant Sup. Engine IV, IOS 12.2.25EW PBR (Policy Based Routing) seems to not work correctly.

Packets which should not be selected by the ACL are routed using the PBR policy. But they should routed using a static route.

Here is a sample of my PBR configuration:

int vlan 14

ip policy route-map vlan14-To-Frame

route-map vlan14-To-Frame permit 10

match ip address vl14-to-Frame

set ip next-hop 10.230.10.5

ip access-list extended vl14-to-Frame

permit ip 10.220.59.16 0.0.0.15 host 10.101.140.42

permit ip 10.220.59.16 0.0.0.15 host 10.101.140.43

permit ip 10.220.59.16 0.0.0.15 host 10.101.140.67

permit ip 10.220.59.16 0.0.0.15 host 10.101.140.75

permit ip 10.220.59.16 0.0.0.15 host 10.101.140.79

permit ip 10.220.59.16 0.0.0.15 host 10.101.140.93

permit ip 10.220.59.16 0.0.0.15 host 10.101.140.94

permit ip 10.220.59.16 0.0.0.15 host 10.101.140.95

I am missing something in my configuration, or is it a bug ?

Thank you !

[Richard Burts]

Pascal

Based on what you have included in this post I do not see a problem with configuration. Assuming that VLAN 14 addresses are in subnet 10.220.59.16/28 then it looks like traffic from that subnet to the selected hosts should have 10.230.10.5 set as the next hop. What is the normal next hop to those hosts?

Can you supply some additional information, especially what is the normal route to those destination addresses. And examples of traffic being policy routed that should not be.

HTH

Rick

[plepesant]

Thanks Rick for your answer. Here is a complement of information:

int vlan 10

ip address 10.220.60.1 255.255.255.0

int vlan 14

ip address 10.220.59.1 255.255.255.0

int vlan 100

ip address 10.230.10.2 255.255.255.128

static route:

ip route 10.101.140.0 255.255.255.0 10.230.10.1

The problem I have is that I see traffic from 10.220.59.20 to 10.220.60.17 when I sniff packets on the ethernet link to the 10.230.10.5 router. Normally with a well working PBR, this traffic should be intrenally routed to the VLAN 10.

Pascal

[Richard Burts]

Pascal

Thank you for the additional information. Based on the information that I see so far I do not see how PBR could be doing this. Would you post the output from show ip policy? Also would you post the output of show ip route? Also would you post the output of show access-list vl14-to-Frame?

HTH

Rick

[plepesant]

Rick, here is the requested information. I removed to some non interesting lines from the #sh ip route.

cat4500#sh ip policy

Interface Route map

Vlan14 vlan14-To-Frame

cat4500#sh route-map

route-map vlan14-To-Frame, permit, sequence 10

Match clauses:

ip address (access-lists): vl14-to-Frame

Set clauses:

ip next-hop 10.230.10.5

Policy routing matches: 155900 packets, 9680310 bytes

cat4500#sh ip access-list vl14-to-Frame

Extended IP access list vl14-to-Frame

permit ip 10.220.59.16 0.0.0.15 host 10.101.140.42

permit ip 10.220.59.16 0.0.0.15 host 10.101.140.43

permit ip 10.220.59.16 0.0.0.15 host 10.101.140.67

permit ip 10.220.59.16 0.0.0.15 host 10.101.140.75

permit ip 10.220.59.16 0.0.0.15 host 10.101.140.79

permit ip 10.220.59.16 0.0.0.15 host 10.101.140.93

permit ip 10.220.59.16 0.0.0.15 host 10.101.140.94

permit ip 10.220.59.16 0.0.0.15 host 10.101.140.95

cat4500#sh ip route

Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP

D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area

N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2

E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP

i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2

ia - IS-IS inter area, * - candidate default, U - per-user static route

o - ODR, P - periodic downloaded static route

Gateway of last resort is 10.230.10.1 to network 0.0.0.0

[...]

10.0.0.0/8 is variably subnetted, 9 subnets, 4 masks

S 10.0.0.0/8 [1/0] via 10.230.10.3

S 10.101.140.0/24 [1/0] via 10.230.10.1

C 10.230.10.0/25 is directly connected, Vlan100

C 10.220.60.0/24 is directly connected, Vlan10

C 10.220.58.0/24 is directly connected, Vlan13

C 10.220.59.0/24 is directly connected, Vlan14

C 10.220.56.0/24 is directly connected, Vlan11

C 10.220.57.0/24 is directly connected, Vlan12

[...]

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

Pascal

[Richard Burts]

Pascal

Thanks for the additional information. I am still not seeing how PBR could cause the symptoms that you are seeing. I think there are a couple things to check out. When you see the packet in the Sniffer, what is the destination MAC address (to whom is the packet being forwarded) and can you identify the IP address associated with that MAC address?

HTH

Rick

[plepesant]

Thank Rick for your perseverance...

The destination MAC address is the frame router's one (10.230.10.5).

Pascal

[Richard Burts · Accepted solution]

Pascal

This is quite strange and I do not yet understand it. The packet that you talk about has a source address that matches the access list but the destination address does not. PBR should not have set the next hop to 10.230.10.5.

I am wondering if there is anything other than what you have sent so far that uses 10.230.10.5. Would would be able to do show run | include 10.230.10.5 and post any result. Also could you do show ip route | include 10.230.10.5 and post any result.

I see in what you have sent that the vlan interface is 10.230.10.2/24. You have a static route with next hop of 10.230.10.1 which implies that this is a router. The PBR sets next hop as 10.230.10.5. Are 10.230.10.1 and 10.230.10.5 both routers connected in that subnet?

I am not clear what your PBR is intended to accomplish. I notice that the VLAN interface says that vlan 14 is 10.220.59.x/24. I notice that the mask in the access list for PBR is 0.0.0.15. So it would only match for a small group of addresses within the entire subnet. Is that what is intended?

I find that sometimes when things start to become illogical that it may help to save the config and reload the box. Would you be in a position to do this?

HTH

Rick

[plepesant]

Rick,

To answer your question:

Yes, 10.230.10.1 and 10.230.10.5 are both routers. One to the internet link (default) the other is a frame router which is implemented for VoIP traffic to a remote link.

10.220.59.16 0.0.0.15 is a small group of addresses assigned to phone system which need to communicate to the remote site via the frame relay link. Other systems in that vlan request normal routing.

I can't reload the box during the day, but it is in plan to reload it next night. I will keep you updated.

Thanks for your help.

Pascal

[plepesant]

I solved my problem by removing the policy from the vlan interface and re-applying it. It was not necessary to reboot the sup-engines.

Thank you very much rick for help.

Pascal

[Richard Burts]

Pascal

Thanks for updating this discussion with the solution. It helps make the forum more valuable when we can see the discussion of the problem and also see what solution solved the problem.

I am glad that you found a solution that was less drastic than rebooting the supervisor.

I encourage you to continue to participate in the forum.

HTH

Rick