Building A Lego Data Center Juniper Style

JDC-BirdsEye

I think I’ve been intrigued by building with Lego sets as far back as I could remember.  I had a plastic case full of them that I would use to build spaceships and castles day in and day out.  I think much of that building experience paid off when I walked into the real world and I started building data centers.  Racks and rails are network engineering versions of the venerable Lego brick.  Little did I know what would happen later.

Ashton Bothman (@ABothman) is a social media rock star for Juniper Networks.  She emailed me and asked me if I would like to participate in a contest to build a data center from Lego bricks.  You could imagine my response:

YES!!!!!!!!!!!!!

I like the fact that Ashton sent me a bunch of good old fashioned Lego bricks.  One of the things that has bugged me a bit since the new licensed sets came out has been the reliance on specialized pieces.  Real Lego means using the same bricks for everything, not custom-molded pieces.  Ashton did it right by me.

Here’s a few of my favorite shots of my Juniper Lego data center:

My rack setup.  I even labeled some of the devices!

My rack setup. I even labeled some of the devices!

Ladder racks for my Lego cables.  I like things clean.

Ladder racks for my Lego cables. I like things clean.

Can't have a data center with a generator.  Complete with flashing lights.

Can’t have a data center with a generator. Complete with flashing lights.

The Big Red Button.  EPO is a siren call for troublemakers.

The Big Red Button. EPO is a siren call for troublemakers.

The Token Unix Guy.  Complete with beard and old workstation.

The Token Unix Guy. Complete with beard and old workstation.

Storage lockers and a fire extinguisher.  I didn't have enough bricks for a halon system.

Storage lockers and a fire extinguisher. I didn’t have enough bricks for a halon system.

The Obligatory Logo Shot.  Just for Ashton.

The Obligatory Logo Shot. Just for Ashton.


Tom’s Take

This was fun.  It’s also for a great cause in the end.  My son has already been eyeing this set and he helped a bit in the placement of the pirate DC admin and the lights on the server racks.  He wanted to put some ninjas in the data center when I asked him what else was needed.  Maybe he’s got a future in IT after all.

JDC-Overview

Here are some more Lego data centers from other contest participants:

Ivan Pepelnjak’s Lego Data Center

Stephen Foskett’s Datacenter History: Through The Ages in Lego

Amy Arnold’s You Built a Data Center?  Out Of A DeLorean?

Juniper Networks Warrior – Review

Documentation is the driest form of communication there is. Whether it be router release notes or stereo instructions I never seem to be able to find a way to read more than a paragraph before tossing things aside. You’d think by now that someone would come up with a better way to educate without driving someone to drinking.

O’Reilly Media has always done a good job of creating technical content that didn’t make me pass out from boredom. They’ve figured out how to strike a balance between what needs to be said and the more effective and entertaining way to say it. Once I started reading the books with the funny animals on the covers I started learning a lot more about the things I was working on. One book in particular caught my eye – Network Warrior by Gary Donahue. Billed as “everything you need to know that wasn’t on the CCNA,” it is a great introduction to more advanced topics that are encountered in day-to-day network operations like spanning tree or the Catalyst series of switches. Network Warrior is heavily influenced by Cisco equipment. While the concepts are pretty straight forward the bias does lean toward the building on Tasman Drive. Thankfully, O’Reilly enlisted an author to bring the Warrior series to Sunnyvale as well:

Screen Shot 2013-05-13 at 2.53.13 PM

Peter Southwick was enlisted to write a Warrior book from the perspective of Juniper engineer. I picked up a copy of this book the last time I was at Juniper’s headquarters and have spent the past few weeks digesting the info inside.

What Worked

Documentation is boring. It’s a dry description of how to do everything. How-to guides are a bit better written, but they still have to cover the basics. I am a much bigger fan of the cookbook, which is a how-to that takes basic building blocks and turns them into a recipe that accomplishes something. That’s what Juniper Networks Warrior is really about. It’s a cookbook with some context. Each of the vignettes tells a story about a specific deployment or project. By providing a back story to everything you get a feel for how real implementations tend to flow back and forth between planning and execution. Also, the solutions provided really do a great job of cutting past the boring rote documentation and into things you’ll use more than once. Couple that with the vignettes being based on something other than technology-focused chapters and it becomes apparent that this is a very holistic view for technology implementation.

What Didn’t Work

There were a couple of things that didn’t work well in the narrative to me. The first was the “tribe” theme. Southwick continually refers to the teams that he worked with in his projects as “tribes.” While I understand that this does fit somewhat with the whole idea behind the Warrior books, it felt a bit out of place. Especially since Donahue didn’t use it in either Network Warrior or Arista Warrior (another entry in the series). I really did try to look past it and not imagine groups of network engineers carrying spears and slings around the data center, but it was mentioned so often in place of “team” or “group” that it became jarring after a while.

The other piece that bothered me a bit was in Chapter 3: Data Center Security Design. The author went out of the way to mention that the solution that his “tribe” came up with was in direct competition with a competing one that utilized Cisco gear. He also mentioned that the Juniper solution was going to displace the Cisco solution to a certain degree. I get that. Vendor displacement happens all the time in the VAR world. What bothered me was the few occasional mentions of a competitor’s gear with words like “forced” or casting something in a negative light simply due to the sticker on the front. I’ve covered that before in my negative marketing post. Why I bring it up here is because it wasn’t present in either Network or Arista Warrior, even though the latter is a vendor-sponsored manual like this one. In particular, an anecdote in the Arista chapter on VRRP mentions that Cisco wanted to shut down the RFC for VRRP due to similarity with HSRP. No negativity, no poking with a sharp stick. Just a statement of fact and the readers are left to draw their own conclusions.

