Hello;
In our BGP table, there are this morning the following AS's :
AS 64610 : 1 prefixes : 1 prefixes supported : 3 hops : as path 1239 209 64610
AS 64615 : 2 prefixes : 2 prefixes supported : 3 hops : as path 1239 209 64615
AS 64616 : 3 prefixes : 3 prefixes supported : 3 hops : as path 1239 209 64616
AS 65008 : 3 prefixes : 3 prefixes supported : 3 hops : as path 145 2200 65008
AS 65102 : 3 prefixes : 3 prefixes supported : 3 hops : as path 1239 209 65102
AS 65209 : 12 prefixes : 12 prefixes supported : 3 hops : as path 1239 209 65209
AS 65498 : 1 prefixes : 1 prefixes supported : 3 hops : as path 1239 209 65498
In the MBGP table for multicast, there are
AS 64580 : 9 prefixes : 9 prefixes supported : 5 hops : as path 1239 5511 2200 2074 64580
AS 65001 : 1 prefixes : 1 prefixes supported : 4 hops : as path 3300 8933 2200 65001
AS 65498 : 1 prefixes : 1 prefixes supported : 3 hops : as path 1239 209 65498
I thought that these AS's were not supposed to be advertised globally.
Is this really a problem ? Is it worth the effort to track the sources of these down and
try and get them to remove them ?
Regards
Marshall Eubanks
Multicast Technologies, Inc.
10301 Democracy Lane, Suite 410
Fairfax, Virginia 22030
Phone : 703-293-9624 Fax : 703-293-9609
e-mail : tme@on-the-i.com http://www.on-the-i.com
Hello;
In our BGP table, there are this morning the following AS's :
AS 64610 : 1 prefixes : 1 prefixes supported : 3 hops : as path 1239 209 64610
AS 64615 : 2 prefixes : 2 prefixes supported : 3 hops : as path 1239 209 64615
AS 64616 : 3 prefixes : 3 prefixes supported : 3 hops : as path 1239 209 64616
AS 65008 : 3 prefixes : 3 prefixes supported : 3 hops : as path 145 2200 65008
AS 65102 : 3 prefixes : 3 prefixes supported : 3 hops : as path 1239 209 65102
AS 65209 : 12 prefixes : 12 prefixes supported : 3 hops : as path 1239 209 65209
AS 65498 : 1 prefixes : 1 prefixes supported : 3 hops : as path 1239 209 65498
In the MBGP table for multicast, there are
AS 64580 : 9 prefixes : 9 prefixes supported : 5 hops : as path 1239 5511 2200 2074 64580
AS 65001 : 1 prefixes : 1 prefixes supported : 4 hops : as path 3300 8933 2200 65001
AS 65498 : 1 prefixes : 1 prefixes supported : 3 hops : as path 1239 209 65498
Qwest and Renater. I think it is worth the effort to track them down and have them fix it.
-Hank
I take transit from Qwest (209), and had to contact them directly and open
a ticket several weeks ago to get them to stop leaking private ASNs into
my tables. They stopped leaking them to me, but apparently going the
extra step and making sure the leak was filtered everywhere was too much
to ask.
-travis
[snip]
I take transit from Qwest (209), and had to contact them directly and open
a ticket several weeks ago to get them to stop leaking private ASNs into
my tables. They stopped leaking them to me, but apparently going the
extra step and making sure the leak was filtered everywhere was too much
to ask.
BTW, private AS leaks are reported as part of the IPMA "routing problems"
reports (http://www.merit.edu/ipma/reports/). Yes, it is based off
route-server data; no, peering with route-servers at a given location
does NOT mean you have to use them for exchanging routing updates. It is
in the best interest of the community for anyone at exchange points
where there is a route-server to participate. IMO not doing so indicates
the desire to hide data, or some measure of irresponsibility; encourage
your providers and peers to supply externally-validated stability data.
Speaking of which, I have not seen any data, public or private, that WCOM
is establishing a route-server presence at MAE-E ATM. It seems customers
are going to lose a service in the MAE-E FDDI close, and all of us will
lose a data-gathering point.
Joe, reminding people to read the X-header
I have a question. Why do you allow Private ASNs into your network? We saw
this once and put in the filters. Same with RFC1918 IPs and default. We
dont care to listen to these from other networks so we filter. We saw 64/8
in our network, we filtered. We saw leaks from RESERVED-IANA blocks, so we
filtered. We saw providers leaking exchange point blocks, so we filtered.
we dont want to see _701_ from sprint or anyone except _701_, so we
filter. we do this for other large providers.
See a problem, filter.
Maybe I should start a company and publish filters since most companies
seem not to have real filters in their network 
Christian
I have a question. Why do you allow Private ASNs into your network? We saw
<condescending crap removed>
Probably because making your upstream type "neighbor x.x.x.x
remove-private-AS" is a little more efficient than doing:
route-map already-full-of-IANA-reserved-filters deny 10
match as-path 1
ip as-path access-list 1 permit _64[5-9][1-9][2-9]_
ip as-path access-list 1 permit _65..._
or, if I want to be sloppy,
ip as-path access-list 1 permit _6[45]..._
and applying it to all my bleeding transit.
Cheers.
-travis
> I have a question. Why do you allow Private ASNs into your network? We saw
Probably because making your upstream type "neighbor x.x.x.x
remove-private-AS" is a little more efficient than doing:
why depend on your upstream to protect your network from things you do not
want to hear?
and applying it to all my bleeding transit.
one simple route-map stanza can be applied to all of your upstreams... no
matter how bloody.
/rf
That's strange. Your 701 connection goes down and you've filtered any
backup route you had into them. Good thinking.
yea. i guess when you only have one link you would need to worry about
that. we have many links to ^701_
i guess in your case you would want to do
permit ^YOURTRANSITPROVIDERAS_701_
deny _701_
or something along those lines.
Christian
I always local-prefed paths to other upstreams down via a
specific upstream in my 2x removed previous life.
made traffic flow the "best" path and was useful when you had
a connection (but not directly to ANS, one of their "sub AsES") w/ ANS
and wanted to insure that traffic to ANS went over your ANS link instead
of via 1239, 701, or 3561 because of as-path win/tiebreak.
- jared