Software Defined Internet Exchange

 

 

Software Defined Internet Exchange

In today’s digital era, where data is the lifeblood of every organization, the importance of a reliable and efficient internet connection cannot be overstated. As businesses increasingly rely on cloud-based applications and services, the demand for high-performance internet connectivity has skyrocketed. To meet this growing need, a revolutionary technology known as Software Defined Internet Exchange (SD-IX) has emerged as a game-changer in the networking world. In this blog post, we will delve into the concept of SD-IX, its benefits, and its potential to revolutionize how we connect to the internet.

Software Defined Internet Exchange, or SD-IX, allows organizations to dynamically connect to multiple Internet service providers (ISPs) through a centralized platform. Traditionally, internet traffic is exchanged through physical interconnections between ISPs, resulting in limited flexibility and control. SD-IX eliminates these limitations by virtualizing the interconnection process, enabling organizations to establish direct, secure, and scalable connections with multiple ISPs.

 

Highlights: Software Defined Internet Exchange

  • The Role of SDN Solutions

Most existing SDN solutions are aimed at cellular core networks, enterprises, and the data center. However, at the WAN edge, SD-WAN and WAN SDN are leading a solid path, with many companies offering a BGP SDN solution augmenting natural Border Gateway Protocol (BGP) IP forwarding behavior with a controller architecture, optimizing both inbound and outbound Internet-bound traffic. So, how can we bring these existing SDN mechanisms to enhance BGP for Interdomain routing at Internet Exchange Points (IXP)?

  • The Role of IXPs

IXPs are location points where networks from multiple providers meet to exchange traffic with BGP routing. Each participating AS exchanges BGP routes by peering eBGP with a BGP route server, which directs traffic to another network ASes over a shared Layer 2 fabric. The shared Layer 2 fabric provides the data plane forwarding of packets. The actual BGP route server is the control plane to exchange routing information.

 

For additional pre-information, you may find the following posts helpful:

  1. Ansible Variables
  2. Open Networking
  3. Software Defined Perimeter Solutions
  4. Distributed Solutions
  5. Full Proxy

 



Software Defined Internet Exchange.

Key Software Defined Internet Exchange Discussion points:


  • Introduction to Software Defined Internet Exchange and where it can be used.

  • Discussion on IXP pain points and challenges.

  • What is the role of SDX, and how it works?

  • The role of OpenFlow with SDX.

 

Back to basics with the Internet Exchange.

An Internet exchange point (IXP) is a physical location through which Internet infrastructure companies such as Internet Service Providers (ISPs) and CDNs connect. These locations exist on the “edge” of different networks and allow network providers to share transit outside their network. IXPs will run BGP.

Also, it is essential to understand that Internet exchange point participants often require that the BGP NEXT_HOP specified in UPDATE messages be that of the peer’s IP address, as a matter of policy.

 

Benefits of SD-IX:

1. Enhanced Performance: SD-IX enables organizations to bypass the public internet and establish direct peering connections with ISPs. By reducing the number of network hops and congestion points, SD-IX improves network performance, resulting in lower latency and faster data transfer speeds.

2. Improved Reliability: SD-IX allows organizations to create redundant connections with multiple ISPs, ensuring high availability and resilience. In an ISP outage, traffic can be seamlessly rerouted through alternate connections, minimizing downtime and ensuring continuous connectivity.

3. Cost Efficiency: SD-IX eliminates the need for physical infrastructure and costly cross-connect fees by virtualizing the interconnection process. Organizations can leverage SD-IX to establish private interconnections with multiple ISPs at a fraction of the cost, significantly reducing network expenses.

4. Scalability and Flexibility: SD-IX allows organizations to scale their network connections on demand. Adding or removing connections can be complex and time-consuming with traditional interconnections. SD-IX simplifies this process by allowing organizations to provision and manage connections through a centralized portal, enabling rapid network expansion or modification.

