North American Network Operators Group|
Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical
Re: Slashdot: Providers Ignoring DNS TTL?
On Sat, 30 Apr 2005 email@example.com 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