Re: Rapidly-variable routing on the time scale of seconds to minutes?

[Daniel Roesen <dr () cluenet de>]

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