Hi Lee

Thanks for getting back to me. What more info do you need? The AS that it connects to? Please let me know and I'll provide it. Note i have this set up in other remote offices and it works however in these offices, i have two routers, one where the MPLS network is set up on the AS and on the other router, the backup tunnel is up and the MPLS is in a shutdown state. On our Frankfurt router, both the MPLS and Backup Tunnel are up.

Thanks,

Rob.

Hi,

I've attached a sh ip bgp for both the frankfurt and mullingar ends. you'll see that on the frankfurt end it is filtered to go over the tunnel. I want this to go directly to the 65203 AS number. Can this be forced?

This is the current trace route from Frankfurt to a server i want to get two in two hops:

50Gro-GER-2801a#traceroute 172.17.4.50

Type escape sequence to abort.

Tracing the route to 172.17.4.50

1 192.168.7.181 [AS 65100] 212 msec 208 msec 204 msec

2 192.168.31.205 [AS 65100] 208 msec 212 msec *

3 192.168.30.34 [AS 65100] 208 msec 212 msec 212 msec

4 192.168.0.254 [AS 65100] 308 msec 300 msec 300 msec

5 172.17.2.17 [AS 65203] 312 msec 304 msec 292 msec

6 172.17.4.50 [AS 65203] 292 msec 304 msec 308 msec

50Gro-GER-2801a#

Thanks again. I hope i'm providing enough info

This is your issue at least for the traceroute

* 172.17.0.0 172.16.0.6 0 19855 65203 i

*>...................192.168.7.181 0 65100 65203 i

Since the best route to 172.17.4.50 is the /16 route to 172.17.0.0. Now there are 2 BGP routes and it is picking your tunnel. The AS-path length is the same so it is using another tie breaker to choose the path.

Now you should never get this route in the first place if I read your bgp

neighbor 192.168.7.181 prefix-list Default-Route-Only in

If this does what it says it does you should only get the default route and not the other prefix but you are getting them so something is wrong.

The default route will be ok because 65100 is prepending so the mpls learned default will be preferred.

I agree if you look at the traceroutes theonly problem I see is the following

since both are using same as-path , and origin code my question is what is influencing the tiebreaker? if that makes sense

* 172.17.0.0 172.16.0.6 0 19855 65203 i

*> 192.168.7.181 0 65100 65203 i

How Can I see what is influcencing the decision to route the 172.17.0.0 traffic?

I can provde more config if that is needed but i'm not sure why traffic to 172.17.10.x and 172.16.0.0 goes the correct path but traffic to 172.17.4.0 or 172.17.5.0 goes over the longer 192.168.7.141 route

Hi There,

Can you post a "show ip bgp 172.17.0.0".. That should give us all the attributes..

sure - this is it on the Frankfurt router:

50Gro-GER-2801a#sh ip bgp 172.17.0.0

BGP routing table entry for 172.17.0.0/30, version 452

Paths: (1 available, best #1, table Default-IP-Routing-Table)

Advertised to update-groups:

1

19855

172.16.0.6 from 172.16.0.6 (80.241.64.8)

Origin IGP, localpref 100, valid, external, best

Extended Community: RT:19855:88001284

50Gro-GER-2801a#

Guys,

it appears this is now resolved. The following line was removed from the config:

neighbor 192.168.7.181 soft-reconfiguration inbound

and i think this has fixed it. any idea why this would be the fix?

When you configure bgp soft-configuration-inbound, all the updates received from the neighbor will be stored unmodified, regardless of the inbound policy

This might be the reason for the presence of the route even after your inbound filter.

BTW, did you try clearing the session after the above configuration?

clear ip bgp soft in

Narayan

In general you want to have soft-config on since it allows you to update the bgp without having to do a hard clear which will cause a interuption in the traffic.

You really need to clear your bgp everytime you make a change to the filters. Since BGP does not retransmit his updates that often and the new filter only takes effect on new routes not the old ones you can get strange results. Maybe when you turned off the soft-config it cleared the sessions for you.

If your configuration is working as it appears you should only get the default route over your tunnel and get other prefixes and the default with a better as-path over the MPLS so it should alway prefer the MPLS.

To the above question on why it picked the tunnel I think the tie break rule for external routes will end up being to prefer the route that is received first. This makes it kinda random.

If you are running in a private as there is the following bgp command

router bgp

neighbor x.x.x.x y.y.y.y ignore-private-as HTH