""Howard C. Berkowitz"" wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... > >> -- 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.
RPSL is a great way of explaining routing policy. Even stranger I found it holds a lot of programming concepts like object-oriented-ness. But the language only goes as far as the real world implementations. Learning RPSL was one thing, but downloading all of the radb.db files over the years and reading through them was the real experience of a lifetime. > The first key question to ask here: what is the broad routing > paradigm? Cold potato/closest exit or hot potato/best exit? For a "peering routes" example, yes best-exit/closest-exist problems are super high on the agenda. However, that seems to be more of an IGP problem, and that's where regular knowledge of say, OSPF, is taken to a whole new level. And one that is never taught in any course or material in any classroom or even online. You learn that on the job at an ISP (does anybody else have any resources for this?). > >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. Reversal routing concepts are common in the workplace and unheard of in any labs/certification courses. > 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. Where is there information available in-print/online about the MED's topic? Another one completely skipped over. Most people are using IGP metrics alone these days, no need to try to translate. At least in the environments I've seen. This is a part of that whole closest-/best- exit argument above. I've never really seen any configs or designs for translating IGP metrics to MED, something like that would interesting to see - even if it produces oscillatory routing. Do you know why this happens? Can you try to explain the problems more effectively? > >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. Don't forget to automate the billing, RWhois/SWIP changes, and the rest. ;> Makes me wonder why anyone bothers to continue to get PA space ever. It might be easier to pick up some swamp space on eBay for $10,000, then to pay out to some ISP's and have to renumber in the end anyways. RIR's need to fix this. RIPE is doing a much better job. > >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? :-) Luckily there are lots of good books and even real-life experiences that you can purchase. And there's lots of people willing to share their experiences. There's a whole different industry and market there, Howard ;> I don't think you need to go to school or have certifications, at least my wife didn't ask for any credentials. > 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. That sounds really cool. Got any examples for those of us who can't wait? > 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. I would never argue against that concept! =] I thought the point of the thread was to identify places where there isn't *any* information out there, and stuff that's totally black-art. Cisco certs clearly don't have the whole ball-of-wax, but a lot of this can be easily incorporated into their curriculum. > Olivier Bonaventure, whom I believe reads this list, has developed a > superb document that I hope will move to Informational RFC. Yes, that one is especially good. He'll be at NANOG discussing exactly this: http://www.nanog.org/mtg-0206/bruno.html Interesting ones to me are the NO-PEER, Link Bandwidth, and the new Alvaro Retana "Cost Community". You're starting to see the BGP community concept explode into the feature creepism that every IETF protocol does. It will be a laugh to see how the Internet holds up to such concepts. They'll be combining BGP communities and LDAP and XML and NFS in no time. ;> > >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. I have a copy of it. You might want to check out http://www.ispbook.com/ in the meantime (the website that goes along with the book). I have some mixed feelings about the book, but I still have full respect for the authors. I'd rather not post to groupstudy my thoughts about the book right now (at least not on this thread), so email me in private if you'd like to know. > 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". If you need some reviewers, you can probably find some here (Hint, Hint) ;> > >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. Hahahaha, that's like saying ATM is a replacement for IP. Or CLNS. Actually IPv6 is a replacement for IPv4. Tell Nortel to work on that. > >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 > >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. But, in my opinion you need to "do the math" (literally) to understand the problem. Something that I doubt anyone would ever teach in a "shortcut certification course". > >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. Which part are we in violent agreement about? RIPE, Conditional Advertisment, or Multihoming NAT configurations? You've always said yourself, "what is the problem you are trying to solve?". Don't you think any of these applications of specific technology will help anyone? IOW: What is your opinion on how to handle the multihoming announcements problem? In the US, more specifically? Should Europe/Asia be handled any differently? Or do you not consider it a problem at all? Bring the cluesticks ON! Please don't say IPv6 because, well, ... we know ... we know ... -dre Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=44781&t=44778 -------------------------------------------------- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
