VNF Service Chaining
Service chaining links two or more virtual network functions (VNFs) in a defined order, so traffic passes through each function, for example firewall then router, before it reaches the cloud. On IZO™+ Multi Cloud Connect you build the chain on the TCx solution canvas, wiring the VNFs together with Device connection links. A Layer 2 connection joins the devices; each device’s Layer 3 routing sets the order of the chain.
What service chaining is
VNFs are software versions of network functions, such as firewalls, routers and load balancers, that were traditionally delivered as dedicated hardware appliances. On IZO™+ Multi Cloud Connect they run as software on shared virtualisation infrastructure at a Fabric Edge location, rather than as separate physical boxes.
Service chaining (also called VNF chaining or Service Function Chaining) links these VNFs one after another in a specific, ordered sequence that traffic must pass through before reaching its destination. It matters because it:
-
automates and simplifies the provisioning of network services;
-
gives you central control to steer traffic across the functions you need;
-
reduces the risk of outages through better visibility and flexibility; and
-
removes the dependency on fixed, single-purpose hardware, so a chain can be redesigned in software.
How it is delivered on IZO™+ Multi Cloud Connect
You build the chain on the TCx solution canvas, the same canvas used to place a IZO™+ Multi Cloud Connect Flex order. Each VNF is an icon you configure (device category, vendor, make and model, size, licensing and management), and each is given an Alias Name that other components reference.
VNFs are wired together with Device connection links. An Edge Connect joins an A-End to a Z-End by Alias Name, for example a Fabric Port to a VNF, or one VNF to the next. This provides the Layer 2 connectivity between the devices; it does not by itself set the traffic order. The order of the chain, for example firewall then router then load balancer, is set by the Layer 3 routing configured on each device. The last VNF in the chain connects on to the cloud through a Virtual Cloud Connection.
On a Tata Communications-managed chain, Tata Communications configures the Layer 3 routing on each device to achieve the intended order; on a customer-managed chain you configure it. For device categories beyond the self-service options, such as firewall or SD-WAN, contact your account manager.
Connectivity options
|
Scope |
Description |
|
Within a metro |
The VNFs in the chain are in the same metro. |
|
Across metros |
The VNFs in the chain are in different metros. |
Resiliency
A single link between two VNFs, like a single cable, has no built-in resiliency. For a chain that needs high availability, add a second link over a second Fabric Port so the chain has a primary and a secondary path. This connection-level resiliency is separate from device-level high availability (a redundant VNF at the compute level); the two can be combined depending on the requirement.
Building a chain
The VNFs are added and wired during an IZO™+ Multi Cloud Connect Flex order: each VNF is configured, then the device connection links that reference them by Alias Name are added in the order in which traffic is to flow, and the setup is completed with the Virtual Cloud Connection to the cloud. The step-by-step canvas fields are covered in Adding VNF and Virtual Edge Connection.
What’s on the cloud side
The cloud connection at the far end is created in the cloud provider’s console. This page covers how a chain of VNFs is built and joined on the Tata Communications side; for the cloud-side connection request and routing, see the relevant per-cloud section.