I realize the books of this nature often require input from the technical resources of a vendor. I also realize that sometimes the regard that these books are held in sometimes looks to be a very appealing platform to launch marketing campaigns or to use a factually based volume to mention some opinion-based verbiage. I sincerely hope that future volumes tone down the rhetoric just a bit for the sake of providing a good reference volume. Engineers will keep going back to a book if it gives them a healthy dose of the information they need to do their jobs. They won’t go back nearly as often to a book that spends too much time discussing the pros and cons of a particular vendor’s solution. I’d rather see pages of facts and configs that get the job done.

Review Disclaimer

The copy of Juniper Networks Warrior that I reviewed was provided to me by Juniper Networks. I received it as part of a group of items during Network Field Day 5. At no time did Juniper ask for nor were they promised any consideration in the writing of this review. All of the analysis and conclusions contained herein are mine and mine alone.

Juniper MX Series – Review

A year ago I told myself I needed to start learning Junos.  While I did sign up for the Fast Track program and have spent a lot of time trying to get the basics of the JNCIA down, I still haven’t gotten around to taking the test.  In the meantime, I’ve had a lot more interaction with Juniper users and Juniper employees.  One of those was Doug Hanks.  I met him at Network Field Day 4 this year.  He told me about a book that he had recently authored that I might want to check out if I wanted to learn more about Junos and specifically the MX router platform.  Doug was kind enough to send me an autographed copy:

MX Series Cover

The covers on O’Reilly books are always the best.  It’s like a zoo with awesome content inside.

This is not a book for the beginner.  Frankly, most O’Reilly press books are written for people that have a good idea about what they’re doing.  If you want to get your feet wet with Junos, you probably need to look at the Day One guides that Juniper provides free of charge.  When you’ve gone through those and want to step up to a more in-depth volume you should pick up this book.  It’s the most extensive, exhaustive guide to a platform that I’ve ever seen in a very long time.  This isn’t just an overview of the MX or a simple configuration guide.  This book should be shipped with every MX router that leaves Sunnyvale.  This is a manual for the TRIO chipset and all the tricks you can do on it.

The MX Series book does a great job of not only explaining what makes the MX and TRIO chipset different, but also how to make it perform at the top of its game.  The chapter on Class of Service (CoS) alone is worth its weight in gold.  That topic has worried me in the past because of other vendor’s simplified command line interfaces for Quality of Service (QoS).  This book spells everything out in a nice orderly fashion and makes it all make more sense than I’ve seen before.  I’m pretty sure those pages are going to get reused a lot as I start my journey down the path of Junos.  But just because the book make things easy to understand doesn’t mean that it’s shallow on technical knowledge or depth.  The config snippet for DDoS mitigation is fifteen pages long!  That’s a lot of info that you aren’t going to find in a day one guide.  And all of those chapters are backed up with case studies.  It’s not enough that you know how to configure some obscure command.  Instead, you need to see where to use it and what context makes the most sense.  That’s where these things hit home for me.  I was always a fan of word problems in math.  Simple formulas didn’t really hit home for me.  I needed an example to reinforce the topic.  This book does an outstanding job of giving me those case studies.


Tom’s Take

The Juniper MX Series book is now my reference point for what an deep dive tome on a platform should look like.  It covers the technology to a very exhaustive depth without ever really getting bogged down in the details.  If you sit down and read this cover to cover, you will come away with a better understanding of the MX platform that anyone else on the planet except perhaps the developers.  That being said, don’t sit down and read it all at once.  Take the time to go into the case studies and implement them on your test lab to see how the various features interact together.  Use this book as an encyclopedia, not as a piece of fireside reading material.  You’ll thank yourself much later when you’re not having dreams of CoS policies and tri-color policers.

Disclaimer

This copy of Juniper MX Series was provided to me at no charge by Doug Hanks for the purpose of review.  I agreed with Doug to provide an unbiased review of his book based on my reading of it.  There was no consideration given to him on the basis of providing the book and he never asked for any when providing it.  The opinions and analysis provided in this review reflect my views and mine alone.

Juniper – Land of Unicorns and Broccoli

The final Network Field Day 4 (NFD4) presentation was from Juniper. Juniper has been a big supporter of Tech Field Day so getting to see some of their newest technology and advances was just another step in the the wonderful partnership. We arrived Friday afternoon to a very delicious lunch before settling in for the four hour session.

We were introduced to one of our own, Derick Winkworth (@cloudtoad). Derick was a delegate and NFD2 and has recently come to Juniper as the PM of Automation. It’s always nice to see someone from Tech Field Day in front of us for the vendor. Some have said that the vendors are stealing away members of the Field Day community, but I see it more as the vendors realizing the unique opportunity to bring someone on board the “gets it.” However, I couldn’t let Derick off the hook quite that easily. At Cisco Live, Derick proved his love for Dave Ward of Cisco by jumping up during Dave’s OnePK panel and throwing a pair of men’s briefs at him with “I <3 Dave” written on the back. Lots of laughs were had by all, and Dave seemed appreciative of his gift. Once I learned the Derick was presenting first for NFD4, I hatched my own fan boy plot. When Derick walked up front to face the NFD delegates as “the enemy,” I too proved my love for the Cloud Toad by jumping up and tossing him a pair of underwear as well. These were adorned with “I <3 @cloudtoad” to show Derick that he too has groupies out there.

Derick then proceeded to give us a small overview of the decision he made to join Juniper and the things that he wanted to improve to make everyone’s life a bit better. I can tell the Derick is genuinely pumped about his job and really wants to make a difference. If someone is that excited about going to work every day, it really doesn’t matter if it’s for a vendor or a VAR or even a garbageman. I only wish that half the people I work with had the same passion for their jobs as Derick.

