At 9:29 AM -0400 6/18/02, Neal Rauhauser 402-301-9555 wrote: >"Howard C. Berkowitz" wrote: > >> At 4:07 PM -0400 6/16/02, Neal Rauhauser 402-301-9555 wrote: >> >My only explanation for this is that there was nothing good on TV on a >> >lazy Sunday morning ... >> > >> > I am about to start doing some truly gruesome things with IBGP due to >> >geographical separate peering points and I've got some internal routers >> >that are maxed out at 64 meg, so I spent a little time this AM examining >> >the source of this silly 114k+ entry global BGP table. My idea was that >> >a carrier stuck smack in the middle of the US could probably ignore >> >details about RIPE and APIC address space. Those two authorities turn >> >out to be responsible for only about 32k of the total so I am casting >> >around for other methods to trim the fat but I thought I'd share the >> >results thus far. >> >> You'll find a LARGE part of the routing table still comes from the >> Swamp [1] or the Toxic Waste Dump [2], rather than any geographical > > region.
I grant your earlier point that many major providers are in the Swamp. Nevertheless, you might consider prefix length filters blocking longer than /24 (or even 20) _in the Swamp_, and see if there are any connectivity problems. If you are defaulting to an upstream, let them worry about getting to the obscure networks. > > >> Neal, this is a distinctly nontrivial problem, with no ideal >> solution. Your basic choice is accepting "suboptimal routing [3]" or >> upgrading your routers. >> >> Several basic questions come up about what you are trying to do: >> >> 1. Is this for an ISP or an enterprise? > > Internet provider, doing wireless, playing with private line replacement >stuff, too. > >> >> 2. From a bandwidth standpoint, how many peering points could you >> lose and still have acceptable performance? > > I've got a single Sprint T1 at one end of the network, an AT&T and >UUNet T1 at the >other end. The Sprint side will grow quickly to more capacity, the AT&T and >UUNet stuff >is a colo company, not mine to rule, so they're fussy about how much output >we >generate, but don't care much about our input side. Well, if Sprint is your major provider, one way to reduce routes is to make Sprint your primary ISP with most-preferred default. Take partial routes from AT&T and UUnet, give better preference to direct-connected or adjacent AS they advertise, and use them as secondary defaults. The colo needs would need more analysis. > >> >> 3. To how many different AS do you connect, and do they have >> approximately >> equal connectivity? > > Sprint, AT&T, UUNet, probably going to add one more at the end where the >Sprint >circuit is, but I suspect it'll be UUNet there, too. If availability is the goal, I tend to prefer to have at least two geographically dispersed peerings with the same well-connected ISP, and get some contractual commitments about route diversity. The latter may cost, but it is a protection against major physical failures. There still is a benefit to connecting to more than one upstream, however, as it tends to protect you against failures in the routing system. No one size fits all. > >> >> 4. What is your IGP? > > Today its OSPF and that is the one I know best. There is some cause to >consider >replacing OSPF area 0 with EIGRP due to different cost links and varying >'cleanliness' >in the wireless layer, but we'll see how that goes - I have enough to do >without >worrying about redistribution right now. Without more specifics, my sense is that converting to EIGRP would not be a good idea. When you talk about different cost links, that makes me wonder if area 0.0.0.0 is too complex. Area 0.0.0.0 should be, at most, linking your POPs, hosting, and management sites, and its behavior is much more predictable with a narrow (or single) range of link speeds. Even if you have a complex hosting/management center, I'll usually put that in its own nonzero area. Another alternative is having multiple OSPF domains linked by a BGP backbone. If you have a lot of policy requirements, these domains might be confederations. Otherwise, they are probably clusters. Do be careful to avoid the persistent route oscillation problem, especially if you go to multiple levels of reflector, by ensuring that intra-cluster metrics are ALWAYS preferred to inter-cluster, much as OSPF intra-area routes are ALWAYS preferred to inter-area. The availability of Type 1 and Type 2 externals also can be very helpful in managing defaults and load sharing without the needs for full routes. If you were trying to simplify, I suspect you could get cleaner simplification with ISIS than EIGRP. It may not be necessary to change. Another thing worth looking at is running BGP primarily at the edge and using MPLS in the middle -- sort of RFC 2547-like but public, not VPN. That will position you well for future traffic engineering. > >> >> 5. How much effort, including programming, are you willing to do to >> optimize tables? > > Lots and lots ... keeps me off the street and contributes to passing my >CCIP BSCI >exam I think ... One quirk in cutting down Asian ISPs is looking for relatively new ones that get a /19 or /20, and immediately cut it into /24s that may or may not have any hosts on them. I get suspicious of any ISP that ONLY advertises /24's as its more-specifics. > >> >> 6. Do you have a decent familiarity with RPSL, routing registry, and >> some >> of the freeware tools such as CIDRadvisor and RtConfig? >> > > I've made a few basic entries in the RADB, I've played with cflowd, >and I've not >done much with the automation tools in this area. I'll prefer to hand tune >at first, >until I really understand what I am facing. > > >> >> Howard >> >> [1] The Swamp is the term used in addressing working groups to refer >> to 192.0.0.0/8, the original Class C space. >> >> [2] The Toxic Waste Dump, which probably is somewhere in Northern New >> Jersey, is that part of the Swamp containing /24 or longer prefixes. >> >> [3] People often worry about suboptimal routing, but the gains of one >> "perfect" >> path may be marginal when compared with the complexity of >> differentiating it from a "decent" route. >> >> -- >> "What Problem are you trying to solve?" >> ***send Cisco questions to the list, so all can benefit -- not >> directly to me*** >> >******************************************************************************** >> Howard C. Berkowitz [EMAIL PROTECTED] >> Chief Technology Officer, GettLab/Gett Communications >http://www.gettlabs.com >> Technical Director, CertificationZone.com http://www.certificationzone.com >> "retired" Certified Cisco Systems Instructor (CID) #93005 Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=46894&t=46726 -------------------------------------------------- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
