On Mon, Jan 31, 2005 at 09:59:39PM -0500, Charles Shen wrote:
From the responses, the answer to "the rapidly-variable routing on the time scale of seconds to minutes" seems to be:
1. It could be link layer load balancing, with the two interfaces belonging to the same router. 2. It could be per-flow load balancing where flows are defined via both L3 and L4 info, so traceroute probe could not reflect the truth.
That's no contradiction as far as I read it. Wether the two equal-cost paths are terminated on the same routers doesn't matter actually.
My question is then: would it be safe to argue that the above two causes explain all (or most of?) the observed "fluttering" routers?
Taking seldom observed, transient control plane convergence effects (IGP/BGP converging while traceroute is used), probably yes.
(some examples listed below)
Well, to see wether flow-balancing is used, use e.g. TCP traceroute. If you see "stable" results (all three probes of a hop matching) there all the time, ...
What we are concerned about is per-packet load balancing (packets in the same flow go through different paths), which will cause trouble to protocols that install state information in routers along the flow path.
Modern core router hardware like Juniper (IP2 ASIC) can't do classic per-packet load balancing anymore at all, only per-flow balancing. I'm not sure for the GSR platform, but as far as I remember, it's not supported at all on Engine 2 line cards, and has a performance penalty otherwise. Exec summary: I seriously doubt the larger shops do so, either because their hardware can't do so at all (Juniper-based cores) and/or people know that per-packet load balancing leads to packet reordering which might make your customers quite unhappy. It's generally a bad idea. Best regards, Daniel -- CLUE-RIPE -- Jabber: dr@cluenet.de -- dr@IRCnet -- PGP: 0xA85C8AA0