Inhalt

Einleitung

Hintergrundinformationen

Auffüllen von TLVs

Beispiel für das Auffüllen von TLV

Kein Hello-Padding

Kein Hello-Padding immer

Problem mit IS-IS und Schnittstellen-MTU

IS-IS-Flooding

Änderungen an der MTU

Hello Padding aktiviert

Hello-Padding deaktiviert

Wichtige Hinweise

Einleitung

In diesem Dokument wird das Verhalten von Integrated Intermediate System-to-Intermediate System (IS-IS) Hello-Paketpolsterung im Cisco IOS® beschrieben.

Hintergrundinformationen

Der IS-IS leitet die Hello-Pakete standardmäßig an die vollständige Maximum Transmission Unit (MTU) der Schnittstelle weiter. Dadurch werden MTU-Diskrepanzen erkannt. Die MTU auf beiden Seiten der Verbindung sollte übereinstimmen. Der Padding kann auch verwendet werden, um den tatsächlichen MTU-Wert der Technologie zu erkennen, die darunter liegt. Bei Layer-2-Transport (L2) über Multiprotocol Label Switching (MPLS)-Szenarien kann die MTU der Transporttechnologie beispielsweise deutlich niedriger sein als die MTU am Edge. Beispielsweise kann die MTU am Edge 9.000 Byte betragen, während die MPLS-Transporttechnologie eine MTU von 1.500 Byte hat.

Wenn die MTU-Werte auf beiden Seiten übereinstimmen, kann die Füllung deaktiviert werden. Dadurch kann die unnötige Ausnutzung von Bandbreite und Puffern durch IS-IS Hello-Pakete vermieden werden. Der Router-Befehl, der zum Deaktivieren des Hello-Padding verwendet wird, ist kein Hello-Padding [multi-point|point-to-point]. Der Schnittstellenbefehl, der zum Deaktivieren des Hello-Padding verwendet wird, lautet no isis hello-padding.

Wenn das Padding zu Beginn deaktiviert ist, sendet der Router immer noch Hello-Pakete mit voller MTU. Um dies zu vermeiden, deaktivieren Sie das Padding mit dem Schnittstellenbefehl, und verwenden Sie das Schlüsselwort always. In diesem Fall werden nicht alle IS-IS Hello-Pakete aufgefüllt.

Anmerkung: Cisco empfiehlt, das IS-IS Hello-Padding nicht zu deaktivieren, um sicherzustellen, dass zwei Router eine IS-IS-Adjacency für eine Verbindung bilden, deren MTU-Werte auf beiden Seiten nicht übereinstimmen.

Auffüllen von TLVs

Die IS-IS Hello-Pakete haben einen Padding Type Length Value (TLV). Bei einem Point-to-Point (P2P) IH beträgt der TLV für die Füllung 8. Für den LAN IIH beträgt der TLV für die Füllung 8.

Beispiel für das Auffüllen von TLV

In diesem Abschnitt wird das Beispiel im folgenden Bild verwendet, um die MTU und die Deaktivierung der Hello-Füllung in IS-IS zu erklären:

In diesem Beispiel haben PE1 und PE2 einen Virtual Circuit (VC) 100 zwischen sich eingerichtet, um die Router R1 und R2 an L2 anzuschließen. Dieser VC ist ein Ethernet over MPLS (EoMPLS) VC.

PE1#show xconnect all

Legend:   XC ST=Xconnect State S1=Segment1 State S2=Segment2 State

UP=Up       DN=Down           AD=Admin Down     IA=Inactive

SB=Standby HS=Hot Standby     RV=Recovering     NH=No Hardware

XC ST Segment 1                         S1 Segment 2                         S2

------+---------------------------------+--+---------------------------------+--

UP pri   ac Se2/0(HDLC)                 UP mpls 10.100.1.5:100              UP

PE1#show mpls l2transport vc 100

Local intf     Local circuit             Dest address   VC ID     Status

------------- -------------------------- --------------- ---------- ----------

Se2/0         HDLC                      10.100.1.5     100       UP

Für Router R1 wird Folgendes ausgegeben:

interface Serial2/0

ip address 10.1.1.1 255.255.255.0

ip router isis 1

serial restart-delay 0

Für Router R2 wird Folgendes ausgegeben:

interface Serial2/0

ip address 10.1.1.2 255.255.255.0

ip router isis 1

serial restart-delay 0

Die Ausgabe des Befehls debug isis adj-packages debug liefert Informationen zur IS-IS-Adjacency:

R1#debug isis adj-packets

