Background:
In our production environment we have a C9500-40X acting as a layer 3 switch with many VLANs and layer 2 switches connected. The layer 2 switches range from 3560 at the low end all the way up to 9300 mgig switches. We have 3750 and 3850 switches as well. One day I noticed that a 3560 without a default gateway configured and no route statement could ping and telnet outside of its management VLAN. I configured a 9300 similarly, but it would not ping outside of its management VLAN.
I searched for an answer and found some good info:
https://community.cisco.com/t5/switching/no-default-gateway-but-can-still-ping-other-network/td-p/2995971
https://community.cisco.com/t5/switching/unusual-bahaviour-on-ws-c3560cg-8pc-ip-connectivity-without-ip/m-p/2027329
Peter Paluch from the 2nd link indicates "all Catalyst" switches behave this way. From my testing the 3560 & 3750 do, but the 3850 & 9300 do not. In fairness, he wrote that in 2012.
Testing:
I wanted to replicate the behavior in a lab environment with minimal equipment and configuration to eliminate as many variables as possible so others can easily duplicate and verify this.
I took a pair of WS-C3560-24PS switches running version:
Cisco IOS Software, C3560 Software (C3560-IPBASEK9-M), Version 12.2(55)SE12, RELEASE SOFTWARE (fc2)
Compiled Thu 28-Sep-17 02:04 by prod_rel_team
On both switches I issued:
write erase
del vlan.dat
reload
They both came back up with the "Would you like to enter the initial configuration dialog? [yes/no]:" prompt, indicating they are at a default out-of-the-box configuration.
On switch 1 I configured:
enable
configure terminal
vtp mode transparent
hostname Switch-1
user tester privilege 15 secret tester
ip routing
line con 0
login local
logging synchronous
line vty 0 15
login local
logging synchronous
interface vlan 1
ip address 192.168.0.1 255.255.255.0
no shutdown
interface vlan 2
ip address 192.168.1.1 255.255.255.0
interface FastEthernet 0/1
switchport access vlan 2
spanning-tree portfast
interface FastEthernet 0/24
switchport trunk encapsulation dot1q
switchport mode trunk
end
write memory
On Switch 2, I configured:
enable
configure terminal
vtp mode transparent
hostname Switch-2
user tester privilege 15 secret tester
line con 0
login local
logging synchronous
line vty 0 15
login local
logging synchronous
interface vlan 1
ip address 192.168.0.2 255.255.255.0
no shutdown
interface FastEthernet 0/1
spanning-tree portfast
interface FastEthernet 0/24
switchport trunk encapsulation dot1q
switchport mode trunk
end
write memory
Of note, switch 2 has no default-gateway, no interface vlan 2, and no switchport access vlan 2. The network masks (255.255.255.0) place networks 192.168.0.0 and 192.168.1.0 outside of each other. Port 24 (trunks) on both switches are connected together and port 1 on both switches are connected to Windows 10 PCs. Switch 1 is acting as a layer 3 switch, and has proxy-arp enabled by default (not explicitly configured.)
Switch 2 will arp for 192.168.1.1 and receive the MAC address for Switch 1's interface VLAN 1. Switch 2 can ping and telnet to 192.168.1.1.
PC2 plugged into port 1 on switch 2 with IP address 192.168.0.254 255.255.255.0 and no gateway cannot reach PC1 plugged into port 1 on switch 1 with IP address 192.168.1.254 255.255.255.0 and no gateway:
PING: transmit failed. General failure.
I was curious to see if the PCs would arp for IPs outside of net mask- and they don't.
Adding gateway 192.168.1.1 to PC1 and 192.168.0.1 to PC2, they can ping each other as expected. Removing the gateways, changing the masks on the PCs to 255.255.0.0, and clearing the arp cache on the PCs and Switches, they can ping each other. So, like Switch-2, PC-2 can arp across VLANs thanks to proxy arp.
As mentioned above, 3560 & 3750 will arp for addresses outside of configured subnet and ping outside of configured subnet without a default-gateway. The 3850 and 9300 switches that I tested will not. I wanted to see if there was something I could do to make the 9300 behave like the 3560. I turned on ip host-routing and this caused the 9300 to arp for an IP outside of its management subnet and it would add the IP address to its arp table, however it still wouldn't ping outside. Before turning on ip host-routing it wouldn't arp outside of management subnet. I used debug arp and debug ip icmp during my testing to verify what was going on.
