Category Archives: Juniper

AI and Trivia

Posted on by
1
questions answers signage

Photo by Pixabay on Pexels.com

I didn’t get a chance to attend Networking Field Day Exclusive at Juniper NXTWORK 2019 this year but I did get to catch some of the great live videos that were recorded and posted here. Mist, now a Juniper Company, did a great job of talking about how they’re going to be extending their AI-driven networking into the realm of wired networking. They’ve been using their AI virtual assistant, named “Marvis”, for quite a while now to solve basic wireless issues for admins and engineers. With the technology moving toward the copper side of the house, I wanted to talk a bit about why this is important for the sanity of people everywhere.

Finding the Answer

Network and wireless engineers are walking storehouses of useless trivia knowledge. I know this because I am one. I remember the hello and dead timers for OSPF on NBMA networks. I remember how long it takes BGP to converge or what the default spanning tree bridge priority is for a switch. Where some of my friends can remember the batting average for all first basemen in the league in 1971, I can instead tell you all about LSA types and the magical EIGRP equation.

Why do we memorize this stuff? We live in a world with instant search at our fingertips. We can find anything we might need thanks to the omnipotent Google Search Box. As long as we can avoid sponsored results and ads we can find the answer to our question relatively quickly. So why do we require people to memorize esoteric trivia? Is it so we can win free drinks at the bar after we’re done troubleshooting?

The problem isn’t that we have to know the answer. It’s that we need to know the answer in order to ask the right question. More often than now we find ourselves stuck in the initial phase of figuring out the problem. The results are almost always the same – things aren’t working. Finding the cause isn’t always easy though. We have to find some nugget of information to latch onto in order to start the process.

One of my old favorites was trying to figure out why a network I was working with had a segmented spanning tree. One side of the network was working just fine but there were three switches daisy chained together that didn’t. Investigations turned up very little. Google searches were failing me. It wasn’t until I keyed in on a couple of differences that I found out that I had improperly used a BPDU filtering command because of a scoping issue. Sure, it only took me two hours of searching to find it after I discovered the problem. But if I hadn’t memorized the BDPU filtering and guard commands and their behavior I wouldn’t have even known to ask about them. So it’s super important to know how every minutia of every protocol works, right?

Presenting the Right Questions

Not exactly. We, as human computers, memorize the answers to more efficiently search through our database to find the right answers. If the problem takes 5 minutes to present we can eliminate a bunch of causes. If it’s happening in layer 3 and not layer 2 we can toss out a bunch of other stuff. Our knowledge is allowing us to discard useless possibilities and focus on the right result.

And it’s horribly inefficient. I can attest to that given my various attempts to learn OSPF hello and dead timers through osmosis of falling asleep in my big CCNP Routing book. The answers don’t crawl off the page and into your brain no matter how loudly you snore into it. So I spent hours learning something that I might use two or three times in my career. There has to be a better way.

Not coincidentally, that’s where the AI-driven systems from Mist, and now Juniper, come into play. Marvis is wonderful at looking at symptoms and finding potential causes. It’s what we do as humans. Except Marvis has no inherent biases. It also doesn’t misremember the values for a given protocol or get confused about whether or not OSPF point-to-point networks are broadcast or not. Marvis just knows what it was programmed with. But it does learn.

Learning is the key to how these AI and machine learning (ML) driven systems have to operate. People tend to discount solutions because they think there’s no way it could be that solution this time. For example, a haiku:

It’s not DNS.
Could it be DNS?
It was DNS.

DNS is often the cause of our problems even if we usually discount it out of hand in the first five minutes of troubleshooting. Even if it was only DNS 50% of the time we would still toss DNS as the root cause within the first five minutes because we’ve “trained” our brains to know what a DNS problem looks like without realizing how many things DNS can really affect.

But AI and ML don’t make these false correlations. Instead, they learn every time what the cause was. They can look at the network and see the failure state, present options based on the symptoms, and even if you don’t check in your changes they can analyze the network and figure out what change caused everything to start working again. Now, the next time the problem crops up, a system like Marvis can present you with a list of potential solutions with confidence levels. If DNS is at the top of the list, you might want to look into DNS first.

AI is going to make us all better troubleshooters because it’s going to make us all less reliant on poor memory. Instead of misremembering how a protocol should be configure, AI and ML will tell us how it should look. If something is causing routing loops or if layer 2 issues are happening because of duplex mismatches we’ll be able to see that quickly and have confidence it’s the right answer instead of just guessing and throwing things at the wall until they stick. Just like Google has supplanted the Cliff Claven people at the bar that are storehouses of useless knowledge, so too will AI and ML reduce our dependence on know-it-alls that may not have all the answers.

