MikroTik

I've been plagued with this issue "feb/16 16:21:34 dhcp,warning vlan8-lan offering lease without success" and have yet to figure out what the root cause is. I have built and rebuilt 3 MT devices, a CRS125, a RB2011 and most recently an RB3011. The problem has shown up in the current version of ROS v6.38.1 as well as v6.37. The configuration is very simple.
I've tried every incarnation of brodcast, non-broadcast, bootp options, etc. I have reset and rebuilt the config from scratch on each device. I have tried plugged directly into the device and via a switch, a MT access point. There is no common thread that I can find. The clients range from iOS, MacOS X, Linux, windows 7, and embedded devices like APC SmartUPS cards and printers (likely busybox linux). MacOS X seems to work the best but even that is inconsistent. The problem seems to worsen over time, working fine for some time and then getting progressively worse. The network is dual stacked with IPv6, it also had a small set of static mappings, but I removed them when the problem began to surface again.
Right now I have moved to an external dhcp server running isc-dhcpd and it works just fine with no other adjustments to the switch or the mikrotik device.
Any ideas, thoughts, rotten fruit to throw?

nb

the hundreds of times ive seen this its always been because of a faulty cable by the remote side thats asking for dhcp. maybe in your case the response is not making it back to the requestor for other reasons, but usually because the cable is faulty.

That's a good thought. I typically start my troubleshooting at layer 1, I've replaced the cabling (twice) during the process of seeing this and cable tested each time. Stats on the interfaces to the RB looks reasonable:
I've also got clients experiencing this across L2 devices, wireless, direct connections to the RB. I don't think that *all* of the cabling could be bad as it is a mix of structured cabling, fiber, and direct patch cables. It *feels* like a bug to me, though. The CLI and web interface for the leases section goes bananas when trying to display in this state, leases showing multiple times, disappearing and reappearing, etc. This is the same behavior across ROS and hardware platforms and it seems to come and go. I would also expect the same behavior to the external dhcp server plugged into the same equipment, which does not occur.

I've encountered this problem at a number of subscriber installations, and never heard a good explanation of why it was happening. The only time I ever actually solved it was when it started occurring at a new installation and then several days later the service went out – I found that indeed, the outdoor cable had been chewed by pack rats. At another site where this occurs, we used a cable that had been installed by the homeowner, so that would be consistent with this diagnosis. However, at a third subscriber, we ended up replacing the entire outdoor cable for completely unrelated reasons (he wanted it rerouted), and the problem did not go away. Perhaps it's due to a bad patch cable inside his house beyond our wiring.

In any event, it might be worth just running the built-in ethernet test for a significant period and seeing if it comes up with transient faults.


Sent from my iPhone using Tapatalk

I've had this problem from about 10 years, in all cases was faulty cable/connector or switch/router. Or just the router needed a resetart.

I've tested these cables for continuity as well as attenuation and xtalk, they all test fine. In addition, there are clients attached via fiber (fiber also cleaned, scoped, and verified). I am not convinced that this is a physical issue since I have literally replaced everything in the path, with the exception of a handful of structured cable runs connecting random remote hosts. With brand new cables, tested and verified, plugged directly into the RB I see the same behavior.
It's moot at this point - I've lost all confidence in the dhcpd implementation and moved everything to an external ISC-dhcpd server and have have integrated dhcpdv6 for the managed bit as well which was on the roadmap anyway.

I have literally replaced everything in the path, with the exception of a handful of structured cable runs connecting random remote hosts. With brand new cables, tested and verified, plugged directly into the RB I see the same behavior.

I'm curious-- have you replaced the Routerboard? A bad or intermittent ether port jack might create the same failure mode as an intermittent cable.

My gut feeling is that this is somehow hardware- or unit-related. DHCP server works perfectly at all but a couple of my sites, and when I see this message, it's always at the same few sites.


Sent from my iPhone using Tapatalk

