IP : Integrated Intermediate System-to-Intermediate System (IS-IS)

Comportement de hello padding IS-IS

18 juin 2016 - Traduction automatique
Autres versions: PDFpdf | Anglais (21 avril 2016) | Commentaires

Introduction

Ce document décrit le comportement de la remplissage de paquet d'Integrated Intermediate System-to-Intermediate System (IS-IS) bonjour dans le Cisco IOS®.

Contribué par Luc De Ghein, ingénieur TAC Cisco.

Informations générales

L'IS-IS par défaut complète bonjour les paquets à la pleine unité de transfert maximale de l'interface (MTU). C'est afin de détecter des non-concordances de MTU. Le MTU des deux côtés du lien devrait s'assortir. La remplissage peut également être utilisée afin de détecter la valeur réelle de MTU de la technologie qui se trouve dessous. Par exemple, pour le transport de la couche 2 (L2) au-dessus des scénarios multi de la commutation par étiquette de Protocol (MPLS), le MTU de la technologie de transport pourrait être beaucoup inférieur au MTU sur la périphérie. Par exemple, le MTU peut être de 9,000 octets sur la périphérie, alors que la technologie de transport MPLS a un MTU de 1,500 octets.

Si le MTU évalue la correspondance de chaque côté, alors la remplissage peut être désactivée. En soi, l'utilisation inutile de la bande passante et les mémoires tampons par des paquets IS-IS bonjour peuvent être évitées. La commande de routeur qui est utilisée afin de désactiver le hello padding n'est aucun hello padding [multipoint|Point à point]. La commande d'interface qui est utilisée afin de désactiver le hello padding n'est aucun isis hello padding.

Si la remplissage est désactivée au début, le routeur envoie toujours bonjour des paquets au plein MTU. Afin d'éviter ceci, désactivez la remplissage avec la commande d'interface et utilisez le mot clé always. Dans ce cas, tous les paquets IS-IS bonjour ne sont pas complétés.

Remarque: Cisco recommande que vous ne désactiviez pas le hello padding IS-IS afin d'assurer ce deux Routeurs forme une contiguïté IS-IS sur un lien qui a mal adapté des valeurs de MTU de chaque côté.

Compléter TLVs

Les paquets IS-IS bonjour ont une valeur de longueur de type de remplissage (TLV). Pour un Point à point (P2P) IH, la TLV pour la remplissage est 8. Pour le RÉSEAU LOCAL IIH, la TLV pour la remplissage est 8.

Compléter l'exemple TLV

L'exemple qui est fourni dans la prochaine image est utilisé dans cette section afin d'expliquer le MTU et la désactivation du hello padding dans l'IS-IS :

 

Dans cet exemple, PE1 et PE2 ont installé un circuit virtuel (circuit virtuel) 100 entre eux afin de connecter les Routeurs R1 et R2 à L2. Ce circuit virtuel est un circuit virtuel de Fonction Ethernet over MPLS (EoMPLS).

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      

Voici la sortie pour le routeur R1 :

interface Serial2/0
ip address 10.1.1.1 255.255.255.0
ip router isis 1
serial restart-delay 0

Voici la sortie pour le routeur R2 :

interface Serial2/0
ip address 10.1.1.2 255.255.255.0
ip router isis 1
serial restart-delay 0

La sortie de la commande de débogage de debug isis adj packets fournit des informations au sujet de la contiguïté IS-IS :

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

Dans ce scénario, la contiguïté IS-IS échoue.

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

Le MTU sur les interfaces série pour les Routeurs R1 et R2 sont le par défaut 1,500 octets.

La contiguïté IS-IS échoue parce que les paquets IS-IS bonjour sont de 1,499 octets dans la taille. Le réseau MPLS permet seulement les paquets 1,500-byte, sans huit octets (deux mpls label pour le service MPLS), qui égale 1,492 octets (la longueur de paquet qui est permise pour traverser). Pour le transport de L2 au-dessus de MPLS, la taille de l'en-tête L2 doit être soustraite des 1,492 octets qui résultent aussi bien.

Aucun hello padding

