10.2 Case Study 2: Advanced Path Selection

10.2 Case Study 2: Advanced Path Selection

This case study will present some more advanced route-selection scenarios and discuss both how IGP metrics come into play and how LOCAL_PREF can affect the way an AS routes traffic to external networks. In Figure 10-2, two networks are being advertised. Washington D.C. is advertising 172.1.0.0/16 , and Atlanta is advertising 172.4.0.0/16 .

Figure 10-2. Advanced Path-Selection Case Study

10.2.1 LOCAL_PREF and IGP Metric

Let's first look at how the border router, Denver, interprets the route advertisements. In the following example, we have the output of show route protocol bgp . We use this command, since we are only injecting two routes into BGP. We could also cover all of these routes with the show route 172.0.0.0/13 command. We see that Denver received the 172.1.0.0/16 network advertisement from AS100 and AS400. The active route is through the shorter AS_PATH list due from AS100, which is what we expect to see.

 lab@dallas> show route protocol bgp  inet.0: 18 destinations, 18 routes (17 active, 0 holddown, 1 hidden) + = Active Route, - = Last Active, * = Both 172.1.0.0/16       *[BGP/170] 00:27:32, localpref 100, from 192.168.0.1                       AS path: 100 I                     > to 10.0.13.1 via fe-0/1/0.0                     [BGP/170] 00:36:43, localpref 100                       AS path: 400 100 I                     > to 10.0.8.1 via fe-0/1/1.0 172.4.0.0/16       *[BGP/170] 00:27:13, localpref 100                       AS path: 400 I                     > to 10.0.8.1 via fe-0/1/1.0                     [BGP/170] 00:20:07, localpref 100, from 192.168.0.1                       AS path: 400 I                     > to 10.0.13.1 via fe-0/1/0.0 

Next , we issue the show route protocol bgp on border router Dallas. Dallas will get to network 172.1.0.0 via border router Denver. For network 172.4.0.0/16 , Dallas will send to AS400 out the directly connected interface.

 lab@denver> show route protocol bgp  inet.0: 17 destinations, 17 routes (16 active, 0 holddown, 1 hidden) + = Active Route, - = Last Active, * = Both 172.1.0.0/16       *[BGP/170] 00:29:11, localpref 100                       AS path: 100 I                     > to 10.0.1.1 via fe-0/1/2.0                     [BGP/170] 00:15:42, localpref 100                       AS path: 400 100 I                     > to 10.0.0.2 via fe-0/1/0.0 172.4.0.0/16       *[BGP/170] 00:15:42, localpref 100                       AS path: 400 I                     > to 10.0.0.2 via fe-0/1/0.0                     [BGP/170] 00:22:49, localpref 100, from 192.168.12.1                       AS path: 400 I                     > to 10.0.16.1 via fe-0/1/1.0                     [BGP/170] 00:22:49, localpref 100                       AS path: 100 400 I                     > to 10.0.1.1 via fe-0/1/2.0 

The way in which the routes are set up is typical for this scenario. Houston and San Francisco will route traffic for the 172.1.0.0/16 network through the border router in Denver. This path is selected because the AS_PATH list is shorter.

When it comes to the 172.4.0.0/16 network, San Francisco will send traffic through Denver, and Houston will send traffic through Dallas. Each sees an equal AS_PATH list. The difference between the two is the IGP metric. This can be seen in the next example, which shows the routing table from San Francisco.

 172.4.0.0/16 (2 entries, 1 announced)         *BGP    Preference: 170/-101                 Source: 192.168.0.1                 Nexthop: 10.0.16.2 via fe-0/1/1.0, selected                 Protocol Nexthop: 10.0.0.2 Indirect nexthop: 83786e8 41                 State: <Active Int Ext>                 Local AS:   600 Peer AS:   600                 Age: 37:56      Metric2: 20                 Task: BGP_600.192.168.0.1+179                 Announcement bits (2): 0-KRT 4-Resolve inet.0                 AS path: 400 I                 Localpref: 100                 Router ID: 192.168.0.1          BGP    Preference: 170/-101                 Source: 192.168.12.1                 Nexthop: 10.0.15.1 via fe-0/1/2.0, selected                 Protocol Nexthop: 10.0.8.1 Indirect nexthop: 8378440 39                 State: <NotBest Int Ext>                 Inactive reason: IGP metric                 Local AS:   600 Peer AS:   600                 Age: 38:33      Metric2: 30                 Task: BGP_600.192.168.12.1+179                 AS path: 400 I                 Localpref: 100                 Router ID: 192.168.12.1 

