|
North American Network Operators Group Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical Re: IS-IS reference
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 <[email protected]> > > To: Vadim Antonov <[email protected]> > > Cc: [email protected] > > 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) >
|