We have one Meraki MS425 configured as an L3 switch to do routing with a transit VLAN so we can connect six buildings together. One building has the internet connection for the whole network. Right now we just have one fiber run going from each building to the Meraki MS425. Here is how we have routing configured on that MS425:
VLANs 10, 30, 40, 50, and 60 are all buildings that have just that one VLAN respectively (and associated subnets 10.1.x.x, 10.3.x.x, 10.4.x.x, 10.5.x.x, and 10.6.x.x), and this MS425 has the .1 virtual interfaces for each of those subnets. Each of those subnets has their own servers (DHCP, DNS, etc.) and all internet traffic passes through this MS425 and the transit VLAN of 172.16.100.0 to get to the building with the internet connection. The next hop IP of 172.16.100.1 is a virtual interface on the upstream switch (Cisco Catalyst) that has the firewall and internet connected to it (and it has it's own DHCP, DNS, etc. in the 10.2.x.x range). I've whitelisted the DHCP servers on VLANs 10, 30, 40, 50, and 60 and this is what this switch sees for DHCP:
What surprises me is what the VLAN 10, 30, 40, 50, and 60 Meraki switches are seeing in terms of DHCP - they are seeing DHCP traffic from other VLANs, and I'm not sure why this is. Here is the view from a switch on the VLAN 30 network:
The port on the MS425 with the transit VLAN that connects it to the VLAN 30 is configured this way:
Port status | Enabled |
Type | Trunk |
Native VLAN | 30 |
Allowed VLANs | all |
Access policy | Open |
Link negotiation | Auto negotiate (10 Gbps) |
RSTP | Enabled (Forwarding) |
STP guard | Root guard |
Port schedule | Unscheduled |
Port isolation | Disabled |
Trusted DAI | Disabled |
UDLD | Alert only |
Tags | none |
PoE | n/a |
Peer SGT capable | Disabled |
Storm control | Enabled |
Port mirroring | Not mirroring traffic |
Stacking port | Disabled |
Here's how the port on the other end of that fiber connection is configured on that VLAN 30 network that's connected to the transit VLAN:
Port status | Enabled |
Type | Trunk |
Native VLAN | 30 |
Allowed VLANs | all |
Access policy | Open |
Link negotiation | Auto negotiate (10 Gbps) |
RSTP | Enabled (Forwarding) |
Port schedule | Unscheduled |
Port isolation | Disabled |
Trusted DAI | Disabled |
UDLD | Alert only |
Tags | none |
PoE | n/a |
Peer SGT capable | Disabled |
Storm control | Enabled |
Port mirroring | Not mirroring traffic |
Stacking port | Disabled |
Why is DHCP traffic crossing VLANs with this setup, and what's the best way to deal with it?
Thats not really 1 transit vlan but a trunk with all vlans.
Allowed VLANs | all |
dhcp request is a broadcast so its also send to your trunkports.
So you need to allow only the vlans you want on the trunk port or make it a access port
My thinking was that should be a trunk because while VLANs 10, 30, 40, 50, and 60 are one VLAN per building, we will probably create more VLANs in those buildings down the line, and if the .1 for those networks is on the MS425, making the downstream (non-L3) Meraki switches like our IDFs. Should I limit the VLANs allowed over trunk ports between switches in each building to just the VLAN(s) being used in that building? Should I also allow VLAN 1 (for switch control plane traffic)?
Right now on our big 10.2.x.x network (that also has the internet connection used by all our networks) we have multiple VLANs and multiple DHCP scopes with one subnet per VLAN (generally speaking) and the core Catalyst switch handles those DHCP requests from the different VLANs just fine using ip helper-address and the switch closets on that network are connected via trunks back to the Catalyst. Here's the configuration of the uplink port in one of those closets back to the Catalyst:
interface TenGigabitEthernet3/1
description *** IDF Uplink Ports ***
switchport
switchport mode trunk
spanning-tree guard root
end
And here's the configuration of one of those VLANs on the Catalyst that corresponds to one non-DHCP IP range (for printers) and one DHCP scope both in that VLAN:
interface Vlan8
description *** workstations 8.1 - 11.255 ***
ip address 10.2.3.1 255.255.255.0 secondary
ip address 10.2.8.1 255.255.252.0
ip helper-address 10.2.1.5
no ip redirects
end
Is DHCP traffic from these scopes crossing VLANs in the 10.2.x.x network and I just don't know it (because it sure seems like it's not)... is the Catalyst doing something different that the Meraki switches don't do? Or is Cisco just not alerting me to the DHCP traffic the way that Meraki switches do?
Definitely start by limiting the vlans allowed in the trunk. If building A only uses vlan 10, trunk only that vlan to the building. If you add more clans later, you simply just add them to the allow list.
Not only is it good from a design perspective but it also means the switches won't see dhcp requests from other buildings.
Ok, I started to limit VLANs on trunks, but now I'm seeing messages on our MS425 transit switch like, "Port 3 is not using the same VLAN settings as its connected switchport". It's configured as a trunk with native VLAN 30 and allowed VLANs 1, 30. It directs me to this page for more info:
Is this just looking at the port configuration on the switch on the downlink and noticing that allowed VLANs there are still "all" and basically suggesting I change that to match the uplink side? I'm not seeing any issues right now reaching hosts in other buildings across VLANs/networks.
And just to clarify, the whole purpose of limiting VLANs on trunks is to lighten the load on the traffic that switches have to cope with, since if you don't, then trunks will carry broadcast traffic from any allowed VLAN to any other trunks, even if there are no ports configured in that or other switches with that VLAN, correct?