Insights doing ICMP via the internet rather than the SD-WAN - Host is advertised over SD-WAN

[BazMonkey]

I have WebexDi deployed in the cloud with a 178.x.x.x address.

When I setup insights to do VOIP health to the server I see 100% loss.

I did a packet capture on the SD-WAN and saw nothing. I jumped on the Internet WAN1 link and saw ICMP coming from the MX trying to ICMP the 178 address. This must have been insights doing it's thing.

I checked my routing table on the local MX and it was clear that my route to 178.x.x.x was the SD-WAN. I could ping the server over the SD-WAN from all local subnets including default.

I logged a ticket with TAC and they said that was expected. Hmmmm. Not so sure that was the answer I expected.

So why would insights use ICMP over the local internet breakout rather than SD-WAN?????

Cheers in advance.

[alemabrahao]

The documentation say's.

Note: We probe with ICMP pings to the server from the MX interfaces.

[Ryan_Miles]

Where are you pinging from? Looking at your config I see the 178.x.x.x advertised from two hubs. Choosing a random spoke site I see the MX has two VLANs, neither enabled for VPN. The static route down to your L3 switch has VPN enabled. 

So, from L3 interfaces on the downstream switch I can ping 178.x.x.x IPs which makes sense. The MX however cannot ping 178.x.x.x as it's sourcing from its interfaces none of which are enabled for VPN. And Insight would be using a MX interface to source pings from.

You may also want to ask Support if the MX should be able to ping a public IP via AutoVPN or if it's not following the route table and instead seeing a public IP and just skipping to sending it out the WAN interface.

[RaphaelL · Accepted solution]

Note: We probe with ICMP pings to the server from the MX interfaces.

https://documentation.meraki.com/MI/MI_VoIP_Health

It is not clear , but I don't see how the MX could souce the trafic from it's LAN interfaces since you can input a FQDN as shown in the documentation. The MX can't do name resolution from it's lan interfaces , however yes it can source trafic ( it takes the highest vlan id , since the MX doesn't have a mgmt interface )

• VoIP On-Prem (Servers with private IP addresses) will not show the hops between the MX's in the Traceroute diagram on the detailed page

I hope that it is not only relying on the IP adresses ( if RFC1918 then -> source in the VPN , else source from the WAN ) instead of relying on the route table ( which would make way more sense ) 

That being said , pretty sure it's always from the WAN interfaces , just like Thousand Eyes.

[BazMonkey]

Ah OK. My mis-understanding that is uses WAN1 & WAN1 as the source. What confused me was that we used to have our VOIP servers hosted at a local DC and we had Insights providing reporting OK. The route to the server was via the SD-WAN so I could not understand the why it was any different to our new servers being available from the SD-WAN. 

[Ryan_Miles]

Looking at pcaps I see when it pings a RFC1918 IP the source is the highest VLAN IP with VPN enabled. When pinging a "public" IP the source is the WAN IP.