The Complete IS-IS Routing Protocol- P5 potx

IS-IS uses dedicated IIH messages for the two types of topologies arouter can be conﬁgured to be a member of: there is one Hello type for the Level 1 adja-cencies and one Hello type for

Trang 1

The System-ID ﬁeld of the LSP-ID is displayed as a name However, the originrouter’s System-ID is displayed with the show isis hostname command (the same

in IOS and JUNOS), which displays the hostname cache on the local router

IOS command

IOS marks the local node with an asterisk (*):

Frankfurt#show isis hostname

Level System ID Dynamic Hostname

hannes@London> show isis hostname

IS-IS hostname database:

represent the System-ID of the sender therefore the CLI renders the output using the to-System-ID database

Trang 2

Hostname-routing hierarchy The concept of an arbitrarily assigned level to the underlying physicaltopology was explained This flexibility allows IS-IS to make very resilient POP top-ology without spending extra costs for physical intra-POP links just to heal the topology.The IP addressing model and the OSI addressing model were discussed in a comparativeway; interestingly, the IS-IS model corresponds almost exactly to the unnumbered IProuting model IS-IS inherits its addressing structure from the OSI suite of protocols.Address assignment is a relatively easy task The fixed part of the NET can be calculatedbased on the IP loopback address of the router and/or the POP/topology codes that areunique to each service provider The Area-ID is the only variable part in the system, andbased on network size, most IS-IS networks use 3 or 5 byte Area-IDs Most Area-IDsstart with 49 because the 49/8 prefix has been allocated for private use – it is the RFC

1918 of the OSI suite Finally, this chapter presented the IS-IS built-in name resolutionservice and several commands to display those ID formats which beneﬁt from the addressresolution service as well

Trang 3

Virtually all routing (and signalling) protocols include a method of automatic neighbour

discovery that enables a router to determine if there are any other adjacent routers running

the same routing protocol Once you enable IS-IS on an interface, the routing protocolwill automatically ﬁnd out if there are other routers out there speaking the same protocoland version and immediately start to interact with these remote routers Additionally therouting protocol needs to verify if the link is two-way capable (that is, equally able to passprotocol trafﬁc in both directions) before it can announce a Reachability Information TLV

in a link-state PDU (LSP) and ﬂood it throughout the topology This veriﬁcation of link

capabilities and bi-directional checks is done using a process known as handshaking This

chapter examines how IS-IS routers perform neighbour discovery and handshaking onLAN and WAN circuits Additionally, different properties of handshaking methods, such asthe simple 2-way handshake and the inherent problems of using this 2-way handshakingmethod are discussed

You will also learn the details of adjacency ﬁnite state machine changes and network

stability improvement techniques like adjacency hold downs Finally, requirements ofhighly resilient neighbour “liveness” checking will be presented and popular solutionswill be explored including technologies like bi-directional fault detection Everythingwill include conﬁguration snippets, show command and debug output, plus tcpdump out-put for a better understanding of the IS-IS protocol

5.1 Hello Message Encoding

Each routing protocol uses Hello messages for neighbour discovery and to performhandshaking In IS-IS, just like in any other routing protocol, this function is performed

through the use of what IS-IS calls Intermediate System to Intermediate System Hello

(IIH) messages IS-IS uses dedicated IIH messages for the two types of topologies arouter can be conﬁgured to be a member of: there is one Hello type for the Level 1 adja-cencies and one Hello type for the Level 2 adjacencies There are more details about theIS-IS hierarchical Level 1/Level 2 routing paradigm in Chapter 4 “IS-IS Basics”.IS-IS supports two different circuit types: point-to-point (p2p) and broadcast LAN cir-cuits There is a dedicated type of Hello Message for point-to-point circuits and anotherone for broadcast circuits So in theory there should be two Hello messages for each cir-cuit type (point-to-point or broadcast) and two Hello message types for each Level, L1

or L2 This should total four distinct Hello message types

1095

Neighbour Discovery and Handshaking

Trang 4

In ISO 10589, however, there was some concern that running two Hellos (one perlevel) on point-to-point links would consume too much bandwidth on narrow-band links.

So IS-IS is optimized for point-to-point circuits and only uses one PDU type for both

