There is a bunch of stuff I intend to put in this file. Lots of examples, lots of stories, lots of stuff that all has to do with the switches at CCCC. The switches are key to any digital activity in the church, and up until now they have been neglected.

At the time of this writing our main switches are Engenius switches that appear have been installed in 2008. They had never had their firmware updated or anything other than the default settings configured.

Then along came Dante - the digital audio networking system consisting of lots of stuff that uses established protocols. Protocols that require some specific, non-default switch configuring.

When Dante was first installed, the entire network was overwhelmed and died. It was an actual DoS attack, but we were attacking ourselves. The problem was that Dante (in our case) uses Multicast addressing and our switches were not configured properly for Multicast which resulted in a storm of traffic hitting every device non-stop.

To make it even more interesting, the engenius switches did not fully support Multicast - about 12 years after they were installed.

The point is that along with all the other sorts of network components that need attention and understanding, don't forget the switches. Get familiar with the IP protocols we use. Get familiar with tcpdump and wireshark.

Minutes before starting the 2021 Sader Facebook stream, I was in the studio talking with Steve S. I happened to remember that I wanted to share with him what the leds on the Cisco switch in the studio ment. While the leds mean different things on different switches, in this case there are 2 port leds for each port. If only the left is lit, it is running at 100 Mbps. All of ours should have both leds lit green indicating it is running at 1 Gbps.

At the same time, we noticed that a yellow cable had only the left let lit. And that cable ran to the wall! Everything in that room was running from a 1 Gbps switch to another 1 Gbps switch but the cable was only allowing 100 Mbps. Real bad news! So I ran and grabbed my tightly guarded 100 meter cable and ran it from the studio, down the hall, down another hall, around a corner and into a closet to the other switch. That gave us two green lit leds. The stream that night was perfect!

The moral of this story is that you need to learn what all of the led indicators on all of your devices mean, and then pay attention to them. The devil is in the little details - actually he gets into whatever he can.

Setting up the studio switch to do port mirroring so I can sniff that entier switch.

https://www.cisco.com/c/en/us/support/docs/smb/switches/cisco-350-series-managed-switches/smb5327-configure-remote-switch-port-analyzer-rspan-settings-on-the.html

Switch Port Analyzer (SPAN), or sometimes called port mirroring or port monitoring, chooses network traffic for analysis by a network analyzer. The network analyzer can be a Cisco SwitchProbe device or other Remote Monitoring (RMON) probe.

Port mirroring is used on a network device to send a copy of network packets seen on a single device port, multiple device ports, or an entire Virtual Local Area Network (VLAN) to a network monitoring connection on another port on the device. This is commonly used for network appliances that require monitoring of network traffic, such as an intrusion-detection system. A network analyzer connected to the monitoring port processes the data packets for diagnosing, debugging, and performance monitoring.

Also see this for info on SPAN
https://support.telosalliance.com/article/c5zq9gb36k-configuring-a-monitor-span-port-on-a-cisco-sg-350

SPAN Local SPAN: Mirrors traffic from one or more interface on the switch to one or more interfaces on the same switch.

Remote SPAN (RSPAN): An extension of SPAN called remote SPAN or RSPAN. RSPAN allows you to monitor traffic from source ports distributed over multiple switches, which means that you can centralize your network capture devices. RSPAN works by mirroring the traffic from the source ports of an RSPAN session onto a VLAN that is dedicated for the RSPAN session. This VLAN is then trunked to other switches, allowing the RSPAN session traffic to be transported across multiple switches. On the switch that contains the destination port for the session, traffic from the RSPAN session VLAN is simply mirrored out the destination port.