BGP Multipath

BGP Multipath

 

 

BGP Multipath

BGP Multipath, also known as Border Gateway Protocol Multipath, is a routing feature that allows traffic load balancing across multiple paths in a network. This feature is handy in scenarios with multiple links or paths between two routers.

Traditionally, BGP selects only the best path for forwarding traffic based on various factors, such as the shortest AS path length or the lowest cost. However, in some situations, utilizing multiple paths simultaneously to distribute traffic more evenly and efficiently may be desirable.

With BGP Multipath, routers can install and use multiple paths for the same destination prefix, increasing the available bandwidth and improving overall network performance. This enables the routers to consider multiple paths equally valid forwarding traffic options.

Highlights: BGP Multipath

  • The Role of BGP

Border Gateway Protocol (BGP) was developed in 1989 to connect networks and provide interdomain routing. The goal was to create a scalable non-chatty protocol. BGP grew in response to the overwhelming growth of the Internet, and its use cases now vary from Multicast, DDoS protection, Layer 2 services, BGP SDN, and the Routing Control Platform variations. A lot of its success comes down to the fact that it is a very well-known protocol.

  • BGP Additional Features

People know how to use BGP, and additional features are easily added, making it very extensible and easy to use. It’s much easier to troubleshoot a BGP problem than a complex IGP problem. If you want to add something new, you can create an attribute, and simple traffic engineering can be done using predefined BGP communities. Many tools are available within the protocol. Recently, there have been infrastructure improvements such as keepalive and update generation enhancements, parallel route refresh, adaptive update cache size, and multipath signalling. 

 

For pre-information, you may find the following helpful

  1. Application Aware Networking
  2. Port 179

 



BGP Add Path.

Key BGP Multipath Discussion Points:


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

  • Discussion on BGP Route Reflectors (RR) and end-to-end visibility.

  • Discussion on Hot Potato Routing.

  • A final note on BGP Add Path.

 

Back to basics with the BGP Multipath

At a fundamental level, BGP multipath allows you to install multiple internal and external BGP paths to the forwarding table. Selecting multiple paths enables BGP to load-balance traffic across multiple links. This allows multiple BGP routes to simultaneously reach the same destination.  The principal benefits of BGP multipath compared to normal BGP are:

  • The capacity to load-balance traffic across multiple links. 
  • Decreased impact in the event of a BGP session or link failure. 

By distributing traffic across multiple paths, BGP Multipath can help alleviate congestion on certain links, prevent bottlenecks, and optimize network utilization. It can also improve resiliency and reliability by providing redundancy in case of link failures. BGP Multipath can automatically reroute traffic to the remaining available paths in a link failure, ensuring uninterrupted connectivity.

It is important to note that BGP Multipath is not enabled by default and must be explicitly configured on the routers participating in the BGP peering. Additionally, not all BGP implementations support Multipath, so verifying compatibility with the specific router and software version is essential.

There are a few considerations to keep in mind when implementing BGP Multipath. First, it is crucial to ensure that all links involved in the multipath configuration have comparable bandwidth, delay, and reliability characteristics. This helps to prevent imbalances in traffic distribution and ensures that each path is utilized optimally.

BGP Multipath
Diagram: BGP Multipath

Second, it is essential to configure BGP Multipath to comply with the network’s policy requirements. This includes setting appropriate criteria for load balancing, such as equal-cost or unequal-cost multipath, and defining the maximum number of paths allowed for a given destination prefix.

Lastly, monitoring and troubleshooting tools should be utilized to verify the correct functioning of BGP Multipath and proactively identify any issues that may arise. Regular monitoring helps ensure that traffic is being distributed as intended and that the desired network performance goals are met.

 

BGP Multipath:

Best Path only & Route-Reflector clusters

BGP Multipath enables BGP to send more than just the “best” path. It is helpful in design where hot potato routing is broken. When you install a route reflector (RR), you break hot potato routing and potentially create route oscillation. Route oscillations may occur in certain network topologies combined with specific MED configurations.