Now that we have a grasp on how the typical routing scenario works, we will set our LOCAL_PREF attribute on Denver to cause it to be the preferred point of egress to reach the 172.4.0.0/16 network and set the LOCAL_PREF on Dallas to cause it to be the preferred point of egress to reach the 172.1.0.0/16 network. This is not the most optimal way to route traffic, given this topology, but it serves the purpose of showing how LOCAL_PREF will affect routing and, potentially , how it could be misused.

Now, if we take a look at the routing table from Dallas to network 172.4.0.0/16 , we see that the active route is now going through the Denver border router.

 lab@dallas> show route 172.4.0.0/16  inet.0: 18 destinations, 18 routes (17 active, 0 holddown, 1 hidden) + = Active Route, - = Last Active, * = Both 172.4.0.0/16       *[BGP/170] 01:02:57, localpref 200, from 192.168.0.1                       AS path: 400 I                     > to 10.0.13.1 via fe-0/1/0.0                     [BGP/170] 01:03:41, localpref 100                       AS path: 400 I                     > to 10.0.8.1 via fe-0/1/1.0 

When we look at the routing table from Denver to network 172.1.0.0/16 , we see that the active route is now going through the Dallas border router.

 lab@denver> show route 172.1.0.0/16  inet.0: 17 destinations, 17 routes (16 active, 0 holddown, 1 hidden) + = Active Route, - = Last Active, * = Both 172.1.0.0/16       *[BGP/170] 00:05:03, localpref 200, from 192.168.12.1                       AS path: 400 100 I                     > to 10.0.16.1 via fe-0/1/1.0                     [BGP/170] 01:05:10, localpref 100                       AS path: 100 I                     > to 10.0.1.1 via fe-0/1/2.0                     [BGP/170] 01:05:06, localpref 100                       AS path: 400 100 I                     > to 10.0.0.2 via fe-0/1/0.0 

Again, these are not the most optimal routing scenarios, which is all the more reason to pay close attention when manipulating LOCAL_PREF to change the routing characteristics of your AS.

10.2.2 NEXT_HOP

We will now take a look at the NEXT_HOP attribute and how it works in an operational environment. When we speak about the term next-hop in routing, especially when BGP is involved, we can be talking about two different subjects. First, there is the next-hop that most people are familiar with, that being the next-hop to send a packet to. Basically a next-hop identifies an address and an egress interface. The second next-hop is a bit more involved as we are referring to protocol next-hop. This is important because BGP will need to be able to resolve this next-hop, which is the NEXT_HOP attribute. In order for BGP to install a route into the routing table, it must be able to do a recursive lookup to the routing table and resolve the address in the NEXT_HOP attribute. If the address in the NEXT_HOP attribute cannot be resolved, then the route will not be installed into the routing table. When a route is advertised from one AS to another, the route is sent from one EBGP router to another. The gaining EBGP router usually has no problem resolving the next-hop, because the next-hop is usually the address of the directly connected subnet that hosts the EBGP session. In IBGP the NEXT_HOP attribute takes on a different value. We will see this and come to understand how the NEXT_HOP attribute is used.

