Upcoming changes to Aritari ViBE Software

 
​New Provisioning and Orchestration Tools (Planned availability January 2021)

These tools are designed to simplify deployment and management of CPE devices for organisations. They will allow a Reseller/Service Provider to manage the sale and provisioning of customer endpoints from a centralised system. Once set up the system allows administration staff to configure and ship endpoint devices by just assigning a device MAC and product type to a customer database. It keeps track of which devices have been deployed and, optionally, details of billing periods, costs etc. Once deployed, products can be changed in the database to enable configuration changes and upgrades of customer CPE devices. This system can be supplied as a managed service or one managed by the service provider themselves.

​Operational Overview Fundamentally, this system allows the reseller or service provider to ship all CPE devices with the same basic configuration, which would normally cause the device to do the following:
Obtain a LAN IP address and gateway via DHCP. Connect to a remote provisioning server using DNS.  
Prior to shipping, the provider assigns the MAC address of the device to the customer in the database, as well as the specific product type. The product type defines, for example:
The hardware type of the CPE. Allowed number of calls. Link bandwidth. RAIN/Bonding Redundant links  
When a customer receives a CPE device, they simply connect it to their network and power it on, at which point it will connect to the provisioning server using a VPN tunnel. The provisioning server will then supply a configuration for the device based on the product parameter, which will then cause the CPE to reconfigure itself and connect to the production server.

What's New In ViBE Version 7 (Planned availability Early 2021)

ViBE version 7 will add layer 2 network support for tunnels, whilst continuing to support all optimisations for voice and data previously supported at layer 3. This allows networks to be joined at the broadcast level, so that devices at either end of the tunnel ( or via multiple tunnels ) can appear to be connected to the same LAN.
VLAN tags ( 802.11q ) are also supported allowing multiple customer virtual networks to be carried within tunnels without those networks being visible to each other. In addition, QinQ ( 802.11ad double tagging ) is supported meaning many customer networks can be carried through tunnels, each having their own set of internal VLANs. ViBE also has the ability to filter VLANs so that only those allowed to be sent via a given tunnel will be.
Layer 2 offers many new deployment scenarios and allows a provider to supply true MPLS-like services without needing to have expensive dedicated links. Backbone links can be configured in a much more ad-hoc fashion, with traffic being routed and re-routed as appropriate in the case of link failures or additions. Some examples of use cases include:
VRRP can be used across links to provide geographically redundant services for either the provider or their customers. A provider with their own AS can use BGP to announce that AS in many geographic locations using a ViBE backbone to join and route traffic as required. Routing protocols such as OSPF can easily be deployed across sites. IGMP snooping allows multicast traffic to be routed efficiently.
 

Refresher on other functionality already available

ViBE and its operating system form an extremely flexible SD-WAN solution for customers, resellers and service providers. What follows is a summary of those features prior to the release of orchestration and V7 detailed above.

