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.

Sign up for GitHub

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

Document double nat scenario for OpenStack deployments #806

Merged
merged 2 commits into from
Jul 27, 2022
Merged

Document double nat scenario for OpenStack deployments #806

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
679604c
Document double nat scenario for OpenStack deployments
sridhargaddam Jul 25, 2022
d786200
Merge branch 'devel' into issue-805
dfarrell07 Jul 26, 2022
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
24 changes: 22 additions & 2 deletions src/content/operations/nat-traversal/_index.en.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -356,9 +356,29 @@ NAT, or if other applications on the internal network were already using the 450
ports, the remote ends would not be able to contact gateway C or D over the expected ports.
{{% /notice %}}

### Double NAT Traversal
### Double NAT Traversal (scenario 1)

In this case case, A & B cluster gateways have direct reachability over their private
In this case, clusters C & D are neither reachable on their private IPs (192.168.0.4 and 192.168.0.4) nor
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Shouldn't it be 192.168.128.4 ?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why? The diagram uses 192.168.0.4

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Private IPs are the node-ips. As per the diagram its 192.168.0.4 (deliberately shown the same IPs as its possible in such deployments) and the private floating-ips are 10.2.0.1 and 10.2.0.2 respectively. The public-ip auto-discovery for such clusters would be the same for both (2.1.1.1).

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ooops, I missed the diagram

on the public IP. However, they are reachable over the private floating IPs (10.2.0.1 and 10.2.0.2).
Submariner cannot detect these private floating IPs. To get the connectivity working, you can annotate
the Gateway node with the private floating IP as shown below.

![on-premises](/images/natt/double_nat_scenario1.png)

```bash
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Q : the annotated public IP (e.g: 10.2.0.1) will be used as EP's public IP for all connections (including to clusters C,D) , can you elaborate how the connection from cluster A to C will work ?

Copy link
Member Author

@sridhargaddam sridhargaddam Jul 27, 2022 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There is no Cluster A in this topology. Please look at the next scenario and it is currently not supported in Submariner.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ack, 10x

kubectl annotate node $GWC gateway.submariner.io/public-ip=ipv4:10.2.0.1
kubectl annotate node $GWD gateway.submariner.io/public-ip=ipv4:10.2.0.2

# restart the gateways to pick up the new setting
for cluster in C D;
do
kubectl delete pod -n submariner-operator -l app=submariner-gateway --kubeconfig $cluster
done
```

### Double NAT Traversal (scenario 2)
sridhargaddam marked this conversation as resolved.
Show resolved Hide resolved

In this case, A & B cluster gateways have direct reachability over their private
IPs (10.0.0.1 and 10.1.0.1) possibly with large MTU capabilities, while between cluster
C and D (192.168.0.4 and 192.168.0.4 too), reachability over the private IPs is not possible
sridhargaddam marked this conversation as resolved.
Show resolved Hide resolved
but it would be possible over the private floating IPs 10.2.0.1 and 10.2.0.2. However Submariner
Expand Down
Binary file added src/static/images/natt/double_nat_scenario1.png
View file
Open in desktop
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.