DHCP traffic crossing VLANs, what to do?

Nater
Comes here often

DHCP traffic crossing VLANs, what to do?

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:

 

Transit switch routing.png

 

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:

Transit switch DHCP.png

 

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:

Grammar school DHCP.png

 

The port on the MS425 with the transit VLAN that connects it to the VLAN 30 is configured this way:

Port statusEnabled
TypeTrunk
Native VLAN30
Allowed VLANsall
Access policyOpen
Link negotiationAuto negotiate (10 Gbps)
RSTPEnabled (Forwarding)
STP guardRoot guard
Port scheduleUnscheduled
Port isolationDisabled
Trusted DAIDisabled
UDLDAlert only
Tagsnone
PoEn/a
Peer SGT capableDisabled
Storm controlEnabled
Port mirroringNot mirroring traffic
Stacking portDisabled

 

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 statusEnabled
TypeTrunk
Native VLAN30
Allowed VLANsall
Access policyOpen
Link negotiationAuto negotiate (10 Gbps)
RSTPEnabled (Forwarding)
Port scheduleUnscheduled
Port isolationDisabled
Trusted DAIDisabled
UDLDAlert only
Tagsnone
PoEn/a
Peer SGT capableDisabled
Storm controlEnabled
Port mirroringNot mirroring traffic
Stacking port

Disabled

 

Why is DHCP traffic crossing VLANs with this setup, and what's the best way to deal with it?

4 Replies 4
ww
Kind of a big deal
Kind of a big deal

Thats not really 1 transit vlan but a trunk with all vlans. 

Allowed VLANsall

 

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

Nater
Comes here often

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?

Brash
Kind of a big deal
Kind of a big deal

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.

Nater
Comes here often

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:

 

https://documentation.meraki.com/MS/Port_and_VLAN_Configuration/VLAN_Mismatch_Alerts_for_Meraki_Swit... 

 

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?

Get notified when there are additional replies to this discussion.
Welcome to the Meraki Community!
To start contributing, simply sign in with your Cisco account. If you don't yet have a Cisco account, you can sign up.
Labels