CLI

You are currently browsing articles tagged CLI.

Over the last day or so I’ve been messing around at the UNIX command line on my Mac, trying to find a workaround for a VPN policy that doesn’t allow split tunneling. (Just as a stupid side question, what is the security issue with split tunneling, anyway?) Along the way, I uncovered some handy commands for gathering information about the networking configuration of your Mac.

I can’t take credit for all of these; most of them were shared with me by Matt Cowger, fellow VCDX and vSpecialist.

If anyone has any additional commands they’d like to share, I encourage you to add them to the comments on this post. Enjoy!

To find the IP address of the default gateway:

netstat -nr -f inet | grep default | grep en | awk '{print $2}'

To find the interface name of the default route:

netstat -nr -f inet | grep default | grep en | awk '{print $6}'

To find the IP address assigned to the interface for the default gateway:

ORGGWIF=`netstat -nr -f inet | grep default | grep en | awk '{print $6}'`
ifconfig $ORGGWIF | grep "inet " | awk '{print $2}'

To find the default gateway network:

ORGGWIF=`netstat -nr -f inet | grep default | grep en | awk '{print $6}'`
netstat -I $ORGGWIF -n | grep -v : | grep $ORGGWIF | awk '{print $3}'

To find the subnet mask for the default gateway network:

ORGGWIF=`netstat -nr -f inet | grep default | grep en | awk '{print $6}'`
system_profiler SPNetworkDataType | grep -A 15 $ORGGWIF | grep "Subnet Masks" | awk '{print $3}'

To convert the subnet mask into CIDR format:

ORGGWIF=`netstat -nr -f inet | grep default | grep en | awk '{print $6}'`
ORGGWMASK=`system_profiler SPNetworkDataType | grep -A 15 $ORGGWIF | grep "Subnet Masks" | awk '{print $3}'`
echo obase=2.$ORGGWMASK | tr . \; | bc | tr -d 0\\n | wc -c | awk '{print $1}'

To determine the wireless SSID to which your Mac is currently associated:

/System/Library/PrivateFrameworks/Apple80211.framework/Versions/A/Resources/airport -I | grep SSID | tail -n 1 | awk '{print $2}'

CLI gurus and wizards are encouraged to share other useful commands in the comments below. Thanks!

Tags: , , ,

This post is probably old news to experienced UNIX sys admins, but I thought the information might be useful to less knowledgeable folks like me. I also hope that the resulting conversation will help uncover even more knowledge we can all put to good use.

I’ve messed around with the screen utility off and on for a while. One thing I’d never quite figured out, though, was how using screen helped with SSH sessions. I kept seeing references to using screen to help keep things running when you needed to disconnect from an SSH session. That seems like a useful feature, so I decided to dig into it and see what I could figure out.

In the end, what I figured out was this:

  • I needed to install screen on the remote host(s). In my case, the remote hosts were OpenBSD (I removed the secret back doors), so a quick pkg_add corrected that issue.
  • I had to recreate my .screenrc file on the remote host(s). Fortunately, my .screenrc is very simple—it only enables the ability to use the iTerm2/Terminal scrollbar to scroll back and increases the scrollback buffer—so that was no big deal.

With these changes in place, you can then use this command to connect to a remote host:

ssh -t <server.domain.name> screen -R

On the first connection, this command will create a new screen session. When you’re done with this SSH session and want to disconnect, just detach from the screen session (typically using Ctrl-a d). That also disconnects the SSH session, but here’s the kicker: your screen session is still running—as are any processes you had running in that session.

When you go to reconnect, use the same command again and it will reconnect you to your existing screen session and you’ll be right back where you left off. Pretty handy!

<aside>By the way, the -t in the SSH command is necessary; without it, you’ll get a “Must be connected to a terminal” error message and it won’t work properly.<aside>

I’m sure this barely scratches the surface of the useful tricks one could perform using screen, so I challenge any and all readers to submit other useful tricks in the comments below. Or, if there is a better way of doing what I’m discussing in this article, please speak up!

Tags: , ,

Trying iTerm2

In 2007 I posted an article about iTerm, an open source terminal application for Mac OS X. At that time, I gave up on iTerm and switched back to the Apple-supplied Terminal.app. For a while, it seemed as if iTerm was stagnating and development had stalled.