Yes, I have seen this behavior with 3 different routerboards in this environment over the last 18 or so months. A CRS, an RB2011 and an RB3011. The entire infrastructure is been replaced at this point with the exception of the structured cabling, which isn't in the critical path (and has been removed from the environment for extended periods for testing). I have even replaced a handful of it when it was convenient - anything in a chase or conduit has been tested and verified as good, then replaced, tested and verified again for good measure. I have also done resting and replacement of 3 different layer2 devices - one of which was new in box.
When I drop in an ISC based dhcpd server the problem disappears - even with zero other changes, this has been tested and verified at every change when the RB dhcpd fails. I've been extremely systematic and methodical during the testing, no more than one change at a time, collect data, etc.
The environment is pretty simple, too. Like I said, I'm resolved to just use the ISC server at this point. It's a known quantity, runs on the local resolver and I have code that works with it. It's not quite as clean but I can deal with it since it buys me managed dhcpdv6 and I've lost confidence in the MT implementation.

Thanks -- this is a valuable data point. You should send a report outlining these findings to support@mikrotik.com. I'm fairly certain they have no idea what is going on here, as we have never received an explanation for or an acknowledgement of this syndrome.


Sent from my iPhone using Tapatalk

I have had issues with this in the past and what I learned is that sometimes the lease time may be a problem ... I don't remember which model exactly, but some HP switches refused to obtain IP address if lease time was less than 2h and one printer required lease time to be maximum 1d .... hope this helps...

JF

That's interesting information. It wouldn't be applicable to my own experiences because we use a lease time of four hours (so we can have a reasonably close indication at any time of how many devices are likely to be connected in the household).

One other curiosity we have noticed is that the devices generating this message have been preponderantly Apple computers. But our sample size is low, plus our business runs exclusively on Apples and has never experienced this problem locally.

I agree with that. We do sometimes see those messages on our WiFi network and it always is an Apple device.

I mostly saw this with embedded devices, predominately based on linux - but there is no exclusivity. I saw it on some apple iOS based devices, some chromebooks, some MacOS based laptops and desktops and one Windows 7 VM. There were a number of static DHCP entries, and those are the ones that had most of the issues, but again, not exclusively. It was a mind numbingly frustrating issue, especially since IPv6 worked completely flawlessly. I'm a wide area guy so dealing with end systems frustrates me pretty quickly and ultimately I ended up killing the MT dhcp service and set up an ISC server running a linux LXC container and was done with it. I may try again since upgrading to 6.38.5 just to see if that changes anything.

nb

Maybe in a wide area network there are different issues. When the 4-packet DHCP exchange does not complete due to packet
loss, you will have problems. But in my case there is good connectivity (an indoor WiFi network) and only Apple devices are
affected. We also have Chromebooks, Microsoft telephones, Android telephones (Samsung) etc and they all work fine.

Packet loss is a problem everywhere, but I am unconvinced that it is the issue since I replaced everything including fiber, twisted pair, ROS devices, patch cables and structured cabling. Dropping in a stand alone dhcp server solved the issue immediately and permanently. I also saw no evidence of packet loss in the tcpdump packet traces I took.

nb

Another data point: Upgrading to 6.38.5 seems to cause this behavior pretty to occur reliably for me on multiple platforms. Downgrading to the bugfix 6.37.5 fixes the issue.

Another data point: Upgrading to 6.38.5 seems to cause this behavior pretty to occur reliably for me on multiple platforms. Downgrading to the bugfix 6.37.5 fixes the issue.

Glad you could resolve your issue. Still, if downgrading to the bugfix has resolved it would be nice if you could let support know about it, so they can look into it to avoid having a possible bug in the upcoming releases.

Oh no, I wasn't clear. It just made it easy to reproduce in that I can update to that version and cause the behavior. It didn't solve it for a number of locations. I still maintain that the dhcp server isn't up to par. I'm moving almost everything to ISC at this point, which I know well and does quite a bit more. Downside is that it requires external resources to run and adds operational overhead.

nb

I still maintain that the dhcp server isn't up to par.

Or maybe it is your configuration that is not OK. I use the MikroTik DHCP server on several networks (often 2-4 networks on a single router) without any
problem other than the occasional trouble with Apple clients.

