Address block problem

Tue Aug 1 13:49:27 EDT 2000

Joe,

Problem with this setup - here's a hypothetical, ISP E is the one that is
filtering anything longer than a /20.  I'll announce the /21's and a /20 to
my connections to ISPA, B, C, and D.  ISPE.  A, B, C, and D and their peers
that to not filter will make routing decisions based upon most specific, and
my network will be visible to ISP E.

       +--------------+       +--------------+
ISP A--|   network    |       |   network    |--ISP C--ISP E
       |     one      |-------|      two     |
ISP B--| 10.10.128/21 |  DS3  | 10.10.136/21 |--ISP D
       +--------------+       +--------------+

That is all good while the connection between my distributed networks is up,
but when that DS3 goes down, and I'm still announcing packets for the entire
/20, I run a serious risk of blackholing network one from folks connected to
ISP E, since it will still think that network two provides connectivity to
network one.

Here are the filtering policies that I could find, I look forwards to any
additional ones that are known:

http://www.mibh.net/mibh-peering.html
http://info.us.bb.verio.net/routing.html#PeerFilter

----
Dani Roisman
Verant Interactive
hostmaster at verant.com

> -----Original Message-----
> From:	Joe Gilbert [SMTP:joe at zyan.com]
> Sent:	Tuesday, August 01, 00 10:14 AM
> To:	Hostmaster, Verant; 'arin-discuss at arin.net'
> Subject:	RE: Address block problem 
> 
> Dani,
> 
> There is another possible solution other than "wasting IP Address 
> space."  Assuming that some larger ISPs filter BGP announcements smaller 
> than a /20 or /19 (which used to be ARIN's minimum allocation), there is a
> 
> way to announce a smaller block for a geographically disparate network 
> without compromising routing.  By the way, if anyone knows the ISPs that 
> specifically filter smaller announcements, it would be very handy to have
> a 
> list of these ISPs and their policies.  Is there possibly a web site 
> maintained with this information?
> 
> In any case, here is a solution that I propose that I have worked with and
> 
> is definitely workable in the real world Internet enviroment.  What I have
> 
> seen ISPs do to solve this problem is to announce the smaller block, i.e. 
> /22, that is being used at the geographically disparate network via BGP to
> 
> the upstream providers in that location.  Some ISPs will filter that 
> announcement but most will see it and route traffic within that CIDR block
> 
> directly to your network.  To get around the filtering, you should
> announce 
> the /20 at a central location, hopefully where you are using the rest of 
> the aggregate.  That way, even if an ISP is filtering your smaller 
> announcement, they will see your larger announcement and route the packets
> 
> to the AS that they are receiving that announcement from.  Hopefully, that
> 
> AS is not filtering the smaller announcement and will route the traffic to
> 
> the more specific announcement.  However, even if some of the traffic does
> 
> get all the way back to your central location without hitting an AS that
> is 
> not filtering, I am sure you could handle that amount of traffic on your 
> internal links.  In actual practice, you probably will not see any traffic
> 
> hitting the AS where the aggregate route is being announced from if you
> are 
> advertising a more specific route elsewhere.  All in all, this is a 
> solution that leads to desirable results and does not greatly 
> overcomplicate your network.
> 
> 
> --
> Joe Gilbert, Development Engineer
> Zyan Communications
> http://www.zyan.com   mailto:joe at zyan.com
> Toll Free 800-DSL SPEED 800-375-7733   Fax 213-488-6101
> Internet Access  DSL  T1  T3  VPN  Hosting  Ecommerce
> 
> 
> 
> At 09:07 AM 8/1/00, Hostmaster, Verant wrote:
> >Jason, I'd agree with you for most cases, but in our case, we have a /18,
> >and have a few networks that are distributed geographically, and are
> >multihomed.  In some cases, there is an imbalance between our
> connectivity
> >to the Internet, and our connectivity within an AS.  E.g. one network
> might
> >have 2 oc12's to 2 different ISPs, but only  have a ds3 back to the rest
> of
> >our network for internal traffic.  I only have a /22 worth of address
> space
> >on that network, but I have to waste and announce an entire /20, because
> >that's all that Verio, mibh, and a few others, will accept from my
> >64.37.128.0/18 block.
> >
> >Now, had I gotten into the game a year ago, my block's first octet would
> >have been in the 200's, and I would be free to use /24's (which I
> wouldn't,
> >the smallest I will announce is a /22).
> >
> >So possbile solutions are:
> >1) get in the game early (too late)
> >2) waste tons of address space (I hate to do this, but it works)
> >3) make enough noise, and tell my customers to change isp's when they
> can't
> >reach my network, and hope that these few ISP's realize that the rest of
> the
> >Internet is accepting /24's from all blocks, and their routers haven't
> >suffered, so they better jump on the bandwagon.
> >
> >We're going with option 3 for now, and see where that takes us.
> >
> >Dani D. Roisman
> >Verant Interactive
> >hostmaster at verant.com
> >
> >
> > > -----Original Message-----
> > > From: Redisch, Jason [SMTP:JRedisch at virtela.com]
> > > Sent: Tuesday, August 01, 2000 8:32 AM
> > > To:   arin-discuss at arin.net
> > > Subject:      RE: Address block problem
> > >
> > > Dani,
> > >       Many ISP's have IP Space from legacy Class A space.  A check of
> the
> > > whois database would show that anyone still filtering on /8 on that
> space
> > > is
> > > missing a large portion of the Internet.  A simple call to their POC
> > > should
> > > fix any connectivity issues.
> > >
> > >       However, several ISP's choose to filter all address space based
> on
> > > the ARIN min allocation size for that block.  They feel that they can
> > > reach
> > > the entire Internet that way while keeping routing tables on their
> > > networks
> > > to a minimum size.  This decision to filter or not is made by each ISP
> > > individually.  In doing so, these ISP's sometimes sacrifice more
> optimal
> > > paths, but in can still reach the entire Internet.  Announcing /24's
> for
> > > multihomed customers should work for the portion of the Internet that
> > > wants
> > > to listen to them, and the larger aggregate blocks of the upstream can
> be
> > > used to direct traffic for those ISP's that do filter at the higher
> bit
> > > boundaries.
> > >
> > >
> /\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
> > > /\
> > > /\/\/\/\/\/\/\
> > > Jason Redisch                           (V) 720.493.5533 ext 4120
> > > Virtela Communications                  (F) 720.493.5006
> > > Sr. IP Engineer
> > >
> > >
> > >
> > >
> > > -----Original Message-----
> > > From: Hostmaster, Verant [mailto:hostmaster at verant.com]
> > > Sent: Monday, July 31, 2000 4:35 PM
> > > To: arin-discuss at arin.net
> > > Cc: Hostmaster, Verant
> > > Subject: RE: Address block problem
> > >
> > >
> > > Yeah, /24's are fine as long as you're not a recent recipient of
> address
> > > space, like us.  We have a block from the 64.0.0.0/8 space, but we
> can't
> > > advertise /24's out of that block because some stick-in-the-mud ISPs
> out
> > > there still consider them from the "class A" address space, and filter
> > > them
> > > out.
> > >
> > > ----
> > > Dani Roisman
> > > Verant Interactive
> > > hostmaster at verant.com
> > >
> > > > -----Original Message-----
> > > > From:       Bruce Robertson [SMTP:bruce at greatbasin.net]
> > > > Sent:       Monday, July 31, 00 3:20 PM
> > > > To: Andy Dills
> > > > Cc: arin-discuss at arin.net
> > > > Subject:    Re: Address block problem
> > > >
> > > > > Why do you force multihomed customers to get their own address
> space?
> > > > You
> > > > > need to be using 8 /24's to get PI space. None of my multihomed
> > > > customers
> > > > > come anywhere near qualifying.
> > > >
> > > > Hmmm... mine do.  A couple have single /24s from the swamp that I'm
> > > > advertising under protest, but the rest have large blocks.
> > > >
> > > > --
> > > > Bruce Robertson, President/CEO
> > > > +1-775-348-7299
> > > > Great Basin Internet Services, Inc.                 fax:
> +1-775-348-9412
> > > > For PGP key: finger bruce at greatbasin.net
> > > >