However, I recently learned that some developers forked the original iTerm to create iTerm2. Like the original iTerm, iTerm2 supports AppleScript and tabbed terminals. The tabbed terminals I don’t really care about (I don’t use tabs, generally speaking), but I do like AppleScript support (in case you hadn’t picked that up already). There are also some other interesting features: split panes, a Visor-like window accessible via hotkey, and Growl support.

So I installed the latest build of iTerm2, and so far it’s been very stable. My only complaint has been that you can’t configure iTerm2 to spawn new windows instead of new tabs by default. Key point: I started using the Remote Hosts plug-in for Quicksilver (great plug-in, by the way). Once I reconfigured iTerm2 as the handler for ssh:// URIs, the plug-in stopped spawning Terminal.app windows and starting spawning iTerm2 tabs instead. Unfortunately, I haven’t been able to figure out how to tell it to spawn a new iTerm2 window instead. (Feel free to chime in with ideas.)

I also whipped up a quick AppleScript that I can invoke with FastScripts; the purpose of this script is to open a new iTerm2 terminal window at the same directory as the frontmost Finder window.

I’m going to continue to work with iTerm2 as my primary terminal application for a while to see how it works. If anyone has any tips or tricks to share, please add them in the comments below. Thanks!

Tags: , ,

That’s right folks, it’s time for another installation of Technology Short Takes. This is Technology Short Take #11, and I hope that you find the collection of items I have for you this time around both useful and informative. But enough of the introduction—let’s get to the good stuff!

Networking

  • David Davis (of Train Signal) has a good write-up on the Petri IT Knowledgebase on using a network packet analyzer with VMware vSphere. The key, of course, is enabling promiscuous mode. Read the article for full details.
  • Jason Nash instructs you on how to enable jumbo frames on the Nexus 1000V, in the event you’re interested. Jason also has good coverage of the latest release of the Nexus 1000V; worth reading in my opinion. Personally, I’d like Cisco to get to version numbers that are a bit simpler than 4.2(1) SV1(4).
  • Now here’s a link that is truly useful: Greg Ferro has put together a list of Cisco IOS CLI shortcuts. That’s good stuff!
  • There are a number of reasons why I have come to generally recommend against link aggregation in VMware vSphere environments, and Ivan Pepelnjak exposes another one that rears its head in multi-switch environments in this article. With the ability for vSphere to utilize all the uplinks without link aggregation, the need to use link aggregation isn’t nearly as paramount, and avoiding it also helps you avoid some other issues as well.
  • Ivan also tackles the layer 2 vs. layer 3 discussion, but that’s beyond my pay grade. If you’re a networking guru, then this discussion is probably more your style.
  • This VMware KB article, surprisingly enough, seems like a pretty good introduction to private VLANs and how they work. If you’re not familiar with PVLANs, you might want to give this a read.

Servers

  • Want to become more familiar with Cisco UCS, but don’t have an actual UCS to use? Don’t feel bad, I don’t either. But you can use the Cisco UCS Emulator, which is described in a bit more detail by Marcel here. Very handy!

Storage

  • Ever find yourself locked out of your CLARiiON because you don’t know or can’t remember the username and password? OK, maybe not (unless you inherited a system from your predecessor), but in those instances this post by Brian Norris will come in handy.
  • Fabio Rapposelli posted a good write-up on the internals of SSDs, in case you weren’t already aware of how they worked. As SSDs gain traction in many different areas of storage, knowing how SSDs work helps you understand where they are useful and where they aren’t.
  • Readers that are new to the storage space might find this post on SAN terminology helpful. It is a bit specific to Cisco’s Nexus platform, but the terms are useful to know nevertheless.
  • If you like’s EMC’s Celerra VSA, you’ll also like the new Uber VSA Guide. See this post over at Nick’s site for more details.
  • Fellow vSpecialist Tom Twyman posted a good write-up on installing PowerPath/VE. It’s worth reading if you’re considering PP/VE for your environment.
  • Joe Kelly of Varrow posted a quick write-up about VPLEX and RecoverPoint, in which he outlines one potential issue with interoperability between VPLEX and RecoverPoint: how will VPLEX data mobility affect RP? For now, you do need to be aware of this potential issue. For more information on VPLEX and RecoverPoint together, I’d also suggest having a look at my write-up on the subject.
  • I won’t get involved in the discussion around Open FCoE (the software FCoE stack announced a while back); plenty of others (J Metz speaks out here, Chad Sakac weighed in here, Ivan Pepelnjak offers his opinions here, and Wikibon here) have already thrown in. Instead, I’ll take the “Show me” approach. Intel has graciously offered me two X520 adapters, which I’ll run in my lab next to some Emulex CNAs. From there, we’ll see what the differences are under the same workloads. Look for more details from that testing in the next couple of months (sorry, I have a lot of other projects on my plate).
  • Jason Boche has been working with Unisphere, and apparently he likes the Unisphere-VMware integration (he’s not alone). Check out his write-up here.