IS-IS Adjacency related packets debugging is on for router process 1

R1#

13:00:59.978: ISIS-Adj: Sending serial IIH on Serial2/0, 3way state:DOWN, length 1499

13:01:07.758: ISIS-Adj: Sending serial IIH on Serial2/0, 3way state:DOWN, length 1499

13:01:16.280: ISIS-Adj: Sending serial IIH on Serial2/0, 3way state:DOWN, length 1499

R2#

13:01:50.100: ISIS-Adj: Sending serial IIH on Serial2/0, 3way state:DOWN, length 1499

13:02:00.062: ISIS-Adj: Sending serial IIH on Serial2/0, 3way state:DOWN, length 1499

13:02:07.899: ISIS-Adj: Sending serial IIH on Serial2/0, 3way state:DOWN, length 1499

In diesem Szenario schlägt die IS-IS-Adjacency fehl.

R1#show isis neighbors

Tag 1:

System Id     Type Interface   IP Address     State Holdtime Circuit Id

R1#

R1#show clns interface Serial 2/0

Serial2/0 is up, line protocol is up

Checksums enabled, MTU 1500, Encapsulation HDLC

ERPDUs enabled, min. interval 10 msec.

CLNS fast switching enabled

CLNS SSE switching disabled

DEC compatibility mode OFF for this interface

Next ESH/ISH in 18 seconds

Routing Protocol: IS-IS

Circuit Type: level-1-2

Interface number 0x1, local circuit ID 0x101

Level-1 Metric: 10, Priority: 64, Circuit ID: R1.01

Level-1 IPv6 Metric: 10

Number of active level-1 adjacencies: 0

Next IS-IS Hello in 5 seconds

if state DOWN

Die MTU an den seriellen Schnittstellen für die Router R1 und R2 beträgt standardmäßig 1.500 Byte.

Die IS-IS-Adjacency schlägt fehl, da die IS-IS Hello-Pakete 1.499 Byte groß sind. Das MPLS-Netzwerk lässt nur Pakete mit 1.500 Byte zu, minus acht Byte (zwei MPLS-Labels für den MPLS-Service), was 1.492 Byte entspricht (die Paketgröße, die durchgelassen wird). Für den Transport von L2 über MPLS muss die Größe des L2-Headers von den ebenfalls resultierenden 1.492 Byte abgezogen werden.

Kein Hello-Padding

In diesem Szenario wird der Befehl no isis hello padding an der Schnittstelle von Serial2/0 auf dem Router R1 verwendet:

interface Serial2/0

ip address 10.1.1.1 255.255.255.0

ip router isis 1

serial restart-delay 0

no isis hello padding

R1#

13:03:46.712: ISIS-Adj: Sending serial IIH on Serial2/0, 3way state:DOWN, length 1499

13:03:54.717: ISIS-Adj: Sending serial IIH on Serial2/0, 3way state:DOWN, length 1499

13:04:03.057: ISIS-Adj: Sending serial IIH on Serial2/0, 3way state:DOWN, length 1499

13:04:11.538: ISIS-Adj: Sending serial IIH on Serial2/0, 3way state:DOWN, length 1499

13:04:21.301: ISIS-Adj: Sending serial IIH on Serial2/0, 3way state:DOWN, length 1499

13:04:30.636: ISIS-Adj: Sending serial IIH on Serial2/0, 3way state:DOWN, length 1499

13:04:39.958: ISIS-Adj: Sending serial IIH on Serial2/0, 3way state:DOWN, length 1499

Wie gezeigt werden mehr als fünf IS-IS Hello-Pakete mit voller MTU-Größe (1.497 Byte) gesendet. Der Router sendet die Hello-Pakete mit Padding weiter, bis die IS-IS-Adjacency aktiviert wird. Solange das MTU-Problem jedoch nicht behoben ist, wird die Adjacency nicht angezeigt.

Die MTU wird auf 1.400 Byte an der Schnittstelle Serial2/0 des Routers R1 gesenkt. Somit können Pakete mit bis zu 1.400 Byte sicher über den Pseudowire durch das MPLS-Netzwerk geleitet werden.

Für Router R1 wird Folgendes ausgegeben:

!

interface Serial2/0

mtu 1400

ip address 10.1.1.1 255.255.255.0

ip router isis 1

serial restart-delay 0

no isis hello padding

R1#

13:07:19.428: ISIS-Adj: Sending serial IIH on Serial2/0, 3way state:DOWN, length 1399

13:07:29.024: ISIS-Adj: Sending serial IIH on Serial2/0, 3way state:DOWN, length 1399

