Cisco DHCP Snooping With Mikrotik Version 6
I’ve written an extensive article here about Layer 2 protection on wired networks. I would reference this first for full details. In a nutshell DHCP snooping prevents a user from acting as a rogue DHCP server. It also builds a binding table that can be used with ARP inspection to prevent man in the middle attacks.
The way it works is your client requests an IP via DHCP, then the switch records the information as the offer returns to you…simples…or is it?
Cisco 3550/3560 switches by default create and send option 82 with your DHCP request. There are a couple of good articles on it here and here.
Option 82 sends back additional information relating to the clients “physical attachment” to the network. It is usually seen in relation to DHCP relaying to help the server determine where the client was sourced from to know which ip pool to allocate an address from. There is a field called the “giaddr” field that is passed along, which is used to determine where the request came from. By default the 3550/3560 sets the giaddr field to 0 when snooping is enabled.
Mikrotik made some change to the DHCP server implementation in version 6, which has an odd effect. When the MTK DHCP server see’s option 82 come in and the giaddr is set to 0 it will send back a DHCP offer packet that does NOT contain a default gateway or subnet mask. So in effect your clients will NEVER WORK!!!!!
Packet capture from a normal DHCP offer.
Packet capture from a 3550 with standard snooping.
Oh muh gurrrd…whuut dew weee dewwwwww?!?! We can actually issue a simple command on the switch that will fix everything:
1 | no ip dhcp snooping information option |
This simple command disables the default option 82 behavior of the switch, and just passes on a standard DHCP request. The Mikrotik V6 DHCP server sees the standard request and passes back a standard DHCP offer…and everything works as it should.
I don’t want to even mention the couple of hours of work it took me to figure this one out. No amount of googling provided the answer. It took several wireshark packet captures to get me on the correct track, and then some good old fashioned experimentation to close the circle.
Have fun and happy routing(or switching as the case may be). 😉