In Figure 10-3, you can see that router Atlanta in AS200 is sending prefix 172.16.16.0/24 to router Washington D.C. in AS100. In this case, Washington D.C. will receive the route with the NEXT_HOP attribute set to 10.0.2.2 . The reason for this is that Atlanta sends the prefix to Washington D.C., setting the NEXT_HOP attribute to the address of the physical interface that is used to establish the peering session. So, in the case of this connection, 10.0.2.2 is being used.

Figure 10-3. NEXT_HOP Case Study

The following example shows router Washington D.C.'s routing table. You can see the route for the 172.16.16.0/24 network learned through BGP with a next-hop of 10.0.2.2 . This will become clearer in the next example.

 lab@DC> show route 172.16.16.0  inet.0: 20 destinations, 20 routes (19 active, 0 holddown, 1 hidden) + = Active Route, - = Last Active, * = Both 172.16.16.0/24     *[BGP/170] 01:15:10, MED 0, localpref 100                       AS path: 200 I                     >  to 10.0.2.2 via fe-0/1/0.0  

The next example shows the same route with the show route 172.16.16.0 extensive command on Washington D.C. You can see that the NEXT_HOP advertised was 10.0.2.2 , which is exactly how BGP works. The advertising router Atlanta is sending itself as the NEXT_HOP . The output will vary between EBGP and IBGP sessions. We will show this over the next few examples.

 lab@DC> show route 172.16.16.0 extensive  inet.0: 20 destinations, 20 routes (19 active, 0 holddown, 1 hidden) + = Active Route, - = Last Active, * = Both  172.16.16.0/24 (1 entry, 1 announced)  TSI: KRT in-kernel 172.16.16.0/24 -> {10.0.2.2} Page 0 idx 0 Type 1 val 8382d20  Nexthop: 10.0.2.2 (this is the attribute NEXT_HOP)  MED: 0     Localpref: 100     AS path: 200 I     Communities: Page 0 idx 1 Type 1 val 8382cb0     Nexthop: 10.0.2.2     AS path: 200 I     Communities: Path 172.16.16.0 from 10.0.2.2 Vector len 4.  Val: 0 1         *BGP   Preference: 170/-101  Source: 10.0.2.2   Nexthop: 10.0.2.2 via fe-0/1/0.0, selected  State: <Active Ext>                Local AS:   100 Peer AS:   200                Age: 1:17:51    Metric: 0                Task: BGP_200.10.0.2.2+179                Announcement bits (3): 0-KRT 1-BGP.0.0.0.0+179 4-Resolve inet.0                 AS path: 200 I                Localpref: 100                Router ID: 4.4.4.4 

This next example of the routing table for router New York shows things coming together. You can see again the route 172.16.16.0/24 was learned through BGP and from ID 1.1.1.1 , which is router Washington D.C. The next-hop listed for this route is 10.0.24.1 . Now, we discussed a few moments ago how the term next-hop can be either the physical next-hop to a destination or a protocol next-hop, as in the BGP NEXT_HOP attribute. In the show route listing here, the portion that shows to 10.0.24.1 via fe-0/1/1.0 is actually the gateway to be used to get to the prefix. There is also a route in there for the 10.0.2.0/24 network. Remember this for we will discuss it further shortly.

 lab@NewYork> show route  inet.0: 11 destinations, 11 routes (10 active, 0 holddown, 1 hidden) + = Active Route, - = Last Active, * = Both 1.1.1.1/32         *[OSPF/10] 00:19:12, metric 10                     > to 10.0.24.1 via fe-0/1/1.0 2.2.2.2/32         *[Direct/0] 02:30:01                     > via lo0.0 10.0.2.0/24        *[OSPF/10] 00:19:12, metric 20                     > to 10.0.24.1 via fe-0/1/1.0 10.0.24.0/24       *[Direct/0] 1w1d 00:03:15                     > via fe-0/1/1.0 10.0.24.2/32       *[Local/0] 1w1d 00:03:15                      Local  172.16.16.0/24     *[BGP/170] 00:32:47, MED 0, localpref 100, from 1.1.1.1   AS path: 200 I   > to 10.0.24.1 via fe-0/1/1.0  