13:07:38.185: ISIS-Adj: Sending serial IIH on Serial2/0, 3way state:DOWN, length 1399

13:07:45.715: ISIS-Adj: Sending serial IIH on Serial2/0, 3way state:DOWN, length 1399

13:07:55.351: ISIS-Adj: Sending serial IIH on Serial2/0, 3way state:DOWN, length 1399

13:08:04.814: ISIS-Adj: Sending serial IIH on Serial2/0, 3way state:DOWN, length 1399

13:08:14.216: ISIS-Adj: Sending serial IIH on Serial2/0, 3way state:DOWN, length 1399

13:08:23.447: ISIS-Adj: Sending serial IIH on Serial2/0, 3way state:DOWN, length 1399

13:08:31.676: ISIS-Adj: Sending serial IIH on Serial2/0, 3way state:DOWN, length 1399

13:08:39.966: ISIS-Adj: Sending serial IIH on Serial2/0, 3way state:DOWN, length 1399

Der Router R1 überträgt die Hello-Pakete weiterhin mit Padding. Die Größe beträgt jetzt 1.400 Byte minus eins.

Sobald die MTU-Größe auf der Schnittstelle Serial 2/0 auf dem Router R2 verringert wurde, wird die Füllung deaktiviert.

Für Router R2 wird Folgendes ausgegeben:

interface Serial2/0

mtu 1400

ip address 10.1.1.2 255.255.255.0

ip router isis 1

serial restart-delay 0

Sobald der Router R1 erkennt, dass das IS-IS Hello-Paket vom Router R2 eingeht, ruft er die IS-IS-Adjacency auf. Da der Router R2 auch die IS-IS-Hello-Pakete vom Router R1 erkennt, wechselt die IS-IS-Adjacency schließlich in den UP-Status, d. h. es wird eine Dreiwege-Adjacency erstellt. An diesem Punkt senkt der Router R1 (bei deaktiviertem Hello-Padding an der Schnittstelle Serial 2/0) die Größe des Hello-Pakets auf das Minimum.

R1#

13:08:47.010: ISIS-Adj: Rec serial IIH from *HDLC* (Serial2/0), cir type L1, cir id 01,

length 1399

13:08:47.010: ISIS-Adj: newstate:1, state_changed:1, going_up:0, going_down:0

13:08:47.010: ISIS-Adj: Action = GOING UP, new type = L1

13:08:47.010: ISIS-Adj: New serial adjacency

13:08:47.010: ISIS-Adj: rcvd state INIT, old state DOWN, new state INIT, nbr usable TRUE

13:08:47.011: ISIS-Adj: Sending serial IIH on Serial2/0, 3way state:INIT, length 1399

13:08:47.055: ISIS-Adj: Rec serial IIH from *HDLC* (Serial2/0), cir type L1, cir id 01,

length 1399

13:08:47.055: ISIS-Adj: rcvd state UP, old state INIT, new state UP, nbr usable TRUE

13:08:47.056: ISIS-Adj: newstate:0, state_changed:1, going_up:1, going_down:0

13:08:47.056: ISIS-Adj: Action = GOING UP, new type = L1

13:08:47.056: ISIS-Adj: L1 adj count 1

13:08:47.056: ISIS-Adj: Sending serial IIH on Serial2/0, 3way state:UP, length 43

Wie dargestellt sendet der Router R1 ein IS-IS-Hello-Paket mit der Länge 43 und empfängt die Hello-Pakete vom Router R2 mit der Länge 1399. Dies liegt daran, dass die Hello-Auffüllung auf dem Router R2 weiterhin aktiv ist.

In diesem Beispiel wird die IS-IS-Adjacency nicht angezeigt, wenn auf beiden Seiten der Verbindung die MTU auf der Schnittstelle "Seriell 2/0" weiterhin auf 1.500 Byte festgelegt ist. Dies ist auch dann der Fall, wenn der Befehl no isis hello padding aktiviert ist. Die Schnittstelle wird erst aktiviert, nachdem die MTU auf beiden Seiten der Verbindung auf den richtigen Wert gesetzt wurde.

Wenn Sie also nur das IS-IS Hello-Padding deaktivieren, reicht es nicht aus, die IS-IS-Adjacency zu aktivieren. Die MTU muss niedrig genug sein, damit die IS-IS-Hello-Pakete in MTU-Größe von den Routern auf beiden Seiten der Verbindung richtig gesendet und empfangen werden.

Kein Hello-Padding immer

