>3/28/2001 12:55pm Wednesday
>=20
>Would anyone care to elaborate on IBGP neighbors?
>Must they always be fully meshed or do route reflectors negate this?
>=20
>=20
>Richard L. Pickard
>[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]> (312) 560-6482
>=20
Perhaps too elaborate a response, but...
One of the practical limits of scaling a BGP implementation is the
number of neighbors with which it peers. There is no single factor
involved here, but
the challenges include:
-- maintaining TCP sessions and BGP keepalives
-- the more peers, the more likely an update, so the more likely there
is to be a frequent need to:
filter route updates
recompute the BGP Loc-RIB
Different strategies are involved in reducing workload for iBGP and
eBGP peers. For iBGP, the basic approach is to reduce the number of
peers by splitting the AS into smaller sub-topologies. Route
reflectors are the most common way of doing so, although
confederations also can serve a similar function.
There's evolving interest in building ISP topologies that have an
intra-provider core that runs little or no BGP. Edge routers run the
BGP, and create MPLS tunnels across the core. The core may run a
fast-converging IGP to help MPLS find alternate paths.
Peer groups can help both iBGP and eBGP.
To reduce the eBGP peering workload, one strategy, historically used
at multilateral exchange points, is to peer with a route server
(i.e., typically a UNIX box that runs route computation code only --
usually RsD -- with no forwarding). While this technique is less
popular than it once was, you essentially create an eBGP reflector
cluster, with the route server acting as the reflector.
Other measures help scale eBGP by limiting the amount and frequency
of routes that can hit the router. These include flap dampening,
maximum received prefix limits, etc.
In the global Internet, things are going to get worse before they get
better, so appropriately scalable implementation is important. At
the IETF meeting last week, there were both public and private
discussions about the global routing system. Some of the trends we
are seeing:
-- exponential growth in prefixes, especially more-specifics of existing
prefixes that primarily are being advertised for multihoming and
traffic engineering.
-- more non-transit AS (because more enterprises have their own policy)
-- more instances of paths to a given destination (i.e., there might
be 10 different AS paths to a given destination, where 4 to 5 was
typical not long ago)
-- shorter AS paths (hierarchy is tending to go away)
The short- and medium-term fixes aren't going to be pretty. One of
the problems is that scalability tends to demand hierarchy and
structure, while the free market and lack of clue tends to more
chaotic routing. It was Talleyrand, I believe, that asked "must every
little language have its own country?" There's a parallel in the
Internet: must every small user have its own routing policy?
_________________________________
FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html
Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