5. Enhanced Security: SD-IX enables organizations to establish private, direct connections with ISPs, reducing exposure to potential security threats associated with the public internet. By bypassing the public internet, SD-IX provides a secure and controlled environment for data transfer, ensuring confidentiality and integrity.

 

Route Server

A route server provides an alternative to full eBGP peering between participating AS members enabling network traffic engineering. It’s a control plane device and does not participate in data plane forwarding. There are currently around 300 IXPs worldwide. IXPs are good locations to deploy SDN of their simple architecture with flat networks.

There is no routing for forwarding, so there is a huge need for innovation. They usually consist of small teams making innovation easy to introduce. Fear is one of the primary emotions that prohibit innovation, and one thing that creates fear is Loss of Service.

This holds quite a significant weight for IXP networks as they may have over 5 Terabytes of traffic per second. IXP are major connecting points, and a slight outage can have a significant ripple effect.

 

  • A key point. Internet Exchange Design

SDX, a software-defined internet exchange, is an SDN solution from the combined efforts of Princeton and UC Berkeley. It aims to address IXP pain points (listed below) by deploying additional SDN controllers and OpenFlow-enabled switches. It doesn’t try to replace the entire classical IXP architecture with something new but rather augments existing designs with a controller-based solution, enhancing IXP traffic engineering capabilities. However, the risks associated with open-source dependencies shouldn’t be ignored.

 

Software Defined Internet Exchange: IXP Pain Points

BGP is great for scalability and reducing complexity but severely limits how networks deliver traffic over the Internet. One tricky thing to do with BGP is good inbound TE. The issue is that IP routing is destination-based, so your neighbor decides where traffic enters the network. It’s not your decision.

The forwarding mechanism is based on the destination IP prefix. A device will forward all packets with the same destination address to the same next hop and the connected neighbor decides.

 

  • The main pain points for IXP networks:

As already mentioned, routing is based on the destination IP prefix. BGP selects and exports routes for destination prefixes only. It doesn’t match other criteria in the packet header, such as source IP address or port number. Therefore, it cannot help application steer, which would be helpful in IXP networks.

Secondly, you can only influence direct neighbors. There is no end-to-end control, and it’s hard to influence neighbors that you are not peering. Some BGP attributes don’t carry across multiple ASes; others may be recognized differently among vendors. We also use a lot of de-aggregation to TE. Everyone is doing this, which is why we have the problem of 540,000 prefixes on the Internet. De-aggregation and multihoming create lots of scalability challenges.

Finally, there is an indirect expression of policy. Local Preference (LP) and Multiple Exit Discriminator (MED) are ineffective mechanisms influencing traffic engineering. We should have better inbound and outbound TE capabilities. MED, AS Path, pretending, and Local Preference are widely used attributes for TE, but they are not the ultimate solution.

They are inflexible because they can only influence routing decisions based on destination prefixes. You can not do source IP or application type. They are very complex, involving intense configuration on multiple network devices. All these solutions involve influencing the remote party to decide how it enters your AS, and if the remote party does not apply them correctly, TE becomes unpredictable.

 

SDX: Software-Defined Internet Exchange

The SDX solution proposed by Laurent is a Software-Defined Internet Exchange. As previously mentioned, it consists of a controller-based architecture with OpenFlow 1.3-enabled physical switches. It aims to solve the pain points of BGP at the edge using SDN.

Transport SDN offers direct control over packet-processing rules that match on multiple header fields (not just destination prefixes) and perform various actions (not just forwarding), offering direct control over the data path. SDN enables the network to execute a broader range of decisions concerning end-to-end traffic delivery.

 

  • How does it work?

What is OpenFlow? The IXP fabric is replaced with OpenFlow-enabled switches? Now, network traffic engineering is based on granular OpenFlow rules. It’s more predictable as it does not rely on 3rd party neighbors to decide the entry. OpenFlow rules can be based on any packet header field, so it’s much more flexible than existing TE mechanisms. SDN-enabled data plane enables networks to have optimal WAN traffic with application steering capabilities. 

