SDN (Software Defined Networking) VE NFV (Network Functions Virtualization)

Bu teknolojiler artan veri trafiğinin yönetim zorluğu , özel donanım bağımlılığından kaçmak ve donanım merkezli sistemden yazılım merkezine geçiş için önemlidir.

Wireless tarafında bütün ap ler tek bir wlc üzerinde çalısıyor , Sdn'deki mantıkta aynı aslında tüm cihazlar bir controller tarafından yönetilecek sw,fw,router gibi

SDN: Büyük ve karmaşık ağları etkin yönetmek için ağ altyapısını sanallaştırmak.Servis yöneticileri tarafından üretiliyor. Osi katmanında 2 ve 3 katmanı temsil eder.Switch , Router , Wireless yönetimi.

NFV: Telekom kaynakları etkin kullanmak, yeni servis gelişimlerinin hızlı ve düşük maliyetli test edebilme.Ağ fonkisiyonlarının tamamı sanallaştırmak amacıdır.Daha çok telekom operatorleri için yapılıyor. Osi katmanında 4-7 ve katmanında çalışır. Load balancer , packet inspection.,Firewallari IP

 Sdn nedir ?

Network cihazlarını geleneksel yöntemler kullanarak konfigurasyon yapmak yerine programlama dilleri ile JAVA,C/C++,Pyhton ile programlanabilmesidir.

Tranditional Network

Network her zaman geleneksel metodlara bağlı olarak gelişimini sürdürdü. Firewal, Switch ve Router gibi cihazlar belirli konfigurasyon templateleri ile konfigure edildi. Kullanılan geleneksel konfigurasyonlar metotları router ve switchler için CLI,Webgui ,Firewall’lar için Asdm,CLI vb. Sdn ile tek tek cihazları konfigüre etmek yerine Controller ile tüm cihazları yönetebileceğiz.

Network cihazları farklı görevleri olan 3 adet plane’den oluşur.

control plane : Butun yolların yedekleri yollarda dahil olmakla birlikte tutulduğu yerdir.Tüm routing protokolleri ve routing tablosu control plane üzerindedir.

data plane :  Asıl routing yapıldığı(Fib) yerdir. Sadece en kısa yolun bilgisi bulunur.

management plane : Ssh, telnet gibi cihazın access ve management bilgilerini tutar.

Aşağıdaki şekilde plane’lerin işlevlerini görebiliriz.

Sdn için örnek bir senaryo üzerinde yapılması gereken işlemleri inceleyelim.

Üsteki H1 makinası data centerımızda yeni oluşturulan 4 adet vmware sanal makinası ile haberleşmesi için yapılacak konfigürasyon adımları ;

Yeni oluşturacağımız Vlanları tüm switchlerde oluşturuluruz.

Stp protokülünden dolayı bazı portlar blocklanacağında Root Bridgeler Vlanlar için belirlenir.

Her bir sanal makina için bulunduğu vlanda bir subnet oluşturulur.

Router’da veya Sw’de Subinterface oluşturulup her vlan için ip atanır.

Hsrp veya Vrrp yapılarak yedeklilik sağlanır.

Firewall üzerinde gerekli erişim izinleri permit veya deny olarak yazılır.

İp bloğunu dynamic routing kullanıyorsak advertise ederiz veya statik route yazarız.

Bu işlemleri CLI üzerinde konfigürasyonları one by one olarak yapıyoruz.Bu işlemler süreç alır ve insan bağımlılığı oluşturur. Sdn ile Vmware’de oluşan sanal makinalarda dahil olmak üzere otomatik olarak konfigurasyonların yapılmasını beklemeden Sdn Controller üzerinden bu adımları uygulayabiliriz.

Ayrıca günümüzde yeni trend sanallaştırmadır . Birçok vendor artık bütün cihazlarını Router ,firewall vb. Hadware ekipmanlar yerine Vmware üzerinde çalıştırılmasını önermektedir.