Our first presentation was a bit of a surprise. We got a first hand look at storage from Simon Gordon. Yes, Juniper shook things up by making their first peek all about hard drives. Okay, so maybe it was more about showing how technologies like QFabric can help accelerate data transfers back and forth across your network. The two storage people in the room seemed fascinated by the peek into how Juniper handled these kinds of things. I was a bit lost with all the terminology and tried to keep up as best I could, but that’s what the recorded video archive is for, right?  It’s no surprise that Juniper is pitching QFabric as a solution for the converged data center, just like their competitors are pitching their own fabric solutions.  It just reminds me that I need to spend some more time studying these fabric systems.  Also, you can see here where the demo gremlins bit the Juniper folks.  It seemed to happen to everyone this time around.  The discussion, especially from Colin McNamara (@colinmcnamara) did a great job of filling the time where the demo gremlins were having their fun.

The second presentation was over Virtual Chassis, Juniper’s method of stacking switches together to unify control planes and create managment simplicity. The idea is to take a group of switches and interconnect the backplanes to create high throughput while maintaining the ability to program them quickly. The technology is kind of interesting, especially when you extend it toward something like QFabric to create a miniature version of the large fabric deployment. However, here is where I get to the bad guy a bit… Juniper, while this technology is quite compelling, the presentation fell a bit flat. I know that Tech Field Day has a reputation for chewing up presenters. I know that some sponsors are afraid that if they don’t have someone technical in front of the group that bedlam and chaos will erupt. That being said, make sure that the presenter is engaging as well as technical. I have nothing but respect for the presenter and I’m sure he’s doing amazing things with the technology. I just don’t think he felt all the comfortable in front of our group talking about it. I know how nervous you can be during a presentation. Little things like demo failures can throw you off your game. But in the end, a bad presentation can be saved by a good presenter. A good presentation can take a hit from a less-than-ideal presenter.  Virtual chassis is a huge talking point for me.  Not only because it’s the way that the majority of my customers will interconnect their devices.  Not because it’s a non-proprietary connector way to interconnect switches.  It’s because Virtual Chassis is the foundation for some exciting things (that may or may not be public knowledge) around fabrics that I can’t wait to see.

Up next was Kyle Adams with Mykonos. They are a new acquistion by Juniper in the security arena. They have developed a software platform that provides a solution to the problem of web application security. Mykonos acts like a reverse proxy in front of your web servers. When it’s installed, it intercepts all of the traffic traveling to your Internet-facing servers and injects a bit of forbidden fruit to catch hackers. Things like fake debug codes, hidden text fields, and even phantom configuration files. Mykonos calls these “tar pits” and they are designed to fool the bad guys into a trail of red herrings. Becauase all of the tar pit data is generated on the fly and injected into the HTTP session, no modification of the existing servers is necessary. That is the piece that had eluded my understanding up until this point. I always thought Mykonos integrated into your infrastructure and sprayed fake data all over your web servers in the hope of catching people trying to footprint your network. Realizing now that it does this instead from the network level, it interesting to see the approaches that Mykonos can take. The tar pit data is practically invisible to the end user. Only those that are snooping for less-than-honorable intentions may even notice it. But once they take the bait and start digging a bit deeper, that’s when Mykonos has them. The software then creates a “super cookie” on the system as a method of identifying the attacker. These super coookes are suprisingly resilient, using combinations of Java and Flash and other stuff to stay persistent even if the original cookie is deleted. Services like Hulu and Netflix use them to better identify customers. Mykonos uses them to tie attacker sessions together and collect data. There are some privacy concerns naturally, but that is a discussion for a different day. Once Mykonos has tagged you, that’s when the countermeasures can start getting implemented.

I loved watching this in demo form. Mykonos randomly selects a response based on threat level and deploys it in an effort to prevent the attacker from compromising things. Using methods such as escalting network latency back to the attacker or creating fake .htacess files with convincingly encrypted usernames and passwords, Mykonos sets the hook to reel in the big fish. While the attacker is churning through data and trying to compromise what he thinks is a legitimate security hole, Mykonos is collecting data the whole time to later identify the user. That way, they can either be blocked from accessing your site or perhaps even prosecuted if desired. I loved the peek at Mykonos. I can see why Christofer Hoff (@beaker) was so excited to bring them on board. This refreshing approach to web application firewalls is just crazy enough to work well. As I said on the video, Mykonos is the ultimate way to troll attackers.

The final presentation at Juniper once again starred Derick Winkworth along with Dan Backman. Dan had presented over workflow automation at NFD2. Today, they wanted to talk about the same topic from a slightly different perspective. Derick took the helm this time and started off with a hilarious description of the land of milk and honey and unicorns, which according to him was representitive of what happens when you can have a comfortable level of workflow automation. It’s also where the title of this post came from.  As you can tell from the video, this was the best part of having a former delegate presenting to us.  He knew just how to keep us in stitches with all his whiteboarding and descriptions.  After I was done almost spitting my refreshments all over my laptop, he moved on to his only “slide”, which was actually a Visio diagram. I suppose this means that Derick has entered the Hall Of Slideless TFD Presenters. His approach to workflow automation actually got me a bit excited. He talked less about scripting commands or automating configuration tasks and instead talked about all the disparate systems out there and how the lack of communication between them can cause the silo effect present in many organizations to amplify.  I like Derick’s approach to using Junos to pull information in from various different sources to help expedite things like troubleshooting or process execution.  Leveraging other utilities like curl helps standardize the whole shooing match without reinventing the wheel.  If I can use the same utilities that I’ve always used, all my existing knowledge doesn’t become invalidated or replaced.  That really speaks to me.  Don’t make me unlearn everything.  Give me the ability to take your product and use additional tools to do amazing things.  That, to me, is the essence of SDN.

