One of my recent forays into Increasing the Awesome has involved learning about NETCONF and the Python programming language. I was lucky enough to spend some time with Jeremy Schulman during my trip to Sunnyvale for the Juniper Ambassadors Summit, and he introduced me to the new py-junos-eznc Python library he has been working on. I had spent a little bit of time earlier in the year looking at the original Ruby library, and I was amazed at how much thought had been put into this new library – obviously Jeremy’s learned a lot on the way!

 An Impatient Start

Let me make a couple of things clear right from the outset:

1. I am not a programmer! Yes I have written the odd script here and there in the deep dark past, but I am by no means a programmer. All of my scripts have been about automating some task I had to do. As long as it worked, I didn’t care how efficient or pretty it was – it did what I needed.
2. I have no intention of becoming a full time programmer! I like being a network architect and I like building and playing with network toys. All I want is the ability to make my job easier, which leads me to my last point…
3. I am lazy! I don’t like repetitive work. I would rather do something once or twice and move on. Computers are here to do the mundane stuff for us, so we can create more awesome. I would rather write scripts for other people to do it next time instead of bugging me about it.

So with the above three stipulations in hand, I started to learn Python. Now, when I say “started”, I literally mean a week ago. I already knew the basics of loops and conditionals etc, but I couldn’t read a lick of Python this time last week. I tried the various online tutorials such as over at Code Academy and Learn Python the Hardway, but I knew the only way I was going to get my head around Python was to jump in and just start coding the working I had on my plate.

A Looming Project

I have a project starting in the next couple of weeks that is going to entail configuring about 50 switches with mostly the same configuration, followed by customising port layouts etc. Now just time involved in unboxing all those switches, cabling them up in the lab, firmware upgrading them, prepping the config and doing burn in tests can take a couple of days.

I knew this would be a prime candidate for “automation”. I had better got off my butt and work out how to do this!

So I contacted Jeremy and we hopped onto a Google Hangout where he was able to unleash 2.5 months of “Python knowledge” on me. It was 11pm for me and 5am for him, and it was so much fun 🙂 Over the course of our conversation we discussed a couple of the core concepts and data structures structures in the Junos-EZ libraries, and Jeremy discussed an idea he had to make extending the existing code base even easier. When I woke up the next morning, he had already committed it to the Github repository.

The Basic Structures

There is a whole heck of a lot in the Junos-EZ libraries, but by only understanding the very basics of the following components, I was able to create some pretty awesome scripts – with only 6 days of Python experience and about 24 hours with the Junos-EZ libraries 🙂

Device

The Device object represents a particular network device. When you call the .open() method, the script establishes an NETCONF over SSH connection to the device. From here you can make any of the NETCONF RPC calls you want against the device.

Tables

Now one of the great things about this library is that Jeremy has gone to great lengths to ensure that the average user of these libraries don’t need to understand the deep internals of the code to be able to add functionality. Tables are a prime example of this.

A table essentially represents all the data collected for a certain RPC request, sorted and keyed on a particular set of values and presented to the user as a collection of native Python data structures. The end user only needs to describe the data sets in YAML format without knowing the Python objects below.

The Table I use in this example is called PhyPortTable, shown here:

[snippet id=”38″]

Views

A view is applied to a table to create a custom combination of the data in the table. As such, a combination of table and view definitions can be created with just a handful of lines of code yet scale infinitely.

The above PhyPortTable example calls the PhyPortView filter as shown here:

[snippet id=”39″]

The Opportunistic Script

So there I was onsite working with a customer yesterday afternoon, and I was asked –

“Can you please get me a list of all of the ports on the following switches, and tell me the current operating status and when they last flapped?”.

This request required looking at 5 switches and about 300 ports. Now what was I to do? Within the last 24hrs I had learned enough to know I could probably whip up a piece of code that would generate the required output. And it turned out to be relatively simple.

The code I wrote is shown here:

[snippet id=”36″]

This is by no means the prettiest code on the planet, but remember our goal was to just remove the mundane so we could increase the awesome, not become a programmer.

• Lines 1 and 2 tell Python to load the relevant libraries.
• Lines 4 and 5 make the NETCONF connection to my lab switch.
• Line 7 is where “the magic” lies. This line requests that the collection of data be returned as defined by the “PhyPortTable” and assign it to a variable called ports.
• Line 9 prints a simple CSV style header to the console
• Lines 12 – 14 loop through the collected data set and print the values for “oper” and “flapped” (names as defined in the view) in CSV format.

