Recently I’ve been lucky enough to be challenged with learning a bit about Fibre Channel Switching, but I’m even luckier in that I’m getting to know it on a set of MDS switches running NX-OS (previously referred to as SAN-OS). So far, I’ve learned the basics of getting things to work, but nothing really beyond that. As the SAN world has always been a mystery to me, I figured I would share what I’ve learned with other engineers that are at least looking for a baseline look into the storage network.

New Terminology

First, lets familureize ourselves with a few terms that we may run into when dealing with the very basics of FC switching…

• WWN: World Wide Name, think 8-byte MAC address. Also pWWN/sWWN (Port/Switch WWN) — This is the addressing of the Fibre Channel world. All of our configs are going to use pWWNs (Port World Wide Names, which actually refer to the node, or N_port)
• vSAN: A vSAN is a virtual collection of ports, sort of like a VRF, or even a vDC (but within the same management plane) — Each port can only be a member of one vSANs. — From my understanding, This is a Cisco specific technology typically used to create at least one unique vSAN per switch. This defines the two (or more) distinct fabric paths.
• Zone: a Zone is a grouping of ports inside a vSAN used to control which devices can speak with other devices. Devices can be members of multiple zones. Devices in different Zones cannot speak to each other. — Think VLAN.
• N_port: Node Port — Could be a Host, or Storage device.
• F_port: Fabric port — Connects to an N_port
• FLOGI: Fibre Channel Logins — Used to exchange device information. Including WWNs

Configuration

First, we’re going to define the group of ports we’re using. Descriptions are set, and since the MDS is licensed per port, you have to enable the license for that port. I also ensure that each of these ports are not shutdown.

interface fc1/1
  switchport description Controller A
  port-license acquire
  no shutdown

interface fc1/2
  switchport description Controller B
  port-license acquire
  no shutdown

interface fc1/15
  switchport description Blade Server Fabric A
  port-license acquire
  no shutdown

interface fc1/16
  switchport description Blade Server Fabric B
  port-license acquire
  no shutdown

interface fc1/17
  switchport description DMZ Server Fabric A
  port-license acquire
  no shutdown

interface fc1/18
  switchport description DMZ Server Fabric B
  port-license acquire
  no shutdown

Next up we’re going to configure the vSAN for this switch, and add the ports/interfaces to it. (Almost brings me back to configuring VLANS on HP switches… )

vsan database
  vsan 10 name "FABRIC_A"
  vsan 10 interface fc1/1
  vsan 10 interface fc1/2
  vsan 10 interface fc1/15
  vsan 10 interface fc1/16
  vsan 10 interface fc1/17
  vsan 10 interface fc1/18

Now that we have our ports inside the vSAN we can discover their PWWNs using the FLOGI database. We will need these for our fcalias groups below.

mds# sh flogi database
--------------------------------------------------------------------------------
INTERFACE        VSAN    FCID           PORT NAME               NODE NAME
--------------------------------------------------------------------------------
fc1/1            10    0x0f0100  50:0a:09:81:8d:8f:f8:ca 50:0a:09:80:8d:8f:f8:ca
fc1/2            10    0x0f0200  50:0a:09:81:9d:8f:f8:ca 50:0a:09:80:8d:8f:f8:ca
fc1/15           10    0x0f0300  20:41:00:05:73:e3:56:c0 20:14:00:05:73:e3:56:c1
fc1/15           10    0x0f0301  20:00:00:25:b5:0b:00:df 20:00:00:25:b5:00:00:8f
fc1/15           10    0x0f0302  20:00:00:25:b5:0b:00:ef 20:00:00:25:b5:00:00:9f
fc1/15           10    0x0f0304  20:00:00:25:b5:0b:00:bf 20:00:00:25:b5:00:00:6f
fc1/16           10    0x0f0000  20:42:00:05:73:e3:56:c0 20:14:00:05:73:e3:56:c1
fc1/16           10    0x0f0002  20:00:00:25:b5:0b:00:9f 20:00:00:25:b5:00:00:2f
fc1/16           10    0x0f0004  20:00:00:25:b5:0b:00:6f 20:00:00:25:b5:00:00:3f
fc1/16           10    0x0f0004  20:00:00:25:b5:0b:00:7f 20:00:00:25:b5:00:00:4f
fc1/17           10    0x0f0300  20:41:00:01:73:b3:26:a0 20:14:00:05:73:e3:56:c1
fc1/17           10    0x0f0301  20:00:00:25:b5:0a:00:ef 20:00:00:25:b5:00:00:8f
fc1/17           10    0x0f0302  20:00:00:25:b5:0a:00:df 20:00:00:25:b5:00:00:9f
fc1/17           10    0x0f0304  20:00:00:25:b5:0a:00:cf 20:00:00:25:b5:00:00:6f
fc1/18           10    0x0f0000  20:42:00:01:73:b3:26:a0 20:14:00:05:73:e3:56:c1
fc1/18           10    0x0f0002  20:00:00:25:b5:0a:00:5f 20:00:00:25:b5:00:00:2f
fc1/18           10    0x0f0004  20:00:00:25:b5:0a:00:bf 20:00:00:25:b5:00:00:3f
fc1/18           10    0x0f0004  20:00:00:25:b5:0a:00:8f 20:00:00:25:b5:00:00:4f

