This article explains the reason for distributed denial of service (DDoS) violation syslogs with the message 'protocol/exception DHCPv4:bad-packets exceeded its allowed bandwidth.'
'protocol/exception DHCPv4:bad-packets exceeded its allowed bandwidth.'
The following syslog message was reported periodically for the FPC:
Jul 10 10:19:21 router jddosd[8808]: DDOS_PROTOCOL_VIOLATION_SET: Warning: Host-bound traffic for protocol/exception DHCPv4:bad-packets exceeded its allowed bandwidth at fpc 0 for 1 times, started at 2020-07-10 10:19:21 CST user@router> show ddos-protection protocols violations Packet types: 227, Currently violated: 1 Protocol Packet Bandwidth Arrival Peak Policer bandwidth group type (pps) rate(pps) rate(pps) violation detected at dhcpv4 bad-pack.. 0 0 10 2020-07-10 11:24:20 CST Detected on: FPC-0
If SCFD (flow detection) was enabled as described in KB29408 - [MX/T] Configuring ddos-protection flow-detection to log interface and source address information [juniper.net] , you can also find the following log:
Jul 10 10:55:46 router jddosd[8808]: DDOS_SCFD_FLOW_AGGREGATED: Flows of protocol DHCPv4:bad-packets on slot fpc 0 are aggregated to subscriber, logical- interface, physical-interface level(s) Jul 10 10:55:56 router jddosd[8808]: DDOS_SCFD_FLOW_FOUND: A new flow of protocol DHCPv4:bad-packets on xe-0/2/0 with source addr -- -- -- is found at 2020-07-10 10:55:46 CST
The following command output checks currently detected DDoS flows:
user@router> show ddos-protection protocols culprit-flows Currently tracked flows: 1, Total detected flows: 4 Protocol Packet Arriving Source Address group type Interface MAC or IP dhcpv4 bad-pack.. xe-0/2/0 -- -- -- <--- dhcpv4 bad-packet comes from interface xe-0/2/0 ifd:0000000000000031 2020-07-10 11:25:06 CST pps:1 pkts:166
If the system received any DHCPV4 message which DHCP message type option length is “NOT” 1, this DHCP message is a bad packet. The packet will be discarded by default.
This type ddos-protection bandwidth is 0 pps, which means once the system receives this message, DDoS violation is triggered.
Note: The ddos-protection protocols bandwidth can be modified. To find the default value currently set, use the following command:
user@router> show ddos-protection protocols dhcpv4 bad-packets Currently tracked flows: 1, Total detected flows: 4 * = User configured value Protocol Group: DHCPv4 Packet type: bad-packets (DHCPv4 traffic with bad format) Individual policer configuration: Bandwidth: 0 pps Burst: 0 packets <-- Default value Priority: Low <snip>
To avoid this type of DDoS violation, set a high bandwidth:
user@router#set system ddos-protection protocols dhcpv4 bad-packets bandwidth 1000 user@router#set system ddos-protection protocols dhcpv4 bad-packets burst 1000
And clear the current violation:
user@router>clear ddos-protection protocols dhcpv4 bad-packets states
Then do a capture on the interface:
user@router> monitor traffic interface xe-0/2/0 no-resolve size 1500 detail matching "port 67 or 68" Address resolution is OFF. Listening on xe-0/2/0, capture size 1500 bytes 11:59:18.941161 In IP (tos 0x0, ttl 255, id 800, offset 0, flags [none], proto: UDP (17), length: 295) 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 00:00:01:00:00:02, length 267, xid 0x1, Flags [Broadcast] Client-Ethernet-Address 00:00:01:00:00:02 <-- You can find the problem client MAC address Vendor-rfc1048 Extensions Magic Cookie 0x63825363 DHCP-Message Option 53, length 2: 1.61 <-- Length 2 is reason of "bad-packet" LOG Option 7, length 1: trailing data length 1 Subnet-Mask Option 1, length 0 Time-Zone Option 2, length 12: 107179113,1701737527,67175951 Static-Route Option 33, length 255: [|rfc1048 255]
The system drops this kind of error message and there is no service impact. We cannot forbid users to send DHCPv4 bad-packet. If users do not like the system to keep reporting such DDoS, then set/clear log messages using the following configuration to disable it.
user@router# set system ddos-protection protocols dhcpv4 bad-packets disable-logging