Will Cisco SD-WAN cut off the branch that DMVPN sits on?

Since August 2017, when Cisco acquired Viptela, the main technology offering for enterprise distributed networking has been Cisco SD-WAN. Over the past 3 years, SD-WAN technology has undergone many changes, both qualitative and quantitative. So the functionality has significantly expanded and support has appeared on the classic routers of the series Cisco ISR 1000, ISR 4000, ASR 1000, and Virtual CSR 1000v. At the same time, many Cisco customers and partners continue to wonder - what is the difference between Cisco SD-WAN and the already familiar approaches based on technologies such as Cisco DMVPN и Cisco Performance Routing And how important are these differences?

Here we should immediately make a reservation that before the appearance of SD-WAN in the Cisco portfolio, DMVPN, together with PfR, constituted a key part in the architecture Cisco IWAN (Intelligent WAN), which in turn was the predecessor of full-fledged SD-WAN technology. Despite the general similarity of both the tasks themselves and the methods for solving them, IWAN did not receive the level of automation, flexibility and scalability necessary for SD-WAN, and over time, the development of IWAN has significantly decreased. At the same time, the technologies that make up IWAN have not gone away, and many customers continue to successfully use them, including on modern equipment. As a result, an interesting situation has developed - the same Cisco equipment allows you to choose the most appropriate WAN construction technology (classic, DMVPN + PfR or SD-WAN) in accordance with the requirements and expectations of customers.

The article does not intend to analyze in detail all the features of Cisco SD-WAN and DMVPN technologies (with or without Performance Routing) - there are a huge number of documents and materials available for this. The main task is to try to evaluate the key differences between these technologies. But still, before moving on to a discussion of these differences, let's briefly recall the technologies themselves.

What is Cisco DMVPN and why is it needed?

Cisco DMVPN solves the problem of dynamic (=scalable) connection of a remote branch network to a corporate central office network using arbitrary types of communication channels, including the Internet (= with communication channel encryption). Technically, this is implemented by creating a virtualized overlay network of L3 VPN class in point-to-multipoint mode with a logical topology of the Star type (Hub-n-Spoke). To do this, DMVPN uses a combination of the following technologies:

• IP routing
• Multipoint GRE Tunnels (mGRE)
• Next Hop Resolution Protocol (NHRP)
• IPSec Crypto profiles

What are the main advantages of Cisco DMVPN compared to classical routing using MPLS VPN channels?

• To create an inter-branch network, it is possible to use any communication channels - everything that can provide IP connectivity between branches is suitable, while the traffic will be encrypted (where necessary) and balanced (where possible)
• Fully connected topology between branches is automatically formed. At the same time, between the central and remote branches - static tunnels, and between remote branches - dynamic tunnels on demand (if there is traffic)
• The central and remote branch routers have a uniform configuration up to the IP addresses of the interfaces. By using mGRE, there is no need to individually configure tens, hundreds, or even thousands of tunnels. As a result, decent scalability with the right design.

What is Cisco Performance Routing and why is it needed?

When using DMVPN on an interbranch network, one extremely important question remains unresolved - how to dynamically evaluate the state of each of the DMVPN tunnels for compliance with the requirements of traffic that is critical for our organization and, again, based on this assessment, dynamically make a decision about rerouting? The fact is that DMVPN in this part is not much different from classical routing - the best thing you can do is set up QoS mechanisms that will allow you to prioritize traffic in the outgoing direction, but are in no way able to take into account the state of the entire path at one time or another.

And what to do if the channel degrades partially, and not completely - how to detect and evaluate it? DMVPN itself does not know how to do this. Considering that the channels connecting branches can pass through completely different telecom operators, using completely different technologies, this task becomes extremely non-trivial. And here Cisco Performance Routing technology comes to the rescue, which by that time had already passed several stages of development.

The task of Cisco Performance Routing (hereinafter referred to as PfR) is reduced to measuring the state of the paths (tunnels) of traffic based on key metrics that are important for network applications - delay, delay variation (jitter), and packet loss (percentage). Additionally, the used bandwidth can be measured. These measurements take place as close to real time as possible (as far as possible and justified) and the result of these measurements allows the router using PfR to dynamically make decisions about the need to change the routing of a particular type of traffic.

Thus, the task of the DMVPN/PfR combination can be briefly characterized as follows:

