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?

Storage Networking and FCoE in the Network

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.

Virtual Chassis Technology

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 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.

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.