The existing route server does not get modified, but now we can push SDN rules into the fabric without requiring classical BGP tricks (local preference, MED, AS prepend). The solution matches on destination MAC address, not the destination IP prefix, and uses an ARP proxy to convert the IP prefixes to MAC addresses.

The participants define the forwarding policies, and the role of the controller is to compile the forwarding entries into the fabric. The SDX controller implementation has two main pipelines: a policy compiler based on Pyretic; and a route server based on ExaBGP.

The policy compiler accepts input policies (custom route advertisements) written in Pyretic from individual participants and BGP routes from the route server. From this, it produces forwarding rules that implement the policies.

The SDX controller combines the policies from multiple member ASes into one policy for the physical switch implementation. The controller is like an optimized compiler, compiling down the policy and optimizing the code in the forwarding by using a virtual next hop. There are other potential design alternatives to SDX, for example, BGP FlowSpec. But in this case, BGP FlowSpec would have to be supported by all participating member AS edge devices.

 

The Future of Networking:

As the demand for high-performance and reliable internet connectivity continues to grow, SD-IX is poised to play a pivotal role in shaping the future of networking. By virtualizing the interconnection process and providing organizations with unprecedented control and flexibility over their network connections, SD-IX empowers businesses to optimize their network performance, enhance security, and reduce costs. With its ability to scale on-demand and seamlessly reroute traffic, SD-IX is well-suited for the evolving needs of cloud-based applications, IoT devices, and emerging technologies such as edge computing.

Conclusion:

Software Defined Internet Exchange represents a paradigm shift in how organizations connect to the Internet. By virtualizing the interconnection process and providing enhanced performance, reliability, cost efficiency, scalability, and security, SD-IX offers a compelling solution for businesses seeking to optimize their network infrastructure. As the digital landscape continues to evolve, SD-IX is set to revolutionize the way we connect to the internet, enabling organizations to stay ahead of the curve and unlock new possibilities in the digital era.

 

BGP FlowSpec

 

DDoS BGP redirect

 

BGP FlowSpec

BGP DDoS

Network operators face various challenges in managing and securing their networks in today’s interconnected world. BGP FlowSpec, a powerful extension to the Border Gateway Protocol (BGP), has emerged as a valuable tool for mitigating network threats and improving traffic management. This blog post aims to provide a comprehensive overview of BGP FlowSpec, its benefits, and its role in enhancing network security and traffic management.

BGP FlowSpec, short for BGP Flow Specification, is an extension of the BGP protocol that allows network operators to define and distribute traffic filtering rules across their networks. Unlike traditional BGP routing, which focuses on forwarding packets based on destination IP addresses, BGP FlowSpec enables operators to control traffic based on various attributes, including source IP addresses, destination ports, protocols, and more.

Highlights: BGP FlowSpec

  • Dealing with DDoS Attacks

To deal with DDoS attacks, as standard IP routing is destination-based, we can use routing to route the packets toward a destination of null. If BGP is involved, we can use Remote Triggered Blackhole (RTBH) to remotely signal our upstream router to route the particular destination into a NULL route.

This is quite a simplistic way to mitigate a DDoS attack. On the other hand, BGP FlowSpec can be used as a BGP SDN DDoS solution. And can influence behavior based on a much broader set of criteria with the DDoS BGP redirect criteria?

  • FlowSpec DDoS

For example, with FlowSpec DDoS, we can match up more fields supported by BGP Flowspec (source and destination, IP protocol, source, and destination port, ICMP code, and TCP Flags) and more dynamic actions such as dropped packet test or rate limit.

 

For pre-information, you may find the following helpful post before you proceed:

  1. IPFIX Big Data
  2.  OpenFlow Protocol
  3. Data Center Site Selection
  4. DDoS Attacks
  5. OVS Bridge
  6. Segment Routing

 