The example below shows the show route 172.16.16.0 extensive command. About halfway through the listing you see Nexthop: 10.0.24.1 via fe-0/1/1.0 , and immediately following, you see Protocol Nexthop: 10.0.2.2 . This last part is the actual NEXT_HOP attribute being passed. It also indicates that it is an indirect next-hop, which should clue you in on the contents. This is where it all comes together. BGP passes the NEXT_HOP attribute, which is the border router 10.0.2.2 . The reason that we are able to see this route as the active route is that BGP was able to resolve the NEXT_HOP attribute in the IGP, which is 10.0.2.0/24 . Taking a close look at this, we see that the route 10.0.2.0 uses a gateway address of 10.0.24.1 .

 lab@NewYork> show route 172.16.16.0 extensive  inet.0: 15 destinations, 15 routes (14 active, 0 holddown, 1 hidden) + = Active Route, - = Last Active, * = Both 172.16.16.0/24 (1 entry, 1 announced) TSI: KRT in-kernel 172.16.16.0/24 -> {indirect(43)}         *BGP    Preference: 170/-101                 Source: 1.1.1.1  Nexthop: 10.0.24.1 via fe-0/1/1.0, selected   Protocol Nexthop: 10.0.2.2 Indirect nexthop: 83785d8 43  State: <Active Int Ext>                 Local AS:   100 Peer AS:   100                 Age: 27:05      Metric: 0       Metric2: 20                 Task: BGP_100.1.1.1.1+179                 Announcement bits (2): 0-KRT 4-Resolve inet.0                 AS path: 200 I                 Localpref: 100                 Router ID: 1.1.1.1  Indirect nexthops: 1  Protocol nexthop: 10.0.2.2 Metric: 20 Indirect nexthop: 83785d8 43  Indirect path forwarding nexthops: 1   Nexthop: 10.0.24.1 via fe-0/1/1.0  

Next, we will see what happens when we remove the 10.0.2.0/24 network from our IGP. Looking at the routing table for Washington D.C., we see that nothing has changed and that we still see the route. This is because the NEXT_HOP that needs to be resolved is a directly connected network, and thus the recursive lookup will be successful.

 lab@DC> show route 172.16.16.0  inet.0: 20 destinations, 20 routes (19 active, 0 holddown, 1 hidden) + = Active Route, - = Last Active, * = Both 172.16.16.0/24     *[BGP/170] 01:39:04, MED 0, localpref 100                       AS path: 200 I                     > to 10.0.2.2 via fe-0/1/0.0 

However, if we take a look in the routing table for New York, we will not see the route. The route does not exist anymore, or does it?

 lab@NewYork> show route 172.16.16.0 

The next example shows the output from the s how route 172.16.16.0 hidden extensive command. You can see the route is here because it was advertised by BGP. However, BGP was unable to resolve the next-hop information because our IGP knows nothing about the 10.0.2.0/24 network.

 lab@NewYork> show route 172.16.16.0 hidden extensive  inet.0: 14 destinations, 14 routes (9 active, 0 holddown, 5 hidden) + = Active Route, - = Last Active, * = Both 172.16.16.0/24 (1 entry, 0 announced) TSI:          BGP    Preference: 170/-101  Next-hop type: Unusable   State: <Hidden Int Ext>  Local AS:   100 Peer AS:   100                 Age: 44:24      Metric: 0                 Task: BGP_100.1.1.1.1+179                 AS path: 200 I                 Localpref: 100                 Router ID: 1.1.1.1                 Indirect nexthops: 1                      Protocol nexthop: 10.0.2.2 Indirect nexthop: 83785d8 43 

10.2.3 Nexthop-Self

