BGP – local-as command

The neighbor local-as command is a useful command when doing AS migration or merging.
Many people get confused by the optional arguments of this command. As we all
know the AS-path is a well known mandatory attribute of the BGP protocol.
Normally a router will prepend its local AS number onto the BGP updates
and send them to the eBGP neighbors. We start out with this configuration.

R1#sh run | s router bgp
router bgp 100
 no synchronization
 bgp log-neighbor-changes
 neighbor 10.0.0.2 remote-as 200
 no auto-summary

R2#sh run | s router bgp
router bgp 64512
 no synchronization
 bgp log-neighbor-changes
 neighbor 10.0.0.1 remote-as 100
 no auto-summary

Obviously this will not work as R1 is expecting another AS in the BGP Open
message. So R2 has to pretend that it is coming from AS 200. First we add
another router R3 that will announce the 3.3.3.0/24 prefix to R2. This is
just to demonstrate the difference in AS-path in an easier way. We see
that R2 is receiving the prefix.

R2#sh bgp ipv4 uni
BGP table version is 2, local router ID is 10.0.0.2
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
*> 3.3.3.0/24       20.0.0.3                 0             0 300 i

Now we will use the local-as command on R2 to fool R1 that it is coming
from AS 200.

R2(config)#router bgp 64512
R2(config-router)#nei 10.0.0.1 local-as 200

The adjacency is now up.

%BGP-5-ADJCHANGE: neighbor 10.0.0.1 Up

What does the AS-path look like over at R1?

R1#sh bgp ipv4 uni
BGP table version is 2, local router ID is 10.0.0.1
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
*> 3.3.3.0/24       10.0.0.2                               0 200 64512 300 i

AS 300 originated the route and then we see that both AS numbers from R2 have
been prepended. The options we have now is to use no-prepend and replace-as.
We look at no-prepend first.

To understand how no-prepend works we need to announce a prefix from R1.
The no-prepend option applies to incoming updates and not outgoing which
is a common source of confusion. We announce 1.1.1.0/24 from R1 and look at
it without the no-prepend option.

R2#sh bgp ipv4 uni
BGP table version is 3, local router ID is 10.0.0.2
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
*> 1.1.1.0/24       10.0.0.1                 0             0 200 100 i

We see that our local-as AS number has been prepended to the update
coming from R1. Now we will add the no-prepend option.

R2(config-router)#nei 10.0.0.1 local-as 200 no-prepend

Now the AS-path looks like expected.

R2#sh bgp ipv4 uni
BGP table version is 5, local router ID is 10.0.0.2
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
*> 1.1.1.0/24       10.0.0.1                 0             0 100 i
*> 3.3.3.0/24       20.0.0.3                 0             0 300 i

So what does the update look like over at R3?

R3#sh bgp ipv4 uni
BGP table version is 5, local router ID is 3.3.3.3
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
*> 1.1.1.0/24       20.0.0.2                               0 64512 100 i
*> 3.3.3.0/24       0.0.0.0                  0         32768 i

We can see that the BGP AS from the BGP process has been added to the outgoing
update. Without the no-prepend we would see AS 200 here as well. This might
not be wanted if we want to appear as one AS to someone but not reveal it to
other peers.

We also have the option of using replace-as. Let us try that.

R2(config-router)#nei 10.0.0.1 local-as 200 no-prepend replace-as

R1#sh bgp ipv4 uni
BGP table version is 11, local router ID is 10.0.0.1
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
*> 1.1.1.0/24       0.0.0.0                  0         32768 i
*> 3.3.3.0/24       10.0.0.2                               0 200 300 i

R1 now only sees the AS from the local-as command so they don’t know that
we are really AS 64512. The final option is to use dual-as which means that
the peer can initiate the BGP adjacency to either AS 64512 or 200, both will
work.

So the summary is that local-as is used to pretend to be another AS. By default
both the local-as AS and the BGP process AS will be prepended to outgoing updates
where the local-as AS will be added last in the AS-path. Incoming updates will have
the local-as AS prepended and then the BGP process AS prepended last when set to
other eBGP peers, this might not be desirable and can be configured with no-prepend.
If we use replace-as then the neighbor that we have configured local-as for will only
see the AS we are pretending to be and not the locally configured AS from the BGP
process.