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

Set an LB VIP address in the 'egressIP' of the "Egress" CRD #2671

Closed
eranshpiner opened this issue Aug 28, 2021 · 4 comments
Closed

Set an LB VIP address in the 'egressIP' of the "Egress" CRD #2671

eranshpiner opened this issue Aug 28, 2021 · 4 comments
Labels
lifecycle/stale Denotes an issue or PR has remained open with no activity and has become stale.

Comments

@eranshpiner
Copy link

eranshpiner commented Aug 28, 2021

Hello,

In the 'egressIP' field of the "Egress" CRD, can I specify an IP of an LB VIP ? Meaning an IP address which is NOT assigned to any of the nodes in cluster ? .... Similar to the use-case described in the discussion of this issue, my requirement is to SNAT all egress UDP traffic from certain pods, setting the LB VIP as the source IP of these UDP packets.

Is this possible?

Thanks,
Eran.

BTW - Is it possible to specify to SNAT only UDP egress traffic (and not TCP) ?

@antoninbas
Copy link
Contributor

Could you clarify your use case? If you SNAT Pod traffic and set the source IP to the LB VIP, how will reply traffic be handled?

I don't think the issue you referred to (#2128) covers a similar use case. Some of the discussions for that issue mention LB VIP allocation, but it seems pretty orthogonal to your use case.

If you define an Egress resource and set spec.EgressIP to your VIP, Antrea will encapsulate your traffic (by default, with Geneve) and try to tunnel it to the VIP. The assumption being that whichever host is assigned the VIP will be responsible for performing SNAT. Normally, this is a cluster Node running Antrea, and the antrea-agent will decapsulate the traffic and perform SNAT. So no, unless you have a host somewhere, which is reachable via the VIP, can decapsulate packets, and can perform SNAT, the use case you describe will not work.

Adding @tnqn since he is the expert for this feature.

BTW - Is it possible to specify to SNAT only UDP egress traffic (and not TCP) ?

That's an interesting proposal. I can't think of a use case for this, but if you do have one, feel free to open a separate issue to discuss it. On the implementation side, I believe it would be pretty straightforward to do.

@tnqn
Copy link
Member

tnqn commented Sep 2, 2021

This will depend on the type of the LB. If you are using external LB, I assume you mean every Node just SNAT its local Pods directly with same LB VIP, then there will be a problem for the return traffic as @antoninbas mentioned.
If you are using in-cluster LB and the LB VIP is configured on a Node physically, I think it can work if you just specify LB VIP as Egress IP.

Is it possible to specify to SNAT only UDP egress traffic (and not TCP) ?

This is possible, and recently I heard another similar requirement from @leonstack that he wants traffic to an IPBlock not to be SNATed as the destination is actually in-cluster (Nodes' other IPs) but we couldn't auto-discover it easily. We discussed a way that adds a except field to Egress which can exclude specific egress traffic from being SNATed. If except can match both destination IP and protocol, I think it would satisfy both use cases. @leonstack may create an issue soon and contribute this enhancement.

@tnqn
Copy link
Member

tnqn commented Sep 2, 2021

Just found the issue is already created: #2707

@github-actions
Copy link
Contributor

This issue is stale because it has been open 90 days with no activity. Remove stale label or comment, or this will be closed in 90 days

@github-actions github-actions bot added the lifecycle/stale Denotes an issue or PR has remained open with no activity and has become stale. label Dec 17, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
lifecycle/stale Denotes an issue or PR has remained open with no activity and has become stale.
Projects
None yet
Development

No branches or pull requests

3 participants