I still maintain that the dhcp server isn't up to par.

Or maybe it is your configuration that is not OK. I use the MikroTik DHCP server on several networks (often 2-4 networks on a single router) without any
problem other than the occasional trouble with Apple clients.

Sure, anything's possible. However, I should note that the data doesn't support that since I had it occurring in multiple locations with vastly different configurations. In addition, I tore out the config on the deployment that sparked this post and re-built it with nothing more than a pool and a server on one segment and still saw the issue. Given that I have been building large, complex networks for 20 years I would have expected to see this before and in other environments if it was in fact one of my configurations causing the issue. Additionally, it only occurs with this particular dhcp implementation, and I have read and re-read the guides to validate my configurations thinking the same thing - it may be my config. I'm pretty confident that it is not.

I have seen this happen where the DHCP server is on a bridge, and the admin-mac has not been set on the bridge.

It is always good practice to set an admin-mac

Nick.

Interesting. In most of these cases the DHCP server is on a bridge. I'll check the admin-mac. I thought I had that set but there is a chance I am mis-remembering. Is this documented as undesirable or unsupported anywhere? Great info - thanks a bunch.

nb

I have seen this happen where the DHCP server is on a bridge, and the admin-mac has not been set on the bridge.

It is always good practice to set an admin-mac

Nick.

It could well be that because I normally use a bridge only when it really cannot be avoided.
The examples I gave all have the DHCP server on an ethernet port or at most on a VLAN interface.

It could well be that because I normally use a bridge only when it really cannot be avoided.
The examples I gave all have the DHCP server on an ethernet port or at most on a VLAN interface.

This is great info - I have seen that there seems to be an apprehension to using bridges, is there a reason for that? I typically use bridges and vlan sub-interfaces, but the config is primarily on the bridge.

nb

I had issues with latter ROS versions stirring up multicast/broadcast traffic with RSTP enabled in connection with third party switches. Disabling STP/RSTP on the bridge may help...

Hi,

I observed DHCP problems in conjunction with

- wrong MTU setting (expecially along with VLAN),
- no Admin MAC on bridge interface
- STP configured on bridge running DHCP

Apart from layer 1 problems, these points are most of the time the cause of all trouble.

Regards,
Ape

It could well be that because I normally use a bridge only when it really cannot be avoided.
The examples I gave all have the DHCP server on an ethernet port or at most on a VLAN interface.

This is great info - I have seen that there seems to be an apprehension to using bridges, is there a reason for that? I typically use bridges and vlan sub-interfaces, but the config is primarily on the bridge.

nb

I prefer to use switch instead of bridge because it offloads the CPU.
Sometimes a bridge can be useful, e.g. with the models that have limited switch capabilities or multiple switches,
and of course it can do filtering. But I certainly do not create a bridge as a standard config even when not required.
But does adding the admin MAC to the bridge solve your problem?

Hi! I can confirm this bug after upgrading to 6.38.5 on RB750GL. After upgrading all my VMs and Hyper-V host was unable to get an ip.
Disabling RSTP on bridge interface helped. Never saw this bug before. RB works about 2 years without issues till now. No Admin-MAC.

UPD. Upgraded another mikrotik router (hEX model) - no bug observed. But this installation has no Hyper-V Virtual switch, only Apple iMac on cisco 2960 switch. Configuration: RSTP is on, no Admin-MAC, Bridge.

It probably depends on the configuration of your external switch as well.
But this STP code sure is giving problems....
A friend has been fighting with a LHG on a point-to-point connection where some tagged VLAN needs to be transferred over the link.
Did not work. In the end he configured the LHG as a router and it works, but after that I remembered the STP thing.
It was probably that. Problem was solved because the bridge was deleted.

After upgrade to 6.38.5 (stable) i am saw error for dhcp, warning offering...
And some computers and devices do not given IP.

Admin mac in bridge with local interface solved my problem. Thank communnity for help. And personnally Ape!

Help me with the same problem
dhcp offering lease

my config

