Rack Cabling and Hardening the IPTV Switches Remotely

Another late night, roughly 00:06 to 03:54. The first part was about the home rack. The rest was getting the hotel IPTV system ready for a trip back later in the day and a call with the hotel's network contractor.

Rethinking the home rack cabling

I wrote out every port on the gateway and the three switches to see whether there was a better way to cable a 10 inch rack. Most of the setup was already right. Each Proxmox node has one bond leg on the 2.5G switch and the other straight on the gateway. The weak spot was pve02, whose failover leg goes through a small switch that itself reaches the gateway through the chain it is meant to cover for.

I then floated a USW-Pro-Max-24 as the main switch, with the NAS and nodes on it, an SFP+ link up to the gateway and another down to the 2.5G PoE switch for the access points. That plan had problems. It is a 19 inch 1U unit, so it won't sit in a 10 inch rack, and only 8 of its ports are 2.5G. Putting both bond legs of every node on one switch would also mean one failure takes everything down, and the bond would only protect against a bad cable.

My idea for the failovers was to run them through the 2.5G PoE switch, but then the gateway has to do the VLAN routing, which I'd rather avoid. The simpler answer is to plug the failover legs straight into the gateway ports, which keeps them independent of the new switch. I'll probably mount a 3U or 4U vertical rack under a shelf or on the ceiling, and airflow and weight are the things to check before I commit.

Getting ready for the contractor call

At 02:36 I started on what I needed to do before going back to the hotel. That became an agenda for the call, with each request written out with the reason and which device it changes, and a checklist of what I can do on my side first. Both got filed into the project.

Checking the IPTV island remotely

The island is the IPTV kit running on its own isolated network until cutover. First I checked the set-top boxes over the remote link. All 7 answer, and 6 are awake on the live player. The seventh is the one connected to a real TV and was asleep, so I left it alone. The awake boxes were pulling 1.2 to 6 Mbps each, all over the wired port. I had expected much more, but a whole broadcast is about 22 Mbps and each box only receives the one channel it is showing.

Next came screenshots and backups from the IPTV server and the tuner. The server's DHCP page showed the gateway and DNS it hands out are my travel router, which I changed on 30 September. The runsheet and the VLAN plan still had the old values, so I had those wrong and corrected both. That matters on cutover day, because once the travel router leaves, every box would point at nothing.

The server backup was 536 MB. The first download over the tunnel returned a 503, and opening the download link directly worked, so I noted that in the runsheet. I also moved the tuner's config backup and kernel log onto the NAS.

The tuner's log showed one network port dropping its link 12 times, which looked worrying until I lined it up with the first switch's own log. The gaps matched to the second, and all of them fell on Thursday and Friday evening while I was re-cabling. Nothing has dropped since Friday night, so I'm treating it as my own cabling and not a fault.

Hardening both switches from home

I saved a pre-change copy of each config first, then worked through the changes over SSH from home.

On the first switch I removed the old cloud account that allowed FTP, Telnet and plain HTTP, limited the remaining accounts to SSH and HTTPS, turned off SSH1 compatibility and made the VTY lines SSH-only. I turned spanning tree off, turned the multicast querier off on that switch, put the tuner's port in a port isolation group, and limited SSH and HTTPS logins to two addresses with an ACL.

On the second switch I shut the uplink port until cutover, turned spanning tree off, and enabled DHCP snooping with only the server's port trusted. I isolated the 7 set-top box ports and the uplink in one group. Then I limited logins with the same kind of ACL.

Every change went in with a 5 minute commit timer, so anything that locked me out would undo itself. For the login ACLs I opened a second SSH window from an allowed address before committing. The timer never had to roll anything back.

A box I rebooted still got its address with snooping on, and with isolation on the boxes kept their streams but couldn't ping each other.

The paste gotcha cost a few attempts. Pasting a whole block at once failed twice. The first time the commit timer was still running from the previous block, so the overwrite prompt swallowed the next pasted lines. The second time I pasted the second half at the user prompt without the first line that enters the config. Either way the final quit logged me out and nothing was applied. Now I paste the timer line, wait for the prompt, then paste the rest.

Still open