05-16-2018 11:24 PM - edited 03-05-2019 10:28 AM
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.
Solved! Go to Solution.
05-19-2018 10:34 PM
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.
05-19-2018 10:34 PM
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.
05-20-2018 01:58 PM
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?
05-20-2018 08:07 PM
05-20-2018 08:40 PM
05-20-2018 09:21 PM
05-20-2018 09:34 PM
ok if ASA has already a different AS, no need of iBGP and RR then.
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide