North American Network Operators Group Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical Re: BGP filtering policies, UU, and you
On Tue, Apr 09, 2002 at 12:29:46PM -0700, David Barak wrote: > There's no real problem with your current space. > Assume for the minute that each of your offices has a > UU T1. You announce the chunks of your /22 through For the time being, only one uunet transit link. > your various T1s, and that announcement (along with > the UU/14) is passed along to UU customers and peers. > Verio will ignore the /22, but will direct traffic to > UU because they will accept the /14. so no problem That part I am clear about. > there. The only possible issue is this: This part is the part that concerns me, as it is specifically our scenario: > assume one T1 to UU and one to <non-Verio provider>. (make that one uunet link and more-than-one <provider>, as well as both private links as well as over-the-'net tunnels interconnecting some of our sites.) > UU T1 goes down, therefore /22 withdrawn there, /22 > announcement through <provider> becomes only route. > Verio ignores this, and directs traffic to UU (via the > /14), and UU will then direct traffic to <provider> > because UU has very liberal routing policies. So in Uh, what's "very liberal routing policies" mean? (And which uunet URL details this?) I assume you mean that uunet will accept announcements for its own blocks (and specifics, not aggregates) from other <providers>; that is, I also advertise this uunet block on my other <provider> link, and they'll accept and propagate it (right?). And uunet will accept this route of their own block from <provider>? If this works as laid out, then uunet would realize that the uunet link is down and send traffic over to the other <provider>. > the worst case, you could get some sub-optimal > routing, but nothing particularly bad, and Verio is No, not particularly bad, but not as good as it could be "if only" the block were allocated in class C space to begin with. > the only substantive ISP who still uses these filters > (AFAIK). I know this is NAnog, but we have important correspondents in Europe and Japan. > The bigger issue in that case would be getting the UU > line up faster :) Unfortunately, the vast majority of failure modes for our sites end up being dependent on the ILEC. It's not a pretty picture. > Henry Yen wrote: > We were recently assigned a /22 from UUNet in > conjunction with some > transit we're buying from them. The space is inside > their superblock, > 65.242.0.0/14. We are concerned that our route > announcement of this > block would be filtered out by some other providers, > as it's not > class C/swamp space (or even class B space for that > matter). > Verio's current policy, for one, indicates that this > would be so. > > This is of particular concern to us as our little > network encompasses > several physical partially-meshed locations, with a > mix of varying > bandwidths both upstream as well as intra-location. > Traffic Engineering > is what we think is a reasonable (business) approach > to address our > flexibility needs, and so we're trying to move to > address space(s) that > would be least likely to be BGP filtered. > > We've asked for a different block from UUNet but the > request didn't > meet with success; UUNet suggested that any problems > encountered > as a result of this allocation could probably solved > by e-mailing > any NSP whose traffic interchange with us might be > negatively > affected (unlikely, to be sure, but still...), and > would then > change their filter (I'm unconvinced of this > scenario). > > I briefly browsed the NANOG archives, and didn't see > this issue discussed > recently. Have the BGP filtering policies for "most" > ISP/NSP's been > relaxed to the level of "accept /24's from class A > (ARIN-allocated) space"? > Am I mis-reading Verio's posted policy? Is there > anyone from UUNet > who might choose to comment? Is there something else > I'm misunderstanding? -- Henry Yen Aegis Information Systems, Inc. Senior Systems Programmer Hicksville, New York
|