Here we’re defining logical groups of devices and identifying their PWWNs. Nothing too scary here.

fcalias name STORAGE vsan 10
    member pwwn 50:0a:09:81:8d:8f:f8:ca
    member pwwn 50:0a:09:81:9d:8f:f8:ca

fcalias name BLADE_SERVERS vsan 10
    member pwwn 20:00:00:25:b5:0b:00:df
    member pwwn 20:00:00:25:b5:0b:00:ef
    member pwwn 20:00:00:25:b5:0b:00:bf
    member pwwn 20:00:00:25:b5:0b:00:9f
    member pwwn 20:00:00:25:b5:0b:00:6f
    member pwwn 20:00:00:25:b5:0b:00:7f

fcalias name DMZ_SERVERS vsan 10
    member pwwn 20:00:00:25:b5:0a:00:ef
    member pwwn 20:00:00:25:b5:0a:00:df
    member pwwn 20:00:00:25:b5:0a:00:cf
    member pwwn 20:00:00:25:b5:0a:00:5f
    member pwwn 20:00:00:25:b5:0a:00:bf
    member pwwn 20:00:00:25:b5:0a:00:8f

And finally, this is where the proverbial “magic” happens. We’re defining a zone called SERVERS_TO_STORAGE inside vsan 10 and adding our fcalias groups as members of the zone. This allows these group members to communicate with each other. This zone is segmented from our DMZ_SERVERS_TO_STORAGE zone, so that there is no change of communication between our DMZ_SERVERS and BLADE_SERVERS.

zone name BLADE_SERVERS_TO_STORAGE vsan 10
    member fcalias STORAGE
    member fcalias BLADE_SERVERS

zone name DMZ_SERVERS_TO_STORAGE vsan 10
    member fcalias STORAGE
    member fcalias DMZ_SERVERS

Verification

From what I understand the only practical verification you can do is checking your host to ensure you can see the LUNS presented by your storage array. With any luck, everything should show up. If not, double check the PWWNS used in the fcalias groups.

Conclusion

While I have given you little more than a 30-second education on fibre channel, I hope it’s enough that when your storage engineer rambles on endlessly about zoning, you at least have a clue as to what he is actually talking about. And as long as your infrastructure isn’t too complicated, I’m sure you could figure out how to connect your new UCS Blades to their storage without their help. That line is getting awful blurred these days, you might find yourself having to learn more about storage because of it.

Our second visit on day 2 of Network Field day was Brocade, who incidentally supplied us with a great lunch! We spent a little time going through the expected marketing presentation, fortunately they kept it short and to the point… Next up was another short presentation from Jon Hudson, aka @the_socialist, who started things out with a overview of Brocade and their core product line. Fortunately for us, Jon had done his homework and cropped his presentation down to the essentials which aided in keeping our short attention-span on focus. All of this lead up to the surprise they had waiting for us. A live Brocade VCS lab. Yes, you read that correctly. A full, hands on lab. Not a demo, not a video.

