The Complete IS-IS Routing Protocol- P11 docx

discus-11.3 Analysis of IS-IS Extensibility IS-IS uses TLVs to encode Hellos, NLRIs, as well as miscellaneous other informationneeded for the IS-IS routing protocol to function properly.

Consider extending OSPF by adding a new, hypothetical LSA type The number could

be anything not currently used or defined – LSA type 53, for example Now, what if a routerrunning older OSPF software does not recognize the new, hypothetical LSA type 53?Should the router flood the LSA further across the network or should the router simplydiscard the update? To explain what OSPF does with extensions that the router does notunderstand, it is necessary to borrow a term from BGP terminology The term is called

transitivity Certain BGP attributes are transitive as the attributes flow from BGP router

to BGP router But the term can be applied to protocols other than BGP Transitivity meansthat if a router cannot interpret a given message, the router will flood the message further

across the network anyway Non-transitive behaviour means that a router does not

for-ward an LSA that the router cannot interpret in terms of the LSA payload

OSPF is a strictly non-transitive protocol OSPF routers will not flood LSA types thatthe routers themselves do not understand The ramifications of that are a bit depressing

Non-transitive OSPF behaviour means that a new feature cannot be rolled out unless all

OSPF routers in a given link-state domain are updated with the new software Given thefact that the role of the IGP is changing from the narrow role of distributing NLRI infor-mation towards a wider role with regard to a topology discovery function, it might benecessary for new OSPF features of increasing interest to use the flooding sub-system ofOSPF for distributing network-wide information And this information must be spreadall over the network, information that not each OSPF speaker must necessarily see

I won’t flood because I do not understand behaviour is not migration-friendly, and

there-fore causes a lot of headache for preparing migrations

Fortunately, the issue of OSPF transitivity has been addressed RFC 2370, The OSPF

Opaque LSA Option, describes an enhancement to base OSPF A set of opaque LSAs is

defined in this RFC that correct the problem with OSPF being non-transitive Instead of

using the BGP terminology of transitive, OSPF uses the concept of an LSA that is visible

(and understandable) to some OSPF routes and yet not visible to all OSPF routers The

new LSAs are not transparent to all OSPF routers, but opaque to some routers, routers that

must still pass on this LSA type through flooding nonetheless With RFC 2370, type 9, 10and 11 LSAs now become the universal transport vehicle for routing and topology-relateddata that need to get distributed by the flooding sub-system of OSPF With those extensions

in place, arbitrary data, including reachability information from other address families such

as IPv6, could theoretically be distributed about an OSPF routing domain A full sion of opaque LSA types in OSPF is not needed in a book on IS-IS It is enough to notethe presence of opaque LSA types in OSPF for the purposes of extensibility

discus-11.3 Analysis of IS-IS Extensibility

IS-IS uses TLVs to encode Hellos, NLRIs, as well as miscellaneous other informationneeded for the IS-IS routing protocol to function properly Virtually all these message elem-ents use Type-Length-Value (TLV) encoding to get their data across to other IS-IS routers

11.3.1 TLV Format

Figure 11.4 shows the basic elements for TLV encoding

Analysis of IS-IS Extensibility 289

The first element of the TLV structure is the Type field The size of the Type field is

8-bits wide, which gives room for 256 different codes In fact, a lot of documents call this

the Code-Length-Value (CLV) structure instead of TLV But the TLV terminology is

much more common and is therefore used here Type number 0 is reserved for furtherexpansion of the protocol The Type field is a well-known field that should be understood

by all routers in a given link-state domain ( IS-IS level) Next comes the Length field that indicates the length of the payload data, which is stored in the Value field Why is the

Length field needed if the Type code establishes the format of the information in theValue field? As long as all Type codes are well known, it would seem that the router hasenough information to decipher the value that the Type contains But it is not that simple.Let’s invent an example demonstrating the need for a Length field Suppose we want toencode an IPv4 prefix What we need is 8 bytes of space in the TLV Four bytes are for theprefix itself and four bytes are for the Netmask Next, let’s give this Value field the hypo-thetical Type number, say 47 Because Type Code #47 is well known by all routers runningthe IS-IS protocol, one could suppose that there could be a rule in the IS-IS protocol that Code 47 always means an implicit length of 8 bytes for the Value field

However, what happens if a router running older software does not recognize our new

hypothetical Type Code 47 Message? How is the Length made know to IS-IS routers that

do not know what a Type Code 47 is? Even worse, the section of IS-IS code that parses allthe incoming routing messages does not know when other messages-codes beyond theType Code 47 begin, because the code has no indication when the unknown Type Code 47

message ends Figure 11.5 illustrates the dilemma of the receiving router’s message parser.

So an explicit Length field is always needed for TLVs The Length field is again 8-bitswide, which leaves room for Values up to 255 bytes Although this may sound like a small

290 11 TLVs and Sub-TLVs

Type Length Value

1–255

Bytes 1 1 1–255

???

1 Type

F 11.5 Implicit length fields do not work unless all routers know all the Type codes

number (just think of a router that has hundreds of adjacencies to advertise) it has turnedout to be a sufficient size for most message types.

11.3.2 TLV Encoding

For the case of messages larger than 255 bytes, smaller message elements are scatteredacross multiple occurrences of a given Type Code Figure 11.6 shows how a large chunk (30

in this case) of IPv4 prefixes are scattered over two occurrences of Type Code 128 messages

Type Code 128, which is not hypothetical, will be discussed in more detail in Chapter 12.

The only thing a router needs to know is that the basic message format of TLV #128 isrepeated occurrences of IPv4 prefixes, metrics and net masks having a fixed length of 12bytes So each IPv4 prefix consumes 12 bytes space in the message What the TLV encod-ing engine needs to know is the maximum amount of IPv4 prefix data that can be stored in a

255 bytes sized message As it turns out, the densest packaging is reached when 21 prefixesare squeezed into one TLV encoded message, filling up the message to 252 bytes That stillresults in a TLV message space utilization of 98.4 per cent, which is fine for a routing proto-col The remaining nine prefixes get stored in a second occurrence of a Type #128 message.Interestingly, IS-IS has a uniform Type Code space for both Hellos and NLRIs Thismeans that an arbitrary TLV can theoretically be present both in all three IS-IS packettypes The three packet types that IS-IS generates are:

Analysis of IS-IS Extensibility 291

Bytes

30 IPv4 prefixes

Type Length Value

However, the 3-way handshake TLV on point-to-point (p2p) links, for example, onlymakes sense in p2p IIHs This is because the problem that this specific TLV #240 is trying to fix is purely related to p2p Hellos, during the startup procedure.

Table 11.1 shows a list of the most important TLVs in IS-IS, and in which packet typethe TLV might occur

The Type field is an 8-bit entity, which is a relatively small space, given the fact thatrouting protocols can live dozens of years In order to not exhaust the 8-bit space

throughout the years the protocol designers carried the TLV orientation further inside the

TLVs This concept is called sub-TLVs

11.3.3 Sub-TLVs

Sub-TLVs are used inside a TLV to encapsulate further message elements Theoretically

a dedicated TLV could be used as well for new message elements This would, however,quickly exhaust the TLV space The Extended IS Reachability TLV is a good example foruse of sub-TLVs The Extended IS Reachability TLV describes an IS-IS Adjacency andall sorts of link properties like Maximum Link Bandwidth, Link colours, Neighbours,

IP addresses, Traffic Engineering metrics and so on

Tcpdump output

The Extended IS Reachability TLV #22 carries an additional 69 bytes of link property mation.

infor-11:36:45.587565 OSI, IS-IS, length: 405

L2 LSP, hlen: 27, v: 1, pdu-v: 1, sys-id-len: 6 (0), max-area: 3 (0)

lsp-id: 1921.6800.1019.00-00, seq: 0x000002fd, lifetime: 1198s

