FW: /8s and filtering

Brian bri at sonicboom.org
Tue Dec 10 19:25:25 UTC 2002


many isps will automatically give a /24 if their client is multihoming,
even if their usage is well below the 254 usable ips allocated by the
above block size.

	Brian


On Tue, 10 Dec 2002, Harsha Narayan wrote:

>
> Hello,
>  No, this is not the case. I enquired and it seems multihoming is not a
> justification for a /24 in any RIR.
>
>  Does a network have to be able to fully utilize a /26 (25% of /24) in
> order to multihome?
>
> Harsha.
>
> On Tue, 10 Dec 2002, Ejay Hire wrote:
>
> >
> > Having a /24 doesn't indicate you are a network of any particular size,
> > ARIN ratified a policy that allows multihoming as justification for a
> > /24.
> >
> > -ej
> >
> > -----Original Message-----
> > From: N [mailto:nathan at stonekitty.net]
> > Sent: Tuesday, December 10, 2002 1:01 PM
> > To: Forrest
> > Cc: nanog at merit.edu
> > Subject: Re: FW: /8s and filtering
> >
> >
> > comments inline
> >
> > On Tue, Dec 10, 2002 at 12:36:39PM -0600, Forrest wrote:
> > > >
> > > > >I was also curious about this - if I am a customer who wants to
> > > > >multihome and can justify only a /24, I would go to an ISP which
> > has an
> > > > >allocation from the Class C space rather than one from the Class A
> > > > >space.
> > > >
> > > > 	It doesn't matter. For all practical purposes, basement
> > multihomers
> > > > only
> > > > care that their two or three providers have their route.
> > >
> > >
> > > Maybe I'm missing something, but what good would it do for someone to
> > > multihome if only their own providers accept their route, but nobody
> > else
> > > does?  I realize that their block should be still announced with their
> >
> > > ISP's larger aggregate, but what good does this do if your ISP goes
> > down
> > > and can't announce the large aggregate.
> >
> > For the assigned block to be part of the same aggregate(of both
> > providers), that implys that the providers sharing the responsibility
> > for the aggregate. It happens, but is rare.  In this case, the providers
> > must accept more specific routes from each other, that is within the
> > space being aggregated.  If they do not share specifics, one uplink down
> > will cause a large percentage ~50% for the customer. This scenario is
> > valid for load balancing, but redundancy is fragile. The only advantage
> > I see is no limit to prefix length. You can do this with a /28 if you
> > want... given the above caveats are addressed.
> >
> > > If you're a smaller organization, perhaps you'll only have a /23 from
> > your
> > > upstream provider.  With the filtering that seems to be in place, it
> > seems
> > > like the only way you can truly multihome with a /23 is if it happens
> > to
> > > be in the old Class C space.  Or is this wrong?
> >
> > In today's VLSM world... the old classes have no bearing on filtering in
> > my experience. Prefix length discrimination knows no classfull
> > boundaries.
> >
> > > What seems to be needed is perhaps a /8 set aside by the RIR
> > specifically
> > > to allocate to small organizations that wish to multihome that people
> > > would accept /24 and shorter from.
> >
> > There is value in the current filtering of longest prefixes... Allowing
> > anyone to multihome with BGP, using any network size, is going to double
> > our BGP tables overnight. Perhaps its good that you must be of some size
> > to participate in public BGP.  Many providers offer redundancy that is
> > more appropriate for the smaller networks.
> >
> > --
> > ,N
> >
> > ~Nathan - routing & switching dude/fly-boy/sport biker - San Jose CA~
> >
>



More information about the NANOG mailing list