Route Manipulation Using Sdn and Quagga

Transcription

1 University of Colorado, Boulder CU Scholar Interdisciplinary Telecommunications Graduate Theses & Dissertations Interdisciplinary Telecommunications Spring Route Manipulation Using Sdn and Quagga Chinmay Abhay Joglekar University of Colorado at Boulder, Follow this and additional works at: Part of the Databases and Information Systems Commons Recommended Citation Joglekar, Chinmay Abhay, "Route Manipulation Using Sdn and Quagga" (2017). Interdisciplinary Telecommunications Graduate Theses & Dissertations This Thesis is brought to you for free and open access by Interdisciplinary Telecommunications at CU Scholar. It has been accepted for inclusion in Interdisciplinary Telecommunications Graduate Theses & Dissertations by an authorized administrator of CU Scholar. For more information, please contact

2 Route Manipulation using SDN and Quagga by Chinmay Abhay Joglekar A thesis submitted to the Faculty of the Graduate School of the University of Colorado in partial fulfillment of the requirements for the degree of Master of Science Department of Interdisciplinary Telecommunications 2017

3 This thesis entitled: Route Manipulation using SDN and Quagga written by Chinmay Abhay Joglekar has been approved for the Department of Interdisciplinary Telecommunications Dr. Levi Perigo Prof. Joe McManus Prof. Kevin Epperson Date The final copy of this thesis has been examined by the signatories, and we find that both the content and the form meet acceptable presentation standards of scholarly work in the above mentioned discipline.

4 iii Joglekar, Chinmay Abhay (M.S., Telecommunications Engineering) Route Manipulation using SDN and Quagga Thesis directed by Prof. Dr. Levi Perigo Software Defined Networking (SDN) is reshaping the networking paradigm. Previous study on SDN shows that SDN implementation has advantages over the traditional network. Enhancing the existing SDN functionality to the global network level, this study examines how utilizing the flexibility and programmability of SDN will benefit BGP inside the autonomous system (AS), and facilitate the transition to next generation transport networks. This research provides a Route Manipulation application in which the SDN controller manipulates routes in the SDN per the BGP updates received from the neighboring peer. The automation in this application provides a new way for the functioning of an AS with the use of the RYU SDN controller. Using SDN at a global network level will give advantages such as increased efficiency, reduced human errors due to automation, faster convergence, and cost effectiveness. The application will provide a new scope to the use of SDN at a global network level.

5 Dedication I would like to dedicate this thesis to my parents.

6 v Acknowledgements I would like to thank Dr. Levi Perigo for his important suggestions during the thesis work. I would also like to thank Zhang Lui for helping me in the initial stages of the thesis.

7 vi Contents Chapter 1 Introduction Problem Setting Research Question Literature Review Background SDN Why SDN? Components of SDN BGP BGP s importance in SDN bgpspeaker program in RYU Quagga REST API Application Purpose of the Route Manipulation application Network design and Implementation Results Conclusion and Future Work 22

8 Bibliography 24 vii

9 viii Figures Figure 2.1 SDN Infrastructure Evolution of Networking Devices SDN topology in Mininet BGP Topology Network Design and Setup bgpconfig.py file snippet Function configuration Function configuration Command to run bgpspeaker Command to run the the application Application running snippet SDN flows

10 Chapter 1 Introduction 1.1 Problem Setting Border Gateway Protocol (BGP) is a protocol which is responsible for interconnection between different Internet Service Providers (ISP). The behavior of BGP makes it vulnerable with respect to efficiency and time. With the increased number of nodes in the internet, the probability of network topology changes increases. The addition of new nodes and decommissioning of the old ones, justify the need of faster convergence and efficient updates of the routing table. The current BGP protocol in use is lacking the ability to converge faster as the internet scales. The convergence at the ibgp level is important for the BGP updates. 1.2 Research Question The research question this study aims to answer is can an SDN controller converge the network at a global level if a traditional BGP peering connection is lost? To answer this question, the researcher will implement SDN at a global network level and addresses the convergence issue at the ibgp level by developing a route-manipulation application to manipulate paths in the SDN per the BGP updates received from the BGP neighbor using the RYU controller as the BGP speaker inside the AS.

