MPLS Layer 3 VPN BGP Allow-AS-In

Hi Rene,

Thank you for your clarification.

Nyi Nyi.



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

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!

Hi Lal & Andrew,

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

Rene

Excellent lab Rene! keep it up!

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?

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

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

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

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.

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

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

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

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

Hello Champion

This is actually expected behavior. The PE routers don’t need to be able to reach the loopback of the CE routers. They don’t need that information in their routing tables because you will never have direct communication between a PE router and the customer network. However, PE routers must be able to direct transient traffic (traffic that doesn’t originate from themselves) to the intended destination, and this is achieved using the BGP VPN table, which we can see with the command show ip bgp vpnv4 all like so:

PE1#show ip bgp vpnv4 all
BGP table version is 4, local router ID is 2.2.2.2
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal, 
              r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter, 
              x best-external, a additional-path, c RIB-compressed, 
              t secondary path, 
Origin codes: i - IGP, e - EGP, ? - incomplete
RPKI validation codes: V valid, I invalid, N Not found

     Network          Next Hop            Metric LocPrf Weight Path
Route Distinguisher: 1:1 (default for vrf CUSTOMER)
 *>   1.1.1.1/32       192.168.12.1             0             0 12 i
 *>i  5.5.5.5/32       4.4.4.4                  0    100      0 12 i
PE1#

Here, you can see that PE1 has a next hop assigned for both the 1.1.1.1 and the 5.5.5.5 networks, which route traffic to their intended destinations.

I hope this has been helpful!

Laz

So why do we need to redistribute when using other routing protocols (eg mpls l3 vpn ospf pe-ce and rip pe-ce), as opposed to when using ml3vpn BGP PE-CE?

Hello Champion

The need to redistribute routing information between protocols arises when using different routing protocols in different parts of a network, such as in MPLS L3 VPNs with OSPF or RIP as the PE-CE protocol. Redistribution helps achieve customer network connectivity on the CEs, as well as correct route exchange between the CE and PE devices.

When using OSPF or RIP as the PE-CE routing protocol, redistribution is necessary because these IGPs don’t inherently have the capabilities to carry VPN-specific information RDs and RTs. As a result, the PE routers need to redistribute the customer routes received from OSPF or RIP into BGP which is used in the MPLS core network. BGP is capable of carrying this VPN-specific information by using address families and is thus better suited for MPLS VPN environments.

On the other hand, when using BGP as the PE-CE routing protocol, there is no need for redistribution because BGP can directly carry VPN-specific information. Since the same protocol is used both between the PE and CE routers and within the service provider’s core network, there’s a seamless exchange of routing information.

I hope this has been helpful!

Laz

Very very helpful Laz.
Thanks so much for your helpful answers

1 Like

Hello, everyone!

So the problem described in this lesson is that the two customers are using the same BGP AS number which would cause them not to install eachother’s routes due to eBGP’s loop prevention system.

Now, it makes perfect sense if the ASes the customers are using are public because it would be a hassle to register a public AS for each of their locations that they want to interconnect using MPLS, so they’d just use the same one and that’s where Override and Allow AS IN could be implemented .

However, what prevents us (as the customer) from just using a private BGP AS number for each location?

That way we wouldn’t have to register any public ASNs and the Allow AS IN and Override options shouldn’t be necessary, right? We could just use a different private ASN for each of our locations.

Thank you.

David

Hello David

Just a clarification. The problem described is that two sites of the same customer are using the same BGP AS number, not two separate customers. This is probably what you meant, I’m just clarifying for the record.

You are correct that a “solution” to the problem is simply to use different ASes, and this can be easily done especially if you are using private ASes. However, there are reasons to keep the ASes the same, and for some organizations, it may be worth it, and if so, the Allow-AS-In feature is necessary. Under what circumstances would you want to keep the same AS? Well, here are a few:

  • Routing policies - some organizations may have applied routing policies based on AS numbers. Changing the AS number could mean reworking these polices which may be more time-consuming and expensive than using the Allow-AS-in feature.
  • BGP features dependent on AS number - there may be BGP features or design principles that are dependent on AS number such as BGP confederations and AS_PATH prepending and filtering.
  • Simplicity - some customers may just want to keep the same AS throughout their remote networks for operational simplicity. This way they don’t have to get involved in eBGP routing and related configurations, especially if they may have tens or hundreds of remote sites.
  • Network design - A customer may also be constrained in the choice of their ASN due to the nature of the rest of their network, network infrastructure that exists beyond the MPLS interconnections of their remote sites.

So although the use of different ASes at each remote site is a solution to the problem presented, there are reasons to maintain the same AS at remote sites (even with private ASNs) necessitating the use of Allow-AS-In.

I hope this has been helpful!

Laz