FW: /8s and filtering
ejay.hire at isdn.net
Tue Dec 10 19:24:47 UTC 2002
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.
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
> -----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
> > > 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
> > 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
> > 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
> > upstream provider. With the filtering that seems to be in place, it
> > like the only way you can truly multihome with a /23 is if it
> > 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
> > What seems to be needed is perhaps a /8 set aside by the RIR
> > 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.
> ~Nathan - routing & switching dude/fly-boy/sport biker - San Jose CA~
More information about the NANOG