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

The introduction to Tungsten Fabric series, which comes from the practical experience taught by technology bulls, is compiled and presented by the TF Chinese community for you, and is designed to help beginners understand the whole process of TF operation, installation, integration, debugging and so on. If you have any relevant experience or questions, you are welcome to interact with us and communicate further with the community geeks. For more TF technical articles, please click the button at the bottom of the official account > learn > articles collection.

Author: Tatsuya Naganawa translator: TF compilation Group

There are many different components in Tungsten Fabric. Next, I will briefly describe their usage. Overview

Overall, Tungsten Fabric consists of 7 roles and (up to) 30 microservices, of which the roles are as follows:

VRouter

Control

Config

Config-database

Analytics (starting with TF 5.1, can be further divided into analytics, analytics-snmp and analytics-alarm)

Analytics-database

Webui

Although there are many components, in a simple use case, only four roles are needed: vRouter,control,config,config-database. Of course, in most cases, webui is also needed.

If you are only interested in the control plane / data plane portion of Tungsten Fabric, you can also omit analytics. Only in this case, some functions (such as v1 service chain, haproxy load balancer and K8s ingress,SNAT) will not work properly. Control, vRouter

Control and vRouter constitute the control plane and data plane of Tungsten Fabric, so it can be said that this is the most important part of Tungsten Fabric system. Since both control and vRouter use MPLS-VPN internally, I recommend that you skim through these materials at least before delving into their details:

Https://www.juniper.net/uk/en/training/certification/certification-tracks/sp-routing-switching-track?tab=jncis-sp

Https://www.juniper.net/uk/en/training/certification/certification-tracks/sp-routing-switching-track?tab=jncip-sp

Since most of the advanced features are in control, and vRouter is inherent in MPLS, this information will help you figure out what they are trying to do. Because both control and vrouter-agent use VPNV4 BGP internally, vRouter and its internal VRF will load the required prefixes based on the extended community attribute (also known as the routing destination route-target). Therefore, when creating a container or virtual machine on vRouter, it can send VPNV4 routed signals to control and map all routes to other vRouter, so that the data plane can know where to send messages automatically. Interestingly, vRouter's virtual network may have multiple default gateways and have the same IP and the same MAC! (in Junos terms, it is similar to the behavior of virtual-gateway-address. Since VRRP is not required to provide a default gateway for each virtual network, it eliminates bottlenecks and makes everything fully distributed. VRouter can also perform flow-based processing for some features, such as stateful firewall, NAT, flow-based ECMP, and so on. This is an important difference because this behavior introduces some adjustment points, such as connections per second and maximum streams. (in packet-based systems, PPS (packets per second) and throughput (and in some cases latency) are critical. If these parameters are important to your system, you may also need to check them. Note: you can choose to disable this behavior using the "packet-mode" parameter in the "ports" configuration. Config

Config also contains several components. Config-api provides an API endpoint for the configuration of Tungsten Fabric, which uses many components, such as control, analytics, and so on.

VRouter does not use it directly, because only the data needed is passed by control (through XMPP).

Of these, both the schema-transformer and svc-monitor processes do important things, so let me describe them in detail.

Schema-transformer

This process converts some abstract config parameters such as logical-router, network-policy, service-chain, and so on into the language of L3 VPN. It is one of the core components of Tungsten Fabric and does most of the work that MPLS-VPN cannot simply explain. For example, logical-router creates a new route-target ID internally that will have all the prefixes of the virtual network. Therefore, if you connect the virtual network to the logical-router, it will receive all the routes that the logical-router has. The behavior uses MPLS-VPN internally, but the route-target configuration is controlled by schema-transformer. Therefore, the configuration is transferred to the data plane in the following way:

Edit config-> (rabbitmq)-> schema-transformer, which creates new route-target-> (internally edit config)-> (rabbitmq)-> control-> (xmpp)-> vrouter-agent-> (netlink)-> vrouter.ko

Schema-transformer is also responsible for everything related to the service chain (service-chain). I won't delve into all the details of the service chain because there is no simple DC use case (even though AWS VPC currently does not provide similar services). Although, from the bottom of my heart, this is an interesting handling of all the prefixes received by VRF, and I personally think it's worth reading. Note: you can get all the details in the book. Https://mplsinthesdnera.net/svc-monitor

This process provides services that must use external processes internally, such as haproxy load balancers, v1 service chain instances based on nova API, iptables MASQUERADE for SNAT, and so on. Internally, vrouter-agent has some logic to start haproxy or set up iptables MASQUERADE, and svc-monitor will start this logic when the relevant services are defined. Svc-monitor selects some vRouter to create these services, instantiates some network functions, and processes these elements. Select one of the output (analytics/uves/vrouter) that uses analytics-api, and then click "Functional".

Https://github.com/Juniper/contrail-controller/blob/master/src/config/svc-monitor/svc_monitor/scheduler/vrouter_scheduler.py#L149

Although future versions may change, the current behavior is one of the reasons why analytics is required when Tungsten Fabric is installed.

