BGP SDN – Centralized Forwarding

Networks with multiple Border Gateway Protocol (BGP) Autonomous Systems (ASNs) under the same administrative control implement traffic engineering with policy configurations at border edges. Policies are applied on multiple routers in a distributed fashion, which can be hard to manage and scale. Any per prefix traffic engineering changes may need to occur on multiple devices and multiple levels. A new BGP Software Defined Networking (SDN) solution introduced by P. Lapukhov & E. Nkposong propose a centralized routing model and introduce the concept of a BGP SDN controller. No protocol extensions or additional protocols are needed to implement the SDN architecture. BGP is employed to push down new routes and peer iBGP with all existing BGP routers. A BGP-only network has many advantages and this solution promotes a more stable Layer 3-only network, utilizing one control plane protocol – BGP. Topology discovery and link up/down events are captured by BGP. BGP is able to push different information to different BGP speakers, while an IGP has to flood the same LSA throughout the IGP domain.


Layer-2 and Layer-3 Technologies

Traditional network designs consist of a mix of Layer 2 and Layer 3 technologies. Topologies look like a tree with different aggregation levels, commonly known as access, aggregation, and core. IP routing is deployed at the top layers while Layer 2 is seen in the lower tier to support VM mobility and other applications that require Layer 2 VLANs to communicate. Fully routed networks are more stable as they confine the Layer 2 broadcast domain to certain areas. Layer 2 is segmented and confined to a single switch, usually used to group ports together. Routed designs run Layer 3 to the Top of Rack (ToR) and VLANs should not span ToR switches. As data centres grow in size, the stability of IP is more preferred over layer 2 protocols.

Traditional data centre traffic patterns leave the data centre, known as north to south traffic flow. In this case, traditional tree-like designs are sufficient. Upgrades consist of scale out mechanisms, such as adding bigger links or additional line cards. However, today’s applications, such as Hadoop clusters require a lot more server to server traffic, known as east to west traffic flow. Scaling up traditional tree topologies to match these traffic demands is possible but not an optimum way to run your network. A better choice is to horizontally scale your data centre with a CLOS topology ( leaf and spine ) not a tree topology.

Leaf and spine topologies permit equidistant endpoints and horizontal scaling, resulting in a perfect combination for optimum east to west traffic patterns. What layer 3 protocol do you use for your routing design? An Interior Gateway Protocol (IGP), such as ISIS or OSPF? or maybe BGP? The robustness of BGP is making it a popular Layer 3 protocol for reducing network complexity.


BGP SDN – Centralized Forwarding

In terms of internal data structures, BGP is less complex that a link-state IGP. Instead of forming adjacency maintain and controls, it runs all its operations over Transmission Control Protocol (TCP) and uses the robust nature of TCP as its transport mechanism. BGP has considerably less flooding overhead compared to IGP’s, which has a propagation scope of a single flooding domain. For these reasons, BGP is great for reducing network complexity and is selected as the singular control plane mechanism for this SDN solution. Petr has written a draft called “Centralized Routing Control in BGP Networks Using Link-State Abstraction”, discussing the use case of BGP for centralized control of routing in the network. The main benefit of the architecture is centralized control opposed to distributed. There is no need to configure policies on multiple devices. All changes are done with an API into the controller.




The network looks like a collection of BGP ASN and the entire routing is done with BGP only. BGP builds a link state map of the network in the controller memory. They use BGP to discover the topology and notice link up and link down events. Instead of installing a 5-tuple that can install flows based on the entire IP header, the BGP SDN solution offers destination based forwarding only. For additional granularity, implement BGP flow spec, RFC 55745, entitled “Dissemination of Flow Specification Rules”. 

The proposed method was inspired by the Routing Control Platform (RCP). The RCP platform uses a controller based function and selects BGP routes on behalf of the routers in an AS using a complete view of the available routes and IGP topology. The RCP platform has similar properties to the BGP SDN solution. Both run iBGP peers to all routers in the network and influence the default topology by making changes on the controller and pushing down new routes. However, a major difference is that the RCP has additional IGP peerings. It’s not a BGP only network. BGP SDN promotes a single control plane of BGP, without any IGPs. BGP is used to health detect, build link state map and represents the network to a 3rd party application as multiple topologies. From the API, you can map prefixes to different topologies and change link costs. The agent actually builds the link state database and presents a multi-topology view of this data to the client applications. You may take this topology, clone it and give certain links a higher costs; mapping some prefixes to this new non-default topology. The controller pushes new routes down with BGP. The peering is based in iBGP so new routes are set with a better Local Preference, enabling them to be selected higher in the BGP path decision process. It is possible to do this with eBGP, but iBGP can be easier. With iBGP, you don’t need to care about next hops.

BGP works like OpenFlow and pushes down the forwarding information. It populates routes in the forwarding table. Instead of using BGP in a distributed fashion, they centralise it. One main benefit of using BGP over OpenFlow is that you can shut the controller down and normal BGP operation continues on the network. But if you transition to an OpenFlow configuration you cannot roll back as easy as you could do with BGP. Using BGP inband has great operational benefits. A great design by P. Lapukhov. No need to deploy BGP-LS or any other enhancements to BGP.





About Matt Conran

Matt Conran has created 184 entries.


  • Jeff Tantsura


    Please let me disagree with some of your statements:
    1. BGP doesn’t work like OF and don’t populate forwarding information, it is a routing protocol, hence it populates routes into RIB which then pushed down to the FIB (forwarding)
    2. BGP is not centralized, it is still distributed, however there’s centralized view of the network (topology) so non BGP (ie business) logic could be applied to BGP best path and then distributed to the network (so called 3rd party NH’s are used) – remember – every BGP speaker has peering with its directly connected neighbors and the controller.
    Without changes from the controller the network is fully distributed and runs as any other BGP network.

    BGP-LS provides transport from IGP for many different attributes of the links and nodes within the topology that can’t be distributed over vanilla BGP.
    Those are the ones we used in GMPLS for quite some time (SRLG’s, etc) as well as newer ones defined in RFC7471 for OSPF and draft-ietf-isis-te-metric-extensions for ISIS

  • Matt Conran

    Hi Jeff. thanks for the comments. Its great to get the feedback. Essentially, when I say “BGP works like OpenFlow” and “BGP is centralized” is a play on words.

    This particular design by Petr is very useful for BGP only networks ( no IGP ) so BGP-LS would not required.

    Thanks again for adding the additional technical information for everyone

  • Faisal

    Hi Matt,

    Thanks for informative article. Can you tell of any commercial product using centralized BGP.


  • Matt Conran

    Hi Faisal, glad you like it.
    One or two of the SD-WAN companies are using BGP but their controllers are not for sale… Have a look at Juniper contrail 🙂

Leave a Reply