01-29-2013 09:33 AM - edited 03-07-2019 11:23 AM
Hi everyone,
I was trying sceanrio below to learn about switching.
Switch A has SVI vlan 10 -- 192.168.10.1
SwitchA# sh run int fastEthernet 1/0/15
Building configuration...
Current configuration : 111 bytes
!
interface FastEthernet1/0/15
switchport access vlan 10
switchport mode access
Interface fas1/0/15 connects to nei Switch B
Switch B
Has
SwitchB#sh run int vlan 11
Building configuration...
Current configuration : 63 bytes
!
interface Vlan11
ip address 192.168.10.2 255.255.255.0
SwitchB#sh run int fastEthernet 2/0/15
interface FastEthernet2/0/15
switchport access vlan 11
switchport mode access
From Switch A i can ping Switch B vlan 192.168.10.2
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.10.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/2/8 ms
SwitchA#traceroute 192.168.10.2
Type escape sequence to abort.
Tracing the route to 192.168.10.2
1
*Mar 1 18:35:42.029: ICMP: dst (192.168.10.1) port unreachable rcv from 192.168
.10.2192.168.10.2 0 msec 0 msec
*Mar 1 18:35:51.047: ICMP: dst (192.168.10.1) port unreachable rcv from 192.168
.10.2 *
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.10.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/2/8 ms
Also Telnet from Switch A to B works fine.
But traceroute to Switch As IP 192.168.10.1 and Vlan 11 on Switch B does not work.
Type escape sequence to abort.
Tracing the route to 192.168.10.2
1
*Mar 1 18:35:42.029: ICMP: dst (192.168.10.1) port unreachable rcv from 192.168
.10.2192.168.10.2 0 msec 0 msec
*Mar 1 18:35:51.047: ICMP: dst (192.168.10.1) port unreachable rcv from 192.168
.10.2 *
SwitchA#traceroute 192.168.10.1
Type escape sequence to abort.
Tracing the route to 192.168.10.1
1
*Mar 1 18:36:41.848: ICMP: dst (192.168.10.1) port unreachable sent to 192.168.
10.1
*Mar 1 18:36:41.848: ICMP: dst (192.168.10.1) port unreachable rcv from 192.168
.10.1192.168.10.1 0 msec 0 msec
*Mar 1 18:36:50.866: ICMP: dst (192.168.10.1) port unreachable sent to 192.168.
10.1
*Mar 1 18:36:50.866: ICMP: dst (192.168.10.1) port unreachable rcv from 192.168
.10.1 *
Can anyone please explain we why traceroute does not work even though ping and telnet works?
Thanks
Mahesh
Solved! Go to Solution.
01-30-2013 02:12 AM
Hi,
IMHO, the ICMP Debug mesages are showing the Traceroute works OK in fact.
As Traceroute command issued on a Cisco switch is sending UDP packest on high (33434, e.g.) ports, you can see either ICMP reply dst port unreachable (your case) or ICMP time exceeded (other hops) replies.
Your output is a mixture of traceroute and debug messages at the moment.
I guess if you stop your debugging, you would see a standard Traceroute ouput like:
SwitchA#traceroute 192.168.10.2
Type escape sequence to abort.
Tracing the route to 192.168.10.2
1 192.168.10.2 0 msec * 0 msec
(* means no reply - there is a limit on many Cisco devices to reply with 2 ICMP packets per second only by default to avoid a CPU overload.)
HTH,
Milan
01-30-2013 05:46 AM
I absolutely agree with Milan (+5) that the traceroute is working correctly.
The confusion probably comes from the difference in implementation of traceroute between Windows and Cisco. Probably the Windows tracert is more familiar to most people. The Windows tracert sends ICMP packets, varying the TTL and expects to receive an ICMP response when it gets to the destination. The Cisco traceroute (like the Unix traceroute) sends UDP packets and expects to receive the port unreachable when it gets to the destination.
HTH
Rick
01-30-2013 05:55 AM
It occurs to me that there is another very interesting aspect to the scenario that Mahesh describes. It is VLAN 10 on switch A and VLAN 11 on switch B. On the surface that looks like a significant mismatch that might prevent connectivity. But Mahesh shows that clearly the switches communicate with each other very well.
The explanation is that both switches are connecting using access ports (not trunk ports). And an access port does not apply any VLAN information to frames as it forwards it. So there is a common broadcast domain (and a common subnet) between the switches which does allow IP communication.
HTH
Rick
01-29-2013 09:11 PM
My bet is the trace route is "failing" because there isn't actually a hop from switch A to B, they are in the same subnet, though different VLANs. Traffic destined between switches isn't being routed, it's being switched.
The other option may be that the switches are missing default gateways.
HTH
Mitch
Sent from Cisco Technical Support iPhone App
01-30-2013 02:12 AM
Hi,
IMHO, the ICMP Debug mesages are showing the Traceroute works OK in fact.
As Traceroute command issued on a Cisco switch is sending UDP packest on high (33434, e.g.) ports, you can see either ICMP reply dst port unreachable (your case) or ICMP time exceeded (other hops) replies.
Your output is a mixture of traceroute and debug messages at the moment.
I guess if you stop your debugging, you would see a standard Traceroute ouput like:
SwitchA#traceroute 192.168.10.2
Type escape sequence to abort.
Tracing the route to 192.168.10.2
1 192.168.10.2 0 msec * 0 msec
(* means no reply - there is a limit on many Cisco devices to reply with 2 ICMP packets per second only by default to avoid a CPU overload.)
HTH,
Milan
01-30-2013 05:46 AM
I absolutely agree with Milan (+5) that the traceroute is working correctly.
The confusion probably comes from the difference in implementation of traceroute between Windows and Cisco. Probably the Windows tracert is more familiar to most people. The Windows tracert sends ICMP packets, varying the TTL and expects to receive an ICMP response when it gets to the destination. The Cisco traceroute (like the Unix traceroute) sends UDP packets and expects to receive the port unreachable when it gets to the destination.
HTH
Rick
01-30-2013 05:55 AM
It occurs to me that there is another very interesting aspect to the scenario that Mahesh describes. It is VLAN 10 on switch A and VLAN 11 on switch B. On the surface that looks like a significant mismatch that might prevent connectivity. But Mahesh shows that clearly the switches communicate with each other very well.
The explanation is that both switches are connecting using access ports (not trunk ports). And an access port does not apply any VLAN information to frames as it forwards it. So there is a common broadcast domain (and a common subnet) between the switches which does allow IP communication.
HTH
Rick
01-30-2013 07:31 AM
Hi Milan and Rick,
You were correct traceroute as working fine yesterday also.
Today i removed all the debugging and here it is the result
With debugging ON
witchA#traceroute 192.168.10.2
Type escape sequence to abort.
Tracing the route to 192.168.10.2
1 192.168.10.2 9 msec
*Mar 2 16:28:58.612: ICMP: dst (192.168.10.1) port unreachable rcv from 192.168
.10.2 * 0 msec
SwitchA#
*Mar 2 16:29:01.616: ICMP: dst (192.168.10.1) port unreachable rcv from 192.168
.10.2
SwitchA#u all
All possible debugging has been turned off
SwitchA#traceroute 192.168.10.2
Type escape sequence to abort.
Tracing the route to 192.168.10.2
1 192.168.10.2 0 msec * 0 msec
Actually i was confused with port unreachable message and thought traceroute is not working.
So it was good that i asked question here and now my confusion is gone.
Also vlan mismtach is working as per Rick when traffic from port fa1/0/15 leaves it does not carry vlan info to Switch B.
Forum is great place to learn as we have many great people here to help us out.
Best Regards
Mahesh
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