• Allow the customer to use any communication channels on the WAN network
• Ensure the highest possible quality of critical applications on these channels

What is Cisco SD-WAN?

Cisco SD-WAN is a technology that uses the SDN approach to build and operate an organization's WAN. In particular, this means the use of so-called controllers (software elements), which provide centralized orchestration and automated configuration of all solution components. Unlike the canonical SDN (Clean Slate style), Cisco SD-WAN uses several types of controllers at once, each of which performs its own role - this is done intentionally in order to provide better scalability and geo-redundancy.

In the case of SD-WAN, the task of using any type of links and supporting business applications remains, but at the same time, the requirements for automation, scaling, security and flexibility of such a network are expanding.

Discussing differences

If we now begin to analyze the differences between these technologies, they will fall into one of the categories:

• Architectural differences - how are the functions distributed among the various components of the solution, how is the interaction of such components organized and how does this affect the capabilities and flexibility of the technology?
• Functionality - what can one technology do that another can't? And is it really that important?

What are the architectural differences and are they important?

In each of the designated technologies, there are many “moving parts”, which differ not only in their role, but also in the principles of interaction with each other. How thought out these principles are, and the general mechanics of the solution directly affects its scalability, fault tolerance and overall efficiency.

Consider the various aspects of the architecture in more detail:

data plane - part of the solution responsible for the transfer of user traffic between the source and the recipient. In DMVPN and SD-WAN, it is generally implemented in the same way on the routers themselves based on Multipoint GRE tunnels. The difference lies in how the necessary set of parameters for these tunnels is formed:

• в DMVPN/PfR is an exclusively two-level hierarchy of nodes with a Star or Hub-n-Spoke topology. A static configuration of the Hub and a static binding of Spoke to the Hub are required, as well as interaction via the NHRP protocol to form data-plane connectivity. Consequently, changes on the Hub are significantly more difficultassociated, for example, with changing / connecting new WAN channels or changing the parameters of existing ones.
• в SD WAN is a fully dynamic model for discovering the parameters of established tunnels based on the control-plane (OMP protocol) and orchestration-plane (interaction with the vBond controller for controller discovery and NAT traversal tasks). At the same time, superimposed topologies can be any, including hierarchical ones. Within the established overlay topology of tunnels, flexible configuration of the logical topology in each individual VPN (VRF) is possible.

Control plane – functions of exchange, filtering and modification of routing and other information between solution components.

• в DMVPN/PfR – carried out only between Hub and Spoke routers. Direct exchange of routing information between Spoke is not possible. Consequently, without a functioning Hub, the control-plane and data-plane cannot function, which imposes additional high availability requirements on the Hub that cannot always be met.
• в SD WAN – control-plane is never carried out directly between routers – interaction takes place on the basis of the OMP protocol and is necessarily carried out through a separate specialized type of vSmart controller, which provides the possibility of balancing, geo-redundancy and centralized control of the signal load. Another feature of the OMP protocol is its significant resistance to losses and independence from the speed of the communication channel with controllers (within reasonable limits, of course). Which equally successfully allows you to place SD-WAN controllers in public or private clouds with access via the Internet.

policy-plane - part of the solution responsible for defining, distributing and applying traffic control policies on a distributed network.

• DMVPN – effectively limited to Quality of Service (QoS) policies configured individually on each router via the CLI or Prime Infrastructure templates.
• DMVPN/PfR – PfR policies are formed on the centralized Master Controller (MC) router via CLI and then automatically distributed to branch MCs. In this case, the same policy transfer paths are used as for the data-plane. There is no way to separate the exchange of policies, routing information, and user data. Policy propagation requires IP connectivity between Hub and Spoke. In this case, the MC function can be combined with a DMVPN router if necessary. It is possible (but not required) to use Prime Infrastructure templates for centralized policy generation. An important feature is that the policy is formed globally on the entire network in the same way - individual policies for individual segments are not supported.
• SD WAN – traffic and quality of service management policies are determined centrally through the Cisco vManage graphical interface, which is also available via the Internet (if necessary). Distributed via signaling channels directly or indirectly through vSmart controllers (depending on the type of policy). Do not depend on data-plane connectivity between routers, because use all available traffic paths between the controller and the router.

  For different network segments, flexible formation of various policies is possible - the scope of the policy is determined by the set of unique identifiers provided in the solution - branch number, application type, traffic direction, etc.

