policy routing problem 1

[ogulcan]

About the down configuration i can not make the pakets matched at list 105 go through tunnel 0 on cisco 6509.
Altough rest is working fine they prefer the route given in static route.
Under the needed vlan i have the command for source routing though...?

route-map switch_6509 permit 5
match ip address 105
set interface Tunnel0
!
route-map switch_6509 permit 10
match ip address 102
!
route-map switch_6509 permit 20
match ip address 103
set ip next-hop 10.3.251.11
!
route-map switch_6509 permit 25
match ip address 104
set ip next-hop 10.3.253.32
!
route-map switch_6509 permit 30
match ip address 101
set interface Tunnel0

access-list 101 permit ip any any
access-list 102 permit ip any 10.2.0.0 0.0.255.255
access-list 102 permit ip any 193.169.75.0 0.0.0.255
access-list 102 permit ip any 10.75.0.0 0.0.3.255
access-list 102 permit ip any 224.65.10.0 0.0.0.255
access-list 103 permit ip any 1.0.0.0 0.255.255.255
access-list 103 permit ip any 2.0.0.0 0.255.255.255
access-list 103 permit ip any 10.11.200.0 0.0.0.255
access-list 104 permit ip 10.2.35.0 0.0.0.255 10.9.0.0 0.0.255.255
access-list 105 permit ip host 10.75.2.200 10.11.200.0 0.0.0.255

ip route 10.11.200.0 255.255.255.0 10.2.250.11 100 name x_servers

interface Vlan130
ip address 10.75.3.252 255.255.254.0
ip policy route-map switch_6509

but pakets do not listens to me?what can i do to convince them?
thanx in advance..

 

[GeorgeOu]

This is a very typical mistake that people make when they try and do policy based routing. Your thinking is backwards. You worry about the RouteMap ACL first, then the RouteMap, and then you slap it on to some interface.

In reality, it is backwards from what you think the process should be. You should look at it from the packet's point of view. The packet first crosses the Interface (this is your flawed assumption), and it notices that a RouteMap is applied to that Interface. It checks the RouteMap from lowest sequence to highest sequence. During each check of each sequence number, it checks to see if there is a match in the RouteMap ACL. If there is a match, the packet immediately takes the detour to that "next-hop" in that particular sequence number of that RouteMap.

If you analyze the first step, you'll note that I wrote that you made the first and final flawed assumption. What makes you think the packet ever crosses the VLAN130 interface in the first place? If it is not the Interface that the packet enters the router, and the static route sends that packet to some other interface, the packet never crosses VLAN130 and therefore you will not even start "Step 1" of the RouteMap process. This is why I say your thinking is backwards, because you're worried about Step 2 and Step 3 before you ever took care of Step 1. The solution is to make sure that the RouteMap is applied to an Interface that is guaranteed to see the packet regardless of the Static route, and therefore should be applied to the Interface that you expect to packet to first arrive in.

George Ou
Network Systems Architect

Get more powerful articles and tools from my webpage

http://www.lanarchitect.net

 

[ogulcan]

George thank you for your detailed explanations but the packets are realy coming from the right interface;

switch_6509#sh arp | inc 10.75.2.200
Internet 10.75.2.200 87 0008.7409.591a ARPA Vlan130
switch_6509#sh ip route 10.75.2.200
Routing entry for 10.75.2.0/23
Known via "connected", distance 0, metric 0 (connected, via interface)
Redistributing via eigrp 11
Routing Descriptor Blocks:
* directly connected, via Vlan130
Route metric is 0, traffic share count is 1

that is the problem what makes it weird..

 

[GeorgeOu]

There are some known issues on the Cisco 3550 enhanced image where PBR does not work unless a special command is entered and then the unit reloaded. I can't remember for sure, but it is possible that this applies to the MSFC in the 6509.

The command was "sdm prefer extended-match" on the 3550 EMI and you had to reload the switch. After that, PBR worked.

I would check call Cisco support if I were you if you're convinced that it is not a configuration issue. They are really good and helpful with things like this. If you're paying for support on your Cisco gear, you may as well use it once in a while.

I neat trick I like to use is to only permit ICMP in the RouteMap ACL, which allows you to test the PBR using Ping or Traceroute. However, doing so will not affect any thing other than ICMP and therefore will not affect any production environment while you're testing.

George Ou
Network Systems Architect

Get more powerful articles and tools from my webpage

http://www.lanarchitect.net

 

[ogulcan]

George, i guess i found the problem.
According to your first message i surveyed the configuration again and again..i found the following.

THOUGH i have a vlan 130 on 6509 my packets belong to that vlan are not entering the 6509 from that vlan interface.How?These vlan is also creted on an other switch, this time 3550,and packets willing to go my desired destination are sent to 6509 from VLAN 1 with a static route.so though packets are seemed at the so called vlan on 6509 at arp and route ,in fact ,packets are not coming from there.They are comeing from vlan 1,from an other device at the same vtp domain.That is why policy routing is not working for that step because under vlan 1 there is no "ip policy "command.

I really thank you for your detailed messages that helped me.I will nearly go crazy otherwise and wiil never find the reasonthank you so much)you really did a great favor for me...thank you.take care u friend.

 

[GeorgeOu]

Ah, congradulations on solving the problem on your own. That's some good detection work you did. One thing that also helps in doing some troubleshooting is if you applied the routemap to the outbound interface that the static route is forcing the traffic to. That will at least confirm that your PBR is set up correctly.

Get more powerful articles and tools from my webpage

http://www.lanarchitect.net

 

[ogulcan]

ok George,
thank you for help again.
I love this site & people helping each other.
take care.