Cmts CBL Arp FLTR
Cmts CBL Arp FLTR
Cmts CBL Arp FLTR
Note Cisco IOS Release 12.2(33)SCA integrates support for this feature on the Cisco CMTS routers. This
feature is also supported in Cisco IOS Release 12.3BC, and this document contains information that
references many legacy documents related to Cisco IOS 12.3BC. In general, any references to Cisco IOS
Release 12.3BC also apply to Cisco IOS Release 12.2SC. For the latest information on Cisco CMTS
router support in Cisco IOS Release 12.2SC, refer to the Cross-Platform Release Notes for Cisco
Universal Broadband Routers in Cisco IOS Release 12.2SC.
This document describes the Cable ARP Filtering feature for the Cisco Cable Modem Termination
System (CMTS). This feature enables service providers to filter Address Resolution Protocol (ARP)
request and reply packets, to prevent a large volume of such packets from interfering with the other
traffic on the cable network.
Finding Support Information for Platforms and Cisco IOS Software Images
Use Cisco Feature Navigator to find information about platform support and Cisco IOS software image
support. Access Cisco Feature Navigator at http://www.cisco.com/go/fn. You must have an account on
Cisco.com. If you do not have an account or have forgotten your username or password, click Cancel at
the login dialog box and follow the instructions that appear.
Contents
• Prerequisites for Cable ARP Filtering, page 2
• Restrictions for Cable ARP Filtering, page 2
• Information About Cable ARP Filtering, page 3
Americas Headquarters:
Cisco Systems, Inc., 170 West Tasman Drive, San Jose, CA 95134-1706 USA
Note If using bundled cable interfaces, the Cable ARP Filtering feature is configured on the master and slave
interfaces separately. This allows you to configure the feature only on the particular interfaces that
require it. In addition, you can configure the feature with different threshold values, allowing you to
customize the feature for each interface’s traffic patterns.
http://www.linksysbycisco.com/US/en/support
For the release notes for the latest revision of the firmware, see the following URL on the Linksys
website:
http://www.linksysbycisco.com/US/en/support
Note It is extremely important that non-compliant CPE devices be updated to firmware that correctly handles
ARP and other broadcast traffic. Even one or two non-compliant devices on a segment can create a
significant problem with dropped packets, impacting all of the other customers on that segment.
Note ARP filtering in PXF is only supported on the PRE2 and is enabled by default.
Note If the offending device is not “repaired” or shut off, it will remain in the PXF ARP Filter indefinitely.
The PXF ARP rate limiter is designed to filter a maximum of 16,000 ARP offenders. If this pool of
16,000 filterable entities is exhausted, then the entity is filtered on the RP. The CLI statistics will
distinguish mac addresses filtered on the RP verses PXF.
Because of possible mac address hash collisions, ARP offenders that cannot be programmed into the
PXF ARP rate limiter will still be filtered in PXF by SID. Since the hash is done by source mac address
and SID, such devices can actually moved back to mac address filtering by deleting the associated
modem and forcing it back online with a new SID (this merely a possibility and is not expected to be a
common practice).
ARP packets with a source mac address that is not “known” to the CMTS as a modem or CPE will be
filtered by their SID in PXF. Therefore, there will never be an unusual ARP packet source that will NOT
be filtered in PXF. False ARP packets with invalid operation codes will be filtered as if they are an ARP
Reply.
PXF Divert-Rate-Limit
Diverted packets sent from the forwarding processor (FP) to the route processor (RP), via the FP-to-RP
interface, may encounter congestion when packets requiring diversion arrive at the FP at a faster rate
than they can be transmitted to the RP. When congestion occurs, valid packets in the FP-to-RP queues
will be dropped. This situation can be deliberately caused by attacks directed at the CMTS or
inadvertently by faulty external hardware.
PXF Divert-Rate-Limit identifies packet streams that will cause congestion of the FP-to-RP interface.
Packets in the stream are dropped according to the configured rate-limiting parameters. Rate-limiting
occurs before the packets are placed in the FP-to-RP queues, preventing valid packets in other streams
from being dropped.
The following diverted packets will be rate-limited:
• fwd-glean—Packets that hit a glean adjacency in the Forwarding Information Base (FIB).
• rpf-glean—Packets that hit a glean adjacency during the Reverse Path Forwarding (RPF) check.
Packets that pass rate-limiting are diverted as they normally would be. Packets that fail rate-limiting are
dropped.
Rate-limiting is implemented by a token-bucket algorithm. The token-bucket algorithm requires two
variables: rate and limit. Both the rate and limit are configurable via the CLI. The rate is the average
number of packets-per-second that pass the rate-limiting code. The limit can be thought of as the number
of packets that will pass during an initial burst of packets.
Note The Divert-Rate-Limit feature is always on and cannot be turned off. Using the no form of the
configuration CLI returns the rate-limiting parameters to their default values. During a PXF and CPU
switchover or reload, the configuration is retained, but not the statistics. Therefore, after switchover, the
statistics shown by the show pxf cpu statistics drl command will show zero.
fwd-glean
IP packets that hit a glean adjacency in the FIB are diverted. There are three requirements:
• RPF-check has passed (if required).
• SV-check has passed (if required).
• Forward adjacency is glean.
Packets are rate-limited based on the destination IP address. A hash on the destination IP address is used
to create an index that stores state information for rate-limiting. In the event of a hash collision, the
pre-existing state information will be used and updated. The table that stores state information is large
enough to make collisions rare.
rpf-glean
The RPF feature is modified to divert packets that hit a glean adjacency during the RPF check. A new
divert_code will be created for this type of diverted packet. Currently, these packets are dropped.
There are four requirements:
• SV-check has passed (if required).
• RPF is enabled.
• The packet is from a non-load-balanced interface.
• RPF-adjacency is glean.
Packets are rate-limited based on the source IP address. A hash on the source IP address is used to create
an index that stores state information for rate-limiting. In the event of a hash collision, the pre-existing
state information will be updated. The table that stores state information is large enough to make
collisions rare.
Step 1 To discover the CPU processes that are running most often, use the show process cpu sorted command
and look for the ARP Input process:
Router# show process cpu sorted
CPU utilization for five seconds: 99%/28%; one minute: 93%; five minutes: 90%
PID Runtime(ms) Invoked uSecs 5Sec 1Min 5Min TTY Process
19 139857888 44879804 3116 31.44% 28.84% 28.47% 0 ARP Input
154 74300964 49856254 1490 20.29% 19.46% 15.78% 0 SNMP ENGINE
91 70251936 1070352 65635 8.92% 9.62% 9.59% 0 CEF process
56 17413012 97415887 178 3.01% 3.67% 3.28% 0 C10K BPE IP Enqu
78 24985008 44343708 563 3.68% 3.47% 3.24% 0 IP Input
54 6075792 6577800 923 0.90% 0.67% 0.65% 0 CMTS SID mgmt ta
...
In this example, the ARP Input process has used 31.44 percent of the CPU for the past five seconds. Total
CPU utilization is also at 99 percent, indicating that a major problem exists on the router.
Note As a general rule, the ARP Input process should use no more than one percent of CPU processing time
during normal operations. The ARP Input process could use more processing time during certain
situations, such as when thousands of cable modems are registering at the same time, but if it uses more
than one percent of processing time during normal operations, it probably indicates a problem.
Step 2 To monitor only the ARP processes, use the show process cpu | include ARP command:
Step 3 To monitor the number of ARP packets being processed, use the show ip traffic command.
Router# show ip traffic | begin ARP
ARP statistics:
Rcvd: 11241074 requests, 390880354 replies, 0 reverse, 0 other
Sent: 22075062 requests, 10047583 replies (2127731 proxy), 0 reverse
Repeat this command to see how rapidly the ARP traffic increases.
Step 4 If ARP traffic appears to be excessive, use the show cable arp-filter command to display ARP traffic
for each cable interface, to identify the interfaces that are generating the majority of the traffic.
Router# show cable arp-filter Cable5/0/0
In the above example, the unfiltered and filtered counters show zero, which indicates that ARP filtering
has not been enabled on the cable interface. After ARP filtering has been enabled with the cable arp
filter command, you can identify the specific devices that are generating excessive ARP traffic by using
the service divert-rate-limit command (see the “Identifying the Sources of Major ARP Traffic” section
on page 10).
SUMMARY STEPS
1. enable
2. configure terminal
3. interface cable x/y
4. cable arp filter reply-accept number window-size
5. cable arp filter request-send number window-size
6. end
DETAILED STEPS
Example:
Router> enable
Step 2 configure terminal Enters global configuration mode.
Example:
Router# configure terminal
Step 3 interface cable x/y Enters interface configuration mode for the specified cable interface.
Example:
Router(config)# interface cable 5/1
Step 4 cable arp filter reply-accept number Configures the cable interface to accept only the specified number of
window-size ARP reply packets every window-size seconds for each active Service ID
(SID) on that interface. The cable interface drops ARP reply packets for
Example: a SID that would exceed this number. (The default behavior is to accept
Router(config-if)# cable arp filter all ARP reply packets.)
reply-accept 2 2
• number = Number of ARP reply packets that is allowed for each
SID within the window time period. The allowable range is 0 to 20
packets, with a default of 4 packets. If number is 0, the cable
interface drops all ARP reply packets.
• window-size = Size of the window time period, in seconds, in which
to monitor ARP replies. The valid range is 1 to 5 seconds, with a
default of 2 seconds.
Step 5 cable arp filter request-send number Configures the cable interface to send only the specified number of ARP
window-size request packets every window-size seconds for each active SID on that
interface. The cable interface drops ARP requests for a SID that would
Example: exceed this number. (The default behavior is to send all ARP request
Router(config-if)# cable arp filter packets.)
request-send 3 1
• number = Number of ARP request packets that is allowed for each
SID within the window time period. The allowable range is 0 to 20
packets, with a default of 4 packets. If number is 0, the cable
interface does not send any ARP request packets.
• window-size = Size of the window time period, in seconds, in which
to monitor ARP requests. The valid range is 1 to 5 seconds, with a
default of 2 seconds.
Tip The Linksys Wireless-B Broadband Router, Model number BEFW11S4 version 4 with 1.44.2 firmware,
has a known problem in which it incorrectly generates an ARP reply for every ARP request packet it
receives. See the “Linksys Wireless-Broadband Router (BEFW11S4)” section on page 4 for information
on how to resolve this problem.
DETAILED STEPS
Step 1 To discover the devices that are responsible for generating or forwarding more ARP requests on a
specific cable interface than a specified minimum number of packets, use the show cable arp-filter
requests-filtered command where number is the threshold value for the number of packets being
generated:
show cable arp-filter cable interface requests-filtered number
For example, to display the devices that have generated more than 100 ARP request packets, enter the
following command:
Router# show cable arp-filter cable 5/1/0 requests-filtered 100
Step 2 Repeat this command to show how quickly the devices are generating the ARP packets.
Step 3 To discover the devices that are responsible for generating or forwarding more ARP replies on a specific
cable interface than a specified minimum number of packets, use the show cable arp-filter
replies-filtered command where number is the threshold value for the number of packets being
generated:
show cable arp-filter cable interface replies-filtered number
For example, to display the devices that have generated more than 200 ARP reply packets, enter the
following command:
Router# show cable arp-filter c5/0/0 replies-filtered 200
Step 4 (Optional) If a particular cable modem is generating or forwarding excessive ARP replies, contact the
customer to see if they are using a Linksys Wireless-B Broadband Router, Model number BEFW11S4.
If so, this router could be running old firmware that is incorrectly generating excessive ARP packets, and
the customer should upgrade their firmware. For more information, see the “Linksys
Wireless-Broadband Router (BEFW11S4)” section on page 4.
Step 5 Repeat this command during each filter period (the time period you entered with the cable arp filter
command) to show how quickly the devices are generating the ARP packets.
Step 6 (Optional) The ARP reply and request packet counters are 16-bit counters, so if a very large number of
packets are being generated on an interface, these counters could wrap around to zero in a few hours or
even a few minutes. Clearing the ARP counters eliminates stale information from the display and makes
it easier to see the worst offenders when you suspect ARP traffic is currently creating a problem on the
network.
To eliminate the modems that are not currently triggering the ARP filters and to isolate the worst current
offenders, use the clear counters cable interface command to reset all of the interface counters to zero.
Then the show cable arp-filter commands clearly identify the SIDs of the modems that are currently
forwarding the most ARP traffic.
For example, the following example indicates that a number of modems are forwarding a large enough
volume of ARP traffic that they have triggered the ARP packet filters:
Router# show cable arp-filter cable 5/1/0 requests-filtered 10
SID 57 shows the largest number of packets, but it is not immediately apparent if this modem is causing
the current problems. After clearing the counters though, the worst offenders are easily seen:
Router# clear counter cable 5/1/0
Clear "show interface" counters on this interface [confirm] y
Step 7 (Optional) If the Req-For-IP-Filtered column shows the majority of ARP packets, use the show cable
arp-filter ip-requests-filtered command to display more details about the CPE device that is generating
this traffic. Then use the debug cable mac-address and debug cable arp filter commands to display
detailed information about this particular traffic; for example:
Router# show cable arp-filter c5/0/0 ip-requests-filtered 100
This example shows that the CPE device at IP address 50.3.81.13 is sending packets to TCP port 445 to
every IP address on the 50.3.82.0 subnet, in a possible attempt to find a computer that has Microsoft
Windows file-sharing enabled.
Step 8 After determining the specific devices that are generating excessive ARP traffic, you can take whatever
action is allowed by your company’s service level agreements (SLAs) to correct the problem.
Examples
In this example, two cable interfaces, C5/0/0 and C7/0/0, are joined in the same bundle, which means
the interfaces share the same broadcast traffic. Separate devices on each interface are generating
excessive ARP traffic:
• The device at MAC address 000C.2854.72D7 on interface C7/0/0 is generating or forwarding a large
volume of ARP requests. Typically, this device is a cable modem that is forwarding the ARP requests
that are being generated by a CPE device behind the modem. The CPE device could be attempting
a theft-of-service or denial-of-service attack, or it could be a computer that has been infected by a
virus and is trying to locate other computers that can be infected.
• The device at MAC address 000C.53B6.562F on Cable 5/0/0 is responding to a large number of ARP
requests, which could indicate that the device is a router that is running faulty software.
The following commands identify the device on the C7/0/0 interface that is generating the excessive
ARP requests:
Router# show cable arp-filter c7/0/0
The following commands identify the device on the C5/0/0 interface that is generating the excessive
ARP replies:
Router# show cable arp-filter c5/0/0
Note The clear counters command clears all of the packet counters on an interface, not just the ARP packet
counters.
SUMMARY STEPS
1. enable
2. configure terminal
3. interface cable x/y
4. service divert-rate-limit divert-code rate limit
5. end
DETAILED STEPS
Example:
Router> enable
Step 2 configure terminal Enters global configuration mode.
Example:
Router# configure terminal
Step 3 interface cable x/y Enters interface configuration mode for the specified cable interface.
Example:
Router(config)# interface cable 5/1
Step 4 service divert-rate-limit divert-code Configures the Divert-Rate-Limit for the following packets:
rate limit
• fwd-glean—Packets that hit a glean adjacency in the FIB.
• rpf-glean—Packets that hit a glean adjacency during the RPF check.
Example:
Router(config-if)# service The rate is the average number of packets-per-second that pass the
divert-rate-limit fib-rp-glean 10 rate-limiting code. The minimum rate is 1 packet-per-second and the
limit 20
maximum rate is 255 packets-per-second. The default rate is 20
or packets-per-second.
The minimum limit is 4 packets. and the maximum limit is 255 packets.
Router(config-if)# service The default limit is 5 packets.
divert-rate-limit fib-rpf-glean 10
limit 20
Note Using the no form of the service divert-rate-limit command
will reset the rate and limit to the default values.
Step 5 end Exits interface configuration mode and returns to privileged EXEC
mode.
Example:
Router(config-if)# end
Additional References
The following sections provide references related to the Cable ARP Filtering feature.
Related Documents
Related Topic Document Title
CMTS Commands Cisco IOS CMTS Cable Command Reference, at the following URL:
http://www.cisco.com/en/US/docs/ios/cable/command/reference/cb
l_book.html
Cisco IOS Release 12.2 Commands Cisco IOS Release 12.2 Configuration Guides and Command
References, at the following URL:
http://www.cisco.com/univercd/cc/td/doc/product/software/ios122/
122cgcr/index.htm
Standards
Standards Title
SP-RFIv1.1-I09-020830 Data-over-Cable Service Interface Specifications Radio Frequency
Interface Specification, version 1.1 (http://www.cablemodem.com)
MIBs
MIBs MIBs Link
No new or modified MIBs are supported, and support To locate and download MIBs for selected platforms, Cisco IOS
for existing MIBs has not been modified by this releases, and feature sets, use Cisco MIB Locator found at the
feature. following URL:
http://www.cisco.com/go/mibs
RFCs
RFCs Title
RFC 826 An Ethernet Address Resolution Protocol (ARP)
RFC 2665 DOCSIS Ethernet MIB Objects Support
RFC 2669 Cable Device MIB
Technical Assistance
Description Link
The Cisco Technical Support website contains http://www.cisco.com/cisco/web/support/index.html
thousands of pages of searchable technical content,
including links to products, technologies, solutions,
technical tips, and tools. Registered Cisco.com users
can log in from this page to access even more content.
Note Table 2 lists only the Cisco IOS software release that introduced support for a given feature in a given
Cisco IOS software release train. Unless noted otherwise, subsequent releases of that Cisco IOS
software release train also support that feature.
CCDE, CCENT, CCSI, Cisco Eos, Cisco Explorer, Cisco HealthPresence, Cisco IronPort, the Cisco logo, Cisco Nurse Connect, Cisco Pulse,
Cisco SensorBase, Cisco StackPower, Cisco StadiumVision, Cisco TelePresence, Cisco TrustSec, Cisco Unified Computing System, Cisco WebEx,
DCE, Flip Channels, Flip for Good, Flip Mino, Flipshare (Design), Flip Ultra, Flip Video, Flip Video (Design), Instant Broadband, and Welcome to
the Human Network are trademarks; Changing the Way We Work, Live, Play, and Learn, Cisco Capital, Cisco Capital (Design), Cisco:Financed
(Stylized), Cisco Store, Flip Gift Card, and One Million Acts of Green are service marks; and Access Registrar, Aironet, AllTouch, AsyncOS,
Bringing the Meeting To You, Catalyst, CCDA, CCDP, CCIE, CCIP, CCNA, CCNP, CCSP, CCVP, Cisco, the Cisco Certified Internetwork Expert
logo, Cisco IOS, Cisco Lumin, Cisco Nexus, Cisco Press, Cisco Systems, Cisco Systems Capital, the Cisco Systems logo, Cisco Unity,
Collaboration Without Limitation, Continuum, EtherFast, EtherSwitch, Event Center, Explorer, Follow Me Browsing, GainMaker, iLYNX, IOS,
iPhone, IronPort, the IronPort logo, Laser Link, LightStream, Linksys, MeetingPlace, MeetingPlace Chime Sound, MGX, Networkers, Networking
Academy, PCNow, PIX, PowerKEY, PowerPanels, PowerTV, PowerTV (Design), PowerVu, Prisma, ProConnect, ROSA, SenderBase, SMARTnet,
Spectrum Expert, StackWise, WebEx, and the WebEx logo are registered trademarks of Cisco and/or its affiliates in the United States and certain
other countries.
All other trademarks mentioned in this document or website are the property of their respective owners. The use of the word partner does not imply
a partnership relationship between Cisco and any other company. (1002R)
Any Internet Protocol (IP) addresses used in this document are not intended to be actual addresses. Any examples, command display output, and
figures included in the document are shown for illustrative purposes only. Any use of actual IP addresses in illustrative content is unintentional and
coincidental.