Thanks for your response. What you said makes perfect sense. Can you pls throw some light on how exactly should I investigate on SA lifetimes. I am sure my IPSec configuration parameters are fine and that is why the tunnels come up....so that is why I am asking how exactly should I investgate on SA lifetimes.
I have also observed that when the show dmvpn shows one of the tunnel in NHRP state and if I use the command "sh crypto session detail"....the 3845 thinks the tunnel is UP and shows the output in "sh crypto session detail" but the 6509 (HUB ) thinks the tunnel is not there and there is no ouput in "sh crypto session detail"..
The following output shows that Tunnel 0 is UP in 3845 but down in 6509
3845 output sh crypto session detail ::::::::::::::::
Session status: UP-ACTIVE
Peer: 220.127.116.11 port 4500 fvrf: (none) ivrf: (none)
IKE SA: local 172.20.7.3/4500 remote 18.104.22.168/4500 Active
When I have had problems with DMVPN it has always been a reachability problem to the remote peer generally because I have to go through an Internet service provider NAT to a private IP or a firewall in between hub and spoke that you dont know about.
If there is a scenerio where there is a private IP, the remote router must initiate the ISAKMP session and then IPSEC session is initiated and data starts flowing. After IPSEC session is established, it is my understanding that the ISAKMP session is no longer needed unless the IPSEC tunnel rekeys. The first side to expire the re-key interval tries to send the re-key down the isakmp tunnel which doesnt exist and drops its side of the IPSEC session, but the opposite side has no idea the other side dropped IPSEC.
Since the ISAKMP session is UDP and very little traffic is sent after IPSEC is establish, firewalls will drop the ISAKMP session, but both ends dont know this.
If you look at:
show crypto ipsec sa
You will see the re-key interval. I feel like this re-key interval may need to be less than what a comman firewall will drop an inactive ISAKMP UDP session, which will force traffic on the ISAKMP session and reset the firewall timer.
I believe also there is an ISAKMP keepalive which can be turned on both ends, which I will research to see if I can provide any further information.
Here is the keepalive information I was looking for. Read carefully that DPD only works if the router needs to send traffic. If it is idle it will not send a DPD. Therefore, to keep the session up, the keepalive will need to be forced at peroidic intervals.
How DPD and Cisco IOS Keepalive Features Work
DPD and Cisco IOS keepalives function on the basis of the timer. If the timer is set for 10 seconds, the router will send a "hello" message every 10 seconds (unless, of course, the router receives a "hello" message from the peer). The benefit of IOS keepalives and periodic DPD is earlier detection of dead peers. However, IOS keepalives and periodic DPD rely on periodic messages that have to be sent with considerable frequency. The result of sending frequent messages is that the communicating peers must encrypt and decrypt more packets.
DPD also has an on-demand approach. The contrasting on-demand approach is the default. With on-demand DPD, messages are sent on the basis of traffic patterns. For example, if a router has to send outbound traffic and the liveliness of the peer is questionable, the router sends a DPD message to query the status of the peer. If a router has no traffic to send, it never sends a DPD message. If a peer is dead, and the router never has any traffic to send to the peer, the router will not find out until the IKE or IPSec security association (SA) has to be rekeyed (the liveliness of the peer is unimportant if the router is not trying to communicate with the peer). On the other hand, if the router has traffic to send to the peer, and the peer does not respond, the router will initiate a DPD message to determine the state of the peer.
Using the IPSec Dead Peer Detection Periodic Message Option
With the IPSec Dead Peer Detection Periodic Message Option feature, you can configure your router so that DPD messages are "forced" at regular intervals. This forced approach results in earlier detection of dead peers. For example, if a router has no traffic to send, a DPD message is still sent at regular intervals, and if a peer is dead, the router does not have to wait until the IKE SA times out to find out.
If you want to configure the DPD periodic message option, you should use the crypto isakmp keepalive command with the periodic keyword. If you do not configure the periodic keyword, the router defaults to the on-demand approach.
I am using DPD periodic of 15 seconds. You have mentioned that the re-key interval should be observed to make sure the firewall is not timing out the UDP sessons...With DPD periodic of 15 seconds do you think it still needs to be observed?
The observations is that the spoke ( 3845 ) thinks that the tunnel is UP while 6509 thinks it is DOWN...So basically when i use Sh crypto ipsec sa there is some output in the 3845 but the relavent output towards the spoke 3845 is not there in 6509.
[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...