Fehlerbehebung für die MTU auf Switches der Catalyst 9000-Serie

Einleitung

In diesem Dokument wird beschrieben, wie Sie die MTU-Werte (Maximum Transmission Unit) auf Catalyst Switches der Serie 9000 ermitteln und Fehler bei diesen beheben.

Voraussetzungen

Anforderungen

Es gibt keine spezifischen Anforderungen für dieses Dokument.

Verwendete Komponenten

Die Informationen in diesem Dokument basieren auf folgenden Software- und Hardware-Versionen:

• C9200
• C9300
• C9400
• C9500
• C9600

Hinweis: Sie können die MTU-Größe für alle Schnittstellen auf einem Gerät gleichzeitig mit dem globalen Befehlssystem mtu konfigurieren.  Ab Cisco IOS® XE 17.1.1 unterstützen Catalyst 9000-Switches MTU pro Port. MTU pro Port unterstützt die MTU-Konfiguration auf Port- und Port-Channel-Ebene. Mit Pro-Port-MTU können Sie verschiedene MTU-Werte für verschiedene Schnittstellen sowie verschiedene Port-Channel-Schnittstellen festlegen.

Hinweis: Informationen zu den zur Aktivierung dieser Funktionen auf anderen Cisco Plattformen verwendeten Befehlen finden Sie im entsprechenden Konfigurationsleitfaden.

Die Informationen in diesem Dokument beziehen sich auf Geräte in einer speziell eingerichteten Testumgebung. Alle Geräte, die in diesem Dokument benutzt wurden, begannen mit einer gelöschten (Nichterfüllungs) Konfiguration. Wenn Ihr Netzwerk in Betrieb ist, stellen Sie sicher, dass Sie die möglichen Auswirkungen aller Befehle kennen.

Hintergrundinformationen

MTU-Zusammenfassungstabelle

Framegröße gesamt = MTU + L2-Header

Port-Typ	Standard-MTU - Byte	Konfigurierte MTU - Bytes	L2-Header	Gesamte Frame-Größe
L2-Zugriff	1500		18	1518
		9216	18	9234
L2-Trunk	1500		22	1522
		9216	22	9238
Physischer L3-Port	1500		18	1518
		9216	18	9234
L3-SVI	1500		18	1518
		9216	18	9234
IP-MTU am L3-Port	1500	Der Bereich wird unterstützt.	18	Basierend auf dem konfigurierten Wert ip mtu.

Fragen und Antworten zur MTU 

Was ist MTU?

• MTU ist die maximale Sendeeinheit, die ein Gerät weiterleiten kann. Im Allgemeinen ist diese Einheit die IP-Paketlänge, die den IP-Header enthält.
• L2-Header wie Dot1q-Tag, MacSec, SVL-Header usw. werden in dieser Berechnung nicht berücksichtigt.

Was ist ein L2-Header und seine Länge?

• Ein generischer L2-Header umfasst 14 Byte + 4 Byte CRC und umfasst insgesamt 18 Byte.
• Ein Trunk fügt vier weitere Bytes für das dot1q VLAN Tag hinzu und ergibt insgesamt 22 Bytes.
• Ebenso fügt MacSec seine eigene Headerlänge über die typische L2-Headerlänge hinzu.
• Der SVL-Port fügt seine eigene Header-Länge über die typische L2-Header-Länge hinzu.
• Daher wird Overall Packet on Wire (Gesamtpaket über Kabel) auf dem Kabel aufgestoßen.

Welche Paketlänge wird von einer Schnittstelle verarbeitet?

• Catalyst 9000-Switches verarbeiten Paketgrößen von 64 Byte bis 9238 Byte. 

Was ist die MTU-Standardeinstellung?

• Die Standard-MTU ist die MTU, die der Switch vor jeder Benutzerkonfiguration festgelegt wird.
• Die Standard-MTU-Größe aller Catalyst 9000-Switches beträgt 1500 Byte.
• Ein Ethernet-Port leitet ein 1500 Byte großes Layer-3-Paket + einen Layer-2-Header weiter.

Findet die MTU-Prüfung am Eingang oder am Ausgang statt?

Ausgehend: MTU ist die maximale Übertragungseinheit. Es handelt sich um eine Egress-Prüfung. Die Entscheidung, die Daten wie besehen oder verworfen zu fragmentieren oder zu übertragen, wird für den Egress entschieden.