If you’d like to learn more about the various Juniper products listed above, be sure to visit their website at http://www.juniper.net.  You can also follow their main Twitter account as @JuniperNetworks.


Tom’s Take

Juniper’s doing some neat things from what they showed us at NFD4.  They appear to be focusing on fabric technology, both from the QFabric converged networking overview and even the Virtual Chassis discussion.  Of course, protecting things is of the utmost importance, so Mykonos can prevent the bad guys from getting the goods in a very novel way.  Uniting all of this is Junos, the single OS that has all kinds of capabilities around SDN and now OpenFlow 1.3.  Sure, the demo gremlins hit them a couple of times, but they were able to keep the conversation going for the most part and present some really compelling use cases for their plans.  The key for Juniper is to get the word out about all their technology and quit putting up walls that try and “hide” the inner workings of things.  Geeks really like seeing all the parts and pieces work.  Geeks feel a lot more comfortable knowing the ins and outs of a process.  That will end up winning more converts in the long run than anything else.

Tech Field Day Disclaimer

Juniper was a sponsor of Network Field Day 4.  As such, they were responsible for covering a portion of my travel and lodging expenses while attending Network Field Day 4.  In addition, Juniper provided me with a hooded sweatshirt with the Juniper logo and some “I Wish This Ran Junos” stickers. They did not ask for, nor where they promised any kind of consideration in the writing of this review.  The opinions and analysis provided within are my own and any errors or omissions are mine and mine alone.

DST Configuration – Just In the Nick of Time

Today is the dreaded day in the US (and other places) when we must sacrifice an hour of our precious time to the sun deity so that he might rise again in the morning.  While this is great for being outdoors and enjoying the sunshine all the way into the late evening hours, it does wreak havoc on our networking equipment that relies on precise timing to let us know when a core dump happened or when that last PRI call came in when running debug isdn q931.  However, getting the right time running on our devices can be a challenge.  In this post, I will cover configuring Daylight Savings Time on Cisco, HP, and Juniper network equipment for the most pervasive OS deployments.  Note that some configurations are more complicated than others.  Also, I will be using Central Time (CST/CDT) for my examples, which is GMT -6 (-5 in DST).  Adjust as necessary for your neck of the woods.  I’m also going to assume that you’ve configured NTP/SNTP on your devices.  If not, read my blog post about it and go do that first.  Don’t worry, I’ll still be here when you get back.  I have free time.

Cisco

I’ve covered the basics of setting DST config on Cisco IOS before, but I’ll put it here for the sake of completeness.  In IOS (and IOS XR), you must first set the time zone for your device:

R1(config)# clock timezone <name> <GMT offset>
R1(config)# clock timezone CST -6

Easy, right?  Now for the fun part.  Cisco has always required manual configuration of DST on their IOS devices.  This is likely due to them being shipped all around the world and various countries observing DST (or not) and even different regions observing it differently.  At any rate, you must the clock summer-time command to configure your IOS clock to jump when needed.  Note that in the US, DST begins at 2:00 a.m. local time on the second Sunday in March and ends a 2:00 a.m. local time on the first Sunday in November.  That will help you decode this code string:

R1(config)# clock summer-time <name> recurring <week number start> <day> <month> <time to start> <week number end> <day> <month> <time to end>
R1(config)# clock summer-time CDT recurring 2 Sun Mar 2:00 1 Sun Nov 2:00

Now your clock will jump when necessary on the correct day.  Note that this was a really handy configuration requirement to have in 2007, when the US government decided to change DST from the previous requirement of the first Sunday in April at the start and the last Sunday in October to end.  With Cisco, manual reconfiguration was required, but no OS updates were needed.

HP (Procurve/E-Series and H3C/A-Series)

As near as I can tell, all HP Networking devices derive their DST settings from the OS.  That’s great…unless you’re working on an old device or one that hasn’t been updated since the last presidential administration.  It turns out that many old HP Procurve network devices still have the pre-2007 US DST rules hard-coded in the OS.  In order to fix them, you’re going to need to plug in a config change:

ProCurve(config)# time daylight-time-rule user-defined begin-date 3/8 end-date 11/1

I know what you’re thinking.  Isn’t that going to be a pain to change every year if the dates are hard-coded?  Turns out the HP guys were ahead of us on that one too.  The system is smart enough to know that DST always happens on a Sunday.  By configuring the rule to occur on March 8th (the earliest possible second Sunday in March) and November 1st (the earliest possible first Sunday in November), the system will wait until the Sunday that matches or follows that date to enact the DST for the device.  Hooray for logic!  Note that if you upgrade the OS of your device to a release that supports the correct post-2007 DST configuration, you won’t need to remove the above configuration.  It will work correctly.

Juniper

Juniper configures DST based on the information found in the IANA Timezone Database, often just called tz.  First, you want to get your device configured for NTP.  I’m going to refer you to Rich Lowton’s excellent blog post about that.  After you’ve configured your timezone in Junos, the system will automatically correct your local clock to reflect DST when appropriate.  Very handy, and it makes sense when you consider that Junos is based heavily on BSD for basic OS operation.  One thing that did give me pause about this has nothing to do with Junos itself, but with the fact that there have been issues with the tz database, even as late as last October.  Thankfully, that little petty lawsuit was sidestepped thanks to the IANA taking control of the tz database.  Should you find yourself in need of making major changes to the Junos tz database without the need to do a complete system update, check out these handy instructions for setting a custom timezone over at Juniper’s website.  Just don’t be afraid to get your hands dirty with some BSD commands.


Tom’s Take