The output of this script is shown here:

[snippet id=”37″]

I was able to run this script across each of the switches I needed to query and provide an “Excel Version” for the customer who asked for the information.

Mop and Bucket

This post only covers an extremely simple example, but most of what we really want to stop doing manually every day is not much more complicated that the above example.

I am going write a follow up post in the next couple of days to discuss how within 24hrs of starting with the Junos-EZ library I was able to bring LLDP discovery functionality to the library with no real skill other than the ability to cut, paste and pray my way through it.

Anybody can work on this stuff, so get out there and start coding!

Finally… it was bound to happen. My three year journey is complete.

It was about this time last year that I posted about my second JNCIE-ENT lab attempt, and sadly it didn’t go the way I wanted it to!  Due to work commitments I was not going to be prepared to sit the 2012 Q3 round of lab offerings, so I resolved to sit the December / January round.

I picked up my studies again and worked on my weak areas noted during my first two attempts. I paid particular attention to areas of multicast and switch security as these two topics were areas of weakness for me last time. I was lucky enough to work on a project at the end of last year that included nearly 1000 ports of 802.1x with dynamic VLAN allocation, so that proved to be an excellent “lab environment” for me.

After a need to reschedule for March, as the January exams were cancelled in Sydney, I knew I was going to do everything in my control to pass this time around. I didn’t want to face the thought of making attempt #4!

Long story short this time around I felt much more prepared and actually finished with more than enough time to go back through all of the questions to confirm the points I believed I had earned. I cannot say enough about good time management efforts during the lab. Set a maximum amount of time per question (or per point) and really make yourself stick to it. Unless you know you need this question to continue on to later questions, just leave it as it is (preferably in a non-broken state), and move on to other questions. Earn more points and come back later.

I finished up the exam reasonably confident, but I also knew I felt confident after attempt #2. I caught a train home and prepared myself for the 15 business day turn around for the exam results. Luckily I didn’t have to way this long to get my results, and after a couple of days I was advised that I had passed!

I am now JNCIE-ENT #368… and Im very happy / relieved 😉

In previous posts Ive covered tips and tricks etc, so I would really like to dedicate this post to saying thanks to people.

All my thanks

• First I would like to thank Liz Burns and everyone at the JNCP team. Thanks for all the work you guys have put in to making these exams and the encouragement you provided me over the past three years has been must appreciated.
• All of my current and former co-workers. Thanks for the opportunities I was given to work on real life network environments and exposure to quirky designs. Also there is no end of thanks for putting up with me on all those days I had my cranky pants on
• All of my current and former customers. Without your need for new networks, and not to mention some of the crazy requests you have thrown at me over the years, I wouldn’t be able to get my head around some of the tricks of the lab.
• Thanks to my friends at Juniper, most notably Francois Prowse, Ashton Bothman and Doug Hanks. Again thanks for the encouragement and the kick in the butt I needed not to give up. Many people from within Juniper were invaluable in answering many of the problems I ran into while studying.
• To everyone on #juniper over on Freenode. Much appreciation for your advice… “hrmpf“
• To Chris Jones and the guys at Proteus Networks. I was lucky enough to be performing “Technical Editing” duties on the new Proteus JNCIE-ENT Preparation Workbook (which was obviously pre-release at the time). As part of this I labbed almost every scenario from the workbooks to ensure they were correct and the descriptions matched. I cannot recommend this guide enough to people studying for the JNCIE-ENT, and I plan to do a separate review in the near future.
• To Burkey and to Nick. I hope you guys both know what your support meant. #FHP
• To “The Wolfpack”. ARRRROOOOOOOOOOOOO! You know who you are, thank you for allowing me to “de-stress” and express myself in some pretty non-conventional ways 🙂
• Last but not least, to my wife Belinda. Thanks for all the love (and feeding) during this journey. You suffered more of the cranky pants than anyone else, and yet you still encouraged me to keep going. Love you heaps 🙂

As many of you know, I had the honour and good fortune of being able to take part in beta testing the JNCIE-ENT lab in August of 2011. The day completely wiped me out and I was walking around in a daze for the remainder of that week. While I knew the technologies I was unprepared for the time-management skills required to pass this lab. Needless to say it was no surprise when I received my fail-mail advising me that I was unsuccessful.

Well after almost a year, I decided it was time to get back on the horse and try again for getting those digits. Here in Australia the Juniper lab exams are only offered every 3 months, and I felt I was unprepared to sit the exam when it was offered in January. I knew that a friend of mine, and now colleague, Cooper Lees was preparing to take his JNCIE-SEC exam during the May schedule so I decided to book my attempt for the same day.

I have spent a lot more time working with Junos and various Juniper hardware devices in the time since I took the beta exam in August, and I was now a lot faster on the CLI, and didn’t need to refer to any documentation during the exam (except verify some config when I thought I had completed each step correctly! Needless to say… I hadn’t).

I had the good fortune at both my previous job at eintellego and also my current position at ICT Networks to have a wide variety of Juniper equipment at my disposal to create a lab environment in which to hone my skills required to get through the exam. I made quite extensive use of these labs to prepare and its true that nothing beats hands on experience when it comes to the lab. The JNCIE-ENT exam is based on EX4200 switches and SRX240’s – so be prepared to configure and support anything on these devices (sometimes items on “the edge of the blueprint”!).

So the lead up to the lab date was “exciting” with Cooper and I giving each other some “friendly rivalry” to try and be ready for the exams we had in front of us. We swapped experiences and ideas back and forth. Even though we were sitting different exams, having somebody else work with you on problems during prep time was certainly a god send. I had this during my prep for the beta with Nick Ryce and Chris Jones, both of whom have now gained their JNCIE-ENT certification.

On lab day Cooper and I met around 8am for breakfast near our office (which is only a few blocks from Juniper’s Sydney Office). A hearty breakfast of Bacon, Eggs, Grilled Tomato and Coffee certainly helped calm my stomach. After some banter about how we just wanted to “get this thing started!”, we decided to head over to the lab location and wait. We got there a little early, but it gave us time to settle down. The foyer area outside the room that served as the lab location included a table tennis table, an xbox and a pinball machine. Cooper showed off his fine table tennis skills while the rest of us pretended like we weren’t stressed 😉

While talking to the other candidates, we worked out that there were 3 attempting JNCIE-SEC, 3 attempting JNCIE-SP, and just myself attempting JNCIE-ENT (The “easy one” apparently :P). All of the candidates had a wealth of experience behind them including front line engineers, instructors and consultants. This was great company to be a part of.

Well the next part of the day is all covered by NDA, but I can tell you that I was wiped out by the end of the day. I feel like I was much better prepared this time around, though I am not sure if I scored enough points to earn a pass. I have already gone over some of the “stumpers” from the exam and worked my way through various solutions.

Im reasonably sure I am going to have to give this lab another attempt, but there is not much I can do about that now. This is all in the hands of the Juniper Certifications Team now. There is a 21 day SLA on the turn around of lab results, so all I can do is wait and prepare to book my next attempt.

I would like to leave the following advice to anybody preparing to take the JNCIE lab in the future:

• Prepare for time management. There is a lot crammed into the exam
• Read the entire exam. There are a lot of steps throughout the paper that can be consolidated and completed at the same time. I suggest making a list of all questions that affect each device and trying devise a strategy on how to meet all requirements before diving in.
• Know all of your topics. The lab exam is laid out quite clearly by topic, and these topics align with the same major headings as the blueprint. You are required to successfully complete at least one task from each section to pass. This means that you cannot say “Oh, I am weak in CoS or Multicast” and think you can make up your points elsewhere. Not completing a task from each section is an instant fail. BE PREPARED AND KNOW YOUR STUFF!
• My workstation during the lab was a Windows notebook computer with an external keyboard and mouse. You are allowed to bring your own keyboard and mouse if you wish. Unfortunately this was not what was tripping me up. You see, I am a Mac user and I had to get used to the fact that Ctrl is used instead of the Command key – I spent a lot of time pressing ALT 🙁 This will probably not be a problem for most people, but I will invest more time in lambing on a windows computer so I get the hand of where the keys are 😛 This may change in the future, but this was what I experienced.
• The lab is accessed via a VPN + Remote Desktop and a console server. All of this was up and running before I sat down at the lab machine. There was a little bit of lag for keystrokes, but nothing outside of what I am used to working on customer equipment in remote locations. Due to the time constraints in the lab though, you will want to be well versed in the Junos CLI short cuts (including Ctrl+W, Esc+b, Esc+f, Ctrl+A and Ctrl+E at the very least). These should help you move around the CLI without waiting for your console to catch up.
• Unlike other vendors, then JNCIE lab does include external machines that operate to show if your configuration is working. Be sure you know how to diagnose correct operation of your protocols and features from the blueprint  because it will be of great benefit with these devices behaving correctly.
• And last of all Juniper have made the sensible decision that IPv4 and IPv6 are equal. (Except of course where EX Licenses are concerned!). Know how to configure most of the tasks on each protocol – because you never know where you might get tested! Remember, this is the future of networking whether you like it or not, so get your IPv6 on!

As mentioned, the rest is just a waiting game now, and I promise I will post an update regardless of pass or fail! Until then, Im back to labbing some of the scenarios I came up against that I thought “should have worked!”.

POST: Well this blog post was supposed to be published over a week ago, unfortunately I have received my “Fail Mail” in the last couple of days, so I will be preparing to take this lab once again in August 🙁 This isn’t the worst news Ive received over the past week, as one of my best friends died in an accident at the beginning of last week and the “Godparent Card” has been activated. This is why my post was delayed somewhat as I have been working through assisting his wife and 2 young boys (both under 3) to deal with everything that is happening.

A couple of weeks back, when we recorded Episode 33 of Packet Pushers Podcast, one of the items we had on the list of topics to discuss was that of multi-vendor networks and the recent Gartner report on the topic.

Due to various reasons this topic was taken off the list, but I still had a few thoughts on the topic so I decided to write this blog post to discuss some of them.

The Gartner Report

In late 2010 I attended a HP Australia executive briefing and breakfast in Sydney. The keynote speaker at this event was Mark Fabbi, and I had the honour (luck?) of sitting at the same table as him during the event. Mr Fabbi was the author of a paper called “Debunking the Myth of the Single Vendor Network”. The presentation was aimed at C-level executives along with the various Magic Quadrants that we Network Engineers love to laminate and stick to the walls of our cubicles!

Whilst telling us (well me at least) something we already knew, he laid out in a fashion suitable for presentation to upper management for discussion and approval to add addition vendors to your network.

Suggestions have been made that vendors with deeper pockets have been pushing the agenda for these reports, but I think that at the end of the day there are compelling reasons not to have vendor lock-in.

The right tool for the right job

At eintellego we specialise in building multi-vendor networks. I like to call this the “Chasing Amy School of Network Design”. Anyone who has seen that movie should know what I am referring to, but basically why should I limit my choice of devices to one particular vendor. If there is a better tool to complete the task I am trying to do then I will not put blinders on because it does not come from my vendor of choice.

By way of an example, for quite a few years we had been selling and supporting the Cisco PIX and ASA platforms for our customers because we felt they offered the best overall hardware firewall solution for our customers. Other vendors had products that were competitive but none of them were compelling enough for us to move away from the ASA. Then in mid-2009 in a space of maybe 3 weeks I had two separate customers ask me on my opinion of the Juniper SRX platform. I had previously looked at Juniper equipment and was quite impressed with the Junos Operating System, but when it came to firewalls I was not impressed with the ScreenOS options. I could have easily just dismissed the new product because it wasn’t from Vendor X who I was used to buying from, but after several recommendations from colleagues as well as requests from customers I decided to take a look. And I am very glad I did!

What I found was a product that met several of the short comings I had with the ASA platform (dynamic routing with redundancy etc), was based on the Junos Operating System, and had quite an impressive throughput and capabilities for the price. Today at eintellego we will recommend and sell SRX solutions to our customers before an ASA solution because we feel that in 2011 it is truly a better option.

Multi-Vendor for the sake of Multi-Vendor

One point I should make clear is that I do not advocate multi-vendor when it is not required. For a long time the Security Industry Best Practice promoted the idea of separate firewalls from separate vendors. While there are sensible reasons behind this approach (vulnerability in one platform will be safe on another), often during the implementation one of the two devices was treated worse than the other. Maybe installing the second box was to achieve a “tick in the box” for some industry security certification, or maybe a choice by a previous admin who no longer is there to champion the cause for the device, but sometimes one of these boxes was modified and updated far less than the other.

Why should we make our lives complicated for ourselves? Why would I force myself to use, say, an ASR and an MX series router as my border routers purely to meet the requirement of multivendor. Valid reasons may exist for this solution, buy “multi-vendor” is not that reason.

I need to learn another System?

I often hear from engineers that they do not want to learn another operating system. I usually laugh at this point at tell them their future doesn’t look that bright. Even within a single vendor you have several new operating systems now, an depending on the direction your network takes you, you may find yourself working with IOS, NX-OS, IOS-XR and/or possibly IOS-XE.

