Shulou(Shulou.com)06/01 Report--

Hi! This is the ninth article on Tungsten Fabric architecture parsing, which describes how TF connects to physical networks.

A series of articles on Tungsten Fabric architecture analysis, presented to you by the TF Chinese community, are designed to help new entrants to the TF community to answer questions. We will systematically introduce the features of TF, how it works, how to collect / analyze / deploy, how to orchestrate, how to connect to physical networks, and so on.

In any data center, some VM is required to access external IP addresses, and users outside the data center also need to access some VM through public IP addresses. To do this, Tungsten Fabric provides several implementation methods:

V P N connects to the local gateway under the underlay structure in the source address NATvRouter in the BGP-enabled gateway vRouter

Each method is suitable for different use cases and has different dependencies on the configuration of external devices and networks.

These methods of connecting to external networks are described below.

BGP-enabled gateway

One way to achieve external connectivity is to create a virtual network with a series of externally routable IP addresses and extend the network to the gateway router. When the gateway router is a Juniper MX router, the configuration on the device can be done automatically by Tungsten Fabric, as shown in the following figure.

Define network An in Tungsten Fabric, which contains subnets with publicly addressable IP addresses. This public virtual network is configured in Tungsten Fabric to extend to the gateway router, and when Tungsten Fabric Device Manager is used, a VRF is automatically created on the gateway, and the route destination matches the path destination of the virtual network (for example, VRF labeled VR).

Tungsten Fabric configures this VRF with a default route, which causes the route of traffic from the Tungsten Fabric cluster to the Internet to be found in the main inet.0 routing table, which contains routes to common destinations in the VRF. Through the forwarding filter, traffic reaching the destination in Gateway A can be found in the VRF created by Tungsten Fabric. The router advertises the default route to the Tungsten Fabric controller through VRF.

Network An is configured as a pool of floating IP addresses in Tungsten Fabric, and when such an address is assigned to an existing VM interface, an additional VRF is created in the vRouter of VM (for example, for network A), and the interface connects to the new public VRF in addition to the original VRF (green or red in the figure). The VRF of the Floating IP address performs a 1:1 NAT between the floating IP address and the IP address configured on the VM.

VM is not aware of this additional connection and continues to send and receive traffic using the address of the original virtual network received through DHCP. VRouter advertises the floating IP address to the controller's route, and the route is sent to the gateway via BGP and installed in a public VRF, such as VRF A.

The Tungsten Fabric controller sends a default route to vRouter through VRF on the physical router and installs it in the public VRF of vRouter.

As a result of these actions, the public VRF on vRouters contains a route to the floating IP address through the local interface of VM, as well as a default route through VRF on the router. The VRF on the gateway has a default route through the inet.0 routing table (implemented using filter-based forwarding) and a host route to each assigned floating IP address. The inet.0 routing table has routes to each floating IP network through the corresponding VRF.

When tenants have their own public IP address range, multiple independent public subnets can be used as separate floating IP address pools with their own VRF (as shown in the figure), and conversely, a floating IP address pool can also be shared among multiple tenants (not shown in the figure).

If you use non-Juniper devices, or if you do not allow Tungsten Fabric to make configuration changes on the gateway, you can set up BGP sessions, public network prefixes, and static routes on the gateway either manually or through the configuration tool. Use this method when the router combines the provider Edge (PE) router role of the enterprise V P N with the data center gateway role.

Typically in this case, the VRF will be created by the V P N management system. When a matching routing target is configured in the virtual network, the virtual network in the Tungsten Fabric cluster connects to the enterprise V P N and exchanges routes between the controller and the gateway / PE.

Source address NAT

Tungsten Fabric enables the network to connect through a source-based NAT service that allows multiple VM or containers to share the same external IP address. In each vRouter, the source NAT is implemented as a distributed service.

The next hop of traffic sent from VM to Internet will be the SNAT service in the same vRouter, which will be the gateway forwarded to the underlay network without encapsulation, its source address will be modified to the address of the vRouter host, and the source port will be set according to the specific sending VM. VRouter uses the destination port to return packets to map back to the original VM.

This option is useful for providing Internet access to the workload, where the destination does not need to know the actual IP address of the source (as is usually the case).

Routing in Underlay

Tungsten Fabric allows you to create networks that are connected using underlay.

In the case where underlay is a routed IP fabric, the Tungsten Fabric controller can be configured to exchange routes with the underlay switch. This allows virtual workloads to connect to any target that is accessible from the underlay network and provides a simpler way to connect virtual workloads to external networks than physical gateways.

It is important to note that overlapping IP addresses do not connect to the IP fabric, which is more useful for connecting the cloud to traditional resources rather than enterprises with multi-tenant service providers.

Note that the traffic that flows into and out of the underlay network is constrained by network and security policies, just like traffic between workloads using a virtual network.

MORE

More Tungsten Fabric parsing articles

Part I: main features and use cases of TF

Article 2: how TF works

Part 3: detailed explanation of vRouter architecture

Part IV: service chain of TF

Part 5: deployment options for vRouter

Part 6: how does TF collect, analyze, and deploy?

Chapter 7: how to arrange TF

Part 8: TF support API list

Follow Wechat: TF Chinese Community

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.