@WMA Hell wrote:
I like the idea of EEM as I rarely use that and would love to play with it. Is there a tempate EEM script for something like this?
Unfortunately, I don't have one, but these forums have lots of engineers who appear to like working with EEM scripts. So, if you post a (new) question on that, good chance you'll get lots of help.
@WMA Hell wrote:
Also, I was not aware of IPsec Dead Peer Detection.
I wrote earlier, didn't recall whether I've used IPsec Dead Peer Detection, but reviewing how to enable it, I do recall having used it, although not the actual cases. (Probably was to down an interface which SNMP often alarms to, more so than losing a routing peer.)
@WMA Hell wrote:
. . . all NHRP hub and spoke devices, which total 5 devices, to configure IPsec dead Peer detection and Hello/dead timers.
Personally, for only 5 devices, I would likely make the changes manually. (Although it's worthwhile learning to use EEM.)
Again, if you have floating static routes, you shouldn't have any lost of connectivity, but if you want to avoid the work/hassle (if much?) using floating static routes, you often run into the problem while changing the remote side's config you lose remote access. There are a couple of ways to mitigate that.
Firstly, since you should only be breaking OSPF, if your remote access from hub router to spoke's tunnel IP, as both routers have (logically) a shared directly connected network, remote access should continue to work. (Likely, you're already aware of this.)
Secondly, if you're doing a config change, of multiple statements, that during application, will break the connection, I've found, you can place on the config changes into a file, copy it onto the remote device's flash, and then, on the remote device, copy that file to the running config. (Your remote session may break, while the file's configuration statements are being applied, but they will all be applied.)
For "disaster" recovery backup, in the past, I've used to schedule reload in 5 to 15 minutes, right before I start messing with the remote device. On newer IOSs, believe they have (optional?) configuration rollback options, but don't recall if those can also be scheduled.
@WMA Hell wrote:
Historically, I have always set the timers for NBMA 120/180, that way you may not drop due to a false positive because the cloud ate your hello packets and you won't inhibit notification of your connection as it will drop immediately becaue of the NHRP native connection "keepalives"..
Again, fully appreciate the desire to avoid false loss of connectivity to lost control packets. Your approach does preclude the problem being directly caused by routing hellos, but if counting on any kind of packet based keep alives, lost of those packets is still a problem.
Having used WAN provider frame-relay, ATM and MPLS clouds, one of the most effective ways (usually) is to insure you're in conformance with your provider's bandwidths, both logical, like a CIR, and physical interface cloud connections.
Simple (pure) hub-spoke example, hub has FE handoff, with 50 Mbps CIR, and spokes have Ethernet hand-offs, with 10 Mbps CIR.
At the hub, you should insure you don't exceed 50 Mbps on the interface, and don't exceed more than 10 Mbps to any one spoke.
Spokes, together should either not exceed 50 Mbps (if CIR also applies to cloud=>hub traffic) or 100 Mbps. Of course, in this example, 5 or less 10 Mbps hubs (logically) cannot overrun hub, but if more than 5 (or 10) such spokes? (The latter is its own can of worms, many things you might do, but I don't want to digress even further.)
If you've working within your WAN bandwidth limits, which your traffic might congest, you also want to insure those packets are not dropped by you (remember, ideally if within cloud's bandwidth capabilities, none of the WAN packets should be dropped), which might be implicitly done by the earlier mentioned pak_priority. Again, pak_priority insures such packets are egress queued, but doesn't guarantee their timely forwarding (although unless you're using very tight dead timers, unlikely they will be so delayed, they will be considered lost).
Again, what's really important, is not hitting a WAN cloud provider's bandwidth restriction where they just "randomly" discard your packets.
