MPLS and Backup VPN Connection - Asymetric routing issues

[Chess Norris]

Hello,

A customer have some asymetric routing issues after a power outage on their local site. They are using MPLS as primary connection to their DC and a static L2L VPN connection as backup. There is a /18 network beeing anounced over MPLS from the DC. That /18 network is divided in multiple /24 subnets. For some reason after the power outage, they stoped getting specific /24 networks in BGP from the MPLS provider and instead the customer only saw the whole /18 network. This lead to that the backup L2L VPN started to establish IPSec tunnels and the traffic was goining out over the IPsec tunnel but came back on the MPLS interface, causing asymetric routing.

As a temporary solution, we disabled the VPN tunnel and the traffic started going over the MPLS interface again. This is not ideal ofcause, because we they cannot use the VPN as a backup no more. One thing that I noted, was they have the VPN tunnel configured to use reverse-route injection. I'm suspecting disabling this could be a workarround, but ot really sure if that would cause any other issues and the question still remains on why we dont see the more specific /24 networks in BGP.

Happy to know if anyone have any ideas on how to troubleshoot the issue.

Thanks

/Chess

[Harold Ritter · Accepted solution]

Hi @Chess Norris ,

You need to check why the more specific routes (/24s) are not advertised to the MPLS service provider anymore. One reason I can think of is that the running configuration allowed the /24s to be advertised, but that configuration was not saved to the startup configuration, which caused the issue after the power outage.

The bottom line is that the current configuration needs to be reviewed to make sure that the /24s can be advertised to the MPLS SP.  

[balaji.bandi · Accepted solution]

Is this advertisement configured using a prefix list and a route map?

Would you happen to have a sample configuration and output that we can review?

[Chess Norris]

Thank you @Harold Ritter & @balaji.bandi 

I think I figured it out now. The customer recently changed their VPN tunnels from IKEv1 to IKEv2. Switching from IKEv1 to IKEv2 enabled reverse-route injection which they didnt used before. I guess that when enableing reverses-route injection it creates a more specific (longer prefix match) route for traffic through the VPN. Disable reverses-route injection fixed it.

/Chess