Sdn Controller cihazların Control Planelerinin kontrolünden sorumludur ve Cihazlarda Control plane olmadığında dumb device gibi davranır. Switch Data plane üzerinden cihazlar forwarding işlemini yapmaya devam eder ancak sdn data plane’de kontrol edebilir.

SDN Controller 2 adet özel interface kullanır. Bunların isimleri northbound interface (NBI) and southbound interface (SBI)’dir.

Southbound Interface

Controller network devicelerı ile iletişime geçer ve data plane’lerini programlar. Görevi bu kadardır.

Bazı populer southbound interfaceler;

OpenFlow : Opensource olması nedeniyle tüm üreticiler tarafında(Cisco,Juniper,Aruba vb.) Openflow 1.3 ile desteklenmeye başlanmıştır.

Cisco OpFlex: Cisco cisconun Openflow çözümüdür.

APIC-EM : Cisco tarafında zero-touch mantığıyla çıkartılmış sdn çözümüdür . Yerini Dna Center’a bırakmıştır.

Northbound Interface

API (Application Programming Interface)’in Sdn ile erişimi için kullanılır.Sdn erişerek script yazabilir ve networkü otomize edebiliriz.

Controller ile erişim yolları Gui, Script veya başka bir application olabilir.

REST API

Rest Api http protokolü kullanarak ile Controller’a mesaj gönderir ve alır.

SDN ÇÖZÜMLERİ VE UYGULANABİLİRLİKLERİ

1-    OpenDayLight

Open source Sdn çözümü olarak öne çıkmaktadır. Tüm vendorlar openflow 1.3 desteklemeye başlaması ile Opendaylight bir sdn çözümü olarak kullanılabilir.

Ancak OpenFlow 1.3 şu an sadece cisco switchler ve routerların bir kısmı tarafında desteklenmektedir. Bizim topolojimizde bulunan 3850 series switchler dışındaki cihazların openflow desteği olmadığı için değişmesi gerekmektedir.

2-      APIC-EM & DNA Center

Bu iki çözümde de cihazların sadece serial number’ları Controller üzerinde ekleyerek cihazları kontrolünü sağlayabiliyoruz. Ancak Apic-Em şu an upgrade edilmiyor yerini Dna Center’a bırakacak. Cisco çözümü ve Third Party cihazları desteklemiyor diyebiliriz. Opendaylight’a göre Dna Center daha fazla cisco switch ve router tarafından desteklenmektedir.Bizim topolojimizde sadece 3850 tarafından desteklenmektedir, Kullanığımız routerlar ve Firewallar tarafından Sdn Controller desteklememektedir .

3-    APIC (Application Centric Infrastructure)

Cisconun Data Center çözümüdür. Cisconun en kapsamlı sdn çözümü diyebiliriz, çok fazla yenilik getirmektedir. Büyük Network yapıları için tasarlanmıştır . Vmware , Hyper V ve F5 gibi bir çok third party cihaz desteği vardır. Bizim topolojimizde Routerlar dışında Firewall ve Switchler tarafında desteklenmektedir.

Sonuç:

Opendaylight opensource olması nedeniyle tüm vendorlar tarafından desteklenecek olması bir avantaj ama bir hata ile karşılaşıdığında karşımızda muhattap bulamayacağız. Kullanım için Firewalların ve Routerların değişmesi gerekmektedir.

Cisco Dna Center Dökümantasyon olarak daha güçlü ayrıca bir problem oluştuğunda case açabilme avantajı var. Router ve Firewall’ların değişmesi gerekmekte Dna Center Firewall olarak sadece virtual Asa firewall’ları destekliyor , appliance modellerine desteği yok.

Cisco Apic Data Center çözümü bizim için kullanışlı olmayacaktır.

Open Source Firewall ve Routerlar

Networkteki cihazları cisco veya diğer marka bağımlılığından çıkararak open source router ve firewall yazılımlarını bir sunucu üzerinde kurarak sunucuyu sanki bir router veya firewall gibi kullanabiliriz. Open source yazılımlara  örnek olarak kullanabileceğimiz opnsense, pfsense ve vyos gibi ön planda olan yazılımlar bulunmaktadır. Bu üç linux firewall’da bir çok özellik desteklemektedir Qos , Url filtering ,Netflow vb. ancak multicast desteği future olarak gösterilmektedir. Opnsense ve Pfsense freebsd üzerinde görsel arayüzler eklenerek yapılmış cihazlar olduklarından user-friendly özelliği kullanım için kolaylık sağlamaktadır.

