Hello Gowthamraj
Ah yes I see. These sequence numbers are not necessarily the same as those found in the ICMP header. These are normalized to zero at the beginning of the echo request sequence, but the actual sequence numbers may begin at a random number, and simply be incremented for each one sent. In each case, both those displayed, and those in the headers are incremented for each echo sent.
Thanks for sharing that!
Laz
in case of in accurate sequence numbers means what is that meaning?
in wireshark identifier (BE,LE ) and sequence number (BE,LE) what is that meaning?
Hello Gowthamraj
Like I mentioned before, the reasons for bad sequence numbers are typically the same as the reasons for any bit errors in transmissions such as a bad network connection, or an error in the OS both of which can create corrupted packets. It really depends on what you see as an error. If the sequence numbers you see are not in the right order, or missing, that may be due to delays in the transmission, or dropped packets.
(Remember that the sequence numbers you see in the output donât necessarily correspond directly to those found within the packet. It depends on how the OS is designed to operate the ping command.)
Within the wireshark output, you see both the identifier and the sequence number, which are calculated in the way I mentioned before. The BE,LE display however is not actually part of the header, but part of the way in which wireshark displays the information found within the header.
According to this wireshark form response, BE stands for big endian, and LE stands for little endian. These terms refer to the âendiannessâ of the contents found within the field. Endianness refers to the order of the bits within the field. A big-endian ordering places the most significant byte first and the least significant byte last, while a little-endian ordering does the opposite.
By displaying both formats, wireshark makes it easier to follow the sequence numbers that are incrementing from one echo request to the next. It simply shows both formats for the benefit of the user.
You can find out more about endianness at the following link:
I hope this has been helpful!
Laz
thank you lagapides. BE and LE is not much important right. it will go in depth
Hello Gowthamraj
For the purposes of certification, BE and LE are not important, and the topic does go very in-depth, however, it is nice to know details of how things work.
Laz
So in this case, âR3 uses this code because nothing is listening on UDP port 33435. R3 replies to R1 and sets this code,â the root case was UDP port 33435 on the router was shutdown by admin ?
Hello Cheng
Yes, you are correct. The administrator has disabled the switch from responding to traceroute and so the router returns Type 3 Code 3, stating that the UDP port is unreachable.
I hope this has been helpful!
Laz
Hi
Iâm confused TTL should be 255 on router 1 . on router 2 it should be 254 and on router 3 it should be 253 .
But this is confusing on router 1 itâs 1 then it decreases ?
Hello Abdul
Regular IP packets have a TTL field in their headers that is typically set to 255 (or some other number depending on the operating system of the particular device). The TTL is decremented every time it passes through a router. The purpose of the TTL is to ensure that if this packet gets caught in a routing loop, it will not be routed forever, but when TTL=0 it will be dropped.
Traceroute takes advantage of this TTL feature to be able to perform its function. Traceroute will send a series of packets to get a response from each router along the path.
To do this, traceroute will not start with a TTL of 255 but it starts by sending one packet with a TTL of 1. This will reach only the next router, and will not go further, because TTL reaches 0 at that point. BUT, that router will send a response saying âI got your packet, it reached a TTL of 0â.
Next it sends another packet with a TTL of 2. It goes to the first router, TTL is decremented by 1, and goes to the second router, where TTL reaches 0. BUT, that router will send a response saying âI got your packet, it reached a TTL of 0â
Next it sends another packet with a TTL of 3⌠and so on.
You can see a visual representation of this in the following post as well:
So each packet that traceroute sends is decremented by 1 by each router it goes through, but the next packet that is sent will increase the initial TTL by 1 so that it can reach the very next router in the sequence.
I hope this has been helpful!
Laz
Hey everyone, i am new in this forum. I hope you are doing well with the current situation.
I have devices (same devices to be precise ) connected to a switch and then it is connected to a core switches (2 cores switches act like one with the vss technologie) and also with HSRP. So the switch layer 2 has 2 cables, one of each goes to one core and with vps it becomes one port-channel to the cores. And in the Cores there are servers. One of them is to control the devices on the switch layer 2. I can ping most of them but there are 5 or 6 are not responding to the icmp. The message what i receive no response seen. Sometimes i have only one ping and then time out request. I tried to change the device to another port it is the same issue. I even changed the cable. But i can ping from the cores to the devices. If someone have an idea or the same issue. Thanks for your help.
Mina
Hello Mina
Whenever you have a topology like the one you describe, and the kind of problem you are experiencing, the following troubleshooting tips should be followed:
Since some devices are accessible and some are not, you must find the commonality between those that are and those that are not. Are all unaccessible devices connected to the same VLAN? Do those unaccessible devices have access to the default gateway? Can they ping each other? Are their subnets correct? Are the VLANs being shared correctly across the port channel? Is the VSS working correctly? Is the result the same even when you connect the server to either core? Are all the devices on the same VLAN as the servers? If not is inter-VLAN routing working correctly?
These are the primary questions you have to answer to see where the problem resides, and should give you a good beginning for the troubleshooting process.
I hope this has been helpful!
Laz
Hello, thanks for your answer. Yes when i move the server it is a VM the ping works for those devices but i loose others devices. The servers had 2 cables to each core. They are on the same vlan the devices, the servers are on another vlan and the routing is working with the HSRP gateway. The vlan are correctly configured on the port channel. They can ping each others even from the Nexus but from the servers a lot of them yes and others not about 7 devices. The funny thing on a switch layer 2 is when i shutdown one of the port-channel the ping works. I donât see really where is the problem. It is like the reply comes from another path.
I will do more tests and thanks for your patience.
Mina
Hello Mina
Thatâs interesting that ping works when one portchannel is shut down. You may find that the issue has to do with the VSS configuration on the switches. They may not be configured correctly, and traffic that goes down one physical link doesnât get passed from one switch to the other properly. When the physical link goes down, the traffic goes over the other link, and reaches the appropriate switch and host.
I hope that your troubleshooting is successful!
Laz
R3 is sending message back to the R1 with TTL value 1. can you please explain this. thanks
Hello Jeewan
When R1 sends the initial packet during traceroute, it sends it with a TTL of 1 so that it will only reach the next hop router and not go beyond it. R2 responds to R1, and R1 has now established what the first hop is, and records it.
Then R1 will send a second packet with a TTL of 2 so that it can reach the next hop router beyond R2. The packet reaches R3 (which is also the final destination of the packet) and R3 responds to R1. R1 now has the information about this next hop, which is also the destination.
When R3 responds to R1, it doesnât set the TTL value to 1. The TTL value is set to 1 only by R1 in its initial packet. The responses always have a normal TTL value.
I hope this has been helpful!
Laz
does TCPTRACEROUTE works the same ? can anyone explain how tcptraceroute works
Hello Kapil
TCPTraceroute works much the same way as traceroute does, only instead of using UDP, it uses TCP. The results of a TCPTraceroute are much the same as those of a regular traceroute, but because of the differences between TCP and UDP, the mechanisms differ slightly.
Specifically, TCPTraceroute will use what is called a TCP SYN scan, also called half-open scanning. It doesnât open a full TCP connection with each hop along the path that is being traced, but it sends a SYN packet, as if it is going to open a real session. A SYN/ACK response indicates that the port is listening or open. When it receives a response, it considers it a successful probe, and then sends a packet with an RST flag to close the connection.
The output of a TCPTraceroute is virtually identical to that of a regular traceroute, as both actually do the same thing. But TCPTraceroute is useful for situations where UDP traffic would otherwise be blocked, such as through a firewall.
I hope this has been helpful!
Laz
in which OS and in which case i can use the TCP traceroute ?
Hello Narad
TCP traceroute does not run natively on a Windows or MAC device. You must install the appropriate tools and utilities to run it from such devices. You can do a web search to find out how that can be done.
Linux devices natively include TCP traceroute by using the following command:
traceroute -T
The -T indicates that it should be a TCP trace. Cisco devices (as far as I know) donât support TCP traces.
I hope this has been helpful!
Laz