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.

[nick@mbp ~]$ ssh root@y.y.y.y -X 
Last login: Wed Nov 28 09:10:47 2018 from supersecretlocation.com
[root@server ~]# echo $DISPLAY
localhost:10.0
[root@server ~]#

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

[nick@mbp ~]$ ssh  myvMX                                                                                                      Password: 
--- JUNOS 16.1R7.8 built 2018-09-12 09:06:00 UTC
nick@vMX> start shell
% su -
Password:
root@vMX%

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

root@213.219.38.122'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

Advertisements

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!

IMG_0037

 

MTR style traceroute on Juniper

Having used MTR on my mac and on Linux system I was always frustrated with the lack of this option from the Junos CLI.  You have always been able to start a shell and run MTR as below:-

nick@ScoobyDoo> start shell
% mtr 8.8.8.8

Although it’s super handy, the inconvenience of starting the shell can be a PITA.

I thought i would have to live with this until I found the following:-

nick@ScoobyDoo> traceroute monitor 8.8.8.8

Who knew!!!!

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

fun with bi-directional forwarding (BFD)

So I was tasked to provide a failover mechanism for a customer with Juniper equipment without using OSPF.

With the L2 providers we use there is always a link from the CPE to the provider equipment and then it breaks out to their backbone.  Now, this means that there could be a break in the provider network and the customer CPE would still see the link as up.  We would then be blindly forwarding traffic into a black hole. Continue reading