I85PREP
⌘ K
Aruba Switching Associate study materials
Aruba Switching Associate study resources

Inter-VLAN Routing Fails After Adding a New Subnet

Aruba Switching Associate · Put your knowledge to work in context.

All case studies

Inter-VLAN Routing Fails After Adding a New Subnet

An Aruba 2930F acts as the Layer 3 gateway for a small campus. Existing VLANs 10 (10.10.10.0/24) and 20 (10.10.20.0/24) route correctly between each other. A new VLAN 40 (10.10.40.0/24) is added for a lab. The lab switchport is untagged in VLAN 40, and the gateway is configured with interface vlan 40 and IP 10.10.40.1/24. Lab hosts can ping 10.10.40.1 but cannot reach hosts in VLAN 10 or 20. Hosts in VLAN 10 can ping VLAN 20 fine. No ACLs were intentionally created, but the switch has ip routing enabled globally.

1. Given the symptoms, what is the most likely cause and how would you verify it?

Read the worked answer

The lab can reach its own gateway (10.10.40.1) but not other VLANs, while VLAN 10↔20 works. That points to a routing/forwarding policy specific to VLAN 40, not a global routing failure. Most likely an ACL or policy was applied to VLAN 40 or its interface (perhaps a default deny inherited from a template), or the VLAN 40 SVI is missing from routing in some way.

Verification steps:

  1. show ip route - confirm connected routes for 10.10.10.0/24, 10.10.20.0/24, and 10.10.40.0/24 all exist.
  2. show running-config interface vlan 40 - check for ip access-group or policy attachments.
  3. show ip access-list / show statistics on the ACL to see if lab traffic is being denied.
  4. From the gateway, ping a VLAN 10 host sourced from 10.10.40.1 to isolate forwarding vs. host firewall. If the connected route is present and no ACL blocks it, check that lab hosts have the correct default gateway (10.10.40.1) and subnet mask.

2. If the cause turns out to be an implicit deny in an ACL applied to VLAN 40, what is the correct fix and what principle should guide it?

Read the worked answer

Add an explicit permit for the intended inter-VLAN flows before the implicit deny, or remove the unintended ACL if it was applied in error. For example, to allow lab-to-VLAN10 only:

ip access-list extended LAB-IN
   permit ip 10.10.40.0 0.0.0.255 10.10.10.0 0.0.0.255
   deny ip any any log
interface vlan 40
   ip access-group LAB-IN in

Guiding principle: ACLs are evaluated top-down and end with an implicit deny, so every permitted flow must be stated explicitly. Also confirm direction (in vs. out) - applying in on the SVI filters traffic entering the gateway from that VLAN, which is usually what you want for segment isolation.