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
At 07:34 04/04/01 -0400, Marshall Eubanks wrote:
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 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
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 On Wed, 4 Apr 2001, Marshall Eubanks wrote:
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
On Wed, Apr 04, 2001 at 07:50:47AM -0400, Travis Pugh wrote: [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 -- Joe Provo Voice 508.486.7471 Director, Internet Planning & Design Fax 508.229.2375 Network Deployment & Management, RCN <joe.provo@rcn.com>
Date: Wed, 4 Apr 2001 09:30:04 -0400 From: Joe Provo <joe.provo@rcn.com> Sender: owner-nanog@merit.edu
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.
I asked the WCOM folks and they told me that there were no current plans for a router server at the ATM MAEs, but that customers who wanted one should let them know as it is still an open issue. R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: oberman@es.net Phone: +1 510 486-8634
On Wed, 4 Apr 2001, Travis Pugh wrote:
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.
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
On Wed, 4 Apr 2001, Christian Nielsen wrote:
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
Christian
On Wed, 4 Apr 2001, Travis Pugh wrote:
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
On Wed, 4 Apr 2001, Christian Nielsen wrote:
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.
That's strange. Your 701 connection goes down and you've filtered any backup route you had into them. Good thinking. --- John Fraizer EnterZone, Inc
On Wed, 4 Apr 2001, John Fraizer wrote:
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
On Wed, Apr 04, 2001 at 04:03:07PM -0400, John Fraizer wrote:
On Wed, 4 Apr 2001, Christian Nielsen wrote:
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.
That's strange. Your 701 connection goes down and you've filtered any backup route you had into them. Good thinking.
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 -- Jared Mauch | pgp key available via finger from jared@puck.nether.net clue++; | http://puck.nether.net/~jared/ My statements are only mine.
On Wed, 4 Apr 2001, Christian Nielsen wrote:
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.
That's strange. Your 701 connection goes down and you've filtered any backup route you had into them. Good thinking.
--- John Fraizer EnterZone, Inc
AhHa! the light dawns and Bill sees the error of his ways... and seeking to banish the curse of ASSUMPTION, he points out to John that the statement; "Your ... connection goes down ... you've filtered any backup route" presuposes certain preexiting conditions. Please note Johns presumption of the singular. I expect the environment Christian is in may not suffer the presumption of singularity, at least where such filtering is in place. --bill
participants (10)
-
bmanning＠vacation.karoshi.com -
Christian Nielsen -
Hank Nussbacher -
Jared Mauch -
Joe Provo -
John Fraizer -
Kevin Oberman -
Marshall Eubanks -
Rich Fulton -
Travis Pugh