DHCP/BOOTPS Broadcast

RouterOS General
1

Hi, one of my Local IX telling me that they receiving DHCP broadcast from our Mac Address. We are using CCR1036-8G-2S+. Bellow is the log sending from the Local IX NOC.

13:36:14.875519 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from XX:XX:XX:XX:XX:XX (oui Unknown), length 300
13:36:15.878888 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from XX:XX:XX:XX:XX:XX (oui Unknown), length 300
13:36:16.878715 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from XX:XX:XX:XX:XX:XX (oui Unknown), length 300
13:36:17.878123 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from XX:XX:XX:XX:XX:XX (oui Unknown), length 300
13:36:18.877802 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from XX:XX:XX:XX:XX:XX (oui Unknown), length 300
13:36:19.885206 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from XX:XX:XX:XX:XX:XX (oui Unknown), length 300
13:36:20.875964 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from XX:XX:XX:XX:XX:XX (oui Unknown), length 300
13:36:21.883990 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from XX:XX:XX:XX:XX:XX (oui Unknown), length 300
13:36:22.878591 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from XX:XX:XX:XX:XX:XX (oui Unknown), length 300

Does anyone has any advice how to prevent this? Cause we dont have any DHCP active in our router and we checked nothing comes up… Please advice…

2

Do I understand you right that you have already checked on the device connected to the IX whether it really sends these packets (no matter from where they actually come)?

/tool sniffer quick port=67 interface=the-interface-connected-to-ix

Because you can only take an effective action at your end if the traffic is really coming from you. Not knowing the topology of the interconnect, it is well possible that some other device is sending that traffic, forging your device’s MAC address.

3

This is what I captured…

sfp-sfpplus1 29.498 171 → 64:D1:54:XX:XX:XX FF:FF:FF:FF:FF:FF 2573 0.0.0.0:68 (bootpc)
sfp-sfpplus1 29.597 172 → 64:D1:54:XX:XX:XX FF:FF:FF:FF:FF:FF 559 0.0.0.0:68 (bootpc)
sfp-sfpplus1 29.918 173 → 64:D1:54:XX:XX:XX FF:FF:FF:FF:FF:FF 1950 0.0.0.0:68 (bootpc)
sfp-sfpplus1 30.197 174 → 64:D1:54:XX:XX:XX FF:FF:FF:FF:FF:FF 0.0.0.0:68 (bootpc)
sfp-sfpplus1 30.466 175 ← 0C:C4:7A:08:26:1D FF:FF:FF:FF:FF:FF 2573 0.0.0.0:68 (bootpc)
sfp-sfpplus1 30.502 176 → 64:D1:54:XX:XX:XX FF:FF:FF:FF:FF:FF 2573 0.0.0.0:68 (bootpc)
sfp-sfpplus1 30.602 177 → 64:D1:54:XX:XX:XX FF:FF:FF:FF:FF:FF 559 0.0.0.0:68 (bootpc)
sfp-sfpplus1 30.873 178 → 64:D1:54:XX:XX:XX FF:FF:FF:FF:FF:FF 2195 0.0.0.0:68 (bootpc)
sfp-sfpplus1 30.918 179 → 64:D1:54:XX:XX:XX FF:FF:FF:FF:FF:FF 1950 0.0.0.0:68 (bootpc)
sfp-sfpplus1 31.179 180 → 64:D1:54:XX:XX:XX FF:FF:FF:FF:FF:FF 0.0.0.0:68 (bootpc)
sfp-sfpplus1 31.501 181 → 64:D1:54:XX:XX:XX FF:FF:FF:FF:FF:FF 2573 0.0.0.0:68 (bootpc)
sfp-sfpplus1 31.719 182 → 64:D1:54:XX:XX:XX FF:FF:FF:FF:FF:FF 796 0.0.0.0:68 (bootpc)
sfp-sfpplus1 31.853 183 → 64:D1:54:XX:XX:XX FF:FF:FF:FF:FF:FF 2195 0.0.0.0:68 (bootpc)
sfp-sfpplus1 32.173 184 → 64:D1:54:XX:XX:XX FF:FF:FF:FF:FF:FF 0.0.0.0:68 (bootpc)
sfp-sfpplus1 32.283 185 → 64:D1:54:XX:XX:XX 34:17:EB:2E:16:00 2195 103.152.XXX.XXX:67 (bootps)
sfp-sfpplus1 32.493 186 → 64:D1:54:XX:XX:XX FF:FF:FF:FF:FF:FF 2573 0.0.0.0:68 (bootpc)
sfp-sfpplus1 32.856 187 → 64:D1:54:XX:XX:XX FF:FF:FF:FF:FF:FF 2195 0.0.0.0:68 (bootpc)
sfp-sfpplus1 32.905 188 → 64:D1:54:XX:XX:XX FF:FF:FF:FF:FF:FF 1950 0.0.0.0:68 (bootpc)
sfp-sfpplus1 33.73 189 → 64:D1:54:XX:XX:XX FF:FF:FF:FF:FF:FF 796 0.0.0.0:68 (bootpc)
sfp-sfpplus1 33.857 190 → 64:D1:54:XX:XX:XX FF:FF:FF:FF:FF:FF 2195 0.0.0.0:68 (bootpc)

