Default Gateway Layer 3

原文：Default Gateway Layer 3 — theDXT (Daniel Keer)

I’ve been playing with a Brocade ICX 6650 in router mode and got hung up on making the second VLAN on another Virtual Ethernet talk to the internet. I’m posting this so I don’t forget how to do it later on lol. This write-up keeps the original notes and expands them: the symptom, why a Layer 3 switch behaves the way it does, the single command that fixed it, how to verify the fix, and the handful of other faults that look exactly the same on the wire.

The setup: two VLANs, two Virtual Ethernet interfaces

Your default VLAN of 1 is on Virtual Ethernet 1 and because that’s likely going to be on your regular network you likely won’t run into this issue. However when you make a second VLAN and you want things on that VLAN to be able to talk to the internet well the missing piece is an IP route for the default gateway so it knows how to get to the internet.

My setup looked like this:

• VLAN 1 / Virtual Ethernet 1 — 192.168.3.50/24, the existing “regular” network. The upstream router is 192.168.3.9.
• VLAN 70 / Virtual Ethernet 70 — 192.168.70.1/24, a brand new subnet for servers and test hosts.
• Hosts on VLAN 70 had their default gateway set correctly to 192.168.70.1 — the ICX itself.

Nothing on VE 70 could talk to the internet.

The important detail is that hosts on VLAN 70 could reach each other and could ping the VE 70 address. The switch was routing within the subnet just fine. Only traffic that had to leave the 192.168.70.0/24 network died — which is the signature of a routing problem, not a VLAN, cabling or STP problem.

Why the second VLAN has no path to the internet

A Layer 3 switch like the ICX 6650 builds its routing table in two ways. Directly connected networks appear automatically the moment a Virtual Ethernet interface has an IP address and the interface is up — that is why VLAN 70 could talk to itself. Everything else has to be learned, and a network with no dynamic routing protocol and no static route knows nothing about anything else.

When a host on VLAN 70 sends a packet to 8.8.8.8, the switch performs a longest-prefix match in its routing table. Without a default route the only candidate entries are 192.168.3.0/24 and 192.168.70.0/24. Neither matches, so there is no next hop to send the packet to, and the packet is dropped. Depending on the platform and the reason code, the switch may return an ICMP unreachable to the sender or simply drop it silently — either way the client just sees “request timed out” and blames the internet connection.

Note also that the routing table is per VRF. A default route in the default VRF does not help a subnet that lives in another VRF, and vice versa. On a plain ICX in router mode everything is in the default VRF, so one route covers every VE and every VLAN on the box.

The fix: add a static default route

The missing piece was adding a route of 0.0.0.0 so that if the IP can’t be resolved by any of those networks it knows where to go.

To do this I had to enter the command:

ip route 0.0.0.0 0.0.0.0 192.168.3.9

My router is 192.168.3.9 so it knows that when it can’t solve for any of those networks to just go to my router to then talk to the internet.

Now if I run the command again this is what it looks like:

Just like that the network on the other VLAN on the other VE is now able to talk to the internet.

The full configuration on a Brocade ICX (FastIron)

For anyone rebuilding this from scratch, here is the complete set of pieces that makes VLAN 70 route and reach the internet. The two lines people forget are router-interface ve 70 (which creates the Virtual Ethernet) and the global ip route statement.

enable
configure terminal
!
vlan 70 name SERVERS
 untagged ethernet 1/1/1 to 1/1/12
 router-interface ve 70
!
interface ve 1
 ip address 192.168.3.50 255.255.255.0
!
interface ve 70
 ip address 192.168.70.1 255.255.255.0
!
ip route 0.0.0.0 0.0.0.0 192.168.3.9
!
end
write memory

Line by line:

• vlan 70 with untagged ethernet 1/1/1 to 1/1/12 puts those ports in VLAN 70 as access ports and sets their PVID, so server traffic arrives in the right broadcast domain.
• router-interface ve 70 is a VLAN-level command on FastIron. Without it there is no VE 70 to assign an address to, and the VLAN stays Layer 2 only.
• interface ve 70 plus ip address gives the switch its Layer 3 presence in that subnet — this is the address that hosts on VLAN 70 must use as their default gateway.
• ip route 0.0.0.0 0.0.0.0 192.168.3.9 is the global static default route, pointing at the upstream router. FastIron expects dotted-quad masks here, and 0.0.0.0 0.0.0.0 is the classic “route of last resort”.
• write memory commits the running configuration to flash. Without it the route works until the next reload — a very common “it broke by itself overnight” story.

