VLAN Translation on a Nexus 5548 - :Sad Trombone:

Date February 23, 2015

I've got a problem. Our school is expanding, and we're constantly hiring people. We're hiring so many people that they won't actually fit in the building we're in. Because of that, we're having to expand outside of the building we've been in for years. Part of that expansion is extending my networks across campus (and in some cases, farther).

The network that I run is really old. Like, it actually predates the network at the central university. I've got around 50 VLANs, and now that we're growing outside of this physical environment, I've got to extend those layer 2 broadcast domains to the other buildings. I have a good relationship with the central network folks, and although most of my VLAN IDs collide with theirs, they assigned us some IDs that we can use on their infrastructure. Now, I just have to translate my VLAN IDs to their VLAN IDs.

My network core is a pair of Cisco Nexus 5548s. When I was planning this migration, I didn't worry at all, because the documentation clearly declared that the switchport vlan mapping command was supported. The only weird thing was, when I went to set up the VLAN translation, the command wasn't found. It was in the docs, but not in the CLI. Weird, right?

So I did what you do when you pay ungodly amounts of money for Cisco support: I opened a ticket with the TAC.

I had been operating under the assumption that my device would be able to perform VLAN ID mapping on an interface, but I can't figure out how to do it.

Is it possible to map VLAN IDs across a link? I have a trunk to my provider across which I need to send several vlans, but my IDs collide with those in use there. I was hoping to use the equivalent of "switchport vlan mapping", but it doesn't appear to be in my release.

Can you please advise me?

Thanks,

Matt

I got back what may be the best response from tech support ever. Emphasis my own:

Hi Matt,

My name is XXXXXXX and I will be assisting you with the Service Request 633401489. I am sending this e-mail as an initial point of contact and so that you can contact me if you need to.

Problem Description
As I have understood it, "switchport vlan mapping" command does not exist in 5548

>>
If you look at the release notes of Nexus5500
http://www.cisco.com/c/en/us/td/docs/switches/datacenter/nexus5500/
sw/release/notes/7x/Nexus5500_Release_Notes_7x.html#pgfId-530160

States:
VLAN Translation
Allows for the merging of separate Layer 2 domains that might reside in a two data centers that are connected through some form of Data Center Interconnect (DCI).

So I can understand why you were under the impression that this platform supports this feature however I must state that the document is incorrect here.

I have verified with the Technical Marketing Engineers and it has been confirmed that there are no plans to support vlan mapping / translation on Nexus5500 platforms however as of today; Nexus5672, Nexus 6000 and Nexus7000 do support this feature in 7.x release.

Please let me know if there is anything else I may assist you with .

...



So that was, you know, less than helpful. And I still need to get those VLANs over there. How are we going to do this?

For now, I'm doing it the old fashioned way. Crossover cables.

Normally, when you move VLAN traffic around, you use a dot1q trunk. Each layer 2 frame gets a header when it leaves a switch that tells the remote device (usually a switch) what VLAN the packet belongs to. So, VLAN ID 10 gets a header that says "this frame goes to VLAN ID 10", which allows traffic from VLAN 10 and VLAN 20 to be sent over the same physical link and still be kept separate.

Since the VLAN ID is encoded in the frame, it'll cause problems if the VLAN ID I'm using means something else to the other network. But, since the only thing the other end cares about is the VLAN ID, if I can send my traffic over to the other network on the proper VLAN ID, then they're happy. To do that, I need to bridge the networks. The easiest way I know how to do that is to take an access port on VLAN A, and an access port on VLAN B, and plug a single cable into both of them (after disabling spanning tree, of course). Yes, this sounds insane. Yes, it might actually be insane. But this is how I did it, and it worked the first time.

The bad part is that I'm currently burning two physical ports for every VLAN I need to translate, and this isn't tenable over the long-run. Fortunately, the Juniper switches on the remote side of the network link support translation, so I believe that we should be able to do it the "right way". The sooner the better, because I feel dirty.

Keeping up with the Jones's and their vSphere clusters

Date February 20, 2015

