why traceroute data shows three first-hop addresses?

[jmaxwellUSAF]

Hello.
---

(obfuscated)

2951#ping 172.16.8.7
Sending 5, 100-byte ICMP Echos to 172.16.8.7, timeout is 2 seconds:!!!!!Success rate is 100 percent (5/5), round-trip min/avg/max = 1/2/4 ms

2951#traceroute 172.16.8.7
Tracing the route to 172.16.8.7
VRF info: (vrf in name/id, vrf out name/id)
1 172.16.20.20 0 msec
172.16.20.30 4 msec
172.16.20.20 0 msec
2 * * *
3 * * *
4 * * *
---

In above traceroute, first-hop device is a nexus 9k switch pair, sharing a HSRP VIP address, but running their standalone running configs.
172.16.20.20 and 172.16.20.30 are each's VLAN address.
The VIP is 172.16.20.10 (nowhere to be seen on the traceroute.)

QUESTIONS:

1. May you please explain why above traceroute data shows three first-hop addresses, and the first and third are the same?

2. Is it evidence of a misconfiguration that the traceroute shows not the VIP, but instead the individual VLAN IPs?

Thank you.

[MHM Cisco World]

That meaning your vpc is correct.

First traceroute send three packet with same ttl.

Traceroute to hsrp the hsrp reply with it real ip no it VIP of hsrp

The portchannel between sw and vpc load balance the traffic' first hit the vpc nsk-1 and second hit vpc nsk-2 and third hit vpc nsk-1

Why both reply? It the main CORE of uing vpc both NSK can forward traffic i.e. hsrp is active/active.

[jmaxwellUSAF]

Relevant-- I had not seen before this type of traceroute output.

Because of dubious previously assigned bandwidth values, I very recently changed all my EIGRP routing devices to bandwidth=1,000,000 kbps.

Your thoughts?

Also, why do * follow after traceroute hits the 9ks ?

[MHM Cisco World]

this traceroute is normal for HSRP 
can you show your topology to see what you meaning about EIGRP?

[jmaxwellUSAF]

why do "*"s follow after traceroute hits the 9ks ?

Topology...

router --- nexus 9k pair --- server

Now router pings server.

[Richard Burts]

Understanding the * in the output may need some explanation of how traceroute works. traceroute sends probe packets toward the destination (Cisco sends udp packets to some high udp port which is likely to not be used, in groups of 3) and varies the ttl of the packet, begging with ttl of 1, then 2 etc. Most devices when they receive an IP packet and the ttl expires sends an error message and the source address of the error message is used in the traceroute output. But some devices do not send the error message. For this the traceroute output uses *.   So the first group (ttl = 1) gets to 9k and it sends error response that ttl expired. The next group of probe packets with ttl of 2 is sent but the next device on the path does not send the ttl error message. So the output shows * * * (for the 3 expired packets).

[MHM Cisco World]

the traffic flow via Peer-link 
when traffic pass via Peer-Link the TTL will reduce by one 
so the traffic is drop. 
can you add layer3 peer-router 
and check

[jmaxwellUSAF]

"when traffic pass via Peer-Link the TTL will reduce by one 
so the traffic is drop."

I don't understand Why is the traffic is dropped. May you explain?

[MHM Cisco World · Accepted solution]

Traceroute depend one ttl become zero' this case make device reply with ttl exceed to source and inform him that it need to increase ttl.

This procedure is broke if traffic pass via peer-link becuase nexus dont send ttl message to source' and source still use same ttl value and nexus still drop it.