Verifying the route and the data path

show ip route
show ip route 0.0.0.0
show ip interface brief
show ip interface ve 70
show vlan 70
show arp
ping 192.168.3.9
ping 8.8.8.8
traceroute 8.8.8.8

What you want to see:

• show ip route should list both connected subnets and a static default route pointing at 192.168.3.9. If the only entries are the connected subnets, the route was never applied (or was applied in a different VRF, or was removed by a no ip route somewhere else in the config).
• show ip interface ve 70 must show the interface up/up with the correct mask. A VE with the wrong mask (/25 instead of /24, say) still routes “locally” but breaks half the subnet — a different fault with a similar smell.
• show arp should show a resolved entry for the upstream router. No ARP entry for 192.168.3.9 means you cannot even reach the next hop, so the problem is Layer 2 or the wrong next-hop IP, not the default route itself.
• ping 192.168.3.9 from the switch proves the next hop is alive; ping 8.8.8.8 proves forwarding works; traceroute 8.8.8.8 proves the return path where the trace dies tells you which hop is dropping traffic.

Why ip default-gateway does not fix this

This is the trap that eats an afternoon. On FastIron and on most Layer 3 switches, ip default-gateway is about management traffic: it gives the switch itself a gateway for syslog, SNMP, TFTP and SSH when the device is operating in Layer 2 mode. It is not a forwarding instruction, and it does not create a route for traffic transiting the switch from a VLAN.

Cisco makes the same distinction: on a Catalyst in Layer 2 mode you use ip default-gateway, and on the same box in Layer 3 mode you need ip route 0.0.0.0 0.0.0.0. If you configured a default gateway and clients still cannot reach the internet, you almost always need the route instead.

The other half of the puzzle: the return path

Adding the default route fixes the traffic leaving VLAN 70. It does nothing for the traffic coming back. The upstream router at 192.168.3.9 has to know how to reach 192.168.70.0/24, and by default it will not:

• If the ICX’s VE 1 address (192.168.3.50) is the only route the upstream router has toward your network, configure a static route on the router for 192.168.70.0/24 with next hop 192.168.3.50.
• If the upstream router was only ever told about 192.168.3.0/24, packets from VLAN 70 will go out with their private source address and be dropped or black-holed on the way back — no ICMP, no log, just timeouts.
• If 192.168.70.0/24 is a private range on a home or small-business router, the router also has to NAT (masquerade) that subnet. A router that only NATs its own LAN interface will happily forward the packets and then never translate them.

A useful diagnostic split: ping the internet from a host on VLAN 70 and then from a host on VLAN 1. If VLAN 1 works and VLAN 70 does not, but the switch’s own traceroute looks fine, the missing piece is almost always the return route or NAT on the upstream device — not the switch.

The same one-liner on other platforms

The concept does not change: a router only forwards toward networks it knows, and “everything else” has to be spelled out as a default route with an explicit next hop you can reach on a directly connected subnet.

Checklist: mistakes that produce the same symptom

1. VE never created — the VLAN has an IP address configured but no router-interface ve, so the VLAN is L2-only and the address sits nowhere.
2. Hosts pointed at the wrong gateway — a DHCP scope for VLAN 70 still handing out 192.168.3.9 (option 3) instead of 192.168.70.1.
3. No return route on the upstream router — outbound works from the switch’s own tests, inbound replies vanish.
4. NAT not applied to the new subnet on the border router.
5. ACLs or a firewall that allow 192.168.3.0/24 but not 192.168.70.0/24 — often the exact rule you wrote when the second VLAN did not exist yet.
6. Configuration not saved — write memory missing, so everything works until the next reboot.
7. Missing IPv6 equivalent — on IPv6 hosts a router advertisement supplies the default gateway; if the prefix in the RA is wrong or RA is not sent on the new VLAN, you get exactly the same “one VLAN works, one doesn’t” pattern.

Further reading

Related posts on this site: essential Brocade switch commands, MLNX-OS VLAN interfaces and IP routing, and a trunk and inter-VLAN routing run book for a second vendor’s take on the same job.