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)