Virtualization

  • For the most part, a lot of people don’t have to deal with SCSI reservation conflicts any longer. However, they can happen (especially in older VMware Infrastructure 3.x environments), and in this post Sander Daems provides some great information on detecting and resolving SCSI reservation conflicts. Good write-up, Sander!
  • If you like the information vscsiStats gives you but don’t like the format, check out Clint Kitson’s PowerShell scripts for vscsiStats.
  • And while we’re talking vscsiStats, I would be remiss if I didn’t mention Gabe’s post on converting vscsiStats data into Excel charts.
  • Rynardt Spies has decided he’s going Hyper-V instead of VMware vSphere. OK, only in his lab, and only to learn the product a bit better. While we all agree that VMware vSphere far outstrips Hyper-V today, Rynardt’s decision is both practical and prudent. Keep blogging about your experiences with Hyper-V, Rynardt—I suspect there will be more of us reading them than perhaps anyone will admit.
  • Brent Ozar (great guy, by the way) has an enlightening post about some of the patching considerations around Azure VMs. All I can say is ouch.
  • The NIST has finally issued the final version of full virtualization security guidelines; see the VMBlog write-up for more information.
  • vCloud Connector was announced by VMware last week at Partner Exchange 2011 in Orlando. More information is available here and here.
  • Arnim van Lieshout posted an interesting article on how to configure EsxCli using PowerCLI.
  • Sander Daems gets another mention in this installation of Technology Short Takes, this time for good information on an issue with ESXi and certain BIOS revisions of the HP SmartArray 410i array controller. The fix is an upgrade to the firmware.
  • Sean Clark did some “what if” thinking in this post about the union of NUMA and vMotion to create VMs that span multiple physical servers. Pretty interesting thought, but I do have to wonder if it’s not that far off. I mean, how many people saw vMotion coming before it arrived?
  • The discussion of a separate “management cluster” has been getting some attention recently. First was Scott Drummonds, with this post and this follow up. Duncan responded here. My take? I’ll agree with Duncan’s final comment that “an architect/consultant will need to work with all the requirements and constraints”. In other words, do what is best for your situation. What’s right for one customer might not be right for the next.
  • And speaking of vShield, be sure to check out Roman Tarnavski’s post on extending vShield.
  • Interested in knowing more about how Hyper-V does CPU scheduling? Ben Armstrong is happy to help out, with Part 1 and Part 2 of CPU scheduling with Hyper-V.
  • Here’s a good write-up on how to configure Pass-Through Switching (PTS) on UCS. This is something I still haven’t had the opportunity to do myself. It kind of helps to actually have a UCS for stuff like this.

It’s time to wrap up now; I think I’ve managed to throw out a few links and articles that someone should find useful. As always, feel free to speak up in the comments below.

Tags: , , , , , , , , , ,

An Introduction to the VPLEX CLI

The VPLEX command line interface (CLI) is a bit different than a lot of other CLIs with which I’ve worked. In some respects, it’s similar to the scope-based CLI that Cisco uses with Unified Computing System (UCS). In this post, I’d like to explore the VPLEX CLI a bit and provide a brief introduction to the VPLEX CLI. Keep in mind that this is just an introduction—for a complete reference to the VPLEX CLI, I’ll refer you to the VPLEX product area on EMC PowerLink where a complete VPLEX CLI User’s Guide is available in PDF.

In my opinion, there are two things to know about the VPLEX CLI that will help you understand how to use it:

  1. First, the CLI is a lot like navigating a directory tree, except that you’re navigating through contexts instead of directories. In the VPLEX CLI, you move between contexts using the cd command and list the contents of a context using the ls and ll commands. Just as with a typical filesystem, if you’re in the right context, you can just run a command (say, like the unclaim command). If you’re not in the right context, you simply specify the full context before the command (I’ll show you some examples later in this post).
  2. Second, the VPLEX CLI supports wildcards and globbing, much like a typical filesystem. Use the asterisk (*) character to represent anything in a context, and use the double asterisk (**) to represent multiple matches across multiple contexts. You can use regular expressions as well.