4

Is 64:D1:54:XX:XX:XX the MAC address the IX peer claims? Is it one of own MAC addresses of your device on which you took the capture?

5

Yes, the IX claims received DHCP broadcast from that MAC. And that is our MAC Address which used connect to IX BGP Session.

6

I can see there are multiple VLANs in use on that link, and some of the requests go also without a VLAN ID, so it seems as if there were multiple /ip dhcp-client items enabled on your device.

So now we know that the requests are really leaving through sfp-sfpplus1 and with own address of the sending device. But if sfp-sfpplus1 is a member port of a bridge, they can still be coming from somewhere else and just forwarded by your device, which may src-nat the MAC address.

So if you are bullet-proof that no /ip dhcp-client row exists on that device itself, run
/tool sniffer set file-name=dhcp-rq.pcap
and then run the previous /tool sniffer quick … again until you gather some data; then break the sniffer, download the file, and check using Wireshark whether the client-id field in those DHCPDISCOVER requests contains the same MAC address (prefixed with 0x1) like the source MAC address of the Ethernet frame carrying them or something else (some other MAC address, a hostname or some other text…).

If something else, what does /interface bridge nat export show?
And what does /ip dhcp-relay export show?

7

Nothing… It only shows the CCR type, system id and serial number

So if you are bullet-proof that no /ip dhcp-client row exists on that device itself, run
/tool sniffer set file-name=dhcp-rq.pcap
and then run the previous /tool sniffer quick … again until you gather some data; then break the sniffer, download the file, and check using Wireshark whether the client-id field in those DHCPDISCOVER requests contains the same MAC address (prefixed with 0x1) like the source MAC address of the Ethernet frame carrying them or something else (some other MAC address, a hostname or some other text…).

Will let you once data is available. Thanks for helping…

8

The data I collect looks like this… Any advice?


No. Time Source Destination Protocol Length Info
1 0.000000 0.0.0.0 255.255.255.255 DHCP 346 DHCP Discover - Transaction ID 0xb5b0a8c0[Malformed Packet]

Frame 1: 346 bytes on wire (2768 bits), 346 bytes captured (2768 bits)
Ethernet II, Src: Routerbo_XX:XX:XX (64:d1:XX:XX:XX:XX), Dst: Broadcast (ff:ff:ff:ff:ff:ff)
802.1Q Virtual LAN, PRI: 0, DEI: 0, ID: 2573
Internet Protocol Version 4, Src: 0.0.0.0, Dst: 255.255.255.255
User Datagram Protocol, Src Port: 68, Dst Port: 67
Dynamic Host Configuration Protocol (Discover)
[Malformed Packet: DHCP/BOOTP]

No. Time Source Destination Protocol Length Info
2 0.045140 0.0.0.0 255.255.255.255 DHCP 346 DHCP Discover - Transaction ID 0x955f6a91[Malformed Packet]

Frame 2: 346 bytes on wire (2768 bits), 346 bytes captured (2768 bits)
Ethernet II, Src: Routerbo_XX:XX:XX (64:d1:XX:XX:XX:XX), Dst: Broadcast (ff:ff:ff:ff:ff:ff)
802.1Q Virtual LAN, PRI: 0, DEI: 0, ID: 559
Internet Protocol Version 4, Src: 0.0.0.0, Dst: 255.255.255.255
User Datagram Protocol, Src Port: 68, Dst Port: 67
Dynamic Host Configuration Protocol (Discover)
[Malformed Packet: DHCP/BOOTP]

No. Time Source Destination Protocol Length Info
3 0.366790 0.0.0.0 255.255.255.255 DHCP 346 DHCP Discover - Transaction ID 0xf269d844[Malformed Packet]

