North American Network Operators Group

Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical

Prefix-legth FUD (was: Re: Opinions about InterNAP)

  • From: Tony Tauber
  • Date: Wed Jun 13 15:12:42 2001

Oe Wed, 13 Jun 2001, Seth. Kusiak wrote:

>
> I've been told by many that most national providers filter any prefix
> greater then a /20 such as sprint and verio.
>
>  -Seth
>

Can we not put this to bed once and for all ?!?

Tony
----
>From a year ago:

http://www.merit.edu/mailinglist/mailarchives/old_archive/2000-06/msg00420.html

++> Date: Thu, 22 Jun 2000 17:35:07 -0400 (EDT)
++> From: Tony Tauber <[email protected]>
++> To: Mike Heller <[email protected]>
++> Cc: "'[email protected]'" <[email protected]>
++>
++> On Thu, 22 Jun 2000, Mike Heller wrote:
++> >
++> > Can anyone point me to a centralized resource for Tier 1 and Tier2
++> > providers'  accept policies?  I have found that when some of
++> > my circuits go down various parts of the 'Net become unreachable
++> > and I attributed that to the size of that announcement being a /24.
++> > I assume that the carriers I'm having issue with are not using
++> > RADB as I registered all of my netblocks,
++>
++> Here's the deal.  If you number out of Provider1's CIDR block
++> but advertise your more-specific to Provider2 and the two Providers
++> touch and Provider1 accepts the more-specific route from Provider2,
++> you should have no problem reaching anyone.
++>
++> Here's the reason: Everyone accepts Provider1's announcement of the block.
++> When your link to P1 is up, any traffic they recieve for your prefix
++> gets routed over that link since they carry your more-specific internally.
++> However, if other providers here the more-specific from P2, they'll
++> send directly via P2 who sends it over the link to you.
++> If your link to P1 goes down, P1 won't see the direct route to you
++> but should see the route via P2 if P1 is accepting it. (Some
++> may either block the announcement or have anti-spoofing packet filters
++> at their borders that block the traffic itself).
++>
++> There are many misconceptions about this topic.
++> Hopefully this explanation has helped someone.
++>
++> To find out exactly why your multi-homing set-up isn't working,
++> I'd work with your providers' operations staff.  Perhaps set up
++> a time to test the fail over with them on hand to help you analyze
++> by looking at the routes on both.  It should be possible for them
++> to help check the behavior of traffic over a third provider as well
++> if the providers are worth their salt.
++>
++> Tony
++>