With these concepts in mind, the real key to using the VPLEX CLI is simply learning where all the various objects reside. For example, in an earlier post on VPLEX storage objects, I discussed the building blocks of storage in a VPLEX environment: storage volumes, extents, devices, and virtual volumes. These reside in different places in the VPLEX contextual tree:

Storage volumes: /clusters/<cluster name>/storage-elements/storage-volumes
Extents: /clusters/<cluster name>/storage-elements/extents
Devices: /clusters/<cluster name>/devices
Distributed devices: /distributed-storage/distributed-devices
Virtual volumes: /clusters/<cluster name>/virtual-volumes

Within each of these contexts, you can use the ls and ll commands to view the contents of that context. The help command will show you what other commands are available in each context.

Here’s my first example. When you first log into the VPLEX CLI, you’ll get dropped into a “root context”. Running ls here will produce output something like this:

VPlexcli:/> ls
clusters    data-migrations  distributed-storage  engines  management-server
monitoring  notifications    system-defaults

Let’s take a look at a few more examples. For example, the following two sets of commands will produce the same output:

cd /clusters
ll

and

ll /clusters

Remember that specifying the context in the command is the same as changing into that context and then running the command. That is why these two commands produce the same output.

To view the list of directors in a cluster:

ll /engines/*/directors

This is an example of using the asterisk to represent a wildcard that matches all entries in that context.

Let’s look at another example of two different commands that produce the same output. To view the status of the ports on a particular director in a cluster, you could use either of these two commands:

ll /engines/<engine name>/directors/<director name>/hardware/ports

or

cd /engines/<engine name>/directors/<director name>/hardware/ports
ll

By the way, if you haven’t figured it out yet, you can easily get the names of the engines (or the directors) by simply running the ll command against the engines context or the directors context within a specific engine.

But what if you wanted to see the status of the ports across multiple directors? Now you won’t want to use the cd command. You’ll want to use globbing with wildcards instead, like this:

ll /engines/**/ports

While the single asterisk matches anything within a context, the double asterisk matches across multiple contexts. So, in this case, it ends up matching multiple engines and directors within those engines.

And if you wanted to see only some of the front-end ports on all directors:

ls /engines/**/hardware/ports/*1-FC0[0-3]

In some cases, you might need to set an attribute on an object within a context. For example, you might need to enable a port by setting the enabled attribute on that port to True. Here’s how you would do that:

set /engines/<engine name>/directors/<director name>/hardware/ports/A0-FC00::enabled true

If you think about it, you could easily combine some globbing to enable multiple ports at the same time:

set /engines/**/hardware/ports/A0-FC0[0-3]::enabled true

You can then verify the operation by using the -t parameter to the ls command, which instructs it to include attributes:

ls -t /engines/**/hardware/ports/A0-FC0[0-3]::enabled

There are many, many more examples I could share with you, but this should get you started for now. I hope to have a post up soon with a CLI guide to setting up storage volumes, extents, devices, and virtual volumes.

As usual, feel free to speak up in the comments if you have any questions or clarifications. Thank you!

Tags: , , ,

As a quick follow-up to yesterday’s article about interoperability between RecoverPoint and the vStorage APIs for Array Integration (VAAI), I wanted to post a short “how to” on disabling VAAI for interoperability with RecoverPoint. I’ll show you how to disable all three VAAI primitives, but keep in mind that only the hardware-accelerated copy and hardware-accelerated zero functions need to be disabled if you are using array-based splitters (all three need to be disabled with fabric splitters).

Given that the future of VMware vSphere is ESXi, I’m using the vSphere Management Assistant (vMA) here as the basis for disabling VAAI from the command-line interface (CLI).

To disable hardware-accelerated copy, use the following command:

vicfg-advcfg --set 0 DataMover/HardwareAcceleratedMove --vihost <ESX/ESXi host to reconfigure> --server <vCenter Server> --username <vCenter Server username>

This will prompt for the password of the specified user account unless you’ve already configured some other form of authentication.

To disable hardware-accelerated zero, use this command:

vicfg-advcfg --set 0 DataMover/HardwareAcceleratedInit --vihost <ESX/ESXi host to reconfigure> --server <vCenter Server> --username <vCenter Server username>