Dans ce scénario, l'aucune commande d'isis hello padding n'est utilisée sur l'interface de Serial2/0 sur le routeur R1 :

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

Comme affiché, plus de cinq paquets IS-IS bonjour sont envoyés avec la pleine taille de MTU (1,497 octets). Le routeur continue à envoyer bonjour les paquets avec la remplissage jusqu'à ce que la contiguïté IS-IS soit soulevée. Cependant, à moins que la question de MTU soit réparée, la contiguïté n'est pas soulevée.

Le MTU est diminué à 1,400 octets sur l'interface Serial2/0 sur le routeur R1. Ainsi, les paquets qui sont jusqu'à 1,400 octets dans la taille peuvent sûrement traverser le réseau MPLS au-dessus du pseudo-fil.

Voici la sortie pour le routeur R1 :

!
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

Le routeur R1 continue à transmettre bonjour les paquets avec la remplissage. La taille est maintenant de 1,400 octets sans une.

Une fois que le MTU est diminué sur l'interface série 2/0 d'interface sur le routeur R2, la remplissage est désactivée.

Voici la sortie pour le routeur R2 :

interface Serial2/0
mtu 1400
ip address 10.1.1.2 255.255.255.0
ip router isis 1
serial restart-delay 0

Une fois que le routeur R1 voit le paquet IS-IS bonjour arriver du routeur R2, il évoque la contiguïté IS-IS. Puisque le routeur R2 voit également les paquets IS-IS bonjour du routeur R1, par la suite la contiguïté IS-IS se déplace à l'état HAUT, ainsi il signifie qu'une contiguïté à trois voies est créée. En ce moment, le routeur R1 (le hello padding étant désactivé sur l'interface série 2/0 d'interface) diminue la taille bonjour du paquet au 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

Comme affiché, le routeur R1 envoie un paquet IS-IS bonjour avec la longueur 43 et reçoit bonjour les paquets du routeur R2 avec la longueur 1399. C'est parce que le hello padding est encore en activité sur le routeur R2.

Dans cet exemple, la contiguïté IS-IS n'est pas soulevée si l'un ou l'autre de côté du lien a toujours le MTU réglé à 1,500 octets sur l'interface série 2/0 d'interface. C'est le cas même lorsque l'aucune commande d'isis hello padding n'est activée. L'interface seulement est soulevée après que le MTU soit placé à la valeur correcte des deux côtés du lien.

Ainsi, si vous désactivez seulement le hello padding IS-IS, il n'est pas assez pour évoquer la contiguïté IS-IS. Le MTU doit être assez bas de sorte que les paquets de taille d'une mtu IS-IS bonjour soient envoyés et reçus correctement par les Routeurs des deux côtés du lien.

Aucun hello padding toujours

Le MTU étant placé à 1,500 octets sur l'interface Serial2/0 sur le routeur R1, la contiguïté n'est pas soulevée parce que les paquets transmis IS-IS bonjour sont toujours la pleine taille de MTU. Afin de fonctionner autour de cette question, vous ne pouvez configurer l'aucune commande d'interface d'isis hello padding toujours sur l'interface Serial2/0 afin de désactiver compléter toujours.

!
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

Dès que cette commande sera configurée, les paquets IS-IS bonjour ont la taille minimum. La contiguïté IS-IS entre les Routeurs R1 et R2 immédiatement est soulevée.

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:

Le problème avec l'IS-IS et le MTU d'interface

Si l'interface MTU est mal adaptée, alors la contiguïté IS-IS n'est pas soulevée. Pour un dépannage rapide, vous pouvez désactiver le hello padding IS-IS avec le mot clé always. Cependant, ceci ne pourrait pas être une vraie difficulté.

Voici la sortie pour le routeur R1 :

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

La contiguïté IS-IS est en hausse.

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

Voici un ping qui est envoyé du routeur R1 au routeur R3 afin de vérifier le trafic qui croise le lien :

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)

Comme affiché, les paquets avec une taille de 1,500 octets ne la font pas. C'est parce que le routeur R1 croit que le MTU est de 1,500 octets sur l'interface Serial2/0 :

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

