TL-SG3428 - DHCP packet processing difficulties - ACLs, filtering, snooping, relaying

TL-SG3428 - DHCP packet processing difficulties - ACLs, filtering, snooping, relaying

TL-SG3428 - DHCP packet processing difficulties - ACLs, filtering, snooping, relaying
TL-SG3428 - DHCP packet processing difficulties - ACLs, filtering, snooping, relaying
a week ago - last edited a week ago
Model: TL-SG3428MP  
Hardware Version: V2
Firmware Version: 2.0.11 Build 20230602 Rel.76586

Hello

 

I've been struggling with this switch and DHCP setup for a while. For reasons I don't want to cover here I want to have two DHCP servers (routers/access points each providing two different default routes to hosts either wired or wireless) on the same VLAN and be able to have control over which ports have visibility of which VLAN and therefore which egress. NB: The routers are pretty dumb and have little support for static routes, dynamic routes, DHCP configuration and I don't want to introduce another component into the setup.

 

So briefly:

 

- the switch and both routers are on the same VLAN

- any hosts attached to router A or B should only receive DHCP offers from the respective router

- For any traffic that traverses the switch I want to control things so that only one offer is made from the router of my choice (or run a DHCP server on switch to make that choice)

 

Looking at the switch naively I thought this should be relatively straightforward. Since it supported switchport ACLs, DHCP server, DHCP snooping/filtering and relaying I believed some combination of the above would create a supportable configuration.
 

However, the prioritisation of how packets are handled as they ingress the switch seems to cause me a problem. From my observations:

 

- ACLs seem to be way down the pecking order in terms of when they get processed by the switch

- In most cases DHCP traffic is completely ignored by ACLs. I can put a blanket deny on an ACL and attach it to a VLAN or a port. Regular IP traffic will be filtered, but DHCP will still get through

- I can mark certain ports to untrusted for DHCP snooping which can block out traffic to some servers

- At one point I considered running DHCP server on the switch but if that is the case it will always respond to any DHCP requests from router A or router B since they are on the same VLAN segment. Also it doesn't seem possible to have multiple pools on the same segment, so manual binding to different routers isn't possible

- I played briefly with DHCP relay options but all of these seem to rely on per VLAN configuration and that would imply I would need to try and implement a flat network with overlapping VLANs

 

I have read in some of the firmware release notes that there have been some changes in how the DHCP packets are processed. I don't 100% need to be on the latest version of the firmware if one of the older versions would make the configuration easier. Other than the above, my configuration is relatively vanilla.

 

Is there any way to control the DHCP request packets BEFORE they get processed by relay/server/filter/snooping logic?

0
0
#1
1 Reply
Re:TL-SG3428 - DHCP packet processing difficulties - ACLs, filtering, snooping, relaying
Friday

Hi @paul778 

 

Currently, achieving the specific scenario you described presents some challenges. In typical network setups, DHCP functions are configured under the assumption that there is only one legitimate DHCP server per network or per VLAN. The main goal of these configurations is to enable the DHCP server to identify clients based on their connection points and assign appropriate IP addresses accordingly.
To address your needs, we might recommend using DHCP filtering. This feature allows you to manually assign MAC addresses to specific DHCP servers, effectively controlling which clients receive IPs from which server. However, please note that DHCP filter settings are applied by MAC address rather than by port.
If your primary goal is to restrict clients to access only a specific router, you might consider using port isolation. This feature can limit a port’s traffic to only communicate with a designated router and its clients, providing a similar level of segmentation while still allowing clients to communicate with each other within the network.

0
0
#2