03.07.2020

3309

Cisco IOS MTU per DHCP festlegen

Hallo,
ich habe nun den Übeltäter gefunden, der dafür sorgt, dass manche Seiten nicht aufrufbar sind, da laufen dann minutenlang TLS-Handshakes.
Da ich einen SIT-Tunnel für IPv6 nutze, muss laut Hurricane Electric die MTU am PC auf 1472 gesetzt werden (wie beim Tunnel auch).
Sobald ich das manuell mache funktioniert auch der Seitenaufruf.
Standard am PC ist 1500.

1. Die MUT gilt ja für alle Ethernet-Pakete, die da rausgehen.
Kommt es zu Problemen, wenn man global die MTU auf 1472 setzt?

2.
Ich würde das gerne per DHCP über den DHCP-Server des Cisco machen, da gibt es auch die Möglichkeit, die Option 26 (MTU) festzulegen.

ip dhcp pool ryzen-m
 host 10.0.0.77 255.255.255.0
 client-identifier xxxxxxx
 dns-server 10.0.0.254 
 default-router 10.0.0.254 
 option 26 ascii 1472
!

Leider funktioniert das nicht, der Wireshark kennzeichnet das auch in rot.

Frame 1511: 342 bytes on wire (2736 bits), 342 bytes captured (2736 bits) on interface enp6s0, id 0
Ethernet II, Src: _gateway (b8:38:61:d1:b5:5c), Dst: ubuntu-Ryzen.local (00:0e:2e:91:1a:8a)
Internet Protocol Version 4, Src: _gateway (10.0.0.254), Dst: ubuntu-Ryzen.local (10.0.0.77)
User Datagram Protocol, Src Port: bootps (67), Dst Port: bootpc (68)
Dynamic Host Configuration Protocol (Offer)
    Message type: Boot Reply (2)
    Hardware type: Ethernet (0x01)
    Hardware address length: 6
    Hops: 0
    Transaction ID: 0x457edf0b
    Seconds elapsed: 0
    Bootp flags: 0x0000 (Unicast)
    Client IP address: 0.0.0.0 (0.0.0.0)
    Your (client) IP address: ubuntu-Ryzen.local (10.0.0.77)
    Next server IP address: 0.0.0.0 (0.0.0.0)
    Relay agent IP address: 0.0.0.0 (0.0.0.0)
    Client MAC address: ubuntu-Ryzen.local (00:0e:2e:91:1a:8a)
    Client hardware address padding: 00000000000000000000
    Server host name not given
    Boot file name not given
    Magic cookie: DHCP
    Option: (53) DHCP Message Type (Offer)
    Option: (54) DHCP Server Identifier (10.0.0.254)
    Option: (51) IP Address Lease Time
    Option: (58) Renewal Time Value
    Option: (59) Rebinding Time Value
    Option: (1) Subnet Mask (255.255.255.0)
    Option: (6) Domain Name Server
    Option: (3) Router
    Option: (26) Interface MTU
        Length: 4
        Value: 31343732
       [Expert Info (Error/Protocol): length isn't 2]  
            [length isn't 2]  
            [Severity level: Error]
            [Group: Protocol]
    Option: (42) Network Time Protocol Servers
    Option: (255) End
    Padding: 0000

Hexadezimal kann ich das dem Cisco auch nicht beibringen

cisco886va(dhcp-config)#option 26 hex 0x5c0
% DHCP could not parse the hexadecimal string. Check character 0 (0).

LG Win10Gegner

Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben

Content-ID: 584531

Url: https://administrator.de/forum/cisco-ios-mtu-per-dhcp-festlegen-584531.html

Ausgedruckt am: 23.05.2025 um 06:05 Uhr

32 Kommentare

Neuester Kommentar

Auf dem Client musst du nicht von Hand an der MTU drehen, das ist Blödsinn. Auf dem Router sollte die MTU aber passend für den Tunnel gesetzt sein. Durch "Path MTU Discovery" wird die maximale Größe der Pakete meist sowieso dem Client mitgeteilt.

Das ganze funktioniert dann ganz grob wie folgt: Dein Rechner versucht mittels seiner Standard MTU ein Packet zu senden. Der erste Router, welcher auf dem jeweiligen Interface eine andere MTU braucht, meldet per ICMP, dass der Rechner zu einer gewissen MTU runter regeln muss. Sobald dies erfolgt ist, wird für die jeweilige Verbindung nur noch die passende MTU verwendet.
https://www.cisco.com/c/en/us/support/docs/ip/generic-routing-encapsulat ...

Kommt es zu Problemen, wenn man global die MTU auf 1472 setzt?

Nein, aber kleinere Pakete == geringerer Durchsatz.

Der Tunnel hat eine MTU von 1472 am Cisco.
Das hat auch der HE-Support gefragt.

Soll ich mal die problematische Seite aufrufen und das im Wireshark mitsniffen und das hier hochladen?
Ich stelle dann die MTU am PC wieder auf 1500, dann sollten ja die ICMP-Pakete geschickt werden.

What is PMTUD?

muss laut Hurricane Electric die MTU am PC auf 1472 gesetzt werden

Allseits bekanntes Problem ! Guckst du hier:
https://www.cisco.com/c/en/us/support/docs/long-reach-ethernet-lre-digit ...
Die Paket Overheads und die daraus resultierende MTU kannst du dir auch ganz einfach selber zusammenrechnen. Guckst du hier:
https://baturin.org/tools/encapcalc/

Was vermutlich falsch ist, ist die Tatsache das du der Option 26 einen ascii Wert zugewiesen hast. Das ist es aber nicht sondern ein Binärwert (2 Bytes) !
http://www.networksorcery.com/enp/protocol/bootp/option026.htm
Deshalb zeigt der Wireshark als Option Content auch so einen vollig wirren Wert von 31343732 an.
Der Kollege @latavia hat aber absolut Recht oben, denn das gibst du ja nie dem Endgerät mit oder solltest es wenigstens nicht. Die Endgeräte kaspern das immer mit der MTU Patch Discovery selber aus.
Der Router sollte nur immer die korrekten MTUs bzw. die MSS Werte gesetzt haben !
Laut deiner_Konfig hast du das ja auch richtig gemacht sollte diese noch stimmen ?!
Hier sind die Zusammenhänge recht gut dokumentiert:
https://networklessons.com/cisco/ccie-routing-switching/pppoe-mtu-troubl ...
Wenn du das anpasst sollte das fehlerlos klappen. Zusätzlich solltest du noch ip tcp path-mtu-discovery auf dem Router konfigurieren.
Auch direkt unter dem Tunnel Interface gibt es ein spezifisches Kommando zur automatischen Patch Discovery bei Cisco.
https://www.cisco.com/c/en/us/support/docs/ip/generic-routing-encapsulat ...

Obwohl also die Syntax mit ascii vorschlägt, soll ich einen Binärwert eingeben. Interessant.

Wie muss dieser denn dann eingegeben werden?
1472 zu bin wäre dann 0b10111000000
Ist das dann so einzugeben oder ohne das 0b am Anfang?

cisco886va(dhcp-config)#option 26 ?
  ascii     Data is an NVT ASCII string
  hex       Data is a hexadecimal string
  instance  Specify the option instance
  ip        Data is one or more IP addresses

cisco886va(dhcp-config)#option 26 

Welche Option soll ich davon nehmen?

soll ich einen Binärwert eingeben. Interessant.

Du siehst ja im Wireshark Trace das der "ascii" Wert 1472 im Paket in einem irrealen Wert von 31343732 endet. Folglich kann ja dann das Format nicht stimmen.
Gib mal spaßeshalber einen Wert von ascii 10 ein und check mal den Wireshark was daraus wird.
Kannst du dir vermutlich sparen und gleich option 26 ascii "1472" eingeben.
Das sollte dann eigentlich den richtigen Wert auch im Wireshark erbringen.

Das geht leider auch nicht.

ip dhcp pool ryzen-m
 host 10.0.0.77 255.255.255.0
 client-identifier 0100.0e2e.911a.8a
 dns-server 10.0.0.254 
 default-router 10.0.0.254 
 option 26 ascii "1472"  
!         

Frame 307: 342 bytes on wire (2736 bits), 342 bytes captured (2736 bits) on interface enp6s0, id 0
Ethernet II, Src: Cisco_d1:b5:5c (b8:38:61:d1:b5:5c), Dst: ubuntu-Ryzen.local (00:0e:2e:91:1a:8a)
Internet Protocol Version 4, Src: _gateway (10.0.0.254), Dst: ubuntu-Ryzen.local (10.0.0.77)
User Datagram Protocol, Src Port: bootps (67), Dst Port: bootpc (68)
Dynamic Host Configuration Protocol (ACK)
    Message type: Boot Reply (2)
    Hardware type: Ethernet (0x01)
    Hardware address length: 6
    Hops: 0
    Transaction ID: 0x87b34a1e
    Seconds elapsed: 0
    Bootp flags: 0x0000 (Unicast)
    Client IP address: 0.0.0.0 (0.0.0.0)
    Your (client) IP address: ubuntu-Ryzen.local (10.0.0.77)
    Next server IP address: 0.0.0.0 (0.0.0.0)
    Relay agent IP address: 0.0.0.0 (0.0.0.0)
    Client MAC address: ubuntu-Ryzen.local (00:0e:2e:91:1a:8a)
    Client hardware address padding: 00000000000000000000
    Server host name not given
    Boot file name not given
    Magic cookie: DHCP
    Option: (53) DHCP Message Type (ACK)
    Option: (54) DHCP Server Identifier (10.0.0.254)
    Option: (51) IP Address Lease Time
    Option: (58) Renewal Time Value
    Option: (59) Rebinding Time Value
    Option: (1) Subnet Mask (255.255.255.0)
    Option: (6) Domain Name Server
    Option: (3) Router
    Option: (26) Interface MTU
        Length: 4
        Value: 31343732
        [Expert Info (Error/Protocol): length isn't 2]  
    Option: (42) Network Time Protocol Servers
    Option: (255) End
    Padding: 0000

Dann stimmt das ascii Format wie befürchtet nicht. Laut Defintion ist das ein 2 Byte Werte also numerisch oder binär. Das Format doer der Wer tist falsch.
Aber wie gesagt, versteif dich nicht so dehr drauf. Normal kaspern entgeräte das immer über die Path MTU Discovery automatisch aus. Bei IPv6 ist das zudem absolute Pflicht und fest im Protokoll implementiert:
Siehe hier:
https://danrl.com/projects/ipv6-workshop/
Seite 68 und Kapitel 5

Sobald die MTU 1500 ist (Standard), sind bestimmte Seiten nicht mehr nutzbar, ein Beispiel wäre rt.com
Der TLS-Handshake dauert so 10 Minuten.
Setzt man die MTU auf 1472 geht alles normal.

Wo denn ?? Auf dem Endgerät ?
Wie gesagt wenn du am Cisco lokalen LAN die MSS auf 1452 setzt bist du immer im sicheren Bereich. das Endgerät sendet dann keine Frames größer 1452.
Die MTUs der Tunnel und PPPoE Interfaces (Dialer) sollten natürlich auch stimmen.
Wie gesagt, bei IPv6 ist die MTU Discovery fest ins Protokoll eingebaut. Dort kann es also niemals zu Mismatches kommen wenn die MTU Werte im Router bzw. dem gesamten Pfad stimmen.
Im Buch ist ein SiXX Tunnel Beispiel beschrieben bei dem die MTU erheblich geringer ist. 1270.
Bist du dir also sicher das deine stimmt ?!

interface Vlan1
 description internal_LAN
 ip address 10.0.0.254 255.255.255.0
 ip nat inside
 ip virtual-reassembly in
 ip tcp adjust-mss 1452
 ipv6 address xxxx/64
 ipv6 enable
 ipv6 nd other-config-flag
 ipv6 dhcp server DHCPv6

Sollte passen, aber der PC (Ubuntu) hat immer eine von 1500, es sei denn ich lege die manuell fest (in meinem Fall auf 1472).
Sobald ich die am PC von 1500 auf 1472 setze, ist alles ok. Sonst eben nicht.

Siehe hier:
https://www.cellstream.com/reference-reading/tipsandtricks/407-ipv6-path ...
Zitat:
"My understanding from reading the Ubuntu docs on this is that whatever you have set for the IPv4 probing, the IPv6 stack mimicks the setting."
Also sysctl net.ipv4.tcp_mtu_probing im /etc/sysctl aktivieren was die MTU Discovery aktiviert.
Hast du das gemacht in deinem Ubuntu ?

Jetzt ja, ändert aber nichts an der Sache, ich habe die MTU vorher wieder auf 1500 gesetzt.
Ich habe da aber vorher nie irgendwas eingestellt.
Setze ich sie wieder manuell auf 1472 geht wieder alles.

Krank...raff ich aber dann auch nicht warum.

Sollte so eigentlich nicht sein.
Welche Seite macht diese Kinken ? Ich teste das hier mit einem nativen IPv6 Anschluss auch mal aus.

Aufgefallen ist es mir bei rt.com und deutsch.com, bei anderen Seiten bisher nicht.

Wie verlief denn der Test?

An einem zweiten Standort mit FB7490 und HE-Tunnel geht alles problemlos, das ist auch ein Ubuntu 20.04, die MTU ist beim Adapter auch 1500, da habe ich nichts manuell eingestellt.
Die Seiten sind da problemlos aufrufbar.

Hier bei nativem v6 (Telekom) und Cisco Router (15.7er latest IOS) komplett problemlos und keine Fehler. Es sind die gleichen MTU/MSS Settings wie hier im Cisco_Tutorial beschrieben.
Keine Ahnung was sich da verschluckt hat...???
Die v6 ICMP Typen hast du alle in der CBAC ACL Liste freigegeben ?

cisco886va#sh run | begin access-list
access-list 23 permit 10.0.0.0 0.0.0.255
access-list 101 permit ip 10.0.0.0 0.0.0.255 any
access-list 111 permit tcp any any eq 22
access-list 111 permit tcp any any eq 443
access-list 111 permit tcp any any eq ftp-data
access-list 111 permit tcp any any eq ftp
access-list 111 permit tcp any eq domain any
access-list 111 permit icmp any any unreachable
access-list 111 permit icmp any any time-exceeded
access-list 111 permit icmp any any timestamp-reply
access-list 111 permit icmp any any echo
access-list 111 permit icmp any any
access-list 111 permit 41 any any
access-list 111 permit ipinip any any
access-list 111 permit tcp any any eq 51413
access-list 111 permit udp any any eq 51413
access-list 111 permit icmp any any administratively-prohibited
access-list 111 permit icmp any any echo-reply
access-list 111 permit icmp any any packet-too-big
access-list 111 permit ip any any
access-list 111 permit udp any eq 5060 any

access-list 111 permit icmp any any
sollte alles was mit ICMP zu tun hat durchlassen. Betrifft das auch ICMPv6?
Ich habe im Tunnel keine Firewall aktiviert (kein ip inspect myfw out).

Vorsicht, das oben sind IPv4 ACLs aber keine v6 ACLs ! Die sind separat !!
ipv6 access-list access-list-name

Da habe ich keine angelegt.
Soll ich eine anlegen?
Müsste dann nicht auch auf dem Tunnel-Interface was konfiguriert werden?

Ähhh...ja ! So wirken die ACL ja nicht die die v6 ICMPs passieren lassen müssen !!
https://www.net.in.tum.de/fileadmin/TUM/NET/NET-2016-09-1/NET-2016-09-1_ ...
Kapitel: 3.2, Seite 5
Und auch hier:
https://tools.ietf.org/html/rfc4890

Du hast wieder mal deine eigenen Threads nicht richtig gelesen !!!
DHCPv6 mit DNS unter Cisco IOS einrichten

Ich nutze nicht die Zonen-FW, sondern die CBAC-FW.
Daher frage ich, wie das dann umgesetzt werden muss.
Ich möchte gerne da nichts blockieren.

Das ist egal. Der Cisco unterscheidet strikt zwischen v6 und v4 ACLs ! Die werden immer mit ipv6 access-list... konfiguriert. Dort gibt es auch ganz andere ICMP Typen, da v6 erheblich mehr ICMP nutzt als v4. Siehe Workshop Buch oden !

Ich habe nun eine angelegt.

Im Tunnel0

 ipv6 traffic-filter ipv6acl in

ipv6 access-list ipv6acl
 permit ipv6 any any
 permit icmp any any
 permit udp any any
 permit tcp any any
 permit icmp any any packet-too-big
 permit icmp any any destination-unreachable
 permit icmp any any parameter-problem

Leider führt auch das nicht zum Ziel.
Wenn ich es richtig verstanden habe wäre diese ACL redundant, da permit icmp any any die letzten 3 Zeilen auch abdeckt.

Deinen ACL ist nicht nur falsch sondern auch noch gefährlich, denn damit lässt du jeglichen v6 Traffic von außen zu !!! (permit ipv6 any any)
Ein abolutes NoGo, denn das hebelt die CBAC Firewall aus !

Die Liste lautet:
ipv6 access-list ICMPv6
permit icmp any any unreachable
permit icmp any any packet-too-big
permit icmp any any hop-limit
permit icmp any any reassembly-timeout
permit icmp any any header
permit icmp any any next-header
permit icmp any any parameter-option
permit icmp any any echo-request
permit icmp any any echo-reply
permit icmp any any dhaad-request
permit icmp any any dhaad-reply
permit icmp any any mpd-solicitation
permit icmp any any mpd-advertisement
!
Die v4 ACL entsprechend:
access-list 111 permit icmp any any administratively-prohibited
access-list 111 permit icmp any any echo-reply
access-list 111 permit icmp any any packet-too-big
access-list 111 permit icmp any any time-exceeded
access-list 111 permit icmp any any unreachable

Auf dem Dialer Interface kommt dann einzig nur die v4 Liste zum Einsatz ! Logisch, denn dein v6 ist ja da noch getunnelt in v4 und unsichtbar für das Dialer Interface !
interface Dialer0
description xDSL Einwahl Interface Internet
ip address negotiated
ip access-group 111 in

Auf dem Tunnel Interface aber was ja dein natives v6 Interface ist:
interface Tunnel0
description Hurricane Electric IPv6 Tunnel Broker
no ip address
ip inspect myfw out
ipv6 address 2001:470:xxx:xxx::2/64
ipv6 enable
ipv6 mtu 1472
ipv6 accress-group ICMPv6 in
tunnel source eigene IP
tunnel mode ipv6ip
tunnel destination 216.66.80.30
!
Ohne eine ACL auf dem Tunnel Interface blockiert die CBAC Firewall doch sämtliche eingehenden ICMPv6 Steuer Pakete.

Da IPv4 funktioniert ändere ich da nichts.

ipv6 access-group gibt es im Tunnel-Int nicht.
Es gibt ipv6 traffic-filter ipv6acl in, das wird auch auf ne Cisco-Seite genannt, das ist im Tunnel-Int eingetragen.

Sobald ich

permit ipv6 any any

entferne, kann man keine Internetseiten per IPv6 mehr aufrufen.

ipv6 access-list ipv6acl
 sequence 70 permit icmp any any parameter-problem      //wundert mich, da ich das nie so eingegeben habe und wenn man es löscht und wieder erstellt sich die Zahl um 10 erhöht //
 permit icmp any any unreachable
 permit icmp any any hop-limit
 permit icmp any any reassembly-timeout
 permit icmp any any header
 permit icmp any any next-header
 permit icmp any any parameter-option
 permit icmp any any echo-request
 permit icmp any any echo-reply
 permit icmp any any dhaad-request
 permit icmp any any dhaad-reply
 permit icmp any any mpd-solicitation
 permit icmp any any mpd-advertisement
 permit icmp any any packet-too-big
 permit icmp any any   //sollte eigentlich alles an ICMP durchlassen
 permit ipv6 any any   //ohne kein Surfen möglich

Wenn aber hier alles an ICMP durchgelassen wird, müsste es ja kein Problem geben, der TLS-Handshake läuft aber weiterhin.

entferne, kann man keine Internetseiten per IPv6 mehr aufrufen.

Kann eigentlichnicht sein ! Die CBAC Firewall lässt ja einzig nur das passieren was ein gesetzte ACK Bit hat bzw. was einen aktiven CBAC Eintrag hat.
Du hast vermutlich die CBAC Firewall gar nicht für IPv6 konfiguriert, oder ?
https://www.cisco.com/en/US/docs/ios-xml/ios/sec_data_cbac_fw/configurat ...
bzw.
https://www.cisco.com/en/US/docs/ios-xml/ios/sec_data_cbac_fw/configurat ...
Was umso fataler wäre...
Guckst du auch hier:
https://www.youtube.com/watch?v=bBSYag-DBPE

Ich habe das mit inspect jetzt eingerichtet, leider geht es noch immer nicht, es ist wohl noch was falsch.

cisco886va#sh ipv6 inspect config
Session audit trail is disabled
Session alert is enabled
Routing Header inspection is disabled
one-minute (sampling period) thresholds are [2147483647:2147483647] connections
max-incomplete sessions thresholds are [2147483647:2147483647]
max-incomplete tcp connections per host is 4294967295. Block-time 0 minute.
tcp synwait-time is 30 sec -- tcp finwait-time is 5 sec
tcp idle-time is 3600 sec -- udp idle-time is 30 sec
icmp idle-time is 10 sec
Session hash table size is 1021
Inspection Rule Configuration
 Inspection name ipv6fw
    icmp alert is on audit-trail is off timeout 60
    tcp alert is on audit-trail is off timeout 3600
    udp alert is on audit-trail is off timeout 30

cisco886va#

cisco886va#sh ipv6 ins
cisco886va#sh ipv6 inspect inter
Interface Configuration
 Interface Tunnel0
  Inbound inspection rule is not set
  Outgoing inspection rule is ipv6fw
    icmp alert is on audit-trail is off timeout 60
    tcp alert is on audit-trail is off timeout 3600
    udp alert is on audit-trail is off timeout 30

cisco886va#

ipv6 access-list ipv6acl
 sequence 70 permit icmp any any parameter-problem
 permit icmp any any unreachable
 permit icmp any any hop-limit
 permit icmp any any reassembly-timeout
 permit icmp any any header
 permit icmp any any next-header
 permit icmp any any parameter-option
 permit icmp any any echo-request
 permit icmp any any echo-reply
 permit icmp any any dhaad-request
 permit icmp any any dhaad-reply
 permit icmp any any mpd-solicitation
 permit icmp any any mpd-advertisement
 permit icmp any any packet-too-big
 permit icmp any any
 permit ipv6 any any

interface Tunnel0
 no ip address
 ipv6 address 2001:470xxxxxx/64
 ipv6 enable
 ipv6 mtu 1472
 ipv6 inspect ipv6fw out
 ipv6 traffic-filter ipv6acl in
 tunnel source xxx
 tunnel mode ipv6ip
 tunnel destination 216.66.80.30

Die neue FW verlangsamt leider das Surfen erheblich, ich habe die FW jetzt wieder aus dem Tunnel rausgenommen, ist jetzt wieder wesentlich schneller.
Gibt es denn eine Option, das mitzuloggen, was verworfen wird?
Ich habe ja keine ACL aktiv, daher wird das nicht wie beschrieben funktionieren mit der ACL und dahinter log.

Gibt es denn eine Option, das mitzuloggen, was verworfen wird?

Ja, wenn du das ACL Logging aktivierst was die Sache aber noch langsamer macht (Process Switching über die CPU)

Ich habe ja keine ACL aktiv,

Wieso ? Oben sind doch zumindestens 2 ACLs aktiv ? Die am Dialer und die am Tunnel ? Unverständlich ??!
CBAC Statistiken und Drops zeigen die die sh ip inspect Kommandos.

Ich habe aus Leistungsgründen die ACL am Tunnel wieder deaktiviert, genauso wie inspect.
Am Dialer ist alles wie gehabt, weiterhin aktiv.

Da du sagst, dass ohne ACL ICMPv6 im Tunnel blockiert wird, würde ich das gerne sehen.
Wenn ich jetzt die ACL wieder eintrage habe ich ja nicht den Zustand ohne ACL, den ich gerne prüfen würde.