cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
3662
Views
5
Helpful
5
Replies

Switches connected by Different Vlans can ping and telnet but no traceroute

mahesh18
Level 6
Level 6

                   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

3 Accepted Solutions

Accepted Solutions

milan.kulik
Level 10
Level 10

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

View solution in original post

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

HTH

Rick

View solution in original post

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

HTH

Rick

View solution in original post

5 Replies 5

Mitchell Dyer
Level 1
Level 1

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

milan.kulik
Level 10
Level 10

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

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

HTH

Rick

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

HTH

Rick

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

Review Cisco Networking for a $25 gift card