On 2009/05/23 13:57, Justin Credible wrote: > On Sat, May 23, 2009 at 4:08 AM, Stuart Henderson <s...@spacehopper.org>wrote: > > > On 2009-05-22, Justin Credible <mista.justin.credi...@gmail.com> wrote: > > > I am running OpenBGPd on an OpenBSD 4.4 router. > > > > > > Some times when traffic goes over one peer and finally gets to our > > router, > > > the last hop will respond as a different peer. For example: > > > > > > Level3 IP 10.0.0.1 > > > Global Crossing IP 192.168.0.1 > > > > > > Traffic traverses Global crossing all the way, last hop, 10.0.0.1 > > responds > > > and vice versa. > > > > > > I noticed If i set one default gateway, this is always the IP to respond > > at > > > the last hop. If i set multi-path default gateways then random IPs > > respond > > > at the last hop. > > > > > > Is there a common way that I am missing to get around this? Am i > > overlooking > > > something on the man pages? > > > > > > Thanks for your help! > > > > > > Regards, > > > > > > Ken > > > > > > > > > > If you're doing a traceroute to an address configured on the router > > itself, it should reply from that address. Are you seeing something > > different there? You definitely shouldn't. (ip_icmp.c:656) > > > > If you traceroute _through the router to another host_ (ip_icmp.c:668) > > it will do a route lookup for the source, and use that as the source > > address of the ICMP message (which is what shows in traceroute). > > > > What routes do you carry besides the default? No matter where default > > points, if you have a specific route for the source of the traceroute > > packets then it shouldn't be using the default. i.e. if you carry full > > tables, you shouldn't see this. > > > > I point default at "localhost -reject" and take full tables and never > > saw any strange behaviour with source address selection. > > > > > Thanks for the response Stuart! > > I should have phrased that differently, sorry about that! What I mean by > "the last hop" is "the last hop before the destination" so the second-last > hop - My bad. > > So here would be another example. > > A traceroute should be: > > Traceroute 172.16.1.1 > 1.192.168.253.211 AS3549 > 2.192.168.24.5 AS3549 > 3. 192.168.0.1 AS3549 > 4. 172.16.1.1 MYASN > > But instead it would look something like this: > > Traceroute 172.16.1.1 > 1.192.168.253.211 AS3549 > 2.192.168.24.5 AS3549 > 3. 10.0.0.1 AS3356 > 4. 172.16.1.1 MYASN > > So the IP address which i use to peer with Level3 responds at the second > last hop, rather than the Global Crossing IP since it traversed the entire > way through Global Crossing. Both of the IPs which respond at the second > last hop are on my router so the problem is on my end. It doesn't appear to > be a BGP problem as much as a default route problem.
So, this part of my mail applies: "If you traceroute _through the router to another host_ (ip_icmp.c:668) it will do a route lookup for the source, and use that as the source address of the ICMP message (which is what shows in traceroute). What routes do you carry besides the default? No matter where default points, if you have a specific route for the source of the traceroute packets then it shouldn't be using the default. i.e. if you carry full tables, you shouldn't see this." Do you carry full tables? > I tried adding "reply-to" rules in my pf.conf so that traffic that comes in > on one interface will go out the same interface but that doesn't seem to > work either, since the reply from the wrong address happens before or during > the state that stateful connections are being established. PF isn't involved in this address selection, it's a message from the router's IP stack because the TTL was exceeded, the lookup is entirely done in the stack, reply-to isn't used.
