On 2009-05-23, Justin Credible <mista.justin.credi...@gmail.com> wrote: >> > >> > 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
this is not necessarily the case; if the route _from_ 172.16.1.1 to 192.168.253.211 is via 3356 then this is exactly what you'll see. but, you say changing the default route changes behaviour... >> > >> > 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? > > > Yes sir > > >> >> >> > 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. >> >> > Ok I think I understand that... So what should be my next move? > > What output do you get from these? route -n get <address> bgpctl sh rib <address> bgpctl sh fib <address> (<address> being where you're doing the traceroute from).
