_65000_ in as-path - paging 8544, 16229, 37958
Hi, Seen in DFZ: 194.9.20.0 - 6661 42652 24611 34088 174 8544 16229 65000 196.216.161.0 - 8657 36881 36881 36881 36881 36881 36881 36881 36881 36881 36881 65000 33763 37036 We manage some bgp speakers running OpenBGPd. This software appears to tear down the session when encountering at least one of these paths : Dec 10 15:31:48 l1-c1 bgpd[15300]: neighbor 84.x.x.x (S): state change Established -> Idle, reason: Fatal error 194.9.20.0 looks like it started being originated by 65000 at 12:30 UTC today or so - this was also the time I started seeing openbgp behave this this way. Renesys thinks 12:58UTC. Andy
On Dec 10, 2008, at 10:40 AM, Andy Davidson wrote:
Hi,
Seen in DFZ:
194.9.20.0 - 6661 42652 24611 34088 174 8544 16229 65000
196.216.161.0 - 8657 36881 36881 36881 36881 36881 36881 36881 36881 36881 36881 65000 33763 37036
We manage some bgp speakers running OpenBGPd. This software appears to tear down the session when encountering at least one of these paths :
Dec 10 15:31:48 l1-c1 bgpd[15300]: neighbor 84.x.x.x (S): state change Established -> Idle, reason: Fatal error
194.9.20.0 looks like it started being originated by 65000 at 12:30 UTC today or so - this was also the time I started seeing openbgp behave this this way. Renesys thinks 12:58UTC.
In my DFZ BGP today I see AS 64553 IANA-RSVD2 | 1 prefixes | 1 prefixes & 1 ASN supported | 254 Addresses | 6 hops | as path 174 2914 9498 9730 9498 64553 AS 65000 IANA-RSVD2 | 1 prefixes | 1 prefixes & 1 ASN supported | 254 Addresses | 4 hops | as path 174 8544 16229 65000 AS 65009 IANA-RSVD2 | 2 prefixes | 2 prefixes & 1 ASN supported | 2300 Addresses | 3 hops | as path 174 8167 65009 AS 65500 IANA-RSVD2 | 1 prefixes | 1 prefixes & 1 ASN supported | 254 Addresses | 4 hops | as path 174 21385 33891 65500 AS 65530 IANA-RSVD2 | 2 prefixes | 2 prefixes & 1 ASN supported | 764 Addresses | 5 hops | as path 174 3320 5483 41313 65530 This is fairly typical. Is there some reason why 65000 is especially problematic ? Regards Marshall
Andy
On Dec 10, 2008, at 11:08 AM, Cvetan Ivanov wrote:
Hi,
Marshall Eubanks wrote:
Is there some reason why 65000 is especially problematic ?
65000 and above are private as numbers and should not be seen in the global table.
None of the numbers I included should be seen in the global tables, that is why I included them. However, these bogons are basically always there (not the same set, but something), and I as far as I can tell they are fairly benign. The "private" ASN I have tracked down in the past have all been apparently innocent mistakes. If someone wanted to phish from an AS, there are lots of others that would not be so obvious. Right now, for example, I see 19 ASN from Afrnic blocks with no WHOIS info at all, which worries me rather more. Regards Marshall
Cvetan
-- Cvetan Ivanov System Administrator SpectrumNet Jsc.
On 10 Dec 2008, at 16:20, Patrick W. Gilmore wrote:
On Dec 10, 2008, at 11:08 AM, Cvetan Ivanov wrote:
Marshall Eubanks wrote:
Is there some reason why 65000 is especially problematic ?
65000 and above are private as numbers and should not be seen in the global table.
64512 & above.
Indeed, the reference is RFC 1930 section 10, which says: 10. Reserved AS Numbers The Internet Assigned Numbers Authority (IANA) has reserved the following block of AS numbers for private use (not to be advertised on the global Internet): 64512 through 65535 Joe
On Thu, Dec 11, 2008 at 08:44:28AM -0500, Joe Abley wrote:
On 10 Dec 2008, at 16:20, Patrick W. Gilmore wrote:
On Dec 10, 2008, at 11:08 AM, Cvetan Ivanov wrote:
65000 and above are private as numbers and should not be seen in the global table.
64512 & above.
Indeed, the reference is RFC 1930 section 10, which says:
10. Reserved AS Numbers
The Internet Assigned Numbers Authority (IANA) has reserved the following block of AS numbers for private use (not to be advertised on the global Internet):
64512 through 65535
the recently published RFC5398 sets aside a few more to add to the permanent ASN bogon list. 64496-64511 Reserved for use in documentation and sample code 65536-65551 is reserved for same, for those playing in the 32-bit space. -- bill
participants (6)
-
Andy Davidson -
bill fumerola -
Cvetan Ivanov -
Joe Abley -
Marshall Eubanks -
Patrick W. Gilmore