After implementing Cisco Nexus 5ks that include native Fibre Channel switching for shops that usually don’t have dedicated SAN guys, I’m often called up sometime later to offer a refresher on how to add zones. I usually share this tidbit via email, but here it is for the internets. These commands are very similar on newer MDS models, as well.
I wanted to take a short minute and document the addition of a few Cisco MDS 9124s to our test lab at work. The purpose of the addition in the test lab is just to show the functioning and capabilities of the devices to work together. See my previous post on configuring native FC over a Nexus 5548 and 5596. The FC-specific portions of the MDS config are very similar to the Nexus line. Here’s what the middle state looks like. I haven’t taken the time to move the NetApp FC links to the MDS switches yet (or the UCS FC links instead), but the port provisioning process will be similar to those already documented in this post and the Nexus post. The Visio of what’s configured is below followed by my MDS configuration notes.
I recently had the opportunity to configure native fibre channel in my test lab at work using Nexus 55xx series switches and Cisco’s UCS. What I’ll do in this post is to share my templatized fibre channel configuration in a somewhat ordered way, at least from the Nexus point of view. This test lab was configured with the attitude that it should show off the capabilities of the hardware and software. Concepts included in this initial configuration include NPIV, NPV, SAN port-channels, F_Port trunking, VSANs, device aliases, and of course, standard FC concepts like zones and zonesets.
Let me first share the end-state as of today, what I’ll call Phase I. I’ll explain what my initial plan was for Phase I and, after learning a bit more, what I plan to do for Phase II. Please feel free to correct me in the comments below – I made a lot of mistakes configuring this and I wouldn’t be surprised if there’re a few more in there.
I’ve recently needed to configure SPAN a couple times in the lab at work to troubleshoot some issues – or at least to see what I could see. It wasn’t exactly glamorous work, but somebody had to do it. Now, I had to look it up the first time because it had probably been a good year since I’d done it. The document I used is here. Well, the second time I needed to configure SPAN was shortly after the first. I was annoyed that I had to look at the same document and skip over all the paragraphs to get to the commands, then sort out the FC ports and other commands I didn’t need. So for my benefit, and perhaps yours, here’s my short and sweet version of how to configure SPAN on a Nexus 5k.
I’d like to take this opportunity to share a message from ONS 2013 as its conference nears.
Software Defined Networking (SDN) is the buzzword on the mind of every player in the networking and telecom ecosystem; promises to revolutionize networking as we know it and will affect service provider networks, cloud networks and enterprise networks.
Open Networking Summit (ONS) 2013 is the premier conference for SDN and Open Flow and has established itself as the leading event to ‘plug-in’ to SDN.
ONS brings together the entire SDN ecosystem, comprised of thought leaders, business leaders, luminaries, creators, researchers, innovators and engineers, to offer the very highest caliber presentations, tutorials, exhibitions, and latest research to enable the SDN community to interact and share ideas.
After my recent DFW VMUG presentation where I spoke on the topic, a friend emailed me and asked what I thought about OTV.
“You mentioned that you were against OTV. Curious on your take on this, as we are using it across two datacenters using N7K, UCS, NetApp and VMware.”
I’d like to share my response to him here.
Please don’t get me wrong. If one is forced to implement a Layer 2 Data Center Interconnect (DCI), OTV is probably the best solution. Sometimes, L2 connectivity between data centers is a functional requirement – perhaps even a constraint. In these cases, one should look at the benefits and risks of implementing an L2 DCI and then make an informed decision on whether they should continue with such a deployment. Should they choose to deploy OTV, someone needs to accept the risks associated with OTV in its current implementation.
24 October 2014 Edit: fixed typos when setting IP addresses and descriptions on Vyatta interfaces (from eth0 to the proper interfaces)
Good day my Internet friends! Let me say that I feel accomplished – and not just because I got out of bed this morning, although that is a big win for me. No, instead I’ve actually been quite productive (based on my standards, anyways). I’ve been rebuilding my home test lab for the past couple of days before I start my new job. What I really wanted was to get back heavy into the NetApp DataONTAP simulator, but I wanted to get inter-VLAN routing working first so I could have some realistic networking. I only have layer 2 switches in the lab so I was looking for ways to accomplish this. I reckon I knew I would have to use software of some sort, but I hadn’t actually messed with anything up to this point. I’d heard of the Vyatta virtual router recently, so I thought I’d give that a try. You can download the free community edition here with a login: http://www.vyatta.org/downloads I wasn’t able to find the Vyatta virtual appliance I saw advertised around the interwebs, but I was able to install from the LiveCD ISO just fine.
I was troubleshooting a production issue a couple days ago that led me to request the switchport configs from our Networking team of our ESXi 5.0 hosts that pass virtual machine traffic. Here’s a snippet of what they came back with for two particular ports:
description -=R910 ESX# 1 – Front Side=-
switchport mode trunk
description -=R910 ESX# 1 – Front Side=-
Well. Not only do I see our problem (no config *at all* on one port!), but I see something else that troubles me. Our ESXi host-facing ports are only configured as trunk ports. Absolutely* nothing* else. Well, this just won’t do.
So my team and I got a call to swing by a customer’s site on our way to another job. They told us half the ports went bad on a FEX and we were to install the replacement that just arrived onsite. In this post, I’ll explain how to replace the FEX (which is trivial) and more importantly how to verify that it’s working after installation.