1. Trang chủ
  2. » Công Nghệ Thông Tin

The Complete IS-IS Routing Protocol- P15 ppsx

10 207 0

Đang tải... (xem toàn văn)

THÔNG TIN TÀI LIỆU

Thông tin cơ bản

Định dạng
Số trang 10
Dung lượng 150,82 KB

Nội dung

Router A Router B circuit #1 circuit #2 I have an adjacency with Router B on circuit #1 I have an adjacency with Router A on circuit #2 1 Tx Rx Tx Rx Rx Tx Rx Tx 2 3 4 5 F IGURE 5.12. Two reported unidirectional LSP advertisements make other routers think that there is a single bi-directional adv ertisement 127 5.3.3 The 3-way Handshake on Point-to-point Circuits In LAN environments, the IS Neighbour TLV #6 does convey the information elements needed for performing the 3-way handshaking function. Unfortunately, this specific TLV is tailored to LAN environments only. Recall that the information elements to transport the “Hello, I have seen you” message is the SNPA,a MAC address. MAC addresses are typical to broadcast circuits such as, Ethernet, however, the typical WAN OSI-RM Layer 2 protocols like PPP, Cisco-HDLC, Frame-Relay, or ATM RFC 1483-SNAP, do not have the notion of MAC addresses. All of those WAN protocols are optimized for point-to- point environments where MAC addressing is not used or necessary. Typically the WAN protocols just need to frame a packet and transmit it to the remote end. Addressing is not needed because there are just two speakers on the circuit: the remote router and the local router. Fortunately, there is an extension to the base ISO 10589 specification, RFC 3373, that specifies an optional TLV that carries adjacency states and a few other information elements in a special TLV. The Adjacency State TLV #240 is discussed in the next section. 5.3.3.1 Adjacency State TLV #240 The main purpose of transporting adjacency states is to find out if the Hello message that a router has received was sent in response to receipt of a previous Hello, or is just any Hello sent by the remote router. If a router detects that the Hello received was sent in response to a previous Hello message sent, it is safe to assume the routers are on a work- ing, bi-directional circuit. This excludes the set of problems previously discussed that resulted from the presence of unidirectional circuits. Figure 5.13 shows the structure of the Adjacency State TLV #240 TLV. The TLV is a variable length and can span 1, 5, 11 or 15 bytes. The minimum length is 1 byte. The first byte conveys the current state of the adjacency, which can be one of three values: • 0x2 Down • 0x1 Initializing • 0x0 Up 128 5. Neighbour Discovery and Handshaking TLV Type TLV Length Adjacency State 240 Bytes 1 1 1 1, 5, 11, 15 Extended Local Circuit-ID 4 Neighbour System-ID 6 Neighbour Extended Local Circuit-ID 4 Optional FIGURE 5.13. The second part of the Adjacency State TLV is optional Figure 5.14 shows how the TLV content is changed during a 3-way handshake. Here is how the TLV works in the 3-way handshake: 1. Router A send a Hello reporting the adjacency as Down 2. Router B replies to Router A’s Hello. Router B tells Router A that this particular Hello message was generated in response to Router A’s previous Hello message by setting the Adjacency State to Initializing. Router A now knows that the circuit is truly bi-directional and declares the adjacency Up. 3. Router A sends a Hello back to Router B setting the Adjacency State to Up which causes Router B to declare the adjacency up on the Router B side as well. There are two different flavours of the Adjacency TLV deployed in the field. The first one is derived from one of the first Internet drafts before the document was extended and finally went to RFC state. The early version is a crippled version which just carries a single byte adjacency state. The more recent flavour implements the full 15 bytes of RFC 3373. From the router’s debug logs and show commands you cannot tell if you receive the single or 15-byte version. Tcpdump is used to reveal the version received. Handshaking 129 tt Router A Router B Router B Adjacency UP IS-IS enabled on the circuit Router A Adjacency UP IIH Router B Adj. State TLV #240 “Initializing” IIH Router A Adj. State TLV #240 “Down” IIH Router A Adj. State TLV #240 “Up” FIGURE 5.14. JUNOS always sends the 15-byte version of TLV #240, IOS per default sends the 1-byte version and optionally the 15-byte version Tcpdump output Older versions of JUNOS and IOS only support the 1-byte Adjacency state TLV #240: 00:29:47.706711 OSI, IS-IS, length: 38 p2p IIH, hlen: 20, v: 1, pdu-v: 1, sys-id-len: 6 (0), max-area: 3(0) source-id: 1921.6809.0034, holding time: 27s, Flags: [Level 2 only] circuit-id: 0x01, PDU length: 38 Point-to-point Adjacency State TLV #240, length: 1 Adjacency State: Up Protocols supported TLV #129, length: 1 NLPID(s): IPv4 IPv4 Interface address(es) TLV #132, length: 4 IPv4 interface address: 172.16.5.156 Area address(es) TLV #1, length: 4 Area address (length: 3): 49.0001 Tcpdump output Recent versions of JUNOS and IOS support the fully fledged, 15-byte version of the Adjacency State TLV #240: 11:35:23.248504 OSI, IS-IS, length: 50 p2p IIH, hlen: 20, v: 1, pdu-v: 1, sys-id-len: 6 (0), max-area: 3 (0) source-id: 1921.6809.0034, holding time: 27s, Flags: [Level 2 only] circuit-id: 0x01, PDU length: 50 Point-to-point Adjacency State TLV #240, length: 15 Adjacency State: Up Extended Local circuit ID: 0x0000001a Neighbor SystemID: 2092.1113.4007 Neighbor Extended Local circuit ID: 0x0000005f Protocols supported TLV #129, length: 1 NLPID(s): IPv4 IPv4 Interface address(es) TLV #132, length: 4 IPv4 interface address: 172.16.5.156 Area address(es) TLV #1, length: 4 Area address (length: 3): 49.0001 Wrapping just the Adjacency State (1 byte) inside the TLV and not adding the optional 14 bytes information only addresses the unidirectional link problem to some degree. One issue is still open: A router can never be 100% sure if a change in the adjacency state is targeted to the receiver itself. A broken or flapping (rapidly up and down) link in a SONET/SDH environment, which frequently terminates at two different routers, can make IS-IS blind spotted and causes the same problems that have been observed with the plain 2-way checks. This issue might seem very far-fetched or esoteric. But the IETF is known for deliver- ing pragmatic protocols that solve real problems. The fact that the Adjacency State TLV was revised in a later version of the draft that finally went into RFC 3373 to include the Neighbours System-ID so that the neighbour can be sure that a change of adjacency state 130 5. Neighbour Discovery and Handshaking was generated by receipt of the neighbour’s recent Hello message indicates that this was a real concern. If there was a state change by a neighbour and the Source-ID is not listed in the Neighbor Extended Local Circuit-ID field, then it was certainly not the receipt of the router’s Hello change that triggered the state change. Additionally, there was concern about the size (8 bits) of the Local Circuit-ID field in the point-to-point Hello message. Modern routers can be configured with literally thou- sands of interfaces (usually logical interfaces, but still interfaces) and so that field needed to be extended. TLV #240 transports 32-bit Local Circuit IDs, which should give any router plenty of Circuit-IDs for the time being. Normally routers insert the local interface index or SNMP index into this field. Contemporary JUNOS releases support the 15-byte version of TLV #240 only. In IOS you can control the emission of the 1-byte or 15-byte version using the isis three- way-handshake interface configuration option. IOS configuration The ietf option to the isis three-way-handshake configuration command emits the 15-byte version of TLV #240. The default parameter is the cisco option which generates the one-byte TLV payload. interface POS4/1 [… ] isis three-way-handshake ietf encapsulation ppp [… ] ! If an implementation follows ISO 10589 by the letter, then the expectation would be that after a completed 2-way or 3-way check, an adjacency goes into the Up state. However, this may not be the case. Most implementations perform additional checks before an adjacency is declared Up. 5.4 Sub-net Checking IS-IS is often expected to be a true multi-protocol IGP. Because adjacency formation, database synchronization and topology calculation (through SPF) is based on Layer-2 information, one would expect that it is entirely decoupled from any network layer dependencies. That assumption does not match the deployed reality. IS-IS routers indeed do verify that the next-hop the router is announcing is valid. The receiving router checks all occurrences of the Interface Address TLV #132 and also checks it against the list of local IP addresses configured on that circuit. Figure 5.15 shows the structure of the IP Interface Address TLV #132 which is a simple list of IP addresses that contains a router’s primary and secondary IP addresses. Both IOS and JUNOS verify that there is a common IP sub-net. If there is no common IP sub-net there is also no viable next-hop that can be entered in a routing table, and therefore the adjacency is considered invalid and stays in the Down / Initializing state. Sub-net Checking 131 There is unfortunately no show command in the router CLI that reports a sub-net mis- match. You need to turn on debugging in IOS and tracing in JUNOS to get any indication there is something wrong in this regard. In IOS, a sub-net mismatch can be detected once the isis adj-packets debug is turned on. In JUNOS, the trace option flag list needs to include the error flag. IOS debug output For IOS to detect sub-net mismatches the debug isis adj-packets needs to be turned on. Additionally you need to run terminal monitor to display the logging output on the vty. London#debug isis adj-packets IS-IS Adjacency related packets debugging is on London#terminal monitor Oct 26 22:33:11: ISIS-Adj: Sending serial IIH on POS4/1, length 4469 Oct 26 22:33:19: ISIS-Adj: Rec serial IIH from *PPP* (POS4/0), cir type L1L2, cir id 01, length 1492 Oct 26 22:33:19: ISIS-Adj: No usable IP interface addresses in serial IIH from POS4/0 JUNOS debug output For JUNOS to detect sub-net mismatches the flag error under the proto-cols isis traceoptions {} stanza needs to be configured. The logging messages will then be written into the specified IS-IS logfile (isis.log) hannes@Frankfurt> show log isis.log Oct 26 22:16:13 trace_on: Tracing to “/var/log/isis.log” started [… ] Oct 26 22:33:43 ISIS L3 periodic xmit to interface so-0/2/2.0 Oct 26 22:33:45 ISIS L3 hello from 1921.6800.1068 interface so-0/2/2.0 absorbed Oct 26 22:33:45 ISIS ERROR: IIH from 1921.6800.1068 without matching address, interface so-0/2/2.0 132 5. Neighbour Discovery and Handshaking TLV Type TLV Length IP Address 132 Bytes 1 1 4 4 N * 4 IP Address FIGURE 5.15. The contents of the Interface Address TLV #132 are matched against the local IP address to check if there is a matching sub-net After the sub-net check is positive, and there are no other configuration mismatches, such as misaligned authentication strings or circuit types and levels, the adjacency should go to the Up state. The transition from Down to Up does not occur immediately after receipt of a valid IIH message. There are some intermediate states in between, and there is also some damping logic involved, which makes sure that the network is not overwhelmed because of a flappy link. The next section is about the adjacency finite state machine and hold down logic of adjacencies. 5.5 Finite State Machine Most routing protocols maintain a finite state machine (FSM) for neighbour manage- ment. The FSM is a graph that describes steady states and the events that enable transi- tions from one state to another. In Figure 5.16 there is a FSM for a 2-way handshake. The three states are: • Down • New • Up A receipt of a valid (level, area and authentication needs to match) IIH transitions from Down to New and finally to Up. A mismatch of level, area and authentication, or a time- out of interface down events immediately transitions the adjacency from Up to Down. Two-way adjacencies and hence 2-way state machines are an anachronism (as demon- strated by the previous examples) and are deprecated today. Figure 5.17 shows the FSM for the 3-way handshake. Finite State Machine 133 Adj. Timeout Intf. Down bogus System-ID Area Mismatch Level Mismatch rcvd IIH Adj. Timeout Intf. Down bogus System-ID Area Mismatch Level Mismatch rcvd IIH rcvd IIH Up New Down FIGURE 5.16. The finite state machine for a 2-way adjacency (deprecated) The 3-way handshake encompasses four states: • Down • New • Init • Up The additional Init state has been created for 3-way handshake functionality. Upon receipt of a valid IIH, the adjacency is moved to the Init state. From there a Seenself event is necessary to proceed to an Up state. The Seenself event can be an Adjacency State of 1 (Init) as part of the Adjacency State TLV #240, or the router’s own SNPA listed in the IS Neighbour TLV #6. As soon as an adjacency is declared Up the router needs to originate a LSP packet reporting the new adjacency to other routers in the network. A good IS-IS implementation tries to protect other routers from locally flapping adjacencies. That means if the local circuit is flapping at a high frequency, there is a risk that the entire network will be overwhelmed with LSPs. Both IOS and JUNOS use timers that artificially hold down 134 5. Neighbour Discovery and Handshaking Adj. Timeout Intf. Down bogus System-ID Area Mismatch Level Mismatch rcvd IIH && seenself rcvd IIH rcvd IIH && seenself rcvd IIH && seenself && hold down timer Adj. Timeout Intf. Down bogus System-ID Area Mismatch Level Mismatch Adj. Timeout Intf. Down bogus System-ID Area Mismatch Level Mismatch rcvd IIH rcvd IIH && seenself rcvd IIH Up Init Down New FIGURE 5.17. The Finite State Machine for a 3-way adjacency an adjacency that is about to enter the Up state for a limited amount of time. Typically those timers are in the range of 1–60 seconds depending on factors such as: • Flapping history • Amount of LSP traffic • Number of adjacencies per interface If an adjacency has flapped frequently in the past then it is highly likely that it will flap in the future too. It is safe to hold down adjacencies longer if they have a higher amount of transitions over time. JUNOS does, for example, measure the amount of LSPs that are transmitted through local interfaces. If the amount of LSPs is higher than one LSP per second then probably the network is shaky and it is not safe to contribute to further churn by announcing an additional LSP. Finally, a common action is to treat point-to-point or single adjacency LAN circuits better than LAN circuits with multiple adjacencies. The idea behind that is if there are some adjacencies already in the Up state then we are prob- ably in the middle of taking up a big LAN segment and there will be more changes to come. Waiting a little extra time here does not do a lot of harm but highly reduces the churn if a big LAN goes down. For high-resiliency routing, it is imperative how fast the router detects that an adja- cency is Down. In the FSM there are two events for Down transitioning: the adjacency timeout and interface down event. In the next section there is a short overview about IS-IS neighbour liveliness detection and how that impacts high-resiliency routing. 5.6 Neighbour Liveliness Detection The Internet has evolved from an academic playground to a business-critical infrastruc- ture. Customers and their Internet service providers are keen to tune the convergence speed in case a backup circuit has to be engaged. The most dominant element for con- vergence behaviour is neighbour liveliness detection. Today there are several options to detect if a circuit to an adjacent router is still able to deliver packets: • IGP Hellos • Interface Tracking • LMI Protocol The two major IS-IS implementations treat all three sources of information equally. 5.6.1 IGP Hellos The historical way of detecting that a neighbour is down is by tracking receipt of a neigh- bour’s Hello packets. That method has two disadvantages. First, on a busy router with many adjacencies the generation and receipt of hundreds of IIH messages may over- whelm the routing process. Second, many routing protocols do not support sub-second timers. Consider Figure 5.4, which displays a point-to-point IIH header. The Hold Time field is a discrete 16-bit field which supports timer values from 1–65535 seconds, but no sub-second timers. The same problem applies to the OSPF routing protocol: The Hello Neighbour Liveliness Detection 135 136 5. Neighbour Discovery and Handshaking and Dead timer there needs to be conveyed in the protocol. The lowest unit are once again seconds. One of the nice things about IS-IS has been that the Hello timer does not need to get encoded on the Hello message. The Hello timer is a purely local matter. The timer that gets transported using the IS-IS protocol is the hold timer which can go down to 1 second. The Hello timer is therefore a fraction of the hold timer. In IOS and JUNOS sub-second Hello timers are configured differently: IOS needs the keyword isis hello-interval minimal in its interface configuration. Depending on the isis-hello-multiplier value, IOS dispatches Hellos in frac- tions of this value. IOS configuration interface POS4/1 [… ] ip router isis encapsulation ppp [… ] isis hello-multiplier 5 level-1 isis hello-interval minimal level-1 ! Unfortunately, IS-IS has no show command to display its sub-second timers. The fol- lowing Tcpdump output monitors the arrival times of the point-to-point IIH messages. Note that they are all spaced within 200 ms Ϫ a random jitter. Tcpdump output 19:15:15.246711 In OSI IS-IS, p2p IIH, length: 4469 19:15:15.440708 In OSI IS-IS, p2p IIH, length: 4469 19:15:15.700683 In OSI IS-IS, p2p IIH, length: 4469 19:15:15.896695 In OSI IS-IS, p2p IIH, length: 4469 19:15:15.1082736 In OSI IS-IS, p2p IIH, length: 4469 In JUNOS, all you can configure is the hold timer. Set it to 1 second and the system dispatches Hellos at the hold-timer/3 frequency. Note that on point-to-point media you need to configure the hold-time to the same value on both IS-IS levels otherwise the sys- tem will use the default hold-time values of 27 seconds. The reason for this behaviour is the sharing of the Hello message between both levels. JUNOS configuration protocols { isis { [… ] interface so-0/1/2.0 { level 1 hold-time 1; level 2 hold-time 1; . configure the hold-time to the same value on both IS-IS levels otherwise the sys- tem will use the default hold-time values of 27 seconds. The reason for this behaviour is the sharing of the Hello. field, then it was certainly not the receipt of the router’s Hello change that triggered the state change. Additionally, there was concern about the size (8 bits) of the Local Circuit-ID field in the. transmit it to the remote end. Addressing is not needed because there are just two speakers on the circuit: the remote router and the local router. Fortunately, there is an extension to the base ISO

Ngày đăng: 03/07/2014, 19:20

TỪ KHÓA LIÊN QUAN