""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. 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. 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). 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. > -- 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. 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. 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. 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 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. 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. 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. > -- 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). > -- 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. > -- 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=44768&t=44768 -------------------------------------------------- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
