Point-to-point Adjacency State TLV #240, length: 15 Adjacency State: Up (0) Extended Local circuit-ID: 0x00000041 Neighbor System-ID: 0000.0000.0003 Neighbor Extended Local circuit-ID: 0x0000005e Protocols supported TLV #129, length: 2 NLPID(s): IPv4 (0xcc), IPv6 (0x8e) IPv4 Interface address(es) TLV #132, length: 4 IPv4 interface address: 172.16.0.5 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 Both IOS and JUNOS support pseudonode suppression. In JUNOS you need to configure the point-to-point keyword inside the protocol isis interface {} stanza. JUNOS configuration In JUNOS pseudonode suppression is activated by adding the point-to-point keyword inside the protocols isis interface {} stanza. hannes@Stockholm> show configuration [… ] protocols { isis { [… ] interface ge-2/2/0.0 { point-to-point; } interface lo0.0; } } You can verify if the circuit was assigned to be a p2p media using the show isis interface command. JUNOS command output Once a broadcast circuit is configured for pseudonode suppression the Point to Point flag is listed instead of the DIS. hannes@Stockholm> show isis interface IS-IS interface database: Interface L CirID Level 1 DR Level 2 DR L1/L2 Metric [… ] ge-2/2/0.0 3 0x1 Point to Point Point to Point 10000/10000 lo0.0 0 0x1 Passive Passive 0/0 Pseudonodes 197 The IOS configuration is similar to JUNOS. Pseudonode suppression is once again an interface property and can be configured using the isis network point-to- point configuration statement. IOS configuration The IOS configuration requires the isis network point-to-point statement to sup- press pseudonodes. Amsterdam# show running-config [… ] ! interface GigabitEthernet0/0 ip address 172.16.26.170 255.255.255.0 ip router isis [… ] isis network point-to-point ! Unfortunately there is no explicit hint in IOS to display if the interface is actually run- ning in p2p mode. The only difference to a regular broadcast interface is that the DR ID line is missing in the output. IOS command output On a point-to-point network configuration the output of the show clns interface com- mand does omit the DR IDs. Amsterdam#show clns interface GigabitEthernet0/0 GigabitEthernet0/0 is up, line protocol is up Checksums enabled, MTU 1497, Encapsulation SAP ERPDUs enabled, min. interval 10 msec. CLNS fast switching disabled CLNS SSE switching disabled DEC compatibility mode OFF for this interface Next ESH/ISH in 30 seconds Routing Protocol: IS-IS Circuit Type: level-1-2 Interface number 0x6, local circuit ID 0x2 Neighbor System-ID: Stockholm Level-1 Metric: 10, Priority: 64, Circuit ID: Amsterdam.02 Number of active level-1 adjacencies: 1 Neighbor System-ID: Stockholm Level-2 Metric: 10, Priority: 64, Circuit ID: Amsterdam.02 Number of active level-2 adjacencies: 1 Next IS-IS LAN Level-1 Hello in 2 seconds Next IS-IS LAN Level-2 Hello in 1 seconds Another possibility is actually looking at the link-state database if one of the two routers on the LAN generates a pseudonode. 198 7. Pseudonodes and Designated Routers IOS command output The database output shows that there is no pseudonode generated by either the Stockholm or Amsterdam router in the database. Additional evidence is that the two routers did link their adjacencies directly (targeting the .00 incarnation) to each other. Amsterdam#show isis database detail IS-IS Level-1 Link State Database LSPID LSP Seq Num LSP Checksum LSP Holdtime ATT/P/OL Amsterdam.00-00 * 0x0000019A 0xF613 818 0/0/0 Area Address: 49.0001 NLPID: 0xCC Router ID: 192.168.1.17 IP Address: 192.168.1.17 Hostname: Amsterdam Metric: 10 IS-Extended Stockholm.00 Metric: 10 IP 172.16.1.0/24 Metric: 0 IP 192.168.1.17/32 Stockholm.00-00 0x0000c1E9 0xE448 414 0/0/0 Area Address: 49.0001 NLPID: 0xCC Hostname: Stockholm Router ID: 192.168.1.8 IP Address: 192.168.1.8 Metric: 10 IS-Extended Amsterdam.00 Metric: 10 IP 172.16.1.0/24 Metric: 0 IP 192.168.1.8/32 The output reveals that no pseudonode is in the database and two routers are linked directly to each other as shown in the top right corner of Figure 7.10. If we allow pseudonode generation then we have silently assumed so far that there is a DIS on the LAN that generates the pseudonode on behalf of the LAN. Before that hap- pens a DIS needs to get elected. The following paragraph describes DIS election proced- ures and timing. 7.3 DIS and DIS Election Procedure The good news is that the DIS election procedure is a very simple process. Due to its state- less nature a receiving router can immediately determine the DIS on the LAN. For DIS elections there are two fields in the LAN IIH header (see Figure 5.2) that are relevant: • Priority field in the LAN-IIH • The Source SNPA (ϭMAC address) of the sender The Priority field is 7-bits wide and therefore Priority values between 0 and 127 can be configured. A Priority value of zero means that this system does not wish to become a DIS at all. In case there are many routers with the same Priority competing for the DIS DIS and DIS Election Procedure 199 then the Source SNPA (ϭ the MAC address) tie breaks. The system with the numerically highest source MAC address then wins the beauty contest. Each router computes the DIS locally after receipt of IIH messages by comparing it against its current DIS Priority and SNPA. For debugging purposes there is also a field in the LAN-IIH where each router on a LAN writes its current DIS belief. 7.3.1 Pre-emption The DIS is pre-emptive. That means, if a router with a higher Priority comes online it immediately resigns from DIS ownership. To document that it has resigned it puts the winning router’s Node-ID in its LAN-ID field. The following tcpdump output shows an example of how a router changes its LAN Priority and commences DIS ownership. Tcpdump output 21:51:17.716553 OSI, IS-IS, L1 Lan IIH, src-id 0000.0000.0002, lan-id 0000.0000.0002.02, prio 65, length 74 21:51:19.813231 OSI, IS-IS, L1 Lan IIH, src-id 0000.0000.0001, lan-id 0000.0000.0002.02, prio 64, length 56 21:51:20.583435 OSI, IS-IS, L1 Lan IIH, src-id 0000.0000.0002, lan-id 0000.0000.0002.02, prio 65, length 74 21:51:22.557163 OSI, IS-IS, L1 CSNP, src-id 0000.0000.0002, length 83 21:51:23.516664 OSI, IS-IS, L1 Lan IIH, src-id 0000.0000.0002, lan-id 0000.0000.0002.02, prio 65, length 74 21:51:24.193870 OSI, IS-IS, L1 Lan IIH, src-id 0000.0000.0001, lan-id 0000.0000.0001.02, prio 120, length 56 Router #1 changes the LAN priority from 64 to 120, and becomes the highest Priority router on the LAN 21:51:24.196787 OSI, IS-IS, L1 Lan IIH, src-id 0000.0000.0002, lan-id 0000.0000.0001.02, prio 65, length 74 21:51:24.197468 OSI, IS-IS, L1 LSP, lsp-id 0000.0000.0002.02-00, seq 0x00000017, lifetime 0s, length 43 Router #2 resigns and purges the old pseudonode 21:51:24.220793 OSI, IS-IS, L1 LSP, lsp-id 0000.0000.0002.00-00, seq 0x0000001b, lifetime 1199s, length 158 21:51:24.444682 OSI, IS-IS, L1 LSP, lsp-id 0000.0000.0001.00-00, seq 0x00000120, lifetime 1198s, length 210 21:51:24.473860 OSI, IS-IS, L1 LSP, lsp-id 0000.0000.0001.02-00, seq 0x00000004, lifetime 1198s, length 76 Router #1 & #2 re-link their LSPs to the new pseudonode 21:51:24.484541 OSI, IS-IS, L1 Lan IIH, src-id 0000.0000.0001, lan-id 0000.0000.0001.02, prio 120, length 56 21:51:26.773307 OSI, IS-IS, L1 Lan IIH, src-id 0000.0000.0001, lan-id 0000.0000.0001.02, prio 120, length 56 200 7. Pseudonodes and Designated Routers 21:51:29.373384 OSI, IS-IS, L1 Lan IIH, src-id 0000.0000.0001, lan-id 0000.0000.0001.02, prio 120, length 56 21:51:30.963776 OSI, IS-IS, L1 Lan IIH, src-id 0000.0000.0002, lan-id 0000.0000.0001.02, prio 65, length 74 21:51:31.773442 OSI, IS-IS, L1 Lan IIH, src-id 0000.0000.0001, lan-id 0000.0000.0001.02, prio 120, length 56 21:51:32.893696 OSI, IS-IS, L1 CSNP, src-id 0000.0000.0001, length 83 The new DIS (Router #1) sends a full CSNP report 7.3.2 Purging After Router #2 resigns from ownership it purges its pseudonode. Purging means remov- ing from the database. A new DIS has been elected and therefore the DIS wants to clean up its remnants. A purged LSP contains nothing but the LSP header (and optionally authentication information if configured). Both the Lifetime and Checksum fields are set to zero. Both are illegal values. The Fletcher Checksumming Algorithm and the Lifetime can never become zero for a regular LSP packet. Tcpdump output A purged pseudonode LSP contains nothing but the LSP header and the Checksum and Lifetime fields are set to zero. 01:34:01.544481 OSI, IS-IS, length: 43 L1 LSP, hlen: 27, v: 1, pdu-v: 1, sys-id-len: 6 (0), max-area: 3 (0) lsp-id: 0000.0000.0002.02-00, seq: 0x00000001, lifetime: 0s chksum: 0x0000 (purged), PDU length: 27, L1L2 IS Purging is described in more detail in Chapter 6 “Generating, Flooding and Ageing LSPs”. The DIS ID can be easily spotted on JUNOS routers using the show isis inter- face detail command. JUNOS command output The last column of the show isis interface detail output lists the designated routers for each level on that LAN circuit. hannes@Stockholm> show isis interface detail IS-IS interface database: ge-2/2/0.0 Index: 64, State: 0x6, Circuit id: 0x2, Circuit type: 3 LSP interval: 100 ms, CSNP interval: 10 s DIS and DIS Election Procedure 201 Level Adjacencies Priority Metric Hello (s) Hold (s) Designated Router 1 2 120 10 3.000 9 Stockholm.02 (us) 2 2 64 10 9.000 27 Amsterdam.02 (not us) [… ] On IOS the DIS is revealed using the show clns interface command. IOS command output If the interface is not configured in p2p mode then for each active broadcast circuit a DIS is listed in the DR ID line. Amsterdam#show clns interface GigabitEthernet0/0 GigabitEthernet0/0 is up, line protocol is up Checksums enabled, MTU 1497, Encapsulation SAP ERPDUs enabled, min. interval 10 msec. CLNS fast switching disabled CLNS SSE switching disabled DEC compatibility mode OFF for this interface Next ESH/ISH in 30 seconds Routing Protocol: IS-IS Circuit Type: level-1-2 Interface number 0x6, local circuit ID 0x2 Neighbor System-ID: Stockholm Level-1 Metric: 10, Priority: 64, Circuit ID: Amsterdam.02 DR ID: Stockholm.02 Number of active level-1 adjacencies: 1 Neighbor System-ID: Stockholm Level-2 Metric: 10, Priority: 64, Circuit ID: Amsterdam.02 DR ID: Amsterdam.02 Number of active level-2 adjacencies: 1 Next IS-IS LAN Level-1 Hello in 2 seconds Next IS-IS LAN Level-2 Hello in 1 seconds Unlike OSPF there is just one DIS per LAN. This is often perceived as a disadvan- tage. However, the IS-IS protocol allows some clever trickery to become at the end more resilient than a OSPF Designated Router (DR) / Backup Designated Router (BDR) pair. 7.3.3 DIS Redundancy In IS-IS there is no DIS redundancy. If the Adjacency to the DIS times out then a new DIS needs to be elected. The re-election can be done immediately as zero state is involved. So the upper bound is detection that the DIS went down. A JUNOS router does a nice trick once it becomes the DIS: it reduces its hold time by a factor of three. The default Hold timer in JUNOS is 27 s. Once the router commences as DIS the hold-time becomes 9 s. 202 7. Pseudonodes and Designated Routers Because of the hard-coded Hello-Multiplier of 3 the Hellos are scheduled at 3-second intervals. There is no similar function in the IOS Implementation of IS-IS. Tcpdump output The DIS (0000.0000.0001.02) sends its Hellos three times as fast as the other router. 02:40:10.009492 OSI, IS-IS, L1 Lan IIH, src-id 0000.0000.0001, lan-id 0000.0000.0001.02, prio 120, length 62 02:40:12.879672 OSI, IS-IS, L1 Lan IIH, src-id 0000.0000.0001, lan-id 0000.0000.0001.02, prio 120, length 62 02:40:15.509631 OSI, IS-IS, L1 Lan IIH, src-id 0000.0000.0001, lan-id 0000.0000.0001.02, prio 120, length 62 02:40:16.227864 OSI, IS-IS, L1 Lan IIH, src-id 0000.0000.0002, lan-id 0000.0000.0001.02, prio 65, length 80 02:40:17.789689 OSI, IS-IS, L1 Lan IIH, src-id 0000.0000.0001, lan-id 0000.0000.0001.02, prio 120, length 62 02:40:20.239755 OSI, IS-IS, L1 Lan IIH, src-id 0000.0000.0001, lan-id 0000.0000.0001.02, prio 120, length 62 02:40:22.619829 OSI, IS-IS, L1 Lan IIH, src-id 0000.0000.0001, lan-id 0000.0000.0001.02, prio 120, length 62 02:40:23.847965 OSI, IS-IS, L1 Lan IIH, src-id 0000.0000.0002, lan-id 0000.0000.0001.02, prio 65, length 80 02:40:24.889888 OSI, IS-IS, L1 Lan IIH, src-id 0000.0000.0001, lan-id 0000.0000.0001.02, prio 120, length 62 02:40:27.429931 OSI, IS-IS, L1 Lan IIH, src-id 0000.0000.0001, lan-id 0000.0000.0001.02, prio 120, length 62 02:40:29.690077 OSI, IS-IS, L1 Lan IIH, src-id 0000.0000.0001, lan-id 0000.0000.0001.02, prio 120, length 62 02:40:31.828099 OSI, IS-IS, L1 Lan IIH, src-id 0000.0000.0002, lan-id 0000.0000.0001.02, prio 65, length 80 The DIS is tuning itself to provide faster resiliency. With 9 seconds of detecting that the DIS is broken and no state for the re-election IS-IS is far more superior than OSPF even without a Backup Designated Router. The DIS convergence is only dependend of the dead interval (hold-timer) of the old DIS. Unlike IS-IS, OSPF cannot set its dead-interval to an arbitrary value because all those values need to match on a given LAN. Arguably one could tune down all the OSPF Hello and Dead timers but that would increase the stress on the LAN by a factor of three to get comparable results. 7.4 Summary Broadcast interfaces like Ethernet are becoming increasingly popular as router-to-router link technology. Both multipoint and point-to-point setups have unique requirements to the IS-IS protocol. In a multipoint environment careful Hello scheduling and applying of jitter needs to be performed to avoid peak-stress through self-synchronization. Because DIS and DIS Election Procedure 203 of storage requirements and LSP churn avoidance the LAN needs to get nodal represen- tation as a pseudonode. The pseudonode is deterministically elected and generates the pseudonode on behalf the LAN circuit which cannot speak for itself. In multipoint setups the pseudonode functionality generates more overhead than gain and is often required to be turned off. A recent Internet draft describes how to build point- to-point adjacency on a 2-party LAN circuit without pseudonode generation. 204 7. Pseudonodes and Designated Routers 9 Fragmentation Modern communication relies on packet networks. On each layer in the OSI reference model a message from higher layers needs to get packetized by lower layers. The under- lying packet switching hardware that finally transports the frames across the Internet has most certain packet size constraints. Ethernet is a good example for these constraints, by not allowing individual packets to be bigger than 1518 bytes. Each layer in the OSI Reference Model needs to deal with the fundamental question: how will messages that do not fit the transport circuit packet be transported? In this chapter you will see some exam- ples how IP and the IS-IS routing protocol solves the underlying problem by chopping messages into pieces and reassembling them at the receiver. Additionally the side effects of such chopping and reassembly techniques, which have been observed in big operational networks, will be highlighted. 9.1 Fragmentation and the OSI Reference Model The OSI Reference Model relies on a layering technique. The purpose of the layering architecture is to hide the actual packet transport infrastructure from the driving application. The result is that the application does not need to care what packet-switching hardware, even what network protocol is used to convey the applications message as long as the receiver on the other end can de-multiplex the layering of message. The Transmission Control Protocol (TCP) is a good example for this. Figure 9.1 shows an example application like the Simple Mail Transfer Protocol (SMTP). SMTP relies on TCP for doing end-to-end flow control, re-sequencing and retransmission. TCP is dependent on a networking pro- tocol like IPv4 or IPv6 to get packets finally relayed from Client A to Server B. During its journey from Client A to Client B the packet will be transported using various layers of Layer-2 transport networks such as (but not limited to) Ethernet, SONET/SDH, Frame Relay, ATM. If you take a look how the original message (the email) is packaged into finally Ethernet, or SONET/SDH frames, you will notice that the message first is split by the transport pro- tocol. Splitting the original application stream is necessary to get packets from streams which finally get packaged and repackaged several times. Think of it like putting a letter in an envelope, which is then put in a larger envelope, which is put in a larger envelope until the packet finally gets delivered. The envelope analogy works also when it comes down to frame sizes. When you want to put a message in an envelope then the envelope has to be larger for the message to fit into. 223 OSI Reference Model Layer 2 Network Layer (IPv4, IPv6) Transport ϩ Session Layer (TCP) MAC Layer (802.3, Frame Relay, ATM, PPP) Physical Layer (Gigabit Ethernet, SONET/SDH) OSI Reference Model Layer 1 Application ϩ Representation Layer (SMTP) OSI Reference Model Layer 3 OSI Reference Model Layer 4 ϩ 5 OSI Reference Model Layer 6 ϩ7 Email message (36.5 KB) Chop into 25 segments and prepend 20 bytes TCP header Prepend 20 bytes IP header Prepend 14 bytes Ethernet header ϩ CRC32 Prepend 8 bytes Ethernet Preamble IP Packet (1500 bytes) TCP Segment (1480 bytes) Ethernet Packet (1518 bytes) Ethernet Frame (1526 bytes) F IGURE 9.1. An SMTP character stream of data gets prepended by header information at all layers to properly transport it across the IP infrastructure. For proper chopping the transport protocol needs to know the MTU of the underlying pack et transport infrastructure 224 . all. In case there are many routers with the same Priority competing for the DIS DIS and DIS Election Procedure 199 then the Source SNPA (ϭ the MAC address) tie breaks. The system with the numerically highest. output The database output shows that there is no pseudonode generated by either the Stockholm or Amsterdam router in the database. Additional evidence is that the two routers did link their adjacencies. two fields in the LAN IIH header (see Figure 5.2) that are relevant: • Priority field in the LAN-IIH • The Source SNPA (ϭMAC address) of the sender The Priority field is 7-bits wide and therefore Priority