Daylight Savings Time is one of my least favorite things.  I can’t see the advantage of having that extra hour of daylight to push the sunlight well past bedtime for my kids.  Likewise, I think waking up to sunrise is overrated.  As a networking professional, DST changes give me heartburn even when everything runs correctly.  And I’m not even going to bring up the issues with phone systems like CallManager 4.x and the “never going to be patched” DST issues with Windows 2000.  Or the Java issues with 79xx phones that still creep up to this day and make DST and confusing couple of weeks for those that won’t upgrade technology. Or even the bugs in the iPhone with DST that cause clocks to spring the wrong way or alarms to fail to fire at the proper time.  In the end though, network enginee…rock stars are required to pull out our magical bags and make everything “just work”.  Thanks to some foresight by major networking vendors, it’s fairly easy to figure out DST changes and have them applied automagically.  It’s also easy to change things when someone decides they want their kids to have an extra hour of daylight to go trick-or-treating at Halloween (I really wish I was kidding).  If you make sure you’ve taken care of everything ahead of time, you won’t have to worry about losing more than just one hour of sleep on the second Sunday in March.

2011 in Review, 2012 in Preview

2011 was a busy year for me.  I set myself some rather modest goals exactly one year ago as a way to keep my priorities focused for the coming 365 days.  How’d I do?

1. CCIE R&S: Been There. Done That. Got the Polo Shirt.

2. Upgrade to VCP4: Funny thing.  VMware went and released VMware 5 before I could get my VCP upgraded.  So I skipped straight over 4 and went right to 5.  I even got to go to class..

3. Go for CCIE: Voice: Ha! Yeah, I was starting to have my doubts when I put that one down on the list.  Thankfully, I cleared my R&S lab.  However, the thought of a second track is starting to sound compelling…

4. Wikify my documentation: Missed the mark on this one.  Spent way to much time doing things and not enough time writing them all down.  I’ll carry this one over for 2012.

5. Spend More Time Teaching: Never got around to this one.  Seems my time was otherwise occupied for the majority of the year.

Forty percent isn’t bad, right?  Instead, I found myself spending time becoming a regular guest on the Packet Pushers podcast and attending three Tech Field Day Events: Tech Field Day 5, Wireless Field Day 1, and Network Field Day 2.  I’ve gotten to meet a lot of great people from social media and made a lot of new friends.  I even managed to keep making blog posts the whole year.  That, in and of itself, is an accomplishment.

What now?  I try to put a couple of things out there as a way to hold myself to the fire and be accountable for my aspirations.  That way, I can look back in 2013 and hopefully hit at least 50% next time.  Looking forward to the next 366 days (356 if the Mayans were right):

1. Juniper – I think it’s time to broaden my horizons.  I’ve talked to the Juniper folks quite a bit in 2011.  They’ve given me a great overview of how their technology works and there is some great potential in it.  Juniper isn’t something I run into every day, but I think it would be in my best interest to start learning how to get around in the curly CLI.  After all, if they can convert Ivan, they must really have some good stuff.

2. Data Center – Another growth area that I feel I have a lot of catching up to do is in the data center.  I feel comfortable working on NX-OS somewhat, but the lack of time I get to configure it every day makes the rust a little thick some times.  If it wasn’t for guys like Tony Mattke and Jeff Fry, I’d have a lot more catching up to do.  When you look at how UCS is being positioned by Cisco and where Juniper wants to take QFabric, I think I need to spend some time picking up more data center technology.  Just in case I find myself stranded in there for an extended period of time.  Can’t have this turning into the Lord of the CLIs.

3. Advanced Virtualization – Since I finally upgraded my VCP to version 5, I can start looking at some of the more advanced certifications that didn’t exist back when I was a VCP3.  Namely the VCAP.  I’m a design junkie, so the DCD track would be a great way for me to add some of the above data center skills while picking up some best practices.  The DCA troubleshooting training would be ideal for my current role, since anything beyond a simple check of vCenter is all I can muster in the troubleshooting arena.  I’d rather spend some time learning how the ESXi CLI works than fighting with a mouse to admin my virtual infrastructure.

4. Head to The Cloud – No, not quite what you’re thinking.  I suffered an SSD failure this year and if it hadn’t been for me having two hard drives in my laptop, I’d probably have lost a good portion of my files as well.  I keep a lot of notes on my laptop and not all of them are saved elsewhere.  Last year I tried to wikify everything and failed miserably.   This year I think I’m going to take some baby steps and get my important documents and notes saved elsewhere and off my local drives.  I’m looking to replace my OneNote archive with Evernote and keep my important documents in Google Docs as opposed to local Microsoft Word.  By keeping my important documents in the cloud, I don’t have to sweat the next drive death quite as much.

The free time that I seem to have acquired now that I’ve conquered the lab seems to have been filled with a whole lot of nothing.  In this industry, you can’t sit still for very long or you’ll find yourself getting passed by almost everyone and everything.  I need to sharpen my focus back to these things to keep moving forward and spend less time sitting on my laurels.  I hope to spend even more time debating technology with the Packet Pushers and engaging with vendors at Tech Field Day.  Given how amazing and humbling 2011 was, I can’t wait to see what 2012 has in store for me.

Juniper – Network Field Day 2

Day 2 of Network Field Day started out with a super-sized session at the Juniper headquarters.  We arrived a bit hungover from the night before at Murphy’s Law and sat down to a wonderful breakfast with Abner Germanow.  He brought coffee and oatmeal and all manner of delicious items, as well as Red Bull and Vitamin Water to help flush the evil of Guiness and Bailey’s Irish Cream from our systems.  Once we were settled, Abner gave us a brief overview of Juniper as a company.  He also talked about Juniper’s support of Network Field Day last year and this year and how much they enjoy having the delegates because we ask public questions and wish to obtain knowledge to make the world a better place for networkers despite any ridicule we might suffer at each other’s hands.

