Dlink switch study after thunderstorms

The article you are currently reading is an extension of the article " Setting Access Level Switches in the Provider's Network ". I justify the correctness of the approach of the author screens and their observations. So, the photo of the test.



Just like in the DMB film, the plot is about the gopher: I also don’t see any cables, but there are links. Switch settings reset to factory default #reset system command.

For clarity, a few more screenshots:
')




The links have risen, the switch works, but how it is busy will tell us wireshark and see an amazing picture:



The screenshot shows a large number of ARP packets that the switch itself generates, presumably as a result of the activity of the failed ports. Based on this, we enable the Loop Detection function, the function is intended to form a switch tree using the STP protocol, but it also works when the STP is disabled:

enable loopdetect
config loopdetect mode vlan-based
config loopdetect recover_timer 1800
config loopdetect interval 10
config loopdetect ports 1-9 state enable

Here is how the situation has changed:





After applying the Loop Detection setting, a record is detected in the switch logs about the detected ring on the faulty port, the port itself goes into err-disabled mode, as can be seen in the screenshots attached above ( mode vlan-based allows you to configure ring detection on trunks, as a result only the traffic from the vlan in which the ring is detected, while the remaining vlans will work as normal).

The type of traffic caught by wereshark has also changed. Now we see a large number of dhcp requests (on the connected computer, the setting for automatically obtaining an IP address).



From this it follows that the situation with broadcast traffic has not changed. This adversely affects the functioning of the network, as Broadcast packets are cloned by switches, and this leads to such a phenomenon as a broadcast storm. Based on this, it was decided to limit the amount of broadcast traffic through a command (if the number of packets exceeds the level, then the packets are discarded):

config traffic control 1-9 broadcast enable action drop threshold 64 countdown 5 time_interval 30

In addition, we will forbid the switch to skip the DHCP request from all ports except Uplink. In addition to restricting traffic, we get the ability to block subscriber dhcp-server Configuration example via CLI - ACL setting, which allows sending DHCP responses from port 10 and prohibiting from all other ports:

create access_profile ip udp src_port_mask 0xFFFF profile_id 1
config access_profile profile_id 1 add access_id 1 ip udp src_port 67 port 10 permit
config access_profile profile_id 1 add access_id 2 ip udp src_port 67 port 1-9 deny


What was it all for, and what did you get as a result

So, after the configuration, we have normal traffic on the working port, small bursts of broadcast traffic, since the failed ports periodically turn on by timeout. In addition, in the logs we get a line of the form “Port 1 VID 156 LBD recovered. Loop detection restarted ”, and if necessary, trap to the monitoring server.

All efforts will allow methodically working to eliminate the consequences of a thunderstorm in the conditions of a city network (replacement of switches). As practice has shown (more than 5 years in a communications operator as a network administrator) Dlink DES3200-series loves thunderstorms very much.

Thanks for taking the time to read. Special thanks to colleagues for your comments and recommendations, as well as interest in this study.

PS
Cycle of articles Constructive admin's laziness or how I have automated the config whose purpose is to reduce the burden on all your favorite computer users as network administrator.