IBGP Confederations

Confederations are another technique that can be used to eliminate the need for a full mesh of IBGP connections. In operation, you divide your AS into multiple subconfederations. Routers within a subconfederation require either full mesh or route reflection connectivity, while the subconfederations themselves are tied together using a special type of EBGP, called C-BGP. C-BGP operates like EBGP, with the exception that certain IBGP attributes, such as local preference, and the BGP next hop, are conveyed unchanged between the subconfederations.

Each subconfederation requires a unique AS number, called the confederation member AS, and will also require a real AS number, referred to as the confederation AS, which will be used when interfacing to routers that belong to a nonconfederation member AS. Lastly, each router in a confederation requires a complete list of all the autonomous system's confederation member AS values, so that C-BGP and EBGP updates can be handled appropriately after matching the remote peer's AS value against the complete list of known confederation members.

Configure a Confederation

To complete this configuration example, you need to deploy a confederation topology that meets the following criteria:

• Your confederation AS is 65412.

• Use AS numbers in the range of 65000 to 65003 for confederation member AS values.

• The failure of any link must not cause the loss of BGP routes (black holes) or the disruption of BGP sessions.

• The confederation topology must not impose suboptimal routing.

• You must have at least three subconfederations.

• Support loopback interface-based peering for all IBGP and C-BGP sessions.

• Continue to redistribute the 192.168.x/24 static routes through BGP.

Before starting your configuration, it is suggested that you first establish a design for a confederation topology that meets all specified criteria. Figure 5.4 provides an example of such a topology.

Figure 5.4: Suggested confederation topology

Figure 5.4 provides an example of a confederation topology that meets the requirements of the configuration example in a relatively straightforward way. IBGP sessions within a subcon- federation are shown with small dashes while the C-BGP sessions used between subconfederations are shown with large dashes. The IBGP/C-BGP connections shown represent the minimum number of BGP sessions required to meet the failover requirements of the example. The loss of the Fast Ethernet link between r1 and r3, for example, will not prevent the lo0-based peering session from being established over another path that uses a different set of interfaces; this inherent fault tolerance is the principal benefit and motivation to loopback-based peering. Additional C-BGP sessions could be added to your design-for example, between r1 and r2-but the added redundancy will not earn you any extra points in this example.

Once again, r5 represents a single point of failure that would isolate routers in subconfederation 65002; your design must tolerate only individual interface and link failures, however. The example topology will not impose any route inefficiencies that can be blamed on your BGP design, but you should not be surprised to find that some paths incur extra hops due to the nature of IS-IS level 1 routing.

Figure 5.5 provides an alternative topology that also meets the stated design requirements. The use of lo0 peering means that some of the C-BGP connections shown are really not needed to satisfy the link and interface failure requirements of this configuration example, but a little added insurance has never hurt anyone.

Figure 5.5: An alternative confederation topology

Before starting your configuration, delete your existing BGP stanza to avoid confusion and to better simulate the thrill of embarking on a new lab scenario.

Configure Subconfederation 65000

The following commands correctly configure r1 for the confederation topology shown earlier in Figure 5.4. You begin by deleting the leftover route reflection configuration, because it would otherwise just get in your way:

[edit] lab@r1# delete protocols bgp [edit] lab@r1# edit protocols bgp group 65000 [edit protocols bgp group 65000] lab@r1# set type internal local-address 10.0.6.1 [edit protocols bgp group 65000] lab@r1# set neighbor 10.0.3.3 

The stipulations for this scenario do not require MD5-based authentication or BGP connection state tracing, so neither has been deployed. Also note that the peer group for subconfederation 65000 members is set to run IBGP through the declaration that the group's type is internal. To complete r1's BGP stanza, you must now apply the ibgp export policy to effect static route redistribution:

[edit protocols bgp group 65000] lab@r1# set export ibgp 

The completed BGP stanza for r1 is shown next:

[edit protocols bgp group 65000] lab@r1# show type internal; local-address 10.0.6.1; export ibgp; neighbor 10.0.3.3;

To finish r1's configuration, you now define the confederation AS and confederation member AS numbers as shown in the following:

[edit routing-options] lab@r1# set autonomous-system 65000 [edit routing-options] lab@r1# set confederation 65412 [edit routing-options] lab@r1# set confederation members 65000 [edit routing-options] lab@r1# set confederation members 65001 [edit routing-options] lab@r1# set confederation members 65002 