Ron Popeil introduced "Set it and forget it" into the lexicon, and really often, we sysadmins take that to heart when it comes to services and software. Blessed are those installations that reliably and quietly update on their own in the background, for they lead to full nights of sleep. But unfortunately, those kinds of things are few and far between.

I get to be part of a team now, which means that the Windows admin is responsible for Patch Tuesday shenanigans, and our Linux admin makes sure that apt-get auto-upgrades the important packages. Since I run the VMware infrastructure, I get to make sure that it is up to date with security patches and so on.

To help with this process, VMware provides the vSphere Update Manager. It runs in vCenter (so you do need to be using a licensed version), but it allows you to apply policies to VMs and hosts, and then scan them to make sure that they comply.

I have known that it existed for a while, but I hadn't spent any time learning it. I had done some upgrades on VM hosts from 4.1 to 5.0, and then from 5.0 to 5.5, but I was doing it manually, by upgrading from the ISO via remote console. That's kind of a drag, and it's completely manual, and just the ugliness of it made me itch to the point where I finally decided, "Alright, self, we're going to check out Update Manager and figure out how to make it work."

I was only hesitant because I'd heard from a few people who had bad experiences, and the "word on the street" from those people was that they found it unreliable and had stopped using it. Maybe in the past, it has been, but as of right now, I kind of consider it a god-send, because it sped up the host-upgrade process by a lot.

I'm not going to tell you how to install it or even really how to use it. There's much better documentation from VMware on that, but if you want a quick howto, I'd recommend checking out this video on YouTube from SysAdminTutorials:



Technically, it covers vSphere 5.1, but the 5.5 is very similar. Note that VMware has been encouraging us to use the web client for everything, but UpdateManager still requires the installed DotNet client to wrangle updates. At first, I absolutely loathed the web client, but after using it for a year or so, I only strongly despise it.

If you check out Bob Planker's 9 Things You'll Love about vSphere 6.0, you can see that some things will be improved, but alas, Update Manager will still live in the installed client. Chris Wahl writes that performance charts are available and usable in less than half the time. Which means that you can probably load them before you either get bored or forget why you visited that page in the first place. Seriously, the web client is bad, but there are some features that make it worthwhile. Update Manager just isn't one of them.

So anyway, at this point, all of my 15-ish vSphere hosts are up to date on the current release of vSphere Hypervisor aka ESXi, and I'm very happy that I spent the hour or so I needed to become comfortable with update manager. If you aren't using it, I'd suggest you take a look, too. It's not as bad as you may have heard!

Self-exile over. Back to writing stuff.

Date February 19, 2015

I've been taking a bit of a break from the whole "social" scene, both on twitter and here on my blog. I've been busy, I haven't felt like writing, and somewhere in the middle of all that, Boston took amazing amounts of snow, so I've been unburying my car again and again. It's been a busy couple of months, but after not being active for so long, it feels good to fire up the blog editor again.

So what has happened since I wrote last? Well, some re-organization here at work. My boss, the esteemed David Blank-Edelman has left to be the "Technical Evangelist" for Apcera, an enterprise platform provider. I've enrolled in classes here at Northeastern, since I get free tuition, and in terms of IT stuff, I've been spending some quality time with my VMware infrastructure. If you follow me on Twitter, I flooded your stream with Virtualization Field Day 4 info, and I'm in the middle of evaluating a couple of the virtualization management solutions from that. In particular, I'm having a great time with VMTurbo, so expect something informative on that, and I'll be getting to play with some other fun stuff shortly.

Basically, I want to get back into blogging like I used to. Not every entry is going to be amazing, but I'm hoping that I can start to contribute again, in some way that will provide something to someone. We'll see how it goes. Thanks for reading.

Upcoming Event: Virtualization Field Day 4 in Austin!

Date January 1, 2015

Happy New Year, and welcome to 2015. This new year will feature an array of exciting things, like writing the wrong date on everything for the better part of a month, and still trying to figure out what to call the decade that we’re currently halfway through.

