|
North American Network Operators Group Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical Re: IS-IS reference
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... 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...). And the second difference is how to use 'communities' to control bgp advertisements - for example, add 'PEERING', 'CUSTOMER', 'BACK-UP' communities and use them. Very stable, widely used, well debugged schema. The hellish things are: 1) 'aggregate' word - use static routing to 'null' everywhere you can instead; 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; 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 <[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)
|