Monitoring an IPSec tunnel in LM?

I have not checked the API for NSX-T to know what is available, but yes, those are great metrics to track.

There is value to recording the “status” of both phase 1 and phase 2 separately. Sometimes, phase 1 will remain up while phase 2 goes down. This can indicate a lack of activity within the scope of that phase 2 rather than a broken link between the sites.

When I built this for NSX-V (unpublished DataSource named “Jenzabar_VMware_NSX_EdgeIPSEC”), the excerpt below created the instances for phase 1 and phase 2. Note the different naming convention as well as the populated properties.

edges.each { edge ->
    def confURL = "https://${hostname}/api/4.0/edges/${edge.id}/ipsec/config"

    def confResponse = getURL(confURL, slurper, auth, debug)
    def statusCode2 = confResponse[1]

    if (statusCode2 == 200) {
        def confOutput = confResponse[0].sites.sites
        confOutput.each { conf ->
            LMDebugPrint("conf: \n" + JsonOutput.prettyPrint(JsonOutput.toJson(conf)), debug)

            // Phase 1
            println "${edge.id}_${conf.siteId}##${conf.name} (Phase 1)######"+
                "auto.nsx.edge=${edge.name} [${edge.id}]"+
                "&auto.nsx.edgeId=${edge.id}"+
                "&auto.nsx.ipsec.localIp=${conf.localIp}"+
                "&auto.nsx.ipsec.siteId=${conf.siteId}"+
                "&auto.nsx.ipsec.peerIp=${conf.peerIp}"

            // Phase 2
            conf.localSubnets.subnets.each { local ->
                conf.peerSubnets.subnets.each { peer ->
                tunnelKey = "${conf.localIp}_${local}-${conf.peerIp}_${peer}"
                println "${tunnelKey}##${conf.name} (${tunnelKey})######"+
                    "auto.nsx.edge=${edge.name} [${edge.id}]"+
                    "&auto.nsx.edgeId=${edge.id}"+
                    "&auto.nsx.ipsec.localIp=${conf.localIp}"+
                    "&auto.nsx.ipsec.siteId=${conf.siteId}"+
                    "&auto.nsx.ipsec.peerIp=${conf.peerIp}"
                }
            }

        }
    }
}

The API for NSX-V also included a failureMessage. I created an enumeration metric (is this a proper term?) for which I started to translate common failureMessage values into numeric values (see excerpt below).

failureMessage = 0
if (tunnel.containsKey("failureMessage") && tunnel.failureMessage.length()) {
	switch (tunnel.failureMessage.toLowerCase()) {
		case "received delete for ipsec-sa":
			failureMessage = 3
			break
		case "unknown":
			failureMessage = 2
			break
		default:
			failureMessage = 1
	}
}
println "${tunnelKey}.failureMessage="+failureMessage