Ok, first - i wouldn't use cisco.com to learn how to build
a backbone. Otherwise, if you buy a Juniper you'll have a
coronary. And conceptually, the Halabi book works for the
most part, but there are some differences in how most
backbones apply those concepts and how they are presented there.
Second - read responses below.
Alex P. Rudnev wrote:
I wonder what are you talking about? How to buil ISP back-bone?
Open
www.cisco.com, read BGP topic, and do just as 99% of IS do - IGP f-r the
inter-router routing, IBGP for the customer's networks, 'network' +
'static -> Null' on the edges to generate your own aggregates...
Ok... maybe I didn't specify in detail.. although Randy may ding me
again for being redundant. sorry randy.
1. if you are going to scale a large national backbone, limit as much
as you can in your IGP. the less fluctation in flooding protocols, the
better. and since most backbones run on a single area (on the main
IGP process) or level-2 only, then fluctuations cause headaches for
all participating routers. this is especially so when you have a
full layer-2 mesh or a full MPLS mesh.
2. if you read what i stated below.... it says, use IBGP for
statics and connecteds.... then aggregate when possible.
Sorry if this is too vague.. but i am referring to all other
connections/statics that are not backbone. my use of
the word aggregate did not mean use the aggregate command
in Cisco's bgp, it meant aggregate to a larger netblock (/30's -> /24)
and yes... you use the static->null route to inject it into the
table and then redistribute into BGP:
router bgp xxx
redist static route-map [tag communities and filter]
redist connected route-map [tag communities and filter] *
* connected is optional if you can get all
your connecteds into larger aggregates. then
they are injected statically.
3. hmm... 99% of the larger backbones do all intra-AS routing using
the IGP.... i think i saw this thread get beaten to death a few months
or a year ago. this is arguable.
The only problem is the absense of the good config tools for the routers
with the object library (through new commercial CISCO tools looks not too
bad, but are very expansive...).
even those aren't ready.
And the second difference is how to use 'communities' to control bgp
advertisements - for example, add 'PEERING', 'CUSTOMER', 'BACK-UP'
communities and use them.
thanks... I will remember that.
Very stable, widely used, well debugged schema.
The hellish things are:
1) 'aggregate' word - use static routing to 'null' everywhere you can
instead;
see above
2) 'redistribution' from/to IGP - prevent it. Really, the any TO/FROM bgp
redistribution (except may be static/connected in some cases) is the bad
thing;
even redistributing static/connected into IGP will increase the IGP's
workload by introducing additional routes, thereby, exhausting more cycles.
again... let IBGP handle that.
3) full IBGP mesh - use reflectors instead.
agree 100%
4) STATIC routing (except the customer's links).
agree 100%
