Policy Based Routing Problem

[smithsera1]

Policy Based Routing

Hi,

Just wondering if anyone has come across this issue, we have two separate MPLS connections, both are from the same provider and both links receive the same bgp routes, however we are trying to manipulate the routing so that one of the LAN sub-interfaces goes across one specific link and will never go across the other.

Ingress to the the CE router from the core is fine as we have stopped the LAN sub-interface (via prefix lists) being advertised so it only knows how to get to the LAN sub-interface via link 1,m it will never go across link 2.

However from the LAN to the core it is using link 2, we have tried to use the following policy based routing and we can see matches in the debug but traffic still prefers going across link 2, I thought once it was matched th epolicy took over and didn't go near the routing table?

!

interface FastEthernet0/0.201

encapsulation dot1Q 201

ip address 10.10.10.1 255.255.255.0

no ip proxy-arp

ip policy route-map outbound-routing-policy

no snmp trap link-status

no cdp enable

link 1

serial 0/1

ip address 20.20.20.1

(link 2)

serial 0/2

ip address 30.30.30.1

route-map outbound-routing-policy permit 10

match ip address 180

set ip next-hop 20.20.20.2

access-list 180 permit ip 10.10.10.0 0.0.0.255 any log

[Jon Marshall]

"I thought once it was matched th epolicy took over and didn't go near the routing table?"

It should do.

Could you draw a quick topology so we can see how it is laid out. What is 20.20.20.2 ?

Also what device are you applying this PBR on ?

Jon

[smithsera1]

Hi Jon,

See attached for topology diagram, 20.20.20.2 is the far end of the MPLS link i.e bgp neighbour (PE),router is 2811

Thanks alot

[Jon Marshall]

Paul

Can't see anything wrong with your config.

Presumably 20.20.20.2 is up and reachable ?

What IOS version/feature set are you running on the 2811 router ?. I had a quick scan for bugs but nothing came up.

Jon

[smithsera1]

No worries Jon, thanks for looking at it anyway

[mailaglady2]

Hi Paul

I also dont see anything wrong with your configs but try this:

route-map outbound-routing-policy permit 10

match ip address 180

set interface serial0/1

[Rui Carlos Antunes]

Do you have a route (on the IP Routing Table) for the 10.10.10.0/24 network?

Do a "show ip route 10.10.10.0".

If you don't have, the command on the route-map should be "set default ip next-hop 20.20.20.2" (instead of just "set ip next-hop 20.20.20.2").

[smithsera1]

Hi,

The route for 10.10.10.0 is showing as directly connected as 10.10.10.1 is configured on the sub-int, I'm just wondering would there be an alternative way of trying to complete the scenario?

[Pavel Bykov]

Hi. Here is how i'd troubleshoot it.

1. Is the traffic really crossing the interface FastEthernet0/0.201 ? Is it possible that it leaks somewhere else? Just if the show commands really show that traffic is flowing

2. issue "ip route-cache policy" command on the FastEthernet0/0.201

3. try debugging PBR (in the afterhours of course) using debug ip policy command

[pidoshi · Accepted solution]

Could you try removing the "log" keyword from the ACL which is tied to the PBR..This is due to the fact that the log option forces pkts to be process switched and might affect PBR which is done in hardware (depending on HW)

Give it a try..!!

cheers

Pinku

[smithsera1]

Hi Pinku,

Super stuff, that sorted it...took out the log on the end of the ACL and it works..

Brilliant, tks a mill

Cheers

Paul