11 2 1.3 Literature Review There has been research on the methods which can reduce the time of BGP convergence, a BGP functionality which is considered vulnerable due to the massive growth of the internet. Most of the proposed methods focused on reducing the Minimum Router Advertisement Interval (MRAI) timer of BGP. [10] and [14] added a SDN approach in solving the problems related to the BGP convergence time. The proposals discussed in these papers were to have SDN controlled devices at specific locations in different ASes. [10] concluded that the BGP convergence rate can be increased with the help of introducing UPDATEs from multiple vantage points that specify the existence of SDN controlled devices. This research lacked to prove the worst-case bounds in relation with the convergence time. [14] introduces the approach where the IP protocol is being implemented on the SDN based device. [12] discussed about the LINUX operating system based SDN application (QUAGFLOW). This paper provided insight on the application to use SDNs OpenFlow. It was possible to achieve communication between the QUAGFLOW subnet and the legacy network. The problem with QUAGFLOW is that there are issues that need additional attentions and evaluation in the virtual environment. These issues are the replication of data plane events such as the link failures, the optimization of the protocol timers and VM managing frameworks. Thus, this has scope to improve and explore. [11] introduced a multi-path flow transfer mechanism for high availability and efficiency of the transfer of data in a data center. This mechanism does an iterative multi path detection process with respect to different domains in a data center. The experiments conducted provide results that show increased network throughput and network resource utilization. The enhancement of BGP convergence is possible also if there is routing centralization [13]. This paper performed the analysis on the route centralization in inter-domain routing to check for the convergence time of BGP. The tests were conducted on different randomly generated topologies in the simulations. The results that were generated were found to reduce the convergence time and this had smaller differences between different topologies [13].

12 3 There was a new mechanism proposed for an SDN controller [16]. This paper proposed a new protocol OFBGP which serves as an application of SDN. The design of this protocol is like BGP, but it is more distributed. Three modules are those that collaborate to form this protocol. Out of these the two modules BGP decision and BGP protocol perform the main tasks of BGP. The BGP decision does the decision process and BGP protocol performs the machine state transitions [16]. The researchers performed OFBGP and found out that further reduction in the communication traffic between tasks is required along with route aggregation and internal routing policies. Route centralization was implemented in a way to know the interaction between the SDN controller and BGP routing protocol [15]. This paper used Dijkstra algorithm to compute the shortest path for all the routes. The authors made use of a hybrid SDN-BGP emulation framework and a multi-as SDN controller that runs as an overlay to the edge routers. The usage of multi-as SDN controller was specified but how to achieve this in the actual internet was not given. The communication between these SDN controllers needs to be understood as well as the time elapsed between this also needs to be taken into consideration. There is another important use of BGP and SDN and that is in the data centers. [8] is a conference presentation that provided insight on the problem of the routing logic, which sometimes requires modification of the ECMP behavior used for load balancing the traffic in the network. This presentation provided a different logic behind programming the forwarding information base of the protocol by having a central controller. Additional ECMP backup paths would also be available if any failover happens in the network [8]. These studies provide important insight on how SDN can be viewed as the more probable solution to improve the vulnerabilities of BGP. In fact, SDN can be a user defined protocol accommodating the requirements of the network. This means that the network operator can create its own service which will perform the functions of a routing protocol. One such SDN application is SDN-IP, which uses Open Network Operating System (ONOS) [14]. This application generates flow entries based on intents, an algorithm that generates flows based on what the network operator intends to do with that flow. This application installs the flows proactively in the ONOS controller controlled devices. This study claims that the Routing Information Base of the SDN device can

