Miscellaneous EBGP Timers and Knobs

The EBGP protocol supports many of the same timers and miscellaneous options that were discussed in the previous IBGP chapter. This section will focus on options that are unique to EBGP. The use of local-as and remove-private are not demonstrated here because they are required in the chapter's case study and so will be illustrated in that section.

To complete this section, you must configure your network in accordance with the following tasks:

• Peer P1 has incorrectly prepended your AS number to one of its routes. You must configure your network to accept this route.

• Use policy so that packets forwarded by T2 will tend to use the 172.16.0.20/30 link to r6 without prepending AS numbers.

• Without using policy, make sure that all routers in your AS use r3 when forwarding to transit destinations.

AS Loops

Your routers will discard any route that contains the local AS number in the AS path list by default. Such routes are not stored in the Routing Information Base (RIB), so they will not be displayed, even with the hidden switch. Setting keep all will cause them to be retained, but the AS loop condition will prevent the route from becoming active. To complete this objective, you must tell r1 and r2 that they should accept routes that contain the local AS number in the path:

[edit routing-options] lab@r1# set autonomous-system loops 2 [edit routing-options] lab@r1# commit commit complete

Note that you will need to set the loops parameter to at least 2, because the default setting of 1 means that a route can cross a given AS only once, and for this route to be accepted, you must indicate that it can cross the local AS twice. After committing, you attempt to verify the route is now present and active:

[edit routing-options] lab@r1# run show route 120.120/16 | match 65412 [edit routing-options] lab@r1#

It would seem that attempt was the right word, because the output from the command indicates that no routes received from P1 contain the local AS number. Before chasing the proverbial wild goose, you should clear the BGP session to force P1 to re-advertise its routes. This action is needed because a BGP speaker will advertise a given route only once due to BGP's reliance on the error correction and acknowledged delivery services of its TCP-based transport. Therefore, if the receiving peer chooses not to install a prefix in its incoming RIB, due to a failed sanity check involving AS loops, for example, then you will need to have the remote peer re-advertise its routes to get things working. JUNOS software support for BGP refresh allows the soft clearing of a BGP neighbor whereby r1 will request that P1 resend all of its advertised routes without having to tear down the established connection:

[edit routing-options] lab@r1# run clear bgp neighbor 10.0.5.254 soft-inbound [edit routing-options] lab@r1# run show route 120.120/16 | match 65412  AS path: 65050 65412 I 

After the soft clearing, a route with the local AS number is now present and active in r1. Before proceeding, you must remember to adjust r2's configuration also, else the failure of r1 will result in the loss of this route.

Influence Incoming Traffic Flow

With AS path prepending not permitted, the second criterion requires that you set the MED attribute in the routes advertised to your transit providers in such a way that T2 will choose the routes advertised by r6 over the same routes as sent from r3. The tricky part of this task relates to the fact that lower MED values are preferred (unlike local preference), and that the absence of the MED attribute is interpreted by JUNOS software as a MED value of 0, which is the lowest MED value possible. Operators lacking experience with the MED attribute will often define a policy on r6 that sets the MED to some value and call it a day. Having only r6 send a MED will automatically result in T2 using the routes advertised by r3, due to the absence of the MED attribute being interpreted as a value of 0. Such a condition results in a behavior that is the exact opposite of what you are trying to achieve.

While you could write policies that instruct both r3 and r6 to attach the MED attribute, being careful to make sure that r3's MED value is higher than r6's, the simplest solution is to have only r3 attach the MED attribute. This will leverage the fact that r6's routes, which will lack the MED attribute, will be interpreted as having a lower MED value. Based on the requirements of this task, it is recommended that you apply your MED policy on r3 in such a way that it will affect only the routes sent to T2. You must also be careful to make sure that all advertised routes have the MED correctly attached. The policy example shown here will attach the MED only to customer routes, due to the local 10/8 aggregate being accepted in term 1 before the MED action in term 4 is ever analyzed:

