I have 2 routers (A and B) with 2 tunnels (1 and 2) between them. OSPF is running and tunnel 1 is favoured due to a better metric. Router B has a route map on it's lan interface. This directs specific traffic to tunnel 2 - Host X to Host Y (route map has match access list 10 and set ip next-hop commands)
Now for the problem....
Host X sits on the LAN on router B. It matches the access list in the route map and is directed to tunnel 2....or so I believe. Trace route from Host X shows the path to the host is via tunnel 2 (which is correct)
To test this is working I have set up an access list on the tunnel 2 interface on router A. I am not seeing any matches for the Host X to Host Y traffic. On Router B I issue a show ip route to Host Y and it shows me that the route is via tunnel 1.
I then put a default route (ip route host Y tunnel 2) on Router B to be via tunnel 2 and then I see matches in the access-list on router A.
Anyone know how I can make sure the traffic obeys the route map?
THanks a lot.
try to use debug ip policy on RB.
it should show you the redirection action
depending on the tunnel type what you have tried can work or not.
Hope to help
Thanks for the reply. I did a debug ip policy (crashed the router!) and found lots of "FIB policy rejected(no match) normal forwarding. So it looks like the policy map is not working even though it looks as if it set correctly. Any ideas on how I should get it to work? you mentioned something about tunnel type?
I am intrigued as to why Host X reports from a trace route to be taking the correct path.
sound like config issue, can you post the relevent config for us to look?
router A would need pbr too if tunnel 1 is the default preferred path.
I'm sorry for the crash I should have added do it under low traffic conditions.
I agree with Ting, at this point it is useful if you post the config.
Change public ip addresses in something else and remove any user/pwd commands.
Hope to help
Thanks for replies.
I have checked the route map on router A and it does not have HOST Y to HOST X in the access list.......but this should not matter as I have a static route to HOST X.
So have you any thoughts on why HOST X would be saying that tracert is saying one thing but the router is acutally doing something else. seems weird to me but as always there will be a logical explanation :-)
As Ting and Giuseppe have pointed out, at this point, it would be very helpful if you could provide the configuration of your router - at least the portions related to your route-map issue and the IP addresses of your hosts that do not seem to be influenced by PBR. It is almost impossible to help you without knowing more detail.
>> #sh access-list DUBTUN2
Extended IP access list DUBTUN2
10 permit ip host 10.200.1.43 10.0.0.0 0.0.0.255 (691955 matches)
the ACL used in the route-map has matches so it looks like it is working your PBR.
what is the output of
sh route-map FE00?
does it reports stats for first clause the one using the ACL above?
note also that route-maps and ACLs on other side shows
sh access-list ODCTUN2
Extended IP access list ODCTUN2
10 permit ip host 10.0.0.10 host 10.200.1.20 (113657 matches)
sh route-map LAN
route-map LAN, permit, sequence 10
ip address (access-lists): ODCTUN2
ip next-hop 10.254.0.18
>>>Policy routing matches: 117260 packets, 22846256 bytes
this is clearly working from RA to RB
you cannot expect PBR to change ip routing table it is not its job.
It has to process traffic overriding IP routing table.
routing table will show via tunnel1 for its lowest OSPF metric.
Hope to help
Thanks for reply.
The output shows that the route map is matching
#sh route-map FE00
route-map FE00, permit, sequence 10
ip address (access-lists): DUBTUN2
ip next-hop 10.254.0.17
Policy routing matches: 2257924 packets, 1219828926 bytes
route-map FE00, permit, sequence 20
ip address (access-lists): BORTUN3
ip next-hop 10.254.210.10
Policy routing matches: 1792 packets, 224409 bytes
route-map FE00, permit, sequence 30
ip address (access-lists): CARTUN1
ip next-hop 10.254.212.2
Policy routing matches: 0 packets, 0 bytes
but from the debug ip policy I did recently it says it is not using the policy map. maybe a bug....