From: Przemyslaw Karwasiecki (karwas@xxxxxxxxxxxxx)
Date: Thu Aug 22 2002 - 14:22:27 GMT-3
Please see my $.02 about BGP:
1) I would risk a statement, that BGP is a very simple protocol,
with very convoluted and "not-so-obvious" idiosyncrasies
in IOS implementation. After all, it was originally called
"3 napkins protocol" :-)
2) Primary goal of BGP, is simply to distribute information about
which prefixes are available via which NEXT_HOP
3) In addition to this, for each group of prefixes, BGP disseminate
some additional informations, like path to final destination
(AS_PATH), like origin of those routes in BGP (ORIGIN), like
preference to use in local AS (LOCAL_PREF), etc, etc...
3a) It is also extensible (COMMUNITIES), so one can define
its own set of attributes and their semantics, by simple
defining some communities and their meanings
After saying all of this, it will be very tempting to thing
about BGP as some king of "distributed database system",
distributing reachability information with associated NEXT_HOP
used either by recursive route lookup, or maybe, by some pre-build
mesh of MPLS tunnels to each and every NEXT_HOP.
There is one substantial difference though -- BGP is more distance
vector then SPF type of protocol. One of its fundamental rules
says: "Never advertise to other peers, reachability information
you will not use by yourself". So, if BGP router will select some
NLRI over some other, it will never advertise to its peers
information about "worse" NLRI
But in the nutshell, it is just a protocol, which is redistributing
reachability information used later (by consulting NEXT_HOP value)
for forwarding. And, the way how do you learn about reachability
to specific prefix, and the way how you will forward packets there,
are totally separate.
Very simple example: in a typical meshed network running
route-reflectors, simple existence of such, creates tree-like
hierarchy. Does it implies, that traffic will be forwarded
via root of such tree, following BGP dissemination of reachability
information? Of course not.
R1 (route reflector)
/\
R2 R3 (route reflector clients)
Traffic from router R2, forwarded to prefix originated into BGP by R3,
will be forwarded via whatever IGP path is selected to NEXT_HOP
on router R3. There is no need to pass traffic via R1.
(This example is based of course on assumption,
that there is a link between R2 and R3)
Rest, is just bunch of rules, how to select "best" routes among
all received routes, how to validate them etc.
And, unfortunately, some of these validation rules, are simply
legacy ballast. That is how I look at stuff like synchronization.
Who is really using it? Who cares about RFC 1364 or RFC 1403?
Funny thing, RFC 1771 doesn't even talk about comparison of length
of AS_PATH in best route selection process.
--As I said, this is just my view, others can disagree,
Przemek, #9958
On Thu, 2002-08-22 at 12:00, perkinsr@WellsFargo.COM wrote: > I need some help with BGP. When reading the labs, I never get a clear > feeling for what the ultimate goal of configuring BGP is. When configuring > IGPs the goal is to have connectivity from every subnet to every subnet. > With BGP this isn't always the case. > > When I read the lab I have no problems deciding who should be neighbors > (that is usually explicitly stated) and what kind of relationship to make > (e/ibgp, confederation, route-reflector). Once I have that going and some > entries in the bgp tables I start to think about synchronization and > redistribution and then get all glossy eyed and pass out. I freeze up and > don't know what direction I am going. > > After considerable thought about what my problem is I only can guess that > the goal of BGP is to provide connectivity from every AS to every AS, and > this doesn't mean that I can get to every subnet in every AS, just the > subnets that are part of BGP. > > Does anyone have any guidance on this? I am lost and by the time I get to > the more advanced topics in BGP I am totally out of focus and don't > understand why I am doing what I am doing. > > > TIA > Ray
This archive was generated by hypermail 2.1.4 : Sat Sep 07 2002 - 19:48:33 GMT-3