orchestration-plane - mechanisms that allow components to dynamically discover each other, configure and coordinate subsequent interaction.

• в DMVPN/PfR Mutual discovery by routers is based on the static configuration of Hub devices and the corresponding configuration of Spoke devices. Dynamic discovery occurs only for Spoke, which communicates its connection parameters to the Hub device, which in turn is preconfigured by Spoke. Without IP connectivity of Spoke with at least one Hub, it is impossible to form either a data-plane or a control-plane.
• в SD WAN solution components are orchestrated using a vBond controller, with which each component (routers and vManage/vSmart controllers) must first establish IP connectivity.

  Initially, the components do not know about each other's connection parameters - for this they need an intermediary orchestrator vBond. The general principle is as follows - in the initial phase, each component learns (automatically or statically) only about the connection parameters to vBond, then vBond informs the router about the vManage and vSmart controllers (discovered earlier), which makes it possible to automatically establish all the necessary signaling connections.

  The next step is for the new router to learn about the rest of the routers on the network through an OMP exchange with the vSmart controller. Thus, the router, not initially knowing anything about the network parameters at all, is able to fully automatically detect and connect to the controllers and then also automatically detect and form connectivity with other routers. At the same time, the connection parameters of all components are initially unknown and may change during operation.

management-plane - part of the solution that provides centralized management and monitoring.

• DMVPN/PfR – a specialized management-plane solution is not provided. For basic automation and monitoring, products such as Cisco Prime Infrastructure can be used. Each router has the ability to manage through the CLI command line. Integration with external systems via API is not provided.
• SD WAN - all regular interaction and monitoring is carried out centrally through the graphical interface of the vManage controller. All features of the solution, without exception, are available for configuration through vManage, as well as through a fully documented REST API library.

  All SD-WAN network settings in vManage come down to two main constructs - the formation of device templates (Device Template) and the formation of a policy that determines the logic of the network and traffic processing. At the same time, vManage, broadcasting the policy formed by the administrator, automatically selects which changes and on which individual devices / controllers need to be made, which significantly increases the efficiency and scalability of the solution.

  Through the vManage interface, not only the configuration of the Cisco SD-WAN solution is available, but also full monitoring of the status of all components of the solution up to the current state of the metrics of individual tunnels and statistics on the use of various applications based on DPI analysis.

  Despite the centralization of interaction, all components (controllers and routers) also have a fully functional CLI command line, which is necessary during the implementation phase or in case of an emergency for local diagnostics. In normal mode (if there is a signal channel between components) on routers, the command line is available only for diagnostics and is not available for making local changes, which guarantees both local security and the only source of changes in such a network - vManage.

Integrated Security - here we should talk not only about the protection of user data during transmission over open channels, but also about the overall security of the WAN network based on the selected technology.

• в DMVPN/PfR it is possible to encrypt user data and signaling protocols. When using certain models of routers, firewall functions with traffic inspection, IPS / IDS are additionally available. It is possible to segment branch networks using VRF. It is possible to authenticate (one-factor) control protocols.

  In this case, by default, the remote router is considered a trusted element of the network - i.e. cases of physical compromise of individual devices and the possibility of unauthorized access to them are not assumed and are not taken into account, there is no two-factor authentication of the solution components, which in the case of a geographically distributed network may carry significant additional risks.

• в SD WAN by analogy with DMVPN, it is possible to encrypt user data, but with significantly expanded network security functions and L3 / VRF segmentation (ITU, IPS / IDS, URL filtering, DNS filtering, AMP / TG, SASE, TLS / SSL proxy, etc.). d.). At the same time, the exchange of encryption keys is carried out more efficiently through vSmart controllers (rather than directly), via pre-established signaling channels protected by DTLS / TLS encryption based on security certificates. Which, in turn, guarantees the security of such an exchange and provides better scalability of the solution up to tens of thousands of devices in one network.

  All signaling connections (controller-to-controller, controller-to-router) are also protected based on DTLS/TLS. Routers are equipped with safety certificates during production with the possibility of replacement / renewal. Two-factor authentication is achieved due to the obligatory and simultaneous fulfillment of two conditions for the router/controller to function in the SD-WAN network:

  • Valid security certificate
  • Explicit and conscious inclusion by the administrator of each component in the "white" list of allowed devices.