One of the first things I’m going to be doing this year is to attend Virtualization Field Day 4, in beautiful (and more importantly, warm) Austin, TX. I’m really excited, not least of which is because the average temperature in January is about 30 degrees above my home in Boston. But I’m also really excited to be a part of an outstanding team of individuals brought together to meet companies doing exciting things in the virtualization space.

As always, Tech Field Day is being organized by tech luminary (and formerly mon capitan) Stephen Foskett, assisted by the most awesome Tom Hollingsworth.

Here are the delegates (stolen blatantly from the TFD website):

Amit Panchal

@AmitPanchal76

Technical IT Manager and blogger at apanchal.com.

Amy Manley

@WyrdGirl

12 years in IT, vExpert and an automation junkie

Christopher Kusek

@cxi

CTO at @Xiologix - EVP of Engineering, Technology Evangelist, vExpert, EMC Elect, BDA, CISSP, MCT, Cloud, Ninja, Vegan, Single, Father, Cat, Humorist, Author

Emad Younis

@Emad_Younis

Emad is a datacenter enthusiast, 2 x vExpert, and blogger @ emadyounis.com.

James Green

@JDGreen

James is an independent blogger at www.virtadmin.com, a 2014 vExpert, and works as a virtualization consultant in the Midwest.

Jeff Wilson

@Agnostic_Node1

Passionate yet disciplined virtualization & storage engineer in the SME market.

Julian Wood

@Julian_Wood

Julian is a London based enterprise infrasstructure architect and blogger.

Justin Warren

@JPWarren

Justin is a consultant and freelance journalist who enjoys coding in Python and words that are fun to say, like 'llama' and 'shenanigans'.

Larry Smith

@MrLESmithJr

19 yrs. in IT | 11 yrs. VMware virtualization | VMware NSX Nut

Marco Broeken

@MBroeken

Dutch Virtualization Admirer and DaaS Lover, Blogger at www.vClouds.nl

Matt Simmons

@StandaloneSA

Small Infrastructure IT Administrator in Academia

Mike Preston

@MWPreston

3 x vExpert, blogger @ mwpreston.net and a typical Canadian eh!

There are a lot of the folks that I know from former events, but there are several I haven’t had the pleasure of meeting yet, and I’m really looking forward to it. Because Tech Field Day delegates help vote on future attendees, you don’t wind up with people there who aren’t interesting and knowledgeable in some way. Somehow, I slipped by, but given my almost encyclopedic knowledge of Star Trek, I fit right in, so they let me keep coming back.

The other side of the Tech Field Day coin is the people we’re brought together to meet with - the vendors! If nothing else, my experiences with Tech Field Day have taught me that not all vendors are bad. A lot of them really get technology, and they care about implementing it well and treat their customers as partners instead of just sources of income. Those companies are a pleasure to talk with, and they tend to have the best presentations at TFD events.

This will be the fourth Virtualization Field Day event (way back in the day, I actually ran the VFD2 event when Stephen couldn’t make it! No pressure!), and Stephen has rounded up a really interesting collection of companies in the virtualization space:

There are several companies there that I suspect most people are familiar with, but some of them are new to me, and I’m going to be going back and doing my homework. As I get my research done, I’ll be posting blog entries so that you can get some background, too. I’ve found this kind of thing to be great prep work for TFD events. Some of the TFD attendees are in the solutions space, and it’s their job to stay current on everyone in the market. I don’t have that kind of time, so I’ve got to play pickup. I figure most of you are in the same boat as me, so we’ll learn together!

Anyway, thanks to Stephen and Tom for having me back. I always enjoy my time with the TFD delegates, and I’m certain that this event won’t be any different. The event starts January 14th, so make sure to watch this blog for more updates!

Leaving the LOPSA Board

Date December 10, 2014

It’s with some amount of sorrow and trepidation that I begin this blog entry.

One of the things that I often need to be reminded of is my own limitations. I think we all can forget that we’ve got human limits and sometimes we take on more than we can deal with. I am a chronic “joiner”. I like people, I like to build communities and organizations, and I like to put forth effort to make things happen.

