This article describes scenarios when duplicate ICMP messages may be seen during a ping across the same interface/VLAN configured for two different subnets, or from a primary IP to secondary IP in the same 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 10.1.1.254/24 vlan.10
10.1.1.1/24 20.1.1.254/24 20.1.1.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 10.1.1.254/24;
address 20.1.1.254/24;
-----------
Ping duplicate message will be seen when pinging from 10.1.1.1 to 20.1.1.1.
----------------------------------
root# run ping 20.1.1.1
PING 20.1.1.1 (20.1.1.1): 56 data bytes
64 bytes from 20.1.1.1: icmp_seq=0 ttl=63 time=2.961 ms
64 bytes from 20.1.1.1: icmp_seq=0 ttl=63 time=3.334 ms (DUP!)
64 bytes from 20.1.1.1: icmp_seq=1 ttl=63 time=1.885 ms
64 bytes from 20.1.1.1: icmp_seq=1 ttl=63 time=3.052 ms (DUP!)
64 bytes from 20.1.1.1: icmp_seq=2 ttl=63 time=1.798 ms
64 bytes from 20.1.1.1: icmp_seq=2 ttl=63 time=3.024 ms (DUP!)
----------------------------------
[Test 2] Physical L3 interface
1.1.1.1/24 1.1.1.254/24
2.2.2.254/24
TEST-------EX4200-3-----------ge-0/0/23 EX4200-1
|
|
|
TEST2
2.2.2.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 1.1.1.254/24;
address 2.2.2.254/24;
-----------
Ping duplicate message will be seen when pinging from 1.1.1.1 to 2.2.2.1.
----------------------------------
root# run ping 2.2.2.1
PING 2.2.2.1 (2.2.2.1): 56 data bytes
64 bytes from 2.2.2.1: icmp_seq=0 ttl=63 time=2.852 ms
64 bytes from 2.2.2.1: icmp_seq=0 ttl=63 time=3.134 ms (DUP!)
64 bytes from 2.2.2.1: icmp_seq=1 ttl=63 time=2.885 ms
64 bytes from 2.2.2.1: icmp_seq=1 ttl=63 time=1.052 ms (DUP!)
64 bytes from 2.2.2.1: icmp_seq=2 ttl=63 time=2.428 ms
64 bytes from 2.2.2.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
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! 1.1.1.1 > 2.2.2.1: ICMP echo request, id 31940, seq 0, length 64
04:53:27.149591 Out IP truncated-ip - 24 bytes missing! 1.1.1.1 > 2.2.2.1: ICMP echo request, id 31940, seq 0, length 64
04:53:28.152827 In IP truncated-ip - 24 bytes missing! 1.1.1.1 > 2.2.2.1: ICMP echo request, id 31940, seq 1, length 64
04:53:28.152878 Out IP truncated-ip - 24 bytes missing! 1.1.1.1 > 2.2.2.1: ICMP echo request, id 31940, seq 1, length 64
04:53:29.154795 In IP truncated-ip - 24 bytes missing! 1.1.1.1 > 2.2.2.1: ICMP echo request, id 31940, seq 2, length 64
04:53:29.154845 Out IP truncated-ip - 24 bytes missing! 1.1.1.1 > 2.2.2.1: ICMP echo request, id 31940, seq 2, length 64
------------------------------------
These packets should not be sent to the CPU. However, due to PFE limitation, the packets were mirrored for ICMP redirect and sent to RE.
Here, RE is forwarding the packet based on an available route. Thus, a duplicate message is seen.
-
The issue is not seen when ping is initiated with a VLAN, SIP and DIP in the same VLAN/subnet
Example: Pinging from 192.168.100.10 to 192.168.100.20 is not a problem.
-
The issue is not seen when 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 ping is initiated from the primary IP to the secondary IP in the same VLAN.
The recommended workaround is to have 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