chksum: 0xe984 (correct), PDU length: 405, L1L2 IS

[ … ]

Extended IS Reachability TLV #22, length: 75

IS Neighbor: 1921.6800.1021.00, Metric: 22000, sub-TLVs present (69)

IPv4 interface address subTLV #6, length: 4, 172.16.33.6

IPv4 neighbor address subTLV #8, length: 4, 172.16.33.5

Traffic Engineering Metric subTLV #18, length: 3, 22000

Unreserved bandwidth subTLV #11, length: 32

In Table 11.2 you can see all current defined sub-TLVs Chapter 14, “Traffic Engineeringand MPLS”, gives a more thorough discussion of the extended IS Reachability TLVwhich is just discussed here for the aspect of sub-TLVs.

Figure 11.7 shows a real-world example of the Extended IS Reachability TLV In our

example TLV, two adjacencies are reported The first link adjacency is describing linkcharacteristics to Neighbour 1921.6800.1008.00 The cost of using this link during the

SPF cycle is 250,000 as described in the Metric field After the Metric field each TLV

ter-minates with an optional sub-TLV length If the length field is zero, then no further linkcharacteristic are reported for this adjacency In our example there is indication that thereare 11 further bytes of link properties

The next byte contains the first sub-TLV type Code-point #8 is used to indicate a remoteneighbour’s IP address The sub-TLV Code is followed by a sub-TLV Length which is set

to 4 What finally follows is the value of 4 bytes describing the actual Neighbor IP Address.

The encoding of the first sub-TLV consumed 1
1
4  6 bytes So there is still

5 bytes left of sub-TLV information to decode

The next sub-TLV is code-type 18 and the sub-TLV length field indicates 3 bytes ofMetric Information This sub-TLV carries a kind of metric information that is purelyrelated to constrained based routing (CSPF) which is further illustrated in Chapter 14,

“Traffic Engineering and MPLS”

The encoding of the second sub-TLV consumed 1
1
3  5 bytes The originalsub-TLVs field of the IS reach adjacency indicated a total sub-TLV length of 11 bytes.What the router tries to find out next is to determine the remaining size of subTLVs –

it does so by subtracting the actual offset from the entire TLV length of 33 bytes So far

22 bytes (the first TLV plus the two sub-TLVs) have been processed so there must be 11

Sub-TLV

Analysis of IS-IS Extensibility 295

bytes left The parser therefore knows that the next 10 bytes is another IS adjacency

pointing to neighbour 1921.6800.1019.00 plus an SPF metric of 22000 This second link

is not carrying any sub-TLVs hence the sub-TLV length field is being set to zero

It has already been shown that there are several levels of information packaging inside

TLVs The Extended IS Reachability TLV #22 is a good example It contains several ISneighbours which may contain further sub-TLVs There is lots of room for all sort ofthings that can go wrong here Just imagine what happens if the sub-TLV length is big-ger than the TLV length Of course this can be avoided by all sorts of clever boundarychecking However, no specification expresses a mandate for boundary checking In the next section you will learn about IS-IS TLV sanity checking and how vendors havehardened their implementations to catch corrupted information

11.3.4 TLV Sanity Checking

Jon Postel postulated a famous guidance about protocol interoperability:

“Be tolerant of what you receive and strict in what you send!”

The background was that a protocol’s implementations should never assume that thereceiver will get it right and should encode its information as concisely as possible Onthe receiving side the rule mandates that the protocol should support error detection and

Type Length Neighbor ID

sub LV Value

22

Bytes 1 1

3 1 1 1 4

Metric subTLVs Length subTLV Type

subTLV Length

33 1921.6800.1008.00

250000

8 4 172.16.33.12

subTLV Value

subTLV Type subTLV Length

18 3 12000

1 1 3

3 1

Metric subTLVs Length

1921.6800.1019.00

22000 0 11

F IGURE 11.7 The sub-TLV length field of the Extended IS Reachability TLV #22 determines if there are any sub-TLVs following the basic IS reachability information