13 4 hold about 10,000 entries [14]. However, this application has all the configurations static and there was a need for dynamic configuration so that the application can be used in different network topologies. Also, this application did not initiate a BGP peer connection. These drawbacks made the application less favorable for this thesis. This thesis uses the Python-based bgpspeaker program on a RYU controller. The bgpspeaker program can produce the basic functionality of the BGP protocol and it can initiate, as well as listen to, the BGP peering connection as opposed to the ONOS application that can only listen to the peering connection. The working of the program is discussed in detail in the following chapters. There are new technologies that are helping to enhance the functionality at different layers of the OSI model (Open Systems Interconnection Reference model). The use of SDN at the network layer will be beneficial [3]. The controller will have the logical centralized control over the entire network layer. It will provide high availability and scalability to the networking devices. It will also avoid misconfigurations that might happen due to human error as all the flow table entries in the devices will be centrally controlled. Since, all the networks in the internet cannot be directly replaced by an SDN controlled network, we need a method which will have the benefits of both the traditional as well as SDN controlled network. This thesis provides an SDN path manipulation application, which utilizes the bgpspeaker program for BGP peering connections. The application will manipulate the flow entries of the OPENFLOW SDN switches via the RYU controller controlled SDN switches to redirect the path for destination prefixes received from the BGP peer when the connection to the BGP peer goes down. Moreover, this application can reinstate the original entries if the BGP peer connection is restored. This review of literature shows the advantages and capabilities of having an SDN layer in an enterprise network would be beneficial. Furthermore, the automation and reactive flow entries added in the network by the SDN application would make the network reliable and efficient, and automation would reduce the configuration errors that can be possible if the configurations are done manually. This study shows that an SDN environment will reduce the convergence of BGP if any of the peering connections are lost, and the application developed from this research can have

14 additional features to determine congestion, change bandwidth, and modify BGP attributes. 5

15 Chapter 2 Background this thesis. This chapter provides a background about the different concepts and technologies used in 2.1 SDN Figure 2.1: This figure [3] shows the SDN infrastructure. The three layers are Application, Control and Forwarding. This section discusses the details of SDN, how it is beneficial in networking, and the components of the technology.

16 7 The Open Networking Foundation (ONF) defines SDN as a networking model that separates the network control plane from the forwarding plane, and logically centralizes the control in the controller. The centralized controller controls the devices in the network. These devices are often referred to as next generation devices, switches, or the infrastructure layer devices [3]. For this study, these devices will be referred to as switches. ONF states that SDN is categorized into three layers representing different devices and/or software applications 2.1. First, the control plane takes all the logical decisions of networking. These decisions are centralized in SDN controllers [3]. The controller also has the entire view of the network. Second, the infrastructure layer represents the forwarding plane. The devices in the forwarding plane are controlled by the controller in the control plane. The third layer is the application layer which represents the application plane. The application plane contains the programs that communicate the desired network requirements to the SDN controller which then performs the functions along with the forwarding plane. The forwarding plane works on the flow entries received from the controller. These flow entries are a set of rules which the device applies to the received packet [3]. These flows entries act as a chain of rules, similar to firewall entries, but not limited by the higher layers of the OSI model. 2.2 Why SDN? Figure 2.2: This figure [9] shows the evolution of the network devices over time. The evolution of networking devices shows that the processes using software and hardware

17 8 have changed over the years. The technological development in the networking devices shows that most of the processes are done in the hardware for faster computation and actions instead of software [9]. Gorannson and Black have depicted the evolution as shown in 2.2. This shows how the software and the hardware sections of the networking devices evolved to provide functions of the different layers of the OSI model. Gorannson and Black also talk about the advantages of SDN and why it would be a better solution for the current behavior of networking devices. One advantage they discuss is that SDN simplifies the network behavior [9]. The simplification is due to the separation of the forwarding and control planes. Also, SDN would be cost effective in contrast with the increasing costs for new devices. SDN controllers are programmable as the control plane is decoupled from the forwarding plane [3]. This does not require any vendor specific hardware and thus, network administrator does not require to have one vendor for the network. This also helps in reducing the cost of purchasing the network devices as the vendor products are expensive. There are also whiteboxes (computer hardware without an operating system) that can be loaded with the required network operating system and thus, SDN does not require vendor specific devices. These whiteboxes can be installed with open source software and SDN can be implemented. Open source products are inexpensive and this will allow reduced capital expenses for the network infrastructure. SDN would also provide automation for the processes which are extremely sensitive and those which cannot sustain human errors as the services can be programmed by the SDN controller. Also, SDN devices are compatible with the present version of the network devices. Such devices are called Hybrid SDN switches which can be used for connecting an SDN to a traditional network. 2.3 Components of SDN The core part of SDN is the SDN controller. A controller is an application which is responsible for making the logical decisions in an SDN network. The controller manages all the southbound devices in an SDN network and installs the flow entries in the SDN devices. Some of these flow entries are generated after going through a logical decision making process. Such entries are called