• Wenn die Port-MTU größer ist als die Paketlänge, die geroutet werden soll, wird das Paket wie besehen gesendet.
• Wenn das Paket größer als die MTU des Ausgangsports ist und der Ausgangsport
  
  • Über einen Layer-3-Port werden Pakete entsprechend der MTU fragmentiert.
  • Über einen Layer-2-Port werden Pakete verworfen. (Fragmentierung nur auf Layer 3)

Hinweis: Wenn für ein Paket das Do Not Fragment (DNF)-Bit im IP-Header festgelegt wurde und die Port-MTU kleiner als das zu leitende Paket ist, wird das Paket verworfen.

Ingress (Eingehend): Die MTU-Prüfung wird auch für Pakete durchgeführt, die an einer Schnittstelle eintreffen. 

• Wenn eine Schnittstelle ein Paket über ihre konfigurierte MTU empfängt, werden diese Pakete als übergroße Pakete behandelt und verworfen. 

Was sind Jumbo Packets?

• Auf Catalyst Switches der Serie 9000 sind alle mehr als 1500 Byte Pakete gigantische Pakete oder Jumbo-Pakete.
  • Beispiel 1: Wenn eine Schnittstellen-MTU für die Weiterleitung von Jumbo-Frames mit einer Größe von 9.216 Byte konfiguriert ist, werden Frames mit 9.216 Byte + Layer-2-Header akzeptiert oder gesendet. 
  • Beispiel 2: Wenn eine Schnittstellen-MTU für die Weiterleitung einer Jumbo-Frame-Größe von 5.000 Byte konfiguriert ist, werden Frames mit 5.000 Byte + Layer-2-Header akzeptiert oder gesendet.

Werden Jumbo-Pakete oder übergroße Pakete als fehlerhafte Pakete angesehen?

• Eine Schnittstelle verwirft empfangene Pakete über konfigurierte MTU und meldet Pakete als Fehler. 
• Wenn die Schnittstelle für die Übertragung einer Jumbo-MTU konfiguriert ist und die empfangenen Pakete diesen Wert nicht überschreiten, werden sie nicht als Fehler gezählt. 

Was ist die minimale Paketgröße, die ein Port verarbeiten kann?

• 64 Byte (einschließlich L2-Header) ist die kleinste gültige Paketgröße, die der Switch bei Eingang akzeptiert. 
• Wenn ein Paket weniger als 64 Byte enthält, wird es als Runt betrachtet und beim Eintritt verworfen.
• Wenn ein Paket senden soll und das Paket kleiner als 64 Byte ist, fügt der Switch dem Paket einen Pad hinzu, um es vor der Übertragung auf ein Minimum von 64 Byte zu verkleinern. 

Was passiert, wenn die System-MTU 9216 beträgt und der SVL-Header weitere 64 Byte hinzufügt?

• Ein Header unter dem Layer-3-IP-Header wird bei der MTU-Berechnung nicht berücksichtigt.
• Die SVL-Verbindung kann eine Paketgröße von 9216 + L2-Header + 64 Byte SVL-Header übertragen. 

Was ist IP-MTU?

• IP-MTU kann nur auf IP-Pakete angewendet werden. Andere Paketgrößen, die keine IP-Adressen sind, werden mit diesem Befehl nicht berücksichtigt. 
• IP-MTU hat bei IP-Paketen Vorrang vor System-MTU oder nach Port aufgegliederter MTU. 
• IP-MTU legt die maximale Größe eines IP-Pakets fest, bevor es fragmentiert werden muss. 
• Wenn die physische oder logische Layer-3-Schnittstelle eine MTU von 1.500 Byte mit einer IP-MTU von 1.400 Byte aufweist, beträgt die Fragmentierungsgrenze 1.400 Byte, unabhängig von der System- oder Port-MTU-Einstellung.
• Die MTU ist ein Wert, der mit dem Peer-Router/-Switch abgeglichen werden muss. Wenn das Peer-Gerät den höheren MTU-Wert nicht unterstützt, verwenden Sie IP-MTU oder MTU, um beide Gerätefunktionen abzugleichen. 
• Wenn IP-MTU konfiguriert ist, passt das Gerät die Größe der Routing-Protokollpakete an den konfigurierten IP-MTU-Wert an. Einige Routing-Protokolle stützen sich auf den abgeglichenen MTU-Wert, um eine Routing-Protokoll-Nachbarschaft herzustellen.

Beispiele:

