Design and development of the reactive BGP peering in softwaredefined routing exchanges

Transcription

1 Design and development of the reactive BGP peering in softwaredefined routing exchanges LECTURER: HAO-PING LIU ADVISOR: CHU-SING YANG ( 1

2 Introduction Traditional network devices are verticallyintegrated black-boxes. Software-defined networking (SDN) separates the data plane and the control plane of the network. allowing centralized control data plane devices just perform packet forwarding The logical view of a SDN architecture 2

3 Introduction (cont.) To deploy SDN in WAN, the ongoing researching direction is to gradually convert legacy networks into SDN or hybrid networks. Many papers mention about using BGP to exchange routes between legacy networks and new SDNenable networks. In this paper, we design a reactive BGP peering in SDN routing exchanges. 3

4 Scenario 4

5 System design Integrating the BGP capability to the central control of SDN Virtual BGP entity BGP messages are encapsulated as OpenFlow packet-in messages and then sent to the controller. BGP peer Packet-in controller Packet-out Similarly, the replies from the controller are also encapsulated as OpenFlow packet-out messages. Legacy Network BGP msg SDN r1 s1 5

6 Architecture (cont.) Main module initiates the virtual BGP entity. Reading the configuration Installing flow rules to match BGP packets Main module receives the request and returns the replies to the corresponding switches. Protocol Handler module is responsible for parsing the packets and generating replies. 6

7 System design Peering mechanism To achieve the BGP peering, we need to handle the entire control of the communication. ARP query TCP 3-way handshake TCP SYN ARP Request BGP query BGP Open TCP SYN/ACK RIB Our Neighbor TCP ACK ARP BGP Reply Open Virtual BGP Entity The Protocol Handler module is designed in a layered manner to handle packet headers at different protocol level. 7

8 System design RIB update BGP Handler module is responsible for extracting the routing information. BGP update BGP Handler RIB Handler module is responsible for modifying the RIB. Routing information entries The SDN domain should also advertise this update message to the other neighbors to continue the information propagation. RIB Handler Insert Delete RIB (Memory) 8

9 System design Software-defined Routing Mechanism This mechanism is designed to provide a path for inter-domain IP traffics. External network Install flow rules Path Handler module is responsible for selecting the flow path and installing the flow rules. IP packet Install flow rules Install flow rules IP packet External network 9

10 System design Software-defined Routing Mechanism (cont.) However, these IP packets will be dropped. Neighbors regard the virtual BGP entity as the next hop. Adding a destination MAC address rewrite action to change the destination MAC address of the packets. Adding a TTL descending action. External network IP packet My next hop is Virtual BGP Entity forward MAC rewrite, TTL-1 forward forward Wrong destination MAC address! IP packet External network 10

11 System design Software-defined Routing Mechanism (cont.) To avoid the excessive number of flow rules on the switches, we can utilize the idle timeout control provided by the OpenFlow protocol. If a flow rule is idle for certain time period, the flow rule will be eliminated automatically. 11

12 Experimental environment In the topology we use: Mininet as the network emulator MiniNet Quagga as the software routing suite used by r1, r2 and r3 Open vswitch provided by Minint as the SDN switch used by s1, s2 and s3 Ryu as the SDN controller 12

13 Experiment result We start Ryu with our approach as an application to control the topology. The figure shows every BGP router records the IP prefix of other ASes. The SDN domain can properly receive the BGP update messages and advertise to the others. 13

14 Experiment result (cont.) We do the Ping tests between the hosts to check the availability of flow paths. As the figure shows, we confirm that each host can receive the IP packets sent from the others. 14

15 Discussion We have achieved the basic stitching between these two type of network paradigms. However, we have not tested our system with the BGP routers in the real internet environment. Scalability issues are predictable due to the restriction of the size of flow tables in the switches and the performance of single controller. 15

16 Conclusion We design a virtual BGP entity on the SDN controller that can mask a SDN domain as a transit AS. By utilizing OpenFlow packet-in and packet-out messages, our system can exchange BGP messages with neighbors through the switches in the data plane. Our approach also provides the software-defined routing mechanism for the inter-domain IP traffics. 16

17 Q & A THANK YOU FOR YOUR LISTENING ANY QUESTIONS? 17

18 AS ( /24) AS ( /24) h1 h1-eth0: h3-eth0: h3 r1-eth1: r3-eth1: Quagga BGP router r1 r1-eth0: r3-eth0: Quagga BGP router r3 Controller control Plane (SDN) OpenFlow s1 s2 s3 AS Data Plane (SDN) r2-eth0: Quagga BGP router r2 r2-eth1: h2-eth0: h2 AS ( /24)