10.3 Case Study 3: Load BalancingMultipath and Multihop


10.3 Case Study 3: Load Balancing”Multipath and Multihop

JUNOS supports load balancing via three different methods :

  1. EBGP load balancing using the multipath statement

  2. IBGP load balancing using the multipath statement

  3. EBGP load balancing using the multihop statement

We will cover the theory of each of these. This is an important topic due to the connected nature of most networks. Large-enterprise networks have several connection points to the same or different ISPs, and ISPs themselves may have several connection points to other peering ISPs.

Load balancing essentially means the sharing of multiple equal-cost paths over which to distribute outbound traffic. In Juniper Networks routers, systems with the Internet Processor I ASIC can support up to 8 equal-cost paths, while systems with the Internet Processor II ASIC can support up to 16 equal-cost paths.

To summarize, here are the three methods of load balancing:

  • Load balancing across multiple links between ASs using EBGP multipath

  • Load balancing across multiple links within an AS using IBGP multipath

  • Load balancing across multiple links between ASs using EBGP multihop and static routes

10.3.1 EBGP Multipath

The first method of load balancing across multiple links between ASs using EBGP multipath is probably the most common. This is because you may have scenarios where you have either links going to more than one AS receiving equal-cost routing information, or multiple links going to multiple routers in the same AS receiving equal-cost routing information. We will take a look at both of these.

Figure 10-6 shows a simple topology where AS400 is advertising the 172.16.0.0/16 network to both AS200 and AS300. In turn , AS200 and AS300 advertise the same route to AS100. Assuming the link to AS200 and AS300 from AS100 is the same speed, and AS100 has no desire to manipulate any of the attributes, AS100 now has two equal-cost paths to network 172.16.0.0/16 .

Figure 10-6. Load Balancing Across Multiple Links Between ASs Using EBGP Multipath Scenario 1

graphics/10fig06.gif

Our second scenario for load balancing across multiple links between AS is similar to what we have just seen. Figure 10-7 shows our new topology. In this situation, we still have a network advertisement coming from AS200 of 172.16.0.0/16 , but the advertisement to AS100 is coming from two routers in AS200. If the policy in AS200 were to modify the MED value to try to manipulate the way AS100 sees the route, then it would not be a truly equal-cost path . However, with policy, AS100 can make the advertisement look the same and implement load balancing.

Figure 10-7. Load Balancing Across Multiple Links Between ASs Using EBGP Multipath Scenario 2

graphics/10fig07.gif

10.3.2 IBGP Multipath

Our next scenario consists of load balancing across multiple links within an AS using IBGP multipath. Typically, load balancing within an AS is performed solely by the IGP. However, by using the multipath statement with our IBGP sessions, we can change this characteristic and allow our load balancing to occur based upon BGP routes in conjunction with our IGP.

Figure 10-8 shows how IBGP, when used with the multipath statement, can provide equal-cost routing. In this scenario, router Tokyo in AS100 is advertising NLRI for 10.10.0.0/16 to both routers San Francisco and Los Angeles, in AS200. In AS200, all routers are peering via an IBGP full-mesh. When router Washington D.C. receives the route advertisement for 10.10.0.0/16 , it receives the information twice; once with 172.16.0.1 for the NEXT_HOP , and once with 172.16.0.2 for the NEXT_HOP .

Figure 10-8. Load Balancing Using IBGP and the multipath Statement Scenario 3

graphics/10fig08.gif

Recalling our discussion on BGP route selection, all things being equal, BGP will install the route from the router with the lowest RID. In this case router San Francisco has the lowest RID, so BGP will select the route to 10.10.0.0/16 via next-hop 172.16.0.1 . When BGP does a recursive lookup for the route 172.16.0.1 , it will find that there are two equal paths in the IGP for 172.16.0.1 : one via Atlanta and one via Dallas. In this case, Washington D.C. will forward any packets destined for 10.10.0.0/16 equally over the links between Washington D.C. to Atlanta and Washington D.C. to Dallas. This does not present a serious problem, unless of course our goal is to provide as much equal distribution of traffic through our network as possible. With the inclusion of the multipath statement, we can manipulate how BGP sees the 10.10.0.0/16 prefix and provide equal distribution of traffic.

