Home
| Calendar
| Mail Lists
| List Archives
| Desktop SIG
| Hardware Hacking SIG
Wiki | Flickr | PicasaWeb | Video | Maps & Directions | Installfests | Keysignings Linux Cafe | Meeting Notes | Linux Links | Bling | About BLU |
Hi Patrick, Thank you very much for your detailed explaination :) ----- Original Message ----- From: "Patrick R. McManus" <mcmanus at ducksong.com> To: "Vriz" <vriztll at hotmail.com> Cc: "__Boston Linux Mail List" <discuss at blu.org> Sent: Friday, April 19, 2002 10:46 AM Subject: Re: IPv6 Routing Header - How does it work? > [Vriz: Fri, Apr 19, 2002 at 10:29:13AM +0800] > > I see. Actually, I'm not trying to state a route for my packet to go. > > It's just that I would like to find out the route my packet has taken from a > > source to a destination. > > If I'm not wrong, I think traceroute in linux does that. However, I would > > like to know how it is done. > > ah! This is a much easier question! > > yes, traceroute shows you the path your packets take from you to the > destination. > > It does this by manipulating the TTL (time to live) field in the IP > header. TTL (in practice) specifies the maximum number of hops a > packet may travel. Each time a router forwards a packet it reduces the > TTL by one (technically max(1,# sec q'd at router), but generally > implmented as just 1) - if a packet has a TTL of 0 it gets dropped and > the original sender is notified via an ICMP_TIME_EXCEEDED ICMP > message. The normal purpose for a TTL is to prevent loops from filling > the network with endlessly forwarded packets. > > traceroute starts out by sending its probe with a TTL of just 1. The > first router gets the packet, decrements the TTL and discovers that it > can't forward it anymore - so it sends the ICMP notification to the > original sender and drops the packet. The original sender uses the src > address of that ICMP message to identify the first hop router. It then > repeats the process with a TTL of 2 to find the second hop router, > etc.. > > There are a whole slew of reasons why this fails to work now and again > in practice (links that filter icmp, and routers using private rfc 1918 > address space combined with links that filter private addresses being > the 2 most common.), but its a pretty good technique overall. > > when this works, this tells you the path from your src to the > destination. It doesn't tell you anything about the path from the > other end towards you - and asymmetric paths are common. Figuring the > latter out is much trickier. > > > And if my packet has travelled from a source to a destination using a > > specific route, does that mean it's going to be more or less unchanged for > > my other packets (same source and destination)? > > they call this 'fate sharing' - and you can assume this with a > fair degree of certainty - but its hardly absolute. There is some > routing that takes port numbers into account, as well as switches and > routers that simply load balance their traffic - but the latter > introduces reordering (you send packets 1,2,3 and they arrive 1,3,2) > which has a bad impact on tcp performance and so networks try and > engineer so that doesn't happen too much. > > -Patrick > > > > _______________________________________________ > Discuss mailing list > Discuss at blu.org > http://www.blu.org/mailman/listinfo/discuss >
BLU is a member of BostonUserGroups | |
We also thank MIT for the use of their facilities. |