Main Operating System Features
This section lists the main abilities of the operating system on which our server and CPE devices run, with a brief description. Some of these features rely on the communication channel ViBE provides, which will be indicated in the description where applicable. This isn’t meant as an exhaustive list, rather an overview of some of the less obvious options useful in an enterprise installation.
Multi-Tenanted Virtual Routers
A single server may have many virtual routers, each with its own physical or virtual interfaces assigned. Specific users can be given access only to specific virtual routers, allowing a single device to serve many customers.
VRF Support
This allows separate networking domains containing specific physical or virtual interfaces within a routing domain. It’s useful for interfacing to MPLS or similar network topologies, and for keeping private customer networks separate.
CPE Control
CPE devices connected to a server can be remotely upgraded or rebooted by schedule or immediately, logs can be viewed, and so on. This requires the ViBE V6 binary.
CPE Configuration
CPE device configurations can be created on a server and deployed to a CPE when it connects, allowing the possibility of zero-touch deployment of CPEs. These configurations can be created from templates ( which are also creatable on a server ) tailored for specific scenarios. The GUI presented by a template can be customised to only request information that changes, such as a LAN IP address for example. A CPE would have a standard stored configuration which simply connects to a server for normal operation. This could then cause the CPE to connect to a different SD-WAN node or the one that configured it. This requires the ViBE V6 binary.
Custom Branding
The GUI logo and colour scheme can be customised to present customer branding. Any upgrade to the system preserves this branding across the upgrade.
Custom Configuration Whilst most common configuration scenarios can be catered for in the GUI, the OS contains various hooks which allow customisation beyond what’s possible using the graphical interface. As an example, whilst the firewall can be configured in many ways using the interface, since the OS uses a Linux kernel there are so many possibilities that creating a system which allows for every eventuality is next to impossible. A custom script can be installed which is executed whenever the firewall is rebuilt, allowing for these additional variations in firewall, QoS, and so on. All of the various custom hooks also survive an upgrade to the OS.
Full System Customisation
It’s also possible to add customisations that aren’t available via other means by adding an archive file containing additional files or scripts, which are applied to the OS whenever it is upgraded. In this way it’s possible, for example, to add some of the many available software packages that run on a Linux OS. Care should be taken to test upgrades when this method is used, however, since we don’t guarantee binary compatibility between upgrade versions.
Diagnostics and Testing
The ViBE binary provides various statistics and monitoring of the tunnels it controls, many of which are available via the GUI on the OS. However, since the system is a Linux distribution in its own right, there are various utilities and functions built in to aid diagnostics and testing. These include the standard ping, traceroute, tcpdump ( for capturing network packets ) and so on, but also various less well known programs such as SIPP ( for generating “fake” RTP streams. ) There is also a kernel module called “netem” included in most of our platforms, which adds the ability to use the router as a network test platform, introducing latency, packet loss, bandwidth restrictions, jitter, etc into the network.
Standard Router Functions
​ Some of the standard modules included are BGP, OSPF, RIP, DNS proxy, DHCP server, PPPoE, traffic graphs, export to netflow analysers, SNMP, VRRP for failover, CDMA dongle support and WiFi support. Anything that can be part of the Linux kernel or achieved using Linux software can be added based on customer demand and suitability for our system. 
Access control.
It is possible to create users with their own username and password which allows them access to the server or CPE GUI but the pages they can view can be individually restricted on a page by page basis. Pages can also be configured as “read only” so that users can view, but not modify, configurations.
Configuration snapshots.
It is possible to take a snapshot of the current configuration of a server or CPE that will automatically be re-deployed after a configurable time after a configuration change is saved unless subsequently cancelled. This is especially useful when making changes that might otherwise accidentally render the device inaccessible. For example , firewall changes or interface address changes.

ViBE SD-WAN/VPN Features
These are the features provided by the ViBE binary itself, and are hence also available on our OEM partner devices.

1. Security/Base Protocol No MTU Issues Most VPN systems encounter issues due to reduced MTU ( Maximum Transmission Unit ) on the link. Since our protocol has no direct link between packets sent through vs by the tunnel, there is no such problem with ViBE. In fact, the tunnel MTU can be set larger than that of the networks over which it runs.
2. Traffic Obfuscation Even without encryption ( which is an option, ) packets are multiplexed in a ViBE tunnel, so reconstructing them is not trivial. In addition, additional bogus traffic can be added to a link such that the usage pattern viewed from outside does not match the communication actually taking place. This removes the ability for an outsider to tell, for example, if a VoIP call is in progress. This bogus traffic takes the form of “padding” and does not affect the capacity of the tunnel.
3. Encryption There is the option to encrypt tunnel traffic, though obviously this will have an impact on device performance. Since much of the time traffic within the tunnel will be encrypted ( HTTPS etc. ) then there may not be a need to encrypt non-voice traffic. So it’s possible to encrypt voice by using a separate tunnel.
4.  Port and IP Hopping ViBE can be configured to use multiple endpoint ports and IP addresses to carry the same tunnel and these IP addresses can be routed differently if the network allows. This makes it very difficult for someone with access to the network core, to capture and reconstruct the tunnel traffic.
5. Multiple Protocols A “normal” ViBE tunnel is carried over UDP. However, it’s possible to change this so that TCP or even ICMP are used, without compromising the nature of the tunnel. Certain networks may give priority to these types of packets, thus making the tunnel more reliable over congested networks, but for security these options also add another layer of obfuscation to the fact that a VPN is in use.
6. HTML Mode When using TCP mode, packets can also be encoded as HTML base64, which adds another layer of encoding.

Multilink/Redundancy There are various ways in which multiple tunnels//links can be used to improve throughput and/or reliability. As far as traffic through the tunnel is concerned, these appear as a single link//tunnel and if routing of the tunnels//links needs to change due to network issues, this will be totally transparent ( i.e. there will be no routing changes as far as the “inner” network is concerned )

1. Bonding Multiple links can be combined to form a single tunnel, providing the sum of the bandwidth available for each link. If any of the component links degrade in terms of packet loss, latency etc, then it will automatically be taken out of service and restored when quality improves. The networks over which individual links run need not be the same technology, so for example a leased line and ADSL can be combined. The main stipulation is that latency of the links needs to be in the same range, or else the latency of the resultant tunnel will be affected. ViBE technology is unique in that the entire bandwidth of all links can be used for a single network TCP stream without bottlenecks being caused because of higher latency or out of order packets.
2. Failover Links can be added which remain passive unless the main link(s) fail. This is useful if the backup links run over metered networks, for example. ViBE can periodically test the passive links to ensure they’re available when required. If the main link(s) fail, ViBE will activate the passive backup in less than a second, though there could be additional time for the passive link to establish ( the extreme case being a dial-up modem, for example )
3. RAIN/RAIN+ Multiple links can also be combined using RAIN mode ( Redundant Array of Inexpensive Networks. ) In this case, every tunnel packet sent is duplicated along an alternative path - the simple case being a pair of links each of which carry a copy of the same traffic. This will mean, in the case of differing bandwidths, all links will be limited to the speed of the slowest. However, in the event that a link fails or has high packet loss, there’s no impact on the overall quality of the tunnel. Using this mode, it’s possible to combine two or more low quality links to create a tunnel of good quality. RAIN+ is a variation on this, in which a single pair of physical network connections can be both bonded to provide higher throughput for data, and RAINed to provide better quality for voice.
4. Combination Modes All of the various multilink modes can be used in combination
5. .​Auto CPE Configuration ( Version 6 ) When using V6 or later at both ends of a connection, only a single link needs to be configured on the CPE when bonding or backup links are used. The server will inform the CPE of the required additional configuration to bring up the other links. This is especially useful when multiple servers are used for redundancy or load balancing, since the correct endpoint addresses will be sent to the CPE based on the server selected.
6. Single Link RAIN RAIN mode can be activated for a single physical network link, so that packets are duplicated. These duplicated packets can then also be delayed, so that any burst of packet loss is mitigated. If there are multiple links configured in RAIN mode, the configuration can specify whether RAIN should still be used when only a single link is available.

Network Optimisation/QoS
ViBE performs various optimisations by default, and has additional options to improve throughput of TCP connections and to prioritise certain traffic.

1. Unique QoS Unlike other technologies, no bandwidth is sacrificed by the use of Quality of Service rules. ViBE’s QoS is also much more granular - rather than sending whole packets at a time which limits efficacy especially at lower bandwidth, ViBE is able to dynamically splice packets together to allow single byte transmission. The result of this is that real time traffic, for example, will remain responsive even on a saturated link ( normal techniques require that only about 70% of the link is used. ) RTP streams used for VoIP calls are ALWAYS given absolute priority.
2. QoS even Over the Internet Since the available bandwidth between the server and CPE is monitored in near real-time, QoS within the tunnel itself can be maintained even if the overall throughput reduces. This is particularly important for voice - providing there remains enough bandwidth end to end for voice traffic, other packets sent in the tunnel will not degrade the quality.
3. RTP Bandwidth Optimisation RTP ( used for VoIP ) is very inefficient, especially when used over ATM based links such as xDSL. As an example, the G.729 CODEC at 20mS quantisation uses 42.4kbit/s on an ADSL link, doubling to 84.8kbit/s at 10mS. ViBE reduces this to just over 8kbit/s in both cases. In addition to this, unlike other QoS schemes voice is given absolute priority on a ViBE enabled link ensuring very low loss and jitter, even in a congested tunnel.
4. TCP Acceleration ( Version 6 ) The TCP protocol, used for most communication on the Internet, was designed when networks were much slower than they are today. As a result, it doesn’t handle high bandwidth links which also have relatively high latency ( such as international or congested connections. ) In addition, even low amounts of packets loss ( well under 1% ) can have a drastic effect on throughput. When ViBE TCP Acceleration is enabled, there are the following benefits:

• TCP streams can use the full link bandwidth regardless of latency, allowing much greater throughput on high bandwidth/high latency connections. This is evident on international connections ( a 100mbit link from South Africa to the UK can yield 100% speed improvement, for example ) and can result in many times the throughput on satellite links.
• TCP connections are much less affected by packet loss. A 50mbit/s link from South Africa to the UK performs over 4 times faster using ViBE TCP acceleration when there is just 0.1% loss present.
• Bonded links are better able to use the full capacity of all links for single TCP sessions.
• Response time is greatly improved, for example when loading web pages which have to transfer many small files. A test of fetching 100 x  50Kbyte files using HTTP from South Africa to the UK using a 50mbit/s took over a minute to complete without ViBE TCPA, versus less than 20 seconds with.
• Statistics about what TCP connections are currently in progress are available using the vibe-stat command line tool.   

