Skip to content

[dualtor] Disable running icmp_responder at session-level#9117

Merged
lolyu merged 1 commit intosonic-net:masterfrom
lolyu:disable_run_icmp_responder_session_level
Jul 26, 2023
Merged

[dualtor] Disable running icmp_responder at session-level#9117
lolyu merged 1 commit intosonic-net:masterfrom
lolyu:disable_run_icmp_responder_session_level

Conversation

@lolyu
Copy link
Copy Markdown
Collaborator

@lolyu lolyu commented Jul 26, 2023

Description of PR

Summary:
Fixes # (issue)

Type of change

  • Bug fix
  • Testbed and Framework(new/improvement)
  • Test case(new/improvement)

Back port request

  • 201911
  • 202012
  • 202205

Approach

What is the motivation for this PR?

Disable running icmp_responder at session level.
The reason is that enabling icmp_responder at the session level could cause some T0 testcase failures as the ICMP replies pollute the FDB table.

For example:
Port Ethernet4, mux server IP 192.168.0.2, connected to ptf port eth1 that has mac A.
Port Ethernet40, connected to ptf port eth10 that has mac B.

Some T0 testcases configure 192.168.0.2 IP on ptf port eth10, DUTs will learn the arp as 192.168.0.2 with mac B on port Ethernet40. After linkmgrd learns the arp, it will send heartbeats to 192.168.0.2 with dest mac as B on Ethernet4. As the icmp_responder is running, DUT will receive heartbeat replies with source IP 192.168.0.2 and source mac B on Ethernet4.
So DUT will learn mac B on Ethernet4, the arp entry of 192.168.0.2 will be: mac B on port Ethernet40.
In this case, the following I/O verification will fail.

Signed-off-by: Longxiang Lyu lolv@microsoft.com

How did you do it?

How did you verify/test it?

Any platform specific information?

Supported testbed topology if it's a new test case?

Documentation

Signed-off-by: Longxiang Lyu <lolv@microsoft.com>
@mssonicbld
Copy link
Copy Markdown
Collaborator

Cherry-pick PR to 202205: #9120

mssonicbld pushed a commit to mssonicbld/sonic-mgmt that referenced this pull request Jul 26, 2023
…t#9117)

Approach
What is the motivation for this PR?
Disable running icmp_responder at session level.
The reason is that enabling icmp_responder at the session level could cause some T0 testcase failures as the ICMP replies pollute the FDB table.

For example:
Port Ethernet4, mux server IP 192.168.0.2, connected to ptf port eth1 that has mac A.
Port Ethernet40, connected to ptf port eth10 that has mac B.

Some T0 testcases configure 192.168.0.2 IP on ptf port eth10, DUTs will learn the arp as 192.168.0.2 with mac B on port Ethernet40. After linkmgrd learns the arp, it will send heartbeats to 192.168.0.2 with dest mac as B on Ethernet4. As the icmp_responder is running, DUT will receive heartbeat replies with source IP 192.168.0.2 and source mac B on Ethernet4.
So DUT will learn mac B on Ethernet4, the arp entry of 192.168.0.2 will be: mac B on port Ethernet40.
In this case, the following I/O verification will fail.

Signed-off-by: Longxiang Lyu lolv@microsoft.com

How did you do it?
How did you verify/test it?
mssonicbld pushed a commit that referenced this pull request Jul 26, 2023
Approach
What is the motivation for this PR?
Disable running icmp_responder at session level.
The reason is that enabling icmp_responder at the session level could cause some T0 testcase failures as the ICMP replies pollute the FDB table.

For example:
Port Ethernet4, mux server IP 192.168.0.2, connected to ptf port eth1 that has mac A.
Port Ethernet40, connected to ptf port eth10 that has mac B.

Some T0 testcases configure 192.168.0.2 IP on ptf port eth10, DUTs will learn the arp as 192.168.0.2 with mac B on port Ethernet40. After linkmgrd learns the arp, it will send heartbeats to 192.168.0.2 with dest mac as B on Ethernet4. As the icmp_responder is running, DUT will receive heartbeat replies with source IP 192.168.0.2 and source mac B on Ethernet4.
So DUT will learn mac B on Ethernet4, the arp entry of 192.168.0.2 will be: mac B on port Ethernet40.
In this case, the following I/O verification will fail.

Signed-off-by: Longxiang Lyu lolv@microsoft.com

How did you do it?
How did you verify/test it?
AharonMalkin pushed a commit to AharonMalkin/sonic-mgmt that referenced this pull request Jan 25, 2024
…t#9117)

Approach
What is the motivation for this PR?
Disable running icmp_responder at session level.
The reason is that enabling icmp_responder at the session level could cause some T0 testcase failures as the ICMP replies pollute the FDB table.

For example:
Port Ethernet4, mux server IP 192.168.0.2, connected to ptf port eth1 that has mac A.
Port Ethernet40, connected to ptf port eth10 that has mac B.

Some T0 testcases configure 192.168.0.2 IP on ptf port eth10, DUTs will learn the arp as 192.168.0.2 with mac B on port Ethernet40. After linkmgrd learns the arp, it will send heartbeats to 192.168.0.2 with dest mac as B on Ethernet4. As the icmp_responder is running, DUT will receive heartbeat replies with source IP 192.168.0.2 and source mac B on Ethernet4.
So DUT will learn mac B on Ethernet4, the arp entry of 192.168.0.2 will be: mac B on port Ethernet40.
In this case, the following I/O verification will fail.

Signed-off-by: Longxiang Lyu lolv@microsoft.com

How did you do it?
How did you verify/test it?
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants