Implement Tanzu on private networks with VyOS
Tags: vmware, linux, kubernetes
Published: 2021-01-05 13:24:44

---
title: Implement Tanzu on private networks with VyOS
published: true
date: 2021-01-04 08:00:00 UTC
tags: #vmware #linux #kubernetes
canonical_url: https://storage-chaos.io/tanzu-vyos.html
---

# TL; DR

With a virtual router (here [VyOS](https://vyos.io/)), and proper routing table, it is possible to implement [VMware Tanzu](https://docs.vmware.com/en/VMware-Tanzu-Kubernetes-Grid/1.0/vmware-tanzu-kubernetes-grid-10/GUID-tanzu-k8s-clusters-create.html) on private networks without NSX-T.

# The premise

I needed to evaluate VMware Tanzu basic capabilities with [CSI driver for PowerScale](https://github.com/dell/csi-powerscale). To install Tanzu, also named Workload Management in vCenter, I followed that [video](https://www.youtube.com/watch?v=XjCbIHlaMR4) and these [1](https://cormachogan.com/2020/09/25/deploy-ha-proxy-for-vsphere-with-tanzu/), [2](https://cormachogan.com/2020/09/28/enabling-vsphere-with-tanzu-using-ha-proxy/), [3](https://cormachogan.com/2020/09/29/deploying-tanzu-kubernetes-guest-cluster-in-vsphere-with-tanzu/) posts.

As a prerequisite, Tanzu needs two networks at least, one for the management cluster (also named Supervisor cluster) and one for the workload (i.e. the on-demand clusters to run workload).

In my lab, I only have one routable VLAN on the network with limited IPs. For other activities, like [Anthos validation](/anthos-baremetal-1.0.html), I use a single private network behind a NAT ; unfortunately that configuration is not enough here.

For Tanzu, I decided to use three networks:

- The frontend network (`10.247.247.0/24`), which is routable to the external world and will have the Load-Balancer VIP
- The management network (`10.0.0.0/24`), for the vSphere management of the supervisor cluster
- The workload network (`10.0.1.0/24`), to host all Tanzu clusters

![Architecture](http://0.0.0.0:4321/assets/img/tanzu/vmware-dswitch.png)

The problem is, I do not have an NSX-T license to manage these private networks. Luckily for us, once again Linux is here to save the day.

# The implementation

The trick here is to use a virtual machine that will act as a router for the different networks. My choice went to [VyOS](https://vyos.io/products/#vyos-platform), a Debian-base distro design for routing. It can be used as a firewall, VPN, do QoS, etc. The configuration is done with commands similar to what you can have with Cisco IOS or other proprietary networking devices.

In this case, I use only the routing and NAT features. For free, VyOS will route between the connected interface, so after the NICs configuration I just had to configure the NAT for my two private networks.

The final configuration is pretty much:

<noscript><pre>400: Invalid request</pre></noscript><script src="https://gist.github.com/baf97ca912d46f6e55a6379088297b8f.js?file=config.boot"> </script>

With that configuration:

- any VMs deployed with Tanzu can connect to the external world through the NAT via the Dell LAN segment
- any VMs with a single NIC can talk to the same segment via the DSwitch or to the other network via the VyOS VM

## Ping issue

Tanzu explicitly states that Supervisor and Workload clusters must be able to connect to the HA Proxy data plane.

On my setup I used [VMware HA Proxy](https://github.com/haproxytech/vmware-haproxy) and deployed the image with three networks. The Data plane API management listens on the Management network and default port of 5556.

Supervisor cluster deployment went well but during the workload cluster creation I got the following error:

```
unexpected error while reconciling control plane endpoint for my-cluster: failed to reconcile loadbalanced endpoint for WCPCluster csi/my-cluster: failed to get control plane endpoint for Cluster csi/my-cluster: Virtual Machine Service LB does not yet have VIP assigned: VirtualMachine Service LoadBalancer does not have any Ingresses

```

As a matter of fact I could :

- ping any IPs from the Load-Balancer
- ping the Load-Balancer IP from a node on the same network
- ping any IP Supervisor IP from the workload node and the other way around
- but I could not ping a Management proxy IP which from a workload node

The problem here the ICMP echo requests goes though the router but the response is issued directly on the DSwitch : ![Ping error](http://0.0.0.0:4321/assets/img/tanzu/tanzu_ping_error.png)

To solve that, the trick is to make sure all the request to HAProxy are answered through the router. To do so there are three things to do :

- Set the workload IP with a `/32` mask to force to use this communication for this device only in : `/etc/systemd/network/10-workload.network`
- Update the gateway of the Management NIC to for the two networks management & workload in : `/etc/systemd/network/10-management.network`
- Add a default route for the external work with a higher weight in : `/etc/systemd/network/10-frontend.network`

Below are the NICs configuration you can edit then apply with a `systemctl restart systemd-networkd`

<noscript><pre>400: Invalid request</pre></noscript><script src="https://gist.github.com/baf97ca912d46f6e55a6379088297b8f.js?file=10-workload.network"> </script><noscript><pre>400: Invalid request</pre></noscript><script src="https://gist.github.com/baf97ca912d46f6e55a6379088297b8f.js?file=10-management.network"> </script><noscript><pre>400: Invalid request</pre></noscript><script src="https://gist.github.com/baf97ca912d46f6e55a6379088297b8f.js?file=10-frontend.network"> </script>

Now the ICMP echo reply goes through the same route and responds : ![Ping success](http://0.0.0.0:4321/assets/img/tanzu/tanzu_ping.png)

# Conclusion

For basic features (like NAT, static or dynamic routing, NAT, DHCP, Firewall, etc.) VyOS is an excellent virtual router that can get you a long way if, like me, you miss NSX-T license.