Finally, for the sake of completeness, here’s how to disable the hardware-accelerated locking (note that RecoverPoint with array-based splitters does support this feature currently):

vicfg-advcfg --set 0 VMFS3/HardwareAcceleratedLocking --vihost <ESX/ESXi host to reconfigure> --server <vCenter Server> --username <vCenter Server username>

I’m still chasing down possible ways to restrict the use of VAAI in a more granular fashion, as using the commands above disable VAAI functionality for the entire VMware ESX/ESXi host. As soon as I have more information, I’ll post it here.

Tags: , , , , ,

I was experimenting tonight with some ways to add more automation to my workflow. One process that is (relatively) time-consuming is the process of generating short URLs via bit.ly. This site had a brief tutorial on how to use curl to do it, but the shortened link didn’t show up in my link history. Upon browsing the bit.ly API documentation, though, I was able to fairly quickly piece together a command line that will shorten a URL via bit.ly and put the shortened URL in the user’s link history.

Note that in order to use this command, you’ll need your bit.ly API key. Your API key is easily accessed from your account settings page.

Here’s the command I tested (works on Mac OS X 10.6.4):

curl 'http://api.bit.ly/v3/shorten?login=<bit.ly login>&apiKey=<bit.ly API key>&longURL=<Long URL to be shortened>&format=txt'

In order to make this truly usable, there are some additional things that have to happen. The long URL has to be properly encoded, as it can’t have any spaces or special characters, for example. But otherwise, this command is a workable solution to shortening a URL from the command line. All I need now is a small AppleScript around this and then I’ll have a URL shortening script I can bind to a hotkey. That should help speed the process up!

Tags: , ,

Readers who also follow me on Twitter have probably noticed that I’ve been in an EMC Symmetrix VMAX training class this week. As part of that class, we’ve been working with Auto-Provisioning Groups. For other users who might be new to SYMCLI (the Symmetrix CLI) and Auto-Provisioning Groups (APGs), I thought this “new user’s guide” to APGs via the CLI might be handy. Comments from experienced users are welcome! In future posts, I’ll provide some additional commands for modifying and viewing APGs via CLI.

Note that this guide doesn’t discuss the requirements for SYMCLI (such as Solutions Enabler) or other prerequisites. I’ll likely cover those pieces in future blog posts.

An APG, at its most basic level, consists of four items:

  1. A storage group containing one or more devices or device groups
  2. A port group containing one or more front-end director ports
  3. An initiator group containing one or more host initiator ports, denoted by their World Wide Port Name (WWPN)
  4. A masking view that combines a storage group, a port group, and an initiator group

OK, with that (very) basic introduction out of the way, here are some commands to create an APG from the command line.

To create a storage group, use this command:

symaccess -sid <Symmetrix ID> create -name <Storage group name> -type storage -devs <Device IDs>

The device IDs are the IDs of the Symmetrix Logical Volumes you created using SYMCLI or Symmetrix Management Console (SMC).

To create a port group containing one or more ports from one or more directors, use this command:

symaccess -sid <Symmetrix ID> create -name <Port group name> -type port -dirports <Director slice:Port number,Director slice:port number...>

The Director slice:Port number would look something like 7e:0 for port 0 on director slice 7e (which would be in enclosure 4).

To create an initiator group, I would first recommend that you create a text file containing a list of all the WWPNs for the initiators in the group, like this:

WWN:1234567890abcdef
WWN:abcdef0123456789
...

Once you have the text file created, you can then create an initiator group using this command:

symaccess -sid <Symmetrix ID> create -name <Initiator group name> -type inititator -file <Text file of initiators>

At this point, you can run symaccess -sid <Symmetrix ID> list and you’ll see the storage, port, and initiator groups you just created.

To combine these groups into a masking view, use this command:

symaccess -sid <Symmetrix ID> create view -name <Masking view name> -storgrp <Storage group name> -portgrp <Port group name> -initgrp <Initiator group name>

This creates the masking view that contains all three objects—the storage group, the port group, and the initiator group—and automatically performs the mapping (associating devices with directors) and masking (exposing devices to hosts) operations.

To get more details on the masking view once it is created, use this command:

symaccess -sid <Symmetrix ID> show view <Masking view name>

The output from this command will show you details on the devices in the storage group, the ports in the port group, and the initiators in the initiator group.

Tags: , , ,

This is one article in a series of articles focused toward new users. Some other New User’s Guide articles include:

