Usage of a Well Known Autonomous System Number '23456' (=AS_TRANS)Source: https://www.cisco.com/c/en/us/products/collateral/ios-nx-os-software/border-gateway-protocol-bgp/whi...
To facilitate compatibility and gradual upgrade, RFC4893 defines a well known 4-octet Autonomous System number for backward compatibility. This well known AS number is '23456', also known as AS_TRANS.
This well known AS number is used by a NEW BGP speaker peering with an OLD BGP speaker in two situations:
1. If a NEW BGP speaker is using a true 4-octet AS number. A true 4-octet AS number is an AS number which can not fully be represented by a 2-octet AS number. (for example AS# "100.100" can not be represented by a 2-octet AS number, where AS# "0.100" could be represented like AS# "100" towards an OLD BGP speaker, by dropping the leading 16 zero's of the full 4-octet AS number). The OLD BGP speaker expects to peer with a BGP speaker that belongs to a 2-octet Autonomous System, and hence the NEW BGP speaker will either remove the 16 leading zero's from its AS#, or it will swap the non-mappable 4-octet AS# with well known AS# "23456"
2. In similar manner, the 4-octet AS-Path is manipulated by a NEW BGP speaker peering with an OLD BGP speaker. An OLD BGP speaker can not understand any 4-octet AS numbers, and hence the NEW BGP speaker will create from its AS-Path, consisting of all 4-octet AS hops, an AS-Path which only contains 2-octet AS hops. For each entry in the AS-Path, the NEW BGP speaker will decide if it is a mappable AS# or not. If it is a mappable AS#, then the leading 16 "zeros" are removed. If the AS# is a non-mappable AS#, then the NEW BGP speaker will swap the AS hop entry with well known AS# "23456"
A side effect from the compatibility between OLD and NEW BGP speakers is that the usage of "23456" as the BGP AS# is not possible. If an OLD BGP speaker would be configured to belong to AS "23456", then this OLD BGP speaker will result as a AS-Path loop detection drop by any BGP routes that have AS# "23456" within the AS-Path list, resulting in an incomplete view from the OLD BGP speaker perspective.
An additional side effect could be if the NEW BGP speaker belongs, for example, to AS# 100.100 and the OLD BGP speaker to AS# 200. Then, there should be an eBGP session with both BGP speakers. If the OLD BGP Speaker would be wrongly configured as belonging to AS# "23456", then instead of an eBGP peering, an iBGP peering would be established between the OLD and NEW BGP speaker, which is highly undesirable, resulting in the wrong BGP behavior.