18 9 reactive flow entries. Other type of flow entries are the proactive flow entries, which are flow table entries that are installed predicting or determining the conditions of the network. For example, a flow entry to change the network topology if the bandwidth utilization exceeds a threshold value would be a proactive flow entry. The controller, thus, can be thought of as the brain of the SDN [9]. There are different controllers that are currently used for SDN. This thesis uses RYU, an open source SDN controller along with the BGP peer in the topology. The main advantage of choosing RYU was that it is written in Python which is a friendly programming language [4]. The controller is open source (i.e. no proprietary on the code which means free to use and experiment) and thus the bugs and support is available from the developers across the globe. Also, the RYU bgpspeaker application which is discussed in the later chapters can be modified according to the requirements of the topology and can have additional features added to it. Another component of SDN is the infrastructure layer SDN devices or switches. These SDN switches are not traditional layer 2 switches but they can be bare metal boxes, vendor proprietary operating system devices, or vendor hybrid switches. The term switches is a generic term given to the SDN device. They can represent a switch, router, firewall, or any other network infrastructure device depending on the network design and programming applications. Typically, these devices communicate with the SDN controller using OpenFlow protocol. They receive flow entries from the controller and then perform the actions on the received packets according to the matched flow entry for that specific packet in the flow table. There is commonly a default flow entry present in the flow table called the table-miss entry [9]. This entry is for the packets that do not match any of the flow entries in the flow table, and need a decision to be made. These packets are sent to the controller to make a logical decision and then the controller can send a flow entry for such a packet for future processing and handling [3]. The third component of SDN is the Application layer. This layer is used to manipulate the SDN controller. The applications in this layer communicate with the SDN controller to perform functions on the SDN switches. This layer enables innovation and helps in providing new features

19 10 and services to the network with the help of the applications [3]. The next sections talk about the BGP protocol. It discusses the details of the protocol, how it is beneficial in SDN, and why it needs to be used with SDN. 2.4 BGP BGP is a protocol that is responsible for the communication between different ASes. It is used for exchanging the prefixes among the ASes as well as exchanging neighbor relationship information such as peer, customer or transit depending on the ASes function and tier level. BGP uses TCP port 179 to listen to the connections from the neighboring BGP peers [1]. This section discusses BGPs importance in SDN, as well as its role in this thesis. 2.5 BGP s importance in SDN The controllers in SDN typically communicate with the next generation networking devices via the OpenFlow protocol which creates a TCP connection between the entities. The TCP connection is used for management purposes. If there are multiple SDN controllers (generally used to have redundancy), these controllers talk to each other via BGP. Also, currently, the ASes of the ISPs use BGP to form BGP-neighbors and exchange the routing information with each other [1]. Thus, to perform experiments and to do research on SDN at the AS level, it is necessary to include BGP compatibility towards SDN so that SDN functionality is compatible with the standard protocol of the internet [1]. BGP is considered to be the protocol of the internet [1]. Extending SDN to a global network level, it needs to be able to communicate with other traditional global networks and since BGP is the best way to communicate at that level, incorporation of BGP into SDN is extremely important. This is an advantage as there is no need to change the infrastructure of other networks. Also, having an existing protocol makes the new technology familiar to implement. Developers around the world are developing code that performs the functions of BGP in an SDN [6,14]. This thesis uses BGP as a protocol to communicate between two different ASes, where one AS is traditional,

20 11 and the other AS has devices controlled by the SDN controller. The BGP controller code running on the RYU controller is called the bgpspeaker. This code listens to the BGP messages on TCP port 179 for a connection. The code is modified to perform per the requirements of the network topology and perform the required functions. These are discussed in the following sections. 2.6 bgpspeaker program in RYU This is a program in RYU controller developed to have BGP functionality for RYU. Python modules have been created to serve this purpose [6]. These modules are specifically designed to implement BGP from the system level and create BGP packets and segments for proper communication between the RYU controller and the neighboring BGP speaker. The bgpspeaker program functions with the help of a JSON file, which receives all the required configuration inputs from the user. This file is parsed as the input to the functions inside the application.py file, which invokes the bgpspeaker.py file and eventually starts the BGP daemon on the RYU controller [6]. The JSON file inputs need to be fed manually to start the application. The inputs include the router identity of the RYU BGP speaker for communication with the other neighboring peers, the local AS number, neighboring peer address (router identity) and AS number, and prefixes to be advertised to the peers. The application.py file takes the inputs from the JSON file and parses it as arguments to the functions defined inside [6]. The application.py file has functions by default, and there is a facility to create additional functions. The RYU speaker class also has additional functions that can be run for better functionality. This flexibility and scalability in this application helped decide its use in this study. The usage of the application is explained in detail in the next chapter. 2.7 Quagga Quagga is a routing protocol suite on Unix platforms [5]. There is a zebra daemon, which forms the base of the Quagga architecture. This daemon talks to the Unix kernel and uses an Application Programming Interface (API) to communicate with Quagga. The zebra daemon runs