296 11 TLVs and Sub-TLVs

be tolerant about slightly malformed information structures Link-state routing protocols

do not allow implementers to follow that guidance, because of their highly distributednature

Consider the following example: A router receives a malformed TLV and detects thatTLV is malformed What should the router do? – further flood it or silently discard it andlog an error message? ISO 10589 mandates that flooding should be transparent through-out the area If the flooding stops what might be the biggest harm? Worst case, a routingloop What happens if the router floods the LSP containing the malicious LSP further?Worst case, it may crash other routers in the network who do not encompass proper TLVsanity checking In the past 10 years of IS-IS deployment there have been at least 20 majornetwork meltdowns because corrupted LSPs got flooded further across the network Thefirst occurrence was back in the NSFNet backbone Dr Rekhter, now a DistinguishedEngineer with Juniper Networks, relates the following story:

“One thing that happened in the NSFNET backbone concerns the way my code dled ISIS link state updates When a router received an ISIS link state update, the router would do some processing on that update, then flood the update to its neighbors, and then complete the rest of the processing on this update Due to some bug in the code the last part (“the rest of the processing”) caused router crash But since the router crashed after

han-it flooded the link state update to han-its neighbors, the update also caused the neighbors to crash as well, resulting in the overall network meltdown.”

Implementers of the IS-IS protocol decided, because of the high inherent risk, to take

a closer look to known TLVs and tightly check their formatting The most commonfound TLV format tests are discussed in the next three subsections

11.3.4.1 Maximum Length Checking

Each TLV and sub-TLV reports a certain length The length field is typically an 8-bit fieldthat can express Value fields between 0 and 255 bytes However, not all TLVs and sub-TLVs can actually consume the full range of 255 bytes

For example, in March 2001 there was a big meltdown in a large US transit carrier’snetwork The root cause was that a failing piece of hardware generated a malformed AreaTLV #1 Figure 11.8 illustrates the structure of the Area TLV #1 The TLV contains a set

of Area Lengths and their corresponding Area-IDs In the OSI world only Area-IDsbetween 1–13 bytes length are supported If the Area-ID is outside that range, then theentire TLV, if not the entire LSP, is highly likely to be corrupted After parsing the TLVthe receiving router did not check for the maximum Area-ID length and overwrote datastructures in the SPF algorithm implementation, which were expecting Area-IDs notlarger then 13 bytes The routing software crash did not manifest itself immediately –

there was unfortunately enough time to flood the killer LSP further, enough time to crash

the entire network

Since that incident, maximum length checking is employed for the Area TLV #1.Continuing that thought there would be other TLVs that could get checked for Minimumand Maximum Length Fields Table 11.3 lists the minimum and maximum length valuesfor all TLVs

Analysis of IS-IS Extensibility 297

TLV TLV Length

1

Bytes 1 1 1 1–13

Area Length Area ID

1 1–13

Area Length Area ID

F IGURE 11.8 The Area TLV #1 lists all the variable length Area that a router participates

T ABLE 11.3 Each TLV, due to its structure, has given minimum and maximum values.

All implementers are encouraged to check each received TLV against Table 11.1.Checking for the minimum TLEB Length Values reveals if there are broken TLVsaround Checking for the maximum value helps to avoid Buffer overruns

11.3.4.2 Sub-TLV Overrun Checking

A sub-TLV parser should verify at any time that the sum of all parsed sub-TLVs does notget bigger than the original TLV minus the TLV specific overhead Table 11.4 lists all theTLVs that support sub-TLVs and their maximum value they can grow

298 11 TLVs and Sub-TLVs

T ABLE 11.4 The sub-TLVs must not consume more space than the TLV offers.

A receiving router needs to check for two things First, is the sub-TLV shorter than themaximum value according to Table 11.4? Then, it needs to verify if the sub-TLV is notbigger than the actual TLV length as encoded in the Length value

11.3.4.3 Discrete Length Checking