BGP DDOS.

Key BGP FlowSpec Discussion Points:


  • Introduction to BGP FlowSpec and how it can be used.

  • Discussion on the BGP FlowSpec operations and how it works.

  • BGP DDoS and mitigation.

  • A final note on DDoS BGP redirect.

 

Back to basics with the BGP FlowSpec

BGP Security

BGP is one protocol that causes the Internet to work. Because of its criticality, unfortunately, BGP has been the target protocol. The main focus of any attacker is to find a vulnerability in a system, in this case, BGP, and then exploit it. RFC 4272, BGP Security Vulnerabilities Analysis, presents various weak areas in BGP that every enterprise or service provider should consider when implementing BGP.

Similar to how most protocols were designed in the past. BGP provides no confidentiality and only limited integrity and authentication services. Furthermore, BGP messages can be replayed; if a bad actor intercepts a BGP UPDATE message that adds a route, the hacker can resend that message after the route has been withdrawn and cause an inconsistent and invalid route to be present in the routing information base (RIB).

 

Enhancing Network Security:

One of the critical benefits of BGP FlowSpec is its ability to enhance network security. By leveraging FlowSpec, network operators can quickly respond to security threats and implement granular traffic filtering policies. For example, in the event of a distributed denial-of-service (DDoS) attack, operators can use BGP FlowSpec to instantly distribute traffic filters across their network, effectively mitigating the attack at its source. This real-time mitigation capability significantly reduces the impact of security incidents and improves network resilience.

Traffic Engineering and Quality of Service:

BGP FlowSpec also plays a crucial role in traffic engineering and quality of service (QoS) management. Network operators can use FlowSpec to shape and redirect traffic based on specific criteria. For instance, by employing BGP FlowSpec, operators can prioritize certain traffic types, such as video or voice traffic, over others, ensuring better QoS for critical applications. Furthermore, FlowSpec enables operators to dynamically reroute traffic in response to network congestion or link failures, optimizing network performance and user experience.

Implementing BGP FlowSpec:

Implementing BGP FlowSpec requires compatible routers and appropriate configuration. Network operators must ensure that their routers support the BGP FlowSpec extension and have the necessary software updates. Additionally, operators must carefully define traffic filtering rules using the BGP FlowSpec syntax, specifying each rule’s desired attributes and actions. It is crucial to thoroughly test and validate the FlowSpec configurations to avoid unintended consequences and ensure the desired outcomes.

Challenges and Considerations:

While BGP FlowSpec offers significant advantages, some challenges and considerations must be considered. FlowSpec configurations can be complex, requiring a deep understanding of network protocols and traffic patterns. Additionally, incorrect or overly aggressive FlowSpec rules can unintentionally disrupt legitimate traffic. Therefore, operators must balance security and network accessibility while regularly reviewing and fine-tuning their FlowSpec policies.

 

Recap on BGP FlowSpec

BGP FlowSpec is a BGP SDN mechanism that distributes flow-based policies to other BGP speakers. It enables the dynamic distribution of security profiles and corrective actions using a signaling mechanism based on BGP. No other protocols (OpenFlow, NETCONF, etc.) are used to disseminate the policies. The solution is based entirely on BGP consisting of a new Border Gateway Protocol Network Layer Reachability Information (BGP NLRI – AFI=1, SAFI=133) encoding format.

It reuses BGP protocol algorithms and inherits all the operational experience from existing BGP designs. It’s simple to extend by adding a new NLRI – MP_REACH_NLRI / MP_UNREACH_NLRI. It’s also a well-known protocol for many other technologies, including IPv6, VPN, labels, and multicast.

All existing BGP high availability and scalability features can be used with BGP FlowSpec; for example, route reflection is possible for a point to multipoint connections. In addition, BGP provides the following:

  • Inter-domain support.
  • Meaning you are not tied down to one AS.
  • You are enabling your BGP FlowSpec domain to span multiple administrative domains.

 

