DISCOVER with giaddr set, but broadcast
Bernhard Schmidt
berni at birkenwald.de
Wed Mar 20 17:20:37 UTC 2013
Hello everyone,
I'm looking for some advice regarding the legitimacy of a packet. I have
read RFC2131 but I'm not sure who is at fault here.
Following setup
ISC DHCP 4.2 ---- Router1 ---- Router2 ---- Switch ---- PC
Router 2 is a DHCP relay for the VLAN the PC is attached to.
The switch is a HP Procurve 4200vl with the latest firmware (which is a
few years old). In some conditions, which appear to be the following
- DHCP relaying is enabled (factory default), but helper addresses are
not configured
- PC and Management of the switch in the same VLAN
- DHCP-Snooping enabled on the switch FOR OTHER VLANs
The switch sets its management IP in the giaddr field of the DHCP
packet, but then keeps forwarding the packet as broadcast.
This is what the router receives
Ethernet II, Src: Oracle_45:90:3a (00:14:4f:45:90:3a), Dst: Broadcast (ff:ff:ff:ff:ff:ff)
Destination: Broadcast (ff:ff:ff:ff:ff:ff)
Address: Broadcast (ff:ff:ff:ff:ff:ff)
.... ..1. .... .... .... .... = LG bit: Locally administered address (this is NOT the factory default)
.... ...1 .... .... .... .... = IG bit: Group address (multicast/broadcast)
Source: Oracle_45:90:3a (00:14:4f:45:90:3a)
Address: Oracle_45:90:3a (00:14:4f:45:90:3a)
.... ..0. .... .... .... .... = LG bit: Globally unique address (factory default)
.... ...0 .... .... .... .... = IG bit: Individual address (unicast)
Type: IP (0x0800)
Internet Protocol Version 4, Src: 0.0.0.0 (0.0.0.0), Dst: 255.255.255.255 (255.255.255.255)
Version: 4
Header length: 20 bytes
Differentiated Services Field: 0x10 (DSCP 0x04: Unknown DSCP; ECN: 0x00: Not-ECT (Not ECN-Capable Transport))
0001 00.. = Differentiated Services Codepoint: Unknown (0x04)
.... ..00 = Explicit Congestion Notification: Not-ECT (Not ECN-Capable Transport) (0x00)
Total Length: 328
Identification: 0x0000 (0)
Flags: 0x00
0... .... = Reserved bit: Not set
.0.. .... = Don't fragment: Not set
..0. .... = More fragments: Not set
Fragment offset: 0
Time to live: 127
Protocol: UDP (17)
Header checksum: 0x3a96 [correct]
[Good: True]
[Bad: False]
Source: 0.0.0.0 (0.0.0.0)
Destination: 255.255.255.255 (255.255.255.255)
[Source GeoIP: Unknown]
[Destination GeoIP: Unknown]
User Datagram Protocol, Src Port: bootpc (68), Dst Port: bootps (67)
Source port: bootpc (68)
Destination port: bootps (67)
Length: 308
Checksum: 0xa655 [validation disabled]
[Good Checksum: False]
[Bad Checksum: False]
Bootstrap Protocol
Message type: Boot Request (1)
Hardware type: Ethernet
Hardware address length: 6
Hops: 1
Transaction ID: 0x5b2f1a32
Seconds elapsed: 0
Bootp flags: 0x0000 (Unicast)
0... .... .... .... = Broadcast flag: Unicast
.000 0000 0000 0000 = Reserved flags: 0x0000
Client IP address: 0.0.0.0 (0.0.0.0)
Your (client) IP address: 0.0.0.0 (0.0.0.0)
Next server IP address: 0.0.0.0 (0.0.0.0)
Relay agent IP address: 10.10.195.3 (10.10.195.3)
Client MAC address: Oracle_45:90:3a (00:14:4f:45:90:3a)
Client hardware address padding: 00000000000000000000
Server host name not given
Boot file name not given
Magic cookie: DHCP
Option: (53) DHCP Message Type
Length: 1
DHCP: Discover (1)
and so on
As you can see, the giaddr is set, but it is still a link-layer
broadcast.
Is this packet valid according to DHCP specifications?
Reason I'm asking is because since we replaced Router2, which used to be
a Cisco Catalyst 6500, with a Cisco Nexus 7000, the PC would not get
DHCP leases anymore. We debugged this for two weeks with Cisco until
they finally found the root cause ... the set giaddr.
It appears that when giaddr is set, NX-OS does not set its own address
in the user VLAN in giaddr and forwards it to the DHCP server from that
address, but leaves giaddr set to the switch and uses its IP-address on
the egress interface (from R2 to R1, so a transport network).
Interestingly, the packet makes it to the DHCP server, but the server
just ignores it. There is not a single log entry about this packet, and
there is nothing visible with dhcpd -d either.
This is a packet received on the server (sorry, this is from another
location, so it's another client and another server, but the relay agent
is also set to a switch):
Frame 1: 342 bytes on wire (2736 bits), 342 bytes captured (2736 bits)
on interface 0
Interface id: 0
WTAP_ENCAP: 1
Arrival Time: Mar 20, 2013 18:14:36.312891000 CET
[Time shift for this packet: 0.000000000 seconds]
Epoch Time: 1363799676.312891000 seconds
[Time delta from previous captured frame: 0.000000000 seconds]
[Time delta from previous displayed frame: 0.000000000 seconds]
[Time since reference or first frame: 0.000000000 seconds]
Frame Number: 1
Frame Length: 342 bytes (2736 bits)
Capture Length: 342 bytes (2736 bits)
[Frame is marked: False]
[Frame is ignored: False]
[Protocols in frame: eth:ip:udp:bootp]
Ethernet II, Src: Cisco_6e:a2:42 (d8:67:d9:6e:a2:42), Dst: Dell_0b:7d:fc
(f0:4d:a2:0b:7d:fc)
Destination: Dell_0b:7d:fc (f0:4d:a2:0b:7d:fc)
Address: Dell_0b:7d:fc (f0:4d:a2:0b:7d:fc)
.... ..0. .... .... .... .... = LG bit: Globally unique address
(factory default)
.... ...0 .... .... .... .... = IG bit: Individual address
(unicast)
Source: Cisco_6e:a2:42 (d8:67:d9:6e:a2:42)
Address: Cisco_6e:a2:42 (d8:67:d9:6e:a2:42)
.... ..0. .... .... .... .... = LG bit: Globally unique address
(factory default)
.... ...0 .... .... .... .... = IG bit: Individual address
(unicast)
Type: IP (0x0800)
Internet Protocol Version 4, Src: 129.187.9.214 (129.187.9.214), Dst:
10.156.33.130 (10.156.33.130)
Version: 4
Header length: 20 bytes
Differentiated Services Field: 0x10 (DSCP 0x04: Unknown DSCP; ECN:
0x00: Not-ECT (Not ECN-Capable Transport))
0001 00.. = Differentiated Services Codepoint: Unknown (0x04)
.... ..00 = Explicit Congestion Notification: Not-ECT (Not
ECN-Capable Transport) (0x00)
Total Length: 328
Identification: 0x0f00 (3840)
Flags: 0x00
0... .... = Reserved bit: Not set
.0.. .... = Don't fragment: Not set
..0. .... = More fragments: Not set
Fragment offset: 0
Time to live: 127
Protocol: UDP (17)
Header checksum: 0x73e6 [correct]
[Good: True]
[Bad: False]
Source: 129.187.9.214 (129.187.9.214)
Destination: 10.156.33.130 (10.156.33.130)
User Datagram Protocol, Src Port: bootpc (68), Dst Port: bootps (67)
Source port: bootpc (68)
Destination port: bootps (67)
Length: 308
Checksum: 0x3043 [validation disabled]
[Good Checksum: False]
[Bad Checksum: False]
Bootstrap Protocol
Message type: Boot Request (1)
Hardware type: Ethernet
Hardware address length: 6
Hops: 1
Transaction ID: 0x4685a802
Seconds elapsed: 0
Bootp flags: 0x0000 (Unicast)
0... .... .... .... = Broadcast flag: Unicast
.000 0000 0000 0000 = Reserved flags: 0x0000
Client IP address: 0.0.0.0 (0.0.0.0)
Your (client) IP address: 0.0.0.0 (0.0.0.0)
Next server IP address: 0.0.0.0 (0.0.0.0)
Relay agent IP address: 10.10.241.15 (10.10.241.15)
Client MAC address: Oracle_20:3c:54 (00:14:4f:20:3c:54)
Client hardware address padding: 00000000000000000000
Server host name not given
Boot file name not given
Magic cookie: DHCP
Option: (53) DHCP Message Type
Length: 1
DHCP: Discover (1)
Option: (12) Host Name
Length: 8
Host Name: moni-kb1
Option: (55) Parameter Request List
Length: 13
Parameter Request List Item: (1) Subnet Mask
Parameter Request List Item: (28) Broadcast Address
Parameter Request List Item: (2) Time Offset
Parameter Request List Item: (3) Router
Parameter Request List Item: (15) Domain Name
Parameter Request List Item: (6) Domain Name Server
Parameter Request List Item: (119) Domain Search [TODO:RFC3397]
Parameter Request List Item: (12) Host Name
Parameter Request List Item: (44) NetBIOS over TCP/IP Name
Server
Parameter Request List Item: (47) NetBIOS over TCP/IP Scope
Parameter Request List Item: (26) Interface MTU
Parameter Request List Item: (121) Classless Static Route
Parameter Request List Item: (42) Network Time Protocol Servers
Option: (255) End
Option End: 255
Padding
This packet is completely ignored by dhcpd.
Is this packet legal?
Best Regards,
Bernhard
More information about the dhcp-users
mailing list