Bei einer MTU von 1.500 Byte an der Schnittstelle Serial2/0 auf dem Router R1 wird die Adjacency nicht aktiviert, da die übertragenen IS-IS Hello-Pakete immer noch die volle MTU-Größe aufweisen. Um dieses Problem zu umgehen, können Sie den Schnittstellenbefehl no isis hello padding always auf der Schnittstelle Serial2/0 konfigurieren, um das Padding always zu deaktivieren.

!

interface Serial2/0

ip address 10.1.1.1 255.255.255.0

ip router isis 1

serial restart-delay 0

no isis hello padding always

Sobald dieser Befehl konfiguriert ist, haben die IS-IS Hello-Pakete die Mindestgröße. Die IS-IS-Adjacency zwischen den Routern R1 und R2 wird sofort aktiviert.

R1#

13:25:47.284: ISIS-Adj: Sending serial IIH on Serial2/0, 3way state:INIT,

length 43, never pad

13:25:47.328: ISIS-Adj: Rec serial IIH from *HDLC* (Serial2/0), cir type L1,

cir id 01, length 1399

13:25:47.328: ISIS-Adj: rcvd state INIT, old state INIT, new state UP,

nbr usable TRUE

13:25:47.328: ISIS-Adj: newstate:0, state_changed:1, going_up:1, going_down:0

13:25:47.328: ISIS-Adj: Action = GOING UP, new type = L1

13:25:47.329: ISIS-Adj: L1 adj count 1

13:25:47.330: ISIS-Adj: Sending serial IIH on Serial2/0, 3way state:UP,

length 43, never pad

13:25:47.374: ISIS-Adj: Rec serial IIH from *HDLC* (Serial2/0), cir type L1,

cir id 01, length 1399

13:25:47.374: ISIS-Adj: rcvd state UP, old state UP, new state UP,

nbr usable TRUE

13:25:47.375: ISIS-Adj: newstate:0, state_changed:0, going_up:0, going_down:0

13:25:47.375: ISIS-Adj: Action = ACCEPT

13:25:47.375: ISIS-Adj: ACTION_ACCEPT:

Problem mit IS-IS und Schnittstellen-MTU

Wenn die Schnittstellen-MTU nicht übereinstimmt, wird die IS-IS-Adjacency nicht aktiviert. Um das Problem schnell zu beheben, können Sie das IS-IS Hello-Padding mit dem Schlüsselwort always deaktivieren. Dies könnte jedoch keine wirkliche Lösung sein.

Für Router R1 wird Folgendes ausgegeben:

interface Serial2/0

ip address 10.1.1.1 255.255.255.0

ip router isis 1

serial restart-delay 0

no isis hello padding always

Die IS-IS-Adjacency ist aktiv.

R1#show isis neighbors

Tag 1:

System Id     Type Interface   IP Address     State Holdtime Circuit Id

R2             L1   Se2/0       10.1.1.2       UP   22       01

Hier ist ein Ping, der vom Router R1 an den Router R3 gesendet wird, um den Datenverkehr zu überprüfen, der über die Verbindung läuft:

R1#ping 10.100.1.3 source 10.100.1.1 size 1400 repeat 1

Type escape sequence to abort.

Sending 1, 1400-byte ICMP Echos to 10.100.1.3, timeout is 2 seconds:

Packet sent with a source address of 10.100.1.1

!

Success rate is 100 percent (1/1), round-trip min/avg/max = 44/44/44 ms

R1#ping 10.100.1.3 source 10.100.1.1 size 1500 repeat 1

Type escape sequence to abort.

Sending 1, 1500-byte ICMP Echos to 10.100.1.3, timeout is 2 seconds:

Packet sent with a source address of 10.100.1.1

.

Success rate is 0 percent (0/1)

Wie gezeigt, kommen Pakete mit einer Größe von 1.500 Byte nicht durch. Der Grund hierfür ist, dass der Router R1 glaubt, dass die MTU 1.500 Byte auf der Schnittstelle Serial2/0 beträgt:

R1#show interfaces Serial2/0

Serial2/0 is up, line protocol is up

Hardware is M4T

Internet address is 10.1.1.1/24

MTU 1500 bytes, BW 1544 Kbit/sec, DLY 20000 usec,

reliability 255/255, txload 1/255, rxload 1/255

Encapsulation HDLC, crc 16, loopback not set

Keepalive set (10 sec)

Restart-Delay is 0 secs

Last input 00:00:01, output 00:00:01, output hang never

Last clearing of "show interface" counters never

Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0

Queueing strategy: weighted fair

Output queue: 0/1000/64/0 (size/max total/threshold/drops)