# apr/04/2017 12:45:54 by RouterOS 6.38.5
# software id =
#
/interface bridge
add name=bridge1
/interface ethernet
set [ find default-name=ether1 ] mac-address=C8:6C:87:3F:25:C8
set [ find default-name=ether2 ] advertise=10M-half,10M-full,100M-half,100M-full name=ether2-master
set [ find default-name=ether3 ] advertise=10M-half,10M-full,100M-half,100M-full
/interface l2tp-client
add add-default-route=yes connect-to=10.255.255.254 disabled=no max-mtu=1460 mrru=1600 name=flex password=**** user=****
/ip neighbor discovery
set ether1 discover=no
/ip hotspot profile
set [ find default=yes ] html-directory=flash/hotspot
/ip pool
add name=dhcp ranges=192.168.0.10-192.168.0.254
add name=dhcp_pool1 ranges=192.168.0.2-192.168.0.254
/ip dhcp-server
add address-pool=dhcp_pool1 disabled=no interface=bridge1 lease-time=51w3d6h name=dhcp1
/interface bridge port
add bridge=bridge1 interface=ether2-master
add bridge=bridge1 interface=ether3
add bridge=bridge1 interface=ether4
add bridge=bridge1 interface=ether5
/ip address
add address=192.168.0.1/24 comment=defconf interface=ether2-master network=192.168.0.0
add address=172.18.248.94/24 interface=ether1 network=172.18.248.0
/ip cloud
set ddns-enabled=yes
/ip dhcp-client
add comment=defconf dhcp-options=hostname,clientid interface=ether1
/ip dhcp-server alert
add alert-timeout=1m disabled=no interface=bridge1 on-alert="/log info \"unknown dhcp-server\"" valid-server=6C:3B:6B:70:43:4D
/ip dhcp-server lease
add address=192.168.0.3 client-id=1:b0:5a:da:87:c7:90 mac-address=B0:5A:DA:87:C7:90 server=dhcp1
add address=192.168.0.40 client-id=1:0:25:22:38:86:ad mac-address=00:25:22:38:86:AD server=dhcp1
add address=192.168.0.46 client-id=1:0:255e:81:2e mac-address=00:25:AB:5E:81:2E server=dhcp1
add address=192.168.0.51 client-id=1:dc:4a:3e:ed:c9:c1 mac-address=DC:4A:3E:ED:C9:C1 server=dhcp1
add address=192.168.0.54 always-broadcast=yes client-id=1:0:15:17:b3:88:47 mac-address=00:15:17:B3:88:47 server=dhcp1
add address=192.168.0.33 client-id=1:0:255d:2e:3e mac-address=00:25:AB:5D:2E:3E server=dhcp1
add address=192.168.0.100 mac-address=00:11:32:4D:95:8C server=dhcp1
/ip dhcp-server network
add address=192.168.0.0/24 comment=defconf gateway=192.168.0.1 netmask=24
/ip dns
set servers=80.252.130.254,80.252.130.253
/ip dns static
add address=192.168.0.1 name=router
/ip firewall filter
add action=fasttrack-connection chain=forward comment="defconf: fasttrack" connection-state=established,related
add action=accept chain=forward comment="defconf: accept established,related" connection-state=established,related
add action=drop chain=forward comment="defconf: drop invalid" connection-state=invalid
add action=drop chain=forward comment="defconf: drop all from WAN not DSTNATed" connection-nat-state=!dstnat connection-state=new in-interface=ether1
add action=accept chain=input protocol=icmp
add action=accept chain=input connection-state=established
add action=accept chain=input connection-state=related
add action=drop chain=input in-interface=ether1
/ip firewall mangle
add action=mark-routing chain=prerouting in-interface=flex new-routing-mark=l2tp_m passthrough=yes src-address=192.168.0.2-192.168.0.254
/ip firewall nat
add action=masquerade chain=srcnat comment="defconf: masquerade" out-interface=ether1
add action=masquerade chain=srcnat out-interface=flex
/ip route
add distance=1 gateway=flex routing-mark=l2tp_m
add distance=1 gateway=172.18.248.254
add distance=10 dst-address=192.168.1.0/24 gateway=192.168.0.4
/ip service
set telnet disabled=yes
set ftp disabled=yes
set www address=192.168.0.0/24
set ssh disabled=yes
set winbox address=192.168.0.0/24
/ip traffic-flow
set cache-entries=256k enabled=yes interfaces=flex
/ip traffic-flow target
add dst-address=192.168.0.54 port=1234
/snmp
set enabled=yes trap-version=2
/system clock
set time-zone-name=Europe/Moscow
/system identity
set name=Zenit
/system logging
add disabled=yes topics=dhcp,debug
/system routerboard settings
# Warning: memory not running at default frequency
set memory-frequency=1200DDR
/tool mac-server
set [ find default=yes ] disabled=yes
add interface=ether2-master
/tool mac-server mac-winbox
set [ find default=yes ] disabled=yes
add interface=ether2-master[/spoiler]