Functional differences between SD-WAN and DMVPN/PfR

Turning to the discussion of functional differences, it should be noted that many of them are a continuation of architectural ones - it is no secret that when forming the architecture of a solution, developers start from the features that they want to get in the end. Consider the most significant differences between the two technologies.

AppQ (Application Quality) - functions for ensuring the quality of transmission of business application traffic

The key features of the technologies under consideration are aimed at improving the user experience as much as possible when using business-critical applications in a distributed network. This is especially important in conditions where part of the infrastructure is not controlled by IT or even does not guarantee successful data transfer.

DMVPN does not provide such mechanisms on its own. The best thing that can be done in a classic DMVPN network is to classify outgoing traffic by application and prioritize it in the direction of the WAN link. The choice of a DMVPN tunnel is determined in this case only by its availability and the result of the operation of routing protocols. This does not take into account the end-to-end state of the path / tunnel and its possible partial degradation in terms of key metrics that are significant for network applications - delay, delay variation (jitter) and loss (%). In this regard, directly comparing classic DMVPN with SD-WAN in terms of solving AppQ tasks makes no sense - DMVPN cannot solve this problem. When Cisco Performance Routing (PfR) technology is added to this context, the situation changes and the comparison with Cisco SD-WAN becomes more appropriate.

Before moving on to a discussion of the differences, a brief summary of how the technologies are similar. So, both technologies:

• have a mechanism that allows you to dynamically assess the status of each established tunnel in the context of certain metrics - at a minimum, delay, delay variation and packet loss (%)
• use a certain set of tools for the formation, distribution and application of traffic control rules (policies), taking into account the result of measuring the state of key tunnel metrics.
• classify application traffic at the L3-L4 levels (DSCP) of the OSI model or by L7 application signatures based on the DPI mechanisms built into the router
• allow for significant applications to define acceptable threshold values ​​of metrics, default traffic transmission rules, traffic rerouting rules when threshold values ​​are exceeded.
• when encapsulating traffic in GRE / IPSec, they use the industry-established mechanism for transferring internal DSCP markings to the external GRE / IPSEC packet header, which allows you to synchronize the QoS policies of the organization and the telecom operator (if there is an appropriate SLA).

How do SD-WAN and DMVPN/PfR end-to-end metrics evaluate mechanisms differ?

DMVPN/PfR

• Both active and passive software sensors (Probes) are used to evaluate standard tunnel health metrics. Active - based on user traffic, passive emulate such traffic (if it is absent).
• There is no fine tuning of timers and degradation detection conditions – the algorithm is fixed.
• Additionally, a measurement of the used bandwidth in the outgoing direction is available. This adds DMVPN/PfR additional traffic management flexibility.
• At the same time, some PfR mechanisms, when the metrics are exceeded, rely on feedback signaling in the form of special TCA (Threshold Crossing Alert) messages that should come from the traffic recipient towards the source, which in turn implies that the state of the measured channels should be at least sufficient for transmission of such TCA messages. Which in most cases is not a problem, but obviously cannot be guaranteed.

SD WAN

• For an end-to-end assessment of standard tunnel state metrics, the BFD protocol in echo mode is used. In this case, special feedback in the form of TCA or similar messages is not required - the isolation of fault domains is observed. It also does not require the presence of user traffic to evaluate the state of the tunnel.
• It is possible to fine-tune the BFD timers to control the speed of operation and the sensitivity of the algorithm to degradation of the communication channel from several seconds to minutes.

  

• At the time of this writing, only one BFD session is provided in each of the tunnels. This potentially creates less granularity when analyzing the state of the tunnel. In fact, this can become a limitation only in the case of using a WAN connection based on MPLS L2 / L3 VPN with negotiated QoS SLA - if the DSCP marking of BFD traffic (after encapsulation in IPSec / GRE) matches the high priority queue in the carrier's network, then this can affect the accuracy and speed of degradation detection for low priority traffic. At the same time, it is possible to change the default BFD marking to reduce the risk of such situations. In future releases of Cisco SD-WAN software, finer tuning of BFD is expected, as well as the ability to run multiple BFD sessions within the same tunnel with individual DSCP values ​​(for different applications).
• BFD additionally allows you to estimate the maximum packet size that can be transmitted over a particular tunnel without fragmentation. This allows SD-WAN to dynamically adjust settings such as MTU and TCP MSS Adjust to make the most efficient use of the available bandwidth on each link.
• In SD-WAN, the option of synchronizing QoS with telecom operators is also available, not only based on the L3 DSCP field, but also based on L2 CoS values ​​that can be automatically generated in a branch network by specialized devices - for example, IP phones