Bsd Router opensource linux router olarak son versiyonunda multicast routing desteklediğini söylüyor. Kurulumları kendi bilgisayarımda test edip kurulumları başarılı şekilde yapabilirsem mevcut topolojimizde kullanabiliriz. Konfigurasyonları cisco gibi user-friendly değil testler zaman alacaktır.

https://bsdrp.net/BSDRP

SDN (Software Defined Networking) is the latest buzzword in IT, getting more popular every year. Some network engineers read or heard stories about how the entire network will be programmed in the future, and now fear that their jobs will be replaced by programmers who know C/C++, Java, or Python inside out.
What is SDN, why is it becoming popular? Are those fears justified?
To answer these questions, we will have to take a closer look at “traditional” networking first. We will discuss the current “limitations” of traditional networking, I will explain what SDN is and how SDN is supposed to solve the “problems” that traditional networking has.

Traditional Networking

Networking has always been very traditional. We have specific network devices like routers, switches, and firewalls that are used for specific tasks.
These network devices are sold by networking vendors like Cisco and often use proprietary hardware. Most of these devices are primarily configured through the CLI, although there are some GUI products like CCP (Cisco Configuration Protocol) for the routers or ASDM for the Cisco ASA firewalls.
A network device, for example, a router has different functions that it has to perform. Think for a moment about some of the things that a router has to do in order to forward an IP packet:

• It has to check the destination IP address in the routing table in order to figure out where to forward the IP packet to.
• Routing protocols like OSPF, EIGRP or BGP are required to learn networks that are installed in the routing table.
• It has to use ARP to figure out the destination MAC address of the next hop or destination and change the destination MAC address in the Ethernet frame.
• The TTL (Time to Live) in the IP packet has to be decreased by 1 and the IP header checksum has to be recalculated.
• The Ethernet frame checksum has to be recalculated.

All these different tasks are separated by different planes. There are three planes:

• control plane
• data plane
• management plane

Let’s take a look at the difference between these three planes…

Control Plane

The control plane is responsible for exchanging routing information, building the ARP table, etc. Here are some tasks that are performed by the control plane:

• Learning MAC addresses to build a switch MAC address table.
• Running STP to create a loop-free topology.
• Building ARP tables.
• Running routing protocols like OSPF, EIGRP, and BGP and building the routing table.

Data Plane

The data plane is responsible for forwarding traffic. It relies on the information that the control plane supplies. Here are some tasks that the data plane takes care of:

• Encapsulate and de-encapsulate packets.
• Adding or removing headers like the 802.1Q header.
• Matching MAC addresses for forwarding.
• Matching IP destinations in the routing table.
• Change source and destination addresses when using NAT.
• Dropping traffic because of access-lists.

The tasks of the data plane have to be performed as fast as possible which is why the forwarding of traffic is performed by specialized hardware like ASICs and TCAM tables.

Management Plane

The management plane is used for access and management of our network devices. For example, accessing our device through telnet, SSH or the console port.
When discussing SDN, the control and data plane are the most important to keep in mind. Here’s an illustration of the control and data plane to help you visualize the different planes:

Above you can see the control plane where we use routing protocols like OSPF and EIGRP and some static routing. The best routes are installed in the routing table. Another table that the router has to build is the ARP table.
Information from the routing and ARP table is then used to build the forwarding table. When the router receives an IP packet, it will be able to forward it quickly since the forwarding table has already been built.

If you want to learn exactly how the different planes work and how ASICs / TCAMs are used then you might want to read my CEF (Cisco Express Forwarding) lesson.

Limitations of traditional networking

Everything I described above is the way we have done things for the last ~30 years so it’s not like there is something “wrong” with traditional networking. However, nowadays there are some business challenges that ask for different solutions.

Let’s look at a scenario.

Above we see the network infrastructure of a company’s data center. At the bottom, we find a VMware ESXi server with a number of virtual machines. This server is connected to some switches in the access and aggregation layers. We also see two ASAs that protect our server and two routers for access to the outside world. On top, there is another router with a host device.
Let’s say this company has a business requirement for a new application that requires four new virtual machines to be installed on the VMware server. For security reasons, each virtual machine should be in a different VLAN. A user that is using H1 behind R3 should be able to access the application that runs on these virtual machines.
Let’s consider some of the things we have to configure on our network to make this happen:

• The VLANs have to be created on all switches.
• We have to configure a root bridge for the new VLANs.
• We have to assign four new subnets, one for each VLAN.
• We need to create new sub-interfaces with IP addresses on the switches.
• We need to configure VRRP or HSRP on the switches for the new VLANs.
• We have to configure the firewalls to permit access to the new applications / subnets.
• We have to advertise the new subnets in a routing protocol on our switches, routers, and firewalls.

Although there are network automation tools to help us, we often use the CLI to configure all of these devices, one-by-one. It’s a slow, manual process that a human has to do. While it only takes a few minutes to spin up a new virtual machine, it might take a few hours for the network team to prepare the network. Changes like these are also typically done during a maintenance window, not during business hours.
Server virtualization is one of the reasons why businesses are looking for something that speeds up the process described above. Before virtualization, we used to have one physical server with a single operating system. Nowadays we have multiple physical servers with hundreds of virtual machines.
These virtual machines are able to move automatically from one physical server to another. When they cross an L3 boundary, you don’t want to wait for the network team to make the required changes to routing or access-lists. It should be automatic.
The “trend” nowadays is that everything should be virtual. It’s not strange to see that this is also happening to networking. Large companies like Cisco that used to sell only proprietary hardware are now also offering virtual routers, ASAs, wireless LAN controllers, etc. that you can run on VMWare servers.

SDN (Software Defined Networking)

Like the buzzword “cloud” a few years ago, every organization or vendor has a different opinion about what SDN exactly is and different products that they offer.
Traditional networking uses a distributed model for the control plane. Protocols like ARP, STP, OSPF, EIGRP, BGP and other run separately on each network device. These network devices communicate with each other but there is no central device that has an overview or that controls the entire network.
One exception here (for those that are familiar with wireless networking) are the wireless LAN controllers (WLC). When you configure a wireless network, you configure everything on the WLC which controls and configures the access points. We don’t have to configure each access point separately anymore, it’s all done by the WLC.
With SDN, we use a central controller for the control plane. Depending on the vendor’s SDN solution, this could mean that the SDN controller takes over the control plane 100% or that it only has insight in the control plane of all network devices in the network. The SDN controller could be a physical hardware device or a virtual machine.
Here’s an illustration to help you visualize this:

Above you can see the SDN controller which is responsible for the control plane. The switches are now just “dumb” devices that only have a data plane, no control plane. The SDN controller is responsible for feeding the data plane of these switches with information from its control plane.
There are some advantages and disadvantages of having a distributed vs a central control plane. One of the advantages of having a central controller is that we can configure the entire network from a single device. This controller has full access and insight of everything that is happening in our network.
Let’s add some more detail to this story. The SDN controller uses two special interfaces, take a look at the image below:

The interfaces are called the northbound interface (NBI) and southbound interface (SBI). Let me explain both…

Southbound Interface

The SDN controller has to communicate with our network devices in order to program the data plane. This is done through the southbound interface. This is not a physical interface but a software interface, often an API (Application Programming Interface).
An API is a software interface that allows an application to give access to other applications by using pre-defined functions and data structures. I’ll explain more about this in a minute.
Some popular southbound interfaces are:

• OpenFlow: this is probably the most popular SBI at the moment, it’s an open source protocol from the Open Networking Foundation. There are quite a few network devices and SDN controllers that support OpenFlow.
• Cisco OpFlex: this is Cisco’s answer to OpenFlow. It’s also an open source protocol which has been submitted to the IETF for standardization.
• CLI: Cisco offers APIC-EM which is an SDN solution for the current generation of routers and switches. It uses protocols that are available on current generation hardware like telnet, SSH, and SNMP.

Northbound Interface

The northbound interface is used to access the SDN controller itself. This allows a network administrator to access the SDN to configure it or to retrieve information from it. This could be done through a GUI but it also offers an API which allows other applications access to the SDN controller. You can use this to write scripts and automate your network administration. Here are some examples:

• List information from all network devices in your network.
• Show the status of all physical interfaces in the network.
• Add a new VLAN on all your switches.
• Show the topology of your entire network.
• Automatically configure IP addresses, routing, and access-lists when a new virtual machine is created.

Here’s an illustration to help you visualize this:

Through the API, multiple applications are able to access the SDN controller:

• A user that is using a GUI to retrieve information about the network from the SDN controller. Behind the scenes, the GUI is using the API.
• Scripts that are written in Java or Python can use the API to retrieve information from the SDN controller or configure the network.
• Other applications are able to access the SDN controller. Perhaps an application that automatically configures the network once a new virtual machine is created on a VMware ESXi server.

REST API

I have mentioned a few times that the north- and southbound interfaces use APIs. Let’s take a closer look at what an API is. SDN controllers typically use a REST API (Representational State Transfer).
The REST API uses HTTP messages to send and receive information between the SDN controller and another application. It uses the same HTTP messages that you use when you browse a webpage on the Internet or when you enter a contact form online:

• HTTP GET: used when we want to retrieve information.
• HTTP POST/PUT: used when we want to upload or update information.

It is similar browsing a webpage, only this time, you are not requesting a webpage or picture but a particular object from the SDN controller, for example, a list with all VLANs in the network.
When the SDN controller receives the HTTP GET request, it will reply with an HTTP GET response with the information that was requested. This information is delivered in a common data format. The two most used data formats are:

• JSON (JavaScript Object Notation)
• XML (eXtensible Markup Language)

Here’s an example to help you visualize this:

Above we have a python script that is using HTTP GET to fetch the following URL through the API:
https://192.168.1.1:8443/sdn/v2.0/net/nodes
This URL will retrieve some of the variables that are available, for example, information about all nodes (hosts) on the network.
Once the API receives this, it will respond with an HTTP GET response message:

The variables that were requested will be supplied in JSON format. Here’s what this looks like:

{
 "nodes": [
  {
  "ip": "172.16.1.1",
  "mac": "fa16.3e5d.f1f4",
  "vid": 0,
  "dpid": "00:00:00:00:00:00:00:03",
  "port": 1
 }, {
  "ip": "172.16.1.2",
  "mac": "fa16.3e5d.f1f5",
  "vid": 0,
  "dpid": "00:00:00:00:00:00:00:03",
  "port": 2
 }
]
}

Even if you have never seen JSON before, the output above is easy to read. It tells us that we have two nodes on the network, their IP, and MAC addresses.

Conclusion

I hope this lesson has helped to get a global understanding of what SDN is about and why the market is looking for solutions like this. In some other lessons, I will give you some configuration examples of SDN solutions like Open SDN, Openflow, OpenDayLight, Cisco ACI and Cisco APIC-EM.
Time will tell what networking will look like in the future. It’s likely that we will be using APIs more often than the CLI in the future. Is this a problem? If you ask me, not really. First of all, a programmer might be very strong in programming languages like C/C+, Java or Python but he/she also requires networking knowledge. Understanding how to use a programming language to run some basic scripts will be very helpful, you don’t have to build an entire application from scratch…that’s a programmer’s job.
It might be wise though to spend some time learning a programming language like Python and how to use APIs. At the moment we don’t know how popular SDN will be but this scenario might be a bit similar to what happened to analog telephony. There are a lot of “telephony veterans” that refused to learn about VoIP because they thought analog telephony has always worked. A few years later, they are dinosaurs in a world dominated by VoIP