blog posts

Why Do We Need SD-Wans?

Why Do We Need SD-Wans?

One Of The Problems With Traditional Networks Is That They Slow Down The Network, Especially When The Number Of Subscribers Is Increasing, Or We Are Going To Use Technologies Such As VOIP.

In such a situation, we need a network with the highest efficiency.

The networks we rely on for business and leisure have various problems and challenges that cause network performance to decline and become generally unstable.

We can experience latency, which refers to the time between sending and receiving data or the return time of data, and refers to the time it takes to send a packet and receive a response. For example, we try to calculate this delay time when using ping.

We can also experience jitter, which is the time delay variance between packets of data in the network and is essentially a “disruption” in the sending and receiving packets.

We have fixed bandwidth networks that can experience congestion. For example, five people sharing the same internet connection can experience a fast and stable network. Still, when that number reaches 20 or 30 people, they will all have a different and horrible experience.

There are ways we can fix these problems and create a better user experience.

For example, we can use the Quality of Service (QoS) technique to prioritize traffic. More bandwidth is provided to audio and video and VoIP applications exposed to network fluctuations. We can also use QoS to give each user a fair share of bandwidth and ensure adequate bandwidth for our critical applications.

QoS works well at the network’s edges, but the big problem is that a human agent must manage it. We need to know our traffic, where that traffic should go, and our priority traffic.

Once we have the exact answers to these questions, we will be able to manage network bandwidth faster. However, we still need network administrators to ensure that the routes that traffic should take are working, working, and reliable.

QoS, along with policy-based routing (PBR), can provide a way to direct traffic through various interfaces, using dedicated high-speed links for critical traffic and other links for user traffic such as Internet browsing and media.

In this case, too, they need a network administrator to plan this traffic-sharing process so that the above method will not be completely dynamic.

There are mechanisms for dynamic traffic routing, including MPLS-TE Multiprotocol Label Switching Traffic Engineering.

Using MPLS, a link-state protocol such as OSPF or IS-IS, RSVP (Resource Reservation Protocol), and CBR (Restricted Routing), we can have a network that learns and responds to network changes. MPLS-TE is widely used by corporations and ISPs because, in the long run, it imposes a lot of infrastructure and engineering costs that only these companies can afford.

Today, however, we are rapidly moving towards cloud acceptance, where almost anything can be provided “as a service.” The platform, infrastructure, and software are all executable with one click, and entire virtual data centers can be set up in minutes.

Letters like Microsoft Azure, Amazon Web Services, and Google Cloud are so ingrained in 21st century technology that we will not remember for a few years when the last time we used a non-cloud service.

So how do we take advantage of the potential benefits of cloud computing while taking advantage of QoS and MPLS-TE and the dynamics of modern networks and then meeting the security requirements? The answer lies in the concept of SD-WAN or software-centric networks. In this regard, the criteria seem to contradict each other.

SD-WAN

SD-WAN combines the concept of software-centric networks (in a local area network) with cloud orchestration and makes it available to us in a concept called Broadband. According to Gartner, there are four conditions for achieving SD-WAN as follows:

Must be able to support multiple types of connections.

Must be able to choose the dynamic path.

It Must be able to support VPNs and third-party services (such as firewalls).

It should have a simple user interface.

Gartner is not the only one to put these requirements on paper.

These are defined in the standard format specified by the MEF (formerly the Metro Ethernet Association) in MEF 70. MEF is an international industrial consortium that emerged to improve secure and coordinated connectivity services. MEF members include Cisco, Ericsson, Huawei, Juniper, Nokia Networks, VMWare, and other companies that are big names in the field of “communications” or “telecom.”

However, MEF 702, as many of the terms used in this document, are three-letter abbreviations. For example, the,

MEF Services, like SD-WAN, are defined using service attributes. A service attribute gathers specific information agreed upon between the service provider and the subscriber of a MEF service and describes some behavioral aspects of the service.

However, the design and implementation process will be better if we consider the SD-WAN deployment from a more practical angle and place it in a specific framework.

In general, the implementation process is as follows:

We start with the SD-WAN edge device. These devices can be physical or virtual. SD-WAN edge devices must support a variety of connections such as MPLS, Internet such as leased lines, and LTE.

Edge device “Between SD-WAN UNI on the shared side and UCS UNI one or more Underlay connection services on its network side” means that these devices are located at the border point between the business network (customer location). ) And ISP, SD-WAN UNI (User-Network Interface), and UCS, or Internet Circuit.

Since we have an infrastructure service, it makes sense that we should also have an infrastructure service. The network overlap we are setting up is done through the SD-WAN controller and the SD-WAN Orchestrator.

These devices control our policy flow and security policies.

The overlay div is responsible for dimming the rest of the network, allowing it to pick up the best routes across the web, and controlling our VPN and other services.

So when we start examining SD-WAN from a practical point of view, MEF 70 is a good starting point.

Cisco, along with Huawei, Nokia Networks, and Verizon, played a vital role in developing the MEF 70.