[edit policy-options policy-statement transit-export] lab@r3# show term 1 {      from {         protocol aggregate;         route-filter 10.0.0.0/8 exact;      }      then accept; } term 2 {     from community [ peers transit ];      then reject; } term 3 {      from {         route-filter 192.168.0.0/16 orlonger reject;      } } term 4 {     then {         metric 100;     } } 

You could choose to modify the existing transit-export policy to include the MED action, but you should first copy it (with a new name) so that you can later apply the modified MED- related export policy to the r3-T2 peering session only. Another alternative is to create a new policy for MED-related activities, which is the approach taken here. The new med policy is displayed next:

[edit] lab@r3# show policy-options policy-statement med term 1 {    then {       metric 100;    }  }

The med policy is not protocol source-specific, because listing from protocol bgp in term 1, for example, would prevent the 10/8 aggregate from having the correct MED attached. Putting an accept action in a match all policy such as this one would result in every active route being exported to T2, which proves that attention to detail is what JUNOS software routing policy is all about. You now apply the med policy to r3 so that it will only affect the T2 peering session, as shown next:

[edit protocols bgp] lab@r3# show group t1-t2 type external; import [ damp bogons community ]; export transit-export; peer-as 65222; multipath; neighbor 172.16.0.14; neighbor 172.16.0.18 {     export med;  }

The problem now is that you have exempted T2 from the t1-t2 group's transit-export policy because of the neighbor-level application of the med policy. The absence of a neighbor- level import policy means that all neighbors listed in the t1-t2 group will still process the damp, bogons, and community policies, however. To correct this situation, you add the transit- export policy at the 172.16.0.18 neighbor level, as shown next:

[edit protocols bgp] lab@r3# show group t1-t2 type external; import [ damp bogons community ]; export transit-export; peer-as 65222; multipath; neighbor 172.16.0.14; neighbor 172.16.0.18 {    export [ med transit-export ];  }

One last point that bears mentioning is that the nature of the transit-export policy requires that the new med policy be evaluated first. If the med policy is processed after the transit-export policy, the 10/8 aggregate will not have the MED attribute attached because of its acceptance by the transit-export policy's first term. You can rearrange the order of chained policies by using the CLI's insert feature when needed.

This capture shows the state of T2's path selection before you commit the med policy changes:

[edit] lab@T2# run show route 10/8 inet.0: 117445 destinations, 117483 routes (117445 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 10.0.0.0/8          *[BGP/170] 00:18:05, localpref 100                        AS path: 65412 I                      > to 172.16.0.17 via fe-0/0/2.0                      [BGP/170] 02:22:03, localpref 100                        AS path: 65412 I                      > to 172.16.0.21 via fe-0/0/1.0                      [BGP/170] 07:47:04, localpref 100                        AS path: 65412 I                     > to 10.0.1.65 via fe-0/0/0.0

T2 currently prefers the 10/8 advertisement from r3 because of its lower router ID. After committing your changes on r3, you can easily confirm the correct setting of the MED attribute in r3's advertisements to T2:

 [edit] lab@r3# run show route advertising-protocol bgp 172.16.0.18 detail | match MED     MED: 100     MED: 100     . . .     MED: 100

The same approach is used to confirm that the MED attribute is not attached to the routes being advertised to T1:

[edit] lab@r3# run show route advertising-protocol bgp 172.16.0.14 detail | match MED [edit] lab@r3#

The output confirms that your MED-related policy modifications are spot on. Though you may not have access to external routers during the actual examination, in this test bed you do, so why not take some time to verify that T2's forwarding behavior has been modified by your med policy on r3?

[edit] lab@T2# run show route 10/8 inet.0: 117454 destinations, 117492 routes (117454 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 10.0.0.0/8          *[BGP/170] 02:26:48, localpref 100                        AS path: 65412 I                     > to 172.16.0.21  via fe-0/0/1.0                      [BGP/170] 07:51:49, localpref 100                        AS path: 65412 I                     > to 10.0.1.65 via fe-0/0/0.0                     [BGP/170] 00:00:02, MED 100, localpref 100                        AS path: 65412 I                      > to 172.16.0.17 via fe-0/0/2.0

