Junos and packet tracing

So its been a while since my last blog as the last year or so has been manic in my $dayjob due to a number of projects and I have finally managed to take a breath and start to think of some content I can give back to the community. The following post comes with a big thanks to James for pointing me towards this great trick and educating me on some linux/unix commands!

Junos devices have the ability to examine packets destined for the routing engine in a number of ways.

Junos Builtin

Using the command

monitor traffic interface ge-0/0/0 no-resolve size 1600 matching "<tcpdump filter>"

You will see any packet bound for the routing engine. Using a tcpdump compatible filter the capture can be refined to specific traffic.

Offline Wireshark

Using the same command but with the hidden option write-file for saving as a PCAP file

monitor traffic interface ge-0/0/0 no-resolve size 1600 matching "<tcpdump filter>" write-file /tmp/mytrace.pcap

Transfer the file off the device via SCP and the trace can then be examined in a local install of wireshark. This is the best way to quickly examine captured packets but makes live debugging tricky

Live Wireshark

Due to Junos being built on Unix and using tcpdump for its underlying packet capture it is possible to redirect the tcpdump output from STDOUT via an SSH connection to a remote system where wireshark is installed for live packet capture. This remote system must be accessible from the device where packets are captured and not behind NAT unless there is a port forward in place. If the remote system is not a local laptop then X-Forwarding can be used to trigger a session that is forwarded to the local laptop.

On the remote system where wireshark is installed open an SSH connection with X-Forwarding enabled, show the current DISPLAY env and leave the session open.

[[email protected] ~]$ ssh [email protected] -X 
Last login: Wed Nov 28 09:10:47 2018 from supersecretlocation.com
[[email protected] ~]# echo $DISPLAY
[[email protected] ~]#

Login to the system where the trace is to be run and start a root shell

[[email protected] ~]$ ssh  myvMX                                                                                                      Password: 
--- JUNOS 16.1R7.8 built 2018-09-12 09:06:00 UTC
[email protected]> start shell
% su -
[email protected]%

Run the tcpdump command setting the interface to capture, IP of the remote system to forward to and a valid source address to use on the system where the packets are captured.

tcpdump -i <interface_to_capture> -nn -s 1600 -w - -l not port 22 | ssh [email protected]<remote_server> -b <local_source_address> "(wireshark --display=:10.0 -knSli  -)"

It will then start tcpdump and prompt for the password to the remote system

Address resolution is OFF.
Listening on ge-1/1/0, capture size 1600 bytes

[email protected]'s password:

Once entered wireshark will automatically start and you will see live packets coming in and out of the interface. Use wireshark to filter for the desired traffic

#NXTWORK2016 Highlights

Having finally got over the jet lag from attending Junipers second #NXTWORK event I thought I would write down a few thoughts.

So this is the second year of the #NXTWORK customer summit and they have learned so much from last year. The amount of attendees has increased, not overly so, which has given the event a new dynamic and a new feel. It still feels intimate but there is a great buzz going around.

The Marriott in Santa Clara was again the venue for this great event and there has been some fantastic additions. No longer is the attendee eating area at the back of the main event room making you feel a bit squeezed! It has now been moved out to a giant marquee just outside the main event area which now gives the event additional space for those great networking chats but also allows for more sponsor stands (more on those below).

Breakout sessions

The breakout sessions were again fantastic and kudos to Juniper for leaving out the Marketing fluff from them. Some of the sessions I found were slightly too high level but generally well received. Especially when you can harass the speaking directly afterwards to find out any information that has not been readily forthcoming before!

The main breakout highlights for me were exploring EVPN and how it is maturing and gaining additional features. As a Network Engineer from an ISP this technology will allow us to provide additional services and resiliency into our products which the likes of VPLS haven’t been able to give us.

Sponsor stands

I have to say my favourite sponsor stand was that of OneConfig with 2 separate products.  One which was their tie in with Juniper Networks in the guise of Project Buffalo and the other was their cloud based MTFW (Multi Tennant Firewall)front end.