For the lab we were broken up into 5 teams of two engineers. Each team had their own switch, with console access, and some OM3 fiber patch cables. They also gave us a packet of information with information about configuring VCS and a list of tasks to accomplish. The icing on the cake was that they wanted us to compete, and allowed us to sabbotage… Serioulsy? Quite a can of worms to open in a room full of the best and brightest engineers. Luckily enough, my partner was the illustrious Greg Ferro, aka the EtherealMind. Next to us, Tom Hollingsworth (NetworkingNerd), and Jeff Fry (FryGuy) joined forces. I knew right out of the gate that they would be our biggest rivals. Once we got started, Greg and I both noted that Brocade’s CLI was very similar to Cisco’s IOS. After some basic configuration tasks, we were ready to cable our switch to the core switches. Greg and I headed off with our OM3 patch cables into the data center right on the coat tails of Tom and Jeff. Once they were patched and headed back in, Greg got us patched in, while I trade out their cables… now, whether or not their LC connectors were slightly tampered with or not is a matter of opinion. Lets just say I was rather tempted to flip send/receive on one of the connectors. Unfortunatley, this is also where things started going downhill. Tom rebooted our switch a couple of times, and ended up changing the password. I chose to bide my time, waiting until we got the password back, and they were on their final configuration steps. Lets just say server was in the middle of a vMotion when it lost connectivity. :) By the time they got things sorted out, we were back up and had already vMotioned our server completing the list of tasks. It was at this point in time that I realized how much entertainment we were providing the team at Brocade, some of which were about to fall out of their chairs.

After the lab, we started up a Q&A with the Brocade team, to paraphrase a quote from @NetworkingNerd, Ivan Pepelnjak and Jon Hudson put on an impressive sparing match over their TRILL implementation (VCS). During most of this time I was having a realization of how powerful their entire presentation was… Starting from a quick overview of Brocade, to the lab, and then holding a Q&A… it was all a very well orchestrated power play on Brocade’s part. I realized how simple their VCS implementation is, the configuration on the fabric switches is just but a few lines, and can obviously be configured by a bunch of caffeine doped apes. (Please ignore my previous comment regarding the best and brightest engineers.) Brocade has done their homework in many ways… and it really made me think long and hard about Brocade and where their going. In a matter of speaking, I’ve had a Brocade wake-up call. (Hence the “This is Jack sleeping on a plane” gif at the top of this article.. ) They’ve made some bold moves in the Ethernet market that will get the attention of engineers around the globe.

The second day of Network Field Day 2 started early at the Juniper EBC, luckily Abner Germanow was prepared with breakfast for the weary and slightly hung over delegates. He gave us an overview of Juniper Networks as a whole including some back history of how they started innovating by putting routing code into ASICs. He quickly handed of to Dan Backman who started off by talking about how Junos has developed itself around workflows. He demonstrated the extensibility of Junos through tools like XML and API calls. Because of the way it was developed, they have the unique ability to provide powerful scripting and automation tools. Dan actually told us that the entire Junos back end is XML, which is VERY interesting. Next he brought up a live Juniper lab to show us the real power of their scripting/automation. This is the first time I’ve heard of Junos commit scripts, which I now wish I had in IOS. During this entire demonstration all of delegates really seemed to enjoy the flexibility Dan was demonstrating, by the end, he had us all drooling over it. And that was before he dropped the bombshell… his entire demonstration had been running inside of Junosphere. Before we were able to bombard him with questions about how to get access to it, he showed some a rather impressive demo using Cariden Mate, and an IS-IS db gathered from what appears to be the I2 backbone. Very cool stuff. Cariden was able to generate a topology from the database, and their plugin for Cariden was able to generate the appropriate Junosphere configuration/startup files. Several times during his presentation he made reference to there being “one more thing” or some secret he wanted to share. It wasn’t long before we learned they were going to give us access to Junosphere for testing! Be on the lookout for my Junosphere review once I’m able to check it out.

