- List of Tables
- Revision
- About This Manual
- Scope
- Definition/Abbreviation
- 1 Feature Overview
- 2 Functionality
- 3 Design
- 4 Flow Diagrams
- 5 Error Handling
- 6 Serviceability and Debug
- 7 Warm Boot Support
- 8 Scalability
- 9 Unit Test
Table 1: Abbreviations Table 2: Storm Control SAI attributes
| Rev | Date | Author | Change Description |
|---|---|---|---|
| 0.1 | 06/24/2019 | Mohanarajan Selvaraj | Initial version |
This document provides general information about Broadcast, Unknown-unicast and unknown-Multicast storm-control feature implementation in SONiC.
This document describes the functionality and high level design of Broadcast, Unknown-unicast and unknown-Multicast storm-control feature in SONiC.
| Term | Meaning |
|---|---|
| BUM | Broadcast Unknown-unicast and unknown-Multicast |
A traffic storm occurs when packets flood the LAN, creating excessive traffic and degrading network performance. The type of traffic can be Broadcast, Unknown-unicast or unknown-Multicast (BUM). The storm-control feature allows the user to limit the amount of BUM traffic admitted to the system. This can be achieved by configuring the type of storm (Broadcast or Unknown-unicast or unknown-Multicast) and the corresponding kilo bits per second (kbps) parameter on a given physical interface. Traffic that exceeds the configured rate will be dropped. Unknown-multicast traffic consists of all multicast traffic which donot match any of the statically configured or dynamically learned multicast groups.
- Support configuration of Broadcast, Unknown-unicast and unknown-Multicast storm-control independently on physical interfaces.
- Support threshold rate configuration in kilo bits per second (kbps) in the range of 0 kbps to 100,000,000 kbps (100Gbps).
This feature supports Click, Klish, REST, gNMI interfaces.
- Support a CLI to add or delete broadcast, unknown-unicast and unknown-multicast storm-control on a physical interface as described in "Configuration Commands" section below.
- Support show commands to display the storm-control configuration as described in "Show Commands" section below.
- Support debug commands as described in "Debug Commands" section below.
Storm-control configuration is done on physical ports. Hence it should be supported on all physical ports of the system.
Storm-control functionality should continue to work across warm reboot.
- To support planned system warm boot.
- To support SWSS docker warm boot.
The Policer Orchestration agent is used for handling BUM storm-control configuration.
No new containers are introduced. Functionality is added to the existing swss container.
The existing SAI policer and interface APIs shall be used to support this feature and they are available at below location,
https://github.com/opencomputeproject/SAI/blob/master/inc/saipolicer.h
https://github.com/opencomputeproject/SAI/blob/master/inc/saiport.h
The details of the changes will be discussed in the design section below.
Refer to section 1
Any Layer-2 network segment where unknown-unicast / broadcast / unknown-multicast traffic storm should be controlled.
Refer to section 1.1
BUM storm control
- Configuration is not supported on VLAN and port-channel interfaces. User can configure on physical port which is part of a VLAN / port-channel.
- Statistics is not supported.
- User is expected to remove all storm-control configurations from interface before doing a breakout from Click CLI.
Figure 1: Storm Control High Level Architecture
- Storm-control configurations are parsed and stored in CFG_PORT_STORM_CONTROL_TABLE in Configuration database by the Management Framework.
- The Policer Orchestration Agent subscribes to notifications from the CFG_PORT_STORM_CONTROL_TABLE and parses the input parameters (interface, storm-control type, kbps). A policer_name is created internally by encoding the interface_name and storm_control_type.
- create_policer SAI API is invoked to create a policer with the given input parameters.
- The identifier of the policer created is associated with the encoded policer_name.
- The policer identifier is passed to set_port_attribute SAI API to set the appropriate type of storm-control on the port.
This section describes the changes made to different DBs for supporting storm-control.
A new table CFG_PORT_STORM_CONTROL_TABLE is introduced in the configuration database for the purpose of storing storm-control configuration parameters. This table is filled by the management framework.
;Store Storm Control configuration per physical port
;Status: work in progress
;storm control type - broadcast / unknown-unicast / unknown-multicast
key = CFG_PORT_STORM_CONTROL_TABLE:port:storm_control_type ; Ethernet Interface Name and storm control type
;field = value
enabled = BIT ; Is the storm control enabled (1) or disabled (0) on the interface
kbps = 1*13 DIGIT ; CIR value in kilo bits per second
No tables are introduced in APP_DB
No tables are introduced in STATE_DB.
No changes are introduced in ASIC_DB.
No changes are introduced in COUNTER_DB.
Policer Orchestration agent is responsible for the following activities:
- Subscribes to notifications on CFG_PORT_STORM_CONTROL_TABLE entries in the CONFIG_DB.
- Creates an internal name for policer by encoding the interface name and storm-control type.
- Creates the policer based on the parameters and associates the policer identifier to internal name
- Populates the port attribute SAI structures and pushes the entry to ASIC_DB.
Storm-control SAI interface APIs are already defined. The table below represents the SAI attributes which shall be used for BUM storm-control.
| Storm Control component | SAI attributes |
|---|---|
| Meter type | SAI_POLICER_ATTR_METER_TYPE |
| Meter mode | SAI_POLICER_ATTR_MODE |
| CIR (bps) | SAI_POLICER_ATTR_CIR |
| Unknown-unicast policer | SAI_PORT_ATTR_FLOOD_STORM_CONTROL_POLICER_ID |
| Broadcast policer | SAI_PORT_ATTR_BROADCAST_STORM_CONTROL_POLICER_ID |
| Unknown-Multicast policer | SAI_PORT_ATTR_MULTICAST_STORM_CONTROL_POLICER_ID |
The BUM storm-control feature can be enabled on a physical port.
The create_policer SAI API is used to create the policer based on the policer parameters listed in Table 2.
- Meter Type - Can be packets or bytes. Storm-control uses bytes meter type.
- Meter Mode - Can be st_tcm or tr_tcm or storm. Storm-control uses storm meter mode.
- CIR (bps) - Value of CIR given in bps.
The set_port_attribute SAI API is used to set the policer on an interface.
- Unknown-unicast policer - Enables storm-control for unknown-unicast traffic received on the interface.
- Broadcast policer - Enables storm-control for broadcast traffic received on the interface.
- Unknown-multicast policer - Enables storm-control for unknown-multicast traffic received on the interface.
Configuration is supported using Click and Klish CLI commands.
This section lists down the Click commands.
BUM storm-control can be configured only on physical interfaces.
switch# config interface storm-control {broadcast | unknown-unicast | unknown-multicast} {add|del} <interface_name> {<kilo_bits_per_second>}
This command configures broadcast storm-control on a physical interface.
switch# config interface storm-control broadcast add <interface_name> {<kilo_bits_per_second>}
This command configures unknown-unicast storm-control on a physical interface.
switch# config interface storm-control unknown-unicast add <interface_name> {<kilo_bits_per_second>}
This command configures unknown-multicast storm-control on physical interface.
switch# config interface storm-control unknown-multicast add <interface_name> {<kilo_bits_per_second>}
The following show command displays storm-control configurations.
show storm-control {all | interface <interface_name>}
Following is a sample output
show storm-control all
+------------------+-----------------+---------------+ | Interface Name | Storm Type | Rate (kbps) | +==================+=================+===============+ | Ethernet0 | broadcast | 1000 | +------------------+-----------------+---------------+ | Ethernet0 | unknown-unicast | 2000 | +------------------+-----------------+---------------+ | Ethernet2 | unknown-unicast | 5000 | +------------------+-----------------+---------------+
show storm-control interface Ethernet2
+------------------+-----------------+---------------+ | Interface Name | Storm Type | Rate (kbps) | +==================+=================+===============+ | Ethernet2 | unknown-unicast | 5000 | +------------------+-----------------+---------------+
Not applicable
Not applicable
Figure 2: Enable storm control on physical interface
Figure 3: Disable storm control on physical interface
Figure 4: Update storm control on physical interface
Debug commands as described in Debug Command section will be supported. Debug command output will be captured as part of tech support.
- A CLI error will be displayed via console and configuration will be rejected
- Internal processing errors within SwSS will be logged in syslog with ERROR level
- SAI interaction errors will be logged in syslog
The storm-control setting on the port should be retained across warmboot so that the BUM storm traffic gets rate-limited as per the configured policer parameters.
Storm-control is a physical port parameter. Testing would be done by enabling storm-control on all the physical ports.
| Name | Scaling value |
|---|---|
| Number of interfaces | max_physical_ports |
1. Configure broadcast storm-control on interface and check that it is updated in CONFIG_DB.
2. Configure unknown-unicast storm-control on interface and check that it is updated in CONFIG_DB.
3. Configure unknown-multicast storm-control on interface and check that it is updated in CONFIG_DB.
4. Unconfigure broadcast storm-control on interface and check that it is updated in CONFIG_DB.
5. Unconfigure unknown-unicast storm-control on interface and check that it is updated in CONFIG_DB.
6. Unconfigure unknown-multicast storm-control on interface and check that it is updated in CONFIG_DB.
7. Execute the show storm-control command to check the configuration.
8. Verify that the BUM storm-control configurations are correctly re-applied after cold reboot.
9. Verify that all the three storm-control types can be configured and rate limiting is
applied independently on the three types of traffic received at the interface.
10. Verify that the kbps value configured is independent per interface.
11. When user configures BUM storm-control on interface where the same type is already configured,
verify that if kbps value is different, the new kbps value is updated to the CONFIG_DB.
12. Verify that broadcast traffic gets rate-limited as per broadcast storm-control policer parameters.
13. Verify that unknown-unicast traffic gets rate-limited as per unknown-unicast storm-control policer parameters.
14. Verify that multicast traffic gets rate-limited as per multicast storm-control policer parameters.
15. Configure all three BUM storm-control on interface and verify that the rate-limiting of traffic is as per the
respective policer parameters.
16. Verify that other traffic streams are unaffected by BUM storm-control configuration.
17. Verify that after unconfiguring BUM storm-control configuration on interface, BUM storm traffic rate is no
more rate limited.
18. Verify that traffic is rate-limited as per the updated value of kbps when user updates existing
BUM storm-control configuration on interface.
19. Configure BUM storm-control on all the physical interfaces on the system and check that rate-limiting is
performed on all interfaces.
20. Verify that BUM storm-control configurations are restored after warm boot.
21. Verify that BUM storm rate-limiting continues to work at the specific rate across warm boot.
22. Verify that BUM storm-control is only active on interfaces that previously had storm-control configurations
before warm boot.
23. Verify that storm-control configuration errors out when applied on port-channel or vlan interfaces.
24. Verify that error is returned when the same configuration is repeated on the interface.
25. Configure BUM storm-control on interface without providing kbps value and check that configuration is
not accepted.
26. Unconfigure BUM storm-control on interface by providing kbps as input and check that
additional / invalid parameter error is displayed.
27. Verify that invalid parameter error is displayed when value of kbps is out of range or invalid.
28. Verify that invalid parameter / input error is displayed when invalid input is provided for storm-control type.