When I train my staff in networking concepts, I try to re-enforce the theory behind the solution or protocol more than the commands required to complete the solution. If you understand why Spanning Tree or OSPF behave a certain way or respond to an event in the network, it does not matter what operating system you are on, all you need to do is work out where to find those options. Knowing the right commands is only 10% of the job!

As an example, we recently rolled out 500+ HP E-series switches for a customer. Prior to this project my experience with the (former) ProCurve range was limited mostly to simple Layer 2 designs with a little bit of AAA and SNMP thrown in. After about an hour of playing on the device, I was already comfortable with the CLI and ready to start “translating” the config I was after into the correct dialect.

ProCurve CLI is very similar to IOS you say? Well how about Junos then? I think we can all agree that Junos is significantly different to many of the other competitors, but it only took me a day or two in the lab before I was comfortable enough to deploy some of these in a semi-production network to start getting some real world experience.

If you’re working in the network field DO NOT be afraid of new tech. That doesn’t matter if it from the same vendor or a new vendor.

My Vendor is the only one who does X?

Personally I think this one falls under the same heading of “The right tool for the right job”, but sometimes people have engineered themselves into a corner and decide to continue implementing the same solutions because to change or re-design is “too hard”.

Maybe you deployed a proprietary protocol and now you are locked into that vendor. In a previous post I discussed how I was not opposed to proprietary solutions, particularly when they are the only option for a solution. Does this mean that you should stick with this solution when new alternatives exist? The same driving force behind the implementation of the proprietary solution should drive the review of new alternatives – The right tool for the right job!

I understand that certain environments have strict design/innovation schedules, and that once a network is built it is extremely hard to get changes made, but we should always be looking for the best way to do our jobs and to design our networks. Don’t be designing networks based on the text-book from 10 years ago!

Wrap up

Multi-Vendor is not scary or hard, as long as you do it for the right reasons.

Feel free to share your comments, flames or multi-vendor nightmares 🙂

In my previous blog post about Juniper Training, I discussed how Juniper Firewall Filters were quite interesting and new to me because I have been using SRX since I started with Juniper equipment 12 months ago.

Robert Juric (@robertjuric) has written two really good blog posts about this topic that provides a really good overview of the topic. Robert is currently studying for his JNCIA-EX exam and has written several articles about Junos configuration.

If you are new to Juniper and Junos, then you really should check out the following to Articles:

• JUNOS Firewall Filters
• JUNOS Firewall Filters – Part 2

If you follow my @networkjanitor twitter feed than you may know that I spent 3 days last week in training provided by Juniper and the local distributer Avnet.

In the old tradition of “free training for channel partners”, I signed up for “Junos Routing Essentials (JRE)” and “Junos for Security Platforms”. There was an “Introduction to Junos Software” course on the Monday that I sent one of my engineers along to, but I didnt attend personally. I have included below my review of the two courses.

Junos Routing Essentials (JRE)

This course was a one day course aimed at engineers who may or may not already understand the theory behind various routing protocols and processes.

There was a brief overview of how a routing table works and how the forwarding table is produced from this, which felt a little redundant at first, but led into further discussion about the various routing tables used within Junos and their functions. There were a few things I had not picked up working on Juniper kit that was handy here.

Quite a bit of this course was devoted to routing policy and how to import and export using Junos routing policies. This makes sense as once you understand the routing policy structures within Junos you open the doorway to some of the true power of the design inherent in Junos. There are quite a lot of match options available to routing policies that make life much easier (especially if you come from a Cisco background). I am working on a seperate blog post to discuss this topic further, as I feel there is a lot to point out.

The section on (stateless) firewall rules was interesting for me because I am used to working on SRX series routers which use zone based / statefull firewalls. To date the extent of my firewall policies was around rules on the loopback to control access to SSH/Telnet/SNMP etc.

Class of Service section was brief but gave an overview of how to build policies to control different CoS settings. You really would want some kind of previous exposure to QoS/CoS to supplement this module, but that really is the point of these condensed courses.

Junos For Security Platforms (SEC)

This course was a two day course focusing on the SRX series routers. Most of my Juniper experience has been on SRX240s, so I felt quite comfortable in this class. As always, I taught myself to do exactly what I needed to do to get the job done, so learning the ins and outs of how and why the platform works the way it does was insightful.