Frame 3: 346 bytes on wire (2768 bits), 346 bytes captured (2768 bits)
Ethernet II, Src: Routerbo_XX:XX:XX (64:d1:XX:XX:XX:XX), Dst: Broadcast (ff:ff:ff:ff:ff:ff)
802.1Q Virtual LAN, PRI: 0, DEI: 0, ID: 796
Internet Protocol Version 4, Src: 0.0.0.0, Dst: 255.255.255.255
User Datagram Protocol, Src Port: 68, Dst Port: 67
Dynamic Host Configuration Protocol (Discover)
[Malformed Packet: DHCP/BOOTP]

No. Time Source Destination Protocol Length Info
4 0.595222 0.0.0.0 255.255.255.255 DHCP 346 DHCP Discover - Transaction ID 0xb9502b6[Malformed Packet]

Frame 4: 346 bytes on wire (2768 bits), 346 bytes captured (2768 bits)
Ethernet II, Src: Routerbo_XX:XX:XX (64:d1:XX:XX:XX:XX), Dst: Broadcast (ff:ff:ff:ff:ff:ff)
802.1Q Virtual LAN, PRI: 0, DEI: 0, ID: 2195
Internet Protocol Version 4, Src: 0.0.0.0, Dst: 255.255.255.255
User Datagram Protocol, Src Port: 68, Dst Port: 67
Dynamic Host Configuration Protocol (Discover)
[Malformed Packet: DHCP/BOOTP]

No. Time Source Destination Protocol Length Info
5 0.659574 0.0.0.0 255.255.255.255 DHCP 346 DHCP Discover - Transaction ID 0x52db984a[Malformed Packet]

Frame 5: 346 bytes on wire (2768 bits), 346 bytes captured (2768 bits)
Ethernet II, Src: Routerbo_XX:XX:XX (64:d1:XX:XX:XX:XX), Dst: Broadcast (ff:ff:ff:ff:ff:ff)
802.1Q Virtual LAN, PRI: 0, DEI: 0, ID: 1950
Internet Protocol Version 4, Src: 0.0.0.0, Dst: 255.255.255.255
User Datagram Protocol, Src Port: 68, Dst Port: 67
Dynamic Host Configuration Protocol (Discover)
[Malformed Packet: DHCP/BOOTP]

No. Time Source Destination Protocol Length Info
6 0.749196 0.0.0.0 255.255.255.255 DHCP 342 DHCP Discover - Transaction ID 0x4f37e3b1[Malformed Packet]

Frame 6: 342 bytes on wire (2736 bits), 342 bytes captured (2736 bits)
Ethernet II, Src: Routerbo_XX:XX:XX (64:d1:XX:XX:XX:XX), Dst: Broadcast (ff:ff:ff:ff:ff:ff)
Internet Protocol Version 4, Src: 0.0.0.0, Dst: 255.255.255.255
User Datagram Protocol, Src Port: 68, Dst Port: 67
Dynamic Host Configuration Protocol (Discover)
[Malformed Packet: DHCP/BOOTP]

No. Time Source Destination Protocol Length Info
7 1.010377 0.0.0.0 255.255.255.255 DHCP 346 DHCP Discover - Transaction ID 0xab47aee4[Malformed Packet]

Frame 7: 346 bytes on wire (2768 bits), 346 bytes captured (2768 bits)
Ethernet II, Src: Routerbo_XX:XX:XX (64:d1:XX:XX:XX:XX), Dst: Broadcast (ff:ff:ff:ff:ff:ff)
802.1Q Virtual LAN, PRI: 0, DEI: 0, ID: 2573
Internet Protocol Version 4, Src: 0.0.0.0, Dst: 255.255.255.255
User Datagram Protocol, Src Port: 68, Dst Port: 67
Dynamic Host Configuration Protocol (Discover)
[Malformed Packet: DHCP/BOOTP]

No. Time Source Destination Protocol Length Info
8 1.044805 0.0.0.0 255.255.255.255 DHCP 346 DHCP Discover - Transaction ID 0x8605328b[Malformed Packet]

Frame 8: 346 bytes on wire (2768 bits), 346 bytes captured (2768 bits)
Ethernet II, Src: Routerbo_XX:XX:XX (64:d1:XX:XX:XX:XX), Dst: Broadcast (ff:ff:ff:ff:ff:ff)
802.1Q Virtual LAN, PRI: 0, DEI: 0, ID: 559
Internet Protocol Version 4, Src: 0.0.0.0, Dst: 255.255.255.255
User Datagram Protocol, Src Port: 68, Dst Port: 67
Dynamic Host Configuration Protocol (Discover)
[Malformed Packet: DHCP/BOOTP]

