BGP, Two DS3 Connections with Crypto-map applied

[jonesl1]

Ok, I have a little dilemma and am hoping to get some help from you super smart people out there.

Here is my issue:

I have a single ASR 1002 router that has 2 AVPN/MPLS DS3 connections coming in from our local telco.  We just

recently had the second one installed so that we can use it for load sharing or backup.  Both DS3's fall into the same AS#

So our main DS3 (DS3-A) currently has a crypto map applied to it so that we can terminate secure tunnels from our remotes

across the telco provider. 

I tried adding the max-paths 2 and adding the second neighbor under the bgp instance on the ASR.   This created the load

sharing scenario, but it broke my vpn tunnels.   At that point, I tried creating duplicate tunnels on the remote endpoint routers to peer

to the new DS3 address on the ASR router.  The tunnels came up, but I believe i believer there were still some traffic issues with

having two tunnels up to the same peer because the remote sites called indicating they weren't working. 

So I guess my first question is......am I setting this up correctly by adding the neighbor and setting max paths to 2?  I do see the

load sharing taking place which is good, but unfortunately, I think it's causing havoc with my Lan2Lan VPN tunnels.   And unfortunately

i'm not sure how to resolve that problem. 

Again, your assistance and time is appreciated.  It's so nice to have a group of super smart tech's like yourselves to assist.

Thanks again                

[paul.cainkar]

Terminate the crypto tunnels on a seperate loopback interface (/32) will solve your issues.  Announce that /32 into BGP.

Or if it's an all-cisco IOS network, consider GETVPN instead.

Or even better, ditch the two DS3s and get a 100-meg metro-e, if available in your location.

Additionally, for the load balancing, you need to make sure the provider does the same maximum-paths.  It's a relatively new command in the last ~5 years or so.  Prior to that, the normal method to load balance BGP was this:

http://www.cisco.com/en/US/tech/tk365/technologies_tech_note09186a00800c95bb.shtml#ebgpmulithoploadbal

Per flow or per prefix load balancing method is advised this day in age.  Avoid per packet.  per-flow is probably best for the typical enterprise use case.

[Richard Burts]

The original poster has not provided much detail about the router and about how the VPN is set up. But I am going to guess at what is the problem. I would guess that the VPN packets probably all arrive on the old interface (because I am assuming that the remote peer probably was configured to use the address of the old interface as the peer address). But when the router is sending packets to the remote peer then load sharing is taking place and some of the packets are sent out the new interface. But without a crypto map on the interface they are not encrypted. And when the non-encrypted packet is received at the remote peer then it is rejected.

The suggestion of using a loopback interface as the peering address might solve the problem (assuming that you then put a crypto map on both interfaces).

It also seems to me that you might be able to configure Local Policy Based Routing and to have that send the VPN packets out the old interface.

HTH

Rick

[paul.cainkar]

Yes, most certainly that is the issue.

Policy-routing would work. 

Keep in mind:

1) Doing so precludes from benefiting from the effects of bgp multipath for the encrypted traffic, which is what broke this to begin with.  (maybe he only wants multipath for unencrypted?)

2) It also prevents from using the second link for redundancy unless you handle this at the ipsec peering level (but, IMHO,

BGP will converge faster than IPSEC DPD w/ 2 peers).

My personal opinion is this is an excellent use-case for GETVPN.

None the less, the good news is that policy route is very easy to implement.

The OP should update this with more detail for the best case scenario.