Dan Backman was next up to start things off with an overview of Junos.  Rather than digging into the gory details of the underlying operating system like Mike Bushong did last year, Dan instead wanted to focus on the extensibility of Junos via things like XML and API calls.  Because Junos was designed from the ground up as a transactional operating system, it has the ability to do some very interesting things in the area of scripting and automation.  Because changes made to a device running Junos aren’t actually made until they are committed to the running config, you can have things like error checking scripts running in the background monitoring for things like OSPF processes and BGP neighbor relationships.  If I stupidly try to turn off BGP for some reason, the script can stop me from committing my changes.  This would be a great way to keep the junior admins from dropping your BGP sessions or OSPF neighbors without thinking.  As we kept moving through the CLI of Junos, the delegates were becoming more and more impressed with the capabilities inherent therein.  Many times, someone would exclaim that Junos did something that would be very handy for them, such as taking down a branch router link if a keepalive script determined that the remote side had been brought down.  By the end of Dan’s presentation, he revealed that he was in fact not running this demo on a live router, but instead had configured everything in a virtual instance running in Junosphere.  I’ve written a little about Junosphere before and I think the concept of having a virtual instantiation of Junos that is easily configurable for many different types of network design.  Juniper is using Junosphere not just for education, but for customer proof-of-concept as well.  For large customers that need to ensure that network changes won’t cause major issues, they can copy the configuration from their existing devices and recreate everything in the cloud to break as they see fit.  Only when confirmed configs are generated from the topology will the customer then decide to put that config on their live devices.  All this lists for about $5/router per day from any Juniper partner.  However, Dan hit us with our Network Field Day “Oprah Moment”.  Dan would give us access to Junosphere!  All we have to do is email him and he’ll get everything setup.  Needless to say, I’m going to be giving him a shout in the near future.

Next up was Dave Ward, Juniper’s CTO of the Platform Divison.  A curious fact about Dave: he likes to present sans shoes.  This might be disconcerting to some, but having been through business communications class in college, I can honestly say it’s not the weirdest quirk I’ve ever seen.  Dave’s presentation focused around programmable network, which is Juniper’s approach to OpenFlow.  Dave has the credentials to really delve into the weeds of programmable networking, and to be honest some of what he had to say went right by me.  It’s like listening to Ivan turn the nerd meter up to 9 or 10.  I recommend you watch part one of the Juniper video and start about halfway through to see what Dave has to say about things.  His ideas behind using our new found knowledge of programmable networking to better engineer things like link utilization and steering traffic to specific locations is rather interesting.

Next up was Kevin with a discussion about vGW, which came for Altor Networks, and using Juniper devices to secure virtual flows between switches.  This is quickly become a point of contention with customers, especially in the compliance area.  If I can’t see the flows going between VMs, how can I certify my network for things like Payment Card Industry (PCI) compliance?  Worse yet, if someone nefarious compromises my virtual infrastructure and begins attacking VMs in the same vSwitch, if I can’t see the traffic I’ll never know what’s happening.  Juniper is using vGW to address all of these issues in an easy-to-use manner.  vGW allows you to do things like attach different security policies to each virtual NIC on a VM and then let the policy follow the VM around the network as it vMotions from here to eternity.  vGW can also reroute traffic to a number of different IDS devices to snoop on traffic flows and determine whether or not you’ve got someone in your network that isn’t supposed to be there.  There’s even a new antivirus module in the new 5.0 release that can provide AV services to VMs without the need to install a heavy AV client on the host OS and worry about things like updates and scanning.  I hope that this becomes the new model for AV security for VMs going forward, as I realize the need to run AV on systems but detest the fact that so many software licenses are required when there is a better solution out there that is quick and easy and lightweight.

The last presentation was over QFabric.  This new technology represents Juniper’s foray in the the fabric switching technology sweeping across the data center like wildfire right now.  I’ve discussed at length my thoughts on QFabric before.  I still see it as a proprietary solution that works really well for switching packets quickly among end nodes.  Of course, to me the real irony is that HP/Procurve spent many years focusing on their Edge-centric network view of the world and eventually bought 3COM/Huawei to compete in the data center core.  Juniper instead went to the edge-centric model and seems to be ready to bring it to the masses.  Irony indeed.  I do have to call out Juniper here for their expected slide about “The Problem”:

The Problem

The Problem - courtesy of Tony Bourke

To Juniper’s credit, once I pointed out that we may or may not have seen this slide before, the presenter quickly acknowledged it and moved on quickly to get to the good stuff about QFabric.  I didn’t necessarily learn any more about QFabric that I already knew from my own research, but it was a good talk overall.  If you want to delve more into QFabric, head over to Ivan’s site and read through his QFabric posts.

Our last treat from the super session was a tour of the Proof-of-Concept labs at the Juniper EBC.  They’ve got a lot of equipment in there and boy is it loud!  I did get to see how Juniper equipment plays well with others, though, as they had a traded-in CRS-1 floating around with a big “I Wish This Ran Junos” sticker.  Tony Mattke was even kind enough to take a picture of it.

Here are the videos: Part 1 – Introduction to Junos

Part 2 – Open Flow Deep Dive

Part 3 – A Dive Into Security

Part 4 – Network Design with QFabric


Tom’s Take

I’m coming around to Juniper.  The transaction-based model allows me to fat-finger things and catch them before I screw up royally.  Their equipment runs really well from what I’ve been told and their market share seems to be growing in the enterprise from all accounts.  I’ve pretty much consigned myself at this point to learning Junos as my second CLI language, and the access that Dan Backman is going to provide to Junosphere will help in that regard.  I can’t say how long it will take me to be a convert to the cause of Juniper, but if they ever introduce a phone system into the lineup, watch out!  I also consider the fine presentations that were put on in this four hour session to be the benchmark for all future Tech Field Day presenters.  Very little fluff, packed with good info and demonstrations is the way to go when you present to delegates at Tech Field Day.  Otherwise, the water bottles will start flying.