You should list all the AS numbers that will be used by AS 65421 confederation members, being sure to include the router's own subconfederation AS number as well. Because r1 uses only IBGP peering in this example, the confederation-related configuration in r1 is not strictly necessary. However, including these statements now causes no harm, and will prove especially useful should r1 later pick up a C-BGP peering session. The completed routing-options stanza for r1 is displayed next:

[[edit routing-options] lab@r1# show static {    route 10.0.200.0/24 next-hop 10.0.1.102;    route 192.168.10.0/24 reject;  } autonomous-system 65000; confederation 65412 members [ 65000 65001 65002 ];

To complete the configuration of subconfederation 65000, the following configuration statements are entered on r3:

[edit] lab@r3# delete protocols bgp [edit] lab@r3# edit protocols bgp group 65000 [edit protocols bgp group 65000] lab@r3# set type internal local-address 10.0.3.3 [edit protocols bgp group 65000] lab@r3# set neighbor 10.0.6.1 [edit protocols bgp group 65000] lab@r3# set export ibgp 

As with r1, you must now reassign r3's AS number and list all the confederation AS members that belong to the confederated AS 65412 using the following configuration statements:

[edit routing-options] lab@r1# set autonomous-system 65000 [edit routing-options] lab@r3# set confederation 65412 [edit routing-options] lab@r3# set confederation members 65000 [edit routing-options] lab@r3# set confederation members 65001 [edit routing-options] lab@r3# set confederation members 65002 

The modified portions of r3's configuration are now displayed with highlights added:

[edit] lab@r3# show routing-options static {     route 10.0.200.0/24 next-hop 10.0.1.102;     route 192.168.10.0/24 reject; } aggregate {      route 10.0.4.0/22; } autonomous-system 65000; confederation 65412 members [ 65000 65001 65002 ]; [edit] lab@r3# show protocols bgp group 65000 {     type internal;     local-address 10.0.3.3;     export ibgp;      neighbor 10.0.6.1; } 

After committing the changes to r1 and r3, we expect to see that an IBGP session is established, and that each router advertises its 192.168.x/24 static route to its peer:

[edit] lab@r3# run show bgp summary Groups: 1 Peers: 1 Down peers: 0 Table          Tot Paths  Act Paths Suppressed    History Damp State     Pending inet.0                 1          1          0          0          0           0 Peer               AS      InPkt     OutPkt    OutQ   Flaps Last Up/Dwn  State|#Active/Received/Damped... 10.0.6.1        65000          7          8       0       0        2:11 1/1/0                 0/0/0 [edit] lab@r3# run show route protocol bgp inet.0: 27 destinations, 27 routes (27 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 192.168.10.0/24    *[BGP/170] 00:02:16, MED 0, localpref 100, from 10.0.6.1                       AS path: I                     > to 10.0.4.14 via fe-0/0/0.0 iso.0: 1 destinations, 1 routes (1 active, 0 holddown, 0 hidden) 

The establishment of the r1-r3 IBGP session and the presence of the IBGP-learned route provides an indication that all is well with subconfederation 65000. We will worry about bringing up the C-BGP links once subconfederations 65001 and 65002 are also operational.

Configure Subconfederations 65001 and 65002

The configuration needed by r2 to function as a member of subconfederation 65001 is shown here with changes highlighted:

[edit] lab@r2# show routing-options static {    route 10.0.200.0/24 next-hop 10.0.1.102;    route 192.168.20.0/24 reject;  }  autonomous-system 65001; confederation 65412 members [ 65000 65001 65002 ]; [edit] lab@r2# show protocols bgp group 65001 {    type internal;    local-address 10.0.6.2;    export ibgp;    neighbor 10.0.3.4;  } 

The configuration of r4 is similar to those of r2 and r3. The completed configuration for r4 is shown here with highlights:

[edit] lab@r4# show routing-options static { static {     route 10.0.200.0/24 next-hop 10.0.1.102;     route 192.168.40.0/24 reject; } aggregate {      route 10.0.4.0/22; } autonomous-system 65001; confederation 65412 members [ 65000 65001 65002 ]; [edit] lab@r4# show protocols bgp group 65001 {     type internal;     local-address 10.0.3.4;     export ibgp;      neighbor 10.0.6.2; } 

As before, you expect to see a single IBGP session established between r2 and r4 when you have committed the changes on both routers:

[edit] lab@r4# run show bgp summary Groups: 1 Peers: 1 Down peers: 0 Table          Tot Paths  Act Paths Suppressed    History Damp State     Pending inet.0                 1          1          0          0          0           0 Peer               AS      InPkt     OutPkt    OutQ   Flaps Last Up/Dwn  State|#Active/Received/Damped... 10.0.6.2        65001         13         15       0       0        5:36 1/1/0                 0/0/0 [edit] lab@r4# run show route protocol bgp inet.0: 28 destinations, 28 routes (28 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 192.168.20.0/24    *[BGP/170] 00:05:41, MED 0, localpref 100, from 10.0.6.2                       AS path: I                     > to 10.0.4.10 via fe-0/0/1.0      iso.0: 1 destinations, 1 routes (1 active, 0 holddown, 0 hidden) 

Results like these indicate that subconfederation 65001 is also working properly. Routers in subconfederation 65002 will require the same type of configuration changes. The highlighted configuration changes shown here are from r5:

[edit] lab@r5# show routing-options static {     route 10.0.200.0/24 next-hop 10.0.1.102;     route 192.168.50.0/24 reject; } aggregate {      route 10.0.2.0/23;      route 10.0.8.0/21;      route 192.168.0.0/22;      route 172.16.40.0/29; }  autonomous-system 65002; confederation 65412 members [ 65000 65001 65002 ]; [edit] lab@r5# show protocols bgp group 65002 {    type internal;    local-address 10.0.3.5;    export ibgp;    neighbor 10.0.9.6;    neighbor 10.0.9.7;  } 

The primary difference between the configuration of r5 compared to that of r3 or r4 is the need for you to define two internal peers in the form of r6 and r7. When similar confederation- related configuration changes have been committed in r6 and r7, we expect to see two IBGP sessions in the established state on each router in subconfederation 65002, as shown next:

 [edit] lab@r5# run show bgp summary Groups: 1 Peers: 2 Down peers: 0 Table          Tot Paths  Act Paths Suppressed    History Damp State     Pending inet.0                 2          2          0          0          0           0 Peer               AS      InPkt     OutPkt    OutQ   Flaps Last Up/Dwn  State|#Active/Received/Damped... 10.0.9.6        65002          4          6       0       0        1:18 1/1/0 0/0/0 10.0.9.7        65002          3          4       0       0          35 1/1/0 0/0/0 [edit] lab@r5# run show route protocol bgp inet.0: 33 destinations, 33 routes (33 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 192.168.60.0/24     *[BGP/170] 00:01:24, MED 0, localpref 100, from 10.0.9.6                       AS path: I                     > to 10.0.8.5 via fe-0/0/0.0 192.168.70.0/24     *[BGP/170] 00:00:41, MED 0, localpref 100, from 10.0.9.7                       AS path: I                          > to 10.0.8.10 via fe-0/0/1.0

Configure C-BGP Links

With each subconfederation operational, it is time to link them together using C-BGP, which, as mentioned previously, is a special type of EBGP. The tricky part here is the need to enable the multihop option on the C-BGP peering sessions to support the loopback-based peering required in this example. The multihop option is needed here because EBGP will only peer over a directly connected interface (by setting the IP packet's TTL to 1) by default.

The next set of commands creates a c-bgp group on r5, and correctly configures this group to peer with r3 and r4:

[edit protocols bgp group c-bgp] lab@r5# set type external local-address 10.0.3.5 [edit protocols bgp group c-bgp] lab@r5# set neighbor 10.0.3.3 [edit protocols bgp group c-bgp] lab@r5# set neighbor 10.0.3.3 peer-as 65000 [edit protocols bgp group c-bgp] lab@r5# set neighbor 10.0.3.4  [edit protocols bgp group c-bgp] lab@r5# set neighbor 10.0.3.4 peer-as 65001 [edit protocols bgp group c-bgp] lab@r5# set multihop 

The c-bgp group differs from previous examples in this section in that the group's type needs to be set to external. Peers listed in an external peer group require an association with the remote peer's AS number. When the router recognizes that peers in AS 65000 and 65001 are members of its own confederation, it will modify its EBGP behavior so as to adhere to confederation EBGP (C-BGP) protocol behavior.

You now apply the ibgp export policy so that r5 will advertise its 192.168.50/24 static route to members of the c-bgp group using its C-BGP session:

[edit protocols bgp group c-bgp] lab@r5# set export ibgp 

The completed C-BGP-related configuration for r5 is shown next:

[edit protocols bgp group c-bgp] lab@r5# show type external; multihop; local-address 10.0.3.5; export ibgp; neighbor 10.0.3.3 {    peer-as 65000;  }  neighbor 10.0.3.4 {    peer-as 65001;  }

Remote peer AS numbers can be specified at the global, group, or neighbor levels as desired. The use of neighbor-level peer-as definitions allows you to have a single BGP peer group that supports EBGP peering sessions with remote peers that belong to different ASs. To complete the configuration of the C-BGP links, you need to configure a similar peer group on r3 and r4 using the same commands shown for r5. The c-bgp group configuration for r3 is shown here for reference:

[edit] lab@r3# show protocols bgp group c-bgp type external; multihop; local-address 10.0.3.3; export ibgp; neighbor 10.0.3.4 {    peer-as 65001;  } neighbor 10.0.3.5 {    peer-as 65002;  } 

Verify Confederation Operation

The following commands are used to verify your confederation topology. We start by verifying that all BGP sessions have been correctly established. Based on the topology shown earlier in Figure 5.4, we expect that r3 will have three BGP sessions, one running IBGP and the other two running C-BGP:

[edit] lab@r3# run show bgp summary Groups: 2 Peers: 3 Down peers: 0 Table          Tot Paths  Act Paths Suppressed    History Damp State     Pending inet.0                 6          6          0          0          0           0 Peer               AS      InPkt     OutPkt    OutQ   Flaps Last Up/Dwn  State|#Active/Received/Damped... 10.0.3.4        65001        111        112       0       0       48:20 2/2/0 0/0/0 10.0.3.5        65002        114        111       0       0       48:16 3/3/0 0/0/0      10.0.6.1        65000         23         29       0       3       10:15 1/1/0                 0/0/0

The output confirms that r3 has the expected number of BGP sessions and that they have all been correctly established. Though not shown, you should issue the same command on all routers in the test bed to verify that each shows the expected number of sessions, and that the sessions are all in the established state. You now confirm that no routes have been lost due to the deployment of your confederation, beginning with r1:

[edit] lab@r1# run show route protocol bgp 192/8 | match 192.168 | count Count: 6 lines 

The output once again confirms that r1 has learned six 192.168-related prefixes through the BGP protocol. Considering that there are six other routers in the test bed, and that they should all be sending a single 192.168.x/24 static route through a combination of IBGP and C-BGP, these results confirm that r1's ability to route to these destinations has not been impacted by the deployment of your confederation. The same command is now issued on a few other routers; it is recommended that you test all routers before deciding your network is healthy:

[edit] lab@r5# run show route protocol bgp 192/8 | match 192.168 | count Count: 6 lines

Good, r5 also displayed the expected number of BGP-learned routes. The same command is now issued on r7:

lab@r7# run show route protocol bgp 192/8 | match 192.168 | count Count: 6 lines

Great-all routers are displaying the expected number of BGP routes. You now confirm that forwarding paths are optimal or, at the very least, that your forwarding paths have not been negatively impacted by your confederation design. You start by analyzing r2's view of the routes owned by subconfederation 65002:

[edit] lab@r2# run show route protocol bgp 192.168.60/24 inet.0: 22 destinations, 22 routes (22 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 192.168.60.0/24    *[BGP/170] 01:13:58, MED 0, localpref 100, from 10.0.3.4                       AS path: (65000 65002) I                        to 10.0.4.9 via fe-0/0/1.0                      > to 10.0.4.1 via fe-0/0/2.0 

It would seem that r2 has learned the 192.168.60/24 route from BGP speaker 10.0.3.4 (r3), which provides the C-BGP connectivity for subconfederation 65001. The use of IS-IS level 1 routing results in r2 believing there are two equal-cost paths that can be used to reach r4's loop- back address. In reality, the 10.0.4.9 forwarding path is shorter than having r2 forward through r3 via 10.0.4.1. r2's misconception is the result of Multi-Level IS-IS operation, so this output does not indicate a problem with your confederation design.

You may find it odd that the AS path sequence lists the AS numbers associated with subconfederations 65000 and 65002, because this implies that r4 has learned the route through r3 instead of r5, which may seem counterintuitive. This warrants additional investigation, so you move over to r4 and issue the same command:

[edit] lab@r4# run show route 192.168.70/24 inet.0: 29 destinations, 34 routes (29 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 192.168.70.0/24     *[BGP/170] 00:00:27, MED 0, localpref 100, from 10.0.3.3                       AS path: (65000 65002) I                      > to 10.0.2.9 via as0.0                      [BGP/170] 00:00:23, MED 0, localpref 100, from 10.0.3.5                       AS path: (65002) I                      > to 10.0.2.9 via as0.0 

Very interesting: r4 indicates that it has learned the route from both r3 and r5, and has selected the advertisement that was learned from r3 as the active route. Forwarding packets through r3 to reach r5 would be less than ideal with this topology, especially because the IS-IS level 2 backbone is not reliant on a default route. Careful inspection of the display indicates that the forwarding next hop will be 10.0.2.9 via r4's as0 interface, which indicates that regardless of which route was chosen as active, the forwarding path will be from r4 to r5, which is as optimal as you can get. But wait, how can r4 install the route learned from r3 with the intent of forwarding through r5?

The answer lies in understanding BGP's use of the advertising router, protocol next hop, and forwarding next-hop fields. The advertising router is just that-the router ID of the BGP speaker that has advertised the route. The protocol next hop identifies the router to which packets should be forwarded if the route is considered best and becomes active. BGP's support of third-party next hops means that the advertising router and protocol next hops need not be the same. The forwarding next hop is the result of the recursive lookup of the protocol next hop, and therefore indicates the preferred IGP next hop that is used to forward toward the advertised protocol next hop. The various next hops used by BGP are highlighted in this capture:

[edit] lab@r4# run show route 192.168.70/24 detail inet.0: 29 destinations, 34 routes (29 active, 0 holddown, 0 hidden) 192.168.70.0/24 (2 entries, 1 announced)          *BGP Preference: 170/-101               Source: 10.0.3.3               Nexthop: 10.0.2.9 via as0.0, selected               Protocol Nexthop: 10.0.9.7 Indirect nexthop: 83e93b8 57               State: <Active Int Ext>               Local AS: 65001 Peer AS: 65000               Age: 5:02 Metric: 0 Metric2: 11               Task: BGP_65000.10.0.3.3+179               Announcement bits (3): 0-KRT 4-BGP.0.0.0.0+179 5-Resolve inet.0               AS path: (65000 65002) I               Localpref: 100               Router ID: 10.0.3.3           BGP Preference: 170/-101               Source: 10.0.3.5               Nexthop: 10.0.2.9 via as0.0, selected               Protocol Nexthop: 10.0.9.7 Indirect nexthop: 83e93b8 57               State: <NotBest Int Ext>               Inactive reason: Router ID               Local AS: 65001 Peer AS: 65002               Age: 4:58 Metric: 0 Metric2: 11               Task: BGP_65002.10.0.3.5+179               AS path: (65002) I               Localpref: 100               Router ID: 10.0.3.5 

The use of C-BGP on the EBGP links connecting r3, r4, and r5 results in a modified EBGP behavior that preserves the original protocol next hop in the route updates sent over the C-BGP sessions. Because the protocol next hop is the same (10.0.9.7) in the advertisements generated by both r3 and r4, and because the IGP resolves this route to a forwarding next hop of 10.0.2.9, it makes no difference whether r4 chooses the route advertised by r3 over the route being advertised by r5. The previous capture also indicates why r3's advertisement was selected as the active route. The active route selection process outcome has been decided by choosing the speaker with the lowest RID value because all other aspects of the route's attributes are otherwise equal.

A traceroute issued at both r4 and r3 confirms optimal forwarding over the IS-IS level 2 backbone to destinations in subconfederation 65002:

[edit] lab@r4# run traceroute 192.168.70.1 traceroute to 192.168.70.1 (192.168.70.1), 30 hops max, 40 byte packets  1 10.0.2.9 (10.0.2.9) 0.761 ms 0.614 ms 0.507 ms  2 10.0.8.10 (10.0.8.10) 0.447 ms 0.441 ms 0.415 ms  3 10.0.8.10 (10.0.8.10) 0.426 ms !H 0.436 ms !H 0.419 ms !H

r4's path is optimal so you check up on r3's forwarding path:

[edit] lab@r3# run traceroute 192.168.70.1 traceroute to 192.168.70.1 (192.168.70.1), 30 hops max, 40 byte packets  1 10.0.2.1 (10.0.2.1) 1.082 ms 1.138 ms 0.994 ms  2 10.0.8.10 (10.0.8.10) 1.004 ms 0.771 ms 1.112 ms  3 10.0.8.10 (10.0.8.10) 1.041 ms !H 0.963 ms !H 1.096 ms !H

These results indicate that forwarding paths have not been impacted by your confederation topology. However, the use of IS-IS level 1 routing can cause routers in area 49.0002 to make a less-than-ideal choice with regard to which attached router they install as the forwarding next hop for their default routes.

Nothing Is Perfect…

While developing this section, this author observed that both r4 and r5 were incorrectly computing an IS-IS metric of 10 for their aggregated SONET interfaces after a reboot (recall that the previous IS-IS case study had the metric automatically calculated based on a 500Mbps bandwidth). The higher metric setting was in turn causing r4 to forward packets destined for r5, r6, and r7 through r3, which is a suboptimal path. This condition is shown next, where the route to r7's loopback address is examined on r4:

[edit] lab@r4# run show route 10.0.9.7 inet.0: 29 destinations, 34 routes (29 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 10.0.8.0/21         *[IS-IS/165] 01:55:34, metric 16, tag 2                       > to 10.0.2.5 via so-0/1/0.100 [edit] lab@r4# run show isis interface IS-IS interface database: Interface             L CirID Level 1 DR        Level 2 DR        L1/L2 Metric as0.0                 2   0x1 Disabled          Point to Point         10/10 fe-0/0/1.0            1   0x2 r2.02             Disabled                5/5 lo0.0                 0   0x1 Disabled          Passive                 0/0 so-0/1/0.100          2   0x1 Disabled          Point to Point          3/3

After observing the anomaly, this author tried bouncing the as0 interface by deactivating and reactivating it, but the problem persisted. After confirming that the IS-IS stanza had not changed, and that the interface still displayed a speed of 311,040Kbps (a minimum of two OC-3 interfaces are required in the aggregated bundle), a routing daemon restart was performed and the problem was cleared:

[edit] lab@r4# run restart routing Routing protocol daemon started, pid 725 [edit] lab@r4# run show isis interface IS-IS interface database: Interface             L CirID Level 1 DR        Level 2 DR        L1/L2 Metric as0.0                 2   0x1 Disabled          Point to Point          1/1 fe-0/0/1.0            1   0x2 0000.0000.0000.02 Disabled                5/5 lo0.0                 0   0x1 Disabled          Passive                 0/0 so-0/1/0.100          2   0x1 Disabled          Point to Point          3/3

The moral to this story is that nothing is perfect, and routers, being the complex systems that they are, provide no exception to this rule. A JNCIP exam candidate is expected to know that 'stuff happens,' and to be able to perform daemon restart and router reboots when operational anomalies are encountered. This particular issue was reproducible, and further investigation confirmed that a Problem Report (PR) had already been filed to correct the problem.

Restart Selectively to Minimize Disruption

Rather than restarting the whole routing daemon, which restarts all routing protocols, you will normally get a faster recovery (and less network disruption) if you can restart just the protocol that is misbehaving. This approach is demonstrated next:

[edit] lab@r4# run show isis interface IS-IS interface database: Interface             L CirID Level 1 DR        Level 2 DR        L1/L2 Metric as0.0                 2   0x1 Disabled          Point to Point         10/10 fe-0/0/1.0            1   0x2 r2.02             Disabled                5/5 lo0.0                 0   0x1 Disabled          Passive                 0/0 so-0/1/0.100          2   0x1 Disabled          Point to Point          3/3 [edit] lab@r4# deactivate protocols isis [edit] lab@r4# commit commit complete [edit] lab@r4# rollback 1 load complete [edit] lab@r4# commit commit complete [edit] lab@r4# run show isis interface IS-IS interface database: Interface             L CirID Level 1 DR        Level 2 DR        L1/L2 Metric as0.0                 2   0x1 Disabled          Point to Point          1/1 fe-0/0/1.0            1   0x2 0000.0000.0000.02 Disabled                5/5 lo0.0                 0   0x1 Disabled          Passive                 0/0 so-0/1/0.100          2   0x1 Disabled          Point to Point          3/3

As with the route reflection example, you may want to deactivate a few strategic interfaces to confirm that the network fails over to an optimal path, as determined by the remaining links. In this example, you once again deactivate r3's ATM interface to verify that it correctly begins forwarding through r4 when routing to subconfederation 65002 destinations:

[edit] lab@r3# run traceroute 192.168.70.1 traceroute to 192.168.70.1 (192.168.70.1), 30 hops max, 40 byte packets  1 10.0.2.6 (10.0.2.6) 0.684 ms 0.542 ms 0.494 ms  2 10.0.2.9 (10.0.2.9) 0.579 ms 9.033 ms 0.533 ms  3 10.0.8.10 (10.0.8.10) 0.449 ms 0.449 ms 0.430 ms  4 10.0.8.10 (10.0.8.10) 0.441 ms !H 0.455 ms !H 0.431  ms !H

With the r3-r5 ATM link down, r3 forwards through r4 as expected, so it looks like r3 has chosen the best of the remaining paths, which in the end is all you can really ask of a router's control plane. After activating the ATM interface on r5, you quickly verify forwarding from r6 to subconfederation 65000 destinations:

lab@r6> traceroute 192.168.10.1 traceroute to 192.168.10.1 (192.168.10.1), 30 hops max, 40 byte packets  1 10.0.8.6 (10.0.8.6) 0.345 ms 0.290 ms 0.234 ms  2 10.0.2.10 (10.0.2.10) 0.286 ms 0.259 ms 0.243 ms  3 10.0.4.10 (10.0.4.10) 0.175 ms 0.170 ms 0.156 ms  4 10.0.4.5 (10.0.4.5) 0.552 ms 0.690 ms 0.378 ms  5 10.0.4.5 (10.0.4.5) 0.361 ms !H 0.685 ms !H 0.375 ms !H

All seems perfect until r5 hands the packet to r4 at hop 2, because this decision results in extra router hops for the packet. A look at r5's routing table confirms that it forwards through r4 when attempting to reach all destinations in the level 1 area 49.0002.

 [edit] lab@r5# run show route 10.0.4/22 inet.0: 32 destinations, 36 routes (30 active, 0 holddown, 2 hidden) + = Active Route, - = Last Active, * = Both 10.0.4.0/22        *[IS-IS/165] 00:16:42, metric 11, tag 2                      > to 10.0.2.10 via as1.0 10.0.5.0/24        *[IS-IS/18] 00:16:42, metric 64, tag 2                      > to 10.0.2.10 via as1.0

As pointed out in Chapter 4, this condition is the result of a lower interface metric on the r4-r5 aggregated SONET interface, which causes r5 to prefer the summary route advertised by r4 over the same route as advertised by r3. The metric value of 11 would indicate that the summary route is injected into the level 2 backbone with a metric of 10 (which is the default), because the aggregated SONET link is known to have an automatically computed IS-IS metric of 1. Downing the aggregated link and comparing the new route metric, which should be 10 + 3, or 13, confirms that it is "normal" IS-IS behavior, and not your confederation design, that is to blame for the extra hops in this example:

[edit] lab@r5# run show route 10.0.4/22 inet.0: 30 destinations, 34 routes (28 active, 0 holddown, 2 hidden) + = Active Route, - = Last Active, * = Both 10.0.4.0/22        *[IS-IS/165] 00:00:04, metric 13, tag 2                      > to 10.0.2.2 via at-0/2/1.35 10.0.5.0/24        *[IS-IS/18] 00:00:04, metric 66, tag 2                      > to 10.0.2.2 via at-0/2/1.35

Your confederation is working perfectly, so after activating r5's as1 aggregated SONET interface, you should congratulate yourself for a job well done!

Save Confederation Configuration

The working confederation configurations on all routers should now be saved for use in Chapter 6, 'EBGP Configuration and Testing.' The save command demonstrated next should be issued at the [edit] hierarchy on r1 through r7; make sure you take note of the specific filename used for easy restoration in the future:

[edit] lab@r4# save confed-r4 Wrote 267 lines of configuration to 'confed-r4'