Home page logo

nanog logo nanog mailing list archives

RE: Generally accepted announcement sizes
From: Mike Heller <mheller () staff iwon com>
Date: Fri, 23 Jun 2000 08:58:24 -0400

The 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,


-----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
down various parts of the 'Net become unreachable and I attributed that
the size of that announcement being a /24.  I assume that the carriers
having issue with are not using RADB as I registered all of my

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

iwon.com is AS 14829, and they seem to announce 3 networks:

They announce to AS 2914 (Verio) and AS 1785
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 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, which is solely seen through AS 2914
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 > 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.


  By Date           By Thread  

Current thread:
[ Nmap | Sec Tools | Mailing Lists | Site News | About/Contact | Advertising | Privacy ]