A customer wishes to use multiple MPLS VPNs within it's network. But since each VPN has the same BGP AS number routing updates are dropped due because the service provider PEs will not allow routes to be leant that have their own AS in the as-path. I would be very grateful for feedback from anyone who might have a solution. Please see attachment for a detailed description of the problem. Thanks, Peter.
I think a simple solution will be for the provider to use different ASes for the different vrfs.
You could also try to configure confederations on the bordering CEs. The idea is to replace the service provider AS (1234) with the local AS (65000) before advertisement to the neighboring AS. Without a full view of your topology though, I can not guarantee that this will work, but it is worth trying.
Thanks for the suggestions Olorunloba. However, I can't find any way to configure a different AS for each VRF. It would be a good solution if it were possible but as far as I can see there is no way to stop the service provider's confederated AS appearing in the path. I would welome any futher advice you have on that. Thanks. Peter.
What about as override? You'd lose some features of BGP for path choice (which you can look to other policy features if necessary) but you would avoid your routing loop phobia of allowas-in.
As a note, allowas-in is a per-neighbor implementation, not global to the process, so you can control the amount of looping you open yourself up to.
Hi Scott. Thanks for the AS-OVERRIDE suggestion. This looks to me to be a suitable solution. And I am glad that we would not have to use ALLOWAS-IN. I am going to ask my colleagues for their feedback. I'll get back to you. Regards, Peter.
I haven't looked at your details or topology, but you may also look at the "neighbor allowas-in" command set under BGP.
(It's in the MPLS command reference, not the BGP one!)
you can use allowas-in , this command is use for readvertisement of all prefixes containing duplicate autonomous system numbers
Is it not the CE side we're talking about?
For the PE side of things, you can use the as-override as well.
I'm thinking that we'd have to take a more detailed look at the total flow there and see what AS is going and where it's being rejected at.
If you are looking to re-inject an SP's routes back into the SP that seems to be a really strange idea. Otherwise, there are solutions out there.
I guess I didn't pay attention to who was trying to do the filtering. Sorry about that!
Dear all: Again thanks for your advice.
I note that Cisco advise that AS-OVERRIDE usually needs to be accompanied by SSO for loop prevention.
We don't have an SSO capability on the CE and so I think we would be reliant on "shortest as-path length" for our loop prevention.
The ALLOWAS-IN option also seems to need us to rely on as-path length for loop prevention.
Generally speaking, do you feel that as-path length can be relied on for loop prevention?
All of these things are workarounds to make sure you get what routes you want and where you want them. You need to pay attention to all of the routes and see what is or is not happening!
AS Path length MAY be adequate to handle loop prevention. But once you are doing allowas-in or as-override in order to "fix" the normal loop prevention concepts, then you MAY be going back and doing things like various AS-path prepending in order to tweak the as-path lengths that you end up with in the end.
Once you get the routes actually appearing (not killed prematurely) then you'll need to pay attention to what you have and verify the path direction is what you want and possibly to make other adjustments.
I am sucessfully using AS-OVERRIDE on the CE to allow the same MPLS-VPN BGP AS to appear multiple times in a customer network. And, of course, the AS-OVERRIDE config needs VRF-Lite to be configured on the CE. I'd like to thank the NetPro community for their contribution.