The 216.73.19.128/25 is a legacy network that I am renumbering off of. I agree that it is too small of a network to be seen consistently. When my verio connection went down the other day, the 165.254.159/24 netblock did not appear in the cerf routeserver and verio wasn't seeing my announcement at all either. It seems that they filter announcements from 128/8 to the /19 and larger thereby filtering my announcement out. The above two are my office networks. The 209.10.180/24 is my production network and I peer directly with GBIX, UUnet, and SPrint. I had no problems there. Thanks for your input, Mike -----Original Message----- From: Kai Schlichting [mailto:kai@pac-rim.net] Sent: Thursday, June 22, 2000 7:33 PM To: Mike Heller Cc: 'nanog@merit.edu' Subject: Re: Generally accepted announcement sizes At Thursday 05:35 PM 6/22/00 , Tony Tauber wrote:

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,

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.

A rather complex setup on their side, as far as I can tell from route-server.cerf.net, route-views.oregon-ix.net and route-server.ip.att.net: iwon.com is AS 14829, and they seem to announce 3 networks: They announce 165.254.159.0/24 to AS 2914 (Verio) and AS 1785 (AppliedTheory) At the Oregon IX, the path via Verio is seen 15 times, via AT only 2 times. That's is an indicator of connectivity (and likely density of interconnectivity of providers to Verio vs. AT) right there. It's more balanced 5:4 (Verio:AT) at AT&T's route view. They announce 209.10.180.0 to AS 701 (UUnet), 4513 (PFM/Globix), 1239 (SL). At the Oregon IX, this is seen somewhat balanced between the 3, but at AT&T, it's 8 paths to UUNet or SL, only one path to PFM/Globix. They announces 216.73.19.128/25, which is solely seen through AS 2914 (Verio) at the Oregon-IX, and only 4 times at that. As expected, Verio seems to accept this as a customer route, but few of their peers accept the /25, Note that AT&T and CERF.net are not seeing this specific, but they see the larger /18 aggregate from AppliedTheory only, which is probably what 90% of all traffic to this network . It's a wonder that the /25 is seen at all: I think it should be withdrawn for sanity's sake. So, what exactly are you trying to accomplish, Mike? One thing is clear: the third network will always receive most traffic from AT, the second one mostly from UUnet+Sprint, the first one (which I believe you are referring to) mostly from Verio. The right way to overcome this is likely not to play with BGP toys like AS_prepend or making your providers manipulate the local_pref for you (and I see that Verio and UUnet don't seem to be crossing paths, at least for the first network listed), but by utilizing bigger networks: /22's in the >204.0.0.0/8 space are looking damn good in terms of 'being heard' compared to /24's. Did I mention that Verio seems to be the only one filtering at /20 boundary in 62/8 and 63/8 ? As a customer, you won't have that problem, obviously. bye,Kai