two GRE tunnels using same interface problem

Mohamed ElHoussini · ‎10-23-2013

dears

i need your help to create 2 gre tunnels using same source interface (serial ) !

the problem is the 2 tunnels aren't up when config them only one is up and the other is down

jamie.grive · ‎10-24-2013

Hi,

Your GRE tunnels need to have something unique about them - I assume they must both also have the same destination address as well as source address?

The easiest thing you could do would be to use some loopback interfaces.

Is there anything else special about the GRE tunnel like IPSEC?

Mohamed ElHoussini · ‎10-24-2013

Hi ,

thanks for your reply

i've different destinations (loopbacks)

P.s there is authentication applied

the main issue now is that the down tunnel is stuck in IPSEC state !

jamie.grive · ‎10-25-2013

Mohamed,

I had a feeling this might be going on - hense why I asked about the IPSEC.

You need to share the tunnel profile using the "tunnel protection IPsec profile shared" command

Note these restrictions

The tunnel source command on all tunnel interfaces using the same tunnel source must be configured using the interface type and number, not the IP address.
All tunnels with the same tunnel source interface must use the same IPsec profile and the shared keyword with the tunnel protection command. The only exception is when only point-to-point generic route encapsulation (GRE) tunnel interfaces are configured with the same tunnel source in the system and associated with unique tunnel destination IP addresses. Shared tunnel protection can be used when the same local address between point-to-multipoint and point-to-point GRE interfaces are shared only if the device is an initiator of the point-to-point tunnels and not a responder.
Different IPsec profile names must be used for shared and unshared tunnels. For example, if "tunnel 1" is configured with thetunnel source loopback0 command, and "tunnel 2" and "tunnel 3" are shared using the tunnel source loopback1 command, then define IPsec_profile_1 for tunnel 1 and IPsec_profile_2 for tunnels 2 and 3.
A different IPsec profile must be used for each set of shared tunnels. For example, if tunnels 1 through 5 use tunnel source loopback1 command as their tunnel source and tunnels 6 through 10 use loopback1, then define IPsec_profile_1 for tunnels 1 through 5 and ipsec_profile_2 for tunnels 6 through 10.
Sometimes, it may be desirable to not share an IPsec session between two or more tunnel interfaces using the same tunnel source. For example, in a service provider environment, each DMVPN cloud can represent a different customer. It is desirable to lock the connections from a customer to a tunnel interface and not share or allow IPsec sessions from other customers. For such scenarios, Internet Security Association and Key Management Protocol (ISAKMP) profiles can be used to identify and bind customer connections to an ISAKMP profile and through that to an IPsec profile. This ISAKMP profile limits the IPsec profile to accept only those connections that matched the corresponding ISAKMP profile. Separate ISAKMP and IPsec profiles can be obtained for each DMVPN cloud (tunnel interface) without sharing the same IPsec SADB.
Sharing IPsec is not desired and not supported for a virtual tunnel interface (VTI) as VTI provides a routable interface type for terminating IPsec tunnels and a way to define protection between sites to form an overlay network.
Shared tunnel protection can be used when the same local address between multiple multipoint generic route encapsulation (mGRE) interfaces are shared.
Shared tunnel protection can be used when the same local and remote addresses between multiple point-to-point GRE interfaces are shared.

Vasilii Mikhailovskii · ‎10-25-2013

Hello.

Could you please draw a diagram or provide a configuration from both ends, including routes per tunnel ddestination.

Routing could be an issue!

PS: if routing is not an issue, you may try to add unique tunnel key value per tunnel (be aware this will decrease MTU by 4 bytes).