• Beispiel 1: Wenn eine Schnittstellen-IP-MTU-Größe bei 500 Byte konfiguriert wird, wobei die Schnittstellen-MTU die Standardeinstellung ist (keine Port-MTU), und wenn die System-MTU 9000 beträgt, beträgt die Schnittstellen-MTU 9000 Byte, wobei die IP-Fragmentierung 500 Byte beträgt.
• Beispiel 2: Ein GRE-Tunnel ist die Ausgangsschnittstelle, daher müssen die 24 Byte des GRE-Headers bei der Paketgrößenberechnung berücksichtigt werden (ip mtu 1476 + 24 Byte GRE-Header = 1500 MTU gesamt).

Worin besteht der Unterschied zwischen der System-MTU und der Port-MTU?

• System-MTU ist eine globale Konfiguration, die die MTU des gesamten Geräts festlegt. Dadurch werden alle physischen und logischen Ports an der Vorderseite auf den Wert geändert, der mit dem Befehl "system mtu" festgelegt wurde.
• Die MTU pro Port ermöglicht das Festlegen eines MTU-Werts auf Schnittstellenbasis. Dieser hat Vorrang vor der System-MTU-Konfiguration. Nach Entfernen der Port-Einstellung wird die Schnittstelle wieder auf die System-MTU zurückgesetzt. 

Beispiele:

• Beispiel 1: Der System-MTU-Wert wird auf 9.000 festgelegt, und alle physischen und logischen Ports und MTUs werden auf 9.000 festgelegt.
• Beispiel 2: Wenn eine Schnittstelle mit einer MTU von 4000 konfiguriert wird und die System-MTU 9000 beträgt, verwendet die Schnittstelle eine MTU von 4000, während andere Ports eine MTU von 9000 verwenden.

Welche Auswirkungen hat die Fragmentierung aufgrund von MTU-Beschränkungen?

• Ein Gerät leitet ein bereits fragmentiertes Paket normal auf Datenebene weiter. Wenn das Gerät jedoch für die Fragmentierung oder Reassemblierung verantwortlich ist, können sich Leistungs-/Ressourcenprobleme ergeben. 
• Eine Fragmentierung kann ernsthafte Auswirkungen auf den Gesamtdurchsatz und die Leistung von Anwendungen und Geräten haben, die für die Fragmentierung verantwortlich sind. 
• Die Behandlung fragmentierter Pakete auf vielen Plattformen erfolgt mithilfe von Software. Bei der Fragmentierung oder Zusammenstellung fragmentierter Pakete sind hohe CPU-Zyklen erforderlich.
• Wenn Ihr Netzwerk stark fragmentiert ist, stellen Sie sicher, dass die MTU entsprechend angepasst wird, um den End-to-End-Paketfluss ohne Fragmentierung zu gewährleisten.

Was ist die PMTUD (Path MTU Discovery)?

• Die TCP-MSS ist, wie zuvor beschrieben, zuständig für die Fragmentierung an den beiden Endpunkten einer TCP-Verbindung, aber nicht für den Fall, dass sich in der Mitte zwischen diesen beiden Endpunkten eine Verbindung mit einer niedrigeren MTU befindet. Die PMTUD wurde entwickelt, um eine Fragmentierung im Pfad zwischen den Endpunkten zu vermeiden. Sie wird verwendet, um die niedrigste MTU auf dem Weg von der Quelle eines Pakets bis zum Ziel dynamisch zu bestimmen.
• Weitere Informationen zur PMTUD und zur Fehlerbehebung finden Sie unter Lösen von IPv4-Fragmentierungs-, MTU-, MSS- und PMTUD-Problemen mit GRE und IPsec.

IPv6-MTU

• IPv6-MTU funktioniert auf die gleiche Weise wie IP-MTU.
• Verwenden Sie zum Konfigurieren ipv6 mtu anstelle von ip mtu in der Schnittstellenkonfiguration. 
• Die Mindestgröße für IPv6 beträgt 1280 Byte, IPv4 dagegen 832 Byte. 
• IPv6 PMTUD funktioniert ähnlich wie IPv4. Weitere Informationen finden Sie im IP Routing Configuration Guide, Cisco IOS® XE Amsterdam 17.3.x (Catalyst 9500 Switches).

Ethernet-Frames

Standard-Ethernet-Frame ohne Dot1Q oder andere Tags.

Dot1Q-Ethernet-Frame 

 

Konfigurieren und Überprüfen der MTU

Konfigurieren von MTU 

Diese Konfiguration kann global oder für einzelne Ports mit Cisco IOS® XE 17.1.1 oder höher durchgeführt werden. Überprüfen Sie, ob Ihre Hardware diese Konfiguration unterstützt.