For MSP’s, Project Buffalo is a no brainer.  Put an SRX into a potential customer site.  Add a bit of config to connect to OneConfig and a week later they provide you with a traffic analysis report highlighting any potential threats.  The best part about this is that Juniper are covering the cost of this!(apart from the SRX and licenses you will need on box)

The MTFW could be a real game changer for some MSP who use a large shared firewall for customers.  This allows junior security/network engineers and customers to login on and make amendments to their part of the firewall without interfering with others customers rules and policies.


Keynote Highlights


As always, Rami’s keynote leaves you feeling positive with the knowledge that Juniper are on a great trajectory and embracing the change to becoming a software company rather than a hardware company.

Kireeti Kompella’s take on SDN (Self Driving Network) shows why he is considered a thought leader in his field (and why i feel as clever as a cheese sandwich when listening to him)!

The main keynote which blew me away was Jonthathon Davidson’s presentation in which they had admitted that Juniper has previously got it wrong in the security space but they are working hard to correct this (see some of the latest Gartner reports on NGFW).  It’s not like Juniper to have to play catch up as in my eyes have lead from the from in the R&S space for some time and it must lead to some awkward conversations internally in how they not only catch up but then get ahead of the competition.

This catching up was also evident when myself and other Juniper Ambassadors got to sit down and grill the security team (read vent!) at a private lunch.  The conversation was frank and somewhat heated on a few of our bugbears but the Security team acknowledged them and advised that for pretty much all of our points, they are already being addressed.


I am currently a Juniper Ambassador and Juniper paid for my flights and accommodation for the NXTWORK event.

My 3 year Workiversary!

So LinkedIn told me it was my 3 year workiversary the other day.  3 whole years since starting with Fluency Communications and building out their National Next Gen Network.

When I first joined the company, the network was ran on 3 Vyatta boxes and a few 100M circuits.  From there we started the upgrade process to Juniper MX5 routers and some 1G links.

What made the MX platform stand out for us was the following:-

  • Stability of Junos OS
  • Rich feature set
  • Built in scripting tools (Netconf/SLAX)
  • Scalability

We required to have a box that would scale not only in performance but features. The MX5 can be easily unlocked from a 20G line rate box up to an MX10 giving 40G line rate performance with a simple license install (and further if you want).  For us, EVPN is looking like a no brainer upgrade from VPLS with its control plane learning and mac learning/filtering with the use of policies.  Sometimes it seems the possibilities are endless!

We have now outgrown the MX5/10 as our core router and we are now in receipt of some shiny MX480 routers (see below picture).  We have also taken the decision to go single vendor, which up until the last year or so I always had an inherent distrust of but seeing the flexibility of the MX platform has removed that mental stumbling block and we are now using the MX104 at our access edge for customer connections rather than our previous vendor.

This allows us to look at things like Junos Space,Network Director and Connectivity Services Director to allow us to build service templates that will allow us to provision complex customer solutions and the click of a button rather than jumping onto several boxes and sitting at the cli for 20-30mins.  This frees up my time to start looking at the next core network upgrade!

Have a great Christmas and a fantastic New Year!

P.S. Here’s a pic of our little MX evolution. From bottom to top – MX5, MX10, MX104 and an MX480!



Why oh why?

So i have been using Juniper MX routers for some years now (mainly MX80’s) and have configured CoS in reasonably basic forms to suit $dayjob’s needs (mainly 4 queues).

It turns out that even though the MX routers support 8 queues in the basic line cards, by default it starts with 4 :s

Would it not be easier to enable all 8 to start with?


The path to certification

Over the last few years I have made the transition at the company I work for, from Support Engineer to Network Engineer. In between this I became a Managed Services Engineer dealing with the configuration, installation and maintenance of Cisco 1800 series routers.  During this time I decided I would use the knowledge gained in my day job to go on the certification trail. 4 months later I gained my CCNA accreditation and a thirst to obtain more understanding in networking in general.

Continue reading