|
North American Network Operators Group Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical RE: FW: /8s and filtering
Hello, 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. Harsha. 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. > > http://www.arin.net/policy/2001_2.html > > -ej > > -----Original Message----- > From: Harsha Narayan [mailto:[email protected]] > Sent: Tuesday, December 10, 2002 1:15 PM > To: Ejay Hire > Cc: [email protected] > Subject: RE: FW: /8s and filtering > > 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:[email protected]] > > Sent: Tuesday, December 10, 2002 1:01 PM > > To: Forrest > > Cc: [email protected] > > 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~ > > >
|