Tom’s Take

I’m ready to be forgetful. I’m tired of playing “stump the chump” in troubleshooting with the network playing the part of the stumper and me playing the chump. I’ve memorized more useless knowledge than I ever care to recall in my life. But I don’t want to have to do the work any longer. Instead, I want to apply my gifts to training algorithms with more processing power than me to do all the heavy lifting. I’m more than happy to look at DNS and EIGRP timers than try to remember if MTU and reliability are part of the K-values for this network.

Does Juniper Need To Be Purchased?

Posted on by
2

You probably saw the news this week that Nokia was looking to purchase Juniper Networks. You also saw pretty quickly that the news was denied, emphatically. It was a curious few hours when the network world was buzzing about the potential to see Juniper snapped up into a somewhat larger organization. There was also talk of product overlap and other kinds of less exciting but very necessary discussions during mergers like this. Which leads me to a great thought exercise: Does Juniper Need To Be Purchased?

Sins of The Father

More than any other networking company I know of, Juniper has paid the price for trying to break out of their mold. When you think Juniper, most networking professionals will tell you about their core routing capabilities. They’ll tell you how Juniper has a great line of carrier and enterprise switches. And, if by some chance, you find yourself talking to a security person, you’ll probably hear a lot about the SRX Firewall line. Forward thinking people may even tell you about their automation ideas and their charge into the world of software defined things.

Would you hear about their groundbreaking work with Puppet from 2013? How about their wireless portfolio from 2012? Would anyone even say anything about Junosphere and their modeling environments from years past? Odds are good you wouldn’t. The Puppet work is probably bundled in somewhere, but the person driving it in that video is on to greener pastures at this point. The wireless story is no longer a story, but a footnote. And the list could go on longer than that.

When Cisco makes a misstep, we see it buried, written off, and eventually become the butt of really inside jokes between groups of engineers that worked with the product during the short life it had on this planet. Sometimes it’s a hardware mistake. Other times it’s software architecture missteps. But in almost every case, those problems are anecdotes you tell as you watch the 800lb gorilla of networking squash their competitors.

With Juniper, it feels different. Every failed opportunity is just short of disaster. Every misstep feels like it lands on a land mine. Every advance not expanded upon is the “one that got away”. Yet we see it time and time again. If a company like Cisco pushed the envelope the way we see Juniper pushing it we would laud them with praise and tell the world that they are on the verge of greatness all over again.

Crimes Of The Family

Why then does Juniper look like a juicy acquisition target? Why are they slow being supplanted by Arista as the favored challenger of the Cisco Empire? How is it that we find Juniper under the crosshairs of everyone, fighting to say alive?

As it turns out, wars are expensive. And when you’re gearing to fight Cisco you need all the capital you can. That forces you to make alliances that may not be the best for you in the long run. And in the case of Juniper, it brought in some of the people that thought they could get in on the ground floor of a company that was ready to take on the 800lb gorilla and win.

Sadly, those “friends” tend to be the kind that desert you when you need them the most. When Juniper was fighting tooth and nail to build their offerings up to compete against Cisco, the investors were looking for easy gains and ways to make money. And when those investors realize that toppling empires takes more than two quarters, they got antsy. Some bailed. Those needed to go. But the ones that stayed cause more harm than good.

I’ve written before about Juniper’s issues with Elliott Capital Management, but it bears repeating here. Elliott is an activist investor in the same vein as Carl Ichan. They take a substantial position in a company and then immediately start demanding changes to raise the stock price. If they don’t get their way, they release paper after paper decrying the situation to the market until the stock price is depressed enough to get the company to listen to Elliott. Once Elliott’s demands are met, the company exits their position. They get a small profit and move on to do it all over again, leaving behind a shell of a company wonder what happened.

Elliott has done this to Juniper in droves. Pulse VPN. Trapeze. They’ve demanded executive changes and forced Juniper to abandon good projects that have long term payoffs because they won’t bounce the stock price higher this quarter. And worse yet, if you look back over the last five years you can find story in the finance industry about Juniper being up for sale or being a potential acquisition target. Five. Years. When’s the last time you heard about Cisco being a potential target for buyout? Hell, even Arista doesn’t get shopped as much as Juniper.

Tom’s Take

I think these symptoms are all the same root issue. Juniper is a great technology company that does some exciting and innovative things. But, much like a beautiful potted plant in my house, they are reaching the maximum amount of size they can grow to without making a move. Like a plant, you can only grow as big as their container. If you leave them in a small one, they’ll only ever be small. You can transfer them to something larger but you risk harm or death. But you’ll never grow if you don’t change. Juniper has the minds and the capability to grow. And maybe with the eyes of the Wall Street buzzards looking elsewhere for a while, they can build a practice that gives them the capability to challenge in the areas they are good at, not just being the answer for everything Cisco is doing.