Some early ISO 10589 TLVs have a very structured layout Some of the RFC 1195 IP ReachTLVs copied the ISO 10589 style and hence have a similar structured layout as well Thatstructured layout allows now to predict certain packet sizes In the right-hand columns of

Table 11.5 there is a small formula for each TLV The factor N is typically the amount of

information elements announced in that TLV For example, a router with three IP addresses

would advertise a N * 4  3 * 4  12 bytes Length Interface Address TLV #132 in is Hello.

The final check tries to verify certain patterns in the information elements

T ABLE 11.5 Certain TLVs because of their structure only have discrete sizes.

11.3.4.4 TLV Content Pattern Checking

A good example for a pattern check is the Netmask field in the IPv4 Internal and ExternalReachability TLVs Although the Netmask field is a 32-bit field, it only allows 33 certainvalues covering all permutations of prefix lengths Another example would be the bandwidthvalues of some Extended IS-Reach #22 sub-TLVs like the Maximum Link Bandwidthsub-TLV #9 can only carry certain discrete bandwidth values draft-ietf-isis-gmpls-exten-sion-19 gives good guidance on which values are supported

TLV sanity checking is a new discipline which is in contradiction to the fully parent flooding model of ISO 10589 However, it turned out that service providers arehappy to trade better stability against flooding transparency especially the one that experi-enced a full-scale network crash due to bogus TLVs that did not get detected

so it doesn’t use all the stable code of the OSPFv2 version All routing software has toundergo a maturity process to become stable enough for productive use in the Internetbackbones of the world and OSPFv3 maturity may take a little longer as it tries to be allthings to all packets.

Compared to OSPF, IS-IS is almost like a case study on how to do it right the first time.

From day one, IS-IS has been designed to stay neutral no matter which Network Layerprotocol information it had to transport IS-IS has always been effectively multi-protocolready: in the 1980s it was used for routing CNLP traffic; in the 1990s IPv4 traffic wasadded; and, since 2001, IPv6 has been efficiently carried It helps when the message elem-ents and packet types of the base IS-IS routing protocol use the proper TLV encoding Inaddition, special precautions have been made not to exhaust the small 8-bit code spacethrough use of sub-TLVs, even in the newer TLVs TLVs and sub-TLVs turn out to be apowerful vehicle to further extend the protocol Due to the extra complexity of sub-TLVencoding and tight sanity checks based on known TLV structure, before loading TLVcontents into the link-state database are recommended

Finally, the code changes from the IPv4 to an IS-IS supporting IPv6 required only400–600 lines of code, not an entire rewrite of the protocol It is unlikely that active rout-ing of IPv6 prefixes will do any harm to the base stability of the IS-IS code

Adapting in a constantly changing environment is what Darwin’s Law is all about.When it comes to routing protocols, extensibility is a prerequisite for routing protocolevolution It is the authors opinion that IS-IS adapts better than OSPF, which is why itwill continue to prevail in the largest routed networks in the world

IP Reachability Information

IS-IS was ready from day one for extensibility Originally intended to route CLNP fixes, today IS-IS carries routing information about a variety of networking protocolsincluding IPv4 and IPv6 In this chapter you will learn about the various places where IPprefixes or IP reachability information, which is the IS-IS term, is encoded Support for

pre-IP prefixes came in three waves The chapter covers both the old-style (first generation)and the new-style (second generation) TLVs Additionally, the limitations of the first-

generation IPv4-related TLVs defined in the Integrated IS-IS Routing specification (RFC

1195) will be highlighted Finally, some of the reasoning surrounding the particular lems that the more recent traffic-engineering TLVs solve will be explained

prob-IS-IS has multiple places to convey IP reachability information To understand why theIP-related TLVs have been re-engineered continually, it is necessary to take advantage ofhindsight and consider the times when a specific protocol decision was made Therefore,before exploring the style of the IP TLVs, a look at one of the original ISO 10589 TLVs isneeded Of course ISO 10589 is totally unrelated to IP; however, to acquire an understand-

ing of how ISO 10589 encodes information, it is a good idea to also get a better

