At 7:58 PM -0400 5/22/02, dre wrote: >""Howard C. Berkowitz"" wrote in message >[EMAIL PROTECTED]">news:[EMAIL PROTECTED]... >> >> :-) well, my book on the subject, "Building Service Provider >> Networks," should be about to ship. >> >> Seriously, let's talk about several areas, beginning with BGP. Every >> BGP scenario I've seen or or heard of in the CCIE context, at best, >> looks at an extremely simple configuration with rules NEVER used in >> the real world. A few contrasts: > >The way Cisco teaches BGP irks me as well. They just don't cover >anything except the "basics". > >> -- in the real world, it's VERY rare to redistribute between a dynamic IGP >> and BGP. Sure, there are exceptions, but they are VERY carefully >chosen. >> A provider backbone CANNOT survive having 100,000-plus routes in its >> IGP, nor should it. > >I wouldn't say it's VERY rare.
There's something as key as OSI (actually more so) in this technology area that often doesn't get mentioned: the abstraction of routing policy (which is distinct from Cisco policy routing). I only started understanding what backbones actually were doing when I began to grok RIPE-181, which has been superceded by RPSL. >Take Philip Smiths' NANOG presentation >on Multihoming as an example. Many Enterprises may want to get "peering >routes or partial routes" and inject them into their IGP. The first key question to ask here: what is the broad routing paradigm? Cold potato/closest exit or hot potato/best exit? The second key question is how one should try for optimal Internet routing at the small to medium enterprise level. It may not really be that important. >Many ISP's may >want >to inject their IGP into their BGP for customer static routes (using a >route-map >to filter out all the junk). With considerable aggregation, yes. Alternatively, though, redistributing blackhole statics for their allocations is common enough. We've been learning a lot about that IGP metric direct translation to MED can be dangerous, and produce persistent oscillation. Those route maps may be the better way to set MED. >I would say this is VERY common. What's not >common >(and what you are referring to) is redistributing everything (IGP to BGP; >BGP to >IGP) for full routes (the 112,000 routes today). > >> -- In provider use, the main purpose of the IGP (or multiple instances of >an >> IGP) is to maintain connectivity among BGP routers. You may have a >> separate IGP instance for each POP or group of POPs. > >Next-hop information for BGP, correct. It holds the "infrastructure >addresses", >and I'm pretty sure you are familiar with this term since I think you >invented it. >So basically, a bunch of routed transit links (/30's or /31's if you can use >them) >and loopback interfaces (/32's) and not much else, if anything else at all. > >> -- To connect customers, there is MUCH more use of static and default >routes. >> You could not possibly run a provider network with the CCIE lab rule >of >> no statics or defaults. > >Service providers typically implement tons of statics and defaults, correct. >Most don't like it, though, and try to design around it for any >alternatives. Well, it depends. If you look at my NANOG and ARIN presentations on address management, this lends itself to being automated. A provider certainly has to keep a database of the address space it hands out. Once you have this database, writing a Perl script or even the DBMS reporting system can be used to generate ip route, DNS A/PTR, etc., records, which then get merged into .cfg files for routers and/or sent directly to the devices, using telnet/TCL/expect. > >> -- AS paths are longer and more complex than you can create with six or >> so routers. > >Most people cannot create/simulate the Internet in their house, very true. > >> -- There's a HUGE amount of things to be concerned with that aren't >strictly >> configuration, such as justifying/obtaining/managing address space, >> intercarrier relationships involving both economics and cooperative > > troubleshooting, DNS management, protecting against distributed denial >> of service, etc. > >This stuff is pretty easy, actually. At least once you start doing it and >getting >your head around the problems. Ummm...isn't that about what you say to a virgin about sex? :-) >CCIE doesn't teach ARIN/RIPE/APNIC >justification. But ARIN's/RIPE's/APNIC's websites teach it pretty well. > >The RIR's and IRR's aren't complex, they are just black art (sort of like >DNS >is). You have to know where to go to get the information, and you can't >just >sit down one day and learn it (well maybe you can). But there are a lot of >good resources out there on RPSL, etc, that will let you pick this up fairly >quickly. RFC 2622 and RFC 2650 are a fairly good start. Yep. A lot of tutorials as well at www.radb.net. I use extensive RPSL and pseudo-RPSL in explaining provider problem analysis in the new book. > >Learning about Inter-Provider relationships is easy, too, once you get >involved. >The best way, IMO, to get really involved quickly is to start talking to >your >local Exchange Point (EP) people. They understand these concepts and are >normally willing to share the information very in-depth to any person who >needs >to know. http://www.ep.net/ for information about your local exchange >points. > >As for the other two black-arts, DNS and handling DDoS/DoS, there *are* many >resources out there *and* the IETF has these topics well-defined. Cisco >doesn't >teach these concepts (at least, not IMO), but they aren't difficult to >learn. Exactly. But the point here is that the certification programs aren't enough to get started. This is one of the reasons people on this list keep emphasizing that proficient network engineers MUST learn to research on their own. > Most >people can just start reading the following list of RFC's and >Internet-Drafts and >understand 99% of what's needed in these two areas: > >DNS: RFC 1034 (Updated by RFC1101, RFC1183, RFC1348, RFC1876, RFC1982, > RFC2065, RFC2181, RFC2308, RFC2535) >DNS: RFC 1035 (Updated by RFC1101, RFC1183, RFC1348, > RFC1876, RFC1982, RFC1995, RFC1996, RFC2065, RFC2136, RFC2181, > RFC2137, RFC2308, RFC2535, RFC2845) >DNS: http://www.ietf.org/ids.by.wg/dnsext.html And the O'Reilly book, DNS and BIND >http://www.ietf.org/ids.by.wg/dnsop.html > Internet-Drafts at the above URL's >DNS: http://www.isc.org/products/BIND/ http://www.ultradns.com/ >DDoS/DoS: RFC 2196, RFC 2827, RFC 3013, RFC 2979, RFC 1858, RFC 3128 >DDoS/DoS: http://packetstorm.dnsi.info/DoS/ >http://packetstorm.dnsi.info/distributed/ > Which will require in-depth knowledge of RFC 791, RFC 792, RFC 793, RFC >768 > and/or TCP/IP Illustrated Volume I, and anything else applicable > >> -- BGP communities are far more important than in typical scenarios. >> You need to know why and when to set up your own, learn the values of >> communities set by other AS and under what circumstances you should >act >> on them, etc. Olivier Bonaventure, whom I believe reads this list, has developed a superb document that I hope will move to Informational RFC. > >There are starting to be a few good resources on BGP communities. Not >taught >by Cisco, of course, you have to go to NANOG for things like this. Dan >Golding >has given a few talks (one on Confederations that had a lot of material >covering >BGP communities, and another at the last NANOG24 specifically on topic). > >To be honest, I am going to give Cisco some credit, because the tutorials >that >Philip Smith and Barry Greene have up on >http://www.cisco.com/public/cons/isp/ >do talk fairly well to BGP communities concepts. They now have it extended to book length. Cisco Press is sending me a review copy that I expect to have this week, and will post my comments here and other relevant places. A stray comment pertinent to the arguments we see here about experience vs. lab rat, "Old Timers" who feel threatened by new and won't share knowledge, etc. Here's a book coming out almost simultaneously with my book on the same general area. I'm delighted! This is a sufficiently complex area that having multiple authors describing it in their own style will help the industry. I know Phil in person, but Barry only electronically, and I'm sure they will do a great job. I really have to think hard to consider them "competitors," rather than true professionals trying to "pay it forward". > However, this is not >material >being taught in the Cisco certified (CCNA, CCNP, CCIE, et al) learning >process. > >The IETF has not documented these BGP communities well either. After you >read >RFC 1998, you're like "ok, so how do implement communities, and why did I >read >this?". There are hidden pieces in internet-drafts (some expired, some >current) and >you have to go looking for them. Actually, to learn almost anything at this >level, some >of the only places to go for this type of information are expired >internet-drafts and old >archives of mailing-lists like NANOG. Here are the best resources for >learning about >organization of network resources, and it takes a lot of reading and a lot >of thinking: >http://www.watersprings.org/ (do a search for keywords on experimental >I-D's) >http://www.nanog.org/ (go into the old meetings and presentations, links, >and archives) > >> -- You may be dealing literally thousands of routers in your own network, >> interconnected with thousands of enterprise networks. You may also >have >> a complex ATM, SONET, MPLS, or other intelligent sub-IP technology >that >> must coordinate with the IP. > >Sub-IP is also not covered by Cisco as well as it should. ATM is covered, >but not >required for CCNA (only CCNA-WAN) or even any of the other certifications. >Plus ATM is going the way of the do-do for large backbones anyways. Knowing >ATM used to make you top-notch in the backbone, now it makes you >niche-market >in the access layer. > >SONET and WDM are even bigger today than MPLS. Knowing O-E/E-O layers, >SONET layers (including GR-253-CORE, BLSR, UPSR), C/L/S bands, etc is >being taught by Cisco, but not for the regular certification tracks. Even >Gigabit >Ethernet and Metro Ethernet and SONET muxed Ethernet (Optical Ethernet) >isn't >very well taught. These are very critical areas for the backbones of today >and >tomorrow. > >I think MPLS is still niche, like ATM, but it's better to know it when you >are going >to need it. Cisco all but invented MPLS as Tag-Switching, and they have the >resources, *and* it *is* becoming a big part of their future certification >curriculum. I see it starting to take off, but a key concept, which I'm not sure that Nortel yet understands, is that it is complementary to IP routing, not a replacement. > >> -- There's a different viewpoint on convergence. It's generally accepted >> among large providers and researchers that the worldwide "BGP table" >> never truly converges -- changes come too fast. We have to work in >that >> environment. > >But you can "sort of" find out what's changed and what hasn't changed. One >way to look at the churn is to do a "show ip route | i , 00:00" every minute >(shows you routes that have converged in the past minute). Another would >be to collect dumps of the routing table and/or BGP table in intervals and >compare them Unix "diff"-style. You can then make comparisons against >the rest of the BGP table (like AS-paths) and/or SNMP IF-MIB-like data >to find out what changed where (and possibly why). Sort of, sure. Craig Labovits and the late Abha Ahuja did a lot of it. My colleagues in the Babylon project are working on this. Phil Smith, Geoff Huston, and others publish reports. But the point I want to make is these are statistical characterizations. The table never truly becomes stable when you are handling full routes, and the research proposals in the IRTF and elsewhere recognize that trying to get global synchronization is like my cat running away from his tail. > >> -- Customers frequently multihome in ways that require coordinating >between >> their providers, even when those providers are competitors. > >Back to the IRR/RPSL concepts, ISP's do filter. PA space is becoming less >and less useful for multhoming purposes -- in Europe, ISP's only allow RIPE >PI space generally and won't do the PA space multihoming like US ISP's do. > >Smart people in this day-and-age that are would-be users of PA space instead >opt into different strategies like conditional advertisement or Doyle Volume >II's >section of the book on Multihoming NAT. But there aren't many smart people >in this day-and-age. We are in violent agreement. Hopefully, I will be able to have physical clue sticks made up soon. > >> -- As opposed to an enterprise network where SOMEBODY is in control, the >> provider space involves cooperative anarchy. One AS fouling up its >> configuration can and has had worldwide effects. > >A lot of this stuff has been, is, and will be covered by Caida and Nanog. >DNS, BGP, DoS, etc -- "global instabilities" are very interesting problems. > >What do you do when someone starts using YOUR AS NUMBER? >What do you do when someone starts annoucing YOUR NETBLOCK? >What do you do when someone sends a million bogus requests to the > root name-servers every few seconds? >What will the next Nimda, Red Alert, Internet Worm, etc .. look like? >Etc. > >These are questions that most network engineers rarely ask themselves. >And these are topics that aren't taught by Cisco, per se. At least not in >the core curriculum. > >> These are just a start. There are other people that can comment on >> some of the differences. Peter van Oene (yes, I'm volunteering you) >> is one with lots of good experience. There are others, and this >> actually might be an interesting thread. > >I think it's a great thread. Thanks for your input, Howard. > >-dre Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=44778&t=44778 -------------------------------------------------- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
