cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
Announcements
Join Customer Connection to register!
1169
Views
20
Helpful
6
Replies
shamax_1983
Participant

Best options to allow Inter-VRF communication with in an Enterprise MPLS environment

I have a specific situation where an Enterprise MPLS core with multiple VRFs needing Inter-VRF communication via a Firewall (using BGP peering with the ASA).

Inter-VRF communication is to be done via an ASA-Firewall with eBGP peering into each VRF (configured on the MPLS PE router(s)).

Each VRF within the MPLS core is configured under the same main BGP AS number (AS 65550).

 

So to get this working, I have found three options:

 

Option1)

I'm going to have to configure eBGP peering into each VRF and for each BGP peer, I will have to configure the same remote AS number ( remote-as 65550).

In addition to this, within each VRF side (ie. within the PE router), we will need to have the "allowas-in" configured so each VRF will accept the prefixes of the other VRFs (learned from the ASA). As these prefixes otherwise will be rejected due to BGP default loop prevention.

--------

 

Option2)

On the PE end, I will configure "local-as 65XXX no-prepend replace-as" command so each VRF will pretend to be a different VRF towards the eBGP peering (to ASA). And on the ASA side, I will configure BGP peering to each VRF using their own unique AS (65XX1, 65XX2 etc).

-------

 

Option3)

Another option I found was configuring as-override on the ASA-Firewall on each BGP session. I am not going with this option as this is already ruled out.

-------

 

I have tried both settings and Option2) seems to make the most sense to me from the troubleshooting and Administration point of view as each prefix learned and exchanged via the ASA will have a unique AS attached to it so we can find out exactly where the Prefix is originated from.

 

Looking possible routing loops; In both cases, we are either disabling the default BGP loop prevention mechanism completely(as with option1) or, try to fool it by manipulating the AS numbers(as with option2), So both options seem to be prone to routing information loops.

For example, I have found that with Option1), if you have multiple BGP connections from the ASA to the same VRF (on two different PEs) and, if you want to prefer one connection over the other using Local-Pref, this will cause a definite loop (as it will start learning and preferring eBGP routes coming via ASA for prefixes originated within its own VRF). And to stop the loops, you will either have to implement Route filtering based on Prefixes and/or communities.  This behaviour is not visible with Option2) as the loop-prevention is still in place. So no need to have any special filters in place for the same scenario. So this is another observation that led me to lean towards the options 2)

-------------

 

I have done a lot of research around this but nothing compares pros and cons of these two options within an Enterprise MPLS core point of view. Most of the document talks about "local-as" as an AS migration technique within the ISP sector. 

So I just wanted to check with the community what is your take on this?

Am I missing something? Have you done something similar? if so what is your experience with this?

 

Thanks in advance for your replies.

1 ACCEPTED SOLUTION

Accepted Solutions
Francesco Molino
VIP Mentor

Hi

 

I agree with you, option 2 is the most suitable solution in your case.

Local-as with no-prepend and replace-as is most used in migration but also on merging networks.

We see it most of the time as isp level but not only. In some specific cases like yours, we use this capability within Enterprise networks.

 

I already did a similar config which is still working, i mean playing with AS. 

 

The cons of the other option you're looking at is more management tasks. I mean this more looks like a workaround than a real case. You would also need to filter correctly your routes to not have any routing issue. With this option 1, you would need to activate allowas-in.

 

 


Thanks
Francesco
PS: Please don't forget to rate and select as validated answer if this answered your question

View solution in original post

6 REPLIES 6
Francesco Molino
VIP Mentor

Hi

 

I agree with you, option 2 is the most suitable solution in your case.

Local-as with no-prepend and replace-as is most used in migration but also on merging networks.

We see it most of the time as isp level but not only. In some specific cases like yours, we use this capability within Enterprise networks.

 

I already did a similar config which is still working, i mean playing with AS. 

 

The cons of the other option you're looking at is more management tasks. I mean this more looks like a workaround than a real case. You would also need to filter correctly your routes to not have any routing issue. With this option 1, you would need to activate allowas-in.

 

 


Thanks
Francesco
PS: Please don't forget to rate and select as validated answer if this answered your question

View solution in original post

Francesco Molino
VIP Mentor

Hi

 

I've answered your post based on your options.

But I was thinking about another option. Can you share a quick design and config (only BGP) of your PEs and ASAs?

 

I would like to see how today interconnection/peering is made. Does your peering is based on MP-iBGP?


Thanks
Francesco
PS: Please don't forget to rate and select as validated answer if this answered your question

Thanks for your reply Francesco. Much appreciated.
Currently, the ASA and the PEs are routing only statically.

Thanks

Ok. You want to move from static to mp-bgp.
Instead of using your option2 which is correct by the way.
Based on what you told in this post, your ASA would act as RR and as far as I remember (checked also in the latest version) ASA couldn’t be RR.

Thanks
Francesco
PS: Please don't forget to rate and select as validated answer if this answered your question

Hi Francesco,
Thanks for your input again. I think I need to clarify the connectivity a little bit (I can see how you came to that conclusion)
In this case, the ASA will be configured with completely different AS number(which is already in place). So the connections going from the ASA to each VRF will be eBGP sessions, in which case I don't think the ASA should act as a RR. But thanks for the heads up.

ok if ASA has already a different AS, no need of iBGP and RR then.


Thanks
Francesco
PS: Please don't forget to rate and select as validated answer if this answered your question