Next was “Shoeless” Dave Ward CTO of Juniper’s Platform Division, previously with Cisco Systems for 12 years where he designed little things like the CRS-1, CRS-3, and the ASR 9000 series.. definitely not a light weight. David was also one of the presenters at the Tech Field Day Open Flow Symposium earlier in the week, and as it happens he was back to talk about just that. This is a rather deep dive into Juniper’s approach for Programmable Networking, and I’m not sure I truly do it justice. Juniper has developed their controller inside a orchestration platform they’re calling Junos Space. From the sounds of it, Space is a layer that interacts with a fully comparable OpenFlow controller, David says they even have gear from Big Switch Networks running on their Space platform. He went on to talk about how Juniper has begun to market Service Engineered Paths (SEP), which are simply OpenFlow enabled Traffic Engineered (TE) paths can be programmed with permit/deny statements in front of them for particular service flows. This enables selective traffic path redirection based upon ephemeral data, such as LSPs being requested/configured via the OpenFlow software. This is very cool stuff, auto-magic end-to-end soft MPLS PVCs dynamically configured by the controller! Make sure you watch the video, it’s definitely worth the time.

Next up was a presentation from one of Juniper’s acquisitions, Altor Networks and their virtual firewall appliance, vGW. This is very similar to Cisco’s VSG in that it enables you to firewall all communications within the VMware cluster including those flows going between VMs. Since this isn’t exactly anything new, I’m not going to spend a lot of time covering it. In it’s simplest form, vGW is a high-performance hypervisor based stateful firewall with an integrated IDS, and AntiVirus protection. Update: Apparently I missed some details during this discussion. Luckily enough, Ivan has come out with another great post letting us know the significance of what Juniper has done with their vGW.

Last but certainly not least was a presentation on QFabric. Juniper’s answer to Cisco’s Fabric Path, Brocade’s VCS, and of course the industry standard TRILL. It is of course a proprietary solution, but in some cases that can be a non-issue. Of course, at around 5:20 into the vidoe, Juniper presented us with their own version of “the problem“, a series of slides that by this point in time we have seen over and over again… Although once Tony Bourke mentioned that we were well aware of “the problem” he recovered quickly and moved on. (Kudos for Tony for quite a tactful engagement and remediation of the situation!) Again, there isn’t a lot of ground breaking going on during this talk so I wont spend much time here… But if you’re dying for more information check out the artciles at IOShints and the Packet Pushers Blog / Podcast.

The last stop was their proof of concept lab which for a bunch of networking geeks is a great way to earn extra credit. Who doesn’t love a data center? Even better, the entire data center was a lab! Here are a few photos from the EBC Lab.

I could’ve just as easily called this article Gigamon… fixing problems you didn’t know about or Why Gigamon scares the crap out of me — but I wont, because they already did! But what I will say, is that Gigamon has become a very interesting product to me…

Gigamon’s product line-up mainly consists of optical fiber and electrical copper taps for network connections, and a series of aggregation taps with the capability to filter traffic being tapped and aggregated. Now, why do I find this interesting? Well, it all goes hand in hand with why your enterprise or ISP may be interested in their products…

Do you run an IDS? If you’re not, should you? I’m guess the answer to one of those is a resounding yes. Well, how are you going to get the data to your IDS? A hub? No, I didn’t think so. Well, how about a SPAN session? Oh, your span session is flaky, or it can’t monitor enough source interfaces? Maybe you just want to filter some of the traffic out. Well, now you need Gigamon’s help. Buy yourself a TAP and feed that into one of their VUE products where you can aggregate and filter the data down to your IDS. Say you want to make a second copy of that traffic, well guess what? You can do that too!

At the high end of the spectrum their GigaVUE-HD8 supports a massive 96 10Gb Ethernet ports with a whopping 1Tbps non-blocking backplane. You may of also noticed that this device is actually the name sake of this post… the Great Pumpkin. As impressive as this is, they also certainly offer smaller devices aimed towards the enterprise market like the GigaVUE-212 which still offers 8xGigE or SFP, 2x10Gb SFP+ ports, and you can add an additional 4xSFP ports via an expansion module..

