The Complete IS-IS Routing Protocol- P34 docx

OSPF Area 11
OSPF Area 47
OSPF Area 0
Backbone
Pennsauken
Frankfurt
London
Washington
New York
Paris
Amsterdam
Stockholm
Vienna
Munich
Atlanta
Miami
San Jose
San Fran
1
2
3
4
1
2
4
3
F
IGURE
12.13. OSPF leaks all prefixes into all areas, which is one of OSPFs scaling harms
330
Domain-wide Prefix Distribution 331

Typically, leakage of all routes into the non-zero areas is not necessary. All that the non-
zero area needs to know is the area internal routes and a default route that points to the
Area Border Routers.
IS-IS has much better scaling properties in that respect. Consider Figure 12.14. Very
much like OSPF, IS-IS passes on Level 1 information to Level 2. However, the other
direction is by default blocked: Level 1 routers have to rely on a default route generated
by the L1L2 routers.
Flooding just a default route is clearly a very scalable approach; however, the use of
the default route as the only routing information pointing towards the ATTached Level 2
router is very unspecific information. Sometimes it is necessary to trade protocol scal-
ability for optimality of traffic flow. The side effect of unspecific information can be sub-
optimal routing, as shown in Figure 12.15. Traffic towards 192.168.1.13/32 gets attracted
to the closest L1L2 router, which is Router Barcelona, due to a lower metric of the
default-route 0/0 of 2000, although from a total routing metric perspective, sending the traf-
fic straight to the L1L2 Router Milan would be more optimal. The sub-optimal path-cost
Madrid-Barcelona-Paris-Frankfurt is 22000. The more optimal path would be Madrid-
Milan-Frankfurt with a composite path-cost of 11500. The use of unspecific routing-
information makes IS-IS have a kind of “blind spot” and results in sub-optimal routing.
RFC 2966 lifts that strict requirement to pass just the default 0/0 route down to Level 1 and
allows leaking of prefixes from Level 1 to Level 2. Additionally, RFC 2966 allows external
routes to exist in Level 1, which was strictly forbidden according to RFC 1195. But allowing
the routes to flow from Level 2 to Level 1 is still not enough, as shown in Figure 12.16.
Suppose some router, located beyond Paris in Level 2 originates (among others) its
loopback IP address, either in the internal IP Reachability TLV #128 or the Extended IP
Reachability TLV #135. Barcelona re-distributes the 192.168.1.1/32 prefix into Level 1.
The Level-1 LSP travels through Level 1 finally arriving at Milan. Milan does what every
L1L2 router has to do, and accepts unconditionally all Level-1 IP prefixes and injects
them into Level 2. This creates a wonderful routing loop as from this point on nobody really
knows where the route really did originate. Therefore a Marker Bit is needed to mark
routes that have been marked as Leaked from Level 2 to Level 1. Additionally, all L1L2

routers need to suppress prefixes where the Marker Bit is set and not propagate them fur-
ther. The Marker Bit is called, in RFC 2966 terminology, the Up/Down Bit. The Extended
IP Reachability TLV #135 has had support for the Up/Down Bit from the beginning.
The old (RFC 1195) style TLVs do not have support for the Up/Down Bit in the ori-
ginal specification, because none of the original authors was aware that too much scal-
ability could lead to a problem. RFC 2966 also redefines the MSB of the default-metric
for the two old-style IP Reachability TLVs #128 and #130. Per RFC 1195, the MSB of
the default-metric was specified as Reserved and should therefore be set to zero. See
Figure 12.17 and Figure 12.18 for the revised version of the old-style TLVs.
12.6.1 Leaking Level-2 Prefixes into Level 1
In both IOS and JUNOS the default behaviour of IS-IS is RFC 1195 compliant and does
not leak L2 prefixes from Level 2 to Level 1. When you want certain prefixes to leak
through you have to explicitly configure that.
Area 49.0001
Level 2-only
Area
49.0200
Area
49.0100
Pennsauken
Frankfurt
London
Washington
New York
Paris
Amsterdam
Stockholm
Vienna
Munich
Atlanta