Conversations 0/1/256 (active/max active/max total)

Reserved Conversations 0/0 (allocated/max allocated)

Available Bandwidth 1158 kilobits/sec

5 minute input rate 0 bits/sec, 0 packets/sec

5 minute output rate 0 bits/sec, 0 packets/sec

590 packets input, 283131 bytes, 0 no buffer

Received 567 broadcasts (0 IP multicasts)

0 runts, 0 giants, 0 throttles

0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort

693 packets output, 313789 bytes, 0 underruns

0 output errors, 0 collisions, 2 interface resets

0 unknown protocol drops

0 output buffer failures, 0 output buffers swapped out

3 carrier transitions     DCD=up DSR=up DTR=up RTS=up CTS=up

Wenn die MTU auf 1.400 Byte an der Schnittstelle Serial2/0 verringert wird, kann der Router R1 die Pakete fragmentieren, wenn für die Pakete nicht das DF-Bit (Do Not fragment) festgelegt ist. Wenn für die Pakete das DF-Bit festgelegt ist, kann der Router eine ICMP 3/4-Nachricht zurücksenden, die von der Path MTU Discovery verwendet wird. Dadurch kann der Absender der Pakete die Größe der von ihm gesendeten Pakete verringern. Die richtige Einstellung der MTU ist wichtig für den Datenverkehr, der den Router passiert, aber auch für den Datenverkehr, der vom Router stammt und diese Verbindung kreuzt. Ein Beispiel hierfür ist das Border Gateway Protocol (BGP), das TCP verwendet und die MTU-Pfaderkennung verwenden kann.

IS-IS-Flooding

Um das IS-IS-Adjacency-Problem zu beheben, kann der Netzwerkbetreiber das Hello-Padding mit dem Schlüsselwort always deaktivieren. Die MTU der seriellen Verbindung bleibt bei 1.500 Byte.

Es gibt immer noch das Problem der IS-IS-Überschwemmungen. Wenn die IS-IS-Datenbank klein ist, gibt es kein Problem.

R1#debug isis update-packets

IS-IS Update related packet debugging is on for router process 1

Wenn der Router R3 ein Präfix hinzufügt und dieses überflutet, empfängt der Router R1 den Router R3 Link State PDU (LSP) vom Router R2.

R1#

*Nov 19 13:53:58.227: ISIS-Upd: Rec L1 LSP 0000.0000.0003.00-00, seq B, ht 1197,

*Nov 19 13:53:58.227: ISIS-Upd: from SNPA *HDLC* (Serial2/0)

*Nov 19 13:53:58.227: ISIS-Upd: LSP newer than database copy

*Nov 19 13:53:58.227: ISIS-Upd: TLV contents different, code 130

*Nov 19 13:53:58.228: ISIS-Upd: TID 0 leaf routes changed

Wenn die Anzahl der Präfixe zunimmt, die vom Router R3 gemeldet werden, ist der LSP des Routers R3 so groß, dass er in mehrere Fragmente aufgeteilt wird:

R3#show isis database

Tag 1:

IS-IS Level-1 Link State Database:

LSPID               LSP Seq Num LSP Checksum LSP Holdtime     ATT/P/OL

R1.00-00             0x0000000C   0x5931       1137             0/0/0

R2.00-00             0x0000000B   0xCB7D       1162             0/0/0

R3.00-00           * 0x0000000D   0xF637       1104             0/0/0

R3.00-01           * 0x00000001   0x6AD8       1104             0/0/0

R3.00-02           * 0x00000001   0xB58A       1104             0/0/0

R3.01-00           * 0x00000002   0x9BB1       387              0/0/0

Tag null:

Das R3.00-00 ist das erste Fragment, das R3.00-01 das zweite Fragment usw.

R2#

14:22:15.584: ISIS-Upd: Retransmitting L1 LSP 0000.0000.0003.00-00 on Serial2/0

14:22:15.624: ISIS-Upd: Sending L1 LSP 0000.0000.0003.00-00, seq E, ht 467 on

Serial2/0

14:22:18.352: ISIS-Snp: Rec L1 CSNP from 0000.0000.0003 (Ethernet1/0)

14:22:20.625: ISIS-Upd: Retransmitting L1 LSP 0000.0000.0003.00-00 on Serial2/0

14:22:20.657: ISIS-Upd: Sending L1 LSP 0000.0000.0003.00-00, seq E, ht 462 on

Serial2/0