If you’re still curious about how they work, or what they do, check out this great video on their Flow Mapping technology. It really shows just how powerful their system is and how well it would work in most any scenario you could come up with.

So why does Gigamon scare some people? Well, it may be their bright orange chasssis, or it could be the fact that our government has gone all big brother while trying to protect us from the crazies of the world… (not that I really blame them) It stands to reason with Gigamon’s own Gigamon Federal twitter account, you don’t have to wonder who some of their largest customers are. But honestly, you’re either going to be scared to death of them, or think that Gigamon is the greatest product that you never knew existed.

Tech Field Day Disclaimer

Gigamon was a sponsoring vendor for Network Field Day 2 and as such they my travel expenses were indirectly paid in part by them. They also gave me top notch swag… However, I was not paid to write about them, nor was I asked to give them special consideration. Any opinion expressed by me is mine and mine alone.

NEC is currently the only Vendor that is shipping an OpenFlow enabled product today. So naturally, their presentation led off with a message about what they’re bringing to the market. If you don’t know anything about OpenFlow, please read my previous post covering the OpenFlow Symposium.

Currently, NEC is shipping their OpenFlow implementation as ProgrammableFlow products which include a ProgrammableFlow Controller (PFC), and a ProgrammableFlow enabled switches. Unfortunately, I’m unable to find any documentation on these products as NEC’s actual website was written by someone who enjoys a difficult maze… (the only page I could find on ProgrammableFlow was here) But I digress. The PFC it’s self is just a Linux box with some custom software implementing the OpenFlow 1.0 standard. In addition to acting as part of your control plane, it can also do topology discovery via LLDP, and perform fault detection and possibly even repair. The graphical representation NEC gives you of your network with their controller software is rather nice, it’s not just a visualization of your netowrk, but it also provides end to end monitoring of each individual flow transported over the network. As for NEC’s ProgrammableFlow switch, it is a 48-port GigE switch with 4x 10Gb SFP+ uplink ports providing line rate multi-layer switching, and maintaining up to 160k OpenFlow “flows”. The switch itself can operate as a hybrid either allow you to control it via an OpenFlow controller, or operate as a traditional managed switch. NEC has also developed a vSwitch for Windows 8′s Hyper-V, this alone should prove to be rather interesting as NEC will hit the ground running on virtual switching with the new release of Windows Server 8.

Conclusion

So, what’s with all the OpenFlow hype? The 30-second version is that ProgrammableFlow/OpenFlow-based networks can help streamline network management by supplying automated/programmable services such as automated re-configuration. This programmability not only helps keep your network up, but also decreases the cost to manage the network. Like I said, if you want more go watch the Symposium. Honestly, I think time will only tell what the futures holds for NEC and ProgrammableFlow. The adoption of radical new technology can be extremely slow and tedious *cough*IPv6*cough* — while I am excited about the technology, I am skeptical if it will be adopted. Just because you have the best technology doesn’t mean you win the war. *cough*BetaMax*cough* — that said, who has NEC switches in their data center? I know I don’t, nor have I EVER seen any. Hopefully the future is bright for them, and I certainly wish them luck. But I’m not holding my breath until I get to put my hands on any NEC ProgrammableFlow gear… As a matter of fact, as was excitedly going through the details with my boss, he was quick to point out that there was no way we were buying it. I had to chuckle, but I knew he was right. Hopefully I’m wrong, and there is a huge market out there for them. They’ve certainly put the right team on developing the product, but now they need to step up and market it properly…

Tech Field Day Disclaimer

NEC was a sponsoring vendor for Network Field Day 2 and as such they my travel expenses were indirectly paid in part by them. They also gave me swag… However, I was not paid to write about them, nor was I asked to give them special consideration. Any opinion expressed by me is mine and mine alone.

During the coarse of NFD2 I found an iPhone app called Halftone, and later, one named ComicStrip that allow you to add some fun effects and speech bubbles to your photos… So, I started in on some of the photos that I took during the trip. After putting a few of them on twitter they got some pretty good responses. Earlier today, I asked a couple people if I should put them all up on my blog as a collection, so here it is, all of the images I have created thus far. Some of them may not make much sense unless you were there, but I hope they’re humorous nonetheless. If you have any questions feel free to ask and I’ll try to explain…