Miami
San Jose
San Fran
1
3
1
3
0/0
0/0
0/0
0/0
F
IGURE
12.14. IS-IS suppresses per default Level 2 routing information to Le
vel 1
332
Domain-wide Prefix Distribution 333
Area 49.0001
Level 2-only
Area
49.0300
192.168.1.13/32
Barcelona Milan
RomeMadrid
Frankfurt
Paris
0/0
0/0
10000
1000010000

1500
20002000
1500 1500
FIGURE 12.15. Injection of default routes often causes sub-optimal routings
Area 49.0001
Level 2-only
Area 49.0300
192.168.1.1/32
Barcelona Milan
RomeMadrid
FrankfurtParis
1
3
4
5
2
F
IGURE 12.16. Leaked-down prefixes need to get marked, otherwise routing loops will form
334 12. IP Reachability Information
TLV Type
TLV Length
IP Address
128
Bytes
1
1
1
1
1
1

4
4
N*12
Default Metric
I/E
0
Delay Metric
S
1
I/E
0
Expense Metric
S
1
I/E
0
Error Metric
S
1
I/E
0
1
1
1
1
Default Metric
I/E
0
Delay Metric
S

1
I/E
0
Expense Metric
S
1
I/E
0
Error Metric
S
1
I/E
0
SUbnet Mask
IP Address
4
4
SUbnet Mask
U/D
U/D
FIGURE 12.17. RFC 2966 redefines the MSB of the default-metric of TLV #128 to support the
Up/Down Bit
In IOS there are two possible ways to leak prefixes from Level 2 to Level 1. The first
one controls the leaking via an extended access list. The second one controls route leak-
ing via a route-map. In the following examples, depending on the application, both methods
are used. For smaller networks, where the loopback IP addresses of all the routers in a
network fall under a common network prefix, the access-list options is typically good
enough. The following IOS configuration leaks prefixes, which match the extended
access list 166 from Level 2 to Level 1.
IOS configuration

Using the redistribute isis ip level-2 into level-1 distribute-list command
the network administrator can specify an extended IP access list which matches prefixes
based on a simple prefix/wildcard bit scheme for leaking from the Level 2 database into
the Level 1 database.
Amsterdam# show running-config
[… ]
Domain-wide Prefix Distribution 335
TLV Type
TLV Length
IP Address
130
Bytes
1
1
1
1
1
1
4
4
N*12
Default Metric
I/E
0
Delay Metric
S
1
I/E
0
Expense Metric

S
1
I/E
0
Error Metric
S
1
I/E
0
1
1
1
1
Default Metric
I/E
0
Delay Metric
S
1
I/E
0
Expense Metric
S
1
I/E
0
Error Metric
S
1
I/E

0
SUbnet Mask
IP Address
4
4
SUbnet Mask
U/D
U/D
F
IGURE 12.18. RFC 2966 redefines the MSB of the default-metric of TLV #130 to support the
Up/Down Bit
router isis
redistribute isis ip level-2 into level-1 distribute-list 166
passive-interface Loopback0
net 49.0001.1921.6816.8007.00
metric-style wide
!
access-list 166 permit ip 192.168.0.0 0.0.0.255 any
access-list 166 permit ip 192.168.168.0 0.0.0.255 any
[… ]
IOS command output
Using the show isis database command you can spot the leaked prefixes.
Amsterdam# show isis database Amsterdam.00-00 detail
IS-IS Level-1 LSP Amsterdam.00-00
LSPID LSP Seq Num LSP Checksum LSP Holdtime ATT/P/OL
Amsterdam.00-00 * 0x00000003 0x94B7 1193 0/0/0
336 12. IP Reachability Information
Area Address: 49.0001
NLPID: 0xCC
Hostname: Amsterdam

