Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

Enable IP Fabric Forwarding and Fabric Source NAT

This topic shows you how to enable IP fabric forwarding and fabric source NAT in Kubernetes-orchestrated environments using Juniper Networks' Cloud-Native Contrail® Networking™ Release 22.1 or later.

Cloud-Native Contrail Networking supports IP fabric forwarding and fabric source NAT. With IP fabric forwarding, clusters running in the overlay network access the underlay network through the external virtual network. Fabric source NAT enables a gateway device in a fabric to translate the source IP address of data plane node traffic exiting the fabric into a public-side IP address.

You can use IP fabric forwarding and fabric source NAT in cloud-networking environments to provide access to the underlay network. This underlay network access does not add significant network complexity like other underlay network options, such as complex BGP topologies or firewall setups.

The underlay network access enables resources within pods to directly access the Internet or to pull external artifacts from the underlay network.

Overview: IP Fabric Forwarding

Starting in Release 22.1, Cloud-Native Contrail supports IP fabric forwarding in Kubernetes environments.

You enable IP fabric forwarding within virtual networks that have access to the external network. These virtual networks require direct access to the underlay network.

A virtual network that has access to the external network is named the default-externalnetwork by default. You can create a customized user-defined external network name, if you choose. When you enable IP fabric forwarding, the path to the underlay network is directly available to clusters running in the overlay network through this external virtual network. This direct connection between the overlay network and the underlay network gives hosts in the overlay network access to the underlay network. Because IP fabric forwarding enables a virtual network to span both the overlay network and the underlay network, data packets traversing the two networks are not encapsulated and de-encapsulated. Packet processing, therefore, is more efficient.

IP fabric forwarding is also extremely useful for load balancing network traffic. A LoadBalancer service automatically detects any external virtual network that has enabled IP fabric forwarding when load-balancing external network traffic.

Overview: Fabric Source NAT

Starting in Release 22.1, Cloud-Native Contrail supports fabric source NAT in Kubernetes environments. Fabric source NAT provides a method for traffic from a data plane node in a Kubernetes environment to directly access the Internet without traversing a separate NAT firewall. You can also use source NAT to pull external artifacts into pods when needed.

Traffic from data plane nodes destined for the Internet must traverse a gateway device. This gateway device is a member device in the fabric that also has at least one interface connected to the public network. When you enable fabric source NAT , the gateway device translates the source IP address of the originating packet from the data plane node into its own public side IP address. This address translation allows traffic from the data plane node to access the Internet.

The IP address translation that source NAT performs also updates the source port in the packet. Multiple data plane nodes can reach the public network through a single gateway public IP address using fabric source NAT.

You need fabric source NAT to translate the IP addresses of traffic exiting the fabric to the Internet. You are not using NAT to translate incoming traffic with this feature.

Example: Configure Fabric Source NAT

Fabric source NAT is disabled by default in user-created virtual networks.

You can enable fabric source NAT manually in any individual virtual network by setting the fabricsource NAT: variable in the VirtualNetwork object to true. You can disable fabric source NAT by setting this value to false.

Following is an example of a virtual network object that has enabled fabric source NAT:

You can also configure your environment to enable fabric source NAT in any user-created virtual network when the virtual network is created. If you want to enable fabric source NAT in any user-created virtual network upon creation, set the enablesource NAT variable in the ApiServer resource to true when initially deploying your environment.

You must set this configuration in the ApiServer resource during initial deployment. You cannot change this setting in your environment after you apply the deployment YAML file. If you want to change the fabric source NAT setting for an individual virtual network after initial deployment, you must change the configuration manually for that network.

Following is a representative YAML file configuration:

Fabric source NAT is enabled in any user-created virtual network upon creation when the enablesource NAT variable is true. You can disable fabric source NAT when user-created virtual networks are created by setting the enablesource NAT variable to false. Fabric source NAT is disabled by default.

Fabric source NAT automatically selects the IP addresses for translation. You do not need to configure address pools for fabric source NAT in most Cloud-Native Contrail Networking use cases. Address pools are configurable, however, using the portTranslationPools: hierarchy within the GlobalVrouterConfig resource.

Example: Configure External Networks with IP Fabric Forwarding

IP fabric forwarding is disabled by default.

You can enable IP fabric forwarding in any virtual network by setting the fabricForwarding: variable in the v4SubnetReference: or v6SubnetReference: hierarchies to true.

Following is an example of how to enable IP fabric forwarding in an external virtual network that accesses the Internet through an IPv4 gateway:

You can also enable IP fabric forwarding while creating the external virtual network that has a path to the Internet.

You configure a virtual network's path to an external network through the Kubemanager resource in environments using Contrail Networking.

You enable external access for a virtual network by connecting the virtual network to an IPv4 or IPv6 gateway IP subnet address. You enable IP fabric forwarding for the external traffic in the virtual network using the same Kubemanager resource.

Note:

You must configure the external network subnets and this IP fabric forwarding setting during the initial Cloud-Native Contrail deployment. You cannot configure these parameters after the initial deployment YAML file is applied.

The following example shows a YAML file used to configure a Kubemanager resource that creates a virtual network with external network access. The virtual network in this example runs with IP fabric forwarding. You would have to commit this YAML file during initial deployment.

You specify the IPv4 subnet or the IPv6 subnet of the external network using the externalNetworkV4Subnet or externalNetworkV6Subnet: variable in this YAML file. The subnet address is a public-side IP address that is reachable from the Internet through the gateway device. When you configure a Kubemanager resource using this YAML file, a new virtual network to the specified external network is created. This virtual network is named default-externalnetwork in the default namespace for Contrail Networking.

IP fabric forwarding runs in the virtual network with external network access when the ipFabricFowardingExtSvc variable is true. You can disable IP fabric forwarding for the external subnet by setting the ipFabricFowardingExtSvc variable to false.