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.

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.

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

The adjacency is now up.

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

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.

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.

Now the AS-path looks like expected.

So what does the update look like over at R3?

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.

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

10 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
  • September 20, 2017 at 9:30 am
    Permalink

    Hello ,

    Nice Post .

    What if R1 and R2 are the RRs in the same example ? It means R1 is RR in AS 100 and R2 is RR in AS 64512. Could you please explain how it would work in such case ?

    R1 peers with RR R2 in as 100 . R2 peers with RR R1 with local-as command 100. Right ?

    Thanks,
    Gaurav Sukahdia

    Reply

Leave a Reply

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

%d bloggers like this: