Cat 6500 DHCP relaying broadcast problem

Mate Grbavac · ‎12-27-2012

Hi,

I have very strange problem with Cat. 6500 running s72033-advipservicesk9_wan-mz.122-33.SXI9.bin on WS-SUP720-3B.

I have L3 interface attached to L2 network. L3 interface is configured with dhcp relaying. When client sends dhcp discover or request, Cat. 6500 forward unicast packets to configured dhcp servers. DHCP server unicasts back reply to Cat. 6500 and now problems starts. Cat. 6500 forwards dhcp reply to client with broadcast and that is bad, it's need to be unicast. We made capture with wireshark and saw that cliet in dhcp packet set broadcast flag to unicast and server too and that is correct.

Have anybody idea what could be problem?

This is L3 interface configuration:

interface GigabitEthernet4/15

mac-address 001f.caf9.7182

mtu 9216

ip vrf forwarding iptv

ip address 10.215.0.2 255.255.0.0

ip helper-address 10.10.19.252

ip helper-address 10.10.19.251

ip mtu 1500

load-interval 30

speed nonegotiate

standby use-bia

standby version 2

standby 215 ip 10.215.0.1

standby 215 preempt

standby 215 authentication md5 key-string 7 08087C7B3F1628245F313B477

Debug shows that 6500 sends packets to client by broadcast.

Dec 12 15:36:32.738 CET: DHCPD: setting giaddr to 10.208.0.3.

Dec 12 15:36:32.738 CET: DHCPD: BOOTREQUEST from fe00.3b1c.012c forwarded to 10.10.10.252.

Dec 12 15:36:32.738 CET: DHCPD: BOOTREQUEST from fe00.3b1c.012c forwarded to 10.10.10.251.

Dec 12 15:36:32.746 CET: dhcp_snooping_get_ingress_port: Interface src_index 0x341

Dec 12 15:36:32.746 CET: DHCPD: forwarding BOOTREPLY to client fe00.3b1c.012c.

Dec 12 15:36:32.746 CET: DHCPD: broadcasting BOOTREPLY to client fe00.3b1c.012c.

Dec 12 15:36:32.798 CET: dhcp_snooping_get_ingress_port: Interface src_index 0xD0

Dec 12 15:36:32.798 CET: DHCPD: setting giaddr to 10.208.0.3.

Dec 12 15:36:32.798 CET: DHCPD: BOOTREQUEST from fe00.3b1c.012c forwarded to 10.10.10.252.

Dec 12 15:36:32.798 CET: DHCPD: BOOTREQUEST from fe00.3b1c.012c forwarded to 10.10.10.251.

Dec 12 15:36:32.810 CET: dhcp_snooping_get_ingress_port: Interface src_index 0x341

Dec 12 15:36:32.810 CET: DHCPD: forwarding BOOTREPLY to client fe00.3b1c.012c.

Dec 12 15:36:32.810 CET: DHCPD: broadcasting BOOTREPLY to client fe00.3b1c.012c.

Dec 12 15:36:32.862 CET: dhcp_snooping_get_ingress_port: Interface src_index 0xD0

Dec 12 15:36:32.862 CET: DHCPD: setting giaddr to 10.208.0.3.

Dec 12 15:36:32.862 CET: DHCPD: BOOTREQUEST from fe00.3b1c.012c forwarded to 10.10.10.252.

Dec 12 15:36:32.862 CET: DHCPD: BOOTREQUEST from fe00.3b1c.012c forwarded to 10.10.10.251.

Dec 12 15:36:32.874 CET: dhcp_snooping_get_ingress_port: Interface src_index 0x341

Dec 12 15:36:32.874 CET: DHCPD: forwarding BOOTREPLY to client fe00.3b1c.012c.

Dec 12 15:36:32.874 CET: DHCPD: broadcasting BOOTREPLY to client fe00.3b1c.012c.

Dec 12 15:36:32.882 CET: dhcp_snooping_get_ingress_port: Interface src_index 0xD0

Dec 12 15:36:32.886 CET: DHCPD: setting giaddr to 10.208.0.3.

Dec 12 15:36:32.886 CET: DHCPD: BOOTREQUEST from fe00.5214.0374 forwarded to 10.10.10.252.

Dec 12 15:36:32.886 CET: DHCPD: BOOTREQUEST from fe00.5214.0374 forwarded to 10.10.10.251.

Dec 12 15:36:32.890 CET: dhcp_snooping_get_ingress_port: Interface src_index 0x87

Dec 12 15:36:32.890 CET: DHCPD: forwarding BOOTREPLY to client fe00.5214.0374.

Dec 12 15:36:32.890 CET: DHCPD: creating ARP entry (10.208.2.169, fe00.5214.0374).

Dec 12 15:36:32.890 CET: DHCPD: unicasting BOOTREPLY to client fe00.5214.0374 (10.208.2.169).

Dec 12 15:36:32.894 CET: dhcp_snooping_get_ingress_port: Interface src_index 0x341

Dec 12 15:36:32.894 CET: DHCPD: forwarding BOOTREPLY to client fe00.5214.0374.

Dec 12 15:36:32.894 CET: DHCPD: creating ARP entry (10.208.2.169, fe00.5214.0374).

Dec 12 15:36:32.894 CET: DHCPD: unicasting BOOTREPLY to client fe00.5214.0374 (10.208.2.169).

Dec 12 15:36:32.918 CET: dhcp_snooping_get_ingress_port: Interface src_index 0xD0

Dec 12 15:36:32.918 CET: DHCPD: setting giaddr to 10.208.0.3. Dec 12 15:36:32.738 CET: DHCPD: setting giaddr to 10.208.0.3.
Dec 12 15:36:32.738 CET: DHCPD: BOOTREQUEST from fe00.3b1c.012c forwarded to 10.10.10.252.
Dec 12 15:36:32.738 CET: DHCPD: BOOTREQUEST from fe00.3b1c.012c forwarded to 10.10.10.251.
Dec 12 15:36:32.746 CET: dhcp_snooping_get_ingress_port: Interface src_index 0x341
Dec 12 15:36:32.746 CET: DHCPD: forwarding BOOTREPLY to client fe00.3b1c.012c.
Dec 12 15:36:32.746 CET: DHCPD: broadcasting BOOTREPLY to client fe00.3b1c.012c.
Dec 12 15:36:32.798 CET: dhcp_snooping_get_ingress_port: Interface src_index 0xD0
Dec 12 15:36:32.798 CET: DHCPD: setting giaddr to 10.208.0.3.
Dec 12 15:36:32.798 CET: DHCPD: BOOTREQUEST from fe00.3b1c.012c forwarded to 10.10.10.252.
Dec 12 15:36:32.798 CET: DHCPD: BOOTREQUEST from fe00.3b1c.012c forwarded to 10.10.10.251.
Dec 12 15:36:32.810 CET: dhcp_snooping_get_ingress_port: Interface src_index 0x341
Dec 12 15:36:32.810 CET: DHCPD: forwarding BOOTREPLY to client fe00.3b1c.012c.
Dec 12 15:36:32.810 CET: DHCPD: broadcasting BOOTREPLY to client fe00.3b1c.012c.
Dec 12 15:36:32.862 CET: dhcp_snooping_get_ingress_port: Interface src_index 0xD0
Dec 12 15:36:32.862 CET: DHCPD: setting giaddr to 10.208.0.3.
Dec 12 15:36:32.862 CET: DHCPD: BOOTREQUEST from fe00.3b1c.012c forwarded to 10.10.10.252.
Dec 12 15:36:32.862 CET: DHCPD: BOOTREQUEST from fe00.3b1c.012c forwarded to 10.10.10.251.
Dec 12 15:36:32.874 CET: dhcp_snooping_get_ingress_port: Interface src_index 0x341
Dec 12 15:36:32.874 CET: DHCPD: forwarding BOOTREPLY to client fe00.3b1c.012c.
Dec 12 15:36:32.874 CET: DHCPD: broadcasting BOOTREPLY to client fe00.3b1c.012c.
Dec 12 15:36:32.882 CET: dhcp_snooping_get_ingress_port: Interface src_index 0xD0
Dec 12 15:36:32.886 CET: DHCPD: setting giaddr to 10.208.0.3.
Dec 12 15:36:32.886 CET: DHCPD: BOOTREQUEST from fe00.5214.0374 forwarded to 10.10.10.252.
Dec 12 15:36:32.886 CET: DHCPD: BOOTREQUEST from fe00.5214.0374 forwarded to 10.10.10.251.
Dec 12 15:36:32.890 CET: dhcp_snooping_get_ingress_port: Interface src_index 0x87
Dec 12 15:36:32.890 CET: DHCPD: forwarding BOOTREPLY to client fe00.5214.0374.
Dec 12 15:36:32.890 CET: DHCPD: creating ARP entry (10.208.2.169, fe00.5214.0374).
Dec 12 15:36:32.890 CET: DHCPD: unicasting BOOTREPLY to client fe00.5214.0374 (10.208.2.169).
Dec 12 15:36:32.894 CET: dhcp_snooping_get_ingress_port: Interface src_index 0x341
Dec 12 15:36:32.894 CET: DHCPD: forwarding BOOTREPLY to client fe00.5214.0374.
Dec 12 15:36:32.894 CET: DHCPD: creating ARP entry (10.208.2.169, fe00.5214.0374).
Dec 12 15:36:32.894 CET: DHCPD: unicasting BOOTREPLY to client fe00.5214.0374 (10.208.2.169).
Dec 12 15:36:32.918 CET: dhcp_snooping_get_ingress_port: Interface src_index 0xD0
Dec 12 15:36:32.918 CET: DHCPD: setting giaddr to 10.208.0.3.