Come on, really???
Move all config from your bridge1 to ether2-master, make ether2-ether4 a slave of etner2-master and delete your bridge.

Come on, really???
Move all config from your bridge1 to ether2-master, make ether2-ether4 a slave of etner2-master and delete your bridge.

ok! thx.

Come on, really???
Move all config from your bridge1 to ether2-master, make ether2-ether4 a slave of etner2-master and delete your bridge.

I don't think that this is a well known caveat. For those that may have come from a more traditional layer3 switching background, or running Linux/Unix devices as network gear, associating things with software interfaces (RVI, SVI, bridge groups, etc.) is pretty standard. It'd be useful to explain why we should not utilize bridges for services. The short seems to be that running bridges is supported but
limited and undesirable in most cases.
I had to learn this the hard way, and was lucky enough to have worked on gear that handled software interfaces similarly. Older brocade / Foundry, FWIW, doesn't have the same feature sets on their ve interfaces as they do on hardware interfaces. For those folks that have a significant networking background may not make that connection on MT gear.

Of course it should work OK with a bridge but there are known issues with bridges in a couple of recent versions and
the easiest way to work around them is not use a bridge when you don't need it. And having a bridge just to put 4
ethernet ports in a bridge group that also are on a switch chip is such an example.
Other things that can be tried (as written above) is not to use STP on the bridge, set a fixed MAC address on the
bridge (admin MAC) and now: upgrade to 6.39.1 or the latest RC. As of course, those issues are known and are
apparently being worked on.

Great info, thanks for sharing.

Of course it should work OK with a bridge but there are known issues with bridges in a couple of recent versions and
the easiest way to work around them is not use a bridge when you don't need it. And having a bridge just to put 4
ethernet ports in a bridge group that also are on a switch chip is such an example.
Other things that can be tried (as written above) is not to use STP on the bridge, set a fixed MAC address on the
bridge (admin MAC) and now: upgrade to 6.39.1 or the latest RC. As of course, those issues are known and are
apparently being worked on.

I recently updated my 750Gr3 to 6.39.2 and soon noticed that DHCP was no longer working for two of my subnets. Interestingly, a third subnet was getting DHCP just fine. The only difference was that the working subnet was configured to get DHCP from an external DHCP server and the two broken ones should have been getting DHCP from the 750G. All three subnets are carried by VLANs across the same cabling and switch ports so I concluded that the cabling was OK. I rolled the OS back to the the latest bugfix (6.37.5) and the problem immediately disappeared.

I recently updated my 750Gr3 to 6.39.2 and soon noticed that DHCP was no longer working for two of my subnets. I rolled the OS back to the the latest bugfix (6.37.5) and the problem immediately disappeared.

And you did not bother to read the topics about this issue and try the solutions mentioned there?

I recently updated my 750Gr3 to 6.39.2 and soon noticed that DHCP was no longer working for two of my subnets. I rolled the OS back to the the latest bugfix (6.37.5) and the problem immediately disappeared.

And you did not bother to read the topics about this issue and try the solutions mentioned there?

Well I did actually. I already had the mac admin set and I tried turning of STP, but it made no difference. I was just trying to post helpful info.