Tech Field Day Disclaimer

Juniper was a sponsor of Network Field Day 2, as as such was responsible for paying a portion of my travel and lodging fees. They also provided us with breakfast and a USB drive containing the Day One Juniper guides and markting collateral. At no time did Juniper ask for, nor where they promised any kind of consideration in the drafting of this review. The analysis and opinions herein are mine and mine alone.

My Thoughts on Dell and Force 10

Big announcement today concerning Michael Dell’s little computer company and their drive to keep up with the Joneses in the data center.  Dell has been a player in the server market for many years, but in the data center they are quickly losing out to the likes of HP, Cisco, and even IBM.  Until they hired away HP’s chief blade architect a few years ago, they weren’t even interested in blade servers/enclosures.  Instead, they relied on the tried-and-true model of 1U rack-mounted servers everywhere.  That has all changed recently with the explosion of high-density server enclosures becoming the rage with customers.  Now, the push seems to be headed toward offering a soup-to-nuts portfolio that allows your customers to go to one vendor to get all their data center needs, whether it be storage, servers, or networking.  HP was the first company to really do this, having acquired 3Com last year and integrating their core switching products into the Flex family of data center offerings.  Cisco has always had a strong background in networking, and their UCS product line appears to be coming on strong as of late.  IBM has been a constant bellweather in the market, offering storage and servers, but being forced to outsource their networking offerings.  Dell found itself in the same boat as IBM, relying on Brocade and Juniper as OEM partners to offer their networking connectivity for anything beyond simple low-end ports, which are covered by the Dell PowerConnect line.  However, the days of OEM relationships are quickly drying up, as the bigger vendors are on an acquisition spree and the little fish in the market are becoming meals for hungry vendors.

Dell has enjoyed a very strong relationship with Brocade in the past, and the positioning of Brocade as a strong player in the data center made them a very logical target for Dell’s pocketbook.  In fact, it had been reported several weeks ago that a deal between Dell and Brocade was all but done.  So, imagine the surprise of everyone when Dell announced on July 20th that they were buying Force10 Networks, a smaller vendor that specializes in high-performance switching for markets such as stock market trading floors.  To say that my Twitter stream erupted was an understatement.  We all knew that Dell was going to buy someone, but most figured it would be Brocade.  I even ranked Arista ahead of Force10 as the likely target of Dell’s acquisition fever.  I just figured that Force10 was a little too small and specialized to garner much attention from the big boys.  Don’t get me wrong, I think that Force10 makes some great products.  Their presentation at Network Field Day was well received, and they several customers that will swear by their performance.

What I expected from Dell was a purchase that would serve them across their whole network portfolio.  Brocade would have given them a replacement for the PowerConnect line at the low end as well as data center and fibre channel connectivity options.  They were already OEM-ing Brocade’s product line, so why not buy them outright?  I think that comes down the fact that EVERYONE is OEM-ing from Brocade (or so it seems).  EMC, IBM, and even HP have products from Brocade in their offerings.  If Dell had purchased Brocade outright, it would have forced those vendors to look elsewhere for fibre channel connectivity.  This would either be due to a desire to not inflate a competitor’s bottom line, or perhaps later if and when Dell decided to change the rules of how other vendors OEM from them.  This move away from a Dell-owned Brocade would have really muddied the waters for those inside Dell that wanted Brocade for it’s revenue stream.  As it is, I’m pretty sure that Dell is going to scale back on the B-series PowerConnect stuff everywhere but the fibre channel line and use Force10 as the main data center core technology group, while at the same time maintaining the PowerConnect line at the lower end for campus connectivity.  This will allow them to keep their margins on the PowerConnect side while at the same time increasing them in the data center, since they’ll no longer have to pay OEM fees to Brocade.

Whither Juniper?

The next most popular topic of conversation after Force10 involved…Juniper.  Juniper was a long-shot target of acquisition for Dell (and others), and now that the only major server vendor without a solid networking background is IBM, people are staring to ask who, if not IBM, is going to buy Juniper?  And when?

Folks, Juniper isn’t an easy acquisition.  Add in the fact that the IBM you see today isn’t the IBM of your father (or my early networking days for that matter), and you’ll see that Juniper is best left to its own devices for the time being.  Juniper isn’t really what I would consider a “data center switching” company like Force10 or Arista.  They tend to fall more in the service provider/campus LAN market to me.  I think that if someone like IBM could pony up the billions to buy them, they’d quickly find themselves lost in what to do with Juniper’s other technologies.  Buying Juniper for their data center offerings would be like buying a Porsche because you like the stereo.  You’re missing the point.  I’d wager money that Juniper is more likely to buy twenty more companies before they get bought themselves.  Their networking business is growing by leaps and bounds right now, and saddling them with a large company as ‘oversight’ would probably cripple their innovation.

IBM already owns a high-speed, low-latency networking company that they bought about this time last year, Blade Networks.  Why should they go out and spend more money right now?  Especially if they are happy with their OEM partnerships with Brocade and Juniper (like Dell has been doing previously)?  IBM has shed so much of what it used to be that it no longer resembles the monster that it once was.  Gone are the PCs and Thinkpads and low-end servers.  Instead, they’ve moved to the blade and high end server market, with storage to complement.  They used to be number one, but have long since been passed by HP.  Now they find themselves fighting off their old foe Dell and this new upstart, Cisco.  Does it really make sense for them to mortgage the family farm to buy Juniper, only to let it die off?  I’d rather see them make a play for a smaller company, maybe even one as well-known as Arista.  It would fit the profile a bit better than buying Juniper.  That’s more HP’s style.