levels Figure 5.1 shows the structure of the IS-IS common header, which starts every IS-ISmessage The 8-bit PDU type ﬁeld indicates the type of message that is carried inside theIS-IS message On the right of the ﬁgure there is a list of the nine distinct PDU types forIS-IS Three out of the nine PDU types are reserved for Hello messages The point-to-point circuit types share one PDU type (17) for both levels, so there are not really four different Hello messages but only three

What do the Hello messages look like on the wire? Each IS-IS message type is

prepended with an 8-byte common header that tells the receiver about the IS-IS protocolversion being used, the header length, the maximum number of concurrent areas sup-ported, as well as other IS-IS global parameters, such as the length of the System-IDfield Figure 5.1 shows the structure of the common header that is prepended to all IS-ISrelated messages In the figure, you can see that some of the fields are already filled inwith number values We have chosen not only to show the frame structure, but also toshow how the frames are populated with number values These numbers represent con-stants and fill in the common header with typical values It is interesting to note that someheader fields, such as the number of supported areas and the length of the System-IDfield, are set to zero Zero has a special meaning in IS-IS Using the zero value is equiv-

alent to telling routers to use the default value for a ﬁeld, which is not typically zero.

Intra-domain routing protocol discriminator

Header Length Indicator

Version/Protocol ID Extension

0x83

Bytes 1 1 1 1 1 1 1 1

1

ID Length PDU Type

6 (0)

1

3 (0) 0

15 16 17 18 20 24 25 26 27

Level 1 LAN Hello Level 2 LAN Hello p2p Hello Level 1 Link State PDU Level 2 Link State PDU Level 1 CSNP Level 2 CSNP Level 1 PSNP Level 2 PSNP

Trang 5

Oddly, because the default value is not explicitly set out in detail in IS-IS, each mentation has to intuitively know the default values The default value for System-ID-

imple-Length is 6 bytes and the default value for Maximum Area Addresses is 3, but these are

really de facto defaults and not set out as hard limitations.

You should now have a basic understanding of IS-IS Hello messages The followingsections discuss LAN Hello messages and point-to-point messages in greater detail

5.1.1 LAN Hello Messages

Figure 5.2 shows the structure of an IS-IS Hello message as it is used on LAN (IS-ISbroadcast) circuits First there is the IS-IS common header The header length of LANHello messages is always set to 27 bytes – this represents the aggregate length of thecommon header (8 bytes) and the LAN Hello header (19 bytes) The PDU type is either

15 or 16 depending on whether or not this is a Hello message targeted for Level 1 routers

or Level 2 routers respectively

Hello Message Encoding 111

Reserved

15, 16 27

circuit type 1, 2, 3

Source ID

Holding Time

PDU Length

Priority R

Trang 6

The IS-IS LAN Hello message header starts with a ﬁeld indicating which levels havebeen conﬁgured on this circuit (the LAN) For the two lower order bits (the six other highorder bits are reserved and should be set to zero) there are three valid values:

• 0x1 Level 1 only

• 0x2 Level 2 only

• 0x3 Level 1 and Level 2

If the Circuit Type ﬁeld is set to zero (both bits are zero, or “cleared” as code opers say) this represents an illegal value and the router will silently discard the Hellomessage, assuming that there is something broken

devel-The Source-ID ﬁeld contains the System-ID (the default length is 6 bytes) of the sender.Holding Time represents the time after which the neighbour wants to be declareddead This sounds strange, but unlike humans, routers can specify their maximum ses-sion lifetime Typically, default holding time values are between 27 and 30 secondsdepending on the routing code implementation (IOS 30 seconds and JUNOS 27seconds) Setting the holding time (for example) to 30 seconds is interpreted by thereceivers of the Hello message as follows: “If the neighbour router with the reportedSystem-ID does not send a Hello message for a period of 30 seconds, we’ll declare theneighbour router dead and take appropriate action.” This action usually involves tellingthe other neighbours that the adjacency relationship between these two routers has been

terminated Each Hello message received resets the countdown number for this

New hello received

reset hold timer

Trang 7

router initializes a countdown timer, starting at 30 seconds Next, the neighbouringrouter will refresh the adjacency To calculate the frequency for those refreshes there is a

constant called the Hello multiplier which is by default set to the value 3 The

neigh-bouring routers refreshes the Hello each (hold-timer divided by the Hello multipliertime) period Using the default values of 30/3, the adjacency should get a refresh every

10 seconds If a router wants to lower the Hello frequency, no problem, as long as theneighbouring router makes sure that the adjacency gets properly refreshed within thehold-time period The Hello message is resent every 10 seconds (or t[10s,20s], as repre-sented in Figure 5.3) resulting in a saw-tooth shaped figure over time A router can alsodecide to change its hold-timer anytime – for example, at t[30s] a Hello message with thehold time set to 40 seconds is received This resets the countdown timer, as might beexpected, to 40 seconds This is a unique capability among IP routing protocols: each IS-IS router can set its hold-timer independently from every other router on the network.This feature is quite different from OSPF networks where the Hello and the dead timerhave to match throughout entire sub-net, otherwise the routers will not form neighbouradjacencies On OSPF LANs, changing timers on the fly is disruptive and lacks the flexi-bility that IS-IS gives you, unless you somehow manage to change all the Hello and dead timers at the same point in time using a configuration script/robot IS-IS is muchmore operationally friendly in that respect, because IS-IS does not rely on any otherrouters to match its timers like OSPF does In OSPF, all the timers have to be alignedwith the designated router (DR)

In IS-IS such a change does not require any coordination/scripting effort If you want

to change your own timers, you simply do it in a step-by-step fashion with no service ruption at all

dis-The PDU Length ﬁeld contains the length of the entire packet including the commonheader and the LAN Hello header

The Priority and DIS LAN-ID ﬁelds are related to the election procedure of theDesignated Intermediate System (DIS) Chapter 7, “Pseudonodes and DesignatedRouters”, contains a detailed description of why a DIS is needed and how the DIS

is elected on a LAN The IS-IS DIS has much the same duties and functions as the OSPF DR

Multiple adjacencies on a circuit are displayed differently in the command line faces of Cisco and Juniper Networks Cisco IOS displays multi-level LAN adjacencies in

inter-one line, while JUNOS displays multi-level LAN adjacencies in two lines.

IOS command output

In IOS a Level 1 and Level 2 adjacency on a LAN circuit is displayed as L1L2 in the show

isis Adjacency output.

London#show clns neighbors

System Id Interface SNPA State Holdtime Type Protocol

Pennsauken GigE4/0 00a0.a512.28d7 Up 18 L2 IS-IS Frankfurt FastE5/0 0090.6900.fe27 Up 24 L2 IS-IS

Hello Message Encoding 113

Trang 8

Reserved

17 20

circuit type 1, 2, 3

2

1

F 5.4 Structure of the point-to-point Hello PDU

JUNOS command output

In JUNOS a Level 1 and Level 2 adjacency on a point-to-point circuit is displayed as two separate adjacencies in the show isis Adjacency output.

hannes@Munich> show isis Adjacency

Interface System L State Hold (secs) SNPA

On point-to-point circuits there is a dedicated Hello type for adjacency management:the point-to-point IIH PDU (17), which will be highlighted in the next section

5.1.2 Point-to-point Hello Messages

Figure 5.4 shows the basic structure of a Hello message used on point-to-point cuits The point-to-point Hello message is a little shorter than its LAN counterpart, but essentially it contains the same set of information that the LAN Hello message does

Trang 9

cir-For instance, the point-to-point Hello contains:

Additionally, there is the Local Circuit-ID ﬁeld that carries the link’s circuit numberThe IS-IS speciﬁcation leaves it quite open as to what value should be inserted for theLocal Circuit-ID For example, in the IOS implementation, the Interface Index of thesender’s interface is taken as the Local Circuit-ID The JUNOS implementation alwayssets this value to 0x1 The JUNOS implementers of this “constant” Local Circuit-IDargue that the Circuit-ID is not needed anywhere for processing, such as in SPF calcula-tions, timer countdowns, or anything else The Local Circuit-ID is there for purely link-

local informational purposes And if something has just informational purposes, then no harm can be done by not setting it to anything other than a constant.

How can IS-IS build both Level 1 and Level 2 adjacencies on a point-to-point link with just

one message type? Figure 5.2 showed that LAN Hellos have two PDU types, one for each

level, whereas point-to-point Hellos share one PDU type for both levels The difference in cessing the point-to-point Hello compared to the LAN Hello is that receipt of a point-to-point

pro-Hello resets the hold timers for all levels, as indicated in the Circuit Type ﬁeld For example,

if the Circuit Type ﬁeld indicates that this is just a Level 1 adjacency, then just the hold timer

of Level 1 is reset The same logic goes for Level 2 and Level 1/Level 2 capable circuits –whatever level is indicated in the Circuit Type, those corresponding hold timers get reset

In contrast to point-to-point Hellos, receipt of a LAN Hello just resets the hold timeraccording to the PDU type A received Hello containing PDU Type 15 just resets theLevel 1 hold timer, while a PDU Type 16 resets the Level 2 hold timer only

Command line interfaces of routers have different ways of displaying a joint Level1/Level 2 adjacency For example, JUNOS displays an L1L2 adjacency on a point-to-point circuit as Level 3 Of course there is (yet) no Level 3, but the reason for this is sim-ple: if you take the bit patterns of a Level 2 circuit (10b) plus the bit pattern of a Level 1circuit (01b) the sum equals to (11b), which is the binary value for 3

JUNOS command output

In JUNOS a Level 1 and Level 2 adjacency on a point-to-point circuit is displayed as

Level 3 in the show isis Adjacency output.

hannes@Frankfurt> show isis Adjacency

Interface System L State Hold (secs) SNPA

Trang 10

IOS command output

In IOS a Level 1 and Level 2 adjacency on a point-to-point circuit is displayed as L1L2 in

the show clns neighbors output.

London#show clns neighbors

System Id Interface SNPA State Holdtime Type Protocol

To summarize, Hello messages are the method used for discovering neighbours IS-ISrouters send Hellos according to their conﬁgured link types, and wait for responses thatare a match Receipt of a matching Hello message means another router on the link is atleast conﬁgured to run IS-IS This is a good start, but not the whole story of establishingand maintaining a full IS-IS router adjacency

The next step is to check if the underlying circuit to the neighbour router is

two-way capable Two-two-way capable means a pair of routers can transmit and receive their

peer’s Hello messages A router needs to be sure that “I can see you and you can see me”, before advertising an adjacency in its LSP In order to verify two-way circuit

capability the router needs to perform a handshaking function There are several

differ-ent handshake algorithms available and, unfortunately, some cannot even guarantee that the underlying link is two-way capable, due to a mistake in the ISO 10589 speciﬁcation

Even if the router is fooled by a broken handshake mechanism, nothing breaks on

the network if (for example) the circuit is just one-way capable and the router announcesthe one-way reachability (I can see you, but you cannot see me) in its router LSP During the

SPF calculation there is a veriﬁcation called the two-way check that makes sure no

transit path is calculated through a one-way circuit The two-way check will be described

in more detail in Chapter 10 “SPF and Route Calculation”

Before IS-IS starts to verify two-way connectivity over a link it actually probes the link ﬁrst to ﬁnd out if it supports large packets for data exchange at a later stage

5.2 MTU Check

In IS-IS the largest packet (which is typically the LSP) may become 1492 bytes (MAClayer excluded) IS-IS tests the link by artificially bloating its Hello size up to 1492 bytes.There is a dedicated Message Element in the Hello PDU called a Padding TLV that isused for this purpose Figure 5.5 shows the structure of the Padding TLV #8 The content of the Padding TLV is filled up with random data The information that it does contain does not matter – what matters is that it makes the PDU artificially big

up to maxLSPsize ( 1492 bytes) The tcpdump output below shows such a padded

Hello

Trang 11

Tcpdump output

20:16:37.411690 OSI, IS-IS, length: 1492

L1 Lan IIH, hlen: 27, v: 1, pdu-v: 1, sys-id-len: 6 (0), max-area: 3 (0) source-id: 1921.6800.1008, holding time: 120s, Flags: [L1, L2]

lan-id: 1921.6800.1008.02, Priority: 64, PDU length: 1492

IS Neighbor(s) TLV #6, length: 6

SNPA: 0090.692b.0e52

Protocols supported TLV #129, length: 1

NLPID(s): IPv4 (0xcc)

IPv4 Interface address(es) TLV #132, length: 4

IPv4 interface address: 193.83.223.236

Area address(es) TLV #1, length: 4

Area address (length: 3): 49.0001

Restart Signaling TLV #211, length: 3

Flags [none], Remaining holding time 0s

IOS and JUNOS do have different styles of how and when they do implement cency checks IOS pads each and every Hello that it transmits on the wire On large WANHub Routers that terminate a lot of circuits – for example on a Router running Framerelay or ATM circuits – periodic emission of large packets can be a burden to the control plane processor If you know that your underlying link supports at least

