Sometimes it’s hard finding extensive, easily digestible documentation on FTOS running on the Dell Force10 switch platform. Recently we had to apply simple rate limiting against ports generating more bandwidth than they should but not get too in the weeds with QoS policies. Also, we’ve needed to enable controls to throttle multicast traffic. I hope this information proves useful for someone else.
Simple Bandwidth Rate Limiting
To enable simple per-port rate limiting on a per interface basis (in megabits) we do the following. This is for a 10GbE port, rate-limiting to 2500 megabits/sec using the rate police command.
S4810-Leaf-5# conf t S4810-Leaf-5(conf)# interface tengigabitethernet 0/12 S4810-Leaf-5(conf)# rate police 2500
- Note that rate police will limit all traffic on the port, so if you know the type of traffic you want limited it’s better to use the storm-control command below or just set up a proper QoS policy.
Limiting Multicast Traffic
Sometimes multicast can be problematic, we had an issue with some R&D deployment tooling that generated an excessive amount of multicast traffic – upwards of several GB/second. Let’s rate limit multicast on the port down to 300 pps (packets per second).
S4810-Leaf-5# conf t S4810-Leaf-5(conf)# interface tengigabitethernet 0/12 S4810-Leaf-5(conf)# storm-control multicast 300 in
Note that the storm-control command can also apply to broadcast and unicast and either be enabled globally or on a per-port basis.
S4810-Leaf-5(conf-if-te-0/3)# storm-control ? broadcast Broadcast Traffic multicast Multicast Traffic unknown-unicast Unknown Unicast Traffic
- It’s recommended to enable it on a per-port basis after you’ve determined where it’s needed as it might be overkill to enable it globally unless you’ve got a small, homogenous environment.
Gathering Statistics or What to Throttle
If you are using a Spine-Leaf topology you can observe which Leaf switches are generating the most throttles and traffic which might impact CPU. If you’re using another design this will probably still apply.
Use the deb cpu-traffic-stats command to start generating debug statistics
01-Spine-1# deb cpu-traffic-stats Started collecting CPU traffic statistics.
Use the show cpu-traffic-stats to view statistics
01-Spine-1# show cpu-traffic-stats Processor : CP -------------- Received 28% traffic on fortyGigE 0/28 Total packets:374 LLC:0, SNAP:0, IP:349, ARP:16, other:9 Unicast:1, Multicast:358, Broadcast:15 Received 26% traffic on fortyGigE 0/24 Total packets:354 LLC:0, SNAP:0, IP:337, ARP:9, other:8 Unicast:1, Multicast:345, Broadcast:8 Received 15% traffic on fortyGigE 0/0 Total packets:207 LLC:0, SNAP:0, IP:17, ARP:5, other:185 Unicast:0, Multicast:202, Broadcast:5
Note the previous count and compare over time.
01-Spine-1# show cpu-traffic-stats Processor : CP -------------- Received 30% traffic on fortyGigE 0/28 Total packets:952 LLC:0, SNAP:0, IP:891, ARP:37, other:24 Unicast:1, Multicast:915, Broadcast:36 Received 29% traffic on fortyGigE 0/24 Total packets:920 LLC:0, SNAP:0, IP:873, ARP:25, other:22 Unicast:3, Multicast:895, Broadcast:22 Received 12% traffic on fortyGigE 0/0 Total packets:395 LLC:0, SNAP:0, IP:52, ARP:27, other:316 Unicast:0, Multicast:367, Broadcast:28
Make sure to use the un all command to turn off debugging when finished as it’s a resource-intensive process and will bog things down if left unkempt.
01-Spine-1# un all All possible debugging has been turned off