_65000_ in as-path - paging 8544, 16229, 37958

Mailman List Mirror (Read Only)
1

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

2

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

3

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.

Cvetan

4

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

5

64512 & above.

6

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

7

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