matthew/sonic-buildimage
1
0
Fork 0
Code Issues Pull Requests Actions 1 Packages Projects Releases Wiki Activity
c323ccfa72
sonic-buildimage/files/image_config/copp/copp_cfg.j2

127 lines
2.9 KiB
Plaintext
Raw Normal View History

Copp Manager Changes (#4861) *Introduce CoPP Manager infrastructure Copp service to generate initial copp config template file Co-authored-by: dgsudharsan <sudharsan_gopalarat@dell.com>
2020-11-23 11:31:42 -06:00
{
"COPP_GROUP": {
"default": {
"queue": "0",
"meter_type":"packets",
"mode":"sr_tcm",
"cir":"600",
"cbs":"600",
"red_action":"drop"
},
"queue4_group1": {
"trap_action":"trap",
"trap_priority":"4",
[copp]: Enable rate limiting for bgp, lacp, dhcp, lldp, macsec and udld (#14859) Why I did it It was observed that a flood of DHCP packets without rate-limiting can cause BGP flaps or lacp keepalive losses. This change attempts to prevent or reduce such BGP flaps by enabling appropriate rate-limiting in SONiC for all traffic types. Work item tracking Microsoft ADO 17964421: How I did it Set a reasonable CIR/CBS value of 300 for queue4_group3 (dhcp, lldp, macsec) and 6000 for queue4_group1. The value 300 was arrived at after testing with dhcp flooding using ptf (using multiple threads). Throttling at this rate was necessary to ensure that dhcp flooding does not cause BGP flaps. How to verify it Verified with this script running from ptf, that BGP flaps don't happen when CBS/CIR is set at 300 for queue4_group3. import threading from scapy.all import * def send_dhcp_discover(intf): dhcp_discover = Ether(dst='ff:ff:ff:ff:ff:ff',src=RandMAC()) \ /IP(src='1.1.1.1',dst='255.255.255.255') \ /UDP(sport=68,dport=67) \ /DHCP(options=[('message-type','discover'),('end')]) sendp(dhcp_discover,count=100000,iface=intf) if __name__ == "__main__": t1 = threading.Thread(target=send_dhcp_discover, args=("eth1",)) t2 = threading.Thread(target=send_dhcp_discover, args=("eth2",)) t1.start() t2.start() t1.join() t2.join() Verified on Arista-7260CX3-D108C8 running 202012 that the copp rule for queue4_group1 and queue4_group3 do NOT affect BGP packets. To verify this using PTF, the copp rules were modified to set the "CBS" and "CIR" for queue4_group1 and queue4_group3 at 600pps and 50k packets each of "BGP open" and "DHCP Discover" were simultaneously sent from the same PTF port to the DUT. It was verified using "show c cpu" that packets are hitting the cpu queue at 1200 pps (double the configured CIR/CBS for these packet types). This helped conclude that throttling rate is per trap (or packet type) and not per queue. Verified with updated sonic-mgmt tests ([tests/copp]: Update copp mgmt tests to support new rate-limits sonic-mgmt#8199) on broadcom and mellanox platforms that these traffic types are rate-limited. Signed-off-by: Prabhat Aravind <paravind@microsoft.com>
2023-10-25 12:49:24 -05:00
"queue": "4",
"meter_type":"packets",
"mode":"sr_tcm",
"cir":"6000",
"cbs":"6000",
"red_action":"drop"
Copp Manager Changes (#4861) *Introduce CoPP Manager infrastructure Copp service to generate initial copp config template file Co-authored-by: dgsudharsan <sudharsan_gopalarat@dell.com>
2020-11-23 11:31:42 -06:00
},
[CoPP] Add always_enabled field (#9302) *Add the "always_enabled" field to copp_cfg.j2 file, in order to allow traps without an entry in features table, to be installed automatically.
2021-11-30 13:04:15 -06:00
"queue4_group2": {
Copp Manager Changes (#4861) *Introduce CoPP Manager infrastructure Copp service to generate initial copp config template file Co-authored-by: dgsudharsan <sudharsan_gopalarat@dell.com>
2020-11-23 11:31:42 -06:00
"trap_action":"copy",
"trap_priority":"4",
"queue": "4",
"meter_type":"packets",
"mode":"sr_tcm",
"cir":"600",
"cbs":"600",
"red_action":"drop"
},
"queue4_group3": {
"trap_action":"trap",
"trap_priority":"4",
[copp]: Enable rate limiting for bgp, lacp, dhcp, lldp, macsec and udld (#14859) Why I did it It was observed that a flood of DHCP packets without rate-limiting can cause BGP flaps or lacp keepalive losses. This change attempts to prevent or reduce such BGP flaps by enabling appropriate rate-limiting in SONiC for all traffic types. Work item tracking Microsoft ADO 17964421: How I did it Set a reasonable CIR/CBS value of 300 for queue4_group3 (dhcp, lldp, macsec) and 6000 for queue4_group1. The value 300 was arrived at after testing with dhcp flooding using ptf (using multiple threads). Throttling at this rate was necessary to ensure that dhcp flooding does not cause BGP flaps. How to verify it Verified with this script running from ptf, that BGP flaps don't happen when CBS/CIR is set at 300 for queue4_group3. import threading from scapy.all import * def send_dhcp_discover(intf): dhcp_discover = Ether(dst='ff:ff:ff:ff:ff:ff',src=RandMAC()) \ /IP(src='1.1.1.1',dst='255.255.255.255') \ /UDP(sport=68,dport=67) \ /DHCP(options=[('message-type','discover'),('end')]) sendp(dhcp_discover,count=100000,iface=intf) if __name__ == "__main__": t1 = threading.Thread(target=send_dhcp_discover, args=("eth1",)) t2 = threading.Thread(target=send_dhcp_discover, args=("eth2",)) t1.start() t2.start() t1.join() t2.join() Verified on Arista-7260CX3-D108C8 running 202012 that the copp rule for queue4_group1 and queue4_group3 do NOT affect BGP packets. To verify this using PTF, the copp rules were modified to set the "CBS" and "CIR" for queue4_group1 and queue4_group3 at 600pps and 50k packets each of "BGP open" and "DHCP Discover" were simultaneously sent from the same PTF port to the DUT. It was verified using "show c cpu" that packets are hitting the cpu queue at 1200 pps (double the configured CIR/CBS for these packet types). This helped conclude that throttling rate is per trap (or packet type) and not per queue. Verified with updated sonic-mgmt tests ([tests/copp]: Update copp mgmt tests to support new rate-limits sonic-mgmt#8199) on broadcom and mellanox platforms that these traffic types are rate-limited. Signed-off-by: Prabhat Aravind <paravind@microsoft.com>
2023-10-25 12:49:24 -05:00
"queue": "4",
"meter_type":"packets",
"mode":"sr_tcm",
[image_config]: Update DHCP rate-limit for mgmt TOR devices (#17630) * [image_config]: Update DHCP rate-limit for mgmt TOR devices Change DHCP rate limit(queue4,group3) in SONiC copp configuration to 300 PPS for mgmt TORs while keeping the rate limit at 100 PPS for other topologies. Why I did it: Some mgmt TORs based on Marvell ASIC do not support 100 PPS CIR, so that led to these devices silently dropping DHCP packets. Microsoft ADO: **25820076** How to verify it: Send DHCP broadcast packets to an M0 DUT and verify that they are trapped to CPU at 300 PPS. On non-mgmt devices, the packets should be trapped at CIR of 100 PPS. Also ran sonic-mgmt dhcp_relay test and confirmed that it passes. Signed-off-by: Prabhat Aravind <paravind@microsoft.com>
2024-01-02 23:29:34 -06:00
{% if DEVICE_METADATA is defined and DEVICE_METADATA['localhost'] is defined and DEVICE_METADATA['localhost']['type'] is defined and 'Mgmt' in DEVICE_METADATA['localhost']['type'] %}
"cir":"300",
"cbs":"300",
{% else %}
[image_config]: Update DHCP rate-limit (#17132) Change DHCP rate limit in SONiC copp configuration to 100 PPS as this is necessary to ensure that DHCP flood does not cause LACP/BGP flaps in all scenarios This is an extension to the change in image_config: copp: Enable rate limiting for bgp, lacp, dhcp, lldp, macsec and udld #14859 and sonic-mgmt change in [tests/copp]: Update copp mgmt tests to support new rate-limits sonic-mgmt#8199 Why I did it 300 PPS is not sufficient to prevent LACP/BGP flaps in all cases. 100 PPS seems to provide better resiliency against DHCP traffic flood to CPU. Microsoft ADO 25776614: Send DHCP broadcast packets to DUT and verify that they are trapped to CPU at 100 PPS. Signed-off-by: Prabhat Aravind <paravind@microsoft.com>
2023-11-22 17:02:17 -06:00
"cir":"100",
"cbs":"100",
[image_config]: Update DHCP rate-limit for mgmt TOR devices (#17630) * [image_config]: Update DHCP rate-limit for mgmt TOR devices Change DHCP rate limit(queue4,group3) in SONiC copp configuration to 300 PPS for mgmt TORs while keeping the rate limit at 100 PPS for other topologies. Why I did it: Some mgmt TORs based on Marvell ASIC do not support 100 PPS CIR, so that led to these devices silently dropping DHCP packets. Microsoft ADO: **25820076** How to verify it: Send DHCP broadcast packets to an M0 DUT and verify that they are trapped to CPU at 300 PPS. On non-mgmt devices, the packets should be trapped at CIR of 100 PPS. Also ran sonic-mgmt dhcp_relay test and confirmed that it passes. Signed-off-by: Prabhat Aravind <paravind@microsoft.com>
2024-01-02 23:29:34 -06:00
{% endif %}
[copp]: Enable rate limiting for bgp, lacp, dhcp, lldp, macsec and udld (#14859) Why I did it It was observed that a flood of DHCP packets without rate-limiting can cause BGP flaps or lacp keepalive losses. This change attempts to prevent or reduce such BGP flaps by enabling appropriate rate-limiting in SONiC for all traffic types. Work item tracking Microsoft ADO 17964421: How I did it Set a reasonable CIR/CBS value of 300 for queue4_group3 (dhcp, lldp, macsec) and 6000 for queue4_group1. The value 300 was arrived at after testing with dhcp flooding using ptf (using multiple threads). Throttling at this rate was necessary to ensure that dhcp flooding does not cause BGP flaps. How to verify it Verified with this script running from ptf, that BGP flaps don't happen when CBS/CIR is set at 300 for queue4_group3. import threading from scapy.all import * def send_dhcp_discover(intf): dhcp_discover = Ether(dst='ff:ff:ff:ff:ff:ff',src=RandMAC()) \ /IP(src='1.1.1.1',dst='255.255.255.255') \ /UDP(sport=68,dport=67) \ /DHCP(options=[('message-type','discover'),('end')]) sendp(dhcp_discover,count=100000,iface=intf) if __name__ == "__main__": t1 = threading.Thread(target=send_dhcp_discover, args=("eth1",)) t2 = threading.Thread(target=send_dhcp_discover, args=("eth2",)) t1.start() t2.start() t1.join() t2.join() Verified on Arista-7260CX3-D108C8 running 202012 that the copp rule for queue4_group1 and queue4_group3 do NOT affect BGP packets. To verify this using PTF, the copp rules were modified to set the "CBS" and "CIR" for queue4_group1 and queue4_group3 at 600pps and 50k packets each of "BGP open" and "DHCP Discover" were simultaneously sent from the same PTF port to the DUT. It was verified using "show c cpu" that packets are hitting the cpu queue at 1200 pps (double the configured CIR/CBS for these packet types). This helped conclude that throttling rate is per trap (or packet type) and not per queue. Verified with updated sonic-mgmt tests ([tests/copp]: Update copp mgmt tests to support new rate-limits sonic-mgmt#8199) on broadcom and mellanox platforms that these traffic types are rate-limited. Signed-off-by: Prabhat Aravind <paravind@microsoft.com>
2023-10-25 12:49:24 -05:00
"red_action":"drop"
Copp Manager Changes (#4861) *Introduce CoPP Manager infrastructure Copp service to generate initial copp config template file Co-authored-by: dgsudharsan <sudharsan_gopalarat@dell.com>
2020-11-23 11:31:42 -06:00
},
"queue1_group1": {
"trap_action":"trap",
"trap_priority":"1",
"queue": "1",
"meter_type":"packets",
"mode":"sr_tcm",
"cir":"6000",
"cbs":"6000",
"red_action":"drop"
},
"queue1_group2": {
"trap_action":"trap",
"trap_priority":"1",
"queue": "1",
"meter_type":"packets",
"mode":"sr_tcm",
"cir":"600",
"cbs":"600",
"red_action":"drop"
},
"queue2_group1": {
"cbs": "1000",
"cir": "1000",
"genetlink_mcgrp_name": "packets",
"genetlink_name": "psample",
"meter_type": "packets",
"mode": "sr_tcm",
"queue": "2",
"red_action": "drop",
"trap_action": "trap",
"trap_priority": "1"
}
},
"COPP_TRAP": {
"bgp": {
"trap_ids": "bgp,bgpv6",
"trap_group": "queue4_group1"
},
"lacp": {
"trap_ids": "lacp",
[CoPP] Add always_enabled field (#9302) *Add the "always_enabled" field to copp_cfg.j2 file, in order to allow traps without an entry in features table, to be installed automatically.
2021-11-30 13:04:15 -06:00
"trap_group": "queue4_group1",
"always_enabled": "true"
Copp Manager Changes (#4861) *Introduce CoPP Manager infrastructure Copp service to generate initial copp config template file Co-authored-by: dgsudharsan <sudharsan_gopalarat@dell.com>
2020-11-23 11:31:42 -06:00
},
"arp": {
"trap_ids": "arp_req,arp_resp,neigh_discovery",
[CoPP] Add always_enabled field (#9302) *Add the "always_enabled" field to copp_cfg.j2 file, in order to allow traps without an entry in features table, to be installed automatically.
2021-11-30 13:04:15 -06:00
"trap_group": "queue4_group2",
"always_enabled": "true"
Copp Manager Changes (#4861) *Introduce CoPP Manager infrastructure Copp service to generate initial copp config template file Co-authored-by: dgsudharsan <sudharsan_gopalarat@dell.com>
2020-11-23 11:31:42 -06:00
},
"lldp": {
"trap_ids": "lldp",
"trap_group": "queue4_group3"
},
[dhcp_relay] Disable dhcp_relay for ToRRouter switches type by the feature manager (#7789) - Why I did it Currently dhcp packets are disabled by the COPP manager for non ToRRouter type switches. Even if the feature is enabled, DHCP packets wont hook to the CPU since the COPP manager will not trap this packets. This change is to disable dhcp_relay by default for non ToRRouter switches from init_cfg.json. With this approach, if the user want to enable the feature for non ToRRouter switches, manual enablement is required by the 'feature' configuration. This is to keep the current approach for MSFT production issue with dhcp relay for non ToRRouter switched and allow the user to decide if to use it or not. - How I did it Configure dhcp_relay 'disabled' by default on init_cfg.json for non ToRRouter switches. Remove the exclusion of dhcp packets on copp_cfg.json - How to verify it Enable dhcp_relay feature on a non ToRRouter switch. Unit-tests modified so the default values on mocked CONFIG DB in 'test_vectors.py' for dhcp_relay will be 'disabled'. This is by the change for 'init_cfg.json.j2'. For ToRRouter the state will change from 'disabled' to 'enabled'. Another test case added for a 'ToR' switch type, this is to test the state is 'enabled' if the user configured it to be so.
2021-07-08 01:10:46 -05:00
"dhcp_relay": {
Copp Manager Changes (#4861) *Introduce CoPP Manager infrastructure Copp service to generate initial copp config template file Co-authored-by: dgsudharsan <sudharsan_gopalarat@dell.com>
2020-11-23 11:31:42 -06:00
"trap_ids": "dhcp,dhcpv6",
"trap_group": "queue4_group3"
},
"udld": {
"trap_ids": "udld",
[CoPP] Add always_enabled field (#9302) *Add the "always_enabled" field to copp_cfg.j2 file, in order to allow traps without an entry in features table, to be installed automatically.
2021-11-30 13:04:15 -06:00
"trap_group": "queue4_group3",
"always_enabled": "true"
Copp Manager Changes (#4861) *Introduce CoPP Manager infrastructure Copp service to generate initial copp config template file Co-authored-by: dgsudharsan <sudharsan_gopalarat@dell.com>
2020-11-23 11:31:42 -06:00
},
"ip2me": {
"trap_ids": "ip2me",
[CoPP] Add always_enabled field (#9302) *Add the "always_enabled" field to copp_cfg.j2 file, in order to allow traps without an entry in features table, to be installed automatically.
2021-11-30 13:04:15 -06:00
"trap_group": "queue1_group1",
"always_enabled": "true"
Copp Manager Changes (#4861) *Introduce CoPP Manager infrastructure Copp service to generate initial copp config template file Co-authored-by: dgsudharsan <sudharsan_gopalarat@dell.com>
2020-11-23 11:31:42 -06:00
},
[macsec] Add eapol to copp config (#8416) This change enables the control packets of MACsec to be processed by CPU.
2021-08-23 20:56:23 -05:00
"macsec": {
"trap_ids": "eapol",
[copp]: Enable rate limiting for bgp, lacp, dhcp, lldp, macsec and udld (#14859) Why I did it It was observed that a flood of DHCP packets without rate-limiting can cause BGP flaps or lacp keepalive losses. This change attempts to prevent or reduce such BGP flaps by enabling appropriate rate-limiting in SONiC for all traffic types. Work item tracking Microsoft ADO 17964421: How I did it Set a reasonable CIR/CBS value of 300 for queue4_group3 (dhcp, lldp, macsec) and 6000 for queue4_group1. The value 300 was arrived at after testing with dhcp flooding using ptf (using multiple threads). Throttling at this rate was necessary to ensure that dhcp flooding does not cause BGP flaps. How to verify it Verified with this script running from ptf, that BGP flaps don't happen when CBS/CIR is set at 300 for queue4_group3. import threading from scapy.all import * def send_dhcp_discover(intf): dhcp_discover = Ether(dst='ff:ff:ff:ff:ff:ff',src=RandMAC()) \ /IP(src='1.1.1.1',dst='255.255.255.255') \ /UDP(sport=68,dport=67) \ /DHCP(options=[('message-type','discover'),('end')]) sendp(dhcp_discover,count=100000,iface=intf) if __name__ == "__main__": t1 = threading.Thread(target=send_dhcp_discover, args=("eth1",)) t2 = threading.Thread(target=send_dhcp_discover, args=("eth2",)) t1.start() t2.start() t1.join() t2.join() Verified on Arista-7260CX3-D108C8 running 202012 that the copp rule for queue4_group1 and queue4_group3 do NOT affect BGP packets. To verify this using PTF, the copp rules were modified to set the "CBS" and "CIR" for queue4_group1 and queue4_group3 at 600pps and 50k packets each of "BGP open" and "DHCP Discover" were simultaneously sent from the same PTF port to the DUT. It was verified using "show c cpu" that packets are hitting the cpu queue at 1200 pps (double the configured CIR/CBS for these packet types). This helped conclude that throttling rate is per trap (or packet type) and not per queue. Verified with updated sonic-mgmt tests ([tests/copp]: Update copp mgmt tests to support new rate-limits sonic-mgmt#8199) on broadcom and mellanox platforms that these traffic types are rate-limited. Signed-off-by: Prabhat Aravind <paravind@microsoft.com>
2023-10-25 12:49:24 -05:00
"trap_group": "queue4_group1"
[macsec] Add eapol to copp config (#8416) This change enables the control packets of MACsec to be processed by CPU.
2021-08-23 20:56:23 -05:00
},
Copp Manager Changes (#4861) *Introduce CoPP Manager infrastructure Copp service to generate initial copp config template file Co-authored-by: dgsudharsan <sudharsan_gopalarat@dell.com>
2020-11-23 11:31:42 -06:00
"nat": {
"trap_ids": "src_nat_miss,dest_nat_miss",
"trap_group": "queue1_group2"
},
"sflow": {
"trap_group": "queue2_group1",
"trap_ids": "sample_packet"
}
}
}
Reference in New Issue Copy Permalink