IS-IS Hello Padding-Verhalten
Inhalt
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.
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.
Feedback