Dies ist der LSP, der vom Router R2 über die Schnittstelle Serial2/0 erneut übertragen wird. Die PDU-Länge beträgt 1.490 Byte, sodass die Größe dieses Pakets nicht zulässt, dass es den Router R1 erreicht.

Während die IS-IS-Adjacency zwischen den Routern R1 und R2 aktiv ist, weist der Router R1 in seiner Routing-Tabelle weniger IP-Präfixe auf:

R1#show isis neighbors

Tag 1:

System Id     Type Interface   IP Address     State Holdtime Circuit Id

R2             L1   Se2/0       10.1.1.2       UP   25       01

R2#show isis neighbors

Tag 1:

System Id     Type Interface   IP Address     State Holdtime Circuit Id

R1             L1   Se2/0       10.1.1.1       UP   26       01

R3             L1   Et1/0       10.1.2.3       UP   8        R3.01

R2#show ip route summary

IP routing table name is default (0x0)

IP routing table maximum-paths is 32

Route Source   Networks   Subnets     Replicates Overhead   Memory (bytes)

connected       0           5           0           360         900

static          0           0           0           0           0

application     0           0           0           0           0

isis 1          0           252         0           18144       45360

Level 1: 252 Level 2: 0 Inter-area: 0

internal        1                                               10620

Total           1           257         0           18504       56880

R1#show ip route summary

IP routing table name is default (0x0)

IP routing table maximum-paths is 32

Route Source   Networks   Subnets     Replicates Overhead   Memory (bytes)

connected        0           3           0           216         540

static           0           0           0           0           0

application      0           0           0           0           0

isis 1           0           2           0           144         360

Level 1: 2 Level 2: 0 Inter-area: 0

internal          1                                              560

Total           1           5           0           360         1460

Dies liegt daran, dass der LSP R3.00-00 vom Router R3 nicht den Router R1 erreicht.

R3#show isis database

Tag 1:

IS-IS Level-1 Link State Database:

LSPID                 LSP Seq Num LSP Checksum LSP Holdtime     ATT/P/OL

R1.00-00             0x0000000E   0x5533       1009              0/0/0

R2.00-00             0x0000000C   0xC97E       453               0/0/0

R3.00-00           * 0x0000000F   0xF239       1045              0/0/0

R3.00-01           * 0x00000003   0x66DA       1098              0/0/0

R3.00-02           * 0x00000003   0xB18C       1060              0/0/0

R3.01-00           * 0x00000004   0x97B3       554               0/0/0

Tag null:

R1#show isis database

Tag 1:

IS-IS Level-1 Link State Database

LSPID                 LSP Seq Num LSP Checksum LSP Holdtime     ATT/P/OL

R1.00-00           * 0x0000000E   0x5533       1008              0/0/0

R2.00-00             0x0000000C   0xC97E       449               0/0/0

R3.00-01             0x00000002   0x68D9       223               0/0/0

R3.00-02             0x00000002   0xB38B       246               0/0/0

R3.01-00             0x00000004   0x97B3       545               0/0/0

Der Router R1 besitzt nicht das erste Fragment des L1 LSP (R3.00-00) des Routers R3. Dieses erste Fragment ist das größte und enthält in diesem Fall die meisten Präfixe. Aus diesem Grund weist der Router R1 einige der Präfixe nicht auf, was ein Blackholing des Datenverkehrs verursacht.

Um dieses Problem zu beheben, können Sie die LSP-MTU über den IS-IS-Befehl lsp-mtu <128-4352> des Routers verringern. Wenn Sie diesen Befehl nur auf dem Router R2 konfigurieren, ändert der Router R2 die vom Router R3 empfangenen LSP in keiner Weise. Das heißt, wenn der Router R2 einen LSP mit einer Größe von 1.490 Byte empfängt, fragmentiert ihn der Router R2 nicht. Wenn Sie den Befehl lsp-mtu 1400 auf dem Router R3 konfigurieren, erstellt der Router R3 kleinere LSP, die klein genug sind, um die Verbindung zwischen den Routern R2 und R1 zu kreuzen.

Die PDU-Länge beträgt jetzt 1.394 Byte, wenn Sie den Befehl lsp-mtu 1400 auf dem Router R3 konfigurieren:

Zusammenfassend lässt sich sagen, wenn Sie eine Verbindung mit einer kleineren MTU haben und den Befehl no isis hello padding always verwenden, kann dies zu Datenverkehrsflutungen und Blackholing führen. Um das Flooding-Problem zu beheben, können Sie die maximale Größe der LSPs reduzieren. Sie müssen jedoch auch den Befehl lsp-mtu router IS-IS auf jedem IS-IS-Router konfigurieren.