under-standing of why the first generation of IP TLVs are the way they are

12.1 Old-style Topology (IS-Reach) Information

Figure 12.1 shows how IS-IS encodes neighbour reachability information in the ISReachability TLV #2 The TLV conveys pure router-to-router connectivity informationand is unrelated to IP The first byte is the Virtual Flag, which is either set to zero or one.Typically this is set to zero It is only set to 1 in Level 2 LSPs and indicates that this link

is used to repair an area partition However, partition repair isn’t something that a col should address Typically partitioning of Level 1 areas is avoided by putting enoughlinks in the area IOS supports area partitioning for CLNP However, JUNOS lacks sup-port for healing broken, partitioned areas Therefore the least common denominator isthe simplistic design rule: “Never let an area get partitioned”, and try to avoid partitioning

proto-of an area by throwing enough links at the problem

After the virtual flag there is a basic structure of 11 bytes that may be repeated out the TLV That 11-byte structure holds 4 bytes of metric-related information and

through-6 bytes of System-ID appended with the one-byte Pseudonode-ID Interestingly, the basic

ISO 10589 specification supports multidimensional metrics There are distinct metrics

301

for Delay, Error, Expense and a mandatory default metric The basic idea behind this scheme

is that each router computes four distinct “topologies” by running a dedicated SPF ation for each However, at the time IS-IS was first deployed (end of the 1980s) people

oper-were cautious about using CPU cycles and therefore only computed the mandatory SPF

topology, which is the default topology If IS-IS would have been first deployed at theend of the 1990s, computing distinct SPF trees probably would have not been much of

an issue due to the massive processing power available even in embedded router systems

For routing IP, the IS-IS implementation of IOS and JUNOS does not support

computa-tion of anything but the default topology Both only propagate the default metric andignore any other metrics during receipt and during the SPF run IOS, however, does sup-port multidimensional metrics for routing CLNP, as already mentioned

Each of the four possible metrics is represented by a dedicated byte The most cant bit (MSB) of the respective metric byte indicates what additional metrics an individ-

signifi-ual router supports Typically the MSB is set in the Delay, Expense and Error metrics, which indicate that the metric is not supported Next to the MSB there is the Internal/External bit, which expresses whether the Metric is comparable or not Internal means it is compar-

able, while External means it is not (Internal metrics are always based on the same

rout-ing protocol, while externals metrics are independent of IS-IS.) Typically the I/E bit is set to

302 12 IP Reachability Information

TLV Type TLV Length Virtual Flag

Neighbour ID

2

Bytes 1 1 1 1 1 1 1

N*11
1 0

Default Metric R

0 I/E0

Delay Metric S

1 I/E0

Expense Metric S

1 I/E0

Error Metric S

1 I/E0

Neighbour ID

1 1 1 1

Default Metric R

0 I/E0

Delay Metric S

1 I/E0

Expense Metric S

1 I/E0

Error Metric S

1 I/E0

F IGURE 12.1 The IS-Reachability TLV is the blueprint for all the old-style Reachability TLVs encompassing 6-bit metrics

zero, indicating that the metric is comparable Confused? Don’t worry! Simply assume the I/E bit is always set to zero – in this TLV the I/E bit has no real practical meaning Next,

there are 6 bits that hold the metric information Six bits can only express routing metricsranging from 0 to 63, which is quite limited these days Once again, the design choice ofusing 6 bits goes back to the anxiousness about the SPF calculation consuming too manyCPU cycles

In every step of the SPF calculation a sorting function needs to be executed One can

optimize that sorting function through the use of linear arrays Consider Figure 12.2 where

a router’s preliminary metric during the SPF calculation is 456 Now the process needs

to find out if there are any other routers offering a better path to a given destination (theSystem-ID) by applying a sorting function Using index arrays, one can skip that sortingfunction All that need be done is store a pointer to the System-ID at the 456th entry inthe array If the array gets traversed from zero to the end, the first non-null pointer must

