parasprinter 10 Geschrieben 12. November 2009 Melden Teilen Geschrieben 12. November 2009 Hallo zusammen, bin hier schon auf einen Beitrag aus dem Jahr 2006 gestoßen in welchem wer beschrieben hat wie an einem X1200 die MTU zu ändern ist. ifstat --> index für die Verbindung ( die zu ändern ist) notieren. IpExtIfTable indexNummer TcpMssClamping:1492 ( Beispiel) cmd=save Bei meinem R3000 komm ich da net so recht weiter Zentrale:> ifstat 010001 WIZ_XDSL_INT ppp 1492 100M up 31486335 0 31577366 0 8 00:01:12 so und nun die Problematik: Zentrale:> IpExtifTable 010001 TcpMssClamping:1200 illegal char , only <NL>, <digit>, are allowed here. inx Index(*ro) RipSend(rw) RipReceive(rw) ProxyArp(rw) Nat(rw) NatRmvFin(rw) NatTcpTimeout(rw) NatOtherTimeout(rw) NatOutXlat(rw) Accounting(rw) TcpSpoofing(rw) AccessAction(rw) AccessReport(rw) Ospf(rw) OspfMetric(rw) TcpCksum(rw) BackRtVerify(rw) RuleIndex(rw) Authentication(rw) AuthMode(rw) AuthLifeTime(rw) AuthKeepalive(rw) RouteAnnounce(rw) IpFragmentation(rw) Rerouting(rw) BodRuleIndex(rw) QosRuleIndex(rw) IpsecAccounting(rw) Multicast(rw) NatSilentDeny(rw) NatPPTPXlat(rw) TcpMssClamping(rw) NbdgmRelayAddress(rw) NatMaxSessions(rw) AllowedPeers(rw) NatFlush(rw) 0 1000 none none off off yes 3600 30 on off off ignore info passive auto check off 1 off strict 3600 60 up_dormant enabled enabled 0 0 ipsec off disabled disabled -1 0.0.0.0 4000 all on Press <RETURN> to continue or <q> to quit. q Zentrale:ipExtIfTable> Finde leider keinen Hinweis wie die Syntax korrekt geschrieben werden muss um hier den MTU Wert zu ändern. Der Router hängt mit Eth5 an einem S-DSL Modem. T-Systems rät hier da VPN eingesetzt wird die MTU zu verändern. Kann mir dabei wer nen Tipp geben wie das geht? Gruß und Danke Michael Zitieren Link zu diesem Kommentar
Muffel 11 Geschrieben 13. November 2009 Melden Teilen Geschrieben 13. November 2009 Ja, so ein Bintec lässt sich nicht von jedem konfigurieren! :D Gib an der Konsole nur IpExtifTable ein. Die Ausgabe sollte wie folgt aussehen: [color="Magenta"]inx Index(*ro)[/color] RipSend(rw) RipReceive(rw) ProxyArp(rw) Nat(rw) NatRmvFin(rw) NatTcpTimeout(rw) NatOtherTimeout(rw) NatOutXlat(rw) Accounting(rw) TcpSpoofing(rw) AccessAction(rw) AccessReport(rw) Ospf(rw) OspfMetric(rw) TcpCksum(rw) BackRtVerify(rw) RuleIndex(rw) Authentication(rw) AuthMode(rw) AuthLifeTime(rw) AuthKeepalive(rw) RouteAnnounce(rw) IpFragmentation(rw) Rerouting(rw) BodRuleIndex(rw) QosRuleIndex(rw) IpsecAccounting(rw) Multicast(rw) NatSilentDeny(rw) NatPPTPXlat(rw) TcpMssClamping(rw) NbdgmRelayAddress(rw) NatMaxSessions(rw) AllowedPeers(rw) NatFlush(rw) [color="Magenta"]0 1000[/color] none none off off yes 3600 30 on off off ignore info passive auto check off 1 off strict 3600 60 up_dormant enabled enabled 0 0 ipsec off disabled disabled -1 0.0.0.0 4000 all on Press <RETURN> to continue or <q> to quit. q Ich habe etwas farblich hervorgehoben. Oben stehen die Variablen-Namen (ro=read only, rw= les- und schreibbar), unten die dazugehörigen Werte. Drücke so oft Return, bis das DSL-Interface erscheint (bei dir vermutlich 10001). Die davor stehende Zahl ist der Index des Interfaces (oben die rosa 1). Sagen wir der Wert ist 5. Mit diesem Index musst du dann den Befehl TcpMssClamping:5=1456 eingeben. 1456 ist die gewünschte MTU-Size. Default ist -1. Anschließend mit cmd=save die Änderung im Gerät sichern. In den VPN-Tunneln musst du den Eintrag "Propagate PMTU" bei den IPSec-Einstellungen der Phase2 auf YES setzen. Ergänzend liest du bitte noch Warum kleinere MTU-Size bei festen IP-Adressen? - onlinekosten.de Community T-DSL BIZ mit fester IP - Probleme mit MTU? - onlinekosten.de Community BTW: Gib noch update http: ein und aktualisiere den Router gleich noch. Zitieren Link zu diesem Kommentar
parasprinter 10 Geschrieben 13. November 2009 Autor Melden Teilen Geschrieben 13. November 2009 Hallo Muffel, ganz so wie du es beschreibst hab ichs nicht gemacht. Ich hab das inzwischen wie folgt gelöst ifstat pppextif Such mir dann mein Interface raus ( in meinem Fall 10001 ) Mtu:0=1200 cmd=save ifstat 10001 reset Warum gehst du über TcpMssClamping?? Router ist auf dem neuesten Stand - hab vergangene Woche ein komplettes Update durchgeführt. Deine Links werde ich mir gleich mal zu Gemüte führen. Vielen Dank schonmal... Zitieren Link zu diesem Kommentar
parasprinter 10 Geschrieben 13. November 2009 Autor Melden Teilen Geschrieben 13. November 2009 Hallo nochmal, habeben mal einen debug mitlaufen lassen.... 13:11:29 DEBUG/INET: NAT: delete session on ifc 10001 prot 6 192.168.99.76:4923/öffentliche IP:41861 <-> 195.30.94.138:80 13:11:33 DEBUG/INET: NAT: new outgoing session on ifc 10001 prot 6 192.168.99.76:4927/öffentliche IP:50055 -> 195.30.94.138:80 13:11:33 DEBUG/INET: interface 10001: TCP SYN [öffentliche IP:50055] -> [195.30.94.138:80] clamp MSS 1460 ==> 1160 13:11:33 DEBUG/INET: interface 10001: TCP SYNACK [195.30.94.138:80] -> [192.168.99.76:4927] clamp MSS 1460 ==> 1160 13:11:34 DEBUG/INET: NAT: delete session on ifc 10001 prot 6 192.168.99.76:4924/öffentliche IP:53347 <-> 195.30.94.138:80 13:11:38 DEBUG/INET: NAT: new outgoing session on ifc 10001 prot 6 192.168.99.76:4928/öffentliche IP:54348 -> 195.30.94.138:80 13:11:38 DEBUG/INET: interface 10001: TCP SYN [öffentliche IP:54348] -> [195.30.94.138:80] clamp MSS 1460 ==> 1160 13:11:39 DEBUG/INET: NAT: delete session on ifc 10001 prot 6 192.168.99.76:4925/öffentliche IP:51737 <-> 195.30.94.138:80 Kann mir wer sagen warum hierbei Pakete verloren gehen? Zitieren Link zu diesem Kommentar
Muffel 11 Geschrieben 15. November 2009 Melden Teilen Geschrieben 15. November 2009 Warum gehst du über TcpMssClamping?? Weil das eine richtige Vorgehensweise ist und es so auch von Funkwerk vorgegeben wird. Hallo nochmal, habeben mal einen debug mitlaufen lassen.... 13:11:29 DEBUG/INET: NAT: delete session on ifc 10001 prot 6 192.168.99.76:4923/öffentliche IP:41861 <-> 195.30.94.138:80 13:11:33 DEBUG/INET: NAT: new outgoing session on ifc 10001 prot 6 192.168.99.76:4927/öffentliche IP:50055 -> 195.30.94.138:80 13:11:33 DEBUG/INET: interface 10001: TCP SYN [öffentliche IP:50055] -> [195.30.94.138:80] clamp MSS 1460 ==> 1160 13:11:33 DEBUG/INET: interface 10001: TCP SYNACK [195.30.94.138:80] -> [192.168.99.76:4927] clamp MSS 1460 ==> 1160 13:11:34 DEBUG/INET: NAT: delete session on ifc 10001 prot 6 192.168.99.76:4924/öffentliche IP:53347 <-> 195.30.94.138:80 13:11:38 DEBUG/INET: NAT: new outgoing session on ifc 10001 prot 6 192.168.99.76:4928/öffentliche IP:54348 -> 195.30.94.138:80 13:11:38 DEBUG/INET: interface 10001: TCP SYN [öffentliche IP:54348] -> [195.30.94.138:80] clamp MSS 1460 ==> 1160 13:11:39 DEBUG/INET: NAT: delete session on ifc 10001 prot 6 192.168.99.76:4925/öffentliche IP:51737 <-> 195.30.94.138:80 Kann mir wer sagen warum hierbei Pakete verloren gehen? Da steht aber rein gar nichts von Paketverlusten! Ich vermute dir fehlen grundlegende Kenntnisse in Netzwerkgrundlagen, hier insbesondere der komplette Ablauf einer TCP-Session (Protokoll 6) und der Aufbau von IP-Paketen. Lies doch mal das: Transmission Control Protocol ? Wikipedia Warum du eine irrsinnig kleine Paketgröße von 1200 einstellst kannst du vermutlich auch nicht sagen. In dem Bereich sollte man über gutes Wissen verfügen und es nicht mittels trial and error probieren. BTW: Siehst du in deinem DEBUG ALL das "clamp MSS"? Genau deshalb geht man über TcpMssClamping. Den Unterschied zwischen MTU und MSS kannst du dir hhier erlesen: Transmission Control Protocol ? Wikipedia, Maximum Segment Size ? Wikipedia, Maximum Transmission Unit ? Wikipedia. Zitieren Link zu diesem Kommentar
parasprinter 10 Geschrieben 16. November 2009 Autor Melden Teilen Geschrieben 16. November 2009 Ich vermute dir fehlen grundlegende Kenntnisse in Netzwerkgrundlagen, hier insbesondere der komplette Ablauf einer TCP-Session (Protokoll 6) und der Aufbau von IP-Paketen. Damit könntest du zum Teil recht haben, geb ich offen und ehrlich zu. Mir bleibt nichts anderes übrig als mich in das Thema mal näher einzulesen. Diese "irrsinnig kleine Paketgröße" hat jedoch nichts mit "trial and error" zu tun. Diese Vorgabe habe ich von der T-Systems erhalten ich solle diesen Wert doch mal einstellen. Verstehe ich Deinen Hinweis auf das TcpMssClamping richtig so werden die Pakete ja eh automatisch fragmentiert um diese korrekt zu versenden. Warum ich das mittels "Mtu:0=1200" gelöst habe kann ich dir auch erklären - Diese Info kam von der Bintec Support Hotline. Und jetzt widme ich mich mal der Lektüre. Vielen Dank Zitieren Link zu diesem Kommentar
Empfohlene Beiträge
Schreibe einen Kommentar
Du kannst jetzt antworten und Dich später registrieren. Falls Du bereits ein Mitglied bist, logge Dich jetzt ein.