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
Trang 1Point-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 interfacecommand
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
Trang 2The IOS configuration is similar to JUNOS Pseudonode suppression is once again an interface property and can be configured using the isis network point-to-pointconfiguration 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
Trang 3IOS 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
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
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
Trang 4then 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
Trang 521: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 detailcommand
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
Trang 6Level 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
Trang 7Because 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
Trang 8of 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
Trang 9Fragmentation
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
Trang 10OSI Reference Model Layer 2
Ethernet Packet (1518 bytes) Ethernet Frame (1526 bytes) FIGURE
224