This article describes scenarios when duplicate Internet Control Message Protocol (ICMP) messages may be seen during a ping across the same interface/VLAN configured for two different subnets, or from a primary IP address to a secondary IP address in the same virtual local area network (VLAN).
This issue applies to EX platforms with Marvel ASICs, EX2200, EX3200, EX3300, EX4200, EX4500, EX4550, EX6200, EX8200, and so on.
[Test 1] RVI interface
vlan.10 vlan.10 192.168.0.254/24 vlan.10 192.168.0.1/24 172.16.0.254/24 172.16.0.1/24 EX4200-1-----------EX4200-3-----------EX4200-2
As the topology shows, two different segment IP addresses are being configured on vlan.10 of EX4200-3.
root@EX4200-3# show interfaces vlan unit 10 { family inet { address 192.168.0.254/24; address 172.16.0.254/24;
A duplicate ping message is seen when pinging from 192.168.0.1 to 172.16.0.1.
root# run ping 172.16.0.1 PING 172.16.0.1 (172.16.0.1): 56 data bytes 64 bytes from 172.16.0.1: icmp_seq=0 ttl=63 time=2.961 ms 64 bytes from 172.16.0.1: icmp_seq=0 ttl=63 time=3.334 ms (DUP!) 64 bytes from 172.16.0.1: icmp_seq=1 ttl=63 time=1.885 ms 64 bytes from 172.16.0.1: icmp_seq=1 ttl=63 time=3.052 ms (DUP!) 64 bytes from 172.16.0.1: icmp_seq=2 ttl=63 time=1.798 ms 64 bytes from 172.16.0.1: icmp_seq=2 ttl=63 time=3.024 ms (DUP!)
[Test 2] Physical L3 interface
192.168.0.1/24 192.168.0.254/24 172.16.0.254/24 TEST-------EX4200-3-----------ge-0/0/23 EX4200-1 | | | TEST2 172.16.0.1/24
As the topology shows, two different segment IP addresses are being configured on ge-0/0/23 of EX4200-1.
root@EX4200-3# show interfaces ge-0/0/23 unit 0 { family inet { address 192.168.0.254/24; address 172.16.0.254/24;
root# run ping 172.16.0.1 PING 172.16.0.1 (172.16.0.1): 56 data bytes 64 bytes from 172.16.0.1: icmp_seq=0 ttl=63 time=2.852 ms 64 bytes from 172.16.0.1: icmp_seq=0 ttl=63 time=3.134 ms (DUP!) 64 bytes from 172.16.0.1: icmp_seq=1 ttl=63 time=2.885 ms 64 bytes from 172.16.0.1: icmp_seq=1 ttl=63 time=1.052 ms (DUP!) 64 bytes from 172.16.0.1: icmp_seq=2 ttl=63 time=2.428 ms 64 bytes from 172.16.0.1: icmp_seq=2 ttl=63 time=1.042 ms (DUP!)
When executing monitor traffic interface ge-0/0/23, ping packets are seen, which means these packets were sent to the CPU.
monitor traffic interface ge-0/0/23,
> monitor traffic interface ge-0/0/23 verbose output suppressed, use <detail> or <extensive> for full protocol decode Address resolution is ON. Use <no-resolve> to avoid any reverse lookup delay. Address resolution timeout is 4s. Listening on ge-0/0/23, capture size 96 bytes -snip- 04:53:27.149542 In IP truncated-ip - 24 bytes missing! 192.168.0.1 > 172.16.0.1: ICMP echo request, id 31940, seq 0, length 64 04:53:27.149591 Out IP truncated-ip - 24 bytes missing! 192.168.0.1 > 172.16.0.1: ICMP echo request, id 31940, seq 0, length 64 04:53:28.152827 In IP truncated-ip - 24 bytes missing! 192.168.0.1 > 172.16.0.1: ICMP echo request, id 31940, seq 1, length 64 04:53:28.152878 Out IP truncated-ip - 24 bytes missing! 192.168.0.1 > 172.16.0.1: ICMP echo request, id 31940, seq 1, length 64 04:53:29.154795 In IP truncated-ip - 24 bytes missing! 192.168.0.1 > 172.16.0.1: ICMP echo request, id 31940, seq 2, length 64 04:53:29.154845 Out IP truncated-ip - 24 bytes missing! 192.168.0.1 > 172.16.0.1: ICMP echo request, id 31940, seq 2, length 64
These packets should not be sent to the CPU. However, due to the Packet Forwarding Engine (PFE) limitation, the packets were mirrored for ICMP redirect and sent to the Routing Engine.
Here the Routing Engine (RE) is forwarding the packet based on an available route. Thus, a duplicate message is seen.
The issue is not seen when the ping is initiated with a VLAN, and the source and destination IP addresses are in the same VLAN/subnet.
Example: Pinging from 192.168.0.10 to 192.168.0.20 is not a problem.
The issue is not seen when the ping is initiated from one VLAN to another VLAN.
Example: host in v10 and host in v20
The issue is seen when different subnets are located under the same VLAN or interface.
The issue is seen when the ping is initiated from the primary IP address to the secondary IP address in the same VLAN.
As a workaround, we recommend having a separate Routed VLAN Interface (RVI) configuration for the second subnet.
2020-11-18: Article reviewed for accuracy; since it is an old article, clarification added in the Summary advising that this issue applies to Marvel ASIC switches
2022-09-21: Updated non-compliant IP addresses to RFC standards