11-14-2023 09:05 AM - last edited on 11-14-2023 03:52 PM by Translator
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.
Solved! Go to Solution.
11-14-2023 10:48 AM
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.
11-14-2023 09:19 AM
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.
11-14-2023 09:30 AM - edited 11-14-2023 09:33 AM
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 ?
11-14-2023 09:35 AM
this traceroute is normal for HSRP
can you show your topology to see what you meaning about EIGRP?
11-14-2023 09:49 AM
why do "*"s follow after traceroute hits the 9ks ?
Topology...
router --- nexus 9k pair --- server
Now router pings server.
11-14-2023 10:08 AM
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).
11-14-2023 10:11 AM
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
11-14-2023 10:27 AM
"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?
11-14-2023 10:48 AM
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.
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide