One example of an
effective use of an extension is to protect against clients flooding the server
with unnecessary traffic. You can use the ChattyClientFilter extension to keep
the server from having to do much of the work of processing these chatty client
packets. If you have large numbers of clients in your network, you might want
to consider implementing this extension.
ChattyClientFilter extension is available in the /examples/dhcp/dex directory
of the Cisco Prime IP Express installation, and compiled and ready to use in
/extensions/dhcp/dex/dexextension.so or /extensions/dhcp/dex/dexextension.dll.
The extension monitors client requests, based on the MAC address, and disables
the client if it generates more than a certain number of packets in a time
interval. Disabling a client means that the server discards packets from it.
However, the server does not ignore the client entirely, because it continues
to monitor traffic from it. If the server detects that the client starts to
generate fewer than a certain number of packets in a time interval, it
reenables the client and begins to allow packets from it again.
Figure 1. Chatty Client
The criteria for
disabling and reenabling are set through arguments to the ChattyClientFilter
extension. By default, the server disables a client when it receives more than
15 packets within 30 seconds; the server reenables the client when it sends
fewer than 5 packets within 10 seconds. Note that these defaults are
conservative and do not protect against all situations. For example, the server
does not disable a client that sends packets every three seconds. Even allowing
for a few retransmissions, a client should never need to send more than a half
dozen packets in a short interval.
If you suspect chatty
clients, review the DHCP server logs to determine incoming rates, then set the
arguments described in the table below in the ChattyClientFilter code
Table 2 ChattyClientFilter
packets when the “drop” attribute of the environment dictionary is set to
“true”; default is not to ignore.
DHCPRELEASE packets if more than the specified count are received in the
specified time interval; default disabled.
keeps dropping DHCPRELEASE packets until the client suspends sending them for
specified interval. (DHCPv4 clients only.)
formula is that the time interval should be at least (packet-count + 2) * 30
SampleHitsToDisable; default 15 packets.
SampleTimeInterval; default 30 seconds.
QuietHitsToLeaveDisabled; default 5 packets.
maximum time a client is disabled, in seconds; default 0 - unlimited.
client if renewing or rebinding; default off. If the client exceeding the
SampleHitsToDisable rate does a DHCPREQUEST, the server sends it a DHCPNAK
instead of discarding the packet.
resolve problems with clients (such as cable modems) that cannot renew leases
for some reason. Sending the DHCPNAK causes the client to restart its DHCP
state machine and send a DHCPDISCOVER.
If you use
this argument, you must attach the ChattyClientFilter to the
check-lease-acceptable extension point. (DHCPv4
QuietTimeInterval; default 10 seconds.
StatisticsInterval; default 300 seconds (5 minutes). This argument controls the
frequency of periodic logging of the number of clients disabled and reenabled.
discards dropped packets; default off.
access on specified port (only enabled over IPv4; specify negative port to not
bind to 127.0.0.1).
The -h, -i, -l,
and -q defaults are unlikely to be appropriate to most situations as these were
designed to address a single type of misbehaving client. Using a longer
interval and packet hit count for normal conditions will produce reasonable
results. Values such as -i 120 -h 8 -q 120 -l 8 would allow a client 8 packets
over a 120 second period. A normal DHCPDISCOVER/OFFER/REQUEST/ACK is only 2
packets from a client. That is, the proper use of the ChattyClientFilter
requires tuning these values for your particular network conditions. Use of the
logscan tool which is available from the Cisco Prime IP Express download
section on the Cisco website can help in analyzing client activity.
Review the comments
in the ChattyClientFilter.cpp file for details on setting the arguments and
enabling the extension. In most cases, you would attach it to the
post-packet-decode extension point (along with
check-lease-acceptable if you use the
A sample use for the
ChattyClientFilter is to drop DHCPRELEASE packets sent from a DHCPv4 client to
prevent the lease history database from growing out of bounds, which can be the
case with certain router configurations.
This scenario uses
The setup on a Linux system might be:
nrcmd> extension dexChattyClientFilter create dex libdexextension.so
init-args="-d 2 120"
nrcmd> dhcp attachextension post-packet-decode dexChattyClientFilter
For Windows, replace libdexextension.so with dexextension.dll.
This setup results in
the server dropping DHCPRELEASE packets if it receives more than two of these
packets from the same client in a 120-second interval, and resuming
DHCPRELEASEs processing when the client does not send a DHCPRELEASE for at
least 120 seconds.
Cisco Prime IP
Express 8.2 or later supports the mini-web server that can be used to obtain
information about the clients being monitored or disabled (traffic being
dropped) by the Chatty Client Filter. A typical request might be
http://127.0.0.1:<port>/report entered in a web browser.
The web server
supports the following requests:
a statistics report.
report—Returns a statistics report and a full client report.
The client report includes all clients currently being monitored and those that
as report except only the disabled clients are returned.
as report but all clients are REMOVED from the internal monitored and disabled
csv-client-list—Returns the client list using CSV format (includes
monitored and disabled clients).
csv-disabled-client-list—Same as csv-client-list but only includes clients
xml-client-list—Returns the client list using XML (includes monitored and
xml-disabled-client-list—Returns the disabled client list using XML.
This web server
is a very basic server implementation. It only supports the requests mentioned