BGP FlowSpec Operations

BGP FlowSpec separates BGP networks’ control and data plane and distributes traffic flow specifications. Within the infrastructure, we have a Flowspec controller, the server, one or more Flowspec clients, and optionally a route-reflector that can be used for scalability. Rules that contain matching criteria and actions are created on the server and are redistributed to clients via MP-BGP. 

The central controller programs forward decisions and inject rules remotely into BGP clients. Cisco, Juniper, and Alcatel-Lucent support BGP FS controllers. It may also run on an x86 server with ExaBGP or Arbor PeakFlow SP Collector Platform.

The client receives the rules from the controller and programs rules of a) traffic descriptions and b) actions to apply to traffic. Then, the client, a BGP speaker, makes the necessary changes to TCAM. An additional optional route reflector component can receive rules from the controller and distribute them to clients.

 

Traffic classification

It classes traffic with Layer 3 and 4 information and offers similar granularity to ACLs. Still, one significant added benefit is that it is distributed, and a central controller controls flow entries. It can match on destination IP, source IP, IP protocol, port, destination port, source port, ICMP type and code, TCP flags, packet length, DCSP, and fragments. Once traffic is identified, it is matched, and specific actions are applied. In some cases, multiple actions are applied.

For example, FlowSpec can remotely program QoS – policers and markers, PBR – leak traffic to a Virtual Routing and Forwarding (VRF) or a new next hop, and replicate the traffic to, for example, a sniffer – all the configuration is carried out on the controller.

 

  • A key point: Scalability restrictions.

However, scalability restrictions exist as BGP FlowSpec entries share the TCAM with ACL and QoS. When the rules are complex using multi-value ranges, it will consume more TCAM than simple matching rules. Cisco provides general guidance of 3000 simple rules per line card.

bgp flowsepc
Diagram: BGP FlowSpec.

 

BGP DDoS and DDoS Mitigation

FlowSpec was initially proposed with RFC 5575 as a DDoS mitigation tool, but its use cases expand to other areas, such as BGP unequal cost load balancing. It’s tough to balance unequally based on your destination. With FlowSpec, it’s possible to identify groups of users based on the source address and then use FlowSpec to traffic engineer on ALL core nodes, not just at network edges.

 

DDoS mitigation operations

BGP Flowspec resembles access lists created with class maps and policy maps that provide matching criteria and traffic filtering actions. They are injected into BGP and propagated to BGP peers. As a result, there are many more criteria to use that destination IP address that can be used to mitigate the DDoS attack.

For example, with the DDoS BGP redirect, we can use criteria such as the source, destination, and L4 parameters and packet specifics such as length.

These are sent in a BGP UPDATE message to BGP border routers within FLOW_SPEC_NLRI along with the action criteria. Once received, several actions can be carried out, and these actions are carried in the extended communities’ Path attributes. So you can drop the policy or redirect to another VRF.

 

DDoS BGP redirect: The volumetric attack.

The primary type of DDoS attack FlowSpec protects against is a volumetric attack – long-lived large flows along with the DNS reflection attack. Volumetric attacks are best mitigated close as possible to the Internet border. The closer you drop the packet to the source, the better. You don’t want the traffic to arrive at its destination or to have the firewall process and drop it.

For example, a TCP SYN attack could be 1000 million packets per second; not many firewall states can address that. It is much better to drop volumetric-type attacks at network borders as they cannot be mitigated within the data center; it’s simply too late.

FlowSpec is also suitable for dropping amplification-type attacks. These attacks do not need to be sent to scrubbing systems and can be handled by FlowSpec by matching the traffic pattern and filtering at the edge.

With BGP Flowspec for DDoS BGP redirects, we have a more granular approach to mitigating DDoS attacks than old-school methods. All this is accomplished by a specific definition of flows based on Layer 3 and 4 matching criteria and actions configured on the FlowSpec server. The rules are automatically redistributed to FlowSpec clients using MP-BGP (SAFI 133), so the clients can take action defined in the rules.

