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.
Anyone else seeing this:
*> 91.196.186.0/24 62.237.167.25 0 3292 3549 15703 43531 23456 ihttp://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 пишет:
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
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#
Saku Ytti 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 ISo 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_breaks_light_N45.pdf
- AS4 Wiki: http://as4.cluepon.net/index.php/Operational_Issues#AS_CONFED_SEQUENCE_in_AS4_PATH
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.txt).
Greg