It's a familiar scene for anyone diving into network labs: you've meticulously configured your router-on-a-stick setup, expecting seamless communication, only to find certain subnets stubbornly refusing to play nice. This is precisely the puzzle a network enthusiast recently encountered, grappling with inter-VLAN routing issues involving the 10.0.30.0/24 subnet.
The core of the problem seemed to stem from how the router's routing table was interpreting the network hierarchy. The user noted a peculiar entry: '10.0.0.0/24 is subnetted, 2 subnets' with '10.0.30.0 is directly connected.' This, they rightly pointed out, felt off. Logically, 10.0.30.0, when configured as a /24 network, should be a distinct subnet, not a sub-subnet of a /24 that itself is only showing two direct connections. It suggests a potential summarization or misinterpretation of the network boundaries.
In a router-on-a-stick scenario, the router acts as the Layer 3 gateway for multiple VLANs, with a single physical interface connected to a trunk port on a switch. Each VLAN is then represented by a sub-interface on the router, each configured with an IP address within the VLAN's subnet and tagged with the corresponding VLAN ID. The switch, in turn, forwards traffic for these VLANs to and from the router.
The user's setup involved an 871W router and a C2960-8TC-L switch. They could ping across some interfaces and manage devices via SSH, but direct Layer 3 connectivity between hosts in different VLANs was failing. Specifically, a host in VLAN 10 couldn't ping sub-interfaces for other VLANs, while a host in VLAN 30 could ping those same sub-interfaces. This asymmetry is often a clue pointing towards routing table discrepancies or access control list (ACL) issues, though ACLs weren't explicitly mentioned as a problem here.
The routing table output provided a key insight: C 10.0.0.0/24 is directly connected, FastEthernet4.10 and C 10.0.30.0 is directly connected, FastEthernet4.30. The router is indeed seeing these as separate, directly connected /24 networks. The confusion arises from the line 10.0.0.0/24 is subnetted, 2 subnets. This phrasing can be misleading. In this context, it's likely the router is simply listing the directly connected networks that fall under the broader 10.0.0.0/8 address space, rather than implying that 10.0.0.0/24 itself has been further subnetted by the router. The critical point is that the router does have specific, directly connected routes for both 10.0.0.0/24 and 10.0.30.0/24.
When troubleshooting inter-VLAN routing, especially with a router-on-a-stick, a few common culprits emerge:
- Sub-interface Configuration: Ensuring the encapsulation dot1q command is correctly applied to each sub-interface, along with the correct VLAN ID, is paramount.
- IP Addressing: Double-checking that the IP addresses assigned to the sub-interfaces are indeed the default gateways for their respective VLANs and that hosts within those VLANs are configured with these gateway IPs.
- Trunk Configuration: The switch's trunk port must be configured to allow the necessary VLANs, and the native VLAN should ideally match on both the router's physical interface (though not explicitly configured on the 871W's sub-interfaces) and the switch's trunk port, or at least be handled consistently.
- Routing Table: As seen in this case, the router needs to have a valid route to reach each subnet. The
show ip routecommand is the go-to for verifying this.
The user's observation about the MAC address table on the switch, showing MACs from VLAN 30 and VLAN 131 appearing on the trunk port (Fa0/1), is also relevant. This confirms that traffic is traversing the trunk. The fact that the VLAN 30 host could ping the sub-interfaces suggests that the routing path from VLAN 30 to the router was functional. The issue was likely on the return path or from the VLAN 10 host's perspective.
Ultimately, the goal is a straightforward setup where the router correctly identifies and routes traffic between these distinct /24 subnets. The initial confusion stemmed from the interpretation of the routing table output, but the underlying configuration for directly connected networks was likely sound, with the connectivity issues potentially arising from subtle misconfigurations in sub-interface encapsulation, IP addressing on hosts, or perhaps even a firewall rule if one were in play. The user's desire for a basic, working router-on-a-stick configuration is a common and achievable goal in network labs.