The next part of this case study will deal with nexthop-self. Figure 10-4 shows the topology we will use for this scenario. As we discussed a few moments ago, BGP will need to be able to resolve the NEXT_HOP address before it can make a route active in the routing table. In the following scenario, we will show how the nexthop-self policy can be used to achieve our desired results. Up until now, we have been taking the network between EBGP peers and advertising it into our IGP through the use of the passive command for a given interface. We know from Section 8.4.6 that the use of the passive command will allow the interface and network associated with it to be advertised into the IGP, but it will not form any adjacencies to any neighbors on that interface. There are times when putting the EBGP link into the IGP may not be desirable. There are also times when you want a BGP router to simply advertise itself as the NEXT_HOP for a given network.

Figure 10-4. Nexthop-Self Case Study

We will first see what our routing table looks like when we have the IGP advertising the EBGP link between Washington D.C. and Denver into AS200. In the Atlanta router, we see that the next-hop advertised in Protocol Nexthop: 10.0.1.2 can be reached via Nexthop: 10.0.2.1 via fe-0/1/2.0 is because OSPF is running passively on interface fe-0/1/2 .

 lab@Atlanta> show route 172.16.0.0/16 detail  inet.0: 16 destinations, 16 routes (15 active, 0 holddown,  1 hidden  ) + = Active Route, - = Last Active, * = Both 172.16.0.0/16 (1 entry, 1 announced)         *BGP    Preference: 170/-101                 Source: 192.168.2.1                 Nexthop: 10.0.2.1 via fe-0/1/2.0, selected                 Protocol Nexthop: 10.0.1.2 Indirect nexthop: 83784c8 23                 State: <Active Int Ext>                 Local AS:   200 Peer AS:   200                 Age: 12:24      Metric2: 20                 Task: BGP_200.192.168.2.1+179                 Announcement bits (2): 0-KRT 4-Resolve inet.0                 AS path: 100 I                 Localpref: 100                 Router ID: 192.168.2.1 

Next, we see what happens when we remove the passive from our configuration on fe-0/1/2 . We know that Washington D.C. will still be able to reach the network 172.16.0.0/16 because it is directly connected to the subnet that the next-hop is on. But, when we look at Atlanta, we get no result. You will notice that there is now a second hidden route when we issue our show route 172.16.0.0/16 command.

 lab@Atlanta> show route 172.16.0.0/16  inet.0: 15 destinations, 15 routes (13 active, 0 holddown,  2 hidden  ) + = Active Route, - = Last Active, * = Both 

This second hidden route is our BGP route. It is hidden from us and will never become active owing to the inability of Atlanta to resolve the next-hop during the recursive lookup. If we issue the show route 172.16.0.0/16 hidden detail command, we see the following results. The next-hop type is listed as unusable because the recursive lookup was unsuccessful .

 lab@Atlanta> show route 172.16.0.0/16 hidden detail  inet.0: 15 destinations, 15 routes (13 active, 0 holddown, 2 hidden) + = Active Route, - = Last Active, * = Both 172.16.0.0/16 (1 entry, 0 announced)  BGP    Preference: 170/-101  Next-hop type: Unusable                 State: <Hidden Int Ext>                 Local AS:   200 Peer AS:   200                 Age: 21:28                 Task: BGP_200.192.168.2.1+179                 AS path: 100 I                 Localpref: 100                 Router ID: 192.168.2.1 

The way we can solve this without using the passive interface in our IGP is to use the nexthop-self policy. Our policy is listed here:

 policy-options {      policy-statement nexthop-self {         from protocol bgp;         then {             next-hop self;         }     } } 

The policy is implemented in our BGP session in the following way:

 protocols {      bgp {         group IBGP {             type internal;             local-address 192.168.2.1;  export nexthop-self;  neighbor 192.168.5.1;             neighbor 192.168.12.1;         }     } } 

