MPLS Layer 3 VPN BGP Allow-AS-In

Lessons Discussion
1

This topic is to discuss the following lesson:

2

Hi Rene,

I want to know the configuration, where the customer will be using bgp protocol.

what will be the steps for CE1 to PE1, PE1-P-PE2, CE2to PE2.

kindly reply.

S Alladi

3

Hi S,

Here is a step-by-step walkthrough:

https://networklessons.com/mpls/mpls-layer-3-vpn-configuration/

Rene

4

Hi Rene,

Thanks! Very Good explanation.

Davis

5

HI Rene,

you mentioned two methods to solve the two same AS issue.

Use Allow-AS in to overrule the loop prevention mechanism of external BGP.
Use AS override to change the AS number on the PE routers.

my question is that among both method which method should I use for which situation?

thanks,
Nyi Nyi.

6

Hi Nyi Nyi,

Both will get the job done, the main difference is that allow AS in is configured on the customer routers and AS override is done on the SP routers. In the real world you probably don’t have access to both the customer and SP routers so it’s possible that only one of the two options is available to you.

Rene

7

Hi Rene,

Thank you for your clarification.

Nyi Nyi.

8



Hi Rene,
everything was clear about this lesson but am confused why did you configure AS 12 on Router CE1? It should have been AS1. If we configure different AS then we dont have to use Allowas-in command, right?

hostname CE1
!
interface Loopback0
 ip address 1.1.1.1 255.255.255.255
!
interface GigabitEthernet0/1
 ip address 192.168.12.1 255.255.255.0
 duplex auto
 speed auto
 media-type rj45
!
router bgp 12
 bgp log-neighbor-changes
 network 1.1.1.1 mask 255.255.255.255
 neighbor 192.168.12.2 remote-as 234
 neighbor 192.168.12.2 allowas-in
!
end
9

Lal,
Good catch. The text of the article is consistent in that each CE is using AS 12, but the picture at the beginning of the article shows them as using AS 1 (it should be 12). I will make sure this gets corrected.

It’s clear you have paid attention and understood the lesson!

10

Hi Lal & Andrew,

Quick update: I just fixed the picture so that it shows AS12 now.

Rene

11

Excellent lab Rene! keep it up!

12

Hi Rene,

Might be a dumb question… but can i just know the reason why under address-family ipv4 the neighbor was set to “No” to be activated?

13

Hi Eleever,

You mean this part?

 address-family ipv4
  no neighbor 4.4.4.4 activate
 exit-address-family
 !
 address-family vpnv4
  neighbor 4.4.4.4 activate
  neighbor 4.4.4.4 send-community extended
 exit-address-family

What is does is that we don’t exchange IPv4 unicast routes but only VPNv4 routes with our neighbor.

Rene

15

Hi,
I’m not sure to understand what is a vpnv4.
Is it relatetd only to mpls?
Thanks

16

Hello Giovanni

An MLPS VPN is used so that routing information from one customer is completely separated from the other customers and tunneled over the service provider MPLS network. The RD and the prefix combined is what we call a VPNv4 route which is used to differentiate between the different prefixes of the customers.

You can find out more information about this at the MPLS Layer 3 VPN Explained. If you are not familiar with MPLS, it would be a good idea to first get to grips with it by going through the MPLS course.

I hope this has been helpful!

Laz

17

As the lesson generally is part of BGP course, maybe it would be helpful to also mention another way to deal with such problems as getting resolved in this (and following) chapter, particularly in non-mpls environment - thats ‘local-as’. It seems provides somewhat more flexible solution (not to mention sounds less scary than ‘allow-as’ or ‘override…’ :slight_smile: ). I would bet it is used more often in real world. That would nicely round up the whole issue for BGP. On a side note, I would go even as far as make local-as a standard on my network - it decouples BGP instance number from peered ASN. Make all BGP instance on your network the same (say 65000 or even ‘1’) everywhere and use local-as (with its attributes) to establish what ASN is used for peering on each particular router and you are set. No more headache with overlapping ASNs or hitting a wall with trying to use different ASN in different VRF on the same router - all it takes to control is to enter one line of command.

18

Hello Vadim

Hmm, that’s an interesting approach. I’m not sure I completely understand it. The local-AS is well-known BGP community that is used for confederations. It’s essentially a no-export community but for use within a sub-AS of a confederation. You can find out more about it here:

The allow-AS in and AS override seem to me to be a simpler approach. Can you elaborate on your suggestion so that we can explore it further?

Thanks!

Laz

19

Laz, the ‘local-as’ I was referring to is a feature (currently supported on all CISCO OS, though with certain limitations on some, and also in Juniper, for instance), its not a community (that’s I was not referring to community with this name).

It’s a neighbor clause ‘neighbor X local-as xxxxx ’ . It replaces the BGP instance name with whatever other ASN you want to use for peering, in essence looking to the router as another virtual router in front of it. Essentially it de-couples the BGP instance name from BGP peering ASN (somewhat similarly to OSPF instance name not used for peering, using the area number for that). Implications are obvious – you are no longer tied to whatever BGP instance you have – its somewhat like having multiple BGP instances on the same router and only needing to modify one line of code if you need to change what BGP is peering on (like merging AS, ets.). It gives a lot of flexibility. That’s why I would standardize on it – give the same BGP instance name to all the routers on my network (or maybe give them names indicative of location or department, whatever) and use local-as everywhere to indicate what ASN I want to peer to. Then, for instance, if I want to change ASN on some router that has 10 VRFs peering to multiple other networks, some of which I don’t even have an access to all I need to do is modify my local-as for specific neighbor, not affecting the rest of the configuration and not worrying about those remote networks – they won’t be aware of anything different.

In such cases I won’t hardly ever need allow-as and override-as. In number of cases these two will provide the same result but still they are less flexible and particularly ‘allow-as’ looks pretty dangerous. Its just easier to modify submitted ASN without changing BGP instance than to allow something that can cause loops potentially. In addition, in latest XE (and/or ASR?) at least, CISCO introduced another great feature – ‘set-as’ that allows using routing policy to replace ASNs in the AS path with whatever you want, both IN and OUT. Combining local-as and set-as really provides anything one ever need to fully control the whole BGP ASN path.

I had particular need just recently related to ASN manipulation and that’s the outcome of some headache I went through .

Thanks

20

Hello Vadim

Thanks for the clarification. Indeed, you can use the neighbor local-as to achieve the same thing as this command is able to customize the AS_PATH attribute for routes received from eBGP neighbors, allowing you to change the attribute as you see fit.

This is definitely achievable, but has the following downside: It allows you to freely change the AS_PATH attribute without any restrictions. That means that it is more prone to errors than AS-override or Local-AS. If for example, the AS numbers change, you would have to change this specific command, whereas the other two options would not need any modification.

But how often do AS numbers change? Not too often, so you can weigh your pros and cons for your particular situation. For more info on the neighbor local-as command, take a look at this Cisco command reference.

As always, thanks for your detailed post, as it is helpful to enrich the content of the form!

I hope this has been helpful!

Laz

21

Hi Rene,

I cannot see the loop back of each CE from the individual PEs.
Dont we need to redistribute routes from mpls table into bgp table?

      1.0.0.0/32 is subnetted, 1 subnets
B        1.1.1.1 [20/0] via 192.168.12.1, 05:35:06
      192.168.12.0/24 is variably subnetted, 2 subnets, 2 masks
C        192.168.12.0/24 is directly connected, GigabitEthernet0/1
L        192.168.12.2/32 is directly connected, GigabitEthernet0/1

no 5.5.5.5 showing