Änderungen an der MTU

In diesem Abschnitt werden die Auswirkungen der an der zugrunde liegenden MTU vorgenommenen Änderungen beschrieben.

Hello Padding aktiviert

In diesem Szenario funktioniert das Netzwerk von Anfang an ordnungsgemäß. Der MTU-Wert für die Schnittstelle "Serial2/0" auf den Routern R1 und R2 ist auf 1.400 Byte festgelegt. Das IS-IS Hello-Padding ist aktiviert, was das Standardverhalten ist.

Für Router R1 wird Folgendes ausgegeben:

interface Serial2/0

mtu 1400

ip address 10.1.1.1 255.255.255.0

ip router isis 1

serial restart-delay 0

Für Router R2 wird Folgendes ausgegeben:

interface Serial2/0

mtu 1400

ip address 10.1.1.2 255.255.255.0

ip router isis 1

serial restart-delay 0

R1#show isis neighbors

Tag 1:

System Id     Type Interface   IP Address     State Holdtime Circuit Id

R2             L1   Se2/0       10.1.1.2       UP   23       01

R2#show isis neighbors

Tag 1:

System Id     Type Interface   IP Address     State Holdtime Circuit Id

R1             L1   Se2/0       10.1.1.1       UP   27       01

0000.0000.0003 L1   Et1/0       10.1.2.3       UP   7       0000.0000.0003.01

Die IS-IS-Adjacency über die serielle Schnittstelle ist aktiv, und das IS-IS-Flooding ist in Ordnung.

Zu einem bestimmten Zeitpunkt tritt ein Problem im MPLS-Service-Provider-Netzwerk auf, das dazu führt, dass die End-to-End-MTU zwischen PE1 und PE2 unter 1.400 Byte fällt.

Da das Hello-Padding aktiviert ist (das Standardverhalten), fällt die IS-IS-Adjacency auf der Schnittstelle Serial2/0 schnell aus. Dies weist auf ein Problem in der MPLS-Cloud hin. Da die IS-IS-Adjacency ausfällt, verweist das Routing nicht mehr auf diese MPLS-Cloud, und es findet kein Blackhole-Verkehr in der gesamten Cloud statt.

Hello-Padding deaktiviert

In diesem Szenario funktioniert das Netzwerk von Anfang an ordnungsgemäß. Der MTU-Wert für die Schnittstelle Serial2/0 auf den Routern R1 und R2 ist auf 1.400 Byte festgelegt. Die IS-IS Hello-Auffüllung ist deaktiviert.

Für Router R1 wird Folgendes ausgegeben:

!

interface Serial2/0

mtu 1400

ip address 10.1.1.1 255.255.255.0

ip router isis 1

serial restart-delay 0

no isis hello padding

Für Router R2 wird Folgendes ausgegeben:

!

interface Serial2/0

mtu 1400

ip address 10.1.1.2 255.255.255.0

ip router isis 1

serial restart-delay 0

no isis hello padding

Die IS-IS-Adjacency über die serielle Schnittstelle ist aktiv, und das IS-IS-Flooding ist in Ordnung.

Dies ist die Datenbank des Routers R1:

R1#show isis database

Tag 1:

IS-IS Level-1 Link State Database:

LSPID                 LSP Seq Num LSP Checksum LSP Holdtime     ATT/P/OL

R1.00-00           * 0x0000001D   0x3742       1148              0/0/0

R2.00-00             0x0000001D   0xA78F       1161              0/0/0

R3.00-00             0x00000016   0xAFE4       454               0/0/0

R3.00-01             0x0000000B   0x0A0B       393               0/0/0

R3.00-02             0x0000000B   0xC2A5       451               0/0/0

R3.01-00             0x00000009   0x8DB8       435               0/0/0

Zu einem bestimmten Zeitpunkt tritt ein Problem im MPLS-Service-Provider-Netzwerk auf, das dazu führt, dass die End-to-End-MTU zwischen PE1 und PE2 unter 1.400 Byte fällt.

IS-IS ist nicht sofort betroffen, der IP-Datenverkehr ist jedoch möglicherweise betroffen. Bei Datenverkehr mit Paketen von 1.400 Byte Größe werden diese im MPLS-Netzwerk verworfen.

Wenn das Netzwerk stabil ist, kommt es für einen Großteil der Zeit nicht zu Überflutungen. Dies bleibt so lange bestehen, wie die LSP-Aktualisierung dauert. Sobald die LSP aktualisiert sind, wird das Flooding im MPLS-Netzwerk unterbrochen.