Si le MTU est diminué à 1,400 octets sur l'interface Serial2/0, alors le routeur R1 peut fragmenter les paquets si les paquets n'ont pas ne fragmentent pas le bit (DF) réglé. Si les paquets ont le bit DF réglé, alors le routeur peut renvoyer à un ICMP 3/4 message, qui est utilisé par la découverte de MTU de chemin. Ceci permet à l'expéditeur des paquets pour diminuer la taille des paquets qu'elle envoie. Le paramètre approprié du MTU est important pour le trafic qui traverse le routeur, mais également pour le trafic qui provient du routeur et des croix qui joignent. Un exemple de ce dernier est Protocole BGP (Border Gateway Protocol), qui utilise le TCP et peut utiliser la découverte de MTU de chemin.

Inondation IS-IS

Afin de réparer la question de contiguïté IS-IS, l'opérateur du réseau peut désactiver le hello padding avec le mot clé always. Le MTU de la liaison série est laissé à 1, 500 octets.

Il reste la question de l'inondation IS-IS. Quand la base de données IS-IS est petite, il n'y a aucune question.

R1#debug isis update-packets
IS-IS Update related packet debugging is on for router process 1

Quand le routeur R3 ajoute un préfixe et inonde ceci, le routeur R1 reçoit l'État de lien PDU (LSP) du routeur R3 du routeur 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

Quand le nombre de préfixes qui sont annoncés par le routeur R3 augmente, le LSP du routeur R3 est si grand qu'il soit coupé en plusieurs fragments :

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:

Le R3.00-00 est le premier fragment, le R3.00-01 est le deuxième fragment, et ainsi de suite.

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

C'est le LSP qui est retransmis par le routeur R2 au-dessus de l'interface Serial2/0. La longueur PDU est de 1,490 octets, ainsi la taille de ce paquet ne lui permet pas pour atteindre le routeur R1.

Tandis que la contiguïté IS-IS entre les Routeurs R1 et R2 est en activité, le routeur R1 a moins de préfixes IP dans sa table de routage :

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                     0           144         360
Level 1: 2 Level 2: 0 Inter-area: 0
internal       1                                              560
Total           1           5           0           360         1460

C'est parce que le LSP R3.00-00 du routeur R3 n'atteint pas le routeur R1.

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

Le routeur R1 n'a pas le premier fragment du L1 LSP (R3.00-00) du routeur R3. Ce premier fragment est le plus grand et tient les la plupart des préfixes dans ce cas. Pour cette raison, le routeur R1 n'a pas certains des préfixes, qui entraînent noir-trouer du trafic.

Afin de résoudre ce problème, vous pouvez diminuer le MTU LSP par l'intermédiaire de la commande IS-IS de routeur du lsp-mtu <128-4352>. Si vous configurez cette commande seulement au routeur R2, alors le routeur R2 ne change pas les LSP qui sont reçus du routeur R3 de quelque façon. Ceci signifie que si le routeur R2 reçoit un LSP avec une taille de 1,490 octets, alors le routeur R2 ne la fragmente pas. Si vous configurez la commande du lsp-mtu 1400 sur le routeur R3, alors le routeur R3 crée de plus petits LSP, qui sont assez petits pour croiser le lien entre les Routeurs R2 et R1.

La longueur PDU est maintenant de 1,394 octets si vous configurez la commande du lsp-mtu 1400 sur le routeur R3 :

En conclusion, si vous avez un lien avec un plus petit MTU et n'utilisez l'aucune commande d'isis hello padding toujours, il peut mener pour trafiquer l'inondation et noir-trouer. Afin de résoudre le problème d'inondation, vous pouvez diminuer la taille maximale des LSP, mais vous devez également configurer la commande IS-IS de routeur de lsp-mtu sur chaque routeur IS-IS.

Modifications au MTU

Cette section décrit les effets des modifications qui sont apportées au MTU sous-jacent.

Hello padding activé

Dans ce scénario, les fonctions réseau correctement dès le début. Le MTU est placé à 1,400 octets sur l'interface Serial2/0 sur les Routeurs R1 et R2. Le hello padding IS-IS est activé, qui est le comportement par défaut.

Voici la sortie pour le routeur R1 :

