Slashdot: Providers Ignoring DNS TTL?

Dean Anderson dean at av8.com
Sun May 1 04:44:09 UTC 2005


On Sat, 30 Apr 2005 sthaug at nethelp.no wrote:

> > > First of all, let's ditch the term "PPLB."  The usual alternative to per 
> > > packet load balancing (what's been being talked about here) is per prefix 
> > > load balancing, which would also be "PPLB."  The abbreviation is therefore 
> > > more confusing than anything else.
> > 
> > Err. No, that would be worse. "Per prefix" load balancing is an artifact
> > of the Cisco route cache. The route engine (ie the route table) isn't
> > queried for every packet. Instead the route in the route cache is used.  
> > One doesn't configure "per prefix" load balancing. One configures load
> > balancing, which adds multiple routes into the route table.
> 
> Modern Cisco routers do not use a "route cache", 

You'll need to define what you mean by "modern" with respect to cisco.  
This statement seems to be incorrect.

> they use a fully populated forwarding table. And load balancing is
> automatic if you have several equal cost routes.

This sounds very much like the Juniper description for the Internet 
Processor ASIC behavior. I'd say that's worse.

> > The route cache then causes only one of these routes to be used.  On
> > cisco, to enable PPLB, you turn off the route cache.
> 
> Many modern Cisco routers can perform per-packet load balancing without
> doing process switching (but this needs to be explicitly configured).

Well, 7500 and 7200 have interface processors that can route packets using
the route cache without interrupting the main processor. So, if you don't
consider 7500's and 7200s to be "modern", this feature above doesn't seem
like a big deal: They could do that before. It was called CEF and DCEF.

> > On Juniper, you configure it to put multiple routes in the route
> > table.  Its actaully more likely to happen on Junipers, because unless
> > you configure additonal policies, you get load balancing on divergent
> > links as well as non-divergent links.  On
> 
> Modern Juniper routers cannot do per-packet load balancing *at all*. It
> is correct that the configuration statement says "per-packet", however
> it is really per-flow (and this is well documented). See for instance
> the description of Internet Processor II ASIC load balancing at
> 
> http://www.juniper.net/techpubs/software/junos/junos70/swconfig70-policy/html/policy-actions-config11.html#1020787

I don't have Junipers, so I'm just going by what the manual says. And your 
link says: 

"On routing platforms with an Internet Processor ASIC, when per-packet
load balancing is configured, traffic between routers with multiple paths
is spread using the hash algorithm across the available interfaces. The
forwarding table balances the traffic headed to a destination,
transmitting it in round-robin fashion among the multiple next hops (up to
a maximum of eight equal-cost load-balanced paths). The traffic is
                                                    ^^^^^^^^^^^^^^^^
load-balanced on a per-packet basis."
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

"On routing platforms with the Internet Processor II ASIC, when per-packet 
load balancing is configured, traffic between routers with multiple paths 
is divided into individual traffic flows (up to a maximum of 16 equal-cost 
load-balanced paths). Packets for each individual flow are kept on a 
                      ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
single interface."
^^^^^^^^^^^^^^^^

I would gues that since both processers are described, that they are both 
still supported, and that probably means that both are widely used.

But, I should qualify that doing PPLB on diverse paths is more likely to
happen on the Internet Processor ASIC. It would seem like the Internet
Processor II ASIC has an architecture more like the cisco 7500s, and only
allows per flow load balancing.

So, I guess it depends on how many people might still be using the 
Internet Processor ASIC platforms. And of course, whether this behavior 
might be disabled in some future release for the 'II ASIC or if some new 
platform might have PPLB on diverse paths.

> I'm afraid your statements show a certain lack of knowledge about modern
> router architectures.

I'm afraid your statements show a certain lack of knowledge about whats
being used in datacenters to route packets. And perhaps some arrogance
about whats "modern".  I'd still call cisco 7500 and 7200 series routers
"modern", and they have route caches.  I don't know that much about GSRs,
but they didn't seem to get much traction. I can't say whether they have a
route cache or not.  And the multi-rack monster router that cisco just
announced a while back doesn't seem to be too popular either. I don't know
its architecture, either.  As I look around datacenters, the 7500 and
7200's and to some lesser extent Junipers are the workhorses doing most of
the routing.  And that basic technology will stay around in the enterprise
for many more years to come.

But again, note that RFC 1546 give a rule about internetwork architecture:

   An internetwork has no obligation to deliver two successive packets
   sent to the same anycast address to the same host.

Whether it used to be impossible to utilize this rule, and whether anyone
actually presently uses this rule is irrelevant to the question of what
rules one needs to follow when building anycast systems.  RFC 1546 gives
some rules to follow, and they are violated at the peril of the
internetwork.

And "vixie-cast" violates this rule. It imposes the new rule that "an
internetwork must deliver to successive packets sent to the same anycast
address to the same host."  And no one has thought much about the
implications of that rule.

Assurances that no one can do PPLB on diverse paths offer no defense to
having violated the design principles given for anycast in RFC 1546.

It is also objectionable to calling something "TCP anycast" that isn't TCP
anycast according to RFC 1546.

		--Dean

-- 
Av8 Internet   Prepared to pay a premium for better service?
www.av8.net         faster, more reliable, better service
617 344 9000   







More information about the NANOG mailing list