On 2009-05-24, Justin Credible <mista.justin.credi...@gmail.com> wrote: > On Sat, May 23, 2009 at 6:35 PM, Justin Credible > *> 199.185.136.0/23 64.x.x.x 200 1 3549 812 812 812 812 3602 > 22512 i > * 199.185.136.0/23 212.x.x.x 100 500 3356 6453 812 3602 22512 i > # route -n show | grep 199.185.136 > 199.185.136/23 212.x.x.x UG1 0 0 - 48 vlan400
this is pretty wierd, bgpd thinks it has installed a route to the kernel (*>) but it isn't actually there. I've seen something a bit like this once, when I botched a router upgrade and managed to upgrade /etc/rc.conf but not /etc/rc, which resulted in an old copy of routed being accidentally run and messing with the routes from the other routing daemons. (I noticed the problems but didn't find what was causing them until I happened to do 'route -n monitor' and noticed route changes were coming from separate process ids, which made me look at which daemons were running). ... >> >>> I don't know why that setting in particular set all of my routes to >>> point at Level 3 regardless of the preferential settings against it, >>> but how i got around it is simple. >>> >>> route add -mpath default gw1 >>> route add -mpath default gw2 >>> etc... >>> >>> Then change that setting to >>> >>> nexthop qualify via default >>> >> >> Why did you set this? Just for fun or was there a reason behind it. >> If you need to use "nexthop qualify via default" or "nexthop qualify via >> bgp" then you have an error in your network setup. Either you should use >> an IGP (like ospfd) or have a static route to the bgp router. > > I toggled this setting to see if it would make a difference on the > routing tables. My main reason for setting preferred routes is because > BGP was selecting Level3 as default for our route to Latin America. We > implemented GBLX since there are only two or three hops to Latin > America through them, but BGP wasn't selecting them by default, BGP doesn't know about hops, only AS paths. (And in reality you can't tell much from "hops", fewer IP hops might just mean they have longer and more complex tunnels of one sort or another). One tool for dealing with sending certain geographic regions via a particular transit is to have your providers tag their routes with communities denoting the geographic origin (some do this, others don't. see as3356 whois entry for examples of what level3 do). You can use this, or alternatively hand-selected AS, in match rules in bgpd.conf and adjust localpref/weight/prepend to influence outbound traffic. Note that localpref is a sledgehammer approach; a hugely long AS path with localpref 101 beats a very short path with localpref 100. Influencing the route traffic takes to reach you is trickier and a lot less direct. > therefore i had to manually intervene. This setting seems to have > fixed that particular problem but the problem in thread "BGP > responding with wrong IP address." still exists somewhat. In a way > they are related, in more ways they are not, that's why I have them as > separate threads. Host X traceroutes through your router. If your kernel route _to_ host X is via level3, it doesn't matter how their packets reach you, your level3- facing interface is the one that will show up. And with the problem you've got where kernel routes don't match the routes bpd is trying to use, this obviously causes the problem much of the time.
