Introduction to the NetFoundry Fabric
NetFoundry fabric is a dynamic mesh of hosted edge routers or customer hosted routers that are enabled to receive traffic (with link listeners). The fabric is dedicated per network and carries traffic only within a network. CloudZiti provides our customers, option to host the fabric routers across multiple public cloud providers such as AWS, Azure, GCP and OCI in any public cloud region. By virtue of multiple availability zones and providers in a region, the fabric gets multiple internet provider paths and thereby an option of routing traffic via the best of available paths. This also allows us to overcome the issues in the internet such as peering issues between providers, congestion, packet drops etc. Our customers who operate in a globally widespread environment have expressed that they have experienced better performance due to a fabric that spans across geos that they operate + smart routing that selects the best of available paths. This article covers details about NF's smart routing, how edge routers make routing decisions and how the best path is selected.
About Smart Routing from NetFoundry:
CloudZiti fabric provides the best path for traffic to reach the service ( application or resource that is accessed over a private CloudZiti network) from the source endpoint or edge router. Links are established between the routers in a network (fabric links). The link latency is measured every 10 seconds per link, and updated to the topology database in the controller. When a service dial occurs, the best path is calculated based on the link latency. The paths of active circuits are calculated every minute, and up to 10% of the circuits may be rerouted to more performant paths based on those calculations. Routers have a default cost (10), so that equal latency paths with more hops are more costly , biasing towards less hops. Any failure in ERs will lead to traffic being re-routed immediately.
The source and destination nodes that communicate in the CloudZiti network can be broadly classified as
1. Endpoint - device endpoint / SDK endpoint etc
2. Edge router -customer edge router - deployed as a router with inbuilt router endpoint
Edge Router as the source/destination:
In this scenario, the source node is a customer hosted edge router that's trying to communicate to a service behind the destination node which is another customer hosted edge router. Let us understand the path selection based on smart routing logic
**NetFoundry hosted Edge Router is referred to in short as NF ER. Customer hosted Edge Router is referred to as Customer ER
Traffic from the Customer ER at the source reaches the customer ER at the destination via the NetFoundry Hosted fabric routers (NF ERs). A customer ER can reach any NF ER in the fabric.
Possible paths for the traffic from Customer ER at Chennai to reach the destination Customer ER at London are:
1. Chennai(Customer ER) - Mumbai (NF ER) - London (NF ER) - London(Customer ER)
2. Chennai(Customer ER) - Chennai (NF ER) - Singapore (NF ER) - London (NF ER) - London(Customer ER)
3.Chennai(Customer ER - London (NF ER) - London(Customer ER)
4. Chennai(Customer ER) - Chennai (NF ER) - Mumbai (NF ER) - London (NF ER) - London(Customer ER)
Paths 1, 3 and 4 might take the same internet route and provide the same latency; however, the number of hops varies. Any of these paths might have a temporary impact on the latency due to congestion/degradation of the internet. In the above example, the source could be Chennai or London and the path would be selected based on least cost = link latency + number of hops
Note: The source/destination services may be configured as router endpoint terminated services which do not impact smart routing since the router endpoint runs on the edge router.
Endpoint as the source/destination:
In this scenario, the source is an endpoint that's trying to communicate with the destination which is another endpoint. The endpoints are deployed in the customer environment. Let's understand the path selection based on NetFoundry's smart routing logic.
Endpoints dial to all the available hosted edge routers as per the edge router policy and use the first responding hosted edge router to send traffic via the fabric to the destination. In the above example, the edge router in Chennai is most likely to be the router of choice for the endpoint at Chennai since it would be the closest and first responding hosted ER. In the unavailability of the hosted ER at Chennai, the next first responding router which is Singapore would be the router of choice for the endpoint. Similarly, on the destination endpoint at London, the first responding hosted ER is most likely the hosted ER at London.
Let's understand the traffic path once the endpoint dials to the first responding hosted ER.
The best path for the hosted ER at Chennai to reach the destination hosted ER at London is decided based on the path that offers the least cost.
Possible paths are:
1. Chennai (NF ER) - Singapore (NF ER) - London (NF ER)
2. Chennai (NF ER) - Mumbai (NF ER) - London (NF ER)
3. Chennai(NF ER) - London (NF ER)
In the normal situation ( i.e without any degradation), path 2 or 3 would be most likely selected.
Note: if you plan to run endpoint hosted services and would like to get the benefit of smart routing, NetFoundry suggests that you choose the fabric routers (NF hosted or customer hosted with link listeners) in the same geography as that of the endpoint hosting the services.