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

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

Juniper as-path-expand with bgp communities

With working in an ISP enviroment I always find myself trying to automate or create process for others to follow so I don’t have to do the work 😉

I recently started to look at BGP communities and to see how I can apply them in day to day life.  One of the applications that would make my life easier the bigger we grow is putting the onus onto the bgp transit customer to affect how we advertise/announce them to our upstreams, peers and customers. Continue reading