DHCP-Relay duplicating unicast packets

Fri Sep 11 11:28:07 UTC 2015

Hi,

I have a test network setup with some VLANs. Relevant here are VLANs
181 (Infrastructure) and 185 (Clients). VLAN 181 houses the
DHCP server; the router between the networks runs a DHCP relay. Both
machines are Debian jessie, DHCP server and relay are ISC DHCP 4.3.2.

My test client is an android phone and has MAC address
cc:07:ab:ac:99:7e and IP address 192.168.185.156.

All systems do run IPv6 as well, that's irrelevant here and I have
thus removed the IPv6 addresses.

Router:
|[3/501]mh at barrida:~$ ip addr show dev int181
|9: int181 at eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default
|    link/ether 9a:3d:9f:63:27:ac brd ff:ff:ff:ff:ff:ff
|    inet 192.168.181.254/32 brd 192.168.181.254 scope global int181
|       valid_lft forever preferred_lft forever
|    inet 192.168.181.163/24 brd 192.168.181.255 scope global int181
|       valid_lft forever preferred_lft forever
|[4/502]mh at barrida:~$ ip addr show dev int185
|13: int185 at eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default
|    link/ether fe:fd:22:0f:79:5e brd ff:ff:ff:ff:ff:ff
|    inet 192.168.185.254/24 brd 192.168.185.255 scope global int185
|       valid_lft forever preferred_lft forever
|[5/503]mh at barrida:~$ sudo cat /proc/net/vlan/config
|VLAN Dev name    | VLAN ID
|Name-Type: VLAN_NAME_TYPE_RAW_PLUS_VID_NO_PAD
|int181         | 181  | eth0
|int185         | 185  | eth0
|[16/514]mh at barrida:~$ cat /etc/default/isc-dhcp-relay
|SERVERS="192.168.181.161 192.168.251.9"
|INTERFACES="int181 int182 int183 int184 int185 int186 int187 int188 int189"
|OPTIONS=""

DHCP server:
|[7/505]mh at chasse:~$ ip addr show dev eth0
|2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
|    link/ether 52:54:00:bd:92:b1 brd ff:ff:ff:ff:ff:ff
|    inet 192.168.181.161/24 brd 192.168.181.255 scope global eth0
|       valid_lft forever preferred_lft forever

Client wants to renew its lease and sends an _Unicast_ DHCP REQUEST
directly to the server that had assigned its lease. Here a tcpdump
taken on the router's int185:
|12:35:30.343624 cc:07:ab:ac:99:7e > fe:fd:22:0f:79:5e, ethertype IPv4 (0x0800), length 353: 192.168.185.156.68 > 192.168.181.161.67: BOOTP/DHCP, Request from cc:07:ab:ac:99:7e, length 311
|12:35:30.353324 fe:fd:22:0f:79:5e > cc:07:ab:ac:99:7e, ethertype IPv4 (0x0800), length 372: 192.168.181.161.67 > 192.168.185.156.68: BOOTP/DHCP, Reply, length 330
|12:35:30.353754 fe:fd:22:0f:79:5e > cc:07:ab:ac:99:7e, ethertype IPv4 (0x0800), length 372: 192.168.185.254.67 > 192.168.185.156.68: BOOTP/DHCP, Reply, length 330

The DHCP relay thinks that it should play here and creates two more
instances of the DHCP REQUEST. Here a tcpdump taken on the router's
int181:
|12:35:30.343739 9a:3d:9f:63:27:ac > 52:54:00:bd:92:b1, ethertype IPv4 (0x0800), length 353: 192.168.185.156.68 > 192.168.181.161.67: BOOTP/DHCP, Request from cc:07:ab:ac:99:7e, length 311
|12:35:30.344094 9a:3d:9f:63:27:ac > 52:54:00:bd:92:b1, ethertype IPv4 (0x0800), length 353: 192.168.181.163.67 > 192.168.181.161.67: BOOTP/DHCP, Request from cc:07:ab:ac:99:7e, length 311
|12:35:30.344184 9a:3d:9f:63:27:ac > 52:54:00:bd:92:b1, ethertype IPv4 (0x0800), length 353: 192.168.181.163.67 > 192.168.181.161.67: BOOTP/DHCP, Request from cc:07:ab:ac:99:7e, length 311
|12:35:30.353242 52:54:00:bd:92:b1 > 9a:3d:9f:63:27:ac, ethertype IPv4 (0x0800), length 372: 192.168.181.161.67 > 192.168.185.156.68: BOOTP/DHCP, Reply, length 330
|12:35:30.353502 52:54:00:bd:92:b1 > 9a:3d:9f:63:27:ac, ethertype IPv4 (0x0800), length 372: 192.168.181.161.67 > 192.168.185.254.67: BOOTP/DHCP, Reply, length 330
|12:35:30.353999 52:54:00:bd:92:b1 > 9a:3d:9f:63:27:ac, ethertype IPv4 (0x0800), length 342: 192.168.181.161.67 > 192.168.181.254.67: BOOTP/DHCP, Reply, length 300
|12:35:30.354106 9a:3d:9f:63:27:ac > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 342: 192.168.181.254.67 > 255.255.255.255.68: BOOTP/DHCP, Reply, length 300

The DHCP server itself writes this to its logs:
|Sep 11 12:35:30 chasse dhcpd[767]: Adap-lease: Total: 100, Free: 96, Ends: 156, Adaptive: 300, Fill: 4, Threshold: 80
|Sep 11 12:35:30 chasse dhcpd[767]: DHCPREQUEST for 192.168.185.156 from cc:07:ab:ac:99:7e via eth0
|Sep 11 12:35:30 chasse dhcpd[767]: DHCPACK on 192.168.185.156 to cc:07:ab:ac:99:7e (android-82ac454c2cdff807) via eth0
|Sep 11 12:35:30 chasse dhcpd[767]: Adap-lease: Total: 100, Free: 96, Ends: 300, Adaptive: 300, Fill: 4, Threshold: 80
|Sep 11 12:35:30 chasse dhcpd[767]: reuse_lease: lease age 0 (secs) under 25% threshold, reply with unaltered, existing lease
|Sep 11 12:35:30 chasse dhcpd[767]: DHCPREQUEST for 192.168.185.156 from cc:07:ab:ac:99:7e (android-82ac454c2cdff807) via 192.168.185.254
|Sep 11 12:35:30 chasse dhcpd[767]: DHCPACK on 192.168.185.156 to cc:07:ab:ac:99:7e via 192.168.185.254
|Sep 11 12:35:30 chasse dhcpd[767]: DHCPREQUEST for 192.168.185.156 from cc:07:ab:ac:99:7e via 192.168.181.254: wrong network.
|Sep 11 12:35:30 chasse dhcpd[767]: DHCPNAK on 192.168.185.156 to cc:07:ab:ac:99:7e via 192.168.181.254

I am now wondering why the DHCP relay does act on those Unicast packets
in the first place. Is it supposed to? Why does it? Why does it send
the DHCP request out twice? And what does the dhcpd mean with "wrong
network" in response to the DHCPREQUEST sent out by the relay with the
relay agent address set to the relay's int181 address?

Any hints will be appreciated.

Greetings
Marc

-- 
-----------------------------------------------------------------------------
Marc Haber         | "I don't trust Computers. They | Mailadresse im Header
Leimen, Germany    |  lose things."    Winona Ryder | Fon: *49 6224 1600402
Nordisch by Nature |  How to make an American Quilt | Fax: *49 6224 1600421