Vendor Whitebox Switches – Better Together?

Posted on by
1

ChocoPeanut

Whitebox switching has moved past the realm of original device manufacturers and has been taken up by traditional networking vendors. Andre Kindness (@AndreKindness) of Forrester recently posted that he fields several calls from his customers every day asking about a particular vendor’s approach to whitebox switching. But what do these vendor offerings look like? And can we predict how a given vendor will address the whitebox market?

Chocolate In My Peanut Butter

Dell was one of the first traditional networking vendors to announce a whitebox switch offering that decoupled the operating system from the switching hardware. Dell offered packages from Cumulus Linux and Big Switch Networks alongside their PowerConnect lineup. This makes sense when you consider that the operating system on the switch has never been the strong suit of Dell. The PowerConnect OS is not very popular with network engineers, being very dissimilar from more popular CLIs such as Cisco IOS and its look-alikes.  Their attempts to capitalize on the popularity of Force Ten OS (FTOS) and adapt it or use on PowerConnect switches has been difficult at best, due to the divide been hardware architecture of the two platforms.

What Dell is very good at is offering hardware at a greatly reduced cost. By utilizing this strength, they can enter the whitebox market successfully by partnering with OS vendors to provide customer options. This also gives them time to adapt FTOS to more switches and attempt to drive acquisition posts down once the port of FTOS to PowerConnect is complete.

Peanut Butter In My Chocolate

What happens when a vendor sees software as their strength? You get an announcement like the one last week from Juniper Networks. Juniper has put a significant amount of time and effort into Junos. The FreeBSD base of the system gives it the adaptability that Cumulus enjoys. Since Juniper sees Junos as a huge advantage, their oath to whitebox switching was to offer hardware that reduces the acquisition cost. Porting Junos to run on the OCP-based OCX1100 allows Juniper to use silicon that is more in line with merchant offering price points. The value to the customer comes from existing experience with Junos allowing for reduced learning time on the new platform.

So how will the rest of the market adopt whitebox switching offerings? HP will likely go the same route as Dell, as their software picture is murky with products split evenly between HP Procurve OS and 3Com/H3C Comware. HP has existing silicon manufacturing facilities that allow for economy of scale to reduce acquisition costs to the customer. Conversely, Brocade will likely leverage existing Vyatta development and investment in projects like OpenDaylight to standardize their whitebox offerings on software while offering OCP-style hardware platforms.

The 800-pound Whitebox Gorilla

And what of Cisco? Cisco had invested significant time and effort into both hardware and software. IOS is being renovated with API access and being ported into containers to broaden the platforms on which it can operate. The Cisco investment in custom silicon development is significant as well, with only the Nexus 3000 and 9000 series using merchant offerings from Broadcom. Their eventual whitebox offering could take any form.

Cisco feels very strongly about keeping IOS and its variants exclusive to Cisco hardware. Given that they sued Arista Networks late last week for patent infringement in EOS, it should be apparent how strongly they feel about IOS. That will be the impetus that pushes them to offering some limited custom silicon that is capable of running third-party operating systems. This allows Cisco to partner closely with one of those developers to ensure peak performance and tight integrations with whatever hardware Cisco includes.  They would likely offer this platform with a bundle of SmartNET support services, recouping the costs of producing the switch with some very high margin services.

The possibility of porting IOS to an OCP-like reference platform is remote at best. A whitebox IOS offering would still carry a high price tag to reflect Cisco R&D and would be priced too high above what customers would be willing to pay for total acquisition cost.  It would also open the door for someone to “port” that version of IOS to run on platforms that it shouldn’t be running on.  At the very least, it will expose Cisco in the market as having too high a price tag on their intellectual property in IOS and give competitors like Juniper and Big Switch ammunition to fight back.

Tom’s Take

When evaluating vendor whitebox offerings, be sure your assessment of the strengths matches theirs. Wide adoption of a given strategy will solidify that approach in the future. Be sure to give feedback to your local account teams and tell them the critical features you need to be supported. That will ensure the vendor has you in mind when the time comes to produce a whitebox offering.  And remember that you always have the option of going your own way.  Nothing says that you have to buy a solution with bundled services from traditional networking vendors.  If you’re willing to fly without a safety net for a while, you can find some great deals on ODM switches and OSes to run on them.

Building A Lego Data Center Juniper Style

Posted on by
2

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

Posted on by
1

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

Posted on by
7

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

Posted on by
5

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 ❤ 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 ❤ @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

Posted on by
Reply

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

Posted on by
6

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

Posted on by
1

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.