Welcome back! We left off with a shiny new vDS added to vCenter, each of the 4 hosts updated with a second NIC, a massive tangled birds nest of cabling semi unraveled, a giant switch jammed in the spot once occupied by the little stack that could and everything pretty much back online, blinky blinking and in need of configuration. We already touched on the enterprise grade interface in the Netgear web UI when we changed the default password (not to mention the full function CLI which we will get to in a bit), but I thought there was another interesting item in the security options worth showing:
In addition to password policies and being able to create unique user ideas with individual access control levels, you can also set specific passwords for the various management interfaces (telnet, terminal, SSH). This is a really great feature, but also something to remember to set as I do believe that the default for all of these would be blank. Be careful not to setup the whole switch just to leave a backdoor like a blank telnet password!
Next step on the switch config path is to give it a proper static IP. This is pretty straightforward. If we head over to the Network Interface subsection under the Management section of the System tab we find the IPv4 Network Configuration entry. By default, “Current Network Configuration Protocol” will be set to DHCP. This isn’t super intuitive, but to go to static, we have to switch this to “None”. You will see a warning that selecting this will reset the IP config. That’s a good thing since it is what we need to do! With “None” selected, you will be able to edit the IP info:
Another extremely cool thing here worth noting is that you can do locally administered MAC address setting on this switch. You can also set your DHCP vendor class ID string which would allow the switch to match any existing vendor class ID setup you might have configured on your existing DHCP server (so to pass it specific options, for example). Last but not least, you can set the VLAN that the management interface will be a part of.
Before getting in to VLAN setup, routing setup and the CLI, I wanted to also take a moment to show this absolutely terrific view that I am in love with in the web UI:
This is just awesome! It is a live port level view of the switch, available under the Device View section of the System tab, with real-time updated status. Clicking into the ports allows you to see all sorts of neat stuff. Rather than walk through the options, how about another screen cap?
OK, it’s now time to get in there and start configuring the switch. There are a ton of options for configuration in the 7224 and lots of ways to get to the same endpoint (normal for a rich management interface). After reading up a bit and poking around, I decided that the “VLAN Routing Wizard” accessible under VLAN off of the Routing tab was the fast path to what I needed to accomplish. The interface is fairly straightforward but does require some explanation:
Once again we get a great graphical representation of the switch. The key things to focus on here are:
- IP Address – this will become the router interface IP. It should be whatever IP address within the subnet you plan to deploy into the VLAN (or have already deployed if, as in our case, this is a switch upgrade), you want to designate as the default gateway for the subnet.
- VLAN ID – the ID you want to assign to the VLAN that the wizard will be creating.
- Port ID – very simply, you check off the ports that are to be included in this new VLAN. The options here are:
- T(Tagged) – Select the ports on which all frames transmitted for this VLAN will be tagged. The ports that are selected will be included in the VLAN.
- U(Untagged) – Select the ports on which all frames transmitted for this VLAN will be untagged. The ports that are selected will be included in the VLAN.
- BLANK(Autodetect) – Select the ports that may be dynamically registered in this VLAN via GVRP. This selection has the effect of excluding a port from the selected VLAN.
In my case I ultimately set these ports as “Untagged” since, on the old config, I did not have the default VM network and management networks tagged. Without further ado, lets have a look at the CLI and see what’s going on (who can resist a CLI?!)
For now I’m sticking with telnet to make life easier. Telnet on OSX connects up right away and accepts the creds for the admin account. A “?” at the command prompt gives you a list of top level commands. The interesting one here for now is the “show” command. “Show ?” as expected gives you the subcommands under Show. For now though, let’s just ping the hosts that should now be part of our new VLAN and see what we get:
Looking good! Now lets try from the Mac (which is living on 192.168.1.0):
Uh oh, that’s not looking healthy! Time to figure out what is going on with our routing. We know the interface is up since 192.168.2.1 is reachable from the 192.168.1.0 subnet and the switch itself can ping hosts in 192.168.2.0, so something must be missing in the routing setup. It turns out what was missing is that IP routing must be specifically enabled and it seems like this has to happen at the CLI for some reason. Counterintuitiveness is also a well honored enterprise tradition, so this very well may be by design (or I missed something). Either way, this set of commands did the trick. Note that we have to enable privileged access for this level of configuration. Privileged access enables a deeper range of settings including management of the NVRAM:
(GSM7224V2) >enable (GSM7224V2) #config (GSM7224V2) (Config)#ip routing (GSM7224V2) (Config)#exit
We can also verify that the GUI created our VLANs correctly within the standard management context by using the VLAN command:
One quick note. I ended up actually pulling the management interface out of 192.168.1.0 and turning 192.168.1.0 into a routed VLAN. I shifted the 7224’s management interface into a dedicated VLAN of its own (in this case 192.168.5.0). In my case this leaves that interface pretty much stranded since it seems the management interface can’t be routed and I don’t want to dedicate an actual physical switch port to it. The device can be managed via any accessible interface though, so I’m not sure that there will be any downside. Time will tell!
With connectivity back online between 192.168.1.0 and 192.168.2.0 and the VM Network in vCenter back online it’s a good time to break! Next up will be verifying that the VMware 802.1Q tagging is playing nice with the 7224 and defining some additional switch VLANs, and then it will be on to finishing the configuration of the vDS. After that is complete, it will be time for vCloud Director and seeing how the VCDNI and VXLAN backed network pools look! Stay tuned!