21 12 the other daemons for the routing protocols such as OSPF, RIP, and BGP if they are enabled by the user. Quagga also has a vty shell, which can be used to enter configuration commands for the protocol daemons that are running on the shell. The command line interface configuration of the Quagga protocol suite is similar to the configuration of traditional vendor-specific routers. The implementation of traditional routers for the thesis in a virtual environment was required. Quagga was the best solution for it as it provides traditional router functionality. 2.8 REST API REpresentational State Transfer (REST) is a web application programming interface. It is used for requesting data over the HTTP service and receiving the requested data in response. This API is available for RYU controller. It works in Python for the next generation network devices with the help of ofctl_rest.py code [7]. When this code runs, it enables the web API which can be used to install flows in the SDN switches, get data from the switches or modify other data. The code receives the API request, and then converts it to OpenFlow specific formatting and transmits it to the SDN switches. The REST API has three requests that are HTTP requests: GET, POST, and PUT [7]. GET is used to receive information from the SDN switches. POST is used to push information, or add information to the SDN switches and PUT signifies modification of an existing information. This study uses the ofctl_rest.py (REST API for RYU controller) to receive DPIDs (the identifiers to uniquely identify SDN switches) from the switches, and install specific flows in the switches, and delete the flows in the SDN switches. The REST API for RYU makes the Route Manipulation application, developed in the thesis, dynamic as the SDN switch identifiers are taken dynamically from the network. This means that even if the switches are changed, the application would continue work. The details of the application are discussed in the next chapter.

22 Chapter 3 Application The previous chapter discussed the various components of the thesis. This chapter discusses the Route Manipulation application developed for this thesis in detail. 3.1 Purpose of the Route Manipulation application The route manipulation application was designed to check the working of the bgpspeaker code in RYU for a specific network topology and condition. This network topology was considered because the current networking devices are getting replaced by SDN devices and soon the SDN devices will dominate the entire network and thus, the AS. The scenario is designed in a way that there is a master SDN controller controlling the network in the AS and the same master controller has a bgpspeaker code running. The bgpspeaker code is responsible for BGP protocol peering connections and the protocol functioning with the other ASes which are still using the traditional networking devices. The purpose is to test the BGP speaker application and determine the feasibility of BGP failure. If a peer loses connection, then can the entire network converge on that one notification. Using Quagga as a traditional BGP AS peer and REST API to manipulate routes in the SDN, the bgpspeaker program within RYU is used to check the peering as well as collect the routes advertised by the neighboring peer.

23 Figure 3.1: This figure shows the SDN topology in Mininet with six SDN switches connecting to the RYU SDN controller 14

24 Network design and Implementation The network topology for testing the Route Manipulation application is setup in a virtualized environment using VirtualBox. The SDN devices used in the thesis were generated with the help of Mininet, which is a virtualized SDN testing environment composed of SDN switches and Linux hosts [2]. The Mininet network can be connected to the controller as shown in 3.1. Figure 3.2: This figure shows the BGP logical topology in this study BGP functionality in this thesis is implemented using the topology shown in 3.2. The Quagga routing protocol suite is used to perform the functionality of the traditional routers. The topology shown was implemented in a virtual environment using the hypervisor VirtualBox. The three blocks in the topology are running on different virtual machines. The network setup is shown in the 3.3. The RYU controller is at the center with the local ASs SDN network connected to the RYU controller. The virtual machines running the Quagga routing protocol suite are a part of a different AS. They have BGP peering connection with the bgpspeaker application running on the RYU controller. The RYU controller is also running the REST API for RYU as well as the route-manipulation.py code which is the code for the route manipulation application developed by the researcher. This code function is explained in the following section. There are six SDN switches running on Mininet which is connected to the RYU controller. The bgpspeaker code opens the TCP 179 port connection with the Quagga routers as well as listens to other peering connections. The BGP speaker exchanges the Keepalive messages with its