IP Address: 192.168.0.166
Metric: 0 IP 192.168.0.166/32
Metric: 10 IP 172.26.26.0/24
Metric: 10 IS-Extended London.00
Metric: 40 IP-Interarea 192.168.168.3/32
Metric: 30 IP-Interarea 192.168.168.4/32
Metric: 20 IP-Interarea 192.168.168.5/32
Metric: 20 IP-Interarea 192.168.168.6/32
Leaked IP prefixes are prepended via the keyword IP-Interarea that is printed if
the Down Bit is found in one of the IP Reach TLVs.
In JUNOS policy processing there is always a default policy for each routing protocol.
The default policy for IS-IS is to reject Level 2 routers from inclusion in the Level 1 data-
base. If you want to change that behaviour then you need to write a policy and call it
using the export statement. This causes your Level 2 prefixes being evaluated before
the default policy has chance to reject it.
JUNOS configuration
In JUNOS the most important task is writing the policy. The policy-statement leak-L2-
to-L1 is a single term policy and it consists of three parts. The from portion reads like “if”
and the keywords route-filter, protocol, level are ANDed together. That is, if the
prefix is originated within protocol isis AND it is Level 2 AND it falls under the route-filter
192.168.0/24 OR 192.168.168/24 THEN put it into the IS-IS Level 1 database.
[edit]
hannes@Frankfurt# show
[… ]
protocols {
isis {
export leak-L2-to-L1;
}
}
policy-options {

policy-statement leak-L2-to-L1 {
from {
route-filter 192.168.0.0/24 orlonger;
route-filter 192.168.168.0/24 orlonger;
protocol isis;
level 2;
}
to {
protocol isis;
level 1;
Domain-wide Prefix Distribution 337
}
then accept;
}
}
[… ]
Using the show isis database detail command you can verify if your prefixes
have been leaked correctly.
JUNOS command output
In JUNOS the leaked prefixes are marked with the Down Bit.
hannes@Frankfurt> show isis database detail
IS-IS level 1 link-state database:
Frankfurt.00-00 Sequence: 0x7, Checksum: 0x8cbb, Lifetime: 1187 secs
IS neighbor: London.00 Metric: 10
IP prefix: 172.26.26.0/24 Metric : 10 Internal Up
IP prefix: 192.168.0.167/32 Metric : 0 Internal Up
IP prefix: 192.168.168.3/32 Metric : 40 Internal Down
IP prefix: 192.168.168.4/32 Metric : 30 Internal Down
IP prefix: 192.168.168.5/32 Metric : 20 Internal Down
IP prefix: 192.168.168.6/32 Metric : 20 Internal Down

[… ]
In the output you can identify leaked prefixes based on the down keyword, which is
printed if the Down Bit is found in one of the IP Reachability TLVs.
12.6.2 Leaking Level-1 External Prefixes into Level 2
RFC 1195 explicitly forbids the use of External IP Reachability TLVs in Level 1. RFC
2966 loosens that restriction as well and allows injecting external information, such as
from another routing protocol (RIP, OSPF, BGP, statics), into IS-IS as well. This is par-
ticular useful when networked-technology does not speak IS-IS or not even a routing
protocol, and the network has to use static routes to inject reachability information. At
this point, the authors do not want to encourage injection of reachability information
(such as customer prefixes or dial-pools) into IS-IS. In modern network designs, all
reachability information is typically carried into BGP, as BGP scales much better with
respect to transporting massive amounts of routes. More consideration of these points
will be covered in Chapter 16, which deals with IS-IS related network design issues and
best current practices. If wide metrics are used in the network then that section can be
skipped: the Extended IP Reachability TLV #135 has no notion of internal versus exter-
nal prefixes and therefore all Level-1 prefixes get leaked to the Level-2 by default.
In IOS you can inject external information from Level 1 to Level 2 via a simple redis-
tribute isis ip level-2 into level-1 command. IOS transfers all routes
that match the access list 155 from Level 1 to Level 2 irrespective of whether it is an
external or an internal route.
338 12. IP Reachability Information
IOS configuration
Like the Level 2 to Level 1 redistribution in IOS you can specify a Level 1 to Level 2 redis-
tribution list which points either to a route-map or to an extented access list.
Amsterdam# show running-config
[… ]
router isis
redistribute isis ip level-2 into level-1 distribute-list 155
passive-interface Loopback0