Tom’s Take

I fully expect the trumpets of Dell’s new-found data center switching expertise to start sounding as soon as the ink is dry on Force10.  In fact, don’t be surprised to see it come up during Tech Field Day 7 next month in Austin, TX.  I think Dell will get a lot of mileage out of their new stalking horse, as most of the complaints I’ve heard about Force10 come from their sales staff, and we all know how great Dell is at selling.

For now, Juniper needs to sit back and bide its time, perhaps stroking a white Persian cat.  They can go down the interoperability road, telling their customers that since they have strong OEM relationships with many vendors, they can tie all these new switches together will very little effort.  They shouldn’t worry themselves with the idea that anyone is going to buy them anytime soon.

An Outsider’s View of Junosphere

It’s no secret that learning a vendor’s equipment takes lots and lots of time at the command line interface (CLI).  You can spend all the time you want pouring over training manuals and reference documentation, but until you get some “stick time” with the phosphors of a console screen, it’s probably not going to stick.  When I was studying for my CCIE R&S, I spent a lot of time using GNS3, a popular GUI for configuring Dynamips, the Cisco IOS simulator developed by the community.  There was no way I would be about to afford the equipment to replicate the lab topologies, as my training budget wasn’t very forgiving outside the test costs and any equipment I did manage to scrounge up usually went into production soon after that.  GNS3 afforded me the opportunity to create my own lab environments to play with protocols and configurations.  I’d say 75-80% of my lab work for the CCIE was done on GNS3.  The only things I couldn’t test were hardware-specific configurations, like the QoS found on Catalyst switches, or things that caused massive processor usage, like configuring NTP on more than two routers.  I would have killed to have had access to something a little more stable.

Cisco recently released a virtual router offering based around IOS-on-Unix (IOU), a formerly-internal testing tool that was leaked and cracked for use by non-Cisco people.  The official IOU simulation from Cisco revolves around their training material, so using it to setup your own configurations is very difficult.  Juniper Networks, on the other hand, has decided to release their own emulated OS environment built around their own hardware operating system, Junos.  This product is called Junosphere.  I was recently lucky enough to take part in a Packet Pushers episode where we talked with some of the minds behind Junosphere.  What follows here are my thoughts about the product based on this podcast and some people in the industry that I’ve talked to.

Junosphere is a cloud-based emulation platform being offered by Juniper for the purpose of building a lab environment for testing or education purposes.  The actual hardware being emulated inside Junosphere is courtesy of VJX, a virtual Junos instance that allows you to see the routing and security features of the product.  According to this very thorough Q&A from Chris Jones, VJX is not simply a hacked version of Junos running in a VM.  Instead, it is a fully supported release track code that simply runs on virtual hardware instead of something with blinking lights.  This opens up all sorts of interesting possibilities down the road, very similarly to Arista Networks vEOS virtualized router.  VJX evolved out of code that Juniper developers originally used to test the OS itself, so it has strong roots in the ability to emulate the Junos environment.  Riding on top of VJX is a web interface that allows you to drag-and-drop network topologies to create testing environments, as well as the ability to load preset configurations, such as those that you might get from Juniper to coincide with their training materials.  To reference this to something people might be more familiar with, VJX is like Dyanmips, and the Junosphere lab configuration program is more like GNS3.

Junosphere can be purchased from a Juniper partner or directly from Juniper just like you would with any other Juniper product.  The reservation system is currently set up in such a way as to allot 24-hour blocks of time for Junosphere use.  Note that those aren’t rack tokens or split into 8-hour sessions.  You get 24 continuous hours of access per SKU purchase.  Right now, the target audience for Junosphere seems to be the university/academic environment.  However, I expect that Juniper will start looking at other markets once they’ve moved out of the early launch phase of their product.  I’m very much aware that this is all very early in the life cycle of Junosphere and emulated enviroments, so I’m making sure to temper my feelings with a bit of reservation.

As it exists right now, Junosphere would be a great option for the student wanting to learn Junos for the first time in a university or trade school type of setting.  By having continuous access to the router environments, these schools can add the cost of Junosphere rentals onto the student’s tuition costs and allow them 24-hour access to the router pods for flexible study times.  For self-study oriented people like me, this first iteration is less compelling.  I tend to study at odd hours of the night and whenever I have a free moment, so 24-hour access isn’t nearly as important to me as having blocks of 4 or 8 hours might be.  I understand the reasons behind Juniper’s decision to offer the time the way they have.  By offering 24-hour blocks, they can work out the kinks of VJX being offered to end users that might not be familiar with the quirks of emulated environments, unlike the developers that were the previous user base for the product.

Tom’s Take

I know that I probably need to learn Junos at some point in the near future.  It makes all the sense in the world to try and pick it up in case I find myself staring at an SRX in the future.  With emulated OS environments quickly becoming the norm, I think that Junosphere has a great start on providing a very important service.  As I said on Packet Pushers, to make it more valuable to me, it’s going to need to be something I can use on my local machine, ala GNS3 or IOU.  That way, I can fire it up as needed to test things or to make sure I remember the commands to configure IS-IS.  Giving me the power to use it without the necessity of being connected to the Internet or needing to reserve timeslots on a virtual rack is the entire reason behind emulating the software in the first place.  I know that Junosphere is still in its infancy when it comes to features and target audiences.  I’m holding my final judgement of the product until we get to the “run” phase of the traditional “crawl, run, walk” mentality of service introduction.  It helps to think about Junosphere as a 1.0 product.  Once we get the version numbers up a little higher, I hope that Juniper will have delivered a product that will enable me to learn more about their offerings.

For more information on Junosphere, check out the Junosphere information page at http://www.juniper.net/us/en/products-services/software/junos-platform/junosphere/.