Ce document décrit le comportement du remplissage de paquets Hello IS-IS (Integrated Intermediate System-to-Intermediate System) dans Cisco IOS®.
Par défaut, IS-IS colle les paquets Hello à l'unité de transmission maximale (MTU) de l'interface complète. Ceci afin de détecter les incohérences de MTU. Le MTU de chaque côté de la liaison doit correspondre. Le remplissage peut également être utilisé afin de détecter la valeur MTU réelle de la technologie qui se trouve en dessous. Par exemple, pour le transport de couche 2 (L2) sur des scénarios MPLS (Multi Protocol Label Switching), le MTU de la technologie de transport peut être beaucoup plus faible que le MTU de la périphérie. Par exemple, la MTU peut être de 9 000 octets en périphérie, tandis que la technologie de transport MPLS a une MTU de 1 500 octets.
Si les valeurs MTU correspondent de chaque côté, le remplissage peut être désactivé. Ainsi, l'utilisation inutile de la bande passante et des tampons par les paquets Hello IS-IS peut être évitée. La commande de routeur utilisée pour désactiver le remplissage Hello est no hello padding [multipoint|point-to-point]. La commande d'interface qui est utilisée afin de désactiver le remplissage Hello est no isis hello padding.
Si le remplissage est désactivé au début, le routeur continue d'envoyer des paquets Hello à MTU complet. Pour éviter cela, désactivez le remplissage avec la commande interface et utilisez le mot clé always. Dans ce cas, tous les paquets Hello IS-IS ne sont pas remplis.
Les paquets Hello IS-IS ont une valeur de longueur de type de remplissage (TLV). Pour une liaison point à point (P2P) IH, le TLV pour le remplissage est 8. Pour le LAN IIH, le TLV pour le remplissage est 8.
L'exemple fourni dans l'image suivante est utilisé dans cette section afin d'expliquer le MTU et la désactivation du remplissage Hello dans IS-IS :
Dans cet exemple, PE1 et PE2 ont configuré un circuit virtuel (VC) 100 entre eux afin de connecter les routeurs R1 et R2 au niveau de L2. Ce circuit virtuel est un circuit virtuel Ethernet sur 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 le résultat du routeur R1 :
interface Serial2/0
ip address 10.1.1.1 255.255.255.0
ip router isis 1
serial restart-delay 0
Voici le résultat du routeur R2 :
interface Serial2/0
ip address 10.1.1.2 255.255.255.0
ip router isis 1
serial restart-delay 0
Le résultat de la commande debug isis adj-packets debug fournit des informations sur 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
La valeur MTU sur les interfaces série des routeurs R1 et R2 est de 1 500 octets par défaut.
La contiguïté IS-IS échoue car les paquets Hello IS-IS ont une taille de 1 499 octets. Le réseau MPLS n'autorise que les paquets de 1 500 octets, moins huit octets (deux étiquettes MPLS pour le service MPLS), ce qui équivaut à 1 492 octets (la taille de paquet autorisée à transiter). Pour le transport de L2 sur MPLS, la taille de l'en-tête L2 doit également être soustraite des 1 492 octets qui en résultent.
Dans ce scénario, la commande no isis hello padding 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 illustré, plus de cinq paquets Hello IS-IS sont envoyés avec une taille MTU complète (1 497 octets). Le routeur continue à envoyer les paquets Hello avec remplissage jusqu'à ce que la contiguïté IS-IS apparaisse. Cependant, à moins que le problème de MTU ne soit résolu, la contiguïté n'apparaît pas.
La MTU est abaissée à 1 400 octets sur l’interface Serial2/0 sur le routeur R1. Ainsi, les paquets dont la taille peut atteindre 1 400 octets peuvent certainement traverser le réseau MPLS sur le pseudo-fil.
Voici le résultat du 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 de transmettre les paquets Hello avec remplissage. La taille est maintenant de 1 400 octets moins un.
Une fois que le MTU est réduit sur l'interface Serial 2/0 sur le routeur R2, le remplissage est désactivé.
Voici le résultat du 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 Hello IS-IS arriver du routeur R2, il active la contiguïté IS-IS. Comme le routeur R2 voit également les paquets Hello IS-IS du routeur R1, la contiguïté IS-IS passe finalement à l'état UP, ce qui signifie qu'une contiguïté à trois voies est créée. À ce stade, le routeur R1 (avec le remplissage Hello désactivé sur l'interface Serial 2/0) réduit la taille du paquet Hello 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 illustré, le routeur R1 envoie un paquet Hello IS-IS de longueur 43 et reçoit les paquets Hello du routeur R2 de longueur 1399. En effet, le remplissage Hello est toujours actif sur le routeur R2.
Dans cet exemple, la contiguïté IS-IS ne s'affiche pas si l'un des côtés de la liaison a toujours la MTU définie sur 1 500 octets sur l'interface Serial 2/0. C'est le cas même lorsque la commande no isis hello padding est activée. L’interface n’apparaît qu’une fois que le MTU est défini sur la valeur correcte de chaque côté de la liaison.
Ainsi, si vous désactivez uniquement le remplissage Hello IS-IS, il ne suffit pas d'activer la contiguïté IS-IS. La MTU doit être suffisamment faible pour que les paquets Hello IS-IS de la taille de la MTU soient envoyés et reçus correctement par les routeurs de chaque côté de la liaison.
Lorsque la MTU est définie sur 1 500 octets sur l’interface Serial2/0 du routeur R1, la contiguïté ne s’active pas car les paquets Hello IS-IS transmis ont toujours la taille MTU totale. Afin de contourner ce problème, vous pouvez configurer la commande d'interface no isis hello padding always sur l'interface Serial2/0 afin de désactiver le remplissage always.
!
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 est configurée, les paquets Hello IS-IS ont la taille minimale. La contiguïté IS-IS entre les routeurs R1 et R2 apparaît immédiatement.
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:
Si le MTU de l'interface ne correspond pas, la contiguïté IS-IS ne s'active pas. Pour une solution rapide, vous pouvez désactiver le remplissage Hello IS-IS avec le mot clé always. Cependant, cela pourrait ne pas être une vraie solution.
Voici le résultat du 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 active.
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 une requête ping envoyée du routeur R1 au routeur R3 afin de vérifier le trafic qui traverse la liaison :
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 illustré, les paquets d'une taille de 1 500 octets ne passent pas. En effet, le routeur R1 estime que la 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 la MTU est abaissée à 1 400 octets sur l’interface Serial2/0, le routeur R1 peut fragmenter les paquets si le bit Ne pas fragmenter (DF) n’est pas défini pour les paquets. Si le bit DF est défini pour les paquets, le routeur peut renvoyer un message ICMP 3/4, qui est utilisé par la détection de MTU de chemin. Cela permet à l'expéditeur des paquets de réduire la taille des paquets qu'il envoie. Le paramètre correct de la MTU est important pour le trafic qui traverse le routeur, mais aussi pour le trafic qui provient du routeur et traverse cette liaison. Le protocole BGP (Border Gateway Protocol), qui utilise le protocole TCP et peut utiliser la détection de MTU de chemin, en est un exemple.
Afin de résoudre le problème de contiguïté IS-IS, l'opérateur du réseau peut désactiver le remplissage Hello avec le mot clé always. Le MTU de la liaison série est laissé à 1 500 octets.
Il y a toujours la question de l'inondation IS-IS. Lorsque la base de données IS-IS est petite, aucun problème ne se pose.
R1#debug isis update-packets
IS-IS Update related packet debugging is on for router process 1
Lorsque le routeur R3 ajoute un préfixe et le diffuse, le routeur R1 reçoit la PDU (Link State PDU) 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
Lorsque le nombre de préfixes annoncés par le routeur R3 augmente, le LSP du routeur R3 est si grand qu’il est divisé 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
Il s’agit du paquet LSP qui est retransmis par le routeur R2 sur l’interface Serial2/0. La longueur de l’unité de données de protocole est de 1 490 octets, de sorte que la taille de ce paquet ne lui permet pas d’atteindre le routeur R1.
Alors que la contiguïté IS-IS entre les routeurs R1 et R2 est active, 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 2 0 144 360
Level 1: 2 Level 2: 0 Inter-area: 0
internal 1 560
Total 1 5 0 360 1460
En effet, 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 ne possède pas le premier fragment du LSP L1 (R3.00-00) du routeur R3. Ce premier fragment est le plus grand et contient le plus grand nombre de préfixes dans ce cas. Pour cette raison, le routeur R1 ne dispose pas de certains préfixes, ce qui entraîne un trou noir du trafic.
Afin de résoudre ce problème, vous pouvez diminuer le MTU LSP via la commande lsp-mtu <128-4352> router IS-IS. Si vous configurez cette commande uniquement au niveau du routeur R2, le routeur R2 ne modifie en rien les paquets LSP reçus du routeur R3. Cela signifie que si le routeur R2 reçoit un paquet LSP d’une taille de 1 490 octets, il ne le fragmente pas. Si vous configurez la commande lsp-mtu 1400 sur le routeur R3, alors le routeur R3 crée des LSP plus petits, qui sont suffisamment petits pour croiser la liaison entre les routeurs R2 et R1.
La longueur de l'unité de données de protocole est maintenant de 1 394 octets si vous configurez la commande lsp-mtu 1400 sur le routeur R3 :
En conclusion, si vous avez une liaison avec un MTU plus petit et utilisez la commande no isis hello padding always, cela peut entraîner une inondation de trafic et un trou noir. Afin de résoudre le problème d'inondation, vous pouvez diminuer la taille maximale des LSP, mais vous devez également configurer la commande lsp-mtu router IS-IS sur chaque routeur IS-IS.
Cette section décrit les effets des modifications apportées au MTU sous-jacent.
Dans ce scénario, le réseau fonctionne correctement dès le début. Le MTU est défini sur 1 400 octets sur l’interface Serial2/0 sur les routeurs R1 et R2. Le remplissage Hello IS-IS est activé, ce qui est le comportement par défaut.
Voici le résultat du 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 le résultat du 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 sur l'interface série est active et la diffusion IS-IS est correcte.
À un certain moment, un problème se produit dans le réseau du fournisseur de services MPLS, qui fait passer le MTU de bout en bout entre le PE1 et le PE2 en dessous de 1 400 octets.
Étant donné que le remplissage Hello est activé (comportement par défaut), la contiguïté IS-IS s’arrête rapidement sur l’interface Serial2/0. Cela indique qu’il y a un problème dans le cloud MPLS. La contiguïté IS-IS étant désactivée, le routage ne pointe plus vers ce nuage MPLS et aucun trafic n'est bloqué à travers celui-ci.
Dans ce scénario, le réseau fonctionne correctement dès le début. Le MTU est défini sur 1 400 octets sur l’interface Serial2/0 sur les routeurs R1 et R2. Le remplissage Hello IS-IS est désactivé.
Voici le résultat du 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 le résultat du 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 sur l'interface série est active et la diffusion IS-IS est correcte.
Voici 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, un problème se produit dans le réseau du fournisseur de services MPLS, qui fait passer 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 peut l'être. Si le trafic comporte des paquets de 1 400 octets, ils sont abandonnés dans le réseau MPLS.
Si le réseau est stable, il n’y a pas d’inondation pendant une longue période. Cela reste tant que le temps d'actualisation LSP. Une fois qu'il est temps d'actualiser le ou les LSP, la propagation est interrompue sur 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
Voici la base de données IS-IS du routeur R1 après que le problème se soit produit sur 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
Il s’agit de la base de données après l’expiration du délai d’attente pour certains 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 routes du routeur R3 ne figurent 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 indiqué, certains fragments LSP du routeur R3 ont expiré et n’apparaissent pas. Certaines routes n’apparaissent donc pas dans la table de routage.
Si vous désactivez le remplissage Hello, il peut masquer un problème futur sur le réseau. Lorsque la MTU sous-jacente change, cela peut entraîner un problème de routage beaucoup plus difficile à résoudre, car vous devez examiner la table de routage et la base de données IS-IS sur plusieurs routeurs afin de localiser le problème. Lorsque le remplissage Hello est activé, le fait que la contiguïté IS-IS tombe en panne facilite grandement la détermination de l'emplacement du problème.
La meilleure solution consiste à définir le MTU sur la valeur correcte sur les liaisons et à s'assurer qu'il est égal des deux côtés des liaisons. Cela garantit que l'inondation IS-IS fonctionne correctement et que le routeur peut effectuer la fragmentation correctement ou se comporter correctement lorsqu'il aide à la détection de MTU de chemin.
Le problème de l'inondation IS-IS ne peut devenir évident que lorsque les paquets LSP deviennent plus grands (lorsque le réseau se développe). Lorsque le remplissage Hello IS-IS est désactivé, il résout le problème lorsque les contiguïtés IS-IS ne s'affichent pas. Cependant, le problème de l'inondation, du trafic de trous noirs et peut-être de la découverte de MTU de chemin cassé, peut potentiellement se poser beaucoup plus tard que le moment où le remplissage Hello IS-IS est désactivé. Cela rend le problème beaucoup plus difficile à résoudre, ce qui prend beaucoup plus de temps.