Config-database

Tungsten Fabric uses multiple databases. Most of the data is stored in Cassandra, and if changes occur, RabbitMQ is notified of the changes to be passed on to other components, such as control, schema-transformer, svc-monitor, and so on. ZooKeeper is only used for operations that require locking to maintain consistency. For example, creating a port requires the allocation of an IP address, and its consistency is managed by ZooKeeper, so IP address assignment is always one-to-one. Nodemgr

I think most of the important components have been covered so far, so I'll cover the rest. First, let's take a look at what nodemgr is. Nodemgr is basically the source of the state of each node, so it checks usage, docker ps or CPU usage, and sends analytics UVE NodeStatus.

Https://github.com/Juniper/contrail-controller/blob/master/src/nodemgr/common/linux_sys_data.py

This value may be the source of contrail-status and other logic (such as analytics-alarm or svc-monitor) that check to see if it is Functional when selecting vRouter. Maintaining the state of these Functional is very important to ensure the proper operation of Tungsten Fabric. If different roles are assigned, this component behaves differently. Therefore, it is installed on each node in a different behavior. In addition, it provision each node for the first time, which means notifying config-api that the IP has been assigned the xxx role. Therefore, the module must exist even if the analytics functionality is not required, at least when the node is started for the first time. Device-manager

This procedure is used to configure physical-router (based on objects in config-database). Internally, it uses the same logic as schema-transformer and svc-monitor, which subscribe to RabbitMQ to see if the config has been changed, and when changes occur, the AMQP client initiates some logic:

For schema-transformer, it will update more config

For svc-monitor, it will add some logic to vRouters

For device-manager, it updates the configuration of physical-router.

This line is controlled by reaction_map, which defines how some changes on some config objects are passed on to other configurations to make changes.

Https://github.com/Juniper/contrail-controller/blob/master/src/config/device-manager/device_manager/device_manager.py#L59

For example, when updating bgp-router

Based on the definition of "self", it will be passed to bgp-router and physical-router through a reference to the original bgp-router object.

For bgp-router, the bgp-router object that is equivalent to the original bgp-router (peer)

The updated bgp-router then passes it to the physical-router where the bgp-router object is located.

Because the physical-router does not update anything when the event is passed from the bgp-router, the event stops there, and the physical-router config with the original bgp-router and the bgp-router with the peer are updated.

When physical-router receives an updated event, it calls the push_conf function from the plug-in to create a routing config based on the object in config-database.

Currently, only MX/QFX has an open source plug-in: https://github.com/Juniper/contrail-controller/tree/master/src/config/device-manager/device_manager/plugins/juniper

To enable this feature, you need to configure this knob in / etc/contrail/common_config.env: DEVICE_MANAGER__DEFAULTS__push_mode = 0.

The following link describes the configuration process: https://www.juniper.net/documentation/en_US/contrail5.0/topics/concept/using-device-manager-netconf-contrail.htmlanalytics

Tungsten Fabric analytics has a lot of features, but most of them are optional, so I'll skip most of the components. If you are interested, check the following links for information about SNMP, LLDP, alerts, etc.:

Https://tungsten.io/sandesh-a-sdn-analytics-interface/

Https://tungsten.io/operational-state-in-the-opencontrail-system-uve-user-visible-entities-through-analytics-api/

Https://tungsten.io/contrail-alerts/

Https://tungsten.io/overlay-to-physical-network-correlation/

Analytics itself has an interesting architecture that covers logs, flows, and stats.

As far as I know, they usually involve different systems, such as EFK for logs/flows and Prometheus for stats.

If you need a tool to easily use all systems, Tungsten Fabric analytics will be a good choice.

Most important metrics and analysis services are marked as UVE (user-visible entities) and have a URL to provide data in JSON format.

Http://(analytics-ip):8081/analytics/uves provides all the available values.

If you need to integrate Tungsten Fabric with other monitoring systems, that may be a good starting point.

Analytics-database

Analytics also uses multiple databases, such as Redis, Cassandra, Kafka (internally, it also uses ZooKeeper for the deployment of the HA option). If you use only analytics, only the Redis database is required, even in this setting, most webui features are available.

Most visualization features use UVE, so it is available even if Cassandra is not installed.

If you need the "Query" function of webui, you need to use Cassandra, which can retrieve logs/flows or stats information in the Cassndra database.

Kafka is used to pass UVE to analytics-alarms, so Kafka is necessary if you want to use the alarm feature. Webui

Finally, let's talk about webui. Basically, this is just a simple webui to view the status of the component and configure the parameters of the Tungsten Fabric. It uses the AJAX behavior to update some graphs that require a long query on analytics-api (for example, Monitor > Dashboard access), while asynchronous jobs are covered by the webui-job process, which is interesting.

END

Series of articles on getting started with Tungsten Fabric

1. First-time startup and operation guide

Series of articles on Tungsten Fabric Architecture Analysis--

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

Article 9: how TF connects to the physical network

Part 10: TF Application-based Security Policy

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.