""Howard C. Berkowitz"" wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... > At 11:27 PM -0400 5/22/02, dre wrote: > >> 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. > > Not necessarily an IGP problem, but possibly an edge router that > classifies traffic, possibly with communities signaled to an > aggregating router, or using policy routing to MPLS tunnels.
You really think that's likely? I always saw it as: same weight/local_pref -> external route -> same as-path -> same origin type -> *then* MED (some people doing annoying internal IGP metrics (based on fiber distances) to MED's, others doing more intelligent, yet also annoying values that force you to do best-exit, but end up costing you money until you local_pref and force shortest-exit, and lastly smart people who tell you they are doing MED's based on delay or congested peers or *ahem* antiquated equipment (can you say AGS+?) and you listen to them because you are friends with the guy or some equally similar situation). Now, what's the next step if MED is the same? Your IGP metric. Boom. Doing something like DS-TE (which it sounds like you are mentioning as common practice for best-exit routing) is unheard of to me. > >Reversal routing concepts are common in the workplace and unheard > >of in any labs/certification courses. > > Are you mentioning reverse path verification as well? Good catch. ;> Actually, I had the idea of reverse triggers using BGP and source-specified routing a long time ago (to actually stop spoofed addresses). I sort of borrowed the concept from MAPS RBL's BGP reverse trigger for stopping unsolicited commercial email and other blackholing concepts. Then Cisco (and now Juniper) started doing this with a FIB and calling it uRPF. Funny name for a simple concept. Well I guess it's not very simple. I'm still trying to get my head around loose vs. strict uRPF and some of the strange ideas I've had recently involving IRRToolSet peval and router configruations for strict mode (or was that loose mode? heh). > >> 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. > http://www.ietf.org/internet-drafts/draft-ietf-idr-route-oscillation-01.txt Ok well that's easy. Implement your RR's correctly (duh). And I personally say Keep It Simple Stupid and use every possibility before considering MED's (never do always-compare, but always use deterministic when you do use MED's), and just stick to good old IGP costing based on whatever you want (fiber distances, delay, etc), but make it overly simple and easy. One way to avoid using MED's is to call your peer and say "hey can you local_pref or change your IGP metric around this for me?". That generally works pretty well ;> > There also some unusual uses of MED, where IOS has knobs to implement > certain behavior. Always-compare-MED can compare the MEDs of > different AS, as long as they are adjacent. Avi Freedman had a > presentation on an informal standard for exchange-point MED values, > based on delay, at the Denver NANOG. Wish there was more out there, but thanks for the pointers =] Cisco docs are lacking, and I hadn't seen those (woo!) 3 slides before. I guess something is better than nothing, so I'll stop complaining now. > >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. > > Well, it depends how complex you want to make the curriculum. I > don't really see, for example, why an ISP routing engineer needs a > particular knowledge of VoIP. If the ISP offers voice, they are > likely to have full-time voice specialist. If the ISP is just > providing connectivity, the VoIP and AVVID in general becomes the > enterprise's problem. I'd rather see more certification types, in > more depth than breadth, in more areas. That's the way the TAC is > internally organized, anyway. I sort of like how the Cisco SE's are organized: Core Transmission (e.g. SONET, ATM, Frame-Relay, Ethernet/Etherchannel) IP Multi-Layer / IP VPN (e.g. MPLS VPN, IPSec, BGP, OSPF, VLAN) IP Aggregation / Access (e.g. xDSL, Cable, Dial, Fixed Wireless, WLAN) Packet Telephony (e.g. VoIP, VoX, SS7, IPBX, H.323, MGCP, SIP) Network Management (SNMP, TFTP, CLI, HTML, XML, CORBA) Is this what you are talking about? Cisco is starting to organize a lot of concepts around good models; I think they have this stuff down (but that doesn't mean it can't be improved - they need a lot of industry feedback). Other companies are also starting to get some momentum (well I'm talking about Juniper, although Foundry and possibly others have their own ceritification programs). > There are a couple of alternatives to NO-PEER, including a concept I > called the super-community in an I-D. It might have advantages with > respect to exchange points and distribution within a region, but > NO-PEER is much more general. Which I-D describes the super-community? I'm already trying to think up crazy ideas with NO-PEER, but what's annoying is that it's breaking a lot of my Keep It Simple concepts. Actually, everything is really coming together in the worst way possible. Too many options now and no one leading the bunch. We now have a big bucket of Cisco, Juniper, IETF, oldtimers, newbies, NetVMG, RouteScience, Packet Design, and the list goes on and on.... all trying to solve the same problems -- and working in opposite (yet equally complicated) directions. Isn't this called Chaos Theory or something? > >Actually IPv6 is a replacement for IPv4. Tell Nortel to work on that. > > I did. To use their euphemisms, telling things like that is one > reason I was "optimized" out of a job. Yeeouch. Bitter, much? > Shortage of smart -- make that uninformed -- people. How many times > do you see posts to this list wanting to know how to globally > load-balance their BGP traffic? What fundamental misunderstanding > causes this? Not RTFM'ing? Cisco's avoidance to test on these topics? Dunno. What caused the 112,000 routes we have today? I really super doubt it's all that mysterious swamp space. I think it's more like the opposite. To be honest, I'm discovering that the industry is filled with people trying to keep their jobs even though they are totally underqualified and only been doing this stuff for like 2-3 (at most!) years. They are filling the bucket of knowledge with FUD, FUD, and more FUD. And they're growing in insanely large numbers everyday. This is *not* an easily solvable problem and it's not going to turnaround for the better anytime soon. > Not sure which aspects you have in mind, and there's a lot of > enterprise education needed about what various multihoming strategies > will and won't buy them -- I spent at least a chapter on these > choices. NO-PEER could help, because it's becoming pretty clear CIDR > aggregation is becoming less useful due to the desire of customers > for multiprovider multihoming. I also find that single-provider > multihoming to multiple POPs, with conscious local loop diversity, is > much underutilized. Your other book says "... get advice from your ISP or a consultant experienced with multihoming address practices". When I read that 3 years ago I wanted to virtually beat you with a cluestick (or something)! Is this what you are going to say in your new book, as well? So, if there's a lot of enterprise education needed -- then start educating!! The only things I've read so far is A) Doyle Vol. II Figure 4-6 (NAT is used to resolve the CIDR problem) B) Conditional Advertisement http://www.cisco.com/warp/public/459/cond_adv.html C) Knowledge of how ARIN and RIPE give allocations and how ISP's filter on boundaries http://www.nanog.org/filter.html So what's the answer? My answer is (keeping it simple) and thus doing PI space whenever possible and annoucing it everywhere (hrmn... disconnected backbones... hrmn... annoying concepts... hrmn...) possible and for inter-domain traffic engineering for inbound use a more-specific with like no-export (and/or send-community setting of upstream local_pref) and/or as-path prepends (which are easily overridden by local_pref). More annoying concepts, but I can't think of anything more simple than that. I guess PA is/was saving a lot (or was it?) for most people (since most people are single homed?), but blah, who wants to be single homed anyways? And who stays single-homed forever? You're going to end up punching holes in your blocks if you hand out PA space. RIPE does it smart: if you want to run BGP at all (which means you probably understand the concept of multihoming), you have to get a PI allocation (but most people there can get a PI allocation because RIPE doesn't require a minimum of 1024 hosts immediate need and 2056 hosts by end of one year like ARIN does to get a /20). Here in ARIN territory, you have to be a lot more clever in order to be a good BGP neighbor and that means choosing options A) or B) above (or going the C route I mentioned before and somehow getting some PI / swamp space). I'd like to see the delta between your thoughts and mine on PA multihoming. -dre Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=44794&t=44778 -------------------------------------------------- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
