[j-nsp] questions regarding port mirroring analyzer in MX series router

[Martin T]

Hi!

According to Juniper documentation, MX series routers support
analyzers([edit forwarding-options analyzer]) since Junos OS Release
14.1 and one can mirror frames entering and exiting the port. However,
when I tested this with vMX running Junos 18.2R1.9, then I encountered
following problems/questions:

1) If the interface family is not bridge, then only the ingress
traffic is mirrored. Looks like this is the case with MX104 as well:
https://forums.juniper.net/t5/Routing/Analyzer-on-MX104/td-p/311718 In
short, am I correct that analyzer feature is dedicated to bridge
family only?

2) I built a following tiny test-setup:
https://i.imgur.com/ToyY31e.png Ports ge-0.0.7-vmx1 and ge-0-0.6-vmx1
are in the same broadcast domain, but in different Linux network
namespaces in order to force the traffic through vMX bridge. When the
analyzer configuration is inactive, then I can ping the 10.88.10.1(src
address is 10.88.10.2) without any issues. However, when the analyzer
configuration is activated:

root at vmx1> show configuration forwarding-options analyzer
test {
    input {
        ingress {
            interface ge-0/0/6.0;
        }
        egress {
            interface ge-0/0/6.0;
        }
    }
    output {
        interface ge-0/0/8.0;
    }
}

root at vmx1> show forwarding-options analyzer
  Analyzer name                    : test
  Mirror rate                      : 1
  Maximum packet length            : 0
  State                            : up
  Ingress monitored interfaces     : ge-0/0/6.0
  Egress monitored interfaces      : ge-0/0/6.0
  Output interface                 : ge-0/0/8.0

root at vmx1>

..and I make the packet capture on ge-0.0.7-vmx1 or
ge-0.0.8-vmx1(analyzer outgoing port for mirrored packets), then the
vMX seems to remove the EtherType field(0x0800) and the first 16 bits
of the IPv4 header starting from the second packet:

# tcpdump -nei ge-0.0.8-vmx1
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on ge-0.0.8-vmx1, link-type EN10MB (Ethernet), capture size
262144 bytes
13:31:42.068347 fe:06:0a:0e:ff:f7 > fe:06:0a:0e:ff:f6, ethertype IPv4
(0x0800), length 98: 10.88.10.2 > 10.88.10.1: ICMP echo request, id
14334, seq 1, length 64
13:31:42.068460 fe:06:0a:0e:ff:f6 > fe:06:0a:0e:ff:f7, ethertype IPv4
(0x0800), length 98: 10.88.10.1 > 10.88.10.2: ICMP echo reply, id
14334, seq 1, length 64
13:31:43.068240 fe:06:0a:0e:ff:f7 > fe:06:0a:0e:ff:f6, ethertype IPv4
(0x0800), length 98: 10.88.10.2 > 10.88.10.1: ICMP echo request, id
14334, seq 2, length 64
13:31:43.068419 fe:06:0a:0e:ff:f6 > fe:06:0a:0e:ff:f7, 802.3, length
84: LLC, dsap Unknown (0x50) Group, ssap Unknown (0x76) Response, ctrl
0x0000: Information, send seq 0, rcv seq 0, Flags [Response], length
80
        0x0000:  5177 0000 4001 0080 0a58 0a01 0a58 0a02  Qw.. at ....X...X..
        0x0010:  0000 dfd3 37fe 0002 9ff2 2d5c 0000 0000  ....7.....-\....
        0x0020:  5b0a 0100 0000 0000 1011 1213 1415 1617  [...............
        0x0030:  1819 1a1b 1c1d 1e1f 2021 2223 2425 2627  .........!"#$%&'
        0x0040:  2829 2a2b 2c2d 2e2f 3031 3233 3435 3637  ()*+,-./01234567
13:31:44.068247 fe:06:0a:0e:ff:f7 > fe:06:0a:0e:ff:f6, ethertype IPv4
(0x0800), length 98: 10.88.10.2 > 10.88.10.1: ICMP echo request, id
14334, seq 3, length 64
13:31:44.068291 fe:06:0a:0e:ff:f6 > fe:06:0a:0e:ff:f7, 802.3, length
84: LLC, dsap Unknown (0x54) Individual, ssap Unknown (0x46) Command,
ctrl 0x0000: Information, send seq 0, rcv seq 0, Flags [Command],
length 80
        0x0000:  5446 0000 4001 fdb0 0a58 0a01 0a58 0a02  TF.. at ....X...X..
        0x0010:  0000 dbd2 37fe 0003 a0f2 2d5c 0000 0000  ....7.....-\....
        0x0020:  5e0a 0100 0000 0000 1011 1213 1415 1617  ^...............
        0x0030:  1819 1a1b 1c1d 1e1f 2021 2223 2425 2627  .........!"#$%&'
        0x0040:  2829 2a2b 2c2d 2e2f 3031 3233 3435 3637  ()*+,-./01234567
^C
6 packets captured
6 packets received by filter
0 packets dropped by kernel
#

Output of the ping utility can be seen below:

$ ping -c10 10.88.10.1
PING 10.88.10.1 (10.88.10.1) 56(84) bytes of data.
64 bytes from 10.88.10.1: icmp_seq=1 ttl=64 time=0.167 ms

--- 10.88.10.1 ping statistics ---
10 packets transmitted, 1 received, 90% packet loss, time 8999ms
rtt min/avg/max/mdev = 0.167/0.167/0.167/0.000 ms
$

Has anyone seen this (bug) before? Once I commit the "delete
forwarding-options analyzer", then this odd behavior disappears.


3) If there is already a port-mirroring([edit forwarding-options
port-mirroring]) available for MX series, then why introduce another
tool? Or does analyzer do something which port-mirroring doesn't?


thanks,
Martin