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.
Leider funktioniert das nicht, der Wireshark kennzeichnet das auch in rot.
Hexadezimal kann ich das dem Cisco auch nicht beibringen
LG Win10Gegner
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
!
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
cisco886va(dhcp-config)#option 26 hex 0x5c0
% DHCP could not parse the hexadecimal string. Check character 0 (0).
LG Win10Gegner
Please also mark the comments that contributed to the solution of the article
Content-ID: 584531
Url: https://administrator.de/contentid/584531
Printed on: October 4, 2024 at 02:10 o'clock
32 Comments
Latest comment
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 ...
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.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 ...
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.
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
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
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 ?!
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 ?!
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 ?
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 ?
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 ?
Keine Ahnung was sich da verschluckt hat...???
Die v6 ICMP Typen hast du alle in der CBAC ACL Liste freigegeben ?
Ä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
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
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.
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.
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
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.