• Nach Entfernen der portspezifischen Konfiguration verwendet der Port die globale System-MTU-Einstellung.

### Global System MTU set to 1800 bytes ###

9500H(config)#system mtu ?
 <1500-9216> MTU size in bytes   <-- Size range that is configurable 

9500H(config)#system mtu 1800     <-- Set global to 1800 bytes 
Global Ethernet MTU is set to 1800 bytes.
Note: this is the Ethernet payload size, not the total
Ethernet frame size, which includes the Ethernet
header/trailer and possibly other tags, such as ISL or
802.1q tags.                     <-- CLI provides information about what is counted as MTU


### Per-Port MTU set to 9216 bytes ###
9500H(config)#int TwentyFiveGigE1/0/1 
9500H(config-if)#mtu 9126        <-- Interface specific MTU configuration 

MTU überprüfen

In diesem Abschnitt wird beschrieben, wie Sie die Software- und Hardwareeinstellungen für die MTU überprüfen. 

• Überprüfen der von der Software konfigurierten MTU und der Hardware-MTU
• Datenverkehrsverluste können auftreten, wenn die Hardware nicht mit der in der Software konfigurierten MTU übereinstimmt.

Software-MTU-Überprüfung

9500H#show system mtu
Global Ethernet MTU is 1800 bytes.     <-- Global level MTU 

9500H#show interfaces mtu

Port         Name              MTU
Twe1/0/1                       9216   <-- Per-Port MTU override
Twe1/0/2                       1800   <-- No per-port MTU uses global MTU 
<...snip...>

9500H#show interfaces TwentyFiveGigE 1/0/1 | inc MTU
MTU 9216 bytes, BW 1000000 Kbit/sec, DLY 10 usec,

9500H#show interfaces TwentyFiveGigE 1/0/2 | inc MTU
MTU 1800 bytes, BW 25000000 Kbit/sec, DLY 10 usec,

Hardware-MTU-Überprüfung

9500H#show platform software fed active ifm mappings
Interface                 IF_ID    Inst Asic Core Port SubPort Mac Cntx LPN GPN Type Active
TwentyFiveGigE1/0/1       0x8        1   0   1    20     0      16  4    1   101 NIF  Y  <-- Retrieve the IF_ID for use in the next command
TwentyFiveGigE1/0/2       0x9        1   0   1    21     0      17  5    2   102 NIF  Y

9500H#show platform software fed active ifm if-id 0x8 | inc MTU
                Jumbo MTU ............ [9216]  <-- Hardware matches software configuration

9500H#show platform software fed active ifm if-id 0x9 | in MTU
                Jumbo MTU ............ [1800]  <-- Hardware matches software configuration

Hinweis: Plattformsoftware anzeigen, die <active|standby> gespeist wird, kann variieren. Bestimmte Plattformen erfordern einen hardwaregespeisten Switch der Anzeigeplattform <active|standby|sw_num>.

Fehlerbehebung bei MTU

Topologie

 

Verworfene Eingangspakete (niedrigere Eingangs-MTU)

Wenn einer dieser Zähler inkrementiert, bedeutet dies in der Regel, dass die empfangenen Pakete die konfigurierte MTU erreicht haben.

• Giants-Zähler im Befehl show interface.
• ValidOverSize-Zähler im Befehl show controller.

9500H#show int twentyFiveGigE 1/0/3 | i MTU
MTU 1500 bytes, BW 100000 Kbit/sec, DLY 100 usec,
   0 runts, 0 giants, 0 throttles                                          <-- No giants counted 

9500H#show controllers ethernet-controller twentyFiveGigE 1/0/3 | i ValidOverSize
            0 Deferred frames                       0 ValidOverSize frames <-- No giants counted


### 5 pings from neighbor device with MTU 1800 to ingress port MTU 1500 ###

9500H#show int twentyFiveGigE 1/0/3 | i MTU|giant
MTU 1500 bytes, BW 100000 Kbit/sec, DLY 100 usec,
   0 runts, 5 giants, 0 throttles                                          <-- 5 giants counted

9500H#show controllers ethernet-controller twentyFiveGigE 1/0/3 | i ValidOverSize
            0 Deferred frames                       5 ValidOverSize frames <-- 5 giants counted

Details zum Befehl show controllers Ethernet-controller.

• Wenn Pakete über die konfigurierte MTU eintreffen und die CRC-Prüfung nicht bestehen, werden sie als InvalidOverSize (Ungültige Größe) gezählt.
• Wenn Pakete innerhalb der konfigurierten MTU ankommen und die CRC-Prüfung nicht bestehen, werden sie als FcsErr gezählt.

