We are using traceroute very often and sometimes take it for granted, until an very interesting question hit me and we have do dive a little deeper to get the answer. Here’s the full story:

Aviatrix CloudN is an appliance that helps to deliver line rate of encryption from on-premises towards the Aviatrix Transit Gateways, it is shipped with three interfaces:

• eth0 : WAN interface, this is where IPSec tunnels will be built towards Aviatrix Transit Gateways. Then BGP session will be established between CloudN to Aviatrix Transit Gateways.
• eth1: LAN interface, this is where BGP is established between CloudN with on-premise router
• eth2: MGMT interface, this is where you connect to CloudN for management, as well as where CloudN connects to internet for software updates.

It’s very common practice to have all three interfaces connected to the same router, have VRF configured on router to segment the three interfaces. As you may recall in my previous blog: Direct Connect to Aviatrix Transit – Option 3. The WAN/LAN/MGMT(not in the diagram) can connect to the same router as show below.

After we have CloudN inline with traffic, when customer tried to do a traceroute from on-premises towards cloud, they discovered that the CloudN hop was responded by the management interface IP, rather than LAN interface IP.

Customer is rightfully concerning that if the data traffic is actually going through MGMT interface instead of from LAN interface.