How do the capabilities, ways of defining and applying AppQ policies differ?

DMVPN/PfR Policies:

• They are defined on the router(s) of the central branch (CF) through the CLI command line or CLI configuration templates. Generating CLI templates requires preparation and knowledge of policy syntax.

  

• Defined globally without the possibility of individual adjustment / change to the requirements of individual network segments.
• Interactive policy generation in the graphical interface is not provided.
• Tracking changes, inheritance, creating multiple versions of policies for quick switching is not provided.
• Distributed automatically to the routers of remote branches. In this case, the same communication channels are used as for the transmission of user data. If there is no communication channel between the central and remote branch, distribution/modification of policies is not possible.
• They are applied on each router and, if necessary, modify the result of standard routing protocols, having a higher priority.
• For cases where all branch WAN links experience significant traffic loss, compensation mechanisms are not provided.

SD-WAN Policies:

• Defined in the vManage GUI through an interactive template wizard.
• Supports the creation of multiple policies, copying, inheritance, switching between policies in real time.
• Support individual policy settings for different segments (branches) of the network
• They spread using any available signaling channel between the controller and the router and / or vSmart - they do not directly depend on the data-plane connectivity between the routers. This of course requires IP connectivity between the router itself and the controllers.

  

• For cases where all available branch channels experience significant data loss exceeding the allowable thresholds for critical applications, it is possible to use additional mechanisms that increase transmission reliability:
  • FEC (Forward Error Correction) – uses a special redundant coding algorithm. When transmitting critical traffic over channels with a significant percentage of losses, FEC can be automatically activated and allows you to restore the lost part of the data if necessary. This slightly increases the usable transmission bandwidth, but significantly improves reliability.

    

  • Duplication of data streams – In addition to FEC, the policy may provide for automatic redundancy of selected application traffic in the event of an even greater level of loss that FEC cannot compensate for. In this case, the selected data will be transmitted through all tunnels towards the receiving branch with subsequent de-duplication (discarding extra packet copies). The mechanism noticeably increases the utilization of channels, but also significantly increases the reliability of transmission.

Cisco SD-WAN capabilities, no direct analogs in DMVPN/PfR

The architecture of the Cisco SD-WAN solution in some cases allows you to get features that are either extremely difficult to implement within the DMVPN / PfR, or impractical due to the necessary labor costs, or even impossible. Consider the most interesting of them:

Traffic Engineering (TE)

The TE includes mechanisms that allow traffic to branch off the standard path formed by routing protocols. TE is often used to provide high availability of network services by being able to quickly and/or proactively transfer important traffic to an alternative (non-overlapping) transmission path in order to provide better quality of service or speed of recovery in the event of a failure on the main path.

The complexity of the TE implementation lies in the need to calculate and reserve (check) an alternative path in advance. In MPLS networks of telecom operators, this problem is solved using technologies such as MPLS Traffic-Engineering with extensions of the IGP protocols and the RSVP protocol. Also recently, the Segment Routing technology, which is more optimized for centralized configuration and orchestration, is gaining more and more popularity. In classic WAN networks, these technologies are usually not represented or reduced to the use of hop-by-hop mechanisms like Policy-Based Routing (PBR), which are able to tap traffic, but implement this on each router separately - without regard to the overall state of the network or the result of the PBR in the previous or subsequent steps. The result of the use of these TE options is disappointing - MPLS TE, due to the complexity of configuration and operation, is usually used only in the most critical part of the network (core), and PBR is used on individual routers without the ability to form some kind of unified PBR policy throughout the network. Obviously, this also applies to networks based on DMVPN.

SD-WAN in this regard offers a much more elegant solution that is not only easy to configure, but also scales much better. This is the result of the control-plane and policy-plane architectures used. The implementation of the policy-plane in SD-WAN allows you to centrally define the policy of the TE - what kind of traffic is of interest? for which VPNs? through which nodes/tunnels is it necessary or vice versa forbidden to form an alternative route? In turn, the centralization of control-plane management based on vSmart controllers allows you to modify the routing results without resorting to the settings of individual devices - routers already see only the result of the logic that was generated in the vManage interface and transferred for use on vSmart.

