I changed a network management and configuration by adding a mikrotik HAP ac 3 wireless router on a small non-profitable org. First they only have an ISP Box to manage their LAN and WAN, which is basically, an internet modem and router with wired port and wireless access. The LAN is a mix of static and dynamic addresses, by changing ISP they must redo their network. So I added the router to avoid that.
As you can see in the draw below, they have two buildings and the network is connected between 2 path panel. I started by only change the network for the first building. This way people from the second building could use internet without interruption during the settings (red line).
When I finished to configure the mikrotik, I just unplug the wire between the path panel and the ISP Box and plug the path panel with the switch.
I thought everything will be fine as I hadn’t issues during the step 1. I had issues with DHCP which were caused by an hidden zyxel wireless router that I discovered later. The laptop in building 1 didn’t get an IP from mikrotik dhcp range 192.168.88.0/24 but instead an address 192.168.1.0/24. I remove the zyxel and everithing went fine. Notice that the zyxel and ISP Box had the same dhcp adress range 192.168.1.0/24.
Till I had questions unsolved.
I know clients broadcast DCHP requests. So it could be an answer that the fist response is accepted by the client and the zyxel router was the first, even if the request go through a more “long” path. By long I mean distance, we are talking about 2 meters of cable between laptop and mikrotik versus almost 200 meters between laptop and zyxel. But I also mean number of devices, there are one switch versus two. In fact, I am not very confident with my hypothesis of distance, because I know that trafic volume and packet processing could be an answer.
As I first suspected the ISP Box because of DHCP IP range and I didn’t know the zyxel was on the network, I did a try. I connected the laptop to the mikrotik router with wifi. In this way, the mikrotik is the first device to receive the broadcast DHCP request. I was surprised by getting another 192.168.1.0/24 address. I thought it was a sort of caching of my client, I restarted the laptop. Same result
So now everything is fine, we also let the zyxel but only as an wifi acces point without DHCP server. But I still don’t understand how it was possible, mainly when I was connected in wifi. If someone could have a clarification ?
The network is working fine, there are no problems with the ac3? Cannot help, nothing to do with MT help forums.
Try a general networking forum (broadband reports etc).
I didn’t actually test my hypothesis below so take it with a grain of doubt…
So when DHCP client requests a lease (it’s a 4-way handshake) and it previously had interface provisioned via DHCP (and it remembers previous settings), it includes old IP address in initial DHCP discover packet. When DHCP server receives such packet, it can either offer a DHCP lease with indicated address or reject indicated address. In general if there are multiple DHCP servers in some L2 broadcast domain, all will handle DHCP request (obviously with slightly different timing and possibly with different answers) and it’s up to DHCP client to accept answer from any of them. Most of times, when answers are equally acceptable, client accepts response which is received first. But in case that first answer is negative and later answer positive, client is free to use the positive answer.
Mikrotik’s DHCP server has a property, which affects the behaviour:
Option changes the way how a server responds to DHCP requests:
yes - replies to clients request for an address that is not available from this server, DHCP server will send a negative acknowledgment (DHCPNAK);
no - DHCP server ignores clients requests for addresses that are not available from this server;
after-10sec-delay - requests with “secs < 10” will be processed as in “no” setting case and requests with “secs >= 10” will be processed as in “yes” case;
after-2sec-delay - requests with “secs < 2” will be processed as in “no” setting case and requests with “secs >= 2” will be processed as in “yes” case;
The secs mentioned in property description refers to DHCP packet header, description of which is as follows:
In BOOTP this field was vaguely defined and not always used. For DHCP, it is defined as the number of seconds elapsed since a client began an attempt to acquire or renew a lease. This may be used by a busy DHCP server to prioritize replies when multiple client requests are outstanding.
Since default setting of ROS DHCP server is authoritative=yes, it sends DHCPNAK immediately … but it doesn’t help much if there’s still another DHCP server sending ACKs for same requests.
@anav : I did ask someone who is also helping the organization and works with cisco hardware in his daily job. He advised me to ask in mikrotik forum
@mkx : Thank you very much. I expected to learn more about DHCP and you help me to better understand it. The authoritative option is set to yes. Even with that I would say the scenario was not the same. During step 1, the laptop got a lease from the mikrotik DHCP server with 192.168.88.0/24. Based on your explanations, in step 2 the request was sent within this IP range to get the same lease. But I got one from Zyxel on range 192.168.1.0/24.
It is a good use case that remembers me that I also need to mitigate Rogue DHCP server in this network
a DHCP client stores old lease and lease server. The client will renew DHCP with the used DHCP server, before requesting via broadcast.
speed of response on broadcast DHCP discover will depend on the DHCP server software and settings (authorative? , Conflict detection? extra options? invalid IP range? … )
(once a Linksys WRT54G with DHCP server set to off, used as cheap switch, just NACKed all DHCP requests, the Linksys was local the real DHCP server remote (and delayed), all leases were lost)
200meters at 70% of the speed of light in the cable is … µs
According to wikipedia article (which includes quite some details), when acquiring DHCP lease DHCP client always sends packets to broadcast MAC address … even if it includes previously used IP address as optional data (in DHCP discover packet). Same for DHCP request (which acts as “confirmation” step), client also sends it to broadcast address. DHCP server always uses client’s MAC address as destination making it unicast ethernet frame.
Regarding renewal (where client believes it already has valid IP address in current subnet), it may (but doesn’t have to) use unicast IP/UDP communication with DHCP server which issued original lease … and in this case rogue DHCP server usually doesn’t interfere (because it hopefully won’t even receive that unicast traffic).
The problem with rogue DHCP servers, as observed by @liochan, is that they pretend to be authoritative (same as Mikrotik’s default setting) and can interfere with ongoing communication with another DHCP server also in second stage (DHCP Request / DHCP Ack) because client’s packets will reach them.
I changed a network management and configuration by adding a mikrotik HAP ac 3
Regarding renewal (where client believes it already has valid IP address in current subnet), it may (but doesn’t have to) use unicast IP/UDP communication with DHCP server which issued original lease … and in this case rogue DHCP server usually doesn’t interfere (because it hopefully won’t even receive that unicast traffic).
Is the hAP ac3 the rogue here in this case ? As the ISP or Zyxel were the original ones, from before the change. And I understood that even a switched off client keeps its lease stored (registry?) for the lease time assigned.
Hunting for a renewal log may take some time if the lease time is long, as roaming between multiple MT routers on same SSID, same LAN, different AP does not trigger any DHCP action at all.