This particular article is a follow-up of sorts to the first article listed above. While that article focused on virtual networking with VMware ESX, this article focuses on virtual networking with VMware ESXi. Given that VMware’s stated focus is on VMware ESXi moving forward, I thought this article would be helpful and timely.

For new users who are seeking a thorough explanation of how VMware ESX/ESXi networking functions, I’ll recommend a series of articles by Ken Cline titled The Great vSwitch Debate. Ken goes into a great level of detail. Go read that, then you can come back here.

All of the commands presented in this article were testing using VMware vSphere 4.1. The environment consisted of hosts running VMware ESXi 4.1 being managed by VMware vCenter Server 4.1. For CLI access, I used the vSphere Management Assistant (vMA) virtual appliance, deployed via OVF.

The majority of all the networking configuration you will need to perform on VMware ESXi boils down to just a few commands:

  • vicfg-vswitch: You will use this command to manipulate virtual switches (vSwitches) and port groups.
  • vicfg-vmknic: You will use this command to create, modify, or delete VMkernel NICs on the VMware ESXi hosts.
  • vicfg-nics: You will use this command to view (and potentially manipulate) the physical network interface cards (NICs) in a VMware ESXi host.

The tasks that you’ll actually perform using this commands are pretty straightforward:

  1. Creating, configuring, and deleting vSwitches
  2. Creating, configuring, and deleting port groups
  3. Creating, configuring, and deleting VMkernel NICs

I’ll start with a few prerequisites that are necessary due to the fact that you are using a remote CLI to access the VMware ESXi hosts.

As you can see from the list above, all the commands you’re going to use are the vicfg-* commands. All of these commands have some standard parameters they require in addition to the task-specific parameters. To make things a bit simpler for you, I’ll recommend that you set persistent values (persistent for the current vMA session, at least) to simplify the commands later. Here are the values I recommend you establish:

  • First, set the value of the VI_SERVER variable to be the fully qualified domain name of the vCenter Server computer. Use the bash export command to set this variable, like this:
     
    export VI_SERVER=vcenter-server.domain.com
     
    Setting this variable now means that none of the vicfg-* commands will need to have this parameter specified. Since it’s likely that you’ll consistently work with one specific instance of vCenter Server, then this is a pretty safe variable to set.
  • In the absence of using Active Directory integration (which is a far cleaner choice, but one which we’ll reserve for a future article), set the VI_USERNAME variable to the name of the user account you’ll use to authenticate against vCenter Server. Again, use the export command as outlined in the previous bullet.

Now that you have some basics established, I’ll move on to creating, configuring, and deleting vSwitches.

Creating, Configuring, and Deleting vSwitches

You’ll use the vicfg-vswitch command for the majority of these tasks. Unless I specifically indicate otherwise, all the commands, parameters, and arguments are case-sensitive. For all these vicfg-* commands, you will get prompted for the password to the user account you defined when you set the value of the VI_USERNAME variable.

To create a vSwitch, use this command:

vicfg-vswitch -h <ESXi hostname> -a <vSwitch Name>

To link a physical NIC to a vSwitch—which is necessary in order for the vSwitch to pass traffic onto the physical network or to receive traffic from the physical network—use this command:

vicfg-vswitch -h <ESXi hostname> -L <Physical NIC> <vSwitch Name>

In the event you don’t have information on the physical NICs, you can use this command to list the physical NICs:

vicfg-nics -h <ESXi hostname> -l (lowercase L)

Conversely, if you need to unlink (remove) a physical NIC from a vSwitch, use this command:

vicfg-vswitch -h <ESXi hostname> -U <Physical NIC> <vSwitch Name>

To change the Maximum Transmission Unit (MTU) size on a vSwitch, use this command:

vicfg-vswitch -h <ESXi hostname> -m <MTU size> <vSwitch Name>

To delete a vSwitch, use this command:

vicfg-vswitch -h <ESXi hostname> -d <vSwitch Name>

Creating, Configuring, and Deleting Port Groups

As with virtual switches, the vicfg-vswitch is the command you will use to work with port groups. Once again, unless I specifically indicate otherwise, all the commands, parameters, and arguments are case-sensitive.

To create a port group, use this command:

vicfg-vswitch -h <ESXi hostname> -A <Port Group Name> <vSwitch Name>

To set the VLAN ID for a port group, use this command:

