cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
478
Views
0
Helpful
6
Replies

Different behavior between Router and L3 Switches.

NetworkingGeek1
Level 1
Level 1

Hello Community,

I run into some different behavior between Router and L3 Switches. I was troubleshooting some connectivity issue in lab environment and accidentally noticed if you tracert some IP which is not assigned to anything, tracert results will be different depending on if target network is directly attached to Router or L3 Switch. Example:

I have L3 Cisco Core Switch which have L3 VLANS. There is some network, which is directly connected to it, let's say it's VLAN 20 and network 192.168.20.0/24. So, for L3 Switch it's directly connected network. I'm tracing some IP in 192.168.20.0/24, let's say 192.168.20.25 from remote location. This IP is not assigned to anything, it's not online. Core Switch is advertising this network with EIGRP to its neighbors - Cisco Routers. So, when I issue tracert 192.168.20.25 from remote Windows machine, tracert stops at Router which is just before Core Switch. On other hand, if I do the same test, but destination network is connected to Cisco Router, then tracert stops at this Router, which for me seems more logical.

Can someone please explain this behavior?

6 Replies 6

Richard Burts
Hall of Fame
Hall of Fame

While there are a few differences between a L3 switch and a router it has not been my experience that handling traceroute was one of them. Could you post the running config of the router and the L3 switch in the first case where the subnet was connected to the switch and the running config of the router when the subnet was connected to the router?

HTH

Rick

Hello @Richard Burts  I'll post more information and simple diagram.

L3 Core Switch model - C9500-40X. There 2 Switches in stack. Each switch is connected to two WAN Routers. So, there totally 4 up-links. But these two Routers are going to the different places, so, when I ping from remote Windows & Linux hosts, ping is going through only one Router, but it can use different down-links towards Core Switch stack, since those links are equal. I checked from both Windows & Linux and results are the same. If I tracert the Core Switch itself (for example - loopback), tracert is working just perfect. The same if I tracert the existent host which is behind the Core Switch. If I tracert existent IP, depending on the destination, ping can go through one down-link or the other, but it always the same Router. Recently, I did even more straightforward test, I just pinged and traceroute directly from those Routers and the results are absolutely the same! If I traceroute existing IP address (for example some alive host, behind the Core Switch), then I see IP address of the Core Switch as a first hop and everything is fine as expected. If I ping nonexistent IP which belongs to the same subnet as of existing IP address, I get time out output right from the beginning, so no L3 Switch hop is seen at all! And I checked Core Switch's ARP table for relevant VLAN and I see that Switch is creating incomplete entry for IP I was trying to traceroute, so Router is sending packets to the Switch.

Simple example, if I traceroute from any of those directly connected Routers, let's say existent host - 192.168.10.15/24. I get this:
1. 172.16.1.1 -> Interface of Core Switch
2. 192.168.10.15 -> destination host

In other hand, if I traceroute from any of those directly connected Routers, let's say nonexistent host - 192.168.10.22/24. I get this:
1. * * *
2. * * *
3. * * *
etc.

And Core Switch will create incomplete entry for 192.168.10.22, so Switch is receiving packets from the Router.

NetworkingGeek1_0-1674382017325.png

 

Hello
You don’t mention how your routing is setup ( how you are advertising networks between L3 and the rtrs)

As such it is a possibly the reason for the failure is when you traceroute from those rtrs their default source interface isn’t known on the L3 core switch 

If those subnets are known you may get a possible result.


Please rate and mark as an accepted solution if you have found any of the information provided useful.
This then could assist others on these forums to find a valuable answer and broadens the community’s global network.

Kind Regards
Paul

Hello @paul driver  I mentioned that these routers are directly connected to Core Switch and there is EIGRP between them. I can ping and tracert any interface of the Switch, the same I can ping and tracert existent IP addresses which are behind this Switch. The strange issue happens only, when I do tracert to non-existent IP.

Simple example, if I traceroute from any of those directly connected Routers, let's say existent host - 192.168.10.15/24. I get this:
1. 172.16.1.1 -> Interface of Core Switch
2. 192.168.10.15 -> destination host

In other hand, if I traceroute from any of those directly connected Routers, let's say nonexistent host - 192.168.10.22/24. I get this:
1. * * *
2. * * *
3. * * *
etc.

And Core Switch will create incomplete entry for 192.168.10.22, so Switch is receiving packets from the Router.

I am interested in the examples that you post. If you tracert to non existing host you show several entries with * * * and then etc. Am I correct in assuming that you get the * * * entries out to 30 entries? The * * * indicates a timeout, or failure to receive a response to that probe. I am wondering if there is something in the switch config, or perhaps in the router config, that prevents transmission of certain responses such as host unreachable?

HTH

Rick

@Richard Burts  Yes, I put "etc" to indicate that it will reply with * * * till end of the traceroute (default is 30 hops max). Most likely, it indicates a timeout. As far as I know, Cisco doesn't generate icmp message "destination host unreachable" if there is no ARP entry for particular IP. Cisco only generates those messages if there no route in Routing table. So, in this case both Router and Switch have route to the destination, but Switch as a last hop towards destination doesn't have ARP entry for it (it creates incomplete entry) and it will not send back any "destination host unreachable". message. But even if switch were to send such ICMP message, in traceroute 1st hop should be Switch itself anyway and only then "destination host unreachable" message: Example from my lab:

R1#traceroute 10.10.25.2
Type escape sequence to abort.
Tracing the route to 10.10.25.2
VRF info: (vrf in name/id, vrf out name/id)
1 10.10.12.2 12 msec 4 msec 8 msec
2 10.10.12.2 !H * !H

R1 has default route to R2. It traceroute to 10.10.25.2, but R2 is not aware of such network and therefore it sends ICMP message "destination host unreachable"

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community:

Innovations in Cisco Full Stack Observability - A new webinar from Cisco