The opening module discusses the benefits and features of a converged router/firewall device and the superiority over traditional disparate devices. Mostly a lot of “my product is better”, but there is little dive into how the hardware traffic flows through the SRX platform. The module finishes up discussing the modular design of the Junos OS and further discussion of Flow based processing that is the foundation of the SRX platform (and shows its lineage from ScreenOS products).

The next two sections discussed the advantages of Zone based firewalling and how to build security policies to implement your goal. Discussion of the scheduling feature of policies to enforce time of day or day of week style firewall rules was an interesting design I had never really looked at, but has obvious uses within an enterprise type environment.

Firewall authentication, which is the ability to auth against the firewall to open up a particular set of firewall policies was interesting, and I have seen similar things when I used to use OpenBSD as a firewall, but I felt the uses were fairly restrictive and somewhat limited. If I really wanted something like this, the SRX is perfectly suited to operate as a VPN device and provide even greater functionality to boot.

Given the lineage from ScreenOS, the SRX platform has inherited a series of SCREEN features to filter broadstroke denial of service attempts as well as handling suspicious traffic. We discussed when to use SCREEN versus some of the optional IDP features or using firewall policies.

NAT on the SRX platform is somewhat different from both traditional Junos as well as from ScreenOS. The usual list of features are supported. Static 1:1 NAT, Destination Nat (port forwards etc), and Source Based Nat (both with and without PAT). Two interesting gotchas with the NAT implementation:

a) Security Policy is applied after NAT translations, so say you have a static 1:1 NAT arrangement, you would actually apply your zone based rules on the outside interface, but reference the internal address in the destination as opposed to the IP address used by the remote host. This makes sense after a while, but took some time to get my head around.

b) Like other firewalls, the SRX will happily snatch and translate any traffic routed through it according to any NAT rules that are configured. If on the otherhand you have say a large subnet on the “untrust” side of the firewall, and you try to make some NAT rules using some of those additional addresses, you will need to tell the router to Proxy ARP those addresses. I had been caught out on this one on a previous job, and felt a little foolish when they brought it up on the course. I wont be forgetting this one.

As one would expect from a modern firewall product, the SRX supports IPSec VPNs, which were covered quite well in the course. There are two types of IPSec VPNs – policy based and route based. Essentially policy based uses security policies to determine which traffic gets handled by IPSec. Anyone familiar with Cisco IPSec implementations should understand this concept. The other option is route based which configures a new interface on the router (st0.x) that is used as the tunnel between two VPN gateways. You can assign IP addresses to these interfaces and route traffic across it (Or use a dynamic routing protocol) just like any other interface type. It feels somewhat like a GRE tunnel in IOS, but with the added benefit of IPSec encryption and integrity checks.

A very brief look at the Intrusion Detection and Prevention features of the SRX was given, but this could have been a whole course on its own, not to mention this is a licensed feature of the SRX. A lot of interesting features, but not as powerful as a dedicated IPS/IDS solution. Worth considering for a branch deployment though, which is where this feature is aimed.

The last section covered an area of the SRX that I have spent some time on – High Availability. One of the great features of the SRX platform is that you can implement an Active/Active zone based firewall solution even on the smaller branch/appliance series of devices. I have implemented a HA pair of SRX240’s for a customer and have been quite happy with the result (though I suggest you lab this heavily before implementing due to instability issues on certain Junos versions).

In HA mode, you configure a set of redundancy groups and weightings for device failover triggers. There is a bit of fiddling to get some of these groups configured the way you expect them, but this is mostly due to the fact that both devices in the cluster have active data planes, and you need to know which interfaces (and on which device) traffic will ingress and egress.

HA on SRX Platforms could take another whole blog entry, which I am happy to go into if there is enough interest – so let me know if you want to hear more.

Final Thoughts?

So, after 3 days of training I walked away feeling that I had managed to learn quite a bit even though I have been working with Juniper equipment for 12 months now. The theory was aimed at engineers who already understood core concepts and routing protocol requirements, but even a junior engineer would learn a lot from these courses. There was a lot of hands-on lab exposure to teach you the ins and outs of the theory – it certainly made sure you learnt the material.

If you can get your account rep to organise the training (or have a company who will pay for it for you), then this is certainly worth spending some time on.

Hope this helps someone out there who is starting to look into Juniper as an alternative network vendor. Please let me know if you want me to follow up anything here, or would like me to show some further examples of the Juniper solutions.