You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Update CoPP design with new always_enabled field info (#962)
A new "always_enabled" field was added to CoPP configurations table.
This change explains the motivation for the change and what will be the new behavior.
Copy file name to clipboardExpand all lines: doc/copp/CoPP Config and Management.md
+39-26Lines changed: 39 additions & 26 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -32,7 +32,7 @@ queue = number; strict queue priority. Higher number means higher priori
32
32
trap_action = packet_action; trap action which will be applied to all trap_ids for this group.
33
33
trap_priority = trap_priority
34
34
35
-
;Settings for embedded policer.
35
+
;Settings for embedded policer.
36
36
meter_type = "packets" | "bytes"
37
37
mode = "sr_tcm" | "tr_tcm" | "storm"
38
38
color = "aware" | "blind"
@@ -43,8 +43,8 @@ pir = number ;packets or bytes depending on the meter_type value
43
43
green_action = packet_action
44
44
yellow_action = packet_action
45
45
red_action = packet_action
46
-
genetlink_name = genetlink_name ;[Optional] "psample" for sFlow
47
-
genetlink_mcgrp_name = multicast group name; ;[Optional] "packets" for sFlow
46
+
genetlink_name = genetlink_name ;[Optional] "psample" for sFlow
47
+
genetlink_mcgrp_name = multicast group name; ;[Optional] "packets" for sFlow
48
48
```
49
49
```
50
50
key = "COPP_TRAP|name"
@@ -63,7 +63,18 @@ state = "ok"
63
63
```
64
64
65
65
### coppmgr
66
-
Introduce a *new* CoPP manager, that subscribes for the Config DB CoPP Tables and Feature Tables. Based on the feature enablement, ```coppmgr``` handles the logic to resolve whether a CoPP table shall be written to APP DB for orchagent consumption. Inorder to reduce changes to copporch and for backward compatibility during warmboot, ```coppmgr``` shall use the existing APP_DB schema and implement internal logic to convert the proposed ConfigDB entries to APP DB entries. Similar to existing swss managers, an entry with state "ok" shall be added to STATE_DB. `coppmgrd` must be started by [supervisord.conf](https://github.com/Azure/sonic-buildimage/blob/master/dockers/docker-orchagent/supervisord.conf) first, before any other process is started in swss. During init, ```coppmgr``` shall read the ```copp_cfg.json``` file and apply the default configuration. The default shall not be part of Config_DB entries. ```coppmgr``` shall also read from the config_db during init and apply the logic to merge if there are same entries within the ```copp_cfg.json``` file.
66
+
Introduce a *new* CoPP manager, that subscribes for the Config DB CoPP Tables and Feature Tables. Based on the feature enablement, ```coppmgr``` handles the logic to resolve whether a CoPP table shall be written to APP DB for orchagent consumption. Inorder to reduce changes to copporch and for backward compatibility during warmboot, ```coppmgr``` shall use the existing APP_DB schema and implement internal logic to convert the proposed ConfigDB entries to APP DB entries. Similar to existing swss managers, an entry with state "ok" shall be added to STATE_DB. `coppmgrd` must be started by [supervisord.conf](https://github.com/Azure/sonic-buildimage/blob/master/dockers/docker-orchagent/supervisord.conf) first, before any other process is started in swss. During init, ```coppmgr``` shall read the ```copp_cfg.json``` file and apply the default configuration. The default shall not be part of Config_DB entries. ```coppmgr``` shall also read from the config_db during init and apply the logic to merge if there are same entries within the ```copp_cfg.json``` file.
67
+
68
+
Trap name added to copp_cfg.json file has to match a feature name exist in FEATURE table in Config DB.
69
+
In order to handle traps which has no associated feature (such as arp, ip2me), a new field called "always_enabled" will be added to COPP_TRAP table in Config DB.
70
+
71
+
With the new "always_enabled" field, coppmgr will determine if a trap should be installed.
72
+
73
+
- If a trap has "always_enabled":"true" field, install it.
74
+
75
+
- If the associated feature is enabled, install the trap.
76
+
77
+
Now, traps which have no associated feature, will be installed only if "always_enabled" field value is "true".
67
78
68
79
### copporch
69
80
```copporch``` shall only be a consumer of APP DB CoPP Table. It is not expected to handle feature logic and the current handling of features like sFlow, NAT shall be revisited and removed to be added as part of ```coppmgr```. However `copporch` must be able to handle any new trap_id getting added or removed from an existing CoPP table, and handle attribute value set for a trap group
@@ -75,7 +86,7 @@ Handling of CoPP config json file shall be removed from ```dockers/docker-orchag
75
86
This file shall be modified to be compatible to Config DB schema, currently placed at ```swssconfig/sample/00-copp.config.json```. It shall be renamed to ```copp_cfg.j2``` and moved to ```files/image_config/copp/copp_cfg.j2```
76
87
77
88
### copp_cfg.json
78
-
A new file ```copp_cfg.json``` shall be introduced to include default CoPP tables from copp_cfg.j2 placed under ```/etc/sonic```. This file shall be read by ```coppmgr``` during initialization.
89
+
A new file ```copp_cfg.json``` shall be introduced to include default CoPP tables from copp_cfg.j2 placed under ```/etc/sonic```. This file shall be read by ```coppmgr``` during initialization.
79
90
80
91
### Default CoPP Tables
81
92
There are two proposals for loading the default CoPP Tables.
@@ -99,22 +110,22 @@ However, this approach has the following limitations:
99
110
In warmboot scenarios, as init_cfg.json is not read during warmboot and may result in ***new*** CoPP Tables in the "to" image not getting applied.
100
111
In coldboot, if user saves the config and the new release happened to have new CoPP values, it will not be applied since previous default values are present in config_db
101
112
102
-
2.```coppmgr``` reading directly from ```copp_cfg.json``` and apply the default CoPP Tables.
113
+
2.```coppmgr``` reading directly from ```copp_cfg.json``` and apply the default CoPP Tables.
103
114
104
-
For this design, considering the limitations, proposal is to go ahead with second option.
115
+
For this design, considering the limitations, proposal is to go ahead with second option.
105
116
106
117
## Warmboot and Backward Compatibility
107
118
It is desirable to have warmboot functionality from previous release versions of Sonic. Since the existing schema has COPP Group name/key with protocol names (e.g `"COPP_TABLE:trap.group.bgp.lacp"`, there is a limitation in adding any new protocol or trap to an existing CoPP group and seamlessly migrate. However, with this proposal, the following options are considered:
108
119
109
120
1. The implementation is to do a migration of APP DB entries to new schema.
110
-
2. Let ```db_migrator``` remove all previously saved APP_DB entries and let syncd reconcile and remove the TRAP entries during warmboot. Later, ```coppmgr``` can reapply the traps afresh. Also remove COPP_TABLES from being saved in [backup_database](https://github.com/Azure/sonic-utilities/blob/master/scripts/fast-reboot#L234). This may require additional tests to confirm system behaviour during warmboot.
121
+
2. Let ```db_migrator``` remove all previously saved APP_DB entries and let syncd reconcile and remove the TRAP entries during warmboot. Later, ```coppmgr``` can reapply the traps afresh. Also remove COPP_TABLES from being saved in [backup_database](https://github.com/Azure/sonic-utilities/blob/master/scripts/fast-reboot#L234). This may require additional tests to confirm system behaviour during warmboot.
111
122
3. Remove '00-copp.config.json' from being included for checksum calculation in ```files/build_scripts/generate_asic_config_checksum.py```
112
123
113
124
In addition, the implementation must ensure that backward compatibility is maintained. If the system is boot-up with an *old* config file, the default CoPP tables are to be loaded from ```copp_cfg.json``` and expected to work seamlessly.
114
125
115
126
## Limitations
116
127
1. In case of downgrade, the config_db entries shall be present as stale entries as there is no subscribers for the table. Functionality would be same as supported by the downgraded version
117
-
2. This proposal expects the table names to be consistent across multiple releases.
128
+
2. This proposal expects the table names to be consistent across multiple releases.
118
129
3. User is expected to resolve any conflicts, say for a trap id or group, that arises due to default values from the Sonic binary vs same trap or group currently or previously configured by the user.
119
130
120
131
## CLI
@@ -124,7 +135,7 @@ CLI support to add/modify CoPP tables is not scoped as part of this design. In f
124
135
125
136
1. User shall be able to change policer values for a queue
126
137
2. User shall be able to change the queue for a protocol/trap
127
-
3. User shall be able to delete a group/trap.
138
+
3. User shall be able to delete a group/trap.
128
139
*In the current proposal, this would mean to keep the key in config_db with empty attributes.
129
140
130
141
# Flows
@@ -139,7 +150,7 @@ The following flow captures scenarios for ```boot-up``` sequence and ```config r
139
150
140
151
## Copp Manager flow
141
152
142
-
The following flow captures CoPP manager functionality.
153
+
The following flow captures CoPP manager functionality.
0 commit comments