To eliminate MED-induced route oscillations, a route reflector must advertise multiple paths. A network with a full mesh of iBGP speakers has consistent and equivalent routing information. It is free from MED-induced route oscillations and other routing inconsistencies.

We need to find an approach where the RR advertises all the available paths for an address prefix or the prefixes that may cause MED-induced route oscillations. As a general design best practice to achieve consistent routing, the IGP metrics for links within a route reflector cluster are smaller than the IGP metrics for the links between the route reflector clusters.

 

The hot potato routing scheme

All transit providers want to protect the hot potato routing scheme for revenue reasons. Traffic consumes bandwidth and bandwidth costs money. Therefore, providers want traffic to leave their networks as soon as possible, aka hot potato routing. The problem is that when a route reflector receives two updates, it only sends one.

This is done by design for scalability reasons. BGP may also withdraw paths with lower policies (MED, Local Preference), resulting in only one NLRI announcement (diagram above). It was relevant, but you might want to send multiple routes for many reasons.

For example, faster convergence requires a primary and backup path and Multipath TCP use. Another issue is that the route reflector selects the best path based on its IGP and the route reflector’s shortest exit point. Route reflector deployments will choose the egress router closest to the RR, not its clients. It selects the best path based on the IGP metric computed from its IGP database and announces it to clients.

This is not optimum for egress traffic selection. As a result, traffic may travel longer paths to exit an AS. To combat this, most service providers create a full mesh of route reflectors in all regions, resulting in a route reflector in every PoP. But an RR in every region is expensive if you have an extensive transit network.

 

BGP Multipath

There are several ways to get an RR or an ASBR to advertise more than one path:

  1. Different RD per prefix
  2. BGP Best External
  3. BGP Add Path
  4. BGP Optimal Route Reflection (ORR) 

Different RD (VPN identifier) per prefix is the recommended method for MPLS-VPN. If you are running Layer 3 VPN, you can assign different route distinguishers (RD) to the same prefix resulting in different IP addresses NLRI. Then the RR sees two different prefixes and will forward both.

RR does the best path on two different VPNv4/v6 NLRI. With BGP Best External, you tell the router not to withdraw an update, even if it’s not the best one. It provides the network with an external backup route.

 

BGP Add path

The BGP Add path feature is a new BGP capability. It is an extension added to a BGP update where you can signal multiple paths to neighbors that must be negotiated at startup with all BGP neighbors. It’s the best method if you have a good memory and all nodes support it. All the information will be in the control plane, and you can still do hot potato routing. There are many add-path flavors, including Add-n-path, Add-all-path, and Add-all-multipath+backup.

BGP Optimal Route Reflection enables a virtual IGP location-style design. It builds multiple RIBs and computes the best path for each RIB. It would help if you influenced your IGP to mimic what it would be like in other network locations. It essentially overwrites the default IGP location placement of the route reflector, enabling clients to direct traffic to their closest exit point in hot potato routing deployments.

In conclusion, BGP Multipath is a powerful feature that enhances BGP-based networks’ scalability, performance, and resiliency. By enabling traffic load balancing across multiple paths, it helps optimize network utilization, prevent congestion, and improve overall reliability. However, careful planning, configuration, and monitoring are essential to ensure its successful implementation.

 

hot potato routing

 

Routing Control Platform

BGP-based Routing Control Platform (RCP)

 

IGP platform

 

Routing Control Platform (RCP)

Routing Control Platforms (RCPs) have become essential tools for efficiently managing and controlling network traffic. In today’s digital age, where businesses rely heavily on network connectivity, the need for optimized routing has never been greater. In this blog post, we will explore the concept of Routing Control Platforms, their benefits, and how they empower organizations to take control of their network routing.