By itself, this is fine, but in the macro, I try to do too much - certainly more than I can accomplish. My work suffers across the board from my lack of attention in any one area. It’s like the old problem of task switching, but when the tasks are completely unrelated to each other, it’s like context switching my entire brain out, and when I do it too often, I lose because of how inefficient it is. Worse than that, the tasks suffer.

For a long time, I was able to not let that be a massive problem, because I worked hard to keep myself out of the “critical path”, so that when I was concentrating on task B, task A could comfortably wait. But that’s not the case anymore. The quality of my work has been suffering, and it’s to the point where not only is everything I’ve been doing mediocre, those organizations where I’m in the critical path have suffered, and I’m no longer willing to make other people suffer because of problem of taking on too much.

Effective today at noon, I’m resigning as a Director of LOPSA. This might be surprising given how much I wanted to actively work and lead the change that I believe the organization needs, and I can tell you that no one is sorrier than I am that I’m stepping down. This isn’t me “breaking up” with the organization. I still believe that the organization has a lot to offer and its community of IT Admins is a potent force capable of a lot of good. But I’m not going to serve as a sea anchor to slow it down just when it needs to be more agile.

I’m really fond of the "golf ball an hour” analogy, and I’m going to start spending my golf balls on my family, and improving my IT skills. I remember when I was a good sysadmin. I don’t feel like that anymore. It’s not impostor syndrome in this case. It’s that I haven’t spent the time honing my skills and keeping up. So I’m going to try to fix that. And maybe I’ll be able to get some blog entries written about what I learn along the way.

So anyway, I’m going back to being a community member rather than a community leader, and I’m fine with that. The other LOPSA Board members have been very supportive of my decision, and I thank them for that, and I thank my many friends who have done the same.

If you were one of the many people who voted for me in the LOPSA Board election when I ran, thank you. You can take heart in the fact that I believe I was able to make some significant changes in the 18 months I served, and I really think that the organization is more aware of what its possibilities are than it ever has been. I’m glad I had the chance to serve and contribute. Thank you for giving me that opportunity.

What is Orbit?

Date December 3, 2014


Flying is learning how to throw yourself at the ground and miss
-- Douglas Adams

Even if you’ve never followed the space program, or know anything about rockets, you probably know what “orbit” is. I mean, all the time, the news reports when a spacecraft “reaches orbit”, and the Space Shuttle was often known as the “orbiter”. So you know, orbit is “up there”, and you circle a planet or moon or something. But have you ever thought about what it takes to get into orbit?

Lets imagine you are me - oh, I don’t know, 10 years ago, before I ever started looking into the specifics of how space stuff works. “Self”, I might ask you, “How do you get to space?”

The answer is clearly to go up. I didn’t know it 10 years ago, but “space” is basically anywhere with an altitude greater than 100km. So if you go up 100km, you will be in space. Will you then be in orbit? No. As soon as you stop going up, you will come right back down. This is what’s called a “ballistic trajectory”, and that’s not how you get to orbit. It doesn’t actually matter how far up you go, you’ll either come back down, or you’ll go away forever*. That’s not how you get to orbit.

Instead of going up, what happens if we go over? If you throw a baseball, what happens? It falls to the ground. But the Earth is round, and if you could throw the ball a thousand miles, when it eventually hit the ground, you can check on a globe and see that it would have followed the curve of the Earth. And if you threw it 4,000 miles? It would curve even more.

Because the Earth’s gravity is always trying to pull the baseball down, the baseball always curves toward the center of the Earth (well, specifically the center of the Earth’s gravity well). But because the baseball has a sideways motion, the ground also constantly curves away as the ball moves. If you can throw it fast enough that the ground curves away just as quickly as the ball goes toward the center, then the ball will never hit the ground. Instead, it will go all the way around and around, thereby completing an orbit.

Fortunately, we live on a planet with an atmosphere, so there’s really no way that you could throw a baseball and get it into orbit - the air would slow it down too much. But we have rockets, and we can use rockets to deliver baseballs. So lets use a rocket to make a baseball achieve orbit.