Now, if we go into our Atlanta router and issue the show route 172.16.0.0/16 detail command, we get the following results. You will notice that the Protocol Next-hop is 192.168.2.1 , whereas before it was 10.0.1.2 . Our nexthop-self policy does this for us. It is a very simple method of controlling next-hop for BGP in cases where the present IGP may not be able to do a recursive lookup on the next-hop. What would happen here is that a packet destined for 172.16.0.0/16 would come to Washington D.C. We would then rely on Washington D.C. to route the packet through the rest of the network.

 lab@Atlanta> show route 172.16.0.0/16 detail  inet.0: 15 destinations, 15 routes (14 active, 0 holddown, 1 hidden) + = Active Route, - = Last Active, * = Both 172.16.0.0/16 (1 entry, 1 announced)         *BGP    Preference: 170/-101                 Source: 192.168.2.1  Nexthop: 10.0.2.1 via fe-0/1/2.0, selected   Protocol Nexthop: 192.168.2.1 Indirect  nexthop: 8378550 23                 State: <Active Int Ext>                 Local AS:   200 Peer AS:   200                 Age: 29:16      Metric2: 10                 Task: BGP_200.192.168.2.1+179                 Announcement bits (2): 0-KRT 4-Resolve inet.0                 AS path: 100 I                 Localpref: 100                 Router ID: 192.168.2.1 

This concludes the case study for next-hop. You have seen how next-hop applies to the interior and exterior of an AS and the interpretation of each. You now know why the IGP is so important to BGP for recursive lookups and how the lack of routing information in IGP can cause your BGP routes not to be installed. We can also overcome some obstacles of the recursive lookup problem through implementation of nexthop-self policy.

10.2.4 MED

The MED attribute is used to tell a remote AS which links to prefer when sending traffic to the local AS. In this scenario, we will refer to Figure 10-5. In this example, Renda's Travel Service uses MOMO ISP for Internet connectivity. Since Renda's Travel Services is a nationwide operation, there are two major gateways: one in Los Angeles, California, and the other in Raleigh, North Carolina. Everything east of the Mississippi comes into the Raleigh site, and everything west of the Mississippi comes into the Los Angeles site. Because of the 24-7 support that Renda's Travel Service provides to its customer base, there must be Internet connectivity at all times.

Figure 10-5. MED Case Study

MOMO ISP has assigned two blocks of address space to Renda's Travel Service. The travel service's network engineers utilize the 172.16.0.0/23 address space for the western region and 172.16.2.0/23 for the eastern region. In general terms, both Los Angeles and Raleigh could advertise the entire address space equally with an advertisement of 172.16.0.0/22 . This would tell MOMO ISP to send the traffic for the entire address space to either location. Bandwidth is expensive, however, and we want to provide the best use of the bandwidth for our client. Instead, we will have Los Angeles advertise 172.16.0.0/23 with a MED = 50 and 172.16.2.0/23 with a MED = 100.

In addition, we will have Raleigh do just the opposite : 172.16.0.0/23 with a MED = 100 and 172.16.2.0/23 with a MED = 50. With this we are telling MOMO to prefer the link between San Francisco and Los Angeles for the 172.16.0.0/23 address space and the link between Washington D.C. and Raleigh for the 172.16.2.0/23 address space. MOMO does not have to do anything with this MED value and can completely ignore it, but since we are a persistent integrator, we finally negotiate a policy for MOMO to use our MED values. This setup also allows us a backup in case either the San Francisco or Los Angeles ISP links go down.

ISPs and customers do not always "listen" to the MED value, mostly because there is potential for dishonesty in the use of the MED value for manipulation of how the other side is going to pass traffic. In a well-negotiated environment, though, where the trust has been built between the client and provider, use of this attribute can be very beneficial.

