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

The Complete IS-IS Routing Protocol- P22 pptx

10 347 0
Tài liệu đã được kiểm tra trùng lặp

Đ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 119,03 KB

Các công cụ chuyển đổi và chỉnh sửa cho tài liệu này

Nội dung

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 1

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 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 2

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-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 3

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

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 4

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

Trang 5

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 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 6

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

Trang 7

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

Trang 8

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

Trang 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

Trang 10

OSI Reference Model Layer 2

Ethernet Packet (1518 bytes) Ethernet Frame (1526 bytes) FIGURE

224

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