[Q] BGP filtering policies
Henry Yen
henry at AegisInfoSys.com
Tue Apr 9 20:28:29 UTC 2002
On Tue, Apr 09, 2002 at 02:34:44AM -0500, Borchers, Mark wrote:
> http://www.arin.net/statistics/index.html#ipv4issued2002
The CIDR section is the part you're referring to?
http://www.arin.net/statistics/index.html#cidr
which indicates /20.
> Unfortunately, this doesn't help in your case. My company also
> has /14's from the traditional class A space. I know of only one
> case in two years where a customer reported a problem arising
> from holding a small assignment out of these blocks, which was
> ultimately corrected by renumbering the customer, a solution which
> does not scale well.
I don't exactly anticipate this ever happening. My observation is
that the scaling will happen in the router area, i.e. as more and
more smaller blocks get announced out of the class A/class B space,
the ability of routers to hold more routes will tend to relax the
typical filtering policies as time goes on. In other words, by
the time we might encounter a problem, it'll no longer be a problem.
Your comment about renumbering is most apropos; if it's not a problem
for uunet to assign in swamp space now (i.e. "pre-renumbering"), then
this also disappears as an issue later.
> Worst case, however, unless your UUNet connection goes down, you'll
It happens more frequently than you might expect.
> still be able to reach most places via your other transit and peering
> (since /24 is the closest thing to a "universal" allowed prefix length)
> and will have full reachability via UUNet. IMHO, accepting up to /24
> in any of the space listed on the above URL is good service provider
> practice.
>
> > -----Original Message-----
> > From: Henry Yen [mailto:henry at AegisInfoSys.com]
> > Sent: Tuesday, April 09, 2002 2:11 PM
> > Subject: [Q] BGP filtering policies
> >
> > 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
More information about the NANOG
mailing list