Border6 SDN Traffic Optimizations

Multihoming to different transit providers has become an essential service component at Internet edge. Multihoming allows you to satisfy a number of high-level requirements, one, of which is redundancy. Redundancy is site or device/link level and protects from a single point of failure. There are a number of ways to route and manage traffic in and out of multihomed sites. Some rely on static routing while others rely on the routing policy capabilities of the inter-domain routing protocol, Border Gateway Protocol (BGP). BGP is great for reducing network complexity and increasing scale at edges, but it has shortcomings in respect to path selection. BGP is scalable and robust, but routing decisions based on BGP attributes are flawed.

BGP validates path attributes and selects the best path by checking the following – local preference, shortest AS Path, ORIGIN attribute, lower MED attribute, eBGP routes are preferred over iBGP routes, lower metric to the NEXT-HOP. Although these attributes allow granular policy control they do not cover aspects relating to path performance. So, how can you add intelligence to BGP?





Border 6 Mission – BGP SDN

Border6 goal is simple, they want to develop an innovative routing optimization platform. Their toolset (NSI probe and NSI server) is not a replacement for BGP but more of a complementary tool. BGP is still required at network edges. The NSI products integrate with the border-routing process to complement the BGP decision process. The integration of NSI to BGP adds additional intelligence to the BGP routing process. Allowing engineers to automate, control, and monitor routing policies. For example, they have a Routing Decision Engine ( RDE ) that looks at the cost of transits. It takes into account the monthly subscription cost and cost of traffic bursts.

NSI probing and analysis allows them to measure latency and packet loss. The best path is then compared to the original path selected by the BGP process. The entire process lets you compare paths in terms of performance. If the best path is not selected by BGP, NSI automates traffic engineering and pushes the outbound traffic always via the best performing path. The NSI probe communicates with the BGP edge routers and sends aggregated data back to the NSI Server. The server then performs analysis on the data, triggers an action for the NSI probe to carry out. For multiple data centres, you can have multiple NSI probes at each location.


NSI Server & NSI Probe

NSI Server & NSI Probe


Optimizing Inbound Traffic flow

Enforcing outbound routing is performed without any difficulty. Inbound routing is different as you are relying on the upstream 3rd party to take action. You can however, influence this with AS-PATH prepending, community tagging and auto-shutdown of defective links. Locator/ID Separation Protocol (LISP) provides more granularity for inbound traffic engineering as it separates the address spaces. Currently, Border 6 support LISP version 1.1 and can respond to external servers the path available to reach a preferred network. This is based on NSI measurements. Border 6 are collaborating with French Research Agency ( ANR ) to develop a design to integrate NSI with LISP for inbound traffic optimization. This is an ongoing project and is dependent on the wider scope of a global LISP implementation. And as Mateusz Viste states – “LISP is not going to rule the Internet tomorrow, nor the day after that.


Border 6 LISP Process

The NSI device registers itself with an MAP server. A LISP Map server is a LISP infrastructure device that advertises host prefixes that are advertising to it. The registration process involves sending the MAP server the customer’s prefix. When other LISP participants need to send a packet to the customer’s prefix, they query the MAP server for its location. The MAP server in turn relays it to the NSI device. NSI identifies who is asking (what remote prefix), and responds with the correct RLOC device. RLOCs identify the location of the prefix. The selection of RLOC is based where transit gateway Border 6 prefer. This, of course, requires LISP tunnels on every one of the customer’s edge routers, making it possible to external entities to send LISP-tunneled packets. Until LISP becomes widely available Border6 continue other working practices to optimize inbound traffic flows: shortest AS-Path, community tagging and auto-shutdown of defective links.


Other Inbound Optimizations

Standard AS-PATH prepending is a well-known BGP path engineering method. BGP selects paths with the shortest AS path. Setting multiple AS entries to a prefix, which are announced to each of your transits will affect inbound traffic flow. Community tagging – is “work-in-progress” project and is due this year. Essentially, they can add custom-defined communities to selected prefix. Transit providers can match these communities and re-announce them partially. Effectively, traffic engineering-inbound flow. Auto-shutdown of defective links – when NSI detects a failure on one of your transit, it can shut down the BGP session on it (via ssh access on your router), preventing announcements of your prefix via particular links.


NSI Route Limiter

RAM and CPU are critical components to router resource and should be protected at all times. Routers at the edge may need to accept large portions of the BGP table, maybe the full BGP table, consuming a lot of router resources. The global IPv4 routing table has surpassed the 500 thousand route benchmark. We are quickly reaching the hard forwarding capacity limits of many popular routers. NSI have a nice feature known as route limiter. It is used for routers that can not accept large BGP table due to memory or some other constraints. NSI can feed low-end customer edge routers routes that are specifically selected by NSI to match destinations where you actually send traffic. This frees up RAM and CPU for other control and data plane tasks. It also allows you to use cheaper Layer 3 switches, such as Cumulus or Brocade. Making your WAN edge and BGP platform a true BGP SDN-powered solution.




About Matt Conran

Matt Conran has created 156 entries.

Leave a Reply