I traveled to Juniper‘s offices in San Jose, CA on Friday afternoon October 12, 2012 for Networking Field Day 4. We met with Derick Winkworth and a number of Juniper product managers and specialists.
I actually have some experience with Juniper and JunOS. I currently employ a clustered pair of Juniper Secure Access 4000 appliances for clientless and SSL-VPN based remote access. I’m also in the process of migrating to the Juniper SRX for our branch office VPN connections utilizing Juniper SRX 650s in the main office and Juniper SRX 210Hs in the branch office. I’m a big fan of the Juniper Secure Access product and the Network Connect client. Our recent deployment of the Juniper SRX product is been going quite well. We’re deploying virtual routing instances (VRFs) within JunOS so we can tunnel all Internet traffic from the branch back to the main office for content filtering and logging.
I’m going to outline the different presentations that we heard and perhaps make a few points here and there if I have anything useful to say. I’ll include a short blurb from Juniper in italics to help define/describe each product or solution. Thankfully since the sessions were recorded you can watch for yourself and make your own informed opinion.
Here’s my disclaimer; I’m not endorsing any of the solutions presented below. I’m merely passing on the information along with a few comments of my own. If you have any personal opinions about the solutions below why not share them with us in the comments?
Introduction
by Derick Winkworth (Networking Field Day 3 Delegate)
Tech Field Day Video
I only learned on my flight back to Philadelphia, PA that Derick was a Networking Field Day 3 delegate although once I did that explained a few things.
Storage Networking and FCoE in the Network
by Simon Gordon and Joe White
Tech Field Day Video
Juniper attempted to demonstrate the Juniper QFX3500 switch with a Windows and Linux server using the converged Intel X520-SR2 network adapter connected to a prototype storage array nicknamed ‘platypus’. Unfortunately ‘platypus’ wasn’t behaving that day and Juniper was unable to present the demo.
Edit: Updated 11/1/2012 – as pointed out by Simon it was the prototype storage array that mis-behaved and not the QFX3500.
My Thoughts?
I’m not expert, not even a novice when it comes to understanding the subject of FCoE. I believe there’s definitely value to be found in a converged FC SAN and NIC adapter. What do you do with your SAN traffic once it gets to the FCoE switch seems to be the question.
I have a question? What exactly is a latency bubble? It sounds like bullshit bingo to me but you never know it might be real.
Douglas Fourlay over at Network World is wondering Why FCoE is Dead, But Not Buried Yet. The article is dated but makes some interesting points.
Virtual Chassis Technology
by Yafan An
Tech Field Day Video
Juniper Networks Virtual Chassis technology is a feature of the Juniper Networks EX4200 line of Ethernet switches allowing the interconnection and operation of switches as a unified, single, high bandwidth device. Up to 10 EX4200 switches may be interconnected via dedicated Virtual Chassis ports on each device, or through optional uplink module ports that are configured as Virtual Chassis ports, with a combined backplane bandwidth of up to 128 Gbps.
Virtual Chassis Technology – stacking in closet or top of rack with 4 different models, EX3300 – 1Gbps Fixed Switch (stack up to 6), EX4200 – 1Gbps Fixed Switch (up to 10), EX4500 – 10Gbps Switch (up to ?), EX8200 – Modular Chassis Core Switch. EX8200s can be supplemented by external XRE (eXternal Routing Engines) all managed as a single switch, single IP address utilizing JunOS. The EX8200 can be stacked up to 40kM apart in a virtual chassis.
My Thoughts?
Initially it appeared to be just another stacking solution for closet/edge switches. Although then I realized that you can actually stack the modular EX8200 chassis which sounds similar to some other vendor solutions.
MyKonos – Web Application Security
Mykonos Software’s web Intrusion Deception™ system effectively eliminates false positives because it employs tar traps to detectttacks with certainty. The software inserts detection points into web application code including urls, forms and server files to create a variable minefield. These traps detect hackers when they manipulate the deception points during the reconnaissance phase of the attack, before they can establish an attack vector. And because hackers are manipulating code that has nothing to do with the website or web application, the malicious action is certain.
My Thoughts?
If you were watching the live stream you probably saw me prop up in my chair. This was a devilishly clever approach to the problem of application hacking and how to thwart the majority of such attempts. I’ve run a number of honeypots over the years but this was really a better mouse trap than anything I’ve ever seen. The MyKonos solution essentially acts as a reverse proxy server that front ends your Internet facing application web servers and injects small pieces of cheese into the HTML to see if anyone will bite. Once someone/something reacts to the pieces of cheese the solution will start tracking the user/host and will attempt to continue deceiving the ‘hacker’ by offering them additional tidbits of information to keep them interested. The ultimate goal of the solution is to keep the rogue users interested by wasting their time (and money) while building a profile of the attacker. Ultimately MyKonos can integrate with third party firewalls to block the IP address of an intruder once they’ve reached the end of the rainbow.
The delegates discussed for a few minutes the legality of placing cookies in a user’s web browser but it seems that Juniper has already addressed the majority of those concerns in a knowledge base article KB25858.
JunOS Automation
by Dan Beckman and Dereck Winkworth
Tech Field Day Video
JunOS 12.2 added the ability to add Curl calls from scripting which enables you to centralize your code snippets.
Junos Automation Technology Overview Presentation
Juniper Script Library
SLAX – SLAX is a syntax overlay of the XSLT programming language. While XSLT is used internally by Junos to power its on-box scripting capabilities, it is not the most intuitive or efficient of languages, so SLAX was created to simplify on-box script programming and make it more comfortable to write. SLAX Reference
JUISE – JUISE takes the abilities provided by the scripting facility of JUNOS and moves it into the open source world, where a script can run on a remote box, accessing JUNOS resources over the NETCONF (or JUNOScript) API. Initially this will be an excellent environment for creating and debugging scripts, but for many users, it may become their “normal” scripting environment.
My Thoughts?
I was able to relate with Dereck as he used phrases like “mountain of automation workflow”, “stop the hurt” and “IT is hard”. I’m a believer in letting the computer do the work and where ever possible and reducing the duplication of effort (eliminate the paperwork). You only need to look at my scripts library and see that I’ve written my share of code using Expect and Perl to automate various tasks and push functionality out to the help desk and support personnel. I just recently coded a Perl application to interface with Infoblox to support personnel could quickly and easily update the DHCP MAC address list which is used to filter DHCP requests (poor mans NAC). The goal was to allow help desk and field engineers to make updates to Infoblox without requiring them to log into the Infoblox appliance. I had to code all sorts of data validation routines within JavaScript to make it as bullet proof as possible. I took the same Perl application and allowed Symantec’s Altiris to make CGI calls to it while provisioning desktops and laptops thereby completely automating the process of on-boarding new desktops and laptops into the network.
Now that I have 2 Juniper SRX 650s and 31 Juniper SRX 210H to manage I’ll be definitely be looking into what I can do to help automate the management of these devices and JUISE will probably be the first component I look at in my quest to make “IT easier”.
Closing
Let me say thanks to Derrick and the entire Juniper team. The presentations were very informative and educational.
Cheers!
Michael,
firstly a couple of fun points:
1) it was to be precist the famous juniper prototype storage array nickname platypus that a) crashed and b) was not released code. the QFX3500 was production hw running production software and did not crash at all – though i know it was noisy !!!
2) my distinguished engineer, friend, and former partical physisist may think it funny that you refer to the term ‘latency bubble’ as bullshit lingo because it was him and not me the product manager (talking sales and marketing) that used the term…
ok, latency bubble… we used the term because the term ‘microburst’ does not well describe the real issue in hand and anyway is often miss discribed both in terms of what it is and what the effect is… putting my marketing hat on and remembering i am british… if you have a water system (water radiators in your car or your house) bubbles trapped in the system and moving around can cause all sorts of nasty things to happen including your car overheating and breaking down.
now, back to technical, if i have a single switch with a single wire speed asic and run all my ports at the same speed and have a pair of devices talking to each other then i will have very consistent latency especially if the destination device can also soack traffic at wire speed (this only matters for lossless). this is because traffic will drain out at wire speed and so you can NEVER get queue build up and so never get a ‘bubble of high latency’ or micro burst (or nano burst or mili burst depending on duration of traffic surge).
however, even in a completely wire speed non blocking any to any switch if you introduce any form of speed missmatch then you can get spikes of queue build up when the faster input(s) exceed the slower output. this is missleadingly referred to as a microbirst problem and its really an incast problem or speed missmatch problem that occurs when you have a brief period of time (hence micro birst) when input traffic vollume exceeds output traffic capabilitiy.
your speed missmatch could be a 10g input going to a 1g output, or it could be multiple 10g inputs feeding to a single 10g output (aka incast). in the later case you can see that you ONLY have a problem if you get a coordinated birst of traffic on multiple inputs at the same time.
this causes a bubble of increased latency as you get a egress q build up, on best effort if you exceed q depth you will then get egress drop. on lossless you will then get back propogation of congestion from egress to ingress and then to the next device.
now, going back to my water system analysis, this CAN be a problem when you have a single switch, however its even more likely to be a problem in a cascaded network of switches, as the microbursts will propogate. firstly most networks have oversubscription and so naturally generate incast from access to aggregation and aggregation to access, and then the first switch we have a little spike, this cases a birst of traffic on the link to the next switch, somewhere else on the network there was another similar burst, multiple of the bursts cross the aggregation switch, these bursts (or bubbles) meet and become bigger bursts, etc etc.
in other words the more complex the network the more likely you are to see these problem, and rumors to the contrary building switches or networks with no oversubscription DOES NOT prevent the problem with the nature of the traffic patterns we see increasingly.
anyway, having joe my techy sidekick using the term latency bubble i as product manager actually think i will use the term more along with the analogy of as i say bubbles in my water cooling system…
hope that helps :-)
Hi Simon,
Thanks for taking the time to post a reply.
I was confused myself about the QFX3500 since I had gleaned from industry rags that it had been shipping for sometime. I will admit that it was really loud and difficult to catch a lot of what was being said while it was running – not sure if it was the switch or servers that was making all the noise. It was only when I went back to the actual video footage that I heard a lot of what was being said. Thanks for clarifying the point – I’ll issue a correction in the article above.
Any additional information available online regarding the prototype storage array named Platypus? Is it just a development platform for internal testing or is it an actual product offering that Juniper is developing?
Thanks for the explanation around the term ‘latency bubble’. I understood the meaning behind it but had never heard the term myself until that day. If you don’t mind I’ll probably feature your definition in an upcoming blog post – What’s a latency bubble?
Cheers!
no problem, sorry about the noise (i thought i had a loud voice…) but we thought the fun of seeing end to end fcoe with only juniper outweighed the downside of noise for a short while… demos animals and children should never be on stage !!! or maybe i should have done a remote demo not in the room.
platypus is our little joke in a few different ways… juniper is not entering the storage business however there are no storage arrays supporting end to end fcoe using VN2VN (layer 2) and so the only way for us to demo is for us to make a mock storage device. by the way not just the switch (and its version of junos with vn2vn fip snooping) but also the server (and its vn2vn driver) are full production code. we are hoping to see real vn2vn storage and know some customers who are asking their storage vendors for it.
that day was the first time (i remember) also hearing the term latency bubble :-) and we would be very happy for you to blog about it – as i note there is much missunderstanding on the area of incast, microburst, congestion, and its increasing importance in the modern datacenter.