vicfg-vswitch -h <ESXi hostname> -v <VLAN ID> -p <Port Group Name> <vSwitch Name>

To delete a port group, use this command:

vicfg-vswitch -h <ESXi hostname> -D <Port Group Name> <vSwitch Name>

To view the current list of vSwitches, port groups, and uplinks, use this command:

vicfg-vswitch -h <ESXi hostname> -l (lowercase L)

Creating, Configuring, and Deleting VMkernel NICs

To work with ESXi’s VMkernel NICs, you’ll primarily use the vicfg-vmknic command. As in the previous sections, all commands are case-sensitive unless I specifically indicate otherwise, and all commands assume you’ve defined the VI_SERVER and VI_USERNAME variables.

To create a new VMkernel NIC, use this command:

vicfg-vmknic -h <ESXi hostname> -a -i <VMkernel NIC IP address> -n <Subnet mask> <Port group>

To delete a VMkernel NIC, use this command:

vicfg-vmknic -h <ESXi hostname> -d <Port group>

To enable vMotion on an already-created VMkernel NIC:

vicfg-vmknic -h <ESXi hostname> -E <Port group>

There are more networking-related tasks that you can perform from the CLI, but for a new user these commands should handle the lion’s share of all the networking configuration. Good luck with your ESXi environment!

Tags: , , , ,

Yesterday I completed the configuration of inter-VLAN routing (aka “router on a stick”, or RoaS) as part of my ongoing CCNA preparation. A couple people mentioned that they would find the configuration useful, so I’m posting what I have. This is by no means a comprehensive treatise on the subject; for that, you should look elsewhere. Google can find you lots of sites with more in-depth and detailed information on the reasons behind the necessary configuration.

There are two primary components in a RoaS configuration:

  1. The configuration of the VLANs and VLAN trunking port on the switch
  2. The configuration of subinterfaces on the router

I describe how to configure each component below.

VLANs and VLAN Trunking

How to create VLANs varies between various switch types. On some switches, you’ll use the vlan database command in privileged EXEC mode. On other switches, you will use the vlan <VLAN ID> command while in global configuration mode. Regardless of which method is necessary for your particular Cisco switch, you will want to ensure that the switch has all the necessary VLANs defined.

After the VLANs have been defined, then you will need to configure the switch port connected to the router as a VLAN trunk port. This is pretty well covered elsewhere, but here is a quick review of the commands (these commands assume port 15 on module 0, a Fast Ethernet port):

switch(config)# int fa0/15
switch(config-if)# switchport trunk encapsulation dot1q
switch(config-if)# switchport mode trunk
switch(config-if)# switchport trunk allowed vlan 1,71-75
switch(config-if)# exit
switch(config)# exit
switch#

A couple notes about these commands:

  • Some switches only accept 802.1Q VLAN encapsulation; therefore, the switchport trunk encapsulation dot1q command isn’t supported because that’s the only encapsulation supported. So, the support for this command will vary from switch to switch.
  • You will want to specify the correct VLANs for your environment in the switchport trunk allowed vlan command.

At this point, the switch is configured correctly; now it’s time to move to the router.

Subinterfaces on the Router

For each VLAN that needs to be routed, you will need to create a subinterface on the router. Creating a subinterface is pretty easy, the commands look something like this:

router(config)# int fa0/0.1
router(config-if)# encapsulation dot1q 1 native
router(config-if)# ip address 192.168.1.1 255.255.255.0
router(config-if)# exit
router(config)# exit
router#

As before, there are a few notes to consider about these commands:

  • The number of the subinterface (the “1″ in fa0/0.1 above) is only locally significant and doesn’t need to match the VLAN ID, but matching the VLAN ID makes it easier to associate the subinterface with its configured VLAN ID. Again, as stated earlier, you’ll need a separate subinterface for each VLAN that you want to route.
  • Only specify the native keyword on the encapsulation dot1q command if this is the native VLAN on the switch side as well. Otherwise, the trunk won’t form as expected.
  • The IP address specified here will be the IP address of the default gateway for that VLAN/subnet.

For the physical interface itself, the interface needs to be up (so don’t issue a shutdown command), but the interface does not need to have any IP address associated with it.

With this configuration in place, you should be able to route between the VLANs; just specify the IP address of the subinterface on the router for that VLAN as the default gateway of the systems on that VLAN and you should be good to go.

If I’ve missed anything glaring please speak up in the comments and let me know.

Tags: , , ,

« Older entries