Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add an iptable rule to allow icmp for antrea-gw0 for NodeLatencyMonitor feature #6952

Open
luolanzone opened this issue Jan 24, 2025 · 3 comments
Assignees
Labels
kind/feature Categorizes issue or PR as related to a new feature.

Comments

@luolanzone
Copy link
Contributor

luolanzone commented Jan 24, 2025

Describe the problem/challenge you have

When I tried the NodeLatencyMonitor feature in a local testbed where the ICMP query is blocked by default, the feature will not work as expected because it relys on ICMP request to get the latency between Nodes.

Describe the solution you'd like

When I added an iptable rule 'iptables -A INPUT -p icmp --icmp-type echo-request -j ACCEPT' on the Node, the feature is back to normal.
We can add a new rule to limit it to antrea-gw0 only with iptables -A INPUT -i antrea-gw0 -p icmp --icmp-type echo-request -j ACCEPT from Antrea side to make the feature work when the Node ICMP is blocked by default.

@luolanzone luolanzone added the kind/feature Categorizes issue or PR as related to a new feature. label Jan 24, 2025
@Dhruv-J
Copy link
Contributor

Dhruv-J commented Feb 12, 2025

I was thinking there would be two workflows that we need to account for: one where the ICMP rule exists before the NodeLatencyMonitor is deployed, and the other for when the ICMP rule is applied after the NLM is already created. For the first case, I believe it would make the most sense to add the changes in the onNodeLatencyMonitorAdd() in pkg/agent/monitortool/monitor.go, where I would check if any ICMP rules exist, and add the iptable rule if they do. However, I had a question about the second workflow, as I see two possible ways of addressing the issue: Should I add a check in the NetworkPolicy controller that checks if an NLM exists whenever an ICMP rule is set? (that seems a bit messy for one edge case) My alternate solution was to add that iptable rule upon any invocation of onNodeLatencyMonitorAdd(). This seems a bit redundant if no ICMP rules are applied, but would allow for easier case handling in my opinion? I might be mistaken though, so what do you think @luolanzone ?

@luolanzone
Copy link
Contributor Author

Hi @Dhruv-J Since we will only allow the ICMP for antrea specific interface antrea-gw0, I feel it should be OK to add it as long as the NodeLatencyMonitor feature is enabled.

@antoninbas @tnqn what's your suggestion?

@antoninbas
Copy link
Contributor

In policyOnlyMode, we use the Node's transport IP for the ICMP probes:

func (s *LatencyStore) getNodeIPs(node *corev1.Node) ([]net.IP, error) {

So based on the mode, we could either use antrea-gw0 or the transport interface - assuming we want to filter based on the interface which sounds reasonable to me?

BTW, should we add an output filter rule as well for the sake of completeness?

I synced up with @Dhruv-J today - I think most of the changes should be in pkg/agent/route/.

Dhruv-J added a commit to Dhruv-J/antrea that referenced this issue Feb 20, 2025
This PR provides the solution to an edge case with NodeLatencyMonitor, where
the feature does not work if ICMP queries are blocked by default. To fix this,
an iptable rule will be added if NodeLatencyMonitor is enabled, such that ICMP
requests via the Antrea gateway will be allowed.

Fixes issue antrea-io#6952

Signed-off-by: Dhruv-J <dhruvj@vmware.com>
Dhruv-J added a commit to Dhruv-J/antrea that referenced this issue Feb 20, 2025
This PR provides the solution to an edge case with NodeLatencyMonitor, where
the feature does not work if ICMP queries are blocked by default. To fix this,
an iptable rule will be added if NodeLatencyMonitor is enabled, such that ICMP
requests via the Antrea gateway will be allowed.

Fixes issue antrea-io#6952

Signed-off-by: Dhruv-J <dhruvj@vmware.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
kind/feature Categorizes issue or PR as related to a new feature.
Projects
None yet
Development

No branches or pull requests

3 participants