25 Figure 3.3: This figure shows the Setup of the application environment. There are six SDN switches with RYU controller running the applications in one AS. The two Quagga router VMs are in the second AS. 16

26 17 peers and exchanges the route prefixes that are being advertised by the peers. This bgpspeaker application also advertises its own network which is connected to the SDN switch s4. The next section details the working of the application. 3.3 Results Figure 3.4: Configuration of BGP parameters for the controller s BGP instance The initial conditions of the network are shown in 3.3. The local AS of the SDN network is AS 65001, and for the traditional network, consisting of Quagga routers, is AS The configuration file that contains all these details is the bgpconfig.py file. The snippet of this file is shown in 3.4. bgpspeaker file: application.py Within the RYU SDN controller, the bgpspeaker file has functions required for the establishment of BGP between two neighboring peers, which check whether the established peer is up or down, as well as adding and removing BGP peers. All the functions that are defined by the RYU bgpspeaker.py can be used in the Route Manipulation application, which will be discussed in the

27 18 following section. The Python function to add a BGP neighbor was modified for this study. A new function was added to receive all the routes advertised by the peer, and extract the prefix information from that list of advertised routes. These prefixes are then used by the route-manipulation.py application to install flows in the six SDN switches so that these switches can route the received packets for these prefixes as destination according to the OpenFlow flow entries installed. The Route Manipulation application makes the flow installation of the prefixes dynamic, as it receives all the prefixes in a variable. Figure 3.5: Function to get routes from the neighbor The flows are installed from the routes received from the newly created function _get_neighbor in the application.py file. 3.5 shows the configuration for the function. This function waits for a time to get all the routes in the routing table of the SDN controller and then it extracts those routes using the existing function [6]. The extracted routes are fed to a file that will be used by the route-manipulation.py application to install flows for the prefixes. Figure 3.6: Function to get BGP peer notification 3.6 shows the peer up and down functions. These functions are triggered when the associated event occurs. This function is modified to inform the route-manipulation.py application that the

28 19 peer is up or down and the flows in the SDN switches need to be modified accordingly. This is done by inserting values of 0 or 1 in a file, which is then checked by the application to determine what set of flows to install in the SDN switches. The set of flows are determined based on where the packet needs to travel to get to the next AS, as shown in the 3.10 Figure 3.7: This is the command to run the bgpspeaker on RYU SDN controller These functions are the ones that were used during this study. The command to run the bgpspeaker code is shown in the 3.7 Once this command runs, all the functions are called and then the respective files are written to indicate what flows need to be installed. But first, SDN switches should have connection to the RYU controller and the Quagga routers to have proper functionality (3.3). The Mininet network should be initialized by using the sudo mn command. The REST API for RYU should also be enabled as the application code route-manipulation.py runs along with the ofctl_rest.py. This should be run using the RYU-manager command that is shown below in 3.8 Figure 3.8: This is the command to run the Route Manipulation application on RYU SDN controller along with REST API route-manipulation.py The Route Manipulation application file installs the flows and changes them per the BGP events taking place in the network. This file takes inputs from the two text files that are fed with information by the RYU bgpspeaker application. The first file gives the input 1 or 0. This determines the flow entries in the SDN switches. The flow entries are directing to one of the Quagga routers. So, if BGP router Quagga 1 goes down, the peering connection down function will trigger the file change and this will direct the flows through s6 to BGP router Quagga 2. If Quagga 1 restores the BGP connection, then the original flows will be reinstalled into the SDN switches after

29 20 the previous flows are removed. In addition to this, the code also checks the contents of the text file whose contents are fed by the neighboring peer prefixes. These prefixes are collected in the form of a list, and the list elements are then fed into the SDN switches as a flow entry. The code runs in an infinite loop to continuously check for a match condition. The route-manipuation.py code is the application that does the SDN path manipulation in the SDN network depending on the events triggered by the bgpspeaker application. The initial working is shown in 3.9. Figure 3.9: This figure shows the snippet of the Route Manipulation Application The image shows that the app is loaded to RYU manager and the initial stage when there is peer connection, the number in the file is 0 and the original flows will be installed in the SDN switches shows the working of the flows. The green colored arrows show the flow entries when the peer is up, and the blue arrows show the path failover flows when the traditional BGP peer is down. The Route Manipulation application provided by the research presents important insights such as scalability, faster convergence inside the AS because of limited ibgp speakers (one in this case), as well as automation to install flows based on the network conditions can be implemented with the help of APIs. Also, these results show that SDN will have better standing at a global network level.