be the highest value This implementation has the disadvantage that it consumes ory By limiting the Link Metric to 63 and the Aggregated Metric to 1023, IS-IS makessure that the indexing function does not consume too much memory This is another placewhere CPU/memory constraints have made their way into the IS-IS protocol In hindsight,almost always where protocol designers tried to address a particular CPU/memory/environment shortage issue of the time by protocol properties, those protocol propertiesfinally got deprecated over time It turned out that protocols live much longer than micro-processors or memory chip restrictions do

mem-Old-style Topology (IS-Reach) Information 303

0

SysID 1921.6800.1008.00 Metric 456

F IGURE 12.2 Index arrays helped to speed up search operations

For lower bandwidth links the limitation to just 63 distinct metric values was not much

of an issue, because there was not much disparity between the smallest and the largestbandwidth links in a network Consider (for instance) a DS0 (64 Kbps) circuit and a T1(1.544 Mbps) circuit The T1 has 24 times the bandwidth of the DS0 Inverse bandwidth

metric schemes are commonly used (since the lower the metric, the more attractive theroute), so setting the T1 line to a metric of 1 and the DSO to a metric of 24 provides gooddifferentiation between the two bandwidths in the metric space Now, consider that thehighest bandwidth in the network becomes an OC-3/STM-1 circuit capable of carrying

155 Mbps Assign the lowest-cost metric to the high-speed circuit, as before About 100times the capacity of a single T1 circuit fits into an OC-3/STM-1 circuit, so assign a met-

ric of 100 to the T1 Stop! Assigning a metric of 100 doesn’t work because there are only

6 bits available The metric must be “clipped” to 63 Continuing with the 155 Mbpsexample, re-doing the calculation for the DS0 again exposes the limitations of a 6-bit met-ric space About 2400 DS0s fit into an OC-3/STM-1 circuit However, since there is nobigger metric, once again clip the metric to 63 The end result is that, from an IS-IS per-spective, the DS0 link becomes now indistinguishable to the T1 line, as both metrics arenow 63 That increasing disparity of IGP metrics became the motivation to introduce new

TLVs that have a broader metric field than just 6 bits (called wide-metrics in IS-IS).

12.2 Old-style IP Reach (RFC 1195) Information

It is best to demonstrate the way of thinking embodied in the ISO 10589-defined TLVsfirst Then it is easier to catch the spirit of the IP reachability information, which is verysimilar to the IS-Reach TLV #2

RFC 1195 specifies six new IP-related TLVs that are used to convey IP reachabilityinformation Two of the 6 TLVs became deprecated and are not used anymore Theremaining 4 TLVs are used for a variety of functions, like transporting IP routes, inform-ing neighbours of new capabilities and troubleshooting ease

12.2.1 Internal IP Reachability TLV #128

The Internal IP Reachability TLV #128 is probably the most important of the RFC

1195-defined TLVs It conveys internal routing information, which is to say, directly

con-nected routes Figure 12.3 shows the basic structure of TLV #128 Please refer to Figure12.1 for comparison Correct – they look very similar The structure basically starts, as inISO 10589, with the same 4 bytes of metric information The Metric fields are still 6 bits.Although broader metrics would not have an impact on CPU cycles (this is just leaf-information), the protocol designers decided to stay consistent with the spirit of ISO

10589 The IP Network Number and the Netmask follow after the 4 Metric bytes Thesefields have these names because it was common at the beginning of the 1990s to specify

IP reachability information not as prefixes and prefix lengths but rather as networks andnetwork masks

The internal IP Reachability TLV gets automatically advertised when IS-IS is run on

an interface with a configured IP address, or through use of the passive option.Whenever IS-IS is run on an interface, once an adjacency forms, all IPv4 addresses onthat interface are encoded using TLV #128 in the router’s LSP Alternatively, if the router

needs to be configured to advertise a sub-net but not form an adjacency (there are valid

reasons to do this, as discussed in Chapter 16), use the passive option The passive

304 12 IP Reachability Information