Conclusion:

BGP FlowSpec has become an essential tool for network operators seeking to enhance network security and traffic management. Its ability to distribute traffic filtering rules in real time and its flexibility in defining granular policies make it a valuable asset in today’s dynamic network environments. By leveraging BGP FlowSpec, operators can effectively respond to security threats, optimize traffic engineering, and deliver better QoS. However, careful planning, implementation, and continuous monitoring are crucial to maximize the benefits of BGP FlowSpec while mitigating potential risks.

 

flowspec ddos

What does SDN mean

BGP has a new friend – BGP-Based SDN

 

what does SDN mean

 

BGP SDN

In today’s digital age, where connectivity and data transfer are paramount, efficient and robust networking solutions have become increasingly crucial. One such solution that has gained significant attention is BGP SDN. This blog post will delve into BGP SDN, its key components, and how it revolutionizes network flexibility and scalability.

BGP SDN, or Border Gateway Protocol Software-Defined Networking, combines two powerful technologies: the Border Gateway Protocol (BGP) and Software-Defined Networking (SDN). BGP, a routing protocol, facilitates inter-domain routing, while SDN provides centralized control and programmability of the network. Together, they offer a dynamic and adaptable networking environment.

 

Highlights: BGP SDN

  • The Role of SDN

Before we start our journey on BGP SDN, let us first address what does SDN mean? The Software-Defined Networking (SDN) framework has a large and varied context. Multiple components may or may not be used, OpenFlow Protocol being one of them. Some evolving SDN use cases leverage the capabilities of the OpenFlow protocol, while others do not require it.

OpenFlow is only one of those protocols within the SDN architecture. This post addresses using the Border Gateway Protocol (BGP) as the transfer protocol between the SDN controller and forwarding devices, enabling BGP-based SDN, also known as BGP SDN.

  • BGP and OpenFlow

BGP and OpenFlow are monolithic, meaning they are not used simultaneously. Integrating BGP to SDN offers several use cases, such as DDoS mitigationexception routing, forwarding optimizationsgraceful shutdown, and integration with legacy networks. Some of these use cases are available using OpenFlow Traffic Engineering; others, like graceful shutdown and integration with the legacy network, are easier to accomplish with BGP SDN. 

 



What Does SDN Mean?

Key BGP SDN Discussion Points:


  • Introduction to BGP SDN and what is involved.

  • Highlighting the the different components involved in a SDN BGP network.

  • Discussing creating an SDN architecture.

  • Technical details on the use of BGP and IGP.

  • The role of BGP-LS.

 

Before you proceed, you may find the following post helpful:

  1. BGP Explained
  2. Transport SDN
  3. What is OpenFlow
  4. Software Defined Perimeter Solutions
  5. WAN SDN
  6. OpenFlow And SDN Adoption
  7. HP SDN Controller

 

Back to basics with BGP SDN

What is BGP?

What is BGP protocol in networking? Border Gateway Protocol (BGP) is the routing protocol under the Exterior Gateway Protocol (EGP) category. In addition, we have separate protocols, which are Interior Gateway Protocols (IGPs). However, IGP can come with some disadvantages.

Firstly, policies are challenging to implement with an IGP because of the need for more flexibility. Usually, a tag is the only tool available that can be problematic to manage and execute on a large-scale basis. In the age of increasingly complex networks in both architecture and services, BGP presents a comprehensive suite of knobs to deal with complex policies, such as the following:

• Communities

• AS_PATH filters

• Local preference