No. Time Source Destination Protocol Length Info
9 1.368744 0.0.0.0 255.255.255.255 DHCP 346 DHCP Discover - Transaction ID 0x995201f9[Malformed Packet]

Frame 9: 346 bytes on wire (2768 bits), 346 bytes captured (2768 bits)
Ethernet II, Src: Routerbo_XX:XX:XX (64:d1:XX:XX:XX:XX), Dst: Broadcast (ff:ff:ff:ff:ff:ff)
802.1Q Virtual LAN, PRI: 0, DEI: 0, ID: 796
Internet Protocol Version 4, Src: 0.0.0.0, Dst: 255.255.255.255
User Datagram Protocol, Src Port: 68, Dst Port: 67
Dynamic Host Configuration Protocol (Discover)
[Malformed Packet: DHCP/BOOTP]

No. Time Source Destination Protocol Length Info
10 1.602472 0.0.0.0 255.255.255.255 DHCP 346 DHCP Discover - Transaction ID 0x10bee565[Malformed Packet]

Frame 10: 346 bytes on wire (2768 bits), 346 bytes captured (2768 bits)
Ethernet II, Src: Routerbo_XX:XX:XX (64:d1:XX:XX:XX:XX), Dst: Broadcast (ff:ff:ff:ff:ff:ff)
802.1Q Virtual LAN, PRI: 0, DEI: 0, ID: 2195
Internet Protocol Version 4, Src: 0.0.0.0, Dst: 255.255.255.255
User Datagram Protocol, Src Port: 68, Dst Port: 67
Dynamic Host Configuration Protocol (Discover)
[Malformed Packet: DHCP/BOOTP]

9

Since the transaction ID is shown, dissection of the DHCP part must have succeeded at least partially although a malformed packet is reported, so open any of these packets in Wireshark (GUI) rather than tshark, unfold the DHCP dissection and find the client-id.

No dhcp-relay configured on the machine? If not, is the sfp-sfpplus1 bridged with any other interfaces (physical or virtual)?

10

Sorry I really dont have any idea reading the output from this wireshark data. So I attached for your review. Hope you can help…

No dhcp-relay configured on the machine? If not, is the sfp-sfpplus1 bridged with any other interfaces (physical or virtual)?

Defenately not… No DHCP Relay configure in any of our router and we dont have bridged configure in our CCR.

2a.png
2a.png1052×935 36 KB

1a.png
1a.png812×940 34.9 KB

11

On the second screenshot, closer to the bottom, there is Option 61 - Client identifier. It says “Hardware type: ethernet, Client MAC address: Routerbo…”. Plus slightly above, there is Option 55 - Parameter Request List, which contains item 138 - CAPWAP Access Controllers, and Option 121 - Classless Static Route. This combination of requested items is quite distinctive, albeit not completely unique, for DHCP requests sent by Mikrotik devices.

So if the MAC address in this item exactly matches the one on the Ethernet II → Source row close to the top of the first screenshot (you have hidden both), the DHCP Discover packets are sent by this Mikrotik - since there is no bridge and no DHCP relay, there is no way how they could come from outside.

So what does /ip dhcp-client export and /ip dhcp-client print on that CCR show?

Could it be that you normally use Winbox or WebFig with “skins” (or someone experimented with them in the past at least) and access to DHCP client configuration is hidden on the GUIs for the user name you use to log in?

And what is the RouterOS version? If the skin assumption is wrong, the /ip dhcp-client section of configuration is empty, and the RouterOS is reasonably up-to-date, I’d recommend to create supout.rif and open a support ticket with Mikrotik, as it would indicate a difference between the actual configuration and the one presented to the administrator.

12

Nothing shows up when I run those command. Thank you very much for advice… I will try to open ticket to support.

Screenshot 2021-02-26 192137.png
Screenshot 2021-02-26 192137.png1081×154 11.1 KB

13

Created Support Ticket on 5 days ago with Ticket # SUP-43015 and till now no one respond to my ticket… SO SAD!

14

PROBLEM SOLVED. Enabling “DETECT INTERNET” in Interface is causing the issue. You only need to Disable it…

15

That’s why posting complete configuration exports is always recommended.

The “detect internet” function causes many different surprises, but as I find nothing useful in it (like other users on this forum), I constantly forget about its existence. So if I could spot it in the configuration export, I’d probably suggest to switch it off, but it didn’t come to my mind without that impulse.

16

Hi,
The same issue was reported by my IX too…
Thanx for your post, il helped me!!