Anyone else seeing this: *> 91.196.186.0/24 62.237.167.25 0 3292 3549 15703 43531 23456 i http://www.ietf.org/rfc/rfc4893.txt 6. Transition An OLD BGP speaker MUST NOT use AS_TRANS as its Autonomous System number. -- ++ytti
Anyone else seeing this: *> 91.196.186.0/24 62.237.167.25 0 3292 3549 15703 43531 23456 i
http://www.ietf.org/rfc/rfc4893.txt 6. Transition An OLD BGP speaker MUST NOT use AS_TRANS as its Autonomous System number.
Seeing it here too. On our 4-byte capable routers: 91.196.186.0/24 *[BGP/170] 1d 13:36:53, MED 0, localpref 105, from 193.75.0.204 AS path: 16150 15703 43531 AS_TRANS I AS path: 3356 6461 15703 43531 AS_TRANS I AS path: 1299 3549 15703 43531 AS_TRANS I And on our non 4-byte capable routers it is simply shown as 23456. This ASN should not be used to originate prefixes, agreed. Steinar Haug, Nethelp consulting, sthaug@nethelp.no
Take a watch on this route: show route 195.128.231.0/24 detail [..omitted..] AS path: AS2 PA[5]: 39792 35320 AS_TRANS AS_TRANS 35748 AS path: AS4 PA[4]: 35320 3.21 AS_TRANS 35748 AS path: Merged[5]: 39792 35320 3.21 AS_TRANS 35748 I [...omitted...] AS4_PATH contain AS_TRANS, it's also RFC violation, isn't it ? sthaug@nethelp.no пишет:
Anyone else seeing this: *> 91.196.186.0/24 62.237.167.25 0 3292 3549 15703 43531 23456 i
http://www.ietf.org/rfc/rfc4893.txt 6. Transition An OLD BGP speaker MUST NOT use AS_TRANS as its Autonomous System number.
Seeing it here too. On our 4-byte capable routers:
91.196.186.0/24 *[BGP/170] 1d 13:36:53, MED 0, localpref 105, from 193.75.0.204 AS path: 16150 15703 43531 AS_TRANS I AS path: 3356 6461 15703 43531 AS_TRANS I AS path: 1299 3549 15703 43531 AS_TRANS I
And on our non 4-byte capable routers it is simply shown as 23456. This ASN should not be used to originate prefixes, agreed.
Steinar Haug, Nethelp consulting, sthaug@nethelp.no
-- С уважением, Егор Зимин
Take a watch on this route:
show route 195.128.231.0/24 detail [..omitted..] AS path: AS2 PA[5]: 39792 35320 AS_TRANS AS_TRANS 35748 AS path: AS4 PA[4]: 35320 3.21 AS_TRANS 35748 AS path: Merged[5]: 39792 35320 3.21 AS_TRANS 35748 I [...omitted...]
AS4_PATH contain AS_TRANS, it's also RFC violation, isn't it ?
Agreed, that sounds wrong. However, that's not how the route appears from here: show route 195.128.231.0/24 detail | match "AS path: [0-9AM]" AS path: 9002 13249 13249 13249 6886 196629 35748 I AS path: 9002 13249 13249 13249 6886 196629 35748 I AS path: AS2 PA[5]: 3356 13249 6886 AS_TRANS 35748 AS path: AS4 PA[4]: 13249 6886 196629 35748 AS path: Merged[5]: 3356 13249 6886 196629 35748 I AS path: AS2 PA[6]: 1299 3356 13249 6886 AS_TRANS 35748 AS path: AS4 PA[4]: 13249 6886 196629 35748 AS path: Merged[6]: 1299 3356 13249 6886 196629 35748 I So in our case the AS4 path seems normal. Steinar Haug, Nethelp consulting, sthaug@nethelp.no
On (2009-02-28 18:05 +0100), sthaug@nethelp.no wrote:
show route 195.128.231.0/24 detail [..omitted..] AS path: AS2 PA[5]: 39792 35320 AS_TRANS AS_TRANS 35748 AS path: AS4 PA[4]: 35320 3.21 AS_TRANS 35748 AS path: Merged[5]: 39792 35320 3.21 AS_TRANS 35748 I [...omitted...]
Agreed, that sounds wrong. However, that's not how the route appears from here:
show route 195.128.231.0/24 detail | match "AS path: [0-9AM]" AS path: AS2 PA[5]: 3356 13249 6886 AS_TRANS 35748 AS path: AS4 PA[4]: 13249 6886 196629 35748 AS path: Merged[5]: 3356 13249 6886 196629 35748 I AS path: AS2 PA[6]: 1299 3356 13249 6886 AS_TRANS 35748 AS path: AS4 PA[4]: 13249 6886 196629 35748 AS path: Merged[6]: 1299 3356 13249 6886 196629 35748 I
So in our case the AS4 path seems normal.
Looks OK in cisco as-dot format too, so unlike first example, I think this may be local problem. gw.ip.fi#show ip bgp 195.128.231.0/24 BGP routing table entry for 195.128.231.0/24, version 29 Paths: (1 available, best #1, table Default-IP-Routing-Table) Multipath: eBGP Not advertised to any peer 3292 3356 13249 6886 3.21 35748, (received & used) 62.237.167.25 from 62.237.167.25 (62.236.0.5) Origin IGP, localpref 100, valid, external, best Community: 3292:1101 3292:1901 gw.ip.fi# -- ++ytti
Saku Ytti wrote:
On (2009-02-28 18:05 +0100), sthaug@nethelp.no wrote:
show route 195.128.231.0/24 detail [..omitted..] AS path: AS2 PA[5]: 39792 35320 AS_TRANS AS_TRANS 35748 AS path: AS4 PA[4]: 35320 3.21 AS_TRANS 35748 AS path: Merged[5]: 39792 35320 3.21 AS_TRANS 35748 I [...omitted...] Agreed, that sounds wrong. However, that's not how the route appears from here:
show route 195.128.231.0/24 detail | match "AS path: [0-9AM]" AS path: AS2 PA[5]: 3356 13249 6886 AS_TRANS 35748 AS path: AS4 PA[4]: 13249 6886 196629 35748 AS path: Merged[5]: 3356 13249 6886 196629 35748 I AS path: AS2 PA[6]: 1299 3356 13249 6886 AS_TRANS 35748 AS path: AS4 PA[4]: 13249 6886 196629 35748 AS path: Merged[6]: 1299 3356 13249 6886 196629 35748 I
So in our case the AS4 path seems normal.
Looks OK in cisco as-dot format too, so unlike first example, I think this may be local problem.
gw.ip.fi#show ip bgp 195.128.231.0/24 BGP routing table entry for 195.128.231.0/24, version 29 Paths: (1 available, best #1, table Default-IP-Routing-Table) Multipath: eBGP Not advertised to any peer 3292 3356 13249 6886 3.21 35748, (received & used) 62.237.167.25 from 62.237.167.25 (62.236.0.5) Origin IGP, localpref 100, valid, external, best Community: 3292:1101 3292:1901 gw.ip.fi#
We have same result, like the first example from Steinar Haug.
show route 195.128.231.0/24 detail | match "AS path" AS path: AS2 PA[6]: 15685 29208 35320 AS_TRANS AS_TRANS 35748 AS path: AS4 PA[4]: 35320 196629 AS_TRANS 35748 AS path: Merged[6]: 15685 29208 35320 196629 AS_TRANS 35748 I ... AS path: AS2 PA[7]: 9002 13249 13249 13249 6886 AS_TRANS 35748 AS path: AS4 PA[6]: 13249 13249 13249 6886 196629 35748 AS path: Merged[7]: 9002 13249 13249 13249 6886 196629 35748 I
Note: If propagated via AS196629,AS35320,.... then the AS4_PATH contains AS_TRANS. Em.
These prefixes all appeared with this problem late last December: 91.207.218.0/23 35320 196629 23456 195.128.230.0/24 35320 196629 23456 35748 195.128.231.0/24 35320 196629 23456 35748 The ill side effects of the AS_CONFED_SEQUENCE in an AS4_PATH and analysis on what is going on were covered in excellent detail by Andy Davidson, Jonathan Oddy, and Rob Shakir: - NANOG thread: http://www.merit.edu/mail.archives/nanog/msg14345.html - NANOG45 presentation: http://www.nanog.org/meetings/nanog45/presentations/Monday/Davidson_asn4_bre... - AS4 Wiki: http://as4.cluepon.net/index.php/Operational_Issues#AS_CONFED_SEQUENCE_in_AS... Numerous attempts to contact AS 35320's NOC and peering folks about the problem by several people have pretty much been ignored. 91.196.186.0/24 looks like it just showed up with a broken AS path in the past couple of days. We'll probably see it a lot more regular invalid uses of 23456 in the future... I mean, how often does someone leak a private ASN :-)? Perhaps it is a good idea for router and routing software vendors to add 23456 to "neighbor remove-private-as". Incidentally, while RFC 4893bis will include better error handling for 32-bit ASNs, a new I-D to suggest better error handling for all optional transitive attributes was just released yesterday (http://www.ietf.org/internet-drafts/draft-scudder-idr-optional-transitive-00...). Greg -- Greg Hankins <ghankins@mindspring.com> +1 404 542 5530
participants (5)
-
Egor Zimin -
Emanuel Petr -
Greg Hankins -
Saku Ytti -
sthaug＠nethelp.no