An alternative local AS number that can be used to establish a session with this peer. This is used when merging two ASs into a single AS. A value of zero means 'not configured'. If an alternative local AS number is configured then the peering session can be established using the alternative local AS instead of the primary local AS number specified by bgpRmEntLocalAs. Setting an alternative local AS number allows the primary local AS number to be changed without reconfiguring the peer at the same time. Later the peer can be reconfigured to establish the session using the new remote AS number and the alternative local AS number can be reset to zero. An alternative local AS number should only be used as an intermediate step on one side of a BGP session. Do not configure an alternative local AS number on both sides of a BGP session - configure the correct remote AS numbers instead. If this is an IBGP peer then bgpPeerRemoteAs must have the same value as bgpRmEntLocalAs. In this case the IBGP session can be established using either bgpRmEntLocalAs/bgpPeerRemoteAs or bgpPeerConfAltLocalAs. If this is an EBGP peer then bgpPeerRemoteAs must specify the remote peer's AS number, and bgpRmEntLocalAs, bgpPeerConfAltLocalAs and bgpPeerRemoteAs must all be different. In this case the EBGP session can be established using bgpRmEntLocalAs or bgpPeerConfAltLocalAs as the local AS number, but the remote AS number must match bgpPeerRemoteAs. The bgpPeerConfAltLocalAsMode field controls detailed operation of the alternative local AS number, including whether the peering session can be established using bgpRmEntLocalAs or only using bgpPeerConfAltLocalAs. Use of alternative local AS numbers is not supported if the router is a member of a confederation. The constraints explained above mean that this field is only used if the following conditions are all met: - bgpRmEntConfederationId = 0 - bgpPeerConfAltLocalAs != 0 - bgpPeerConfAltLocalAs != bgpRmEntLocalAs - bgpPeerConfAltLocalAs != bgpPeerRemoteAs. This field can be changed at any time. However, if the field is changed while the peer is admin_status UP, the change will only take effect after the peer has been cycled admin_status DOWN and then UP, thus forcing the peer session to be restarted. In this case, until the peer is set admin_status DOWN, the peer will be marked as out of date (as reported by the config_state field in the AMB_BGP_PEER_STATUS row for the peer).