net 49.0001.1921.6816.8007.00
metric-style wide
!
access-list 155 permit ip 10.0.0.0 0.0.255.255 any
[… ]
JUNOS makes distinction between internal or external prefixes. If you want to inject
external prefixes into the Level 2 of your network you need to match against the exter-
nal keyword in your routing-policy.
JUNOS configuration
The default policy for leaking external prefixes from Level 1 to Level 2 is reject. If you
want to pre-empt the default policy you have to chain-in a policy called leak-ext-L1-to-
L2 which catches all external Level 1 routes which match the 10.0/16 prefix.
[edit]
hannes@Frankfurt# show
[… ]
protocols {
isis {
export leak-ext-L1-to-L2;
}
}
policy-options {
policy-statement leak-ext-L1-to-L2{
from {
route-filter 10.0.0.0/16 orlonger;
protocol isis;
external;
level 1;
}
to {
protocol isis;

level 2;
}
then accept;
}
}
[… ]
Domain-wide Prefix Distribution 339
Notice the access lists and route filters that control the leakage between the two levels.
It turned out that managing these access lists is a particular pain for large networks. Every
time you deploy new routers whose loopback IP addresses need to be leaked then you
need to touch all L1L2 routers in your network adjusting the access lists. Most ISPs mit-
igated the problem by assigning blocks of loopback addresses to different POPs. The
access lists on the L1L2 routers therefore only need to be touched if a block in the POP
is fully allocated. Another common practice is to filter based on a prefix length such as
/32. Therefore only the loopback IP addresses get leaked – while this may seem as a
modest approach for medium-sized networks it clearly does not scale for large networks.
The largest networks in the world consist of about 7000–8000 IS-IS speaking routers.
Leaking all 8000 prefixes at every L1L2 router may overwhelm the smaller routers in the
POP. So what is needed is a more selective way of picking off the /32s from Level 2.
12.6.3 Use of Admin Tags for Leaking Prefixes
Most routing protocols support a tagging mechanism to enforce a route-redistribution
policy. IS-IS has a similar extension formulated in draft-martin-neal-policy-isis-admin-
tags.txt. The draft mentions two optional sub-TLVs to the Extended IP Reachability TLV
#135 carrying 32-bit and 64-bit tags. Figure 12.19 shows how these administrative tags
are being used in large-scale deployments. First, each interesting /32 prefix (in the figure
it is Quebec’s prefix 192.168.1.13/32) is tagged on the default leakage from Level 1 to
Level 2. Interesting typically means all those routers that rely on a proper IGP metric like
public Internet routing. In our example, the Tag #200 is used for all Internet routers that
carry Internet routes. The L1L2 routers Boston and Chicago attach the Tag #200 along with
the route. Next, those tagged prefixes travel through the Level-2. On the egress L1L2

routers (Frankfurt and Paris) the leaking policy now gets very simple as all we have to
look for is Tag #200 to find out whether to leak the prefix or not. The policy needs to be
configured only once and then all you have to do is properly tag the prefixes and your
network will act accordingly.
In the following two configurations you will see two configurations for IOS and two
configurations for JUNOS. The first of the two respective configurations does the tagging
and the second one does the leakage based on the existence of a tag.
Applying admin tags is fairly simple in IOS. An admin tag is typically an interface prop-
erty and can be set using the keyword isis tag <tag>.
IOS configuration
In IOS you set the Admin tag typically on the Loopback Interface. Using the show isis
database London.00-00 level-1 verbose you can verify if the Admin tag has been
successfully attached to your Loopback route.
London# show running-config
[… ]
interface Loopback0
ip address 192.168.0.166 255.255.255.255
isis tag 200
!