T2 now forwards traffic through r6 instead of r3, indicating that your med policy application to r3 has correctly altered the results of the active route selection process on T2. This results in the redirection of traffic from T2 onto the T2-r6 peering link instead of the RID-based decision that had resulted in the use of the T2-r3 link.

This particular MED application could have been performed without using policy by specifying the metric-out keyword in r3's BGP configuration stanza at the T2 neighbor level. Policy is normally the preferred way to set MED because it provides greater granularity and increased flexibility with MED settings. MED values set through policy override the MED values configured under the BGP stanza. One alternative r3 configuration that meets the requirements of this task would be as follows. Note the lack of a med policy, and the fact that both of r3's sessions to transit providers now execute the same export policy defined at the group level:

[edit protocols bgp group t1-t2] lab@r3# show type external; import [ damp bogons community ]; export transit-export; peer-as 65222; multipath; neighbor 172.16.0.14; neighbor 172.16.0.18 {     metric-out 100;  }

Set Local Preference Directly

The last requirement can be achieved by setting the local preference of r3's c-bgp peer group directly so that routing policy is not involved. You can also set local preference in the 65000 peer group, but this is not needed, as r3's lower RID already causes r1 and r2 to select r3's routes as active. The suggested change will also affect the local preference setting of the 192.168.x/24 routes that originate in subconfederation 65000, but this does not alter packet forwarding due to r3 having a preferred RID when compared to r4. The prefer-2 import policy on r3 and r4 continues to ensure that packets addressed to the 192.168.100/24 prefix, as advertised by both r1 and r2, are still forwarded to r2.

Before adjusting r3's local preference, confirm that r7 forwards through the metrically closer r6 for transit destinations:

[edit] lab@r7# run show route 4/8 inet.0: 112338 destinations, 114557 routes (112334 active, 0 holddown, 4 hidden) + = Active Route, - = Last Active, * = Both 4.0.0.0/8          *[BGP/170] 00:00:29, localpref 100 , from 10.0.9.6                       AS path: 65222 10458 3944 2914 1 I                      > to 10.0.8.1 via fe-0/3/0.0                     [BGP/170] 01:32:09, localpref 100 , from 10.0.3.5                       AS path: (65000) 65222 10458 3944 2914 1 I                      > to 10.0.8.9 via fe-0/3/1.0 

The highlighted change is now committed on r3:

[edit] lab@r3# show protocols bgp group c-bgp type external; local-preference 200; neighbor 10.0.2.1 {    peer-as 65001;  }

You confirm the effects of the change at r7:

[edit] lab@r7# run show route 4/8 inet.0: 112339 destinations, 198459 routes (112332 active, 60391 holddown, 4 hidden) + = Active Route, - = Last Active, * = Both 4.0.0.0/8 *[BGP/170] 01:34:19, localpref 200, from 10.0.3.5  AS path: (65000) 65222 10458 3944 2914 1 I > to 10.0.8.9 via fe-0/3/1.0

The output confirms that the route's local preference has been altered, and that the modified local preference value has resulted in the desired forwarding behavior at r7. Traceroute testing shows that even r6 has installed r3's routes, despite it having a direct EBGP peering session with T2!

[edit] lab@r6# run traceroute 130.130.0.1 traceroute to 130.130.0.1 (130.130.0.1), 30 hops max, 40 byte packets  1 10.0.8.6 (10.0.8.6) 0.417 ms 0.330 ms 0.251 ms  2 10.0.2.2 (10.0.2.2) 1.230 ms 1.016 ms 0.887 ms  3 130.130.0.1 (130.130.0.1) 0.379 ms 0.677 ms 0.397 ms

The various screen outputs confirm that you have met the requirements of the 'Miscellaneous EBGP Timers and Knobs' section.