We have two choices. We could go straight up like we tried before, except this time, because we have a powered rocket, we can turn sideways once we’re out of the atmosphere and apply thrust in the direction we want to go, or we can turn sideways much sooner, and fly diagonally through the atmosphere, picking up speed vertically and horizontally at the same time.

The first one will work if you’ve got a rocket with enough fuel on it, but you end up wasting an awful lot. Whenever you’re just thrusting straight upup, you are making no progress going sideways, and in order to get an orbital trajectory, where you can make a full circle without hitting the ground (or, importantly, without coming back into the thicker parts of the atmosphere), you have to be going very fast unless you’re going very, very far away from the planet.

Instead, it almost always ends up being a good idea to go diagonally, though the flight profile (that is, how much thrust you use, when, and what direction you’re going) depends on the orbit you’re trying to reach, the mass of your rocket, and its performance capabilities. This technique is known as a gravity turn, because it uses gravity to help turn the vehicle into the orbit you want it to achieve.

Most of the things we launch are launched “prograde”, that is, they are going in the same direction that the planet spins. On a map, that means they go from West to East. The reason for this is that the planet is turning, and you get a free boost if you go in the same direction as the planet.

There are also times where you might want a “retrograde” orbit, where the orbit will end up going East to West. This is useful if you want your space craft to cover a lot of ground in a little bit of time (because the spacecraft is orbiting against the rotation, it sees the entire ground path in less time than if it were prograde and traveling with the ground). This orbit is harder to achieve because you’re working against the rotational boost of the planet.

A third option is a polar orbit, where the spacecraft orbits north to south, or south to north. You don’t get a rotational boost with this orbit, though your inherent rotation does need to be corrected so that it doesn’t skew your orbit away from the pole. This orbit has the benefit of being able to observe 100% of the body’s surface. Because the vehicle is orbiting from pole to pole as the planetary body turns underneath it, all of the surface winds up under the ground path.

As an aside, a ground path is, literally, the part of the ground under the spacecraft. If you’ve ever seen a picture or movie of Mission Control, there’s usually a map with curved lines tracing the path that the craft will follow. Those curves don’t mean that the craft is in orbit bobbing and weaving back and forth. It means that the craft is orbiting at an angle, called the inclination.

Inclination is almost always measured from the equator of the planetary body, so if a ship is orbiting at a 0% inclination, it means it’s basically tracing the equator. If it has an inclination of 51.65 degrees like the International Space Station, then the orbit the ship is taking is slightly steeper than halfway between a flat orbit on the equator and a flat orbit on the poles.

On a globe, it looks something like this:

and if you trace the path that orbit follows over the ground, it looks like this:

Now, whenever you see a ground track like that in mission control, you’ll usually see a couple of them together. That’s because the planet is constantly turning, and by the time one orbit is done, what was underneath the ship has moved, and now something else is.

The last thing we should talk about is orbital altitudes - that is, the distance from the ground.

It’s important to realize that almost no (and, in fact, probably no) orbits are perfectly round, and a lot of them are very elliptical. Simplistically, an orbit looks like a conic section. That is, if you take a cone, and cut it, the edge of the cone you cut resembles a potential orbit. In reality, irregularities in the mass distribution of the body a ship is orbiting (and in the ship itself) means that the orbit won’t perfectly match the conic section, and that you won’t be able to describe an orbit using a perfect ellipse. But you can get a pretty good idea of how orbits work by thinking about them in terms of ellipses.

The two things that determine a ship’s orbit around any given body are its altitude and its orbital velocity. With a circular orbit, the ship maintains a constant orbital speed (that is, how fast it travels through space) and a constant altitude (that is, distance from the ground). Remember that since this is an orbit, you don’t need to thrust constantly to maintain the orbit. You’re falling down and sideways at the same speed - you just keep going. That’s what orbit is.

* - There are very small possibilities where you could launch straight up, get a gravity assist from something else, then come back and orbit Earth via free return trajectory. But that’s cheating.