9500H#show controllers ethernet-controller twentyFiveGigE 1/0/3 | i Fcs|InvalidOver
            0 Good (>1 coll) frames                           0 InvalidOverSize frames <-- MTU too large and bad CRC
            0 Gold frames dropped                             0 FcsErr frames          <-- MTU within limits with bad CRC

Konfigurieren und Überprüfen der IP-MTU

IP-MTU konfigurieren 

In diesem Abschnitt wird beschrieben, wie Sie die IP-MTU auf einer Tunnelschnittstelle konfigurieren. 

• Die IP-MTU kann so konfiguriert werden, dass sie die Größe der vom lokalen System generierten IP-Pakete beeinflusst (z. B. Routing-Protokoll-Updates), oder sie kann verwendet werden, um eine Größe festzulegen, die bei der Fragmentierung auftreten soll.

C9300(config)#interface tunnel 1
C9300(config-if)#ip mtu 1400

interface Tunnel1
 ip address 10.11.11.2 255.255.255.252
 ip mtu 1400                       <-- IP MTU command sets this line at 1400 
 ip ospf 1 area 0
 tunnel source Loopback0
 tunnel destination 192.168.1.1

IP-MTU überprüfen

Software-IP-MTU-Überprüfung

C9300#sh ip interface tunnel 1 <-- Show the IP level configuration of the interface 
Tunnel1 is up, line protocol is up
  Internet address is 10.11.11.2/30
  Broadcast address is 255.255.255.255
  Address determined by setup command
  MTU is 1400 bytes <-- max size of IP packet before fragmentation occurs

Hardware-IP-MTU-Überprüfung

C9300#sh platform software fed switch active ifm interfaces tunnel
Interface                         IF_ID               State
----------------------------------------------------------------------
Tunnel1                           0x00000050          READY            <-- Retrieve the IF_ID for use in the next command

C9300#sh platform software fed switch active ifm if-id 0x00000050
Interface IF_ID         : 0x0000000000000050  <-- The interface ID (IF_ID) 
Interface Name          : Tunnel1
Interface Block Pointer : 0x7fe98cc2d118
Interface Block State   : READY
Interface State         : Enabled
Interface Status        : ADD, UPD
Interface Ref-Cnt       : 4
Interface Type          : TUNNEL
<...snip...>   
       Tunnel Sub-mode: 0 [none]
       Hw Support : Yes
       Tunnel Vrf : 0
       IPv4 MTU : 1400                        <-- Hardware matches software configuration
<...snip...> 

Fehlerbehebung: IP-MTU

Topologie

IP-Fragmentierung

Wenn Pakete über eine Tunnel-Schnittstelle gesendet werden, kann die Fragmentierung auf zwei in diesen Beispielen beschriebene Arten erfolgen. 

Standard-IP-Fragmentierung

Fragmentierung des ursprünglichen Pakets zur Reduzierung der MTU vor der Tunnelkapselung. 

• Für diese Fragmentierungsaktion ist nur das Eingangsgerät verantwortlich, wobei die Fragmente am eigentlichen Endpunkt und nicht am Tunnelendpunkt wieder zusammengesetzt werden. 
• Diese Art der Paketfragmentierung ist weniger ressourcenintensiv. 

### Tunnel Source Device: Tunnel IP MTU 1400 | Interface MTU 1500 ###

C9300#ping 172.16.1.1 source Loopback 1 size 1500 repeat 10 <-- ping with size over IP MTU 1400
Type escape sequence to abort.
Sending 100, 1500-byte ICMP Echos to 172.16.1.1, timeout is 2 seconds:
Packet sent with a source address of 172.16.2.1
!!!!!!!!!!
Success rate is 100 percent (100/100), round-trip min/avg/max = 1/1/1 ms


### Tunnel Destination Device: Ingress Capture Twe1/0/1 ###
9500H#show monitor capture 1

Status Information for Capture 1
Target Type:
Interface: TwentyFiveGigE1/0/1, Direction: IN  <-- Ingress Physical interface 

