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/mail.archives/nanog/2000-06/msg00420.html ++> Date: Thu, 22 Jun 2000 17:35:07 -0400 (EDT) ++> From: Tony Tauber <ttauber@genuity.net> ++> To: Mike Heller <mheller@staff.iwon.com> ++> Cc: "'nanog@merit.edu'" <nanog@merit.edu> ++> ++> 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 ++>