Service-chaining (Service chains)

The formation of service chains is an even more time-consuming task in classical routing than the already described Traffic-Engineering mechanism. Indeed, in this case, it is necessary not only to form a certain special route for a specific network application, but also to provide the ability to output traffic from the network on certain (or all) nodes of the SD-WAN network for processing by a special application or service (ITU, Balancing, Caching, Inspection traffic, etc.). At the same time, it is necessary to be able to control the state of these external services in order to prevent black-holing situations, and we also need mechanisms that allow placing such external services of the same type in different geo-locations with the ability of the network to automatically select the most optimal service node for processing traffic of a particular branch . In the case of Cisco SD-WAN, this is quite easy to achieve by creating an appropriate centralized policy that "glues" all aspects of the target service chain into a single whole and automatically changes the data-plane and control-plane logic only where and when necessary.

The ability to form geo-distributed processing of traffic for selected types of applications in a certain sequence on specialized (but not related to the SD-WAN network itself) equipment is perhaps the most clear demonstration of the advantages of Cisco SD-WAN over classical technologies and even some alternative SD solutions. - WAN of other manufacturers.

The result?

Obviously both DMVPN (with or without Performance Routing) and Cisco SD-WAN end up solving very similar problems in relation to a distributed WAN network of an organization. At the same time, significant architectural and functional differences in Cisco SD-WAN technology bring out the process of solving these problems. to another quality level. Summarizing, the following significant differences between SD-WAN and DMVPN/PfR technologies can be noted:

• DMVPN/PfR generally use time-tested technologies for building overlay VPN networks and are similar in terms of data-plane to more modern SD-WAN technology, while there are a number of restrictions in the face of a mandatory static configuration of routers and the choice of topologies is limited to Hub-n-Spoke. On the other hand, DMVPN / PfR has some functionality that is not yet available within SD-WAN (we are talking about per-application BFD).
• Within the control-plane technologies differ fundamentally. Taking into account the centralized processing of signaling protocols, SD-WAN allows, in particular, to significantly narrow down the failure domains and “decouple” the process of transferring user traffic from signaling interaction - temporary unavailability of controllers does not affect the possibility of transferring user traffic. At the same time, the temporary unavailability of any branch (including the central one) does not affect the ability of other branches to interact with each other and controllers.
• The architecture for generating and applying traffic control policies in the case of SD-WAN also surpasses that in DMVPN / PfR - geo-reservation is implemented much better, there is no connection to the Hub, more options for fine-tuning policies, the list of implemented traffic control scenarios is also much larger.
• The solution orchestration process is also significantly different. DMVPN assumes the presence of previously known parameters that must be somehow reflected in the configuration, which somewhat limits the flexibility of the solution and the possibility of dynamic changes. In turn, SD-WAN proceeds from the paradigm that at the initial moment of connection time, the router “does not know anything” about its controllers, but knows “whom you can ask” - this is enough not only to automatically establish communication with the controllers, but also to automatically formation of a fully connected data-plane topology, which can then be flexibly configured / changed using policies.
• In terms of centralized management, automation and monitoring, SD-WAN is expected to outperform DMVPN/PfR, which is the result of the development of classic technologies and rely more on the CLI command line and the use of template-based NMS systems.
• In SD-WAN, compared to DMVPN, security requirements have reached a different quality level. The main principles are zero trust, scalability and two-factor authentication.

From these simple conclusions, one may get the wrong impression that the creation of a network based on DMVPN/PfR has lost all relevance today. This is of course not entirely true. For example, in cases where the network uses a lot of legacy equipment and there is no way to replace it, DMVPN can allow you to combine "old" and "new" devices into a single geo-distributed network with many of the advantages described above.

On the other hand, it should be remembered that All current Cisco enterprise routers based on IOS XE (ISR 1000, ISR 4000, ASR 1000, CSR 1000v) today support any mode of operation - both classic routing and DMVPN and SD-WAN - the choice is determined by current needs and the understanding that at any time on the same equipment you can start moving towards more advanced technology.

Source: habr.com