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.

BGP – local-as command

9 thoughts on “BGP – local-as command

  • August 16, 2012 at 6:39 am
    Permalink

    Thanks! I’ve always seen these options, but never really needed to use anything but the few “default” settings to get peering up. For my small network, I don’t see any use cases, but I’ll test it in my lab.

    Reply
  • August 16, 2012 at 8:46 am
    Permalink

    Yes I agree that this would not be very common. The use case would be for mergers or acquisitions. Maybe you have reconfigured your AS but it is difficult to have all your peers change peering at the same time, then you could configure with dual-as.

    Replace-as would be useful if you have changed AS but you still want to appear as your old AS to your customers. That means you also have to configure no-prepend.

    Reply
  • August 17, 2012 at 7:13 am
    Permalink

    I’ve made some notes in my network book. We may need to some trickery when we move one of our BGP end points to a different data center towards the end of the year. Maybe this will be the ace up my sleeve 🙂

    This blog is super awesome. The level of details, diagrams and explanations is very very good. Thank you

    -P

    Reply
    • August 17, 2012 at 8:39 am
      Permalink

      That is great that you like it Petter 🙂 It’s a good learning experience for me to put down my thoughts into text. Hopefully in the future I hope to do some more teaching and maybe produce some training products. We will see what happens.

      Thanks for reading 🙂

      Reply
  • February 3, 2013 at 1:54 pm
    Permalink

    good explanation…left dual-as in between

    Reply
  • Pingback: VRF-Lite & BGP | FrÃ¥n CCNA till certifierad CCIE

  • October 28, 2015 at 7:00 pm
    Permalink

    Very good explanation

    Reply
  • November 16, 2015 at 12:18 am
    Permalink

    Excellent explanation. couple points though arises:

    1. I am really wondering why not just use dual-as at all times to avoid complications and be prepared for other external peers migration.

    2. What i have found out is that if the internal AS domain routers have already migrated to the new AS then it safe to NOT prepend local-as. is it true ?

    many thanks.

    Reply
    • November 16, 2015 at 1:07 pm
      Permalink

      1. I think that would be possible. The only risk I suppose is that an andministrator from the other side pulls the trigger too early so to speak and configures BGP towards new AS before other side is ready. Maybe there is a need to update filters and so on.

      2. Yes, I would agree with that. If the local AS is prepended there would be a risk of BGP dropping the update due to the loop prevention mechanism.

      Reply

Leave a Reply

Your email address will not be published. Required fields are marked *

%d bloggers like this: