Here you 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 Cisco IWAN (Intelligent WAN) architecturewhich in turn represented the predecessor to full-fledged SD-WAN technology. Despite the general similarity of both the problems being solved and the methods for solving them, IWAN has not yet received 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 themselves that make up the IWAN have not gone anywhere, and many customers continue to successfully use them, including on modern equipment. As a result, an interesting situation developed - the same Cisco equipment allows you to choose the most suitable WAN 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 is a huge amount of available documents and materials for this. The main task is to try to assess the key differences between these technologies. But still, before moving on to discussing 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 the network of the central office of an enterprise using arbitrary types of communication channels, including the Internet (= with encryption of the communication channel). Technically, this is accomplished by creating a virtualized overlay L3 VPN in point-to-multipoint mode with a logical topology of the "Star" (Hub-n-Spoke) type. 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 in comparison with classic routing using MPLS VPN channels?
- – , IP- , ( ) ( )
- . – , – ( )
- IP- . mGRE , . , .
Cisco Performance Routing ?
When using DMVPN on the interbranch network, one extremely important question remains unresolved - how to dynamically assess 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 rerouting decision? The fact is that DMVPN in this part is not much different from classical routing - the best thing that can be done is to configure QoS mechanisms, which will allow prioritizing 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, but not completely - how to detect and evaluate it? DMVPN itself cannot 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 this is where Cisco Performance Routing technology comes to the rescue, which by that time had already gone through several stages of development.
The task of Cisco Performance Routing (hereinafter PfR) boils down to measuring the state of the paths (tunnels) of traffic passing based on key metrics important for network applications - latency, delay variation (jitter) and packet loss (in percent)... Additionally, the used bandwidth can be measured. These measurements take place as close to real time as possible and warranted, and the result of these measurements allows a router using PfR to dynamically make decisions about the need to change the routing of a particular type of traffic.
Thus, the problem of combining DMVPN / PfR can be briefly described 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 an 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 all types of channels and ensuring the operation of business applications remains, but at the same time, the requirements for automation, scalability, security and flexibility of such a network increase.
Discussion of differences
If we now start to analyze the differences between these technologies, then they will fall into one of the categories:
- Architectural differences - how are 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 can't another? And is it so important?
What are the architectural differences, and are they really important?
Each of the indicated technologies has many "moving parts", which differ not only in their role, but also in the principles of interaction with each other. The scalability, fault tolerance and overall efficiency of the solution directly depend on how well thought out these principles and the general mechanics of the solution.
Let's consider various aspects of the architecture in more detail:
Data-plane is part of the solution responsible for transferring user traffic between the source and the destination. In DMVPN and SD-WAN, the implementation is generally the same on the routers themselves based on Multipoint GRE tunnels. The difference is how the required set of parameters for these tunnels is formed:
- DMVPN/PfR – «» Hub-n-Spoke. Hub Spoke Hub, NHRP data-plane . , Hub, , / WAN- .
- in SD-WAN , it 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). In this case, the superimposed topologies can be any, including hierarchical ones. Within the established superimposed tunnel topology, 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 – Hub Spoke. Spoke . , Hub control-plane data-plane, Hub , .
- in SD-WAN - the control-plane is never carried out directly between routers - the interaction is based on 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 signaling load. Another feature of the OMP protocol is its significant resistance to losses and independence from the speed of the communication channel with the controllers (within reasonable limits, of course). This is equally successful in hosting SD-WAN controllers in public or private clouds with Internet access.
Policy-plane - the part of the solution responsible for defining, distributing and enforcing traffic control policies on a WAN.
- DMVPN – (QoS), CLI Prime Infrastructure.
- DMVPN/PfR – PfR Master Controller (MC) CLI MC. , data-plane. , . IP- Hub Spoke. MC DMVPN . ( ) Prime Infrastructure . — – .
- SD-WAN – Cisco vManage ( ). vSmart ( ). data-plane , .. .
– , – , , ..
Orchestration-plane - mechanisms that allow components to dynamically discover each other, configure and coordinate subsequent interaction.
- in 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 Hub connection parameters to the device, which in turn is pre-configured in the Spoke configuration. Without IP connectivity, a Spoke with at least one Hub cannot form either a data-plane or a control-plane.
- SD-WAN vBond, ( vManage/vSmart) IP-.
– - vBond. – ( ) vBond, vBond vManage vSmart ( ), .
In the next step, the new router learns about the rest of the routers in the network via OMP exchange with the vSmart controller. Thus, the router, initially not 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 is a part of the solution that provides centralized management and monitoring.
- DMVPN/PfR – management-plane . , Cisco Prime Infrastructure. CLI. API .
- SD-WAN – vManage. vManage, REST API.
SD-WAN vManage – (Device Template) , . vManage, , / , .
vManage Cisco SD-WAN, DPI .
, ( ) CLI, . ( ) , – vManage.
Integrated security - here we should talk not only about protecting user data when transmitting over open channels, but also about the overall security of the WAN network based on the selected technology.
- DMVPN/PfR . , IPS/IDS. VRF. () .
- – .. , , . - SD-WAN DMVPN , L3/VRF (, IPS/IDS, URL-, DNS-, AMP/TG, SASE, TLS/SSL proxy ..). vSmart ( ), , DTLS/TLS . .
(-, ) DTLS/TLS. /. / SD-WAN :
- «» .
SD-WAN DMVPN/PfR
Moving on to discussing the functional differences, it should be noted that many of them are a continuation of the architectural ones - it is no secret that when shaping the architecture of a solution, developers start from the capabilities they want to get in the end. Let's consider the most significant differences between the two technologies.
AppQ (Application Quality) - functions to ensure the quality of traffic transmission of business applications
The key functions of these technologies 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 by itself. 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 in this case only due to its availability and the result of the routing protocols. At the same time, the end-to-end state of the path / tunnel and its possible partial degradation from the point of view of key metrics that are significant for network applications - delay, delay variation (jitter) and loss (%) are not taken into account. In this regard, it makes no sense to directly compare the classic DMVPN with SD-WAN in terms of solving AppQ problems - DMVPN cannot solve this problem. With the addition of Cisco Performance Routing (PfR) technology to this context, the situation changes and comparison with Cisco SD-WAN becomes more appropriate.
Before moving on to discussing the differences, here's a quick summary of how the technologies are similar. So, both technologies:
- have a mechanism that allows you to dynamically assess the state of each established tunnel in the context of certain metrics - at least 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 metrics of tunnels.
- classifies application traffic at L3-L4 layers (DSCP) of the OSI model or L7 application signatures based on the DPI mechanisms built into the router
- allow for important applications to define acceptable threshold values of metrics, rules for traffic transmission by default, rules for rerouting traffic when the threshold values are exceeded.
- GRE/IPSec DSCP GRE/IPSEC , QoS ( SLA).
SD-WAN DMVPN/PfR?
DMVPN/PfR
- , (Probes). — , ( ).
- – .
- . DMVPN/PfR .
- PfR TCA (Threshold Crossing Alert) , , , TCA-. , .
SD-WAN
- BFD echo-. TCA – . .
- BFD .
- BFD . . WAN- MPLS L2/L3 VPN QoS SLA — DSCP- BFD ( IPSec/GRE) , . BFD - . Cisco SD-WAN BFD, BFD DSCP- ( ).
- BFD , . SD-WAN , MTU TCP MSS Adjust, .
- SD-WAN QoS L3 DSCP , L2 CoS , — , IP-
, AppQ ?
DMVPN/PfR:
- (-) () CLI CLI- . CLI- .
- / .
- .
- , , .
- . , . / .
- , .
- , WAN- , .
SD-WAN:
- vManage .
- , , , .
- ()
- , / vSmart – data-plane . IP- .
- , , , , :
- FEC (Forward Error Correction) – . , FEC . , .
- Duplication of data streams - In addition to FEC, the policy can provide for automatic duplication of traffic of selected applications in the event of an even more severe level of loss that cannot be compensated by using FEC. In this case, the selected data will be transmitted through all tunnels towards the receiving branch with subsequent de-duplication (discarding extra copies of packets). The mechanism significantly increases the channel utilization, but also significantly increases the transmission reliability.
- FEC (Forward Error Correction) – . , FEC . , .
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 opportunities, the implementation of which within DMVPN / PfR is either extremely difficult, or impractical due to the necessary labor costs, or even impossible. Let's consider the most interesting of them:
Traffic-Engineering (TE)
TE includes mechanisms that allow traffic to be diverted from the standard path formed by routing protocols. TE is often used to provide high availability of network services, due to the ability to quickly and / or advance important traffic to an alternative (non-overlapping) transmission path, in order to provide better quality of service or speed of its recovery in the event of a failure on the main path.
The complexity of TE implementation lies in the need to compute 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 IGP protocols and RSVP protocol. Also recently, Segment Routing technology, which is more optimized for centralized configuration and orchestration, is gaining more and more popularity. In classic WAN networks, these technologies, as a rule, are not represented or are reduced to the use of hop-by-hop mechanisms such as Policy-Based Routing (PBR), which are able to branch traffic, but implement this on each router separately - without taking into account the overall state of the network or PBR result in the previous or subsequent steps.The result of using these TE options is disappointing - due to the complexity of configuration and operation, MPLS TE is used, as a rule, only in the most critical part of the network (core), and PBR is used on individual routers without the ability to form a certain uniform 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 significantly better scalable. This is a result of the control-plane and policy-plane architectures used. SD-WAN policy-plane implementation allows centralized TE policy definition - what traffic is of interest? for which VPN? through which nodes / tunnels is it necessary or, on the contrary, forbidden to form an alternative route? In turn, the centralization of control-plane control based on vSmart controllers allows you to modify the routing results without resorting to the settings of individual devices - the routers already see only the result of the logic that was formed in the vManage interface and transferred to be applied to vSmart.
Service-chaining
Formation of service chains is an even more laborious 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 to 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 mechanisms are also needed to place such external services of the same type in different geolocations with the ability of the network to automatically select the most optimal service node for processing the traffic of one branch or another. ...In the case of Cisco SD-WAN, this is easy enough to achieve by creating an appropriate centralized policy that "glue" all aspects of the target service chain into a single whole and automatically change the data-plane and control-plane logic only where and when it is needed.
The ability to form geo-distributed processing of traffic of selected types of applications in a certain sequence on specialized (but not related to the SD-WAN network itself) equipment is perhaps the most vivid demonstration of the advantages of Cisco SD-WAN over classical technologies and even some alternative SD solutions -WAN from other manufacturers.
What's the bottom line?
Obviously, both DMVPN (with or without Performance Routing) and Cisco SD-WAN ultimately solve very similar problems in relation to the organization's distributed WAN network. At the same time, significant architectural and functional differences of the Cisco SD-WAN technology bring the process of solving these problems to a different quality level . In summary, the following significant differences between SD-WAN and DMVPN / PfR technologies can be noted:
- DMVPN/PfR VPN data-plane SD-WAN , Hub-n-Spoke. , DMVPN/PfR , SD-WAN ( per-application BFD).
- control-plane . SD-WAN , , «» – . - ( ) .
- SD-WAN DMVPN/PfR – -, Hub, , .
- . DMVPN , - , . SD-WAN , « » , « » – , data-plane , / .
- , SD-WAN DMVPN/PfR, CLI NMS .
- SD-WAN DMVPN . – , .
From these simple conclusions, one might get the wrong impression that the creation of a network based on DMVPN / PfR has lost all relevance today. This is certainly not entirely true. For example, in cases where a lot of legacy equipment is used on the network and there is no way to replace it, DMVPN can allow combining "old" and "new" devices into a single geo-distributed network with many of the benefits described above.
On the other hand, it should be remembered that all current Cisco corporate 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.