TCP Deduplication ( Version 6 )
This employs a cache of data on the local CPE and the server, which are synchronised. If a block of data ( note, not a whole file ) has been seen previously, one end will tell the other to refer to the stored block rather than sending the whole block again. In extreme cases ( such as downloading the same file again ) this can improve transfer time by many orders of magnitude. However, the use of this feature needs to be carefully considered. For one thing, for best performance it requires devices with large memory and storage capacities. Also, if encryption is used through the tunnel, it’s unlikely an improvement will be seen, since the point of encryption is to make data look random, and random data won’t be seen more than once. One application might be to deploy a ViBE appliance in Azure, and to use unencrypted SMB for file sharing to the Azure domain. ViBE tunnel encryption would be used to ensure the privacy of the data in transit.
Packet Routing
Each link from a server to a CPE is associated with a set of network routes, and also an optional “VPN ID” which can group certain CPE devices so that they can not be “seen” by CPEs in a different VPN. Servers can be connected together by tunnels in order to create a multi-site or even global network, though currently there’s no way to keep CPE groups separate across these backbone links ( though layer 2 can be used for this when released in 2021. )

1. Multiple Virtual Interfaces ViBE creates virtual interfaces which appear to the OS to be normal Ethernet ports, hence anything that can be applied to a normal Ethernet port ( such as routing, QoS, firewalling etc. ) can be applied to the virtual interface. Multiple such interfaces can be created and tunnels associated then with them, in order to keep routing domains separate. Whenever a tunnel, which contains a route to a network, comes up, that route is automatically added to the kernel so that traffic is sent into the appropriate virtual interface. Note that this is distinct from the OS virtual router functionality, which allows completely separate instances of ViBE to run in each router.
2. Tunnel State Based Routes Static network routes can be applied or removed based on the status of a tunnel. These can send particular traffic via the tunnel itself, or via an external gateway address ( so a tunnel coming up can cause specific destinations to be routed elsewhere. )
3. Tunnel Quality Based Routes Alternative IP routes can be used if the tunnel quality is below a specified standard ( based on loss, latency and jitter. )
4. Multi-Metric Routes can be given a metric, which determines the priority of the route versus other routes to the same network. In the event that a tunnel drops for some reason and there’s no backup, routes disappear. If there’s a higher metric route via a different tunnel, the IP block will be routed via that instead, otherwise it will be sent back out of the virtual interface to be routed via the normal kernel routing process.
5. Separate Voice and Data Routing Voice and data can be sent over separate tunnels. For example, you may want voice to traverse a RAIN tunnel to enhance quality, but data to be bonded to maximise bandwidth.
6. DNS Based Routing Routes can be specified using DNS names and wildcards, so for example *.netflix.com can be sent outside of a tunnel ( or indeed inside it ) if needed. 
7. Geographic Routing Routes can be specified using a geographic database, so for example all IP traffic based in the USA can be sent to a specific tunnel.

ViBE Communication Channels ( Version 6 )
From version 6, there is an encrypted communication channel that is used to send information and data between tunnel endpoints. This facilitates the remote upgrade and configuration features of our operating system. The actual communication protocol is built into the binary itself and would be retained if ported to another system ( though external “helper” code would be needed to make use of them in some cases. )
The configuration of an endpoint determines whether a specific channel is available or not ( for example you wouldn’t normally want a CPE being able to upgrade a server or view its logs.)

1. Remote Log Viewing The ability to view ViBE log messages is self contained ( so messages about endpoints coming up or going down, quality warnings and so on. ) Other requests are passed to an external helper program, so that various system logs can be retrieved.
2. Remote Upgrade/Configuration A file can be transferred and then passed to an external helper to perform an upgrade. It’s up to the operating system to select files, schedule upgrades, and so on.
3. ViBE Configuration/Licensing Independently of the OS, one ViBE process can send a configuration to another. The server configuration can contain variables which are substituted for certain items such as endpoint addresses, so that configurations themselves can be the same across multiple servers. A license request can also be made and the resulting request string be retrieved, and a new license can be installed.

Monitoring
​ViBE tunnels are continuously monitored in real time for packet loss, latency and jitter. Due to the unique way the protocol works, this data is that of the underlying link, even if the tunnel is saturated with traffic ( where normal “pings” would show very high latency because there’s no space on the link to send the ping packet. ) If EsP is enabled ( V6 ) the links are also continuously monitored for throughput, and the tunnel bandwidth setting adjusted accordingly. Version 6 also monitors all of these parameters in near real time ( previous versions used a rolling 20 second period. )
The monitoring data is available using a companion “vibe-stat” application, which is the way the running ViBE process is controlled. The GUI of the OS makes this information available, plus SNMP can be used.