I recently ran out of ports on my HP V1910-24G switch, so I purchased a Cisco SG300-52 switch to add capacity, try something new, and test the waters on a multi-vendor lab build out. After a half day of fiddling with the equipment, I’ve got it all installed and in production. Additionally, I took the time to swap out a white box running Untangle 10 and inserted my Meraki MX60W into the mix as the primary, production security appliance. This post will detail the steps to get a new switch added to the stack and migrate in a new security appliance.
On a side note, my white box for the Untangle will be 10 years old in a few months and runs on an Atom CPU – I’m quite amazed it has held up this long and performed so well. 🙂
I waffled a bit on how to connect the two switches. Normally I’d shoot for L3 to avoid any spanning tree goofiness, but that invited all sorts of caveats that are unique to a home lab (such as the broadcast domain for my Plex virtual machine). I ultimately created a simple design for a L2 trunk to connect the switches together, thus extending VLANs into the Cisco switch and keeping L3 SVIs on the HP. This design had the least impact on current state.
To do this, I mapped out 4 ports that would be used as a port channel between the switches. I used my whiteboard, especially important as the numbering schemes between the two vendors do not match. HP numbers from left to right, while Cisco numbers from top to bottom. This isn’t a normal Cisco numbering scheme, but is reality for the SG300 line. Thus, HP ports 1-4 would connect to Cisco ports 1-2,25-26.
I tried to first use LACP, but the HP complained that the ports were not configured properly. So, I used a static “mode on” EtherChannel instead. In this particular use case, it’s not a huge deal: I have a static number of VLANs and I don’t see the trunk between the switches being modified with any frequency.
The SG300-52 is limited to 8 port channels, so I used Po8 on both the HP and Cisco for consistency.
Building a LAG on the Cisco SG300-52 is a little bit different from a Nexus switch. Make sure to define the member ports for the LAG first, then apply the VLAN details to the LAG. If you try applying VLAN details to the member ports, the LAG will not form because the “port belongs to a VLAN.”
Core2#sh run int po8 interface Port-channel8 flowcontrol auto description TO-HP-SWITCH switchport trunk allowed vlan add 10,20,30,40,50,60 ! Core2#sh run int ge1-2 interface gigabitethernet1 description TO-HP-SWITCH channel-group 8 mode on ! interface gigabitethernet2 description TO-HP-SWITCH channel-group 8 mode on
I also placed an IP on VLAN 20 to provide L3 management connectivity to the switch.
interface vlan 20 name Lab ip address 172.16.20.2 255.255.255.0 ! ip default-gateway 172.16.20.1 ip route 172.16.20.0 /24 172.16.20.1
Finally, I set the spanning tree priority to max to avoid becoming the root bridge.
spanning-tree priority 61440
At this point, I connected my trunk cables between the two switches and made sure that I could hit the SVI on the HP switch. I’m using 2 cables for now, but have more on order.
I want most of the traffic to be local to a switch, with little traffic needing to use the switch-to-switch trunk. I separated out the network into two distinct zones: a top zone of management and home resources, and a bottom zone of lab resources.
As an added bonus, the Meraki is providing guest wireless access that is completely out of band from my internal networks. And I can throttle the bandwidth on it. 😉
ESXi Host Migration
Host network migration was rather simple because I have all networks dual connected. Once I made sure the Cisco ports were properly configured for the VLANs I needed, it was just a matter of walking one link over to the Cisco switch at a time. I’m a bit of label and color code freak, which made the migration incredibly simple. Blue are IP Storage connections, orange are general LAN connections. The labels are also lettered, which tells me which network port is being moved (A is the first port on the server, B is the second, and so on). The letters match the bus discovery order, too.
[symple_box color=”red” fade_in=”true” float=”center” text_align=”left” width=””]
Looking for these ties? They are called Marker Cable Ties and are sold in 100 unit packs for cheap!
The switchport config looks like this:
Core2#sh run int ge5 interface gigabitethernet5 description ESX1 spanning-tree portfast switchport trunk allowed vlan add 10,20,30,40,50,60 !
I also cleaned up the management host connections on the HP switch by moving them over to the left. I kept a bank of 4 empty ports near ESXM1 because I plan to procure ESXM2 (a second management host) very soon.
With that completed, there really wasn’t much left on the HP switch anymore.
I also kind of like the HP port status panel because the Cisco LEDs are a bit buried in cables. However, there would be no place to put a port status panel on the SG300-52 because the entire face is covered in switchports. 🙂
Security Appliance Replacement
The final order of business was swapping out an Untangle appliance for a Meraki MX60W, which I unboxed in this video. Since I have very few firewall and port forward rules configured, this wasn’t all that bad. The first order of business was to define the VLANs and routes. Although the “use a single VLAN” method would work for a simple L3 network, I wanted to move my VLAN 15 for guest wireless up to the Meraki and get it off my network.
VLAN 99, my transit network, was configured to be identical to the Untangle configuration. Meaning the security appliance (Meraki) would be on 172.16.99.1 /29, while the HP SVI would be on 172.16.99.2 /29. I can have duplicate IPs for now because the Meraki is not yet inserted into the network. I also went and created static routes for my other networks to keep L3 switching on my HP, rather than trunking all of the networks directly into the Meraki.
As a reminder, the only reason I have a route to the NFS network is for the Synology NAS arrays, which are auto-grabbing DSM updates and syncing data to Amazon Glacier. Once the configuration was saved and validated, I unplugged the Untangle box and changed the cabling over to the Meraki. I went ahead and rebooted my cable modem to ensure that it recognized a new device and would assign it an IP address via DHCP.
After a successful round of ping tests to ensure that I had end-to-end connectivity back to my loving Interwebs, I manually re-created the few firewall and port forward rules needed for various services and tested them, too.
This was quite a fun brain puzzle, especially trying to move everything while it was running without accidentally breaking connectivity. My new network stack is much smaller. I’ve removed a little unmanaged switch that my workstation and IP phone were using and plugged those ports into my Linksys access point, which is discussed in this post. I’ve also pitched a small shuttle box that was running my Untangle appliance.
Here is the full network stack in all of its glory. Plenty more ports to go!
Because some equipment moved a little, I had to use temporary network cables. I’ll definitely be picking up new ones with the correct length and color in the future. My workbench is covered in odd colors and lengths of cable, along with ties that are no longer required.