30 Figure 3.10: This figure shows the SDN flow directions depending on the BGP peer connection 21

31 Chapter 4 Conclusion and Future Work This study helped prove that SDN is a viable solution to provide faster, more efficient BGP convergence and failover in an AS while connecting to a traditional BGP network. Also, this topology design reduces the processing power of the edge routers as all the logical processing is done by the RYU SDN controller. The use of bgpspeaker code also shows some fallacies in the application and gives direction for future work. Developing the Route Manipulation application for this study provided important insight to the way SDN switches behave in regards to BGP convergence. Convergence is an issue in BGP, which this thesis attempted to solve by providing a way that BGP can converge internally in the AS, and propagate these changes in the SDN OpenFlow flow table entries. These flow entries takes less time than the convergence updates sent by the internal routing protocols as well as ibgp. On a larger scale, this can be enhanced by having different functions and flows created for different combinations of BGP-related events. Accordingly, the flows can be installed and the system can converge in a faster, and more efficient way. RYUs bgspeaker application is flexible and has available documentation. The network operator can add additional features as per the requirements in the form of Python programming language functions. This application has a functionality of adding BGP attributes to the updates that are being sent to the other traditional edge routers. This helps in keeping an equilibrium with the traditional network as well as work with the SDN. This study provided a Route Manipulation application that changes the flow entries in the

32 23 SDN depending on the updates received from the traditional network BGP neighboring peers. The application developed gave insight on the working of the RYU controller in handling the updates. This is done with the help of the application code which runs in an infinite loop to continuously test for the condition match. Also, since the application automates SDN flow installation based on the updates received, the application can match a list of valid routes and can prevent illegitimate routes from advertising into the internet. The future scope for this study can be improved by testing the same network topology, but in physical environment, instead of virtual. Also, different SDN controllers can be tested to evaluate funxtionality such as convergence, processing and flow manipulation. Additional BGP and SDN features such as Time of Day, modification of BGP attributes, and advertising the routes coming from other ASes dynamically, can be done using the base of the application.py code and the Route Manipulation application developed from this research.

33 Bibliography [1] Bgp rfc [2] Mininet reference. [3] Open networking foundation. [4] Python reference. [5] Quagga routing protocol suite. [6] Ryu bgp speaker application reference. [7] Ryu rest api reference. [8] P. Lapukhov A. Abouchaev, T. LaBerge and E. Nkposong. Brain-slug: A bgp-only sdn for large-scale data-centers. [9] P. Goransson and C. Black. Software defined networks: a comprehensive approach. [10] M. Gulzar F. Zafar H. Kazmi, H. Nawaz and A. Gehani. Bgp is high on sdn: Improving bgp convergence and security using sdn and reassertions. [11] L. Junzhou J. Jian L. You, L. Wei and X. Nu. An inter-domain multi-path flow transfer mechanism based on sdn and multi-domain collaboration [12] Marcos Rogerio Salvador Marcelo Ribeiro Nascimento, Christian Esteve Rothenberg and Maurcio Ferreira Magalhaes. Quagflow: Partnering quagga with openflow. [13] X. Dimitropoulos P. Sermpezis. Inter-domain sdn: Analyzing the effects of routing centralization on bgp convergence time [14] Umesh Krishnaswamy Tetsuya Murakami Masayoshi Kobayashi Ali Al-Shabibi Kuang- Ching Wang Pingping Lin, Jonathan Hart and Jun Bi. Seamless internetworking of sdn and ip [15] A. Gamperli V. Kotronis and X. Dimitropoulos. Routing centralization across domains via sdn: A model and emulation framework for bgp evolution [16] D. Li Y. Zhou R. Liu L. Ruan-Y. Xia W. Duan, L. Xiao and M. Zhu. Ofbgp: A scalable, high available bgp architecture for sdn