dcooper at gulp.org
Tue Sep 14 18:58:55 UTC 1999
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?
> 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
> 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
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.
> 4) STATIC routing (except the customer's links).
> But it's the things all ISP was passed through a lot years ago...
> On Mon, 13 Sep 1999, Dave Cooper wrote:
> > Date: Mon, 13 Sep 1999 16:17:54 -0700
> > From: Dave Cooper <dcooper at gulp.org>
> > To: Vadim Antonov <avg at kotovnik.com>
> > Cc: nanog at merit.edu
> > Subject: Re: IS-IS reference
> > 1. Use IBGP and redistribute connected/static and when you can, aggregate
> > those statics/connecteds at each router.
> > 2. Use IGP (IS-IS level-2 or OSPF area0) for the backbone links and
> > IBGP, Any-RP loopbacks. Don't add instability to your
> > IGP when you have IBGP that can take care of it much more efficiently.
> > As long as IGP can reach/see each router's loopback, IBGP will
> > work great for connecteds/statics (just make sure you don't announce
> > these specifics to your peers).
> > 3. Don't use static routing for backbone links.... i am not sure how that
> > even came up. Remember this is a NSP of some sorts.
> > 4. Do multicasting, just make sure you get clueful on it. Its not rocket
> > science... and with PIM sparse/dense, its much easier than the DVMRP
> > days. (and make sure you get on a good IOS release and stay off the
> > buggy releases)
> > -dave
> > Vadim Antonov wrote:
> > >
> > > I think the right plan of action should be: a) design numbering plan allowing
> > > aggregation on per-location basis; b) design a dynamically-routed redundant
> > > backbone and c) attach tree-like access networks to the backbobne.
> > >
> > > The backbone should not take _any_ routing information from the leaf networks.
> > > It would also help to keep strict access controls, and separate backbone routers
> > > from leaf access routers, so only the authorized backbone engineers can change
> > > things in those.
> > >
> > > Leaf networks should do static routing, and no proxy ARP. This way any damage from
> > > badly behaving hosts or apps is limited to the segment they're on.
> > >
> > > And don't do multicasting.
> > >
> > > May be we should start defensive networking classes? :)
> > >
> > > --vadim
> Aleksei Roudnev, Network Operations Center, Relcom, Moscow
> (+7 095) 194-19-95 (Network Operations Center Hot Line),(+7 095) 230-41-41, N 13729 (pager)
> (+7 095) 196-72-12 (Support), (+7 095) 194-33-28 (Fax)
More information about the NANOG