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@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@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@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..@....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..@....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 _______________________________________________ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp