North American Network Operators Group|
Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical
Re: Rapidly-variable routing on the time scale of seconds to minutes?
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: [email protected] -- [email protected] -- PGP: 0xA85C8AA0