R2#

15:27:07.848: ISIS-Upd: Retransmitting L1 LSP 0000.0000.0003.00-01 on Serial2/0

15:27:07.880: ISIS-Upd: Sending L1 LSP 0000.0000.0003.00-01, seq C, ht 1147 on

Serial2/0

15:27:12.883: ISIS-Upd: Retransmitting L1 LSP 0000.0000.0003.00-01 on Serial2/0

15:27:12.924: ISIS-Upd: Sending L1 LSP 0000.0000.0003.00-01, seq C, ht 1142 on

Serial2/0

Dies ist die IS-IS-Datenbank des Routers R1, nachdem das Problem im MPLS-Netzwerk aufgetreten ist:

R1#show isis database

Tag 1:

IS-IS Level-1 Link State Database:

LSPID                 LSP Seq Num LSP Checksum LSP Holdtime     ATT/P/OL

R1.00-00           * 0x0000001D   0x3742       725               0/0/0

R2.00-00             0x0000001D   0xA78F       737               0/0/0

R3.00-00             0x00000016   0xAFE4       30                0/0/0

R3.00-01             0x0000000B   0xCE1F       0 (30)            0/0/0

R3.00-02             0x0000000C   0xC0A6       895               0/0/0

R3.01-00             0x0000000A   0x8BB9       906               0/0/0

Dies ist die Datenbank nach Ablauf der Haltezeit für einige LSP-Fragmente des Routers R3:

R1#show isis database

Tag 1:

IS-IS Level-1 Link State Database:

LSPID                LSP Seq Num LSP Checksum LSP Holdtime     ATT/P/OL

R1.00-00           * 0x0000001D   0x3742       605               0/0/0

R2.00-00             0x0000001D   0xA78F       618               0/0/0

R3.00-02             0x0000000C   0xC0A6       775               0/0/0

R3.01-00             0x0000000A   0x8BB9       787               0/0/0

Die Fragmente R3.00-00 und R3.00-01 erscheinen nicht mehr auf dem Router R1, und die Routen vom Router R3 befinden sich nicht mehr auf dem Router R1:

R1#show ip route summary

IP routing table name is default (0x0)

IP routing table maximum-paths is 32

Route Source   Networks   Subnets     Replicates Overhead   Memory (bytes)

connected       0           3           0           216         540

static          0           0           0           0           0

application     0           0           0           0           0

isis 1          0           2           0           144         360

Level 1: 2 Level 2: 0 Inter-area: 0

internal        1                                               560

Total           1           5           0           360         1460

Wie dargestellt, liegt bei einigen der Router-R3-LSP-Fragmente ein Timeout vor, und sie werden nicht angezeigt. Dadurch werden einige Routen nicht in der Routing-Tabelle angezeigt.

Wenn Sie das Hello-Padding deaktivieren, kann ein zukünftiges Problem im Netzwerk ausgeblendet werden. Wenn sich die zugrunde liegende MTU ändert, kann dies zu einem Routing-Problem führen, das viel schwieriger zu beheben ist, da Sie die Routing-Tabelle und die IS-IS-Datenbank auf mehreren Routern untersuchen müssen, um das Problem zu identifizieren. Wenn die Hello-Polsterung aktiviert ist, kann der Speicherort des Problems wesentlich einfacher bestimmt werden, da die IS-IS-Adjacency ausfällt.

Wichtige Hinweise

Die beste Lösung besteht darin, die MTU für die Verbindungen auf den richtigen Wert einzustellen und sicherzustellen, dass sie auf beiden Seiten der Verbindungen gleich ist. Dadurch wird sichergestellt, dass das IS-IS-Flooding ordnungsgemäß funktioniert und dass der Router die Fragmentierung korrekt durchführen oder sich korrekt verhalten kann, wenn er die MTU-Pfaderkennung unterstützt.

Das Problem mit der IS-IS-Überflutung wird möglicherweise erst dann offensichtlich, wenn die LSP größer werden (wenn das Netzwerk wächst). Wenn die IS-IS Hello-Füllung deaktiviert ist, wird das Problem behoben, bei dem die IS-IS-Nachbarschaften nicht verfügbar sind. Das Problem von Flooding, Blackholing-Datenverkehr und möglicherweise defekter Path MTU Discovery kann jedoch viel später auftreten, als der Zeitpunkt, zu dem die IS-IS Hello-Füllung deaktiviert ist. Dadurch wird die Fehlerbehebung erheblich erschwert, was viel mehr Zeit in Anspruch nimmt.