9500H#sh monitor capture 1 buffer br | inc IPv4|ICMP
    9  22.285433   172.16.2.1 b^F^R 172.16.1.1 IPv4 1434 Fragmented IP protocol (proto=ICMP 1, off=0, ID=6c03)
   10  22.285526   172.16.2.1 b^F^R 172.16.1.1 ICMP 162 Echo (ping) request id=0x0004, seq=0/0, ttl=255
   11  22.286295   172.16.2.1 b^F^R 172.16.1.1 IPv4 1434 Fragmented IP protocol (proto=ICMP 1, off=0, ID=6c04)
   12  22.286378   172.16.2.1 b^F^R 172.16.1.1 ICMP 162 Echo (ping) request id=0x0004, seq=1/256, ttl=255

<-- Fragmentation occurs on the Inner ICMP packet (proto=ICMP 1)
<-- Fragments are not reassembled until they reach the actual endpoint device 172.16.1.1

Fragmentierung der Post-Tunnel-Kapselung 

Fragmentierung des eigentlichen Tunnelpakets zur Reduzierung der MTU, sobald die Kapselung erfolgt ist, aber das Gerät erkennt, dass die MTU zu groß ist.

• In diesem Fall ist das Tunnelziel das Gerät, das für die Fragmentreassemblierung verantwortlich ist, und nicht der echte Zielendpunkt. 
• Dieser Fall tritt auf, wenn ein Konfigurationsproblem vorliegt. Das Gerät ist auf eine höhere IP-MTU eingestellt, als die tatsächliche Port- oder System-MTU verarbeiten kann, nachdem Tunnel-Header angewendet wurden.
• In diesem Fall muss die Tunnelquelle den Tunnel selbst fragmentieren, und das Tunnelziel muss die Tunnel-Header neu assemblieren, um die Pakete an den nächsten Hop oder das nächste Ziel zu senden. 
• Diese Art der Header-Fragmentierung kann den Verarbeitungsaufwand erheblich erhöhen. Sie hängt von der Rate der Datenflüsse ab, die verarbeitet werden müssen. 
• Je nach Plattform, Code und Datenverkehrsrate werden auch Paketverluste und -verluste im CoPP-Class-Forus-Datenverkehr festgestellt.
  

### Tunnel Source Device: Tunnel IP MTU 1500 | Interface MTU 1500 ###
C9300(config-if)#ip mtu 1500
%Warning: IP MTU value set 1500 is greater than the current transport value 1476, fragmentation may occur 
<-- Device warns the user that this can cause fragmentation (this is a configuration issue)


### Tunnel Destination Device: Ingress Capture Twe1/0/1 ###
9500H#show monitor capture 1

Status Information for Capture 1
Target Type:
Interface: TwentyFiveGigE1/0/1, Direction: IN <-- Ingress Physical interface 

9500H#sh monitor capture 1 buffer br | i IPv4|ICMP
    1   0.000000  192.168.1.2 b^F^R 192.168.1.1  IPv4 1514 Fragmented IP protocol (proto=Generic Routing Encapsulation 47, off=0, ID=4501)
    2   0.000042   172.16.2.1 b^F^R 172.16.1.1   ICMP 60 Echo (ping) request id=0x0005, seq=0/0, ttl=255
    3   2.000598  192.168.1.2 b^F^R 192.168.1.1  IPv4 1514 Fragmented IP protocol (proto=Generic Routing Encapsulation 47, off=0, ID=4502)
    4   2.000642   172.16.2.1 b^F^R 172.16.1.1   ICMP 60 Echo (ping) request id=0x0005, seq=1/256, ttl=255

<-- Fragmentation has occurred on the outer GRE header(proto=Generic Routing Encapsulation 47)
<-- Fragments must be reassembled at the Tunnel endpoint, in this case the 9500

Cisco Bug-IDs

Die Cisco Bug-ID CSCvr84911 System-MTU wird nach dem Neuladen nicht beachtet.

Cisco Bug-ID CSCvq30464CAT9400: MTU-Konfiguration nicht auf inaktive Ports angewendet, die aktiviert werden.

Cisco Bug-ID Der nicht standardmäßige System-MTU-Konfigurationswert CSCvh04282 Cat9300 wird nach dem Neuladen nicht beachtet.

Zugehörige Informationen 

• Technischer Support und Dokumentation für Cisco Systeme
• Konfigurationsanleitung für Schnittstellen- und Hardwarekomponenten, Cisco IOS® XE Amsterdam 17.3.x (Catalyst Switches der Serie 9500)
• Konfigurationsanleitung für Schnittstellen- und Hardwarekomponenten, Cisco IOS® XE Amsterdam 17.3.x (Catalyst Switches der Serie 9600)
• Behebung von IPv4-Fragmentierung, MTU-, MSS- und PMTUD-Problemen mit GRE und IPSec