Re: IS-IS reference

[Dave Cooper <dcooper () gulp org>]

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%

> 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 () gulp org>
> > To: Vadim Antonov <avg () kotovnik com>
> > Cc: nanog () 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)