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.
[toc:faq]The ProblemOn traditional switches whenever we have a trunk
interface we use the VLAN tag to demultiplex the VLANs. The switch needs
to determine which MAC Address table to look in for a forwarding
decision. To do this we require the switch to do...
[toc:faq]Introduction:Netdr is a tool available on a RSP720, Sup720 or
Sup32 that allows one to capture packets on the RP or SP inband. The
netdr command can be used to capture both Tx and Rx packets in the
software switching path. This is not a substitut...
IntroductionOSPF, being a link-state protocol, allows for every router
in the network to know of every link and OSPF speaker in the entire
network. From this picture each router independently runs the Shortest
Path First (SPF) algorithm to determine the b...