• Multiple exit discriminator (MED

 

Critical Components of BGP SDN:

a. BGP Routing: BGP SDN leverages the BGP protocol to manage the routing decisions between different networks. This enables efficient and optimized routing, enabling seamless communication across various domains.

b. SDN Controller: The SDN controller acts as the centralized brain of the network, providing a single point of control and management. It enables network administrators to define and enforce network policies, configure routing paths, and allocate network resources dynamically.

c. OpenFlow Protocol: BGP SDN uses the OpenFlow protocol to communicate between the SDN controller and the network switches. OpenFlow enables the controller to programmatically control the forwarding behavior of switches programmatically, resulting in greater flexibility and agility.

Benefits of BGP SDN:

a. Enhanced Flexibility: BGP SDN allows network administrators to tailor their network infrastructure to meet specific requirements. With centralized control, network policies can be easily modified or updated, enabling rapid adaptation to changing business needs.

b. Improved Scalability: Traditional network architectures often struggle to handle the growing demands of modern applications. BGP SDN provides a scalable solution by enabling dynamic allocation of network resources, optimizing traffic flow, and ensuring efficient bandwidth utilization.

c. Simplified Network Management: The centralized management offered by BGP SDN simplifies network operations. Network administrators can configure, monitor, and manage the entire network from a single interface, reducing complexity and improving overall efficiency.

Use Cases for BGP SDN:

a. Data Centers: BGP SDN is well-suited for data center environments, where rapid provisioning, scalability, and efficient workload distribution are critical. By leveraging BGP SDN, data centers can seamlessly integrate physical and virtual networks, enabling efficient resource allocation and workload migration.

b. Service Providers: BGP SDN offers service providers the ability to provide flexible and customizable network services to their customers. It enables the creation of virtual private networks, traffic engineering, and service chaining, resulting in improved service delivery and customer satisfaction.

 

Highlighting BGP-based SDN 

BGP-based SDN involves two main solution components that may be integrated into several existing BGP technologies. Firstly, we have an SDN controller component speaking BGP, deciding what needs to be done. Secondly, we have a BGP originator componentsending BGP updates to the SDN controller and other BGP peers. For example, the controller could be a BGP software package running on Open Daylight. BGP originators are Linux daemons or traditional proprietary vendor devices running the BGP stack.

What does SDN mean
Diagram: What does SDN mean with BGP SDN?

 

Creating an SDN architecture

To create the SDN architecture, these components are integrated with existing BGP technologies, such as BGP FlowSpec (RFC 5575), L3VPN (RFC4364), EVPN (RFC 7432), and BGP-LS. BGP FlowSpec distributes forwarding entries, such as ACL and PBR, to the TCAM of devices. L3VPN and EVPN offer the mechanism to integrate with legacy networks and service insertion. BGP-LS extracts IGP network topology information and passes it to the SDN controller via BGP updates.

 

Central policy, visibility, and control

Introducing BGP into the SDN framework does not mean a centralized control plane. We still have a central policy, visibility, and control, but this is not a centralized control plane. A centralized control plane would involve local control plane protocols establishing adjacencies or other ties to the controller. In this case, the forwarding devices outright require the controller to forward packets; forwarding functionality is limited when the controller is down.

If the BGP SDN controller acts as a BGP route reflector, all announcements go to the controller, but the network runs fine without it. The controller is just adding value to the usual forwarding process. BGP-based SDN architecture augments the network; it does not replace it. Decentralizing the control plane is the only way; look at Big Switch and NEC’s SDN design changes over the last few years. Centralized control planes cannot scale.

 

Why use BGP?

BGP is well-understood and field-tested. It has been extended on many occasions to carry additional types of information, such as MAC addresses and labels. Technically, BGP can be used as a replacement for Label Distribution Protocol (LDP) in an MPLS core. Labels can be assigned to IPv6 prefixes (6PE) and labeled switched across an IPv4-only MPLS core.

BGP is very extensible. It started with IPv4 forwarding, then address families were added for multicast and VPN traffic. Using multiple addresses inside a single BGP process was widely accepted and implemented as a core technology. The entire Internet is made up of BGP, and it carries over 500,000 prefixes. It’s very scalable and robust. Some MPLS service providers are carrying over 1 million customer routes.

 

The use of open-source BGP daemons

There are many high-quality open-source BGP daemons available. Quagga is one of the most popular, and its quality has improved since it adopted Cumulus and Google. Quagga is a routing suite and has IGP support for IS-IS and OSPF. Also, a BIRD daemon is available. The implementation is based around Internet exchange points as the route server element. BIRD is currently carrying over 100,000 prefixes.

Using BGP-based SDN on an SDN controller integrates easily with your existing network. You don’t have to replace any existing equipment, deploy the controller and implement the add-on functionality BGP SDN offers. It enables a preferred step-by-step migration approach, not a risky big bang OpenFlow deployment.

 

IGP to the controller?

Why not run OSPF or ISIS to the controller? IS-IS is extendable with TLVs and, too, can carry a variety of information. The real problem is not extensibility but the lack of trust and policy control. IGP extension to the SDN controller with few controls could present a problem. OSPF sends LSA packets; there is no input filter. BGP is designed with policy control in mind and acts as a filter by implementing controls on individual BGP sessions.

BGP offers control on the network side and predicts what the controller can do. For example, the blast radius is restricted if the controller hits a bug or gets compromised. BGP gives greater policy mechanisms between the SDN controller and physical infrastructure.

 

Introducing BGP-LS

SDN requires complete topology visibility. If some topology information is hidden in IGP and other NLRI in BGP, it does not have a complete picture. If you have an existing IGP, how do you propagate this information to the BGP controller? Border Gateway Protocol Link-State (BGP-LS) is cleaner than establishing an IGP peering relationship with the SDN controller. 

BGP-LS extracts network topology information and updates it to the BGP controller. Once again, BGPv4 is extended to provide the capability to include the new Network Layer Reachability Information (NLRI) encoding format. It sends information from IS-IS or OSPF topology database through BGP updates to the SDN controller. BGP-LS can configure the session to be unidirectional and stop incoming updates to enhance security between the physical and SDN world.

 

  • A key point: SDN controller cannot leak information back

As a result, the SDN controller cannot leak information back into the running network. BGP-LS is a relatively new concept. It focuses on the mechanism to export IGP information and does not describe how the SDN controller can use it. Once the controller has the complete topology information, it may be integrated with traffic engineers and external path computing solutions to interact with information usually only carried by an IGP database.

For example, the Traffic Engineering Database (TED), built by ISIS and OSPF-TE extensions, is typically distributed by IGPs within the network. Previously, each node maintained its own TED, but now this can be exported to a BGP RR SDN application for better visibility.

 

BGP scale-out architectures

SDN controller will always become the scalability bottleneck. It can scale better when it’s not participating in data plane activity, but eventually, it will reach its limits. Every controller implementation eventually hits this point. The only way to grow is to scale out. 

Reachability and policy information is synchronized between individual controllers. For example, reachability information can be transferred and synchronized with MP-BGP, L3VPN for IP routing, or EVPN for layer-2 forwarding.

BGP SDN

Utilizing BGP between controllers offers additional benefits. Each controller can be placed in a separate availability zone, and tight BGP policy controls are implemented on BGP sessions connecting those domains, offering a clean failure domain separation.

An error in one available zone is not propagated to the next available zone. BGP is a very scalable protocol, and the failure domains can be as large as you want, but the more significant the domain, the longer the convergence times. Adjust the size of failure domains to meet scalability and convergence requirements. 

Conclusion:

BGP SDN combines the power of BGP routing and SDN to create a networking paradigm that enhances flexibility, scalability, and manageability. By leveraging BGP SDN, organizations can build dynamic networks that adapt to their changing needs and optimize resource utilization. As the demand for faster, more reliable, and flexible networks continues to grow, BGP SDN is poised to play a critical role in shaping the future of network infrastructure.