Routing Control Platforms are software-based solutions that give network administrators greater control over the routing decisions within their networks. These platforms provide a centralized interface for managing and distributing routing information, allowing organizations to optimize network performance, enhance security, and improve overall network resilience.

 

Highlights: Routing Control Platform

  • Centralized Forwarding Solution

The Routing Control Platform (RCP) is a centralized forwarding solution, similar to BGP SDN that enables the collection of a network topology map, running an algorithm, and selecting the preferred BGP route for each router in an Autonomous System (AS). It does this by peering both the IGP platform and iBGP to neighboring routers and communicating the preferred routes using unmodified iBGP.

It acts similarly to an enhanced route reflector and does not sit in the data path. It is a control plane device, separate from the IP forwarding plane. The RCP protocol exhibits the accuracy of a full mesh iBGP design and scalability enhancements of route reflection without sacrificing route selection correctness.

  • Hot Potato Routing

A potential issue with route reflection is that AS exit best path selection (hot potato routing) is performed by route reflectors from their IGP reference point, which in turn gets propagated to all RR clients scattered throughout the network. As a result, the best path selected may not be optimal for many RR clients as it depends on where the RR client is logically placed in the network.

You may also encounter MED-induced route oscillations. The Routing Control Platform aims to solve this problem.

 

Before you proceed, you may find the following blog BGP of interest:

  1. What is BGP protocol in networking
  2. Full Proxy
  3. What Does SDN Mean
  4. DNS Reflection Attack
  5. Segment Routing

 



Routing Control.

Key Routing Control Platform Discussion Points:


  • Introduction to Routing Control Platform and how it can be used.

  • Discussion on BGP Route Reflectors (RR) and BGP Confederations.

  • Discussion on an IGP platform and how RCP works.

  • Details on extracting the topology.

 

Back to Basics Routing Control Platform

Routing Foundations

A network carries traffic where traffic flows from a start node to an end node; generally, we refer to the start node as the source node and the end node as the destination node. We must pick a path or route from the source node to the destination node. A route can be set up manually; such a route is static. Or we can have a dynamic routing protocol, such as an IGP or EGP.

With dynamic routing protocols, we have the use a routing algorithm. The role of the routing algorithm is to determine a route. Each routing algorithm will have different ways of choosing a path. Finally, a network can be expressed as a graph by mapping each node to a unique vertex in the graph, where links between network nodes are represented by edges connecting the corresponding vertices. Each edge can carry one or more weights; such weights may depict cost, delay, bandwidth, and so on. Many of these methods are now enhanced with an IGP platform and different types of routing control.

 

  • A key point: Replacing iBGP with the OpenFlow protocol

There are proposed enhancements to the Routing Control Platform by replacing iBGP with the OpenFlow protocol, providing additional capabilities beyond next-hop forwarding. This may be useful for a BGP-free edge core and will be addressed later. The following discusses the original Routing Control Platform proposed by Princeton University and AT&T Labs-Research.

 

Benefits of Routing Control Platforms:

1. Enhanced Network Performance:

RCPs offer granular control over routing decisions, allowing network administrators to optimize traffic flow and minimize latency. By intelligently distributing traffic across multiple paths, RCPs ensure that network resources are utilized efficiently, improving network performance and end-user experience.

2. Improved Network Resilience:

RCPs enable organizations to build highly resilient networks by implementing diverse routing paths. In the event of a network failure or congestion, RCPs automatically reroute traffic to alternative paths, ensuring uninterrupted connectivity and minimizing downtime.

3. Increased Security:

Organizations’ network security has become a top priority with the rise in cyber threats. RCPs provide advanced security features, such as traffic filtering and access control, to protect against malicious activities. By centralizing routing control, RCPs enable network administrators to implement robust security policies and mitigate potential risks.

4. Scalability and Flexibility:

As businesses grow and networks expand, scaling and adapting becomes crucial. RCPs offer scalability by allowing organizations to add or remove network devices seamlessly. Additionally, RCPs provide flexibility in managing routing protocols, allowing administrators to easily configure and customize routing policies based on specific business requirements.

