10.1 Case Study 1: Path Selection
10.1 Case Study 1: Path SelectionFor this first case study, we refer to Figure 10-1 for our topology. This is a very simple setup and can be used to reinforce our understanding of concepts discussed in Chapter 9. In these scenarios, we have four different ASs. Figure 10-1. Path-Selection Case Study 10.1.1 Path Selection with RIDWe will first look at some common examples of route selection. In this scenario, the Washington D.C. router is advertising the 172.18.0.0/16 network to both Atlanta and Denver, who in turn advertise the prefix to their neighbors. When the prefix advertisement reaches the Houston router, Houston must select a path, based upon our previous discussion on route selection in Section 9.1.4.4. When we issue the show route 172.18.0.0 detail command, we see the output in the example below. Path selection has gone through each step in the route-selection process. To outline briefly , LOCAL_PREF is equal (at 100) for each route received. When the comparison of AS_PATH length is processed , they are equal. They both have a path list of two ASs each, and the ORIGIN is set to I for each, meaning that the route was learned in the originating AS by the IGP. Since Houston is learning the prefix 172.18.0.0/16 from two internal neighbors, there will be no advertisement of the MED attribute. Both of these routes were learned via IBGP peering sessions, so there is no comparison of EBGP-learned routes to be accepted over IBGP-learned routes. Also, there is no IGP metric associated with these links because both border routers are directly connected to the Houston router. When the route reaches the RID comparison, we finally have a difference. The RID assigned to Dallas is 192.168.12.1 , and the RID assigned to San Francisco is 192.168.16.1 . Since Dallas has the lower of the two RIDs, it will be selected as the active route. If you look at the output from San Francisco, 192.168.16.1 , you will see Inactive reason: Router ID . JUNOS lets you know why a route was not selected. lab@houston> show route 172.18.0.0 detail inet.0: 14 destinations, 14 routes (13 active, 0 holddown, 1 hidden) + = Active Route, - = Last Active, * = Both 172.18.0.0/16 (2 entries, 1 announced) *BGP Preference: 170/-101 Source: 192.168.12.1 Nexthop: 10.0.13.2 via fe-0/1/0.0, selected Protocol Nexthop: 10.0.8.1 Indirect nexthop: 83784c8 37 State: <Active Int Ext> Local AS: 600 Peer AS: 600 Age: 13:19 Metric2: 20 Task: BGP_600.192.168.12.1+179 Announcement bits (2): 0-KRT 4-Resolve inet.0 AS path: 400 100 I Localpref: 100 Router ID: 192.168.12.1 BGP Preference: 170/-101 Source: 192.168.16.1 Nexthop: 10.0.15.2 via fe-0/1/1.0, selected Protocol Nexthop: 10.0.16.2 Indirect nexthop: 8378550 38 State: <Int Ext> Inactive reason: Router ID Local AS: 600 Peer AS: 600 Age: 12:46 Metric2: 20 Task: BGP_600.192.168.16.1+3881 AS path: 700 100 I Localpref: 100 Router ID: 192.168.16.1 Next , we will look at the routing table for Denver. This example will show how AS_PATH length comes into play when selecting an active route. In this scenario, Washington D.C. advertises the 172.18.0.0/16 prefix to Atlanta and Denver. Atlanta will announce the prefix to Dallas and Denver, and Denver will announce the prefix to San Francisco and Denver. 10.1.2 Path Selection with AS_PATHIn the example below, we see the show route 172.18.0.0/16 detail output from the Denver router. Denver knows about the 172.18.0.0/16 prefix from both Washington D.C. and Atlanta. The link between Denver and Washington D.C. is chosen as the active route because the AS_PATH length is shorter than that for Denver to Atlanta to Washington D.C. The highlighted portions of the output reinforce this. lab@denver> show route 172.18.0.0/16 detail inet.0: 9 destinations, 9 routes (8 active, 0 holddown, 1 hidden) + = Active Route, - = Last Active, * = Both 172.18.0.0/16 (2 entries, 1 announced) *BGP Preference: 170/-101 Source: 10.0.1.1 Nexthop: 10.0.1.1 via fe-0/1/2.0, selected State: <Active Ext> Local AS: 700 Peer AS: 100 Age: 1:44:59 Task: BGP_100.10.0.1.1+1059 Announcement bits (2): 0-KRT 1-BGP.0.0.0.0+179 AS path: 100 I Localpref: 100 Router ID: 192.168.2.1 BGP Preference: 170/-101 Source: 10.0.0.2 Nexthop: 10.0.0.2 via fe-0/1/0.0, selected State: <Ext> Inactive reason: AS path Local AS: 700 Peer AS: 400 Age: 1:44:59 Task: BGP_400.10.0.0.2+1044 AS path: 400 100 I Localpref: 100 Router ID: 192.168.5.1 10.1.3 Path Selection EBGP over IBGPThe next example is show route 172.18.0.0/16 detail from the Dallas router. Dallas will receive the 172.18.0.0/16 prefix from external neighbor Atlanta and from internal neighbor Houston. Path selection for an active route will not occur until we reach the selection criteria of EBGP routes chosen over IBGP routes. Because of this, Dallas is going to prefer the advertisement from Atlanta to that from San Francisco. The nature of BGP is often characterized as hot potato routing, or "get the packet out of the AS via the shortest path." lab@dallas> show route 172.18.0.0/16 detail inet.0: 14 destinations, 14 routes (13 active, 0 holddown, 1 hidden) + = Active Route, - = Last Active, * = Both 172.18.0.0/16 (2 entries, 1 announced) *BGP Preference: 170/-101 Source: 10.0.8.1 Nexthop: 10.0.8.1 via fe-0/1/1.0, selected State: <Active Ext> Local AS: 600 Peer AS: 400 Age: 1:19:05 Task: BGP_400.10.0.8.1+1060 Announcement bits (3): 0-KRT 3-BGP.0.0.0.0+179 4-Resolve inet.0 AS path: 400 100 I Localpref: 100 Router ID: 192.168.5.1 BGP Preference: 170/-101 Source: 192.168.16.1 Nexthop: 10.0.13.1 via fe-0/1/0.0, selected Protocol Nexthop: 10.0.16.2 Indirect nexthop: 83784c8 38 State: <Int Ext> Inactive reason: Interior > Exterior > Exterior via Interior Local AS: 600 Peer AS: 600 Age: 1:18:31 Metric2: 30 Task: BGP_600.192.168.16.1+3883 AS path: 700 100 I Localpref: 100 Router ID: 192.168.16.1 10.1.4 AS_PATH PrependNext, we are going to influence how we wish to route traffic to our destination network of 172.18.0.0/16 sent inbound to our AS100. In Figure 10-1, we see the link between Washington D.C. and Atlanta is a DS-3, and the link between Washington D.C. and Denver is and OC3. We prefer traffic coming to us over the higher-speed OC3 circuit from Denver. You might initially think that setting the MED value would influence how the external neighbors send traffic to AS100. MED , in this case, will not provide any benefit because we are not multihomed to a single AS. The next thought is to use AS path prepending. AS path prepending is a method by which we can attempt to influence how traffic will be sent to our AS by external networks. Up to now, we have advertised our network 172.18.0.0/16 without any additional tweaking. Now we want to have external networks send traffic to us via our OC3 link between Washington D.C. and Denver. To do so, we will prepend our own ASN to our AS_PATH attribute when we advertise our route to Atlanta in AS400. This is done through setting policy. If we take a look at Atlanta's routing table in the example below, we see there are two routes for network 172.18.0.0/16 , one that is directly connected and the other through AS700. lab@Atlanta> show route 172.18.0.0 inet.0: 9 destinations, 9 routes (8 active, 0 holddown, 1 hidden) + = Active Route, - = Last Active, * = Both 172.18.0.0/16 *[BGP/170] 00:00:03, localpref 100 AS path: 100 I > to 10.0.2.1 via fe-0/1/2.0 [BGP/170] 00:41:05, localpref 100 AS path: 700 100 I > to 10.0.0.1 via fe-0/1/0.0 Our next example shows the routing table in Atlanta after we implement AS path prepending. We now see that Atlanta prefers to use the path to Denver to get to Washington D.C., rather than its own direct path to Washington D.C. This influence could potentially cause problems in how the rest of the world is seeing route advertisements due to the prepended path being advertised out to other neighbors of Atlanta. lab@Atlanta> show route 172.18.0.0 inet.0: 9 destinations, 9 routes (8 active, 0 holddown, 1 hidden) + = Active Route, - = Last Active, * = Both 172.18.0.0/16 *[BGP/170] 00:44:08, localpref 100 AS path: 700 100 I > to 10.0.0.1 via fe-0/1/0.0 [BGP/170] 00:00:23, localpref 100 AS path: 100 100 I > to 10.0.2.1 via fe-0/1/2.0 [BGP/170] 00:00:23, localpref 100 AS path: 600 700 100 I > to 10.0.8.2 via fe-0/1/1.0 When we issue the show route 172.18.0.0/16 detail command, we see why the new route is preferred. The last route in the table fails because of AS_PATH length. The second route is not active because it loses out in the RID comparison. lab@Atlanta> show route 172.18.0.0/16 detail inet.0: 9 destinations, 9 routes (8 active, 0 holddown, 1 hidden) + = Active Route, - = Last Active, * = Both 172.18.0.0/16 (3 entries, 1 announced) *BGP Preference: 170/-101 Source: 10.0.0.1 Nexthop: 10.0.0.1 via fe-0/1/0.0, selected State: <Active Ext> Local AS: 400 Peer AS: 700 Age: 46:13 Task: BGP_700.10.0.0.1+179 Announcement bits (2): 0-KRT 1-BGP.0.0.0.0+179 AS path: 700 100 I Localpref: 100 Router ID: 192.168.0.1 BGP Preference: 170/-101 Source: 10.0.2.1 Nexthop: 10.0.2.1 via fe-0/1/2.0, selected State: <Ext> Inactive reason: Router ID Local AS: 400 Peer AS: 100 Age: 2:28 Task: BGP_100.10.0.2.1+1073 AS path: 100 100 I Localpref: 100 Router ID: 192.168.2.1 BGP Preference: 170/-101 Source: 10.0.8.2 Nexthop: 10.0.8.2 via fe-0/1/1.0, selected State: <Ext> Inactive reason: AS path Local AS: 400 Peer AS: 600 Age: 2:28 Task: BGP_600.10.0.8.2+179 AS path: 600 700 100 I Localpref: 100 Router ID: 192.168.12.1 When we perform AS path prepending, another interesting characteristic of route advertisement shows up. Because Atlanta now prefers the path to Denver to get to Washington D.C. in AS100, it will also advertise that same route to Dallas. However, Dallas also receives an advertisement from San Francisco with a shorter AS_PATH list. Consequently, Dallas will now send any traffic for prefix 172.18.0.0/16 through Houston, then to San Francisco, then to Denver, and finally off to Washington D.C., whereas before the prepending took place, Dallas would have sent traffic for 172.18.0.0/16 to Atlanta, and Atlanta would have sent it directly to Washington D.C. lab@dallas> show route 172.18.0.0 inet.0: 14 destinations, 14 routes (13 active, 0 holddown, 1 hidden) + = Active Route, - = Last Active, * = Both 172.18.0.0/16 *[BGP/170] 00:04:38, localpref 100, from 192.168.16.1 AS path: 700 100 I > to 10.0.13.1 via fe-0/1/0.0 [BGP/170] 00:04:38, localpref 100 AS path: 400 700 100 I > to 10.0.8.1 via fe-0/1/1.0 Let's see what happens when we lose the link between Atlanta and Denver with the prepended path. Dallas now sees an advertisement for prefix 172.18.0.0/16 from Atlanta, but the AS_PATH list is longer than that of the advertisement from San Francisco. Essentially, though, the prepending has had the desired effect of causing all traffic inbound to Washington D.C. to come through the link between Denver and Washington D.C. lab@dallas> show route 172.18.0.0 inet.0: 14 destinations, 14 routes (13 active, 0 holddown, 1 hidden) + = Active Route, - = Last Active, * = Both 172.18.0.0/16 *[BGP/170] 00:10:32, localpref 100, from 192.168.16.1 AS path: 700 100 I > to 10.0.13.1 via fe-0/1/0.0 [BGP/170] 00:00:09, localpref 100 AS path: 400 100 100 I > to 10.0.8.1 via fe-0/1/1.0 What we have seen up to this point are some simplified examples of route selection in JUNOS. The preceding examples should reinforce the route-selection criteria, as well as provide a foundation for the remainder of this chapter. |
EAN: 2147483647
Pages: 176