So, like me, you want to have redundancy for your virtual machine network. For my lab setup, I use a refurbished Cisco router 3825 with two gigabit interfaces, two Procurve 2810-24G and a small server with 4 gigabit interfaces for the ESXi.
You just have to:
- team the NICs on the ESXi (use src-mac + beacon probing),
- use port-channel on the Cisco router and src-mac too,
- configure the switches exactly the same way as if there wasn’t any redundancy,
- add a link between the two switches and configure it to transmit the VLANs you need,
- don’t forget to add STP on the switches and put a high priority (low number) on the link between the switches.
So you should end up with the following setup:
On the ESXi , you have vSwitch0 with vmnic0 and vmnic1 teamed up. You have a VMkernel without VLAN assigned for management (ip address 10.0.0.100/24) and you have one or more VMnetwork with VLAN assigned.
On the Cisco router, you have Port-channel1 (ip address 10.0.0.1/24) with gi0/0 and gi0/1 and you have one or more VLANs configured on the port-channel1 (so you have interface Port-channel1.10 with encapsulation dot1Q 10, etc).
On the HP Procurve switches, you have no trunk configured for interfaces connected to either the ESXi ports nor the Cisco router. You put your management VLAN untagged and the other VLANs you have tagged on those ports.
You do the same to the interface connected to the other switch. If you want, you can use a LACP trunk between the two switches; then you would configure the VLANs on the trunk and not on the underlying interfaces.
Now you should ping any of the IP addresses you defined even if you start disconnecting cables or killing switches. If you start iperf and disconnect the path it’s going through, you’ll see it will stall for some seconds (up to 10 in my case) and then resume its job. When you plug back the cables, it will stall a bit again (but a lot shorter now) and resume again.
Mission accomplished. Next step is to put more links between the ESXi and the switches.
PS: do remember the goal was to have redundancy, but we also have a bit of load balancing thanks to LACP/etherchannel.
It’s MAC based so any connection between two given hosts will stay on the same link, but eventually, other connections between two other hosts will use a different path. So statistically and if you have many MAC addresses discussing with each other, you should end up with more bandwidth than before :)