interface Serial2/0
mtu 1400
ip address 10.1.1.1 255.255.255.0
ip router isis 1
serial restart-delay 0

Voici la sortie pour le routeur R2 :

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

La contiguïté IS-IS à travers l'interface série est en hausse, et l'inondation IS-IS est bien.

À un certain moment, une question se produit dans le réseau du fournisseur de service MPLS qui fait relâcher le MTU de bout en bout entre le PE1 et le PE2 en-dessous de 1,400 octets.

Puisque le hello padding est activé (le comportement par défaut), la contiguïté IS-IS va rapidement vers le bas sur l'interface Serial2/0. Ceci indique qu'il y a une question à travers le nuage MPLS. Puisque la contiguïté IS-IS descend, l'acheminement n'indique plus ce nuage MPLS, et aucun trafic noir-n'est troué à travers lui.

Hello padding désactivé

Dans ce scénario, les fonctions réseau correctement dès le début. Le MTU est placé à 1,400 octets sur l'interface Serial2/0 sur les Routeurs R1 et R2. Le hello padding IS-IS est désactivé.

Voici la sortie pour le routeur R1 :

!
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

Voici la sortie pour le routeur R2 :

!
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

La contiguïté IS-IS à travers l'interface série est en hausse, et l'inondation IS-IS est bien.

C'est la base de données du routeur 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

À un certain moment, une question se produit dans le réseau du fournisseur de service MPLS qui fait relâcher le MTU de bout en bout entre le PE1 et le PE2 en-dessous de 1,400 octets.

L'IS-IS n'est pas affecté immédiatement, mais le trafic IP pourrait être. S'il y a du trafic avec les paquets qui sont de 1,400 octets dans la taille, ils sont lâchés dans le réseau MPLS.

Si le réseau est stable, il n'y a aucune inondation pendant un grand nombre d'heure. Ceci reste tant que le LSP régénèrent le temps. Une fois qu'il est temps de régénérer le LSP, l'inondation est cassée à travers le réseau MPLS.

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

C'est la base de données IS-IS du routeur R1 après que la question se produise dans le réseau MPLS :

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

C'est la base de données après que le holdtime ait expiré pour certains des fragments LSP du routeur 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

Les fragments R3.00-00 et R3.00-01 n'apparaissent plus sur le routeur R1, et les artères du routeur R3 ne sont plus sur le routeur 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

Comme affiché, certains des fragments du routeur R3 LSP sont synchronisés- et n'apparaissent pas. Ceci fait ne pas apparaître certaines des artères dans la table de routage.

Si vous désactivez le hello padding, il peut masquer une future question dans le réseau. Quand le MTU sous-jacent change, il peut entraîner une question de routage il est beaucoup plus difficile de dépanner que parce que vous devez examiner la table de routage et la base de données IS-IS sur des plusieurs routeurs afin d'indiquer exactement la question. Le hello padding étant activé, le fait que la contiguïté IS-IS descend le facilite beaucoup pour déterminer l'emplacement de la question.

Remarques importantes

La meilleure solution est de placer le MTU à la valeur correcte sur les liens et de s'assurer qu'elle est égale des deux côtés des liens. Ceci s'assure que l'inondation IS-IS fonctionne correctement et que le routeur peut exécuter la fragmentation correctement ou se comporter correctement quand elle aide avec la découverte de MTU de chemin.

La question avec l'inondation IS-IS pourrait seulement devenir évidente quand les LSP deviennent plus grands (quand le réseau se développe). Quand le hello padding IS-IS est désactivé, il répare la question où les contiguïtés IS-IS ne sont pas soulevées. Cependant, la question de l'inondation, noir-trouant le trafic, et peut-être la découverte de MTU de chemin cassée, peut potentiellement surgir beaucoup plus tard que le temps à l'où le hello padding IS-IS est désactivé. Ceci rend la question beaucoup plus dure pour dépanner, qui prend beaucoup plus de temps.


Conversations connexes de la communauté de soutien de Cisco

Le site Cisco Support Community est un forum où vous pouvez poser des questions, répondre à des questions, faire part de suggestions et collaborer avec vos pairs.


Document ID: 119399