write-file and read-file knobs in monitor traffic command
From Junos CLI you can use write-file and read-file to write and read packet captures using ‘monitor traffic’ command.
These commands are hidden in CLI. However, if you login to shell, you can use ‘-w’ and ‘-r’ parameters on tcpdump to achieve the same results.
But that is an extra step to do something so you might find useful these hidden knobs.
You will be able to read the packet capture at the level at which you wrote it.
For instance, if you write the packet capture using extensive and read it using the extensive displaying, you will get more output as if you are writting the packet capture without using extensive and reading it using extensive displaying.
The output below should give you the details to understand what I mean.
So I have an aggregated interface(ae0) between one QFX5100 and one EX4550. The output will be collected from EX45500. OSPF is running between the two devices and I will use filter only the ‘ip’ packets(OSPF packets are one of them).
This is the maximum that you can get out of ‘monitor traffic’ command output:
{master:0}[edit] root@EX4550# run monitor traffic interface ae0 extensive size 1500 no-resolve matching ip Jan 15 15:38:38 Address resolution is OFF. Listening on ae0, capture size 1500 bytes 15:38:43.750640 In -----original packet----- 64:64:9b:54:0a:00 > 01:00:5e:00:00:05, ethertype 802.1Q (0x8100), length 98: vlan 50, p 0, ethertype IPv4, (tos 0xc0, ttl 1, id 46220, offset 0, flags [none], proto: OSPF (89), length: 80) 50.50.50.1 > 224.0.0.5: OSPFv2, Hello, length 60 [len 48] Router-ID 99.99.99.1, Backbone Area, Authentication Type: none (0) Options [External, LLS] Hello Timer 10s, Dead Timer 40s, Mask 255.255.255.0, Priority 128 Designated Router 50.50.50.1, Backup Designated Router 50.50.50.2 Neighbor List: 99.99.99.2 LLS: checksum: 0xfff6, length: 3 Extended Options (1), length: 4 Options: 0x00000001 [LSDB resync] 15:38:43.875971 Out -----original packet----- 54:e0:32:86:f8:c1 > 01:00:5e:00:00:05, ethertype IPv4 (0x0800), length 94: (tos 0xc0, ttl 1, id 20341, offset 0, flags [none], proto: OSPF (89), length: 80) 50.50.50.2 > 224.0.0.5: OSPFv2, Hello, length 60 [len 48] Router-ID 99.99.99.2, Backbone Area, Authentication Type: none (0) Options [External, LLS] Hello Timer 10s, Dead Timer 40s, Mask 255.255.255.0, Priority 128 Designated Router 50.50.50.1, Backup Designated Router 50.50.50.2 Neighbor List: 99.99.99.1 LLS: checksum: 0xfff6, length: 3 Extended Options (1), length: 4 Options: 0x00000001 [LSDB resync] ^C 7 packets received by filter 0 packets dropped by kernel {master:0}[edit] root@EX4550#
This is how ‘write-file’ is used. Obviously, you won’t see the packets on the terminal:
{master:0}[edit] root@EX4550# run monitor traffic interface ae0 write-file packet-capture-simple.pcap matching ip Jan 15 15:14:44 Address resolution is ON. Use <no-resolve> to avoid any reverse lookup delay. Address resolution timeout is 4s. Listening on ae0, capture size 96 bytes ^C 5 packets received by filter 0 packets dropped by kernel {master:0}[edit] root@EX4550#
And now, if you read the packet capture without extensive, you will get this:
{master:0}[edit] root@EX4550# run monitor traffic interface ae0 read-file packet-capture-simple.pcap Jan 15 15:15:05 Reverse lookup for 50.50.50.2 failed (check DNS reachability). Other reverse lookup failures will not be reported. Use <no-resolve> to avoid reverse lookups on IP addresses. 15:14:46.898366 Out IP truncated-ip - 20 bytes missing! 50.50.50.2 > 224.0.0.5: OSPFv2, Hello, length 60 15:14:46.934338 In IP truncated-ip - 24 bytes missing! 50.50.50.1 > 224.0.0.5: OSPFv2, Hello, length 60 {master:0}[edit] root@EX4550#
And if you are using ‘extensive’, additional output will be displayed:
{master:0}[edit] root@EX4550# run monitor traffic interface ae0 read-file packet-capture-simple.pcap extensive no-resolve Jan 15 15:16:24 15:14:46.898366 Out -----original packet----- 54:e0:32:86:f8:c1 > 01:00:5e:00:00:05, ethertype IPv4 (0x0800), length 74: truncated-ip - 20 bytes missing! (tos 0xc0, ttl 1, id 43475, offset 0, flags [none], proto: OSPF (89), length: 80) 50.50.50.2 > 224.0.0.5: OSPFv2, Hello, length 60 [len 48] Router-ID 99.99.99.2, Backbone Area, Authentication Type: none (0) Options [External, LLS] Hello Timer 10s, Dead Timer 40s, Mask 255.255.255.0, Priority 128 Designated Router 50.50.50.1 [|ospf2] 15:14:46.934338 In -----original packet----- 64:64:9b:54:0a:00 > 01:00:5e:00:00:05, ethertype 802.1Q (0x8100), length 74: vlan 50, p 0, ethertype IPv4, truncated-ip - 24 bytes missing! (tos 0xc0, ttl 1, id 45364, offset 0, flags [none], proto: OSPF (89), length: 80) 50.50.50.1 > 224.0.0.5: OSPFv2, Hello, length 60 [len 48] Router-ID 99.99.99.1, Backbone Area, Authentication Type: none (0) Options [External, LLS] Hello Timer 10s, Dead Timer 40s, Mask 255.255.255.0, Priority 128 [|ospf2] {master:0}[edit] root@EX4550#
Let’s now write the packet capture using extensive:
{master:0}[edit] root@EX4550# run monitor traffic interface ae0 write-file packet-capture-extensive.pcap matching ip extensive size 1500 Jan 15 15:17:03 Address resolution is ON. Use <no-resolve> to avoid any reverse lookup delay. Address resolution timeout is 4s. Listening on ae0, capture size 1500 bytes ^C 12 packets received by filter 0 packets dropped by kernel {master:0}[edit] root@EX4550#
If default reading is done, it’s similar to the output from the first situation:
{master:0}[edit] root@EX4550# run monitor traffic interface ae0 read-file packet-capture-extensive.pcap Jan 15 15:17:35 Reverse lookup for 50.50.50.1 failed (check DNS reachability). Other reverse lookup failures will not be reported. Use <no-resolve> to avoid reverse lookups on IP addresses. 15:17:04.401094 In IP 50.50.50.1 > 224.0.0.5: OSPFv2, Hello, length 60 15:17:05.335156 Out IP 50.50.50.2 > 224.0.0.5: OSPFv2, Hello, length 60 15:17:13.778305 In IP 50.50.50.1 > 224.0.0.5: OSPFv2, Hello, length 60 15:17:15.144869 Out IP 50.50.50.2 > 224.0.0.5: OSPFv2, Hello, length 60 {master:0}[edit] root@EX4550#
However if we are choosing the read the file by using extensive displaying, additional output will be seen(there were 4 packets in the capture, but I left only 2 of them to minimize the output):
{master:0}[edit] root@EX4550# run monitor traffic interface ae0 read-file packet-capture-extensive.pcap extensive size 1500 Jan 15 15:17:40 15:17:13.778305 In -----original packet----- 64:64:9b:54:0a:00 > 01:00:5e:00:00:05, ethertype 802.1Q (0x8100), length 98: vlan 50, p 0, ethertype IPv4, (tos 0xc0, ttl 1, id 52144, offset 0, flags [none], proto: OSPF (89), length: 80) 50.50.50.1 > 224.0.0.5: OSPFv2, Hello, length 60 [len 48] Router-ID 99.99.99.1, Backbone Area, Authentication Type: none (0) Options [External, LLS] Hello Timer 10s, Dead Timer 40s, Mask 255.255.255.0, Priority 128 Designated Router 50.50.50.1, Backup Designated Router 50.50.50.2 Neighbor List: 99.99.99.2 LLS: checksum: 0xfff6, length: 3 Extended Options (1), length: 4 Options: 0x00000001 [LSDB resync] 15:17:15.144869 Out -----original packet----- 54:e0:32:86:f8:c1 > 01:00:5e:00:00:05, ethertype IPv4 (0x0800), length 94: (tos 0xc0, ttl 1, id 47982, offset 0, flags [none], proto: OSPF (89), length: 80) 50.50.50.2 > 224.0.0.5: OSPFv2, Hello, length 60 [len 48] Router-ID 99.99.99.2, Backbone Area, Authentication Type: none (0) Options [External, LLS] Hello Timer 10s, Dead Timer 40s, Mask 255.255.255.0, Priority 128 Designated Router 50.50.50.1, Backup Designated Router 50.50.50.2 Neighbor List: 99.99.99.1 LLS: checksum: 0xfff6, length: 3 Extended Options (1), length: 4 Options: 0x00000001 [LSDB resync] {master:0}[edit] root@EX4550#
So there is a difference between the two packet captures. And this is coming from the way they were initially written.
Also the packet captures shows less information when they are opened with Wireshark.
I hope this was useful for you and it will help you write and read packet captures directly from Junos CLI.
Paris ARAU
Latest posts by Paris ARAU (see all)
- Junos Fusion – Part IV – Satellite policies and uplink failure detection - 30 July 2018
- Junos Fusion – Part III – Satellite commands and traffic forwarding - 16 July 2018
- Junos Fusion – Part II – Configuration, Administration and Operation - 16 July 2018
- Junos Fusion – Part I – Overview, Components, Ports and Software - 11 July 2018
- Vagrant – Part IV – Network topology using Juniper and Cumulus - 26 April 2018
Comments
So empty here ... leave a comment!