First of all, I want to say thank you to everyone from Cisco Systems for inviting us into the CCIC (Cisco Cloud Innovation Center), this was an amazing room to hold our discussions. We started off with a greeting from Omar Sultan who then brought our old friend Ron Fuller. Ron gave us a quick overview of Cisco’s Nexus lineup, and some of their current sales figures. Did you know they currently have 18,000 Nexus 7000s in the wild, and over 3,000,000 10GB ports? That alone is pretty amazing to me. During this time he gave us a run down of the F2, and Fab2 series cards for the Nexus 7000, which can provide 550Gbps per slot, 17.6Tbps per chassis, essentially doubling the bandwidth available in the series. He also made mention of the new M1L series cards which have increased memory, and the Nexus 2248tpe whose large buffers (32Mb) are optimized for large data and video. He also made mention of a Nexus feature called PONG, which does L2 traceroute. I’m curious how this differs from the MAC traceroute in the 6500 series. There was also mention of the new Nexus B22 for the HP C-class enclosure. Ron has also let slip that the Nexus line is actually powered by Awesomesauce, a grave error IMHO, as any company could now reverse engineer this sauce and begin to make their own…

Next Cisco brought up two representatives from some of Cisco’s recent acquisitions. Both of them, unsurprisingly, related to IaaS/Cloud based services, Linesider and NewScale. First up, was defining the problem that their solution solves. This was the first of many times we would go through this CIO pitch of “The Problem”. In many fewer words, this problem has been defined as the desire to provide automated provisioning of cloud services. After this was clear, we got back to the good stuff. They showed us a demo of the Cisco IT Elastic Infrastructure Services (CITEIS) software, which was rather impressive.

Last but not least, Cisco’s Prashant Ghandi from the Nexus 1000V virtual switching team spoke to us regarding the 1000v and it’s future. Prashant went on to cover some topics on how data center design is changing due to the large movement into virtual infrastructures. He spoke briefly on many topics including the Virtual ASA, vWAAS, VSG, VPath, and of course VXLAN. Lots of great information, I only wish we had more time to spend with them as we ran over and were not able to ask many questions.

Conclusion

Cisco puts on a great show, from the room to the stellar presentations, and of course their products. It’s honestly no wonder why they’re leaders in the industry as they are innovating their way through problems. Where they can’t innovate, they buy. Although this strategy hasn’t always worked out for them, it does keep them in the top seat. And you can’t deny their core competency products are tough to beat.

Tech Field Day Disclaimer

Cisco Systems was a sponsoring vendor for Network Field Day 2 and as such they my travel expenses were indirectly paid in part by them. However, I was not paid to write about them, nor was I asked to give them special consideration. Any opinion expressed by me is mine and mine alone.

Well, here is the update that I promised you. I’ve spent the last few days with some of the top minds in Networking industry. One of the most exciting technologies being presented was OpenFlow which allows for a concept referred to as Software Defined Networking (SND). No matter who you are, or who you work for, this should be something interesting for you. OpenFlow could have real benefits from the Enterprise all the way up to large Service Providers networks, just imagine being able to move flows of traffic around on your network without disturbing other traffic headed to the same destination? Seriously, we will finally be able to control networks the same way people (users) think we’re able to now. But I’m seriously getting ahead of myself…

This post is already going to be long enough without me providing every last detail on what’s going on with OpenFlow development, so I’ve kept my comments to a bare minimum. Below I’ve included the days events in chronological order, (at least to the best of my memory) although Ivan has suggested watching them in a specific order. I’ve included PDFs of their slide decks where I can, but not everyone provided them. The day started off with an opening presentation from Stephen Foskett and Greg Ferro.

First up was Kyle Forster of Big Switch (presentation) who talked about the company and its vision for OpenFlow networking.

Next up was Curt Beckmann of Brocade (presentation).

David Meyer of Cisco (presentation) had a great presentation on the limitations of complexity vs. robustness.