Now that we have laid some groundwork , let's see how it all works together. We will be looking at the routing table in router San Francisco. Notice that there are two routes: one for the 172.16.0.0/23 network and another for the 172.16.2.0/23 network. Each of these is sent to San Francisco from Los Angeles with different MED values. With these settings, any traffic sent to San Francisco destined for network 172.16.0.0/23 will be sent to Los Angeles. If traffic is destined for the 172.16.2.0/23 network, it will traverse the link from San Francisco to Washington D.C., then to Raleigh. If for some reason there is a link failure between San Francisco and Washington D.C., then all traffic intended for the 172.16.2.0/23 network would be sent to Los Angeles via San Francisco.

 lab@SanFrancisco> show route 172.16.0.0/22  inet.0: 19 destinations, 19 routes (18 active, 0 holddown, 1 hidden) + = Active Route, - = Last Active, * = Both 172.16.0.0/23      *[BGP/170] 01:05:05, MED 50, localpref 100                       AS path: 100 I                     > to 10.0.24.2 via fe-0/1/1.0 172.16.2.0/23      *[BGP/170] 00:23:39, MED 50, localpref 100, from 4.4.4.4                       AS path: 100 I                     > to 10.0.2.2 via fe-0/1/0.0                     [BGP/170] 01:05:05, MED 100, localpref 100                       AS path: 100 I                     > to 10.0.24.2 via fe-0/1/1.0 

Next, we have the routing table for Washington D.C. In this case, you can see just the opposite effect with the different networks. The path information will switch.

 lab@DC> show route 172.16.0.0/22  inet.0: 17 destinations, 17 routes (16 active, 0 holddown, 1 hidden) + = Active Route, - = Last Active, * = Both 172.16.0.0/23      *[BGP/170] 01:06:51, MED 50, localpref 100, from 1.1.1.1                       AS path: 100 I                     > to 10.0.2.1 via fe-0/1/2.0                     [BGP/170] 00:25:25, MED 100, localpref 100                       AS path: 100 I                     > to 10.0.8.2 via fe-0/1/1.0 172.16.2.0/23      *[BGP/170] 00:25:25, MED 50, localpref 100                       AS path: 100 I                     > to 10.0.8.2 via fe-0/1/1.0 

In this next example, we are going to take down the link between San Francisco and Los Angeles. We will see, in the next two examples, the changes to the routing table. The first example is the routing table for San Francisco. We now will route through Washington D.C. for all traffic destined to any network in the 172.16.0.0/22 block.

 lab@SanFrancisco> show route 172.16.0.0/22  inet.0: 17 destinations, 17 routes (16 active, 0 holddown, 1 hidden) + = Active Route, - = Last Active, * = Both 172.16.0.0/23      *[BGP/170] 00:00:13, MED 100, localpref 100, from 4.4.4.4                       AS path: 100 I                     > to 10.0.2.2 via fe-0/1/0.0 172.16.2.0/23      *[BGP/170] 00:35:23, MED 50, localpref 100, from 4.4.4.4                       AS path: 100 I                     > to 10.0.2.2 via fe-0/1/0.0 

For good measure, the following shows the table for Washington D.C. We see that any traffic for the 172.16.0.0/23 or 172.16.2.0/23 networks will be sent out of the link from Washington D.C. to Raleigh.

 lab@DC> show route 172.16.0.0/22  inet.0: 15 destinations, 15 routes (14 active, 0 holddown, 1 hidden) + = Active Route, - = Last Active, * = Both 172.16.0.0/23      *[BGP/170] 00:37:34, MED 100, localpref 100                       AS path: 100 I                     > to 10.0.8.2 via fe-0/1/1.0 172.16.2.0/23      *[BGP/170] 00:37:34, MED 50, localpref 100                       AS path: 100 I                     > to 10.0.8.2 via fe-0/1/1.0 

If we were to flip this scenario around and break the link between Washington D.C. and Raleigh, we would see similar results.

Through the use of MED , we now understand how to manipulate the way the neighboring AS sees our route advertisements. MED can be used to take advantage of links the local AS prefers and to balance inbound traffic patterns to an extent.