Interactive traffic-monitoring tool
SR Linux features an interactive traffic-monitoring tool that allows you to capture and monitor traffic either based on 5-tuple match criteria or by (sub)interface. The tools command can either capture based on the 5 tuple or interface not both at the same time. The system supports the execution of one tools traffic-monitoring command at one time. For the 5-tuple match, Tthe match criteria is injected into a packet capture filter ACL entry that is applied to all subinterfaces. For capture based on interface or subinterface, all packets traversing the specified interfaces and subinterfaces are captured; information from all matching packets can be displayed on screen or directed to a file.
Using the interactive traffic-monitoring tool
You can specify the match criteria either by using the tools system traffic-monitor CLI command, or by defining capture-filter ACL entries.
ACL capture
If you use the tools system traffic-monitor command to specify the match criteria, SR Linux dynamically creates a capture-filter entry with the match criteria. Packets that match the capture-filter entry are sent to the traffic-monitoring tool running on the CPM and displayed until the traffic-monitoring tool is exited, at which time the dynamically created capture-filter entries are removed.
Use the following syntax to configure the tools system traffic-monitor command:
tools system traffic-monitor [source-address <ip-addr/len>] [destination-address <ip-addr/len>] [protocol <proto-val>] [source-port <value | range>] [destination-port <value | range>] [verbose] [output-file <file-name>] [hex-output]
The command parameters are described in Traffic monitoring command parameters.
|
Command/parameter |
Description |
|---|---|
|
tools system traffic-monitor |
Initiates an interactive monitor session |
|
source-address <ip-addr/len> |
Source IP address (IPv4 or IPv6) prefix and netmask length value. For example: 10.10.11.0/24 |
|
destination-address <ip-addr/len> |
Destination IP address (IPv4 or IPv6) prefix and netmask length value. For example: 10.10.20.0/24 |
|
protocol <proto-val> |
Specifies the protocol type value to match (required if either port values are specified) |
|
source-port <value | range> |
Source port integer value or port range in the format of port1..port2 |
|
destination-port <value | range> |
Destination port integer value or port range in the format of port1..port2 |
|
verbose |
Displays detailed output |
|
output-file <file-name> |
Directs output to a file |
|
hex-output |
Displays output in hex format |
|
direction <ingress | egress> |
Mirroring direction when |
|
interface <value> |
Interface, subinterface, or LAG to mirror. Only one interface per command. |
If you specify the match criteria by defining capture-filter ACL entries, starting the traffic-monitoring tool with the tools system traffic-monitor command causes the system to send packets that match the defined capture-filter entries to the CPM and display them until the traffic-monitoring tool is exited. Unlike the dynamically created capture-filter entries, the defined capture-filter entries are not removed from the system when the traffic-monitoring tool is exited.
There is one packet capture filter for IPv4 traffic and another packet capture filter
for IPv6 traffic. The default IPv4 packet capture filter copies no IPv4 packets, and
the default IPv6 packet capture filter copies no IPv6 packets. To configure a packet
capture filter, you create an IPv4 or IPv6 ACL filter named capture
and specify match conditions and actions.
The following is an example of a capture-filter ACL entry:
--{ + candidate shared default }--[ ]--
# info with-context acl acl-filter capture type ipv4
acl {
acl-filter capture type ipv4 {
entry 1 {
match {
ipv4 {
protocol icmp
destination-ip {
address 10.1.1.1
mask 255.255.255.255
}
source-ip {
address 10.2.2.2
mask 255.255.255.255
}
}
}
action {
copy {
}
}
}
}
}Capture filters are applied to traffic after any subinterface filters, but before CPM filters. If a packet is dropped by a subinterface filter, it is not evaluated by a capture filter.
Only a single instance of the traffic-monitoring tool can be running at a time.
If no capture-filter entries are already defined, you must specify the match criteria with the tools system traffic-monitor command. If capture-filter entries are already defined, match criteria specified with the tools system traffic-monitor command is ignored.
Interface and subinterface capture
On 7250 IXR platforms, you
can specify an interface in the tools system
traffic-monitor command. In this case, the system does not create a
capture-filter entry. Instead, it creates an internal mirror with traffic monitoring
as the destination and sends the mirrored packets to the same traffic-monitoring
tool on the CPM, including PCAP output if an output file is specified.
- The system can capture about 5000 packets per second. Exceeding this rate results in missing packets.
- Only one interface can be captured at one time and is mutually exclusive with ACL capture
- If the capture interface or subinterface is already a mirror source, executing the tool traffic-monitoring command for that interface or subinterface is rejected.
- Interface or subinterface capture depends on available mirroring resources and if those resources are exhausted, the system returns an error message.
The command syntax adds optional interface mirroring parameters.
tools system traffic-monitor [direction <ingress|egress>] [interface <interface-name>] [source-address <ip-addr/len>] [destination-address <ip-addr/len>] [protocol <proto-val>] [source-port <value | range>] [destination-port <value | range>] [verbose] [output-file <file-name>] [hex-output]
Monitoring ICMP Packets
The following is an example of using the traffic-monitoring tool to monitor ICMP packets. In this
example, information about ICMP packets with source address 10.2.2.2/32 and
destination address 10.1.1.1/32 is displayed in the monitor window, including the
arrival time and source port (ethernet-1/20.1) of each packet. The
traffic-monitoring tool captures ICMP packets until you press Ctrl-C.
Traffic-monitoring tool
# tools system traffic-monitor destination-address 10.1.1.1/32 source-address 10.2.2.2/32 protocol icmp
Capturing on 'monit'
1 0.000 ethernet-1/20.1 10.1.1.1 10.2.2.2 ICMP 146 Echo (ping) reply id=0x28a8, seq=119/30464, ttl=63
2 1.803 ethernet-1/20.1 10.1.1.1 10.2.2.2 ICMP 146 Echo (ping) reply id=0x28a8, seq=119/30464, ttl=63
3 2.895 ethernet-1/20.1 10.1.1.1 10.2.2.2 ICMP 146 Echo (ping) reply id=0x28a8, seq=119/30464, ttl=63
4 3.749 ethernet-1/20.1 10.1.1.1 10.2.2.2 ICMP 146 Echo (ping) reply id=0x28a8, seq=119/30464, ttl=63
5 4.250 ethernet-1/20.1 10.1.1.1 10.2.2.2 ICMP 146 Echo (ping) reply id=0x28a8, seq=119/30464, ttl=63
6 5.759 ethernet-1/20.1 10.1.1.1 10.2.2.2 ICMP 146 Echo (ping) reply id=0x28a8, seq=119/30464, ttl=63
7 6.644 ethernet-1/20.1 10.1.1.1 10.2.2.2 ICMP 146 Echo (ping) reply id=0x28a8, seq=119/30464, ttl=63
^C
7 packets captured
Command execution aborted : 'tools system traffic-monitor destination-address 10.1.1.1/32 source-address 10.2.2.2/32 protocol icmp'
When you execute the tools system traffic-monitor command in the example above, it dynamically creates the following traffic monitoring policy:
acl {
acl-filter capture type ipv4 {
entry 1 {
match {
ipv4 {
protocol icmp
destination-ip {
address 10.1.1.1
mask 255.255.255.255
}
source-ip {
address 10.2.2.2
mask 255.255.255.255
}
}
}
action {
copy {
}
}
}
}
}When you terminate the command by pressing Ctrl-C, the dynamically created traffic monitoring policy is removed from all ingress interfaces.
tools system traffic-monitor interface
# tools system traffic-monitor interface lag8 direction egress
Capturing on 'monit'
1 0.000000000 ethernet-1/30 00:31:26:7c:31:55 01:80:c2:00:00:02 00:31:26:7c:31:55 01:80:c2:00:00:02 LACP 172 v1 ACTOR 00:31:26:7c:29:38 P: 15 K: 32775 **DCSGSA PARTNER 00:31:26:7b:99:38 P: 15 K: 32775 **DCSGSA
2 0.491820319 ethernet-1/32 00:31:26:7c:31:57 01:80:c2:00:00:02 00:31:26:7c:31:57 01:80:c2:00:00:02 LACP 172 v1 ACTOR 00:31:26:7c:29:38 P: 16 K: 32775 **DCSGSA PARTNER 00:31:26:7b:99:38 P: 16 K: 32775 **DCSGSA
When you execute the tools system traffic-monitor interface command in the above example, it dynamically creates the following mirroring session:
mirroring-instance __tm_mirror_capture_0xffe6_internal {
admin-state enable
oper-state up
mirror-source {
interface lag8 {
direction egress-only
}
}
mirror-destination {
pcap {
capture-type [
capture-interface
]
}
}
}Displaying verbose output
If you include the verbose option in the tools system traffic-monitor command, it displays the header fields and additional information from the shim header, followed by the original packet.
Verbose output
The following example shows verbose output for an ICMP packet:
--{ + candidate shared default }--[ ]--
# tools system traffic-monitor destination-address 10.1.1.1/32 source-address 10.2.2.2/32 protocol icmp verbose
Capturing on 'monit'
Frame 1: 146 bytes on wire (1168 bits), 146 bytes captured (1168 bits) on interface monit, id 0
Section number: 1
Interface id: 0 (monit)
Interface name: monit
Encapsulation type: Ethernet (1)
Arrival Time: Oct 16, 2026 10:01:02.801848603 UTC
UTC Arrival Time: Oct 16, 2026 10:01:02.801848603 UTC
Epoch Arrival Time: 1792144862.801848603
[Time shift for this packet: 0.000000000 seconds]
[Time delta from previous captured frame: 0.000000000 seconds]
[Time delta from previous displayed frame: 0.000000000 seconds]
[Time since reference or first frame: 0.000000000 seconds]
Frame Number: 1
Frame Length: 146 bytes (1168 bits)
Capture Length: 146 bytes (1168 bits)
[Frame is marked: False]
[Frame is ignored: False]
[Protocols in frame: eth:srlinux:eth:ethertype:ip:icmp:data]
Srlinux Packet
Ingress Port: ethernet-1/13.0
Padding: 000000
Ethernet II, Src: 08:47:4c:c7:bd:a7, Dst: 08:47:4c:c7:b5:a7
Destination: 08:47:4c:c7:b5:a7
.... ..0. .... .... .... .... = LG bit: Globally unique address (factory default)
.... ...0 .... .... .... .... = IG bit: Individual address (unicast)
Source: 08:47:4c:c7:bd:a7
.... ..0. .... .... .... .... = LG bit: Globally unique address (factory default)
.... ...0 .... .... .... .... = IG bit: Individual address (unicast)
Type: IPv4 (0x0800)
[Stream index: 0]
Internet Protocol Version 4, Src: 10.2.2.2, Dst: 10.1.1.1
0100 .... = Version: 4
.... 0101 = Header Length: 20 bytes (5)
Differentiated Services Field: 0x00 (DSCP: CS0, ECN: Not-ECT)
0000 00.. = Differentiated Services Codepoint: Default (0)
.... ..00 = Explicit Congestion Notification: Not ECN-Capable Transport (0)
Total Length: 84
Identification: 0x8bd3 (35795)
010. .... = Flags: 0x2, Don't fragment
0... .... = Reserved bit: Not set
.1.. .... = Don't fragment: Set
..0. .... = More fragments: Not set
...0 0000 0000 0000 = Fragment Offset: 0
Time to Live: 64
Protocol: ICMP (1)
Header Checksum: 0x97d0 [validation disabled]
[Header checksum status: Unverified]
Source Address: 10.2.2.2
Destination Address: 10.1.1.1
[Stream index: 0]
Internet Control Message Protocol
Type: 8 (Echo (ping) request)
Code: 0
Checksum: 0xd3c6 [correct]
[Checksum Status: Good]
Identifier (BE): 54219 (0xd3cb)
Identifier (LE): 52179 (0xcbd3)
Sequence Number (BE): 1 (0x0001)
Sequence Number (LE): 256 (0x0100)
Timestamp from icmp data: Oct 16, 2026 10:01:02.800981000 UTC
[Timestamp from icmp data (relative): 0.000867603 seconds]
Data (40 bytes)
0000 10 11 12 13 14 15 16 17 18 19 1a 1b 1c 1d 1e 1f ................
0010 20 21 22 23 24 25 26 27 28 29 2a 2b 2c 2d 2e 2f !"#$%&'()*+,-./
0020 30 31 32 33 34 35 36 37 01234567
Data: 101112131415161718191a1b1c1d1e1f202122232425262728292a2b2c2d2e2f3031323334353637
[Length: 40]Capturing packets to a file
You can direct the captured packets to a file, which can be used as a source for the SR Linux packet trace utility or for Wireshark.
Directing captured packets
The following example directs information about ICMP packets with source address 10.2.2.2/32 and
destination address 10.1.1.1/32 to a
.pcap file.
# tools system traffic-monitor destination-address 10.1.1.1/32 source-address 10.2.2.2/32 protocol icmp output-file /home/linuxadmin/ICMP.pcap
Capturing on 'monit'
6 packets captured
Command execution aborted : 'tools system traffic-monitor destination-address 10.1.1.1/32 source-address 10.2.2.2/32 protocol icmp output-file /home/linuxadmin/ICMP.pcap '
Before opening the .pcap file, remove the shim header (the first 48
bytes of the file). For example:
$ editcap -C 0:48 /home/linuxadmin/ICMP.pcap /home/linuxadmin/ICMP_chopped.pcap
Capturing bidirectional transit traffic
The 5-tuple matching criteria defined in a tools system traffic-monitor command applies in one direction only. To capture traffic in both directions, you define capture filters for each direction, then start the traffic-monitoring tool, which applies both capture filters on all ports.
Capturing bidirectional transit traffic
The following example defines one capture filter entry that matches traffic with destination IP address 10.0.0.0/8 and source IP address 10.0.0.0/8.
--{ + candidate shared default }--[ ]--
# info acl acl-filter capture type ipv4
acl {
acl-filter capture type ipv4 {
entry 1 {
match {
ipv4 {
protocol icmp
destination-ip {
prefix 10.0.0.0/8
}
source-ip {
prefix 10.0.0.0/8
}
}
}
}
}
}When you start the traffic-monitoring tool, it captures packets matching both filter entries. For example:
# tools system traffic-monitor
1 0.000000000 ethernet-1/1.1 10.1.1.1 10.2.2.2 ICMP 146 Echo (ping) request id=0x8e3d, seq=23/5888, ttl=64
2 0.000946459 ethernet-1/2.1 10.2.2.2 10.1.1.1 ICMP 146 Echo (ping) reply id=0x8e3d, seq=23/5888, ttl=64 (request in 1)
3 1.001009926 ethernet-1/1.1 10.1.1.1 10.2.2.2 ICMP 146 Echo (ping) request id=0x8e3d, seq=24/6144, ttl=64
4 1.002960526 ethernet-1/2.1 10.2.2.2 10.1.1.1 ICMP 146 Echo (ping) reply id=0x8e3d, seq=24/6144, ttl=64 (request in 3)
5 2.002007753 ethernet-1/1.1 10.1.1.1 10.2.2.2 ICMP 146 Echo (ping) request id=0x8e3d, seq=25/6400, ttl=64
6 2.002949632 ethernet-1/2.1 10.2.2.2 10.1.1.1 ICMP 146 Echo (ping) reply id=0x8e3d, seq=25/6400, ttl=64 (request in 5)
7 3.001983363 ethernet-1/1.1 10.1.1.1 10.2.2.2 ICMP 146 Echo (ping) request id=0x8e3d, seq=26/6656, ttl=64
8 3.003938511 ethernet-1/2.1 10.2.2.2 10.1.1.1 ICMP 146 Echo (ping) reply id=0x8e3d, seq=26/6656, ttl=64 (request in 7)
9 4.003997530 ethernet-1/1.1 10.1.1.1 10.2.2.2 ICMP 146 Echo (ping) request id=0x8e3d, seq=27/6912, ttl=64
104.004949967 ethernet-1/2.1 10.2.2.2 10.1.1.1 ICMP 146 Echo (ping) reply id=0x8e3d, seq=27/6912, ttl=64 (request in 9)