Best regards, M

Edison Ortiz · ‎12-27-2012

It seems to be happening only to that device.

Here is an entry where the BOOTREPLY is unicast

Dec 12 15:36:32.890 CET: DHCPD: forwarding BOOTREPLY to client fe00.5214.0374.

Dec 12 15:36:32.890 CET: DHCPD: creating ARP entry (10.208.2.169, fe00.5214.0374).

Dec 12 15:36:32.890 CET: DHCPD: unicasting BOOTREPLY to client fe00.5214.0374 (10.208.2.169).

If the 6500 is unable to create and ARP entry, then the reply will be broadcasted due to missing unicast address.

Mate Grbavac · ‎12-27-2012

Hi Edison,

thank you for reply.

It's not happening only for that device. This is very short log, it's happening for many devices. I saw Wireshark capture in wich is visible that 6500 broadcasts pakets to client even despite the fact that broadcast flag is not set in DHCP packet sent by DHCP server or client.

What do you think, from wich reason could be 6500 unable to create ARP entry?

P.S. In previous post I putted wrong interface configuration, coreect interface is:

interface Vlan3994

ip vrf forwarding iptv

ip address 10.208.0.3 255.255.0.0

ip helper-address 10.10.10.252

ip helper-address 10.10.10.251

load-interval 30

standby version 2

standby 1 ip 10.208.0.1

standby 1 preempt

standby 1 authentication md5 key-string 7 00324157577D5C5E3C640D

Edison Ortiz · ‎12-27-2012

Verify the affected devices are actually getting an IP address.

Without an IP address, the switch can't unicast packets.

Mate Grbavac · ‎12-27-2012

Yes, devices are getting IP addresses correctly.

Sent from Cisco Technical Support iPhone App

Edison Ortiz · ‎12-27-2012

No idea why is doing it selectively. Best to open a TAC case

Mate Grbavac · ‎12-28-2012

After further investigation with wireshark I can conclude that 6500 broadcasts only DHCP NAK packetes, other packets are sent O.K.

Probably I will contact TAC.

Rolf Fischer · ‎12-28-2012

That's strange. According to RFC 2131, a relay agent should unicast DHCPNAKs:

"If 'giaddr' is 0x0 in the DHCPREQUEST message, the client is on
the same subnet as the server. The server MUST
broadcast the DHCPNAK message to the 0xffffffff broadcast address
because the client may not have a correct network address or subnet
mask, and the client may not be answering ARP requests.
Otherwise, the server MUST send the DHCPNAK message to the IP
address of the BOOTP relay agent, as recorded in 'giaddr'. The
relay agent will, in turn, forward the message directly to the
client's hardware address, so that the DHCPNAK can be delivered even

if the client has moved to a new network."

Maybe you really should open a case.

Regards,

Rolf

atef yamin · ‎12-28-2012

The dhcpnak messages are responses to dhcprequests. The main question here is what do the flags on dhcprequest packets look like.

If the client decides to set the BROADCAST flag on the dhcprequest packets to '1', which specifies to servers and relay agents to reply as Broadcast then your relay agent will reply back as Broadcast.

So let us know what do the dhcprequests look like and then we will go from there.

HTH

Mate Grbavac · ‎12-29-2012

As I wrote in first post, client does not set broadcast flag in request.

DHCP relayer (6500) correctly put's it's LAN address in giaddr field and forward packet by unicast to server.

All packets sent by server 6500 forwards to client by unicast except NAK.

Sent from Cisco Technical Support iPhone App