Don Clark of NEC presented his companies ProgrammableFlow product line, which is the only shipping implementations of OpenFlow. This doesn’t even compare to their full presentation which we got the next day.

David Ward of Juniper (presentation) gave us some real world examples of problems they hope to solve.

Next Google and Yahoo! went on to talk about how they’re using OpenFlow. It seems they both have been interested in using OpenFlow to solve some inherent issues in IaaS cloud service. First, we have Ed Crabbe of Google (presentation) followed immediately by Igor Gashinksy of Yahoo! (presentation)

After the Morning talks we had a few minutes for quesitons, and after lunch Ivan Pepelnjak led the Technical Q&A.

Conclusion

Very cool stuff indeed. Soon I’ll be posting about later talks with NEC and Juniper, both of which continue to expand on the need for developing OpenFlow. If you haven’t had enough as of yet, you can also read Derick Winkworth or Ethan Banks posts on the Packet Pushers blog. Packet Pushers has also put out a Podcast that was recorded just moments after the Symposium which you can find here. You can also read more on the OpenFlow website, the Open Networking Foundation site, or check out NOX, the free OpenFlow controller.

What is OpenFlow?

OpenFlow is a proposed standard for exchanging flow data between controllers and networking devices. OpenFlow has the potential to move our networking control plane into the world of Software Defined Networking. But what does that mean for you?

The biggest advantage to having a SDN/OpenFlow enabled network is that you’re able to add plugins to your control plane from multiple vendors. Since it is an open standard, anyone can write modules to add control features for your network, allowing you the flexibility to use any of those to enhance your network.

Panelists

Tech Field Day has done a great job bringing the top minds together, the line up looks something like this.

• Guido Appenzeller Kyle Foster (Big Switch)
• Curt Beckmann (Brocade)
• David Meyer (Cisco)
• Ed Crabbe (Google)
• David Ward (Juniper)
• Don Clark (NEC)
• Samrat Ganguily (NEC)
• Igor Gashinksy (Yahoo)

Watch the Stream

Followup

After the event, I hope to have some more interesting tidbits to update here as I will be taking some notes on the more interesting bits being discussed. But for now, be sure to check out the Packet Pusher’s blog for some great links and information on OpenFlow. Be on the lookout for an updated post hopefully later today.

As I feel this may be a regular section of the blog due to my lack of availability. Please suggest a better name for this “series”. I would certainly appreciate it, as would my readers who have heard enough of my bad humor…

SSL as we know it has been compromised!
The other Tony, as in Tony Bourke has brought to my attention the recently BEAST exploit that compromises TLS1.0 aka, SSL as you know it. This has been fixed in TLS 1.1 and 1.2, but as it seems, there is very little support out there for anything but TLS 1.0 thanks to the OpenSSL project.

TLS 1.2 and NLB
This is a follow up in a way to the article above, Tony talks about solving the TLS issue using NLBs.

IT Panic Mode
Tom bring up some very good points discussing how engineers deal with stress during outages. And he throws out a great Ghostbusters quote!

Nexus BFD
Interesting article discussing some oddities in the way the Nexus handles BFD processing.

The Reason Enterprises aren’t deploying IPv6
Ethan brings up some great points here discussing why Enterprise enviorments haven’t deployed IPv6, or in many cases, haven’t even considered it.

IPexpert IOU Topology
@jdsilva has built a great IOU Netmap for use with IPexpert’s CCIE R&S labs.

The Last Cable Tool…
Tom has found an interesting tool put out by Gerber. I’d like to see one of these in the store so I could get a feel for it before throwing down some hardcore cash…

MPLS is not Tunneling!
Yet another great post by Ivan, discussing the differences between MPLS virtual circuits and a true tunnel.

Is RIM using Cisco Nexus?
This weeks RIM failure was apparently caused by a core switch failure within their infrastructure. They stated that, “Although the system is designed to failover to a back-up switch, the failover did not function as previously tested.” — This makes me wonder if they’ve experienced some of the same fail over issues as we have with the Nexus line. As these have been fixed in later revisions of code, I would certainly hope this wasn’t the case.