FW: /8s and filtering
hnarayan at cs.ucsd.edu
Tue Dec 10 19:31:33 UTC 2002
I asked if the multihomer has to be able to fully utilize a /26=25% of
/24 to be able to multihome.
I am sorry but the link doesn't help.
On Tue, 10 Dec 2002, Ejay Hire wrote:
> Interesting. Perhaps your source hasn't read the policy updates.
> Here is the link to ARIN's site, and I have successfully used this as
> justification for a customer.
> -----Original Message-----
> From: Harsha Narayan [mailto:hnarayan at cs.ucsd.edu]
> Sent: Tuesday, December 10, 2002 1:15 PM
> To: Ejay Hire
> Cc: nanog at merit.edu
> Subject: RE: FW: /8s and filtering
> 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?
> On Tue, 10 Dec 2002, Ejay Hire wrote:
> > Having a /24 doesn't indicate you are a network of any particular
> > 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
> > > > >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
> > > multihome if only their own providers accept their route, but nobody
> > else
> > > does? I realize that their block should be still announced with
> > > 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
> > must accept more specific routes from each other, that is within the
> > space being aggregated. If they do not share specifics, one uplink
> > will cause a large percentage ~50% for the customer. This scenario is
> > valid for load balancing, but redundancy is fragile. The only
> > 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
> > 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
> > 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
> > 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
> > > would accept /24 and shorter from.
> > There is value in the current filtering of longest prefixes...
> > anyone to multihome with BGP, using any network size, is going to
> > our BGP tables overnight. Perhaps its good that you must be of some
> > 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