DHCP Not passing through Switch

[monkeybike]

Hi,

I have a setup which is a Mikrotik Routerboard with 2 DHCP Servers, a DHCP server operating for my Main LAN (untagged devices), and a DHCP operating on VLAN 101

This all works with a Ubiquiti Tough Switch.

However with a WISP Switch DHCP does not pass through the switch for the devices not on a VLAN 101

Firmware is 1.3.2

VLAN 101 only works if I tick trunk port 6 and make it 101, port 6 has my Unifi AP in it. Set to VLAN 101 for Wifi.

However the same AP on port 6 is set to get DHCP from my main LAN and it doesn't work.

Any ideas as to why?

As tried all sorts to make this work.


Richard

[sirhc]

Please post up your Config Tabs - Ports, VLANs and any other Tab with changes.

I am amazed that more people do not LAB a new piece of equipment to make sure they have all the intercruises worked out with the new brand with they way they have their network set up as everyone does something slightly differently?

I make Tom my CTO at my WISP LAB everything "New" before taking it to the field...no surprises.

[monkeybike]

Thought I would post the answer to my problem so as to help other people who might have a DHCP issue.

Basically Turning on WDS on the WiFI links solved the problem. The APs grabbed a DHCP address, and kept them bound.

Not sure why this works across links far away but doesn't seem to effect links in close proximity, even though its the same link technology.

As my LAB using the same method but only using a couple of links (locations) does not display the problem.

So it seems in my experience so far.

Netonix with Ubiquiti needs WDS

but when its all Ubiquiti Kit as in Tough Switches and Unifi then WDS is not needed. In this setup scenario.

My original post failed to say the set-up is

Unifi Nanobeams are linking locations together, there is no physical cabling other than out of the Router into the first location Netonix switch, which then has a NanoBeam and a AP. That Nanobeam then links to another Nanobeam at another location, where there is another Netonix switch, another nanobeam linking to another location and another AP and so on, further and further away from original starting point.

Next thing to work out is seeing if I can lock down the VLANs, so you might see another posting.

Richy

[sirhc]

Glad your working but no, WDS has nothing to do with Netonix.

WDS is needed for a transparent bridge to function correctly as Fireblade suggested but you would also need this with ToughSwitches as well.

ALWAYS USE WDS ON ALL RADIOS, IF ONE RADIO DOES NOT IN A GROUP WEIRD THINGS BEGIN TO HAPPEN.

[lligetfa]

WiFi essentially breaks layer 2 transparency and WDS was an afterthought to fix it. DHCP might sometimes work without it but it is marginal at best so WDS should always be used. Of course using it can sometimes add a load to ARP tables that were never designed for so many entries but that is rare and usually only manifests if you run too large of a flat network. Usually the ARP traffic will cripple the network before the tables fill up.

Anyway, glad you got things sorted.

[yahel]

I'm seeing a similar problem with DHCP replies not getting to device through Netonix.
It worked fine before we swapped out the ToughSwitch with Netonix - nothing else is changed!
I would ensure the uplink for the site is in WDS - but it's an AC500 PTP - and there's no WDS checkbox like in the older UBNT gear.
(Also flow-control is not working on the AC gear and cannot be enabled using ethtool)...

Ideas?

[sirhc]

I'm seeing a similar problem with DHCP replies not getting to device through Netonix.
It worked fine before we swapped out the ToughSwitch with Netonix - nothing else is changed!
I would ensure the uplink for the site is in WDS - but it's an AC500 PTP - and there's no WDS checkbox like in the older UBNT gear.
(Also flow-control is not working on the AC gear and cannot be enabled using ethtool)...

Ideas?

Yea your the second person to report that the airOS 7 does not appear to support Flow Control, this issue will need to be pressed to UBNT as we have to way to change their code.

The DHCP solution above for monkeybike was to enable WDS and as you say the AC gear does not seem to support this? Just to make sure you do NOT have Port Isolation turned on (checked)under the Ports Tab for any of the ports do you? That would be the column with the heading ISO?

[yahel]

Nope - no port isolation...

I'm sure it's a UBNT oddity - but oddly enough, DHCP was passing through the ToughSwitch - so replacing it with Netonix is causing us a problem now.
Ideas of how to fix this?

I'll look into how to give the device asking for DHCP a fixed IP - only I can't connect to it, as it has no IP right now.
(It's an OpenMesh unit, BTW).

How do I sniff on a particular port of the Netonix?
With tcpdump I only see things to/from the switch itself and broadcast, as expected...
Being able to tcpdump a particular port would be enormously helpful.

Also - if anyone knows WTF is wrong with UBNT for not allowing flow-control in the XC firmware - or how to enable it...
My solution for now is to restrict the ports of these devices to 100BaseT and not allow them 1GE... dumb, but solves the problem for now...

[sirhc]

Nope - no port isolation...

I'm sure it's a UBNT oddity - but oddly enough, DHCP was passing through the ToughSwitch - so replacing it with Netonix is causing us a problem now.
Ideas of how to fix this?

I'll look into how to give the device asking for DHCP a fixed IP - only I can't connect to it, as it has no IP right now.
(It's an OpenMesh unit, BTW).

How do I sniff on a particular port of the Netonix?
With tcpdump I only see things to/from the switch itself and broadcast, as expected...
Being able to tcpdump a particular port would be enormously helpful.

Also - if anyone knows WTF is wrong with UBNT for not allowing flow-control in the XC firmware - or how to enable it...
My solution for now is to restrict the ports of these devices to 100BaseT and not allow them 1GE... dumb, but solves the problem for now...

First I would go to the remote device in question and try assigning a static IP and see if you have access to ping the DHCP server and to the net.

This issue may not be that the device is not getting a DHCP lease but rather something else is configured incorrectly and the device simply does not have access to the DHCP server?

Report back what you find when you assign the device a Static IP.

Also maybe post up your Ports, VLAN, STP, and Device/Configuration Tabs as well as check your Log for anything weird.

[yahel]

Valina setup, no VLANs, no STP.
The device which is not getting IP via DHCP is an Open-Mesh router.
I wish I had a way to set it up with a static-IP, that would have solved the problem.

I can see it's MAC address initiating the DHCP-request, it gets all the way to the DHCP server - quite a few hops away.
I can also trace the DHCP-reply, by sniffing on the UBNT router on the remote side of the link (the AC500 device), but as expected, the reply does not pass the Wireless part of the link... and no WDS setting to enable ;-(

This is all expected behavior from UBNT without WDS - I know that...
What drives me nuts - is why on earth it worked when it was a ToughSwitch - it must do something fishy to solve the problem, and it did... what?