Interactive traffic-monitoring tool
SR Linux features an interactive traffic-monitoring tool that allows you to capture and monitor traffic based on 5-tuple match criteria. The match criteria is injected into a packet capture filter ACL entry that is applied to all subinterfaces; information from 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.
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 |
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:
Capture filter ACL entry
--{ * candidate shared default }--[ ]--
# info 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.
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.1.1.1/32 and destination address 10.2.2.2/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 2.2.2.2 1.1.1.1 ICMP 146 Echo (ping) reply id=0x28a8, seq=119/30464, ttl=63
2 1.803 ethernet-1/20.1 2.2.2.2 1.1.1.1 ICMP 146 Echo (ping) reply id=0x28a8, seq=119/30464, ttl=63
3 2.895 ethernet-1/20.1 2.2.2.2 1.1.1.1 ICMP 146 Echo (ping) reply id=0x28a8, seq=119/30464, ttl=63
4 3.749 ethernet-1/20.1 2.2.2.2 1.1.1.1 ICMP 146 Echo (ping) reply id=0x28a8, seq=119/30464, ttl=63
5 4.250 ethernet-1/20.1 2.2.2.2 1.1.1.1 ICMP 146 Echo (ping) reply id=0x28a8, seq=119/30464, ttl=63
6 5.759 ethernet-1/20.1 2.2.2.2 1.1.1.1 ICMP 146 Echo (ping) reply id=0x28a8, seq=119/30464, ttl=63
7 6.644 ethernet-1/20.1 2.2.2.2 1.1.1.1 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.
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:
# tools system traffic-monitor destination-address 10.1.1.1/32 source-address 10.2.2.2/32 protocol icmp verbose
Frame 1: 146 bytes on wire (1168 bits), 146 bytes captured (1168 bits) on interface 0
Interface id: 0 (monit)
Interface name: monit
Encapsulation type: Ethernet (1)
Arrival Time: Jan 4, 2098 19:53:01.144789891 UTC
[Time shift for this packet: 0.000000000 seconds]
Epoch Time: -255263715.144789891 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/20.1
Padding: 000000
Ethernet II, Src: 00:00:5e:00:53:d2, Dst: 00:00:5e:00:53:41
Destination: 00:00:5e:00:53:41
Address: 00:00:5e:00:53:41
.... ..0. .... .... .... .... = LG bit: Globally unique address (factory default)
.... ...0 .... .... .... .... = IG bit: Individual address (unicast)
Source: 00:00:5e:00:53:d2
Address: 00:00:5e:00:53:d2
.... ..0. .... .... .... .... = LG bit: Globally unique address (factory default)
.... ...0 .... .... .... .... = IG bit: Individual address (unicast)
Type: IPv4 (0x0800)
Internet Protocol Version 4, Src: 10.20.20.20, Dst: 10.10.10.10
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: 0xa166 (41318)
Flags: 0x0000
0... .... .... .... = Reserved bit: Not set
.0.. .... .... .... = Don't fragment: Not set
..0. .... .... .... = More fragments: Not set
...0 0000 0000 0000 = Fragment offset: 0
Time to live: 63
Protocol: ICMP (1)
Header checksum: 0x9e07 [validation disabled]
[Header checksum status: Unverified]
Source: 10.2.2.2
Destination: 10.1.1.1
Internet Control Message Protocol
Type: 0 (Echo (ping) reply)
Code: 0
Checksum: 0xd01f [correct]
[Checksum Status: Good]
Identifier (BE): 10408 (0x28a8)
Identifier (LE): 43048 (0xa828)
Sequence number (BE): 1352 (0x0548)
Sequence number (LE): 18437 (0x4805)
Timestamp from icmp data: Jan 4, 2098 19:53:01.000000000 UTC
[Timestamp from icmp data (relative): 0.144789891 seconds]
Data (48 bytes)
0000 5a 30 02 00 00 00 00 00 10 11 12 13 14 15 16 17 Z0..............
0010 18 19 1a 1b 1c 1d 1e 1f 20 21 22 23 24 25 26 27 ........ !"#$%&'
0020 28 29 2a 2b 2c 2d 2e 2f 30 31 32 33 34 35 36 37 ()*+,-./01234567
Data: 5a30020000000000101112131415161718191a1b1c1d1e1f…
[Length: 48]
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.1.1.1/32 and
destination address 10.2.2.2/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 two capture filter entries: one that matches traffic with source address 10.1.1.1/32 and one that matches traffic with destination address 10.2.2.2/32.
--{ * candidate shared default }--[ ]--
# info acl acl-filter capture type ipv4
acl {
acl-filter capture type ipv4 {
entry 10 {
match {
ipv4 {
source-ip {
address 10.1.1.1
mask 255.255.255.255
}
}
}
action {
copy {
}
}
}
entry 20 {
match {
ipv4 {
destination-ip {
address 10.2.2.2
mask 255.255.255.255
}
}
}
action {
copy {
}
}
}
}
}When you start the traffic-monitoring tool, it captures packets matching both filter entries. For example:
# tools system traffic-monitor
Capturing on 'monit'
1 0.000 ethernet-1/20.1 1.1.1.1 2.2.2.2 ICMP 146 Echo (ping) reply id=0x28a8, seq=119/30464, ttl=63
2 1.803 ethernet-1/21.1 2.2.2.2 1.1.1.1 ICMP 146 Echo (ping) reply id=0x28a8, seq=119/30464, ttl=63
3 2.895 ethernet-1/20.1 1.1.1.1 2.2.2.2 ICMP 146 Echo (ping) reply id=0x28a8, seq=119/30464, ttl=63
4 3.749 ethernet-1/21.1 2.2.2.2 1.1.1.1 ICMP 146 Echo (ping) reply id=0x28a8, seq=119/30464, ttl=63
5 4.250 ethernet-1/20.1 1.1.1.1 2.2.2.2 ICMP 146 Echo (ping) reply id=0x28a8, seq=119/30464, ttl=63
6 5.759 ethernet-1/21.1 2.2.2.2 1.1.1.1 ICMP 146 Echo (ping) reply id=0x28a8, seq=119/30464, ttl=63
7 6.644 ethernet-1/20.1 1.1.1.1 2.2.2.2 ICMP 146 Echo (ping) reply id=0x28a8, seq=119/30464, ttl=63