We are trying to replace a Cisco core switch with an EX2052-P and so trying to replace the Cisco IP Helper command with Cambium’s DHCP relay. This is so we can get IP addresses for a local subnet from a remote DHCP server (routed via MPLS). This obviously all works fine on the Cisco kit and we are simply trying to replicate it on our new Cambium cnMatrix EX2052-P.
We’ve hit a wall in that our DHCP server will receive the Cambium DISCOVER packets but will not respond with any OFFER packets. We’ve done packet captures and the only notable difference between the Cambium and Cisco discover packets in that the source address with Cambium is the switches IP address in the internet subnet instead of it’s interface on the subnet where the original discover packet came from.
Does anyone have any insight into this?
My understanding is that the source address is used by DHCP servers to identify the network to provide an IP address for and so the internet subnet set as the source address is misleading the DHCP server and it doesn’t respond.
So we first noticed this issue on the current recommended 4.3. We upgraded to 4.6 in the hope it would help.
We have also raised a ticket and I actually reached out here as there has been no progress on the ticket so far, despite lots of tests we have performed.
I was hoping someone might have some experience with using the DHCP relay functionality and could shed some light on our issue.
Hi Aron, I am awaiting confirmation from the engineers that our switch is relaying dhcp with src ip is the outgoing interface facing the server. I am not aware of any change in the dhcp relay so it is expected the same behavior with all switch software versions. We have not encountered other customers’ report of similar problem. My understanding is that similar implementation is happening with other vendors such as HP, Ruckus etc. I am not familiar with Cisco in this regard. Can you please let us know what type of dhcp server you are using? There is VLANID option that can be configured on the switch to include vlan id in the relay packet. Does your server support this option to identify the pool? I am also checking with our engineering team whether it is possible to configure the switch to use the interface connecting to the dhcp client for source ip in the packet. Thanks.
Many thanks for the in depth reply and looking into this!
We are using a Windows server 2019 DHCP server. Just standard windows basically. We have noticed the VLANID option and have tried to enable it, but we aren’t sure what to do at the DHCP server end to match it up. If you have any guidance on what option would need to be set on the DHCP scope to get it to use the VLANID, we would appreciate it.
Wherever I read on the internet, all articles say the same thing, which is that the source IP address of the relayed DHCP packet is what is used to identify the subnet and so the scope to hand out an IP address from.
I’d be interested to learn how others are getting this to work if their Cambium switches also use the made internet address for the source instead of the VLAN interface.
Yes it does, we can see the Relay Agent IP address buried in the packet. However that is clearly not being picked up or used by the Windows DHCP server. However when the source IP address is the DHCP client’s default gateway (switch interface on that subnet), then the DHCP servers offers an address.
I can only conclude that the Relay Agent IP is not used by Windows DHCP. If you know how to get it to use it then please let me know.
We have done further testing to see if the relay sends Option 82 sub-option 5 information in the packets.
From our testing it does NOT. We can see option 82 sub options 1, 2 and 10, but we cannot get it to include sub-option 5.
We have read that sub-option 5 is a supported standard in Windows DHCP server so it could potentially be a way around this issue.
At present we are at a loss, as we have a switch here that can’t relay DHCP packets using the source IP nor the opt82so5 methods to let the DHCP server identify the scope.
I would be VERY interested to learn how this works for others on Cambium switches in a similar situation.
Hi Aron, I am going to confirm whether sub-option 5 is supported. Our test engineer is checking the problem with Windows server 2019 DHCP server and examining the server’s setting to work with our switch. Do you happen to have other servers that can be used in a meantime? If it is possible to modify our current implementation to be compatible with Windows DHCP server, what’s time line for the patch release? Thanks.
Very much appreciate your efforts in helping us resolve this. We have a test lab set up now and are doing some tests with different configurations to see if we can get around it!
In terms of timescale, we are trying to get past this ASAP really so find a work around is top priority and if we do then a patch isn’t as urgent.
So we have managed to get this working now. We think it was an issue with our DHCP server as a full restart of the Windows server seemed to get it working.
We think it’s properly using the Relay Agent IP address embedded in the packet to choose the correct scope so things are working as they should be.
If it didn’t solve the problem, please subimt a ticket