I've been told by many that most national providers filter any prefix greater then a /20 such as sprint and verio. -Seth David McGaugh writes:
/24's are sufficient to multihome with most if not all providers out there. Why not conventionally multi-home to 2 large well established providers?
-Dave
"Seth M. Kusiak" wrote:
Hi
We have a small network (5 /24s) and we need to host our web applications internally because they access backend servers that absolutely cannot be collocated. I am thinking about getting 2 T1s or fractional DS3s from InterNAP from different P-NAPS (1 from Philly and 1 from NY) each circuit from a different CO
The reason that Im thinking InterNAP is because we dont qualify for a /20 and we would not be able to efficiently multi-home. It seems that InterNAP is perfect in our situation because they buy transit from multiple providers and claim to not have any black holes in their network.
I hear many great things about InterNAP and I hear the opposite as well.
Any thoughts would GREATLY be appreciated
Thanks!
-Seth
On Wed, 13 Jun 2001, Seth M. 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
David McGaugh writes:
/24's are sufficient to multihome with most if not all providers out there. Why not conventionally multi-home to 2 large well established providers?
-Dave
Filters depend on where you get your allocation. We got 216.249.16.0/20 from arin. Since we're above the swamp, we have a greater chance of having any given /24 not be filtered. Shortly after we got the allocation, I announced a single /24, and could cleanly traceroute to machines on that subnet from points behind sprint, verio, C&W, worldcom, etc. Had we been given an allocation from 65/8 or another block in former-class-A space, we probably would've had problems. FWIW, what I've heard is that most people like Verio who used to have painfully strict filtering policies have reverted to something a little better. Personally I've seen no impact on filtering, we renumbered our production networks out of the GBLX/GBLC/Exodus-owned and aggregated space (64.209.175.0/24 and 64.210.164.0/23) into our own /22 in 216.249.16.0, and usage is still increasing. We've also heard no complaints of unreachability. -j -- -Jonathan Disher -Sr. Systems and Network Engineer, Web Operations -Internet Pictures Corporation, Palo Alto, CA -[v] (650) 388-0497 | [p] (877) 446-9311 | [e] jdisher@eng.ipix.com
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 ++>
participants (3)
-
Jonathan Disher -
Seth M. Kusiak -
Tony Tauber