|
|
Traffic engineering refers generally to the process of directing or influencing traffic flows across a network. It is important to remember that traditional IP routing decisions are performed router by router and are destination-based. That is, each router along a path to a destination individually examines the destination address of a particular packet and independently decides where to forward the packet next. Because of this behavior, the options for deterministically influencing traffic from source to destination are few.
Two high-level tools available are the ability to influence the content of routing tables and the ability to vary the value of link metrics. With these two tools, it is possible to achieve what is known as a coarse grain degree of traffic engineering. That is, when we make a modification, we tend to modify the traffic patterns of all traffic, versus a select amount of traffic. Fine grain traffic engineering has recently become possible using the tools available in the MPLS protocol suite.
The following sections cover some of the options available within ISIS to control the flow of traffic in the ISIS domain.
Digging deeper into Link State RoutingFor those interested in the mathematical algorithms and constructs that are used in a link state routing implementation, reseach into graph theory and particularly weighted digraphs should prove fruitful. William Stallings in "High Speed Networks: TCP/IP and ATM Design Principles" provides a brief, yet concise overview of these topics toward the end of his book. |
Recall that ISIS routers build routing tables based on the contents of the link state database. Specifically, routers within the same area build a graph of the areas topology and subsequently run the Dijkstra algorithm to calculate the shortest path to each other router in the area. Path length in ISIS is determined by the sum of the composite link metrics from source to destination. Thus, by modifying the values of the various link metrics, one can influence the path selection.
ISIS was originally designed with 4 bytes of metric space for each prefix advertised. This space was divided into four individual sections to describe four different types of metric. However, as discussed in "ISIS Part I," only the default metric was ever used in production ISIS implementations. As seen in Figure 8, 3 full bytes of the metric field remain unused. Further, the high order bit, bit 8 has been reserved for future use, and the 7th bit is used to indicate whether a prefix is internal or external. That leaves only 6 bits out of 32 for use as a metric, yielding a range from 0 through 63. As you can imagine, this lack of space does not provide a tremendous amount of flexibility for metric manipulation.
Figure 8. The ISIS Metric Field
When configuring normal metrics, notice the range of available values provided in the following configuration snippet.
R1(config)#int eth0 R1(config-if)#isis metric ? <0-63> Default metric
As you would expect, link metrics are configured at the interface level of the command hierarchy.
The folks in the IETF realized that both the small size of the ISIS metric and the amount of wasted bits in the TLV created a serious limitation and, while enabling ISIS to carry traffic engineering information in a new TLV, Tony Li and Henk Smit also remedied the metric issue. Specifically, ISIS Extensions for Traffic Engineering, defines a new TLV for carrying IP prefix reachability information. This new TLV, Extended IP Reachability Type 135, dedicates 4 bytes in total for use as a metric. This new metric is often called a wide metric vs. the previous narrow metric.
Figure 9 displays the old-style and the new-style TLV structures and their related metric spaces. As far as I can tell, Cisco began to support the use of Wide Metrics and, moreover, the communication of IP reachability with extended TLVs, in about IOS 12.0.7(T).
Figure 9. Old- and New-style TLVs
Use of wide metrics can be configured per level. For example, one can use wide metrics in the backbone of a network and narrow metrics in an area. Or, more realistically, one can have a number of L1 areas where certain areas run narrow metrics and others run wide metrics. This can be useful when supporting a migration to the newer metric style.
The command to enable wide metrics exists at the router configuration level. Specifically, under router isis, one can set the metric style using:
R1#(config-router) metric-style wide ...
[Level-1 | Level-1-2 | Level-2]
As we will see when examining route leaking, the metric style command unlocks some interesting dependencies. Specifically, it is key to enabling the use of Type 135 TLVs, which are necessary to support the flow of prefix reachability downward from the L2 backbone into L1 areas.
Notice the rather dramatic change in the metric range on a router with wide metrics enabled:
R3(config-if)#isis metric ? <0-16777215> Default metric
One must ensure that, when wide metrics are enabled for a Level, all the routers within the area support the metrics. Note that the previous TLVs, 128/130, are still transmitted within the LSP to enable backwards compatibility. It is worth noting that when enabling wide metrics, Cisco uses only 3 bytes of the available 4. The 3 bytes provide the above value of 224, and are populated in the previously unused space in the TLV such that routers not able to properly decode them will safely ignore their presence.
Default routes can play an important role in many networks in a variety of ways. In the ISIS domain, you may recall that routes are set by L1 routers toward L1/L2 routers whose L1 LSP indicates connectivity to the backbone by setting the ATT bit. This dynamic provisioning of a gateway of last resort is a very useful tool. The general idea is to direct traffic toward more informed information sources. In the L1/L2 example, the L1/L2 router has complete awareness of the L2 backbone and thereby knowledge of the rest of the ISIS domain, whereas the L1 area routers understand only their local area. Hence, it is natural to bring traffic destined outside of the area to the L1/L2 router as it most likely has more specific information about where to deliver that traffic.
However, provisioning default in the backbone can also be a useful tool. For example, it may prove beneficial in a service provider network to provide default routing toward AS border routers so that packets destined for unknown destinations exit the AS as soon as possible. Further, should certain areas of the service provider network contain routers that do not participate in the iBGP mesh, it may prove wise to provide default toward the mesh so that traffic quickly flows toward a more informed source. In all, there are many potential benefits to injecting a default route into the L2 domain.
Fortunately, it is not a difficult function to enable. Consider our lab network and specifically the routing table of R3 as shown below.
Table 9. R3's Routing Table without a Gateway of Last Resort
Gateway of last resort is not set
1.0.0.0/32 is subnetted, 4 subnets
i L2 1.0.0.1 [115/30] via 10.20.0.1, Ethernet0
C 1.0.0.3 is directly connected, Loopback0
i L2 1.0.0.2 [115/20] via 10.20.0.1, Ethernet0
i L1 1.0.0.4 [115/20] via 10.30.0.2, Serial0
10.0.0.0/8 is variably subnetted, 5 subnets, 2 masks
i L2 10.0.0.0/24 [115/20] via 10.20.0.1, Ethernet0
i L2 10.0.0.1/32 [115/20] via 10.20.0.1, Ethernet0
C 10.30.0.0/24 is directly connected, Serial0
C 10.30.0.2/32 is directly connected, Serial0
C 10.20.0.0/24 is directly connected, Ethernet0
R3#
Notice that R3 currently does not have a gateway of last resort. By adding a static route to null0 on R2 and entering the command default-information originate under the router ISIS process, R2 will then add a default route to its L2 LSP that R3 can then publish as its gateway of last resort. See Figure 10.
Figure 10. Originating Default
Here are the relevant aspects of R2's new configuration.
Table 10. R2 Configured to Originate Default
router isis
default-information originate
net 49.0001.0000.0000.0002.00
!
ip route 0.0.0.0 0.0.0.0 null0
Finally, here is the new routing table on R3 including the gateway of last resort.
Table 11. R3's Routing Table with a Gateway of Last Resort
Gateway of last resort is 10.20.0.1 to network 0.0.0.0 1.0.0.0/32 is subnetted, 2 subnets C 1.0.0.3 is directly connected, Loopback0 i L2 1.0.0.2 [115/20] via 10.20.0.1, Ethernet0 10.0.0.0/8 is variably subnetted, 5 subnets, 2 masks i L2 10.0.0.0/24 [115/20] via 10.20.0.1, Ethernet0 i L2 10.0.0.1/32 [115/20] via 10.20.0.1, Ethernet0 C 10.30.0.0/24 is directly connected, Serial0 C 10.30.0.2/32 is directly connected, Serial0 C 10.20.0.0/24 is directly connected, Ethernet0 i*L2 0.0.0.0/0 [115/10] via 10.20.0.1, Ethernet0 R3#
As I've mentioned previously, the inability to offer any more information than a simple default route to L1 areas proved a serious impediment to two-level ISIS networks. The lack of granular information, or even network summary information, left L1 only routers with very little detail from which to make informed routing decisions.
RFC 2966, Domain-wide Prefix Distribution, remedied this situation by creating the ability for L1/L2 routers to advertise all or a subset of the L2 topology downward into L1 areas. This RFC allowed ISIS networks the benefit of bounded LSP flooding along with the ability not to compromise the accuracy and granularity of reachability information.
On a more specific note, RFC 2966 actually describes route leaking using narrow metrics in TLVs 128 and 130, while the draft ISIS Extensions for Traffic Engineering extends this ability for TLV 135.
HintFor the adventurous, if you do chose to try to leak routes with narrow metrics, you will need to use an IOS from the T train, of at least 12.0 vintage. |
Route leaking with narrow metrics can be a grief-inducing process. The key issue for implementers lies in the selection of metric bits to steal for use as the up/down bit. As described previously, the up/down bit provides loop mitigation capabilities by indicating whether prefixes have already leaked downward and thus shouldn't be reintroduced into the backbone. Most implementations using narrow metrics can be vary problematic due to the various work-around solutions that implementers have chosen to enable this functionality. For these reasons, it is highly recommended that one enable wide metric support when endeavoring to leak routes. As indicated in Figure 9, the TLV 135 has a separate, well-identified and unambiguous up/down bit.
Route leaking can be accomplished using the redistribute command. In essence, one redistributes the L2 reachability into the L1 area. Of note, a mandatory distribute list is required to filter this redistribution. In most cases, one would not redistribute the entire L2 topology into an L1 area. However, for the purposes of building up this theory, let's have a look at how that would be accomplished.
Consider again the tutorial topology and specifically the routing tables of R1 and R2.
Table 12. R1's Routing Table
Gateway of last resort is 10.0.0.2 to network 0.0.0.0
1.0.0.0/32 is subnetted, 2 subnets
C 1.0.0.1 is directly connected, Loopback0
i L1 1.0.0.2 [115/20] via 10.0.0.2, Serial0
10.0.0.0/8 is variably subnetted, 3 subnets, 2 masks
C 10.0.0.2/32 is directly connected, Serial0
C 10.0.0.0/24 is directly connected, Serial0
i L1 10.20.0.0/24 [115/20] via 10.0.0.2, Serial0
i*L1 0.0.0.0/0 [115/10] via 10.0.0.2, Serial0
Table 13. R2's Routing Table
Gateway of last resort is 0.0.0.0 to network 0.0.0.0
1.0.0.0/32 is subnetted, 3 subnets
i L1 1.0.0.1 [115/20] via 10.0.0.1, Serial1
i L2 1.0.0.3 [115/20] via 10.20.0.2, Ethernet0
C 1.0.0.2 is directly connected, Loopback0
10.0.0.0/8 is variably subnetted, 5 subnets, 2 masks
C 10.0.0.0/24 is directly connected, Serial1
C 10.0.0.1/32 is directly connected, Serial1
i L2 10.30.0.0/24 [115/20] via 10.20.0.2, Ethernet0
i L2 10.30.0.2/32 [115/20] via 10.20.0.2, Ethernet0
C 10.20.0.0/24 is directly connected, Ethernet0
Notice that R2 has three L2 routes that are not currently present in R1's table. Hence, for R1 to reach those networks, it would be forced to use its default route. The following configuration enables R2 to leak those L2 routes downward toward R1 as shown in Figure 11.
Figure 11. R2 Leaks
Table 14. R2 Configuration for Route Leaking
router isis redistribute isis ip level-2 into level-1 distribute-list 100 net 49.0001.0000.0000.0002.00 metric-style wide ! access-list 100 permit ip any any
As you can see, the redistribute command has been bolstered with a few new options. The ip keyword instructs ISIS to redistribute IP prefixes instead of CLNP prefixes since ISIS is a capable CLNP routing protocol. The level-2 keyword selects only those routes that are Level 2 and can be replaced with either level-1 or level-1-2. Of note, these latter options are more relevant for the redistribution of ISIS into other protocols. The into command indicates a target for redistribution. This keyword could potentially be used for redistributing one ISIS domain into another, for example. Finally, the distribute-list points to an extended IP access-list that is used to filter the set of candidate prefixes prior to redistribution. In this example, we are permitting all L2-learned prefixes to be leaked downward. Notice the new routing table on R1 after this feature has been implemented.
Table 15. R1's Routing Table -- With L2 Leaked Routes
Gateway of last resort is 10.0.0.2 to network 0.0.0.0
1.0.0.0/32 is subnetted, 3 subnets
C 1.0.0.1 is directly connected, Loopback0
i ia 1.0.0.3 [115/30] via 10.0.0.2, Serial0
i L1 1.0.0.2 [115/20] via 10.0.0.2, Serial0
10.0.0.0/8 is variably subnetted, 5 subnets, 2 masks
C 10.0.0.2/32 is directly connected, Serial0
C 10.0.0.0/24 is directly connected, Serial0
i ia 10.30.0.0/24 [115/30] via 10.0.0.2, Serial0
i ia 10.30.0.2/32 [115/30] via 10.0.0.2, Serial0
i L1 10.20.0.0/24 [115/20] via 10.0.0.2, Serial0
i*L1 0.0.0.0/0 [115/10] via 10.0.0.2, Serial0
R1#
As you can see, all three L2 routes from R2 have been successfully leaked to L1. Also note that the metric has been preserved and properly incremented by the additional link cost from R2 to R1. It is interesting to note as well that these newly leaked routes carry the ia marker to indicate that they are indeed, intra-area routes.
To take this a step closer to reality, consider again the service provider who maintains a full iBGP mesh between all of its routers. Although there is no real need for each router to maintain accurate metrics toward various interior links, it is critical that every router has accurate reachability information for the BGP Next_Hop addresses associated with the various BGP paths. These Next_Hop addresses are usually set to the loopback addresses of the various AS Border routers.
Assume that R3 in our tutorial network is an AS Border router and that R1 has a number of BGP paths for which 1.0.0.3 is the BGP Next_Hop. Prior to leaking routes, R1 would not have an accurate idea of the best path toward R3, nor would it know the cost of that path. However, leaking the entire L2 backbone including the interior link 10.30/24 and R2's associated interface 10.30.0.2/32 serves no purpose and, in fact, forces R1 to uselessly track more information. In this case the ideal solution involves leaking only the loopback address of R3 toward R1. This can be achieved with a simple modification of the distribute list as follows:
access-list 100 permit ip 1.0.0.0 0.0.0.255 any
This command, in fact, leaks all routes that match the 1/24 subnet, which would usually be the desired effect in a well-designed service provider network where the loopback addresses are pulled from a contiguous block of address space. This access-list modification yields the correct result on R1 as evidenced in the below capture of R1's new routing table.
Table 16. R1's Routing Table Following Constrained Route Leak
Gateway of last resort is 10.0.0.2 to network 0.0.0.0
1.0.0.0/32 is subnetted, 3 subnets
C 1.0.0.1 is directly connected, Loopback0
i ia 1.0.0.3 [115/30] via 10.0.0.2, Serial0
i L1 1.0.0.2 [115/20] via 10.0.0.2, Serial0
10.0.0.0/8 is variably subnetted, 3 subnets, 2 masks
C 10.0.0.2/32 is directly connected, Serial0
C 10.0.0.0/24 is directly connected, Serial0
i L1 10.20.0.0/24 [115/20] via 10.0.0.2, Serial0
i*L1 0.0.0.0/0 [115/10] via 10.0.0.2, Serial0
R1#
This technique has been an essential modification to the ISIS algorithm that has enabled ISIS networks to take full advantage of two-tiered topologies.
As with all routing implementations, the ability to summarize groups of prefixes into aggregates to control the size of routing tables is essential. Similar to OSPF, ISIS provides this ability at Level borders, which manifest themselves as L1/L2 routers. Keep in mind that the need to maintain synchronization of link state databases, both in L1 areas and across the L2 backbone, eliminates the possibility for summarization within those areas. Due to this characteristic of link state protocols in general, one of the key reasons to implement a two-tiered ISIS network is to provide the opportunity for address summarization.
Summarization can also take place as information is brought into or out of the ISIS domain. These external, or soon-to-be external, addresses can be grouped together to minimize the amount of routing information needed to convey reachability for a set of contiguous prefixes. External summarization is covered in some detail in the Redistribution section of this tutorial. Further, the principals of route summarization should be well understood by the CCIE candidate but are not covered within this text beyond their related implementation in ISIS.
In an ISIS domain, internal summarization can take place as prefixes are advertised up into the L2 backbone and also as prefixes are leaked downward into L1 areas. The following two sections cover each in some detail.
L1/L2 routers can shield the ISIS domain from a degree of specific information resident in a particular L1 area by summarizing the specific information from that area into a less-specific aggregate. Should a contiguous set of prefixes exist in an L1 area, summarizing these prefixes can minimize the size of the backbone routing tables. Naturally, should there exist two paths into an L1 area, a degree of sub-optimality in path selection might occur since backbone routers may not always chose the best L1/L2 router toward a destination. However, these tradeoffs in routing optimality for smaller routing tables often make sense for many networks.
In order to demonstrate summarization in the tutorial network, I have added a set of contiguous prefixes to R1 as loopback addresses. The following is a snippet of the relevant configuration.
Table 17. Loopback Addresses on R1 to be Summarized
interface Loopback1 ip address 172.16.0.1 255.255.0.0 ip router isis ! interface Loopback2 ip address 172.17.0.1 255.255.0.0 ip router isis ! interface Loopback3 ip address 172.18.0.1 255.255.0.0 ip router isis ! interface Loopback4 ip address 172.19.0.1 255.255.0.0 ip router isis
These routes show up as L1 routes in R2's routing table as you would expect. Here is a look at R2's table.
Table 18. R2's Routing Table
Gateway of last resort is 0.0.0.0 to network 0.0.0.0
1.0.0.0/32 is subnetted, 3 subnets
i L1 1.0.0.1 [115/20] via 10.0.0.1, Serial1
i L2 1.0.0.3 [115/20] via 10.20.0.2, Ethernet0
C 1.0.0.2 is directly connected, Loopback0
i L1 172.17.0.0/16 [115/20] via 10.0.0.1, Serial1
i L1 172.16.0.0/16 [115/20] via 10.0.0.1, Serial1
i L1 172.19.0.0/16 [115/20] via 10.0.0.1, Serial1
i L1 172.18.0.0/16 [115/20] via 10.0.0.1, Serial1
10.0.0.0/8 is variably subnetted, 5 subnets, 2 masks
C 10.0.0.0/24 is directly connected, Serial1
C 10.0.0.1/32 is directly connected, Serial1
i L2 10.30.0.0/24 [115/20] via 10.20.0.2, Ethernet0
i L2 10.30.0.2/32 [115/20] via 10.20.0.2, Ethernet0
C 10.20.0.0/24 is directly connected, Ethernet0
i*L2 0.0.0.0/0 [115/10] via 10.20.0.1, Ethernet0
R2#
As you can see, the four 172.16/14 routes showed up nicely in R2's table. Without summarization, these prefixes would be flooded into the backbone individually. However, since they can be nicely summarized at the /14 boundary, we can minimize both the size of the backbone routing tables and the size of the LSPs necessary to build the link state databases in the backbone by summarizing these before they go into L2 LSPs. This relationship is shown in Figure 12.
Figure 12. L1/L2 Summary
Before we move on, here is a look at R3's routing table prior to summarization.
Table 19. R3's Routing Table Prior to Summarization
Gateway of last resort is 10.20.0.1 to network 0.0.0.0
1.0.0.0/32 is subnetted, 3 subnets
i L2 1.0.0.1 [115/30] via 10.20.0.1, Ethernet0
C 1.0.0.3 is directly connected, Loopback0
i L2 1.0.0.2 [115/20] via 10.20.0.1, Ethernet0
i L2 172.17.0.0/16 [115/30] via 10.20.0.1, Ethernet0
i L2 172.16.0.0/16 [115/30] via 10.20.0.1, Ethernet0
i L2 172.19.0.0/16 [115/30] via 10.20.0.1, Ethernet0
i L2 172.18.0.0/16 [115/30] via 10.20.0.1, Ethernet0
10.0.0.0/8 is variably subnetted, 5 subnets, 2 masks
i L2 10.0.0.0/24 [115/20] via 10.20.0.1, Ethernet0
i L2 10.0.0.1/32 [115/20] via 10.20.0.1, Ethernet0
C 10.30.0.0/24 is directly connected, Serial0
C 10.30.0.2/32 is directly connected, Serial0
C 10.20.0.0/24 is directly connected, Ethernet0
i*L2 0.0.0.0/0 [115/10] via 10.20.0.1, Ethernet0
R3#
In order to summarize the 172.16/14 addresses, the following configuration is added to R2, the L1/L2 router that is introducing these prefixes.
Table 20. Additional Configuration for Summarization
router isis summary-address level-2 172.16.0.0 255.252.0.0 net 49.0001.0000.0000.0002.00 metric-style wide !
Notice that, unlike OSPF, which only uses the summary-address command for externals, ISIS uses it for both internals and externals. The additional keyword level-2, designates that L1 routes being advertised into the L2 backbone will be summarized along with externals being redistributed into the backbone. The impact of the command is reflected in the updated routing table on R3 (see Table 21).
Table 21. R3's Routing Table with Summary Route
Gateway of last resort is 10.20.0.1 to network 0.0.0.0
1.0.0.0/32 is subnetted, 3 subnets
i L2 1.0.0.1 [115/30] via 10.20.0.1, Ethernet0
C 1.0.0.3 is directly connected, Loopback0
i L2 1.0.0.2 [115/20] via 10.20.0.1, Ethernet0
10.0.0.0/8 is variably subnetted, 5 subnets, 2 masks
i L2 10.0.0.0/24 [115/20] via 10.20.0.1, Ethernet0
i L2 10.0.0.1/32 [115/20] via 10.20.0.1, Ethernet0
C 10.30.0.0/24 is directly connected, Serial0
C 10.30.0.2/32 is directly connected, Serial0
C 10.20.0.0/24 is directly connected, Ethernet0
i*L2 0.0.0.0/0 [115/10] via 10.20.0.1, Ethernet0
i L2 172.16.0.0/14 [115/30] via 10.20.0.1, Ethernet0
R3#
As you can see, R3 has properly received the supernet route 172.16/14 in lieu of the four more specific routes as prescribed.
Not only is it possible to leak a specific set of routes from the backbone into an L1 area, it is also possible to summarize a set of routes and leak only the summary into that L1 area. Thus, so long as a single contributing route within the summary exists, an L1/L2 router can offer a single summary route into an L1 area to provide reachability for a number of more specific routes. Doing so becomes somewhat of a compromise between leaking the specific routes themselves into the L1 area and leaking only the default route into the area. This compromise allows L1-resident routes to make more informed decisions toward sets of destinations than they could with simply a default route, yet still shielding them from large amounts of specific routes.
As with summarizing into the backbone, summarizing out of the backbone uses the summary-address command, but this time specifying the level-1 keyword instead of level-2. In order to demonstrate this form of summarization, a group of contiguous static routes have been created on R3 and redistributed plainly into the ISIS domain. The relevant bits of configuration are shown in Figure 13 along with a diagram of the intended functionality.
Figure 13. L1/L2 Summary
R3 Configuration to contribute routes into the backbone router isis redistribute static ip metric 0 net 49.0002.0000.0000.0003.00 metric-style wide ! ip classless ip route 100.0.0.0 255.255.0.0 Null0 ip route 100.1.0.0 255.255.0.0 Null0 ip route 100.2.0.0 255.255.0.0 Null0 ip route 100.3.0.0 255.255.0.0 Null0
As is evident in the following display of R2's routing table, these static routes are being properly introduced into the L2 backbone by R3 within R3's Level 2 LSP.
Table 22. R2's Routing Table after Redistribution
Gateway of last resort is 0.0.0.0 to network 0.0.0.0
1.0.0.0/32 is subnetted, 3 subnets
i L1 1.0.0.1 [115/20] via 10.0.0.1, Serial1
i L2 1.0.0.3 [115/20] via 10.20.0.2, Ethernet0
C 1.0.0.2 is directly connected, Loopback0
100.0.0.0/16 is subnetted, 4 subnets
i L2 100.0.0.0 [115/10] via 10.20.0.2, Ethernet0
i L2 100.1.0.0 [115/10] via 10.20.0.2, Ethernet0
i L2 100.2.0.0 [115/10] via 10.20.0.2, Ethernet0
i L2 100.3.0.0 [115/10] via 10.20.0.2, Ethernet0
10.0.0.0/8 is variably subnetted, 5 subnets, 2 masks
C 10.0.0.0/24 is directly connected, Serial1
C 10.0.0.1/32 is directly connected, Serial1
i L2 10.30.0.0/24 [115/20] via 10.20.0.2, Ethernet0
i L2 10.30.0.2/32 [115/20] via 10.20.0.2, Ethernet0
C 10.20.0.0/24 is directly connected, Ethernet0
S* 0.0.0.0/0 is directly connected, Null0
At this point, R2 is still configured to leak the full set of L2 routes downward from the backbone into area 1. Because of this, R1 quickly sees the full set of 100.0/14 routes as we can see in the routing table in Table 23.
Table 23. R1's Routing Table Prior to Summarization
Gateway of last resort is 10.0.0.2 to network 0.0.0.0
1.0.0.0/32 is subnetted, 3 subnets
C 1.0.0.1 is directly connected, Loopback0
i ia 1.0.0.3 [115/30] via 10.0.0.2, Serial0
i L1 1.0.0.2 [115/20] via 10.0.0.2, Serial0
100.0.0.0/16 is subnetted, 4 subnets
i ia 100.0.0.0 [115/20] via 10.0.0.2, Serial0
i ia 100.1.0.0 [115/20] via 10.0.0.2, Serial0
i ia 100.2.0.0 [115/20] via 10.0.0.2, Serial0
i ia 100.3.0.0 [115/20] via 10.0.0.2, Serial0
10.0.0.0/8 is variably subnetted, 5 subnets, 2 masks
C 10.0.0.2/32 is directly connected, Serial0
C 10.0.0.0/24 is directly connected, Serial0
i ia 10.30.0.0/24 [115/30] via 10.0.0.2, Serial0
i ia 10.30.0.2/32 [115/30] via 10.0.0.2, Serial0
i L1 10.20.0.0/24 [115/20] via 10.0.0.2, Serial0
i*L1 0.0.0.0/0 [115/10] via 10.0.0.2, Serial0
In order to summarize the routes, as previously mentioned, the summary-address command with the level-1 keyword is applied on R2, the L1/L2 router leaking the routes toward L1.
Table 24. R2's Summary Related Configuration
router isis
summary-address 100.0.0.0 255.252.0.0 level-1
redistribute isis ip level-2 into level-1 distribute-list 100
net 49.0001.0000.0000.0002.00
metric-style wide
!
access-list 100 permit ip any any
Applying the above configuration produces the following impact on R1's routing table.
Table 25. R1's Routing Table after Summarization
Gateway of last resort is 10.0.0.2 to network 0.0.0.0
1.0.0.0/32 is subnetted, 3 subnets
C 1.0.0.1 is directly connected, Loopback0
i ia 1.0.0.3 [115/30] via 10.0.0.2, Serial0
i L1 1.0.0.2 [115/20] via 10.0.0.2, Serial0
10.0.0.0/8 is variably subnetted, 5 subnets, 2 masks
C 10.0.0.2/32 is directly connected, Serial0
C 10.0.0.0/24 is directly connected, Serial0
i ia 10.30.0.0/24 [115/30] via 10.0.0.2, Serial0
i ia 10.30.0.2/32 [115/30] via 10.0.0.2, Serial0
i L1 10.20.0.0/24 [115/20] via 10.0.0.2, Serial0
i*L1 0.0.0.0/0 [115/10] via 10.0.0.2, Serial0
i ia 100.0.0.0/14 [115/20] via 10.0.0.2, Serial0
As was intended, the correct summary route now appears on R1.
By now it should be obvious that ISIS offers a great deal of flexibility when it comes to controlling the flow of reachability information within the ISIS domain. The next section illustrates similar finesse when dealing with information external to the ISIS domain.
[IE-ISIS2-WP2-F02]
[2002-11-05-01]
|