Looking for 32-bit AS numbers, I get some strange results from routeviews: route-views>sh ip bgp regexp _23456_ BGP table version is 2393809200, local router ID is 128.223.51.103 Status codes: s suppressed, d damped, h history, * valid, > best, i - internal, r RIB-failure, S Stale Origin codes: i - IGP, e - EGP, ? - incomplete Network Next Hop Metric LocPrf Weight Path * 31.177.16.0/22 128.223.253.10 0 3582 3701 3356 23456 3.1043 i * 46.29.72.0/21 129.250.0.11 285 0 2914 12389 12389 12389 12389 23456 3.627 i * 46.243.96.0/21 154.11.11.113 0 0 852 174 39704 39704 23456 3.787 i * 91.208.62.0/24 154.11.11.113 0 0 852 174 39704 39704 23456 3.787 i * 91.217.87.0/24 194.85.40.15 0 3267 174 23456 3.661 i * 91.230.169.0/24 208.51.134.254 13905 0 3549 29152 29152 29152 29152 23456 23456 23456 23456 3.1426 i * 91.238.8.0/24 194.85.40.15 0 3267 8220 23456 3.2040 i * 111.235.148.0/22 194.85.40.15 0 3267 9498 9730 23456 i * 141.0.176.0/21 129.250.0.11 285 0 2914 12389 12389 12389 12389 23456 3.627 i Unless I missed something, AS 23456 is supposed to show up as a stand-in for 32-bit ASNs on 16-bit BGP implementations, not in _addition_ to 32-bit ASNs. So the penultimate line would make sense if the other lines weren't there and the others don't make sense period. Maybe a bug in the IOS they're running? route-views>sh ver Cisco IOS Software, 7200 Software (C7200P-ADVENTERPRISEK9-M), Version 12.4(24)T2, RELEASE SOFTWARE (fc2) Or is something else going on?
On Sun, Dec 16, 2012 at 11:48:13PM +0100, Iljitsch van Beijnum wrote:
Looking for 32-bit AS numbers, I get some strange results from routeviews:
route-views>sh ip bgp regexp _23456_ BGP table version is 2393809200, local router ID is 128.223.51.103 Status codes: s suppressed, d damped, h history, * valid, > best, i - internal, r RIB-failure, S Stale Origin codes: i - IGP, e - EGP, ? - incomplete
Network Next Hop Metric LocPrf Weight Path * 31.177.16.0/22 128.223.253.10 0 3582 3701 3356 23456 3.1043 i * 46.29.72.0/21 129.250.0.11 285 0 2914 12389 12389 12389 12389 23456 3.627 i * 46.243.96.0/21 154.11.11.113 0 0 852 174 39704 39704 23456 3.787 i * 91.208.62.0/24 154.11.11.113 0 0 852 174 39704 39704 23456 3.787 i * 91.217.87.0/24 194.85.40.15 0 3267 174 23456 3.661 i * 91.230.169.0/24 208.51.134.254 13905 0 3549 29152 29152 29152 29152 23456 23456 23456 23456 3.1426 i * 91.238.8.0/24 194.85.40.15 0 3267 8220 23456 3.2040 i * 111.235.148.0/22 194.85.40.15 0 3267 9498 9730 23456 i * 141.0.176.0/21 129.250.0.11 285 0 2914 12389 12389 12389 12389 23456 3.627 i
Unless I missed something, AS 23456 is supposed to show up as a stand-in for 32-bit ASNs on 16-bit BGP implementations, not in _addition_ to 32-bit ASNs. So the penultimate line would make sense if the other lines weren't there and the others don't make sense period.
Maybe a bug in the IOS they're running?
route-views>sh ver Cisco IOS Software, 7200 Software (C7200P-ADVENTERPRISEK9-M), Version 12.4(24)T2, RELEASE SOFTWARE (fc2)
Or is something else going on?
This can happen when a old 2-byte only routers are doing prepends with the neighbor address (4-byte). Then the magic in the 4-byte AS RFC to fix up ASPATH has no chance to work and you will see 23456. -- :wq Claudio
On Mon, Dec 17, 2012 at 6:14 AM, Claudio Jeker <cjeker@diehard.n-r-g.com> wrote:
This can happen when a old 2-byte only routers are doing prepends with the neighbor address (4-byte). Then the magic in the 4-byte AS RFC to fix up ASPATH has no chance to work and you will see 23456.
After a careful re-read of RFC4893 section 4.2.3 Processing Received Updates, I am fairly sure it is either an implementation issue with the involved 4-octet ASN routers, or else their transit providers are using as-path-*expand* when learning their routes for some reason (customers ask for the strangest things.) The specification for 4-octet AS refers to "old" and "new" BGP speakers, which I'll do here: When NEW speaker receives a route from an OLD speaker, its job is to make AS_PATH and AS4_PATH the same length by using ASNs from from AS_PATH, which cannot have been inserted into AS4_PATH by the OLD speaker(s) that do not support the Attribute. If a NEW speaker implements as-path-prepend incorrectly, and puts 23456 (AS_TRANS) into AS4_PATH instead of his real ASN, then the route passes through some OLD speakers and out to a NEW one again, the second NEW speaker has no opportunity to reconstruct the correct path. On the other hand, if an OLD speaker is configured for as-path-*expand* as it learns routes from a NEW speaker, then it may insert AS_TRANS into the AS_PATH but no entries are being pushed to AS4_PATH. This is a limitation of the specification and cannot be avoided. In effect, the use of as-path-* expand* at a NEW->OLD boundary where the NEW router has a 4-octet ASN and OLD router is performing *expand* means the correct AS_PATH cannot be rebuilt. -- Jeff S Wheeler <jsw@inconcepts.biz> Sr Network Operator / Innovative Network Concepts
On Sun, 16 Dec 2012 23:48:13 +0100, Iljitsch van Beijnum said:
Looking for 32-bit AS numbers, I get some strange results from routeviews:
Unless I missed something, AS 23456 is supposed to show up as a stand-in for 32-bit ASNs on 16-bit BGP implementations, not in _addition_ to 32-bit ASNs. So the penultimate line would make sense if the other lines weren't there and the others don't make sense period.
Maybe a bug in the IOS they're running?
Or is something else going on?
I think you've just found a number of AS's that are at high risk of being mystified when D-root shuts down 7 months from now. :)
On 12/16/12 2:48 PM, Iljitsch van Beijnum wrote:
Looking for 32-bit AS numbers, I get some strange results from routeviews:
route-views>sh ip bgp regexp _23456_ BGP table version is 2393809200, local router ID is 128.223.51.103 Status codes: s suppressed, d damped, h history, * valid, > best, i - internal, r RIB-failure, S Stale Origin codes: i - IGP, e - EGP, ? - incomplete
Network Next Hop Metric LocPrf Weight Path * 31.177.16.0/22 128.223.253.10 0 3582 3701 3356 23456 3.1043 i * 46.29.72.0/21 129.250.0.11 285 0 2914 12389 12389 12389 12389 23456 3.627 i * 46.243.96.0/21 154.11.11.113 0 0 852 174 39704 39704 23456 3.787 i * 91.208.62.0/24 154.11.11.113 0 0 852 174 39704 39704 23456 3.787 i * 91.217.87.0/24 194.85.40.15 0 3267 174 23456 3.661 i * 91.230.169.0/24 208.51.134.254 13905 0 3549 29152 29152 29152 29152 23456 23456 23456 23456 3.1426 i * 91.238.8.0/24 194.85.40.15 0 3267 8220 23456 3.2040 i * 111.235.148.0/22 194.85.40.15 0 3267 9498 9730 23456 i * 141.0.176.0/21 129.250.0.11 285 0 2914 12389 12389 12389 12389 23456 3.627 i
Unless I missed something, AS 23456 is supposed to show up as a stand-in for 32-bit ASNs on 16-bit BGP implementations, not in _addition_ to 32-bit ASNs. So the penultimate line would make sense if the other lines weren't there and the others don't make sense period.
Maybe a bug in the IOS they're running?
route-views>sh ver Cisco IOS Software, 7200 Software (C7200P-ADVENTERPRISEK9-M), Version 12.4(24)T2, RELEASE SOFTWARE (fc2)
Or is something else going on?
Off topic, this reminds me I would rather have ASPLAIN again. We switched a couple of years ago on a particular user request. If there is no objection, I would love to switch back ASAP. This would be on route-views, and on route-views3. Just asking if others concur? -- John Kemp (kemp@routeviews.org) RouteViews Engineer NOC: noc@routeviews.org MAIL: help@routeviews.org WWW: http://www.routeviews.org
Off topic, this reminds me I would rather have ASPLAIN again. We switched a couple of years ago on a particular user request.
listening to those pesky users, eh?
If there is no objection, I would love to switch back ASAP. This would be on route-views, and on route-views3. Just asking if others concur?
makes sense to me randy
+1 On Tue, Dec 18, 2012 at 9:23 PM, Randy Bush <randy@psg.com> wrote:
Off topic, this reminds me I would rather have ASPLAIN again. We switched a couple of years ago on a particular user request.
listening to those pesky users, eh?
If there is no objection, I would love to switch back ASAP. This would be on route-views, and on route-views3. Just asking if others concur?
makes sense to me
randy
participants (8)
-
Claudio Jeker -
Iljitsch van Beijnum -
Jeff Wheeler -
John Kemp -
Nick Hilliard -
Randy Bush -
Tony Tauber -
Valdis.Kletnieks＠vt.edu