Let's now take a look at how Washington D.C. will view the routes with multipath enabled. When Washington D.C. receives the two routes, one with a next-hop of 172.16.0.1 and the other with 172.16.0.2 , it will install both routes into the routing table. This is because the multipath statement allows BGP to install multiple routes in the routing table as long as they are equal in cost. In this case, when Washington D.C. does a recursive lookup for 172.16.0.1 and 172.16.0.2 , it will see that the IGP has equal-cost routes to both next-hop addresses. Thus, it will override the RID rule and allow both BGP routes to be installed. When this occurs, Washington D.C. will distribute traffic for prefix 10.10.0.0/16 over all four links leading to the border routers.

This scenario is probably one of the least commonly used, but it does illustrate how multipath can be used to take advantage of equal-cost paths.

10.3.3 EBGP Multihop

This next scenario concerns load balancing between two EBGP peering routers with multiple links. Previously, it was mentioned that peering between EBGP peers is typically done using the physical interface addresses. This works in general and is the best way to peer (via EBGP) when only one link exists. However, we want to be able to take advantage of the multiple links that are there primarily for resiliency.

For this scenario, take a look at Figure 10-9. The topology shows Washington D.C. in AS100 with three links to New York in AS200. For ease of understanding, we will only refer to links A and B for the time being.

Figure 10-9. Load Balancing EBGP Using the multihop Statement

graphics/10fig09.gif

AS100 and AS200 want to peer with each other through Washington D.C. and New York, respectively. In a typical EBGP peering scenario using only one link, we would create an EBGP session between Washington D.C. and New York using the physical interface addresses. However, in this case we want to maintain a higher level of resiliency and take advantage of the multiple links. Why? There are two reasons. The first is to take advantage of the link redundancy in case of link failure; the second is to take advantage of the second link to load-balance traffic.

The easiest way to do this is to create an EBGP session between AS100 and AS200 by using the loopback interfaces of each router. To do this, we need to address two issues: loopback interface routing and EBGP TTL .

In IBGP, we are able to peer between two routers using the loopback interface because we have an IGP running in our AS that knows about all internal interfaces to the AS and provides routing information to each router within the routing domain. Thus, there is a logical connection. In this scenario, however, there is no IGP running between AS100 and AS200, and we do not want one. In order for Washington D.C. to know about the loopback interface address on New York, we must configure a static route to the loopback address via link A and link B. We do the same thing in New York. We create two static routes to Washington D.C.'s loopback interface address via link A and link B. With this accomplished, each router can now see the other's loopback interface.

The second issue we need to overcome is the EBGP TTL . In EBGP the TTL is set to 1, so you have basically one hop to create your BGP session. Through the use of the multihop statement, we can increase our TTL to 2 and create an EBGP session between loopback interfaces.

Now that we have addressed our connectivity issues, we can explain our ability to take advantage of the two characteristics provided by the links: redundancy against failure and multiple links for load balancing.

For EBGP session redundancy, we are peering between the two loopback interface addresses on each router: Washington D.C. and New York. If link A fails, the characteristics of TCP will allow our BGP EBGP peering session, which uses TCP as a transport protocol, to remain up over link B. As for load balancing, our EBGP peering session is between loopback interfaces. When AS100 receives routes from AS200, Washington D.C. (in AS100) will do its recursive lookup to the routing table. In the routing table, we have two equal-cost static routes pointing to the loopback interface's address on New York, thereby giving our router two equal-cost paths over which to route traffic.

What about link C? If we were to add an additional link between the two peers, we would only have to add an additional static route to each router pointing to the neighbor's loopback interface address.



Juniper Networks Reference Guide. JUNOS Routing, Configuration, and Architecture
Juniper Networks Reference Guide: JUNOS Routing, Configuration, and Architecture: JUNOS Routing, Configuration, and Architecture
ISBN: 0201775921
EAN: 2147483647
Year: 2002
Pages: 176

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net