Routing – wrong BGP AS number transmitted

bgprouting

i have a problem with BGP AS number. We have configured two BGP peers to different ISPs on a Cisco ISR4451-X Router. One peer works fine but at the second peer the state oft the connection is always idle.
When I look into the logging I see that the wrong AS number is transmitted:
I have configured the AS 202xxx but transmitted is always the number 23456.

Log Buffer (4096 bytes):
Dec 20 12:52:13.940: BGP_Router: unhandled major event code 128,minor 0
Dec 20 12:52:19.609: BGP: xxx active went from Idle to Active
Dec 20 12:52:19.609: BGP: xxx open active, local address xxx
Dec 20 12:52:19.621: BGP: ses global xxx (0x7F33116D6630:0) act Adding topology IPv4 Unicast:base
Dec 20 12:52:19.621: BGP: ses global xxx (0x7F33116D6630:0) act Send OPEN
Dec 20 12:52:19.621: BGP: xxx active went from Active to OpenSent
Dec 20 12:52:19.621: BGP: xxx active sending OPEN, version 4, my as: 23456, holdtime 180 seconds, ID B99E6022
Dec 20 12:52:19.634: BGP: ses global xxx (0x7F33116D6630:0) act Remote close.
Dec 20 12:52:19.634: BGP: nbr_topo global xxx IPv4 Unicast:base (0x7F33116D6630:0) Not scheduling for GR processing [Peer did not advertise GR cap]
Dec 20 12:52:19.634: %BGP-5-NBR_RESET: Neighbor xxx active reset (Peer closed the session)
Dec 20 12:52:19.634: BGP: ses global xxx (0x7F33116D6630:0) act Reset (Peer closed the session).
Dec 20 12:52:19.634: BGP: nbr_topo global xxx IPv4 Unicast:base (0x7F33116D6630:0) NSF delete stale NSF not active
Dec 20 12:52:19.634: BGP: nbr_topo global xxx IPv4 Unicast:base (0x7F33116D6630:0) NSF no stale paths state is NSF not active
Dec 20 12:52:19.634: BGP: nbr_topo global xxx IPv4 Unicast:base (0x7F33116D6630:0) Resetting ALL counters.
Dec 20 12:52:19.634: BGP: xxx active closing
Dec 20 12:52:19.634: BGP: ses global xxx (0x7F33116D6630:0) act Session close and reset neighbor xxx topostate
Dec 20 12:52:19.634: BGP: nbr_topo global xxx IPv4 Unicast:base (0x7F33116D6630:0) Resetting ALL counters.
Dec 20 12:52:19.634: BGP: xxx active went from OpenSent to Idle
Dec 20 12:52:19.634: %BGP_SESSION-5-ADJCHANGE: neighbor xxx IPv4 Unicast topology base removed from session  Peer closed the session

A monitor capture output with wireshark also show the wrong AS Number and the BGP notification message show Bad Peer AS.

Border Gateway Protocol – OPEN Message

   Marker: ffffffffffffffffffffffffffffffff
   Length: 29
   Type: OPEN Message (1)
   Version: 4
   My AS: 23456
   Hold Time: 180
   BGP Identifier: xxx
   Optional Parameters Length: 0

Border Gateway Protocol – NOTIFICATION Message

Marker: ffffffffffffffffffffffffffffffff
Length: 21
Type: NOTIFICATION Message (3)
Major error Code: OPEN Message Error (2)
Minor error Code (Open Message): Bad Peer AS (2)

router bgp 202xxx
bgp router-id xxx
bgp log-neighbor-changes
neighbor xxx remote-as 212xx
neighbor xxx dont-capability-negotiate
neighbor xxx password 7 0337723xxxxxxxx

BGP router identifier xxx, local AS number 202xxx
BGP table version is 1814938, main routing table version 1814938
613561 network entries using 152163128 bytes of memory
613561 path entries using 73627320 bytes of memory
102358/96231 BGP path/bestpath attribute entries using 25384784 bytes of memory
88809 BGP AS-PATH entries using 4146064 bytes of memory
1 BGP ATTR_SET entries using 40 bytes of memory
201 BGP community entries using 7928 bytes of memory
0 BGP route-map cache entries using 0 bytes of memory
0 BGP filter-list cache entries using 0 bytes of memory
BGP using 255329224 total bytes of memory
BGP activity 1988167/1374600 prefixes, 3700228/2473531 paths, scan interval 60 secs


Neighbor    V    AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down    State/PfxRcd
xxx         4   xxx    0      0        1       0   0    5d04h    Idle
xxx         4   xxx  609982   3337     1814810 0   0    1d01h    613562
xxx         4   xxx     0      0        1       0   0    never    Active

Why is the wrong AS transmitted at this peer?

Best Answer

AS23456 is a special ASN called "AS_TRANS". When 4-byte ASN's were introduced to deal with the shortage of AS-numbers, not every router was running software able to handle that. AS23456 was used so routers only supporting 2-byte ASN's are able to properly handle routes to 4-byte ASN's without needing to upgrade them. You can read more about this in RFC 4893.

I'm a bit amazed your router still logs that AS as its local ASN though. 4-byte AS numbers have been the standard for a long time now.