[isp-bgp] RE: BGP advantages

[James <haesu@...>]

On Tue, Sep 07, 2004 at 03:58:52AM -0400, Dean Anderson wrote:
> > From: "Arie Vayner" <ariev@....il>
> > 
> > You would be loosing the ease of load balancing. The advantage of the
> > Link Proof that it load balances automatically, where with BGP you would
> > have to "tweak" it manually all the time.
> 
> People do tweak BGP to adjust load on links, but this is usually dubious.  
> I've heard that an MIT group studying BGP has found that 20% of all
> network failures are preceeded by BGP alterations by about 15 minutes.  
> While not actually conclusive, the obvious suggestion is that admins cause
> 20% of the outages, and their activity is indicated 15 minutes prior to
> failure.  Such tweaking can only directly affect routes taken by packets
> going out, though communities do allow some adjustment of how advertised
> routes are used.

I tend to agree with you here.. I personally don't find tweakings and black
magics on BGP to hack around as a QoS type appealing. Some people view BGP as
their god for traffic, and in my most experience, it causes more troubles than
it fixes. In my point of view, BGP is very useful and simple when its kept 
simple when possible -- try to run it over equal sized links for example instead
of trying route load balancing over a whacked unequal ratio (i.e. multihomed
between a T1 vs. FastE).


> 
> > Also real load balancing would be effective only if you have many users
> > and they are all going out on the internet with different ip addresses
> > (and not via a single hide-nat address)
> > BGP works well only on a highly statistical network (with many users and
> > destinations)
> 
> I wouldn't go that far. BGP does not prevent fine grained load balancing.  
> But the large router vendor uses a flow cache that sends all traffic in
> that flow out the same interface. Thus, only new flows get to choose new
> routes. This is good because the router doesn't have to search 150K routes 
> for each packet, but the usually much smaller flow cache. The flow cache 
> has also been acl checked, so that is quicker as well.  If a flow is 
> already cached, the routing tables and acls won't be consulted.   Of 
> course, a new hardware generation could keeps sets of outgoing interfaces, 
> or simply expire the cache more quickly.


The newer implementation of today's internet backbone routers no longer use
the flow cache (ofcourse, dependent on operator's operating procedures and
local configuration of each device) to forward the packets. ~150k routes are
all compiled into prepopulated FIB designed for fast insertions, deletions and
lookups right on the fly, popular implementation being a 256-way 4-level mtrie.
There is no flow cache in a FIB, so you still gain granularity in next hop
destinations as if you had plain RIB -- except FIB is much faster and smaller --
It is trivial to get 135,000 routes to fit in a 1MB L2 cache of a Intel Xeon 
CPU.

Cisco CEF is one of the implementations doing this. Using netflow under CEF
will turn on the flow activities, however router itself will run and count the
flows purely for statistical and accounting purposes, but not for actually
forwarding and acl'ing the packets.

On hardware assisted forwarding, you then have the option of using TCAM to
store the FIB, which allows hardware assisted database structure for extremely
fast lookups. TCAM memories are expensive per byte, but optimized mtrie FIB can
fit inside most TCAM sizes used by big router vendors.

While flows are fast and nice on a well behaving network, it has become 
increasingly apparent to not scale in the event of increasing extensive worm
traffic and internet noise that bombs the random destination. Using an optimized
FIB has proven to work as the best for today's scenario.

> 
> > From: Jon Lewis <jlewis@...>
> 
> > On Mon, 6 Sep 2004, Dean Anderson wrote:
> > 
> > > You need to have portable address space before BGP is going to useful.
> > 
> > That's not entirely true.  Multihoming to 2 or more providers using
> > BGP to announce PA address space from one of your providers to all of your
> > providers works just fine generally.  The main disadvantage is you're
> > still tied to that provider for the IPs and will have to renumber if you
> > want to dump that provider.
> 
> The more specific prefix will get advertised and used if both prefixes are
> in table, but this isn't a /good thing/:  It creates untenable route table
> growth.  You can imagine what might happen if another 100,000 companies
> wanted to advertise /28's.  Also some ISPs will reject small prefixes, or 
> won't accept non/16 prefixes from legacy class B space (verio).

I've been hearing rumours that Verio has stopped filtering in many places, one
statement even from a higher-up network engineer there.. But I can't prove this,
however their claim was that today's hardware has far more advanced that its
more of an annoyance to keep up with filtering than let it all go (as long as
its shorter than /24 yadda yadda).

Either way, the impact of /24 or small sizes not being reachable has reduced
significantly over the past few years, and my expectation is that it will remain
on that course as the time moves forward.. Only time will tell.. 

-J

-- 
James Jun                                            TowardEX Technologies, Inc.
Technical Lead                        Network Design, Consulting, IT Outsourcing
james@...                  Boston-based Colocation & Bandwidth Services
cell: 1(978)-394-2867           web: http://www.towardex.com , noc: www.twdx.net







To unsubscribe via postal mail, please contact us at:
Jupitermedia Corp.
Attn: Discussion List Management
475 Park Avenue South
New York, NY 10016

Please include the email address which you have been contacted with.