Use Cases of Routing Control Platforms:

1. Internet Service Providers (ISPs):

ISPs can leverage RCPs to optimize network performance, enhance customer experience, and manage bandwidth effectively. RCPs allow ISPs to distribute traffic intelligently across their networks, ensuring optimal utilization of infrastructure and reducing congestion.

2. Data Centers:

In data center environments, where high availability and low latency are critical, RCPs play a vital role in achieving efficient routing. By implementing RCPs, data centers can distribute traffic across multiple paths, balancing the load and minimizing response times.

3. Enterprise Networks:

Large enterprises with complex network infrastructures can benefit from RCPs to gain control over routing decisions. RCPs provide centralized management capabilities, simplifying the configuration and monitoring of routing policies across the entire network.

 

iBGP and eBGP

Routers within an AS exchange routes to external destinations using internal BGP (iBGP), and routers are peering external to their AS using external BGP (eBGP). All BGP speakers within a single AS must be fully meshed to propagate external destinations. For loop prevention, the original BGP design states reachability information learned from an iBGP router can not be forwarded to another iBGP router inside the full mesh. eBGP designs use AS-PATH for loop prevention. All routing protocols, not just BGP, require some mechanism to prevent loops.

  • With iBGP, the maximum number of iBGP hops an update can traverse is 1.

 

Route-reflection (RR) and confederations

To combat the scalability concerns with an iBGP full mesh design, in 1996, several alternatives, such as route reflection and confederations, were proposed. Both of these enable hierarchies within the topology. However, route reflection has drawbacks, which may result in path diversity and network performance side effects. There is a trade-off between routing correctness and scalability. With iBGP full mesh designs, if one BGP router fails, it will have a limited impact. An update travels only one i-BGP hop. However, if a route reflector fails, it has an extensive network impact. All iBGP peers peering with the route reflector are affected. 

An update message may traverse multiple route reflectors with a route reflection design before reaching the desired i-BGP router. This may have adverse effects, such as prolonged routing convergence. One of route reflection’s most significant adverse effects is reduced path diversity. A high path diversity can increase resilience, while low path diversity will decrease resilience. Since a route reflector only passes its best route, all clients peering with that route reflector use the same best path for that given destination.

 

  • A key point: Lab on BGP Route-Reflection

The following lab guide will look at the BGP RR if you don’t want a full mesh of iBGP speakers. Route reflectors (RR) are one method to eliminate the full mesh of IBGP peers in your network. The other method is BGP confederations.

The route reflector allows all IBGP speakers within your autonomous network to learn about the available routes without introducing loops. 

The route reflector can have three types of peerings:

    • EBGP neighbor
    • IBGP client neighbor
    • IBGP non-client neighbor

In the example below, we have 3 IBGP routers. With standard IBGP rules, when R2 receives a route from R1, it will not be forwarded to R3 (IBGP split horizon). We will configure R2 as the route reflector to get around this.

BGP Route Reflection
Diagram: BGP Route Reflection

 

Proper route reflector placement and design can eliminate some of these drawbacks. We now have path diversity mechanisms such as the BGP ADD Path capability and parallel peerings for better route reflection design. These were not available during the original RCP proposal.

 

Routing Control Platform (RCP)

The RCP consists of several components, 1) Route Control Server ( RCS), 2) BGP Engine, and 3) IGP platform viewer. It is similar to the newer BGP SDN platform proposed by Petr Lapukhov but has an additional IGP platform viewer function. Petr’s BGP SDN solution proposes a single Layer 3 protocol with BGP – a pure Layer 3 data center.

The RCP platform has two types of peerings: IGP and iBGP. It obtains IGP information by peering with IGP and learns BGP routes with iBGP. The Route Control Server component then analyzes the IGP and BGP viewer information to compute the best path and send it back via iBGP. Notice how the IGP Viewer only needs one peering into each partition in the diagram below.