adja-1492 bytes sized packets then you can turn off the artiﬁcial bloating of Hello PDUs usingthe no hello padding router conﬁguration command

Trang 12

JUNOS encompasses a technique called smart padding, where the router transmits

padded Hellos only at the beginning of the Adjacency Bring up After both ends of arouter have completed the handshake procedure JUNOS automatically omits the PaddingTLVs in the Hello message That behaviour is a nice compromise between strict MTUchecking and making sure that the IS-IS router does not consume excess bandwidth intight WAN environments The brief Tcpdump output shows the JUNOS speciﬁc vari-ation in packet sizes during an IS-IS Adjacency bring up

Tcpdump output

20:16:37.411690 OSI, IS-IS, L1 Lan IIH, src-id 1921.6800.1002,

lan-id 1921.6800.1002.02, prio 64, length 1492

lan-id 1921.6800.1003.02, prio 64, length 65 20:16:37.418742 OSI, IS-IS, L2 Lan IIH, src-id 1921.6800.1002,

lan-id 1921.6800.1002.02, prio 90, length 65

The next few sections show how the IS-IS Protocol veriﬁes two-way connectivity over

a link From now on, the term handshaking is used as a replacement for “verifying

two-way connectivity” That is really all that handshaking means

Trang 13

5.3 Handshaking

In the IS-IS speciﬁcation there are two general ways of handshaking:

• 2-way handshake

• 3-way handshake

Figure 5.6 illustrates what occurs during a 2-way handshake IS-IS is started on Router

A A Hello message is sent to Router B As soon as Router B responds with a HelloMessage of its own, Router A will declare the Adjacency with Router B up The impor-tant aspect here is that Router A does not know if the Hello message from Router B is in

response to the Hello message that Router A sent or if it is just any Hello message that

Router B has generated (perhaps Router A’s Hello message has been lost on the link).There is no state that is kept That insight is signiﬁcant later when we explore a failureconditions resulting from a pure 2-way handshake check Of course the same procedure

is executed from Router B’s perspective as well The Router B perspective is not shown

in Figure 5.6, because the picture would have been too crowded and harder to stand But Router B of course also sends a Hello message and as soon as Router B

under-receives any Hello message from Router A, Router B will declare the adjacency up

Only two messages are necessary in the 2-way handshake The 3-way handshake worksdifferently

Handshaking 119

t t

Router B

Adjacency UP

IIH Router A misc TLVs

IIH Router B misc TLVs

IS-IS enabled

on the circuit

Router A Adjacency UP

Trang 14

Figure 5.7 shows a 3-way handshake transition Router A ﬁrst sends the Hello sage out, just as before Next, Router B responds with a Hello message Router A will

mes-know that this Hello was not sent by accident (in the 2-way case Router A never really

knows) because the Hello message from Router B carries an indication that this Hello

has been sent in response to Router A’s original Hello This is done by mentioning Router

A explicitly in the message body, by means of a special TLV Later, in the ﬁnite state

machine section such an event is described as Seenself Router B receives Router A’s

Hello message and now realizes that it has been seen by the neighbour (Router A) and

declares the adjacency up Router A now responds by sending a third Hello message

back to Router B conﬁrming that it has also seen Router B’s Hello message, which

causes Router B to declare the adjacency (from its perspective) now up as well The 3-way handshake is a stateful transition and much more robust than the simple 2-way

version, but does require an extra message

IS-IS uses different message elements and handshaking methods depending onwhether it is performing the handshaking on LAN or on point-to-point circuits The following section shows where and in which environment the different handshakingmethods are used, and what TLVs are encoded in the Hello messages to convey neigh-bour adjacency state in IS-IS

5.3.1 The 3-way Handshake on LAN Circuits

On LANs, IS-IS uses a 3-way handshake Figure 5.8 shows the state changes on the LANfrom Router A’s perspective Please note that for better visibility again, only the state

t t

Router B

Adjacency UP

IIH Router A misc TLVs

IIH Router B

“I have seen Router A”

&

IS-IS enabled

on the circuit

IIH Router A

“I have seen Router B”

&

Router A Adjacency UP

Định dạng
Số trang	30
Dung lượng	329,25 KB