Routing Control Platform
Diagram: Routing Control Platform

 

Since the link-state protocol uses reliable LSA flooding, the IGP viewer has an up-to-date topology view. To keep the IGP viewer out of the data plane, higher costs are configured on the links to the controller. As discussed, the BGP engine creates iBGP sessions for other directly reachable speakers or via the IGP.

By combining these elements, the RCS has full BGP and IGP topology information and can make routing decisions for routers in a particular partition. The RCP must have complete visibility. Otherwise, it could assign routes that create black holes, forwarding loops, or other issues preventing packets from reaching their destinations.

 

Centralized controller: Extract the topology

RPC uses a centralized controller to extract the topology and make routing decisions. These decisions are then pushed to the data plane nodes to forward data packets. It aims to offer the correctness of full-mesh iBGP designs and the scalability of route reflector designs. It uses iBGP sessions to peer with BGP speakers, learn topology information, and send routing decisions for destination prefixes.

As previously discussed, a route reflector design only sends its best path to clients, which limits path diversity. However, the RCP platform overcomes this route reflector limitation and sends each router a route it would have selected in an iBGP full mesh design.

Conclusion:

Routing Control Platforms empower organizations to take control of their network routing, leading to enhanced performance, improved resilience, and increased security. By leveraging RCPs, businesses can optimize their network infrastructure, ensuring smooth operations and a seamless user experience. As the demand for robust and flexible networks grows, Routing Control Platforms will play an increasingly vital role in effectively managing and controlling network traffic.

 

ip routing

Advances of IP routing and Cloud

 

ip routing

 

With the introduction and hype around Software Defined Networking ( SDN ) and Cloud Computing, one would assume that there has been little or no work with the advances in IP routing. You could say that the cloud has clouded the mind of the market. Regardless of the hype around this transformation, routing is still very much alive and makes up a vital part of the main internet statistics you can read. Packets still need to get to their destinations.

 

Advanced in IP Routing

The Internet Engineering Task Force (IETF) develops and promotes voluntary internet standards, particularly those that comprise the Internet Protocol Suite (TCP/IP). The IETF shapes what comes next, and this is where all the routing takes place. It focuses on anything between the physical layer and the application layer. It doesn’t focus on the application itself, but on the technologies used to transport it, for example, HTTP.

In the IETF, no one is in charge, anyone can contribute, and everyone can benefit. As you can see from the chart below, that routing ( RTG ) has over 250 active drafts and is the most popular working group within the IETF.

 

 

IP routinng
Diagram: IETF Work Distribution.

 

The routing area is responsible for ensuring the continuous operation of the Internet routing system by maintaining the scalability and stability characteristics of the existing routing protocols and developing new protocols, extensions, and bug fixes promptly

The following table illustrates the subgroups of the RTG working group:

Bidirectional Forwarding Detection (BFD) Open Shortest Path First IGP (OSPF)
Forwarding and Control Element Separation (forces) Routing Over Low power and Lossy networks (roll)
Interface to the Routing System (i2rs) Routing Area Working Group (RTGW)
Inter-Domain Routing (IDR) Secure Inter-Domain Routing (SCIDR)
IS-IS for IP Internets (isis) Source Packet Routing in Networking (spring)
Keying and Authentication for Routing Protocols (Karp)
Mobile Ad-hoc Networks (manet)

The chart below displays the number of drafts per subgroup of the routing area. There has been a big increase in the subgroup “roll,” which is second to BGP. “Roll” relates to “Routing Over Low power and Lossy networks” and is driven by the Internet of Everything and Machine-to-Machine communication.

 

IP ROUTING
Diagram: RTG Ongoing Work.

 

OSPF Enhancements

OSPF is a link-state protocol that uses a common database to determine the shortest path to any destination.

Two main areas of interest in the Open Shortest Path First IGP (OSPF) subgroups are OSPFv3 LSA Extendibility and Remote Loop-Free Alternatives ( LFAs ). One benefit IS-IS has over OSPF is its ability to easily introduce new features with the inclusion of Type Length Values ( TLVs ) and sub-TLVs. The IETF draft-IETF-OSPF-ospfv3-lsa-extend extends the LSA format by allowing the optional inclusion of TLVs, making OSPF more flexible and extensible. For example, OSPFv3 uses a new TLV to support intra-area Traffic Engineering ( TE ), while OSPFv2 uses an opaque LSA.

 

TLV for OSPFv3
Diagram: TLV for OSPFv3.

 

Another shortcoming of OSPF is that it does not install a backup route in the routing table by default. Having a pre-installed backup up path greatly improves convergence time. With pre-calculated backup routes already installed in the routing table, the router process does not need to go through the convergence process’s LSA propagation and SPF calculation steps.

 

Loop-free alternatives (LFA)

Loop-Free Alternatives ( LFA ), known as Feasible Successors in EIGRP, are local router decisions to pre-install a backup path.
In the diagram below:

-Router A has a primary ( A-C) and secondary ( A-B-C) path to 10.1.1.0/24
-Link State allows Router A to know the entire topology
-Router A should know that Router B is an alternative path. Router B is a Loop-Free Alternate for destination 10.1.1.0/24

OSPF LFA
Diagram: OSPF LFA.

 

This is not done with any tunneling, and the backup route needs to exist for it to be used by the RIB. If the second path doesn’t exist in the first place, the OSPF process cannot install a Loop-Free Alternative. The LFA process does not create backup routes if they don’t already exist. An LFA is simply an alternative loop-free route calculated at any network router.

A drawback of LFA is that it cannot work in all topologies. This is most notable in RING topologies. The answer is to tunnel and to get the traffic past the point where it will loop. This effectively makes the RING topology a MESH topology. For example, the diagram below recognizes that we must tunnel traffic from A to C. The tunnel type doesn’t matter – it could be a GRE tunnel, an MPLS tunnel, an IP-in-IP tunnel, or just about any other encapsulation.

 

In this network:

-Router A’s best path through E
-Routers C’s best path is through D
-Router A must forward traffic directly to C to prevent packets from looping back.

Remote LFA
Diagram: Remote LFA.

 

In the preceding example, we will look at “Remote LFA,” which leverages an MPLS network and Label Distribution Protocol ( LDP ) for label distribution. If you use Traffic Engineering ( TE ), it’s called “TE Fast ReRoute” and not “Remote LFA.” There is also a hybrid model combining Remote LFA and TE Fast ReRoute, and is used only when the above cannot work efficiently due to a complex topology or corner case scenario.

Remote LFAs extend the LFA space to “tunneled neighbors”.

– Router A runs a constrained SPF and finds C is a valid LFA

– Since C is not directly connected, Router A must tunnel to C

a) Router A uses LDP to configure an MPLS path to C

b) Installs this alternate path as an LFA in the CEF table

– If the A->E link fails.

a) Router A begins forwarding traffic along the LDP path

The total time for convergence usually takes 10ms.

Remote LFA has some topology constraints. For example, they cannot be calculated across a flooding domain boundary, i.e., an ABR in OSPF or L1/L2 boundary is IS-IS. However, they work in about 80% of all possible topologies and 90% of production topologies.

 

BGP Enhancements

BGP is a scalable distance vector protocol that runs on top of TCP. It uses a path algorithm to determine the best path to install in the IP routing table and for IP forwarding.

 

Recap BGP route advertisement:

  • RR client can send to a RR client.
  • RR client can send to a non RR client.
  • A non-RR client cannot send to a non-RR client.

One drawback to the default BGP behavior is that it only advertises the best route. When a BGP Route Reflector receives multiple paths to the same destination, it will advertise only one of those routes to its neighbors.

This can limit the visibility in the network and affect the best path selection used for hot potato routing when you want traffic to leave your AS as quickly as possible. In addition, all paths to exit an AS are not advertised to all peers, basically hiding ( not advertising ) some paths to exit the network.

The diagram below displays default BGP behavior; the RR receives two routes from PE2 and PE3 about destination Z; due to the BGP best path mechanism, it only advertises one of those paths to PE1. 

Route Reflector - Default
Diagram: Route Reflector – Default.

 

In certain designs, you could advertise the destination CE with different Route Distinguishers (RDs), creating two instances for the same destination prefix. This would allow the RR to send two paths to PE.

 

Diverse BGP path distribution

Another new feature is diverse BGP Path distribution, where you can create a shadow BGP session to the RR. It is easy to deploy, and the diverse iBGP session will announce the 2nd best path. Shadow BGP sessions are especially useful in virtualized deployments, where you can create another BGP session to a VM acting as a Route-Reflector. The VM can then be scaled out in a virtualized environment creating numerous BGP sessions. You are allowing the advertisements of multiple paths for each destination prefix.

Route Reflector - Shadow Sessions
Diagram: Route Reflector – Shadow Sessions.

 

BGP Add-path 

A special extension to BGP known as “Add Paths” allows BGP speakers to propagate and accept multiple paths for the same prefix. The BGP Add-Path feature will signal diverse paths, so you don’t need to create shadow BGP sessions. There is a requirement that all Add-Path receiver BGP routers must support the Add-Path capability.

There are two flavors of the Add-Path capability, Add-n-path, and Add-all-path. The “Add-n-path” will add 2 or 3 paths depending on the IOS version. With “Add-all-path,” the route reflector will do the primary best path computation (only on the first path) and then send all paths to the BR/PE. This is useful for large ECMP load balancing, where you need multiple existing paths for hot potato routing.

BGP Add Path
Diagram: BGP Add Path

 

Source packet routing

Another interesting draft the IETF is working on is Source Packet Routing ( spring ). Source Packet Routing is the ability of a node to specify a forwarding path. As the packet arrives in the network, the edge device looks at the application, determines what it needs, and predicts its path throughout the network. Segment routing leverages the MPLS data plane, i.e., push, swap, and pop controls, without needing LDP or RSVP-TE. This avoids millions of labels in the LDP database or TE LSPs in the networks.

 

Application Controls - Network DeliversDiagram: Application Controls – Network Delivers 

The complexity and state are now isolated to the network’s edges, and the middle nodes are only swapping labels. The source routing is based on the notion of a 32-bit segment that can represent any instructions, such as service, context, or IGP-based forwarding construct. This results in an ordered chain of topological and service instructions where the ingress node pushes the segment list on the packet.

 

Prefix Hijacking in BGP

BGP hijacking revolves around locating an ISP that is not filtering advertisements, or its misconfiguration makes it susceptible to a man-in-the-middle attack. Once located, an attacker can advertise any prefix they want, causing some or all traffic to be diverted from the real source towards the attacker.

In February 2008, a large portion of YouTube’s address space was redirected to Pakistan when the Pakistan Telecommunication Authority ( PTA ) decided to restrict access to YouTube.com inside the country but accidentally blackholed the route in the global BGP table.

These events and others have led the Secure-Inter Domain Routing Group ( SIDR ) to address the following two vulnerabilities in BGP:

-Is the AS authorized to originate an IP prefix?

-Is the AS-Path represented in the route the same as the path through which the NLRI traveled?

This lockdown of BGP has three solution components:

 

RPKI Infrastructure Offline repository of verifiable secure objects based on public-key cryptography
Follows resources (IPv4/v6 + ASN) allocation hierarchy to provide “right of use”
BGP Secure Origin AS You only validate the Origin AS of a BGP UPDATE
Solves most frequent incidents (*)
No changes to BGP nor the router’s hardware impact
Standardization is almost finished and running code
BGP PATH Validation BGPSEC proposal under development at IETF
Requires forward signing AS-PATH attribute
Changes in BGP and possible routers

The roll-out and implementation should be gradual and create islands of trust worldwide. These islands of trust will eventually interconnect together, making BGP more secure.

The table below displays the RPKI Deployment State;

RIR Total Valid Invalid Unknown Accuracy RPKI Adoption Rate
AFRINIC 100% .44% .42% 99.14% 51.49% .86%
APNIC 100% .22% .24% 99.5% 48.32% .46%
ARIN 100% .4% .14% 99.46% 74.65% .54%
LACNIC 100% 17.84% 2.01% 80.15% 89.87% 19.85%
RIPE NCC 100% 6.7% 0.59% 92.71% 91.92% 7.29%

Cloud Enhancements – The Intercloud

Today’s clouds have crossed well beyond the initial hype, and applications are now offered as on-demand services ( anything-as-a-service [XaaS] ). These services are making significant cost savings, and the cloud transition is shaping up to be as powerful as the previous one – the Internet. The Intercloud and the Internet of Things are the two new big clouds of the future.

Currently, the cloud market is driven by two spaces – the public cloud ( off-premise ) and the private cloud (on-premise). The intercloud takes the concept of cloud much further and attempts to connect multiple public clouds. A single application that could integrate services and workloads from ten or more clouds would create opportunities and potentially alter the cloud market landscape significantly. Hence, it is important to know and understand the need for cloud migration and its related problems.

We are already beginning to see signs of this in the current market. Various applications, such as Spotify and Google Maps, authenticate unregistered users with their Facebook credentials. Another use case is a cloud IaaS provider could divert incoming workload to another provider if it doesn’t have the resources to serve the incoming requests, essentially cloud bursting from provider to provider. It would also make economic sense to move workload and services between cloud providers based on cooling costs ( follow the moon ). Or maybe dynamically move workloads between providers, so they are closest to the active user base ( follow the sun )

The following diagram displays a Dynamic Workload Migration between two Cloud companies.

 

Intercloud
Diagram: Intercloud.

 

A: Cloud 1 finds Cloud 2 -Naming, Presence
B: Cloud 1 Trusts Cloud 2 -Certificates, Trustsec
C: Both Cloud 1 and 2 negotiate -Security, Policy
D: Cloud 1 sets up Cloud 2 -Placement, Deployment
E: Cloud 1 sends to Cloud 2 -VM runs in cloud-Addressing, configurations

The concept of Intercloud was difficult to achieve with the previous version of vSphere based on the restriction of latency for VMotion to operate efficiently. Now vSphere v6 can tolerate 100 msec of RTT.

InterCloud is still a conceptual framework, and the following questions must be addressed before it can be moved from concept to production.

1) Intercloud security

2) Intercloud SLA management

3) Interoperability across cloud providers.

 

Cisco’s One Platform Kit (onePK)

The One Platform Kit is Cisco’s answer to Software Defined Networking. It aims to provide simplicity and agility to a programmatic network. It’s a set of APIs driven by programming languages, such as C and Java, that are used to program the network. We currently have existing ways to program the network with EEM applets but lack an automation tool that can program multiple devices simultaneously. It’s the same with Performance Routing ( PfR ). PfR can program and traffic engineer the network by remotely changing metrics, but the decisions are still local and not controller-based.

 

Traffic engineering

One useful element of Cisco’s One Platform Kit is its ability to perform “Off box” traffic engineering, i.e., the computation is made outside the local routing device. It allows you to create route paths throughout the network without relying on default routing protocol behavior. For example, the cost is the default metric for route selection for equal-length routes in OSPF. This cannot be changed, which makes the routing decisions very static. In addition, Cisco’s One Platform Kit (onePK) allows you to calculate routes using different variables you set, giving you complete path control.

 

ip routing