Hallo,
wir haben bei uns unsere Cisco Router gegen Lancoms abgelöst und jetzt einige Sprachprobleme untereinander.
Auf dem Lancom sind 2 Netze per VLAN Definiert (Voip + Daten) und ein Lancom ist an einer 2Mbit SDSL Leitung, sowie der in der Zentrale an einem 100Mbit CompanyConnect der Telekom.
Es handelt sich um 2 1711 Lancoms bei denen die Bandbreite für Qos auf dem Interface eingestellt ist.
Bisher habe ich mir 2 Regeln, Voip-IN + Voip-OUT erstellt und angepasst, die Optionen unter "IP-Router" für Diff-Serv Feld beachten ist aktiv und zum Probieren wurde die Option DiffServ-Tags aus Layer-2: Nach Layer-3 kopieren eingestellt.
Die Regel:
Allgemein
- Regel Aktiv
- Diese Regel hält die Verbindungszustände nach
Aktion
- Accept
QoS
- PMTU Reduzieren (derzeit wieder 512, vorher 256)
- Mindestbandbreite garantieren 128kbit/sekunde, Pro Station
Stationen
- Verbindungen von folgenden Stationen (Lokale Netz VOIP)
Dienste
- keine Einschränkungen
Die zweite Regel sieht genauso aus, nur das bei Stationen das VOIP Netz als Ziel eingetragen ist.
Wenn wir ein Telefonat führen, wird im Lanmonitor die Reservierung für RX,TX und PMTU angezeigt, jedoch wenn ich im VPN etwas kopieren fehlen mir einzelne Buchstaben und es ist abgehackt.
Wen ein Telefonat ohne Kopieren geführt wird, dann geht dies manchmal eine Weile ohne Probleme und dann kann meist einer den anderen nicht mehr verstehen.
Besten Dank für Eure Beispiele oder Hilfe schonmal vorab.
Sprachaussetzer bei VOIP über VPN trotz QoS
Moderator: Lancom-Systems Moderatoren
-
TitanChris
- Beiträge: 18
- Registriert: 07 Mär 2009, 13:43
-
Dr.Einstein
- Beiträge: 3241
- Registriert: 12 Jan 2010, 14:10
Huhu,
ich würde ein paar Einstellungen verändern, aber das ist je nach Anschluss und Anzahl der IP-Telefone etc. jedem selbst überlassen und "Feintuning".
Nur eine Firewallregel nach dem Muster:
DiffServ-Tags aus Layer-2: Nach Layer-3 kopieren wieder rausnehmen
Dafür sorgen, dass die IP-Telefone + TK Anlage auf DSCP: EF ihre Sprachpakete rauschicken, und für Steuerung zB SIP was anderes nutzen.
Die Regel:
Allgemein
- Regel Aktiv
- Diese Regel hält die Verbindungszustände nach
Aktion
- Accept
QoS
- Paketgröße einer Pakete auf 576 Byte
bei VPN + DiffServ: EF
- Mindestbandbreite garantieren 128kbit/sekunde, Pro Station
alternativ auf global setzen und erhöhten Wert
bei VPN + DiffServ: EF
- erzwungen
(ich persönlich finde Global besser, da es nicht das Risiko gibt, dass mehr Bandbreite reserviert wird, als dem Router überhaupt zur Verfügung steht)
Stationen
- keine Einschränkungen
Dienste
- keine Einschränkungen
Generell ist die Bandbreite bei der WAN Verbindung zu überprüfen. zB wenn du einen 2000er SDSL hast, nicht 2000 eintragen sondern den genauen Sync.Wert inkl. 36 Byte Overhead oder was du auch immer hast. Auf oder Abrunden um mehr als 100 Kbit/s macht die Sache schon interessant, da der Router denkt, dass er ja noch Luft hat und nix reservieren braucht ...
Aber wie gesagt, ist alles individuell bei jeder Vernetzung.
Gruß Dr.Einstein
ich würde ein paar Einstellungen verändern, aber das ist je nach Anschluss und Anzahl der IP-Telefone etc. jedem selbst überlassen und "Feintuning".
Nur eine Firewallregel nach dem Muster:
DiffServ-Tags aus Layer-2: Nach Layer-3 kopieren wieder rausnehmen
Dafür sorgen, dass die IP-Telefone + TK Anlage auf DSCP: EF ihre Sprachpakete rauschicken, und für Steuerung zB SIP was anderes nutzen.
Die Regel:
Allgemein
- Regel Aktiv
- Diese Regel hält die Verbindungszustände nach
Aktion
- Accept
QoS
- Paketgröße einer Pakete auf 576 Byte
bei VPN + DiffServ: EF
- Mindestbandbreite garantieren 128kbit/sekunde, Pro Station
alternativ auf global setzen und erhöhten Wert
bei VPN + DiffServ: EF
- erzwungen
(ich persönlich finde Global besser, da es nicht das Risiko gibt, dass mehr Bandbreite reserviert wird, als dem Router überhaupt zur Verfügung steht)
Stationen
- keine Einschränkungen
Dienste
- keine Einschränkungen
Generell ist die Bandbreite bei der WAN Verbindung zu überprüfen. zB wenn du einen 2000er SDSL hast, nicht 2000 eintragen sondern den genauen Sync.Wert inkl. 36 Byte Overhead oder was du auch immer hast. Auf oder Abrunden um mehr als 100 Kbit/s macht die Sache schon interessant, da der Router denkt, dass er ja noch Luft hat und nix reservieren braucht ...
Aber wie gesagt, ist alles individuell bei jeder Vernetzung.
Gruß Dr.Einstein
-
TitanChris
- Beiträge: 18
- Registriert: 07 Mär 2009, 13:43
Hallo,
danke für das Beispiel, werde es mal umsetzen.
Also die Packete der Anlage (Siemens Openscape) werden schon mit EF + AF31 im DSCP Feld versendet, das kontte ich auch im Trace des IP-Routers sehen.
Gibt es eine Übersicht welcher Overhead für welchen Anschluss anzusetzen ist? Derzeit habe ich 2048 + 36 Byte Overhead für den SDSL eingetragen, jedoch habe ich keine Ahnung was der Overhead beim CompanyConnect der Telekom ist.
Gruß
danke für das Beispiel, werde es mal umsetzen.
Also die Packete der Anlage (Siemens Openscape) werden schon mit EF + AF31 im DSCP Feld versendet, das kontte ich auch im Trace des IP-Routers sehen.
Gibt es eine Übersicht welcher Overhead für welchen Anschluss anzusetzen ist? Derzeit habe ich 2048 + 36 Byte Overhead für den SDSL eingetragen, jedoch habe ich keine Ahnung was der Overhead beim CompanyConnect der Telekom ist.
Gruß
-
Dr.Einstein
- Beiträge: 3241
- Registriert: 12 Jan 2010, 14:10
Hey TitanChris,
bei Siemens ist ja meist EF für Sprache und AF31 für Rest vorkonfiguriert, wobei ich beim QoS AF31 dann vernachlässigen würde.
Beim SDSL würde ich eher 2087 Kbit/s hinterlegen (2304 Brutto *48/53, Dokument dafür gibts in der Knowlegdebase von Lancom).
An der Zentrale 100 Mbit/s CoCo? Oder "nur" 10 ? Bei 10 ist die Frage, ob es über Kupfer läuft. Kupfer erkennt man auch am Produktnamen 10M Flex mit den Stufen 2,5 5 und 10 Mbit/s. Da wäre der Overhead 12 Byte bestehend aus 8 Byte SDH-Header + 4 Byte Prüf-Header. Die genauen Werte für Down/Upstream findest über Lanconfig / WAN mit dem ? auf Overhead.
Bei CoCo-Anschlüssen mit Glas gab es meines Wissens keinen Overhead, aber dafür genaue Dokumente zu finden macht keinen Spaß ...
Gruß Dr.Einstein
bei Siemens ist ja meist EF für Sprache und AF31 für Rest vorkonfiguriert, wobei ich beim QoS AF31 dann vernachlässigen würde.
Beim SDSL würde ich eher 2087 Kbit/s hinterlegen (2304 Brutto *48/53, Dokument dafür gibts in der Knowlegdebase von Lancom).
An der Zentrale 100 Mbit/s CoCo? Oder "nur" 10 ? Bei 10 ist die Frage, ob es über Kupfer läuft. Kupfer erkennt man auch am Produktnamen 10M Flex mit den Stufen 2,5 5 und 10 Mbit/s. Da wäre der Overhead 12 Byte bestehend aus 8 Byte SDH-Header + 4 Byte Prüf-Header. Die genauen Werte für Down/Upstream findest über Lanconfig / WAN mit dem ? auf Overhead.
Bei CoCo-Anschlüssen mit Glas gab es meines Wissens keinen Overhead, aber dafür genaue Dokumente zu finden macht keinen Spaß ...
Gruß Dr.Einstein
-
TitanChris
- Beiträge: 18
- Registriert: 07 Mär 2009, 13:43
Hallo Dr.Einstein,
besten Dank erst mal für die Vorschläge, habe mich bisher noch nicht gemeldet da ich das Ganze noch testen wollte.
Aber leider ist das Problem noch immer da das ich im Gespräch Fragmente habe dich in nicht verstehe, oder auch mein Gesprächspartner mich kurz nicht versteht. Das Problem ist meist nur kurz und fängt sich dann wieder.
Die Regeln greifen soweit auch Laut LanMonitor und machen so auch Sinn, aber trotzdem habe ich noch diese "Stolperer" beim Sprechen.
Habe noch überlegt den ganzen Traffic der Außenstelle über die Zentrale zu Routen, ggf. den MTU Wert für den Tunnel auf 1492 zu setzen?
Kann es evtl. auch daran liegen das der Lancom die LAN-Interfaces nicht priorisieren kann? Mehr Ideen habe ich bald nicht mehr außer vielleicht mit der Fragmentierung zu spielen.
Besten Dank und Gruß
besten Dank erst mal für die Vorschläge, habe mich bisher noch nicht gemeldet da ich das Ganze noch testen wollte.
Aber leider ist das Problem noch immer da das ich im Gespräch Fragmente habe dich in nicht verstehe, oder auch mein Gesprächspartner mich kurz nicht versteht. Das Problem ist meist nur kurz und fängt sich dann wieder.
Die Regeln greifen soweit auch Laut LanMonitor und machen so auch Sinn, aber trotzdem habe ich noch diese "Stolperer" beim Sprechen.
Habe noch überlegt den ganzen Traffic der Außenstelle über die Zentrale zu Routen, ggf. den MTU Wert für den Tunnel auf 1492 zu setzen?
Kann es evtl. auch daran liegen das der Lancom die LAN-Interfaces nicht priorisieren kann? Mehr Ideen habe ich bald nicht mehr außer vielleicht mit der Fragmentierung zu spielen.
Besten Dank und Gruß
-
Dr.Einstein
- Beiträge: 3241
- Registriert: 12 Jan 2010, 14:10
Hey TitanChris,
schade, dass es bis jetzt wenig gewirkt hat. Ich glaube aber auch nicht, dass die Aussetzer eine lanseitige Ursache haben.
Hast du in den QoS Regeln erzwingen aktiviert? Hast du auch einmal einfach mehr Bandbreite dem Gespräch reserviert bzw. globale Reservierung getestet?
Interessant wäre wirklich mal Volllast im Down/Upload zu verursachen und dann 2-3 Gespräche drüber führen.
Gruß Dr.Einstein
schade, dass es bis jetzt wenig gewirkt hat. Ich glaube aber auch nicht, dass die Aussetzer eine lanseitige Ursache haben.
Hast du in den QoS Regeln erzwingen aktiviert? Hast du auch einmal einfach mehr Bandbreite dem Gespräch reserviert bzw. globale Reservierung getestet?
Interessant wäre wirklich mal Volllast im Down/Upload zu verursachen und dann 2-3 Gespräche drüber führen.
Gruß Dr.Einstein
-
TitanChris
- Beiträge: 18
- Registriert: 07 Mär 2009, 13:43
Hallo,
also ich hatte es nach der Empfehlung gleich mal mit "Global" und "Erzwungen" eingestellt, aber das Problem ist leider noch präsent.
Scheinbar ist die Bandbreite nicht das Problem, diese Aussetzer habe ich auch wenn die Bandbreite nicht mal zum 1/4 genutzt wird von dem 2 Mbit Anschluss. An dem 2 Mbit Anschluss hatte ich heute und gestern gesessen und das beobachtet, die Reservierung liegt hier bei 256kbit/sec global (2 Telefone an dem Standort).
Wenn ich einen Copy Job über den Tunnel laufen lassen und dann telefoniere geht sofort die Übertragungsrate für das Kopieren runter. Hatte zum Testen einmal in der Zentrale meine Mailbox abgefragt und dann ein 500MB File mir von der Zentrale heruntergeladen als das Gespräch aufgebaut war, da bekam ich zwar nicht die 2 Mbit für das Kopieren (wie es sein sollte), aber ich hatte beim Start des Kopierens merkliche Aussetzen.
Daher war meine Vermutung, das ich evtl. die MTU für die beiden Gegenstellen auf 1492 oder mal 1400 setze und es besser wird, vielleicht habe ich nur ein Problem mit großen Packten die "plötzlich" und für einen kurzen Moment auftauchen.
Die Konfig vom Cisco hatte ich mir auch angesehen, hier wird scheinbar das LAN Interface auch mit QoS belegt und eine max MTU für den Tunnel definiert.
Habe soeben einen UP+Download von und zur Zentrale aktiviert, nebenbei die Mailbox dran und es ist OK mit leichten hängern (nach 3:30 Min sogar Aussetzer). Das Kopieren habe ich zuerst begonnen und nach 4-5 Sekunden das Telefon benutzt.
Upload laut Windows zur Zentrale
81KB/sek (langsam steigend)
Download
172KB/sek
Lanmonitor:
Send: 1,2Mbit/Empfang 1,9Mbit
QoS.
- greift nur bei TX mit 256 Reserviert
- PMTU 576
gruß
also ich hatte es nach der Empfehlung gleich mal mit "Global" und "Erzwungen" eingestellt, aber das Problem ist leider noch präsent.
Scheinbar ist die Bandbreite nicht das Problem, diese Aussetzer habe ich auch wenn die Bandbreite nicht mal zum 1/4 genutzt wird von dem 2 Mbit Anschluss. An dem 2 Mbit Anschluss hatte ich heute und gestern gesessen und das beobachtet, die Reservierung liegt hier bei 256kbit/sec global (2 Telefone an dem Standort).
Wenn ich einen Copy Job über den Tunnel laufen lassen und dann telefoniere geht sofort die Übertragungsrate für das Kopieren runter. Hatte zum Testen einmal in der Zentrale meine Mailbox abgefragt und dann ein 500MB File mir von der Zentrale heruntergeladen als das Gespräch aufgebaut war, da bekam ich zwar nicht die 2 Mbit für das Kopieren (wie es sein sollte), aber ich hatte beim Start des Kopierens merkliche Aussetzen.
Daher war meine Vermutung, das ich evtl. die MTU für die beiden Gegenstellen auf 1492 oder mal 1400 setze und es besser wird, vielleicht habe ich nur ein Problem mit großen Packten die "plötzlich" und für einen kurzen Moment auftauchen.
Die Konfig vom Cisco hatte ich mir auch angesehen, hier wird scheinbar das LAN Interface auch mit QoS belegt und eine max MTU für den Tunnel definiert.
Habe soeben einen UP+Download von und zur Zentrale aktiviert, nebenbei die Mailbox dran und es ist OK mit leichten hängern (nach 3:30 Min sogar Aussetzer). Das Kopieren habe ich zuerst begonnen und nach 4-5 Sekunden das Telefon benutzt.
Upload laut Windows zur Zentrale
81KB/sek (langsam steigend)
Download
172KB/sek
Lanmonitor:
Send: 1,2Mbit/Empfang 1,9Mbit
QoS.
- greift nur bei TX mit 256 Reserviert
- PMTU 576
gruß
Hi TitanChris
genau das hier dürfte das Problem sein:
ach ja: Damit eine Mindestbandbreite in Empfangsrichtung überhaupt greifen kann, mußt du auch die Up- und Downstream-Raten für das DSL-Interface (Schnittstellen -> WAN -> Interface-Einstellungen -> DSL1) eintragen
Gruß
Backslash
genau das hier dürfte das Problem sein:
du mußt auch für die Empfangsrichtung eine Mindestbandbreite definieren. denn sonst kommt wird das Telefonat bei einem Download ins stottern.- greift nur bei TX mit 256 Reserviert
ach ja: Damit eine Mindestbandbreite in Empfangsrichtung überhaupt greifen kann, mußt du auch die Up- und Downstream-Raten für das DSL-Interface (Schnittstellen -> WAN -> Interface-Einstellungen -> DSL1) eintragen
Gruß
Backslash
-
TitanChris
- Beiträge: 18
- Registriert: 07 Mär 2009, 13:43
Hallo Backslash,
das gestern nur die TX reserviert worden sind war scheinbar nur ein Fehler, denn als ich es Tagsüber beobachtet habe, wurde es bei RX und TX reserviert.
Jedoch hatte ich mit jemandem in einer Außenstelle telefoniert und trotz Reservierung Aussetzer gehabt. Bei uns wird der Traffic immer über den 100Mbit in der Zentrale geroutet, da auch an den Außenstellen der Traffic nicht sehr hoch ist, kann ich mir nicht vorstellen das es viel an der Auslastung der Bandbreite liegt.
Derzeit habe ich für das QoS nur eine Regel (in Zusammenarbeit mit Dr. Einstein.):
Allgemein
- Regel Aktiv
- Diese Regel hält die Verbindungszustände nach
Aktion
- Accept
QoS
- PMTU Reduzieren (derzeit wieder 768 vorher 576), bei DiffServ=EF, nur wenn VPN-Route
- Mindestbandbreite garantieren 256kbit/sekunde (768kbit/sekunde an Standorten mit 5 Telefonen), Global, erzwungen, bei DiffServ=EF, nur wenn VPN-Route
Stationen
- Verbindungen von allen Stationen
- Verbindungen an alle Stationen
Dienste
- keine Einschränkungen
Gruß
das gestern nur die TX reserviert worden sind war scheinbar nur ein Fehler, denn als ich es Tagsüber beobachtet habe, wurde es bei RX und TX reserviert.
Jedoch hatte ich mit jemandem in einer Außenstelle telefoniert und trotz Reservierung Aussetzer gehabt. Bei uns wird der Traffic immer über den 100Mbit in der Zentrale geroutet, da auch an den Außenstellen der Traffic nicht sehr hoch ist, kann ich mir nicht vorstellen das es viel an der Auslastung der Bandbreite liegt.
Derzeit habe ich für das QoS nur eine Regel (in Zusammenarbeit mit Dr. Einstein.):
Allgemein
- Regel Aktiv
- Diese Regel hält die Verbindungszustände nach
Aktion
- Accept
QoS
- PMTU Reduzieren (derzeit wieder 768 vorher 576), bei DiffServ=EF, nur wenn VPN-Route
- Mindestbandbreite garantieren 256kbit/sekunde (768kbit/sekunde an Standorten mit 5 Telefonen), Global, erzwungen, bei DiffServ=EF, nur wenn VPN-Route
Stationen
- Verbindungen von allen Stationen
- Verbindungen an alle Stationen
Dienste
- keine Einschränkungen
Gruß
-
Dr.Einstein
- Beiträge: 3241
- Registriert: 12 Jan 2010, 14:10
Steht den in der Zentrale am 100 Mbit/s Anschluss auch ein Lancom ? Wenn ja, was für einer. Weil so gut wie kein Lancom Router kann mit 100 Mbit/s WAN/VPN-Last einen kühlen Kopf bewahren. Vielleicht kommen die Aussetzer durch 100% CPU Auslastung in der Zentrale ?
Du sagtest, du hattest vorher Cisco's dastehen. Da gab es keinerlei Probleme mit VoIP ?
Ansonsten nochmal die Endgeräte anschauen. Besonders Siemens IP Telefone mögen es gar nicht, mit alter oder/und ungleicher Firmware zu telefonieren, wenn dazwischen ein VPN Tunnel liegt
Am QoS selbst wüsste ich keinen Ansatz mehr im Router.
Gruß Dr.Einstein
Du sagtest, du hattest vorher Cisco's dastehen. Da gab es keinerlei Probleme mit VoIP ?
Ansonsten nochmal die Endgeräte anschauen. Besonders Siemens IP Telefone mögen es gar nicht, mit alter oder/und ungleicher Firmware zu telefonieren, wenn dazwischen ein VPN Tunnel liegt
Am QoS selbst wüsste ich keinen Ansatz mehr im Router.
Gruß Dr.Einstein
-
TitanChris
- Beiträge: 18
- Registriert: 07 Mär 2009, 13:43
Hi,
danke für Antwort.
An der Zentrale steht auch ein 1711, aber die Geräte sind im Monitoring drin und haben bisher eine Auslastung im Schnitt von 15% und Peaks von ca 60-70% bei der CPU.
Jedoch werden auch bei dem Peaks max. 8 Mbit übertragen, da unsere Außenstellen wie folgt sind:
1x 10 Mbit
2x 2Mbit
Der Traffic für Internet etc. geht nicht über den Lancom, sondern wird über einen Proxy gezogen.
Bei den Ciscos gab es sehr selten mal Aussetzer, auf jeden Fall waren es weniger als jetzt, zurück wechseln würde ich ungern, da die Config des Cisco immer etwas Zeit und Nerven kostet.
Die Firmware bei den Telefonen ist überall gleich, das hatten wir mit Siemens schon geprüft.
Gruß
Chris(QoS)
danke für Antwort.
An der Zentrale steht auch ein 1711, aber die Geräte sind im Monitoring drin und haben bisher eine Auslastung im Schnitt von 15% und Peaks von ca 60-70% bei der CPU.
Jedoch werden auch bei dem Peaks max. 8 Mbit übertragen, da unsere Außenstellen wie folgt sind:
1x 10 Mbit
2x 2Mbit
Der Traffic für Internet etc. geht nicht über den Lancom, sondern wird über einen Proxy gezogen.
Bei den Ciscos gab es sehr selten mal Aussetzer, auf jeden Fall waren es weniger als jetzt, zurück wechseln würde ich ungern, da die Config des Cisco immer etwas Zeit und Nerven kostet.
Die Firmware bei den Telefonen ist überall gleich, das hatten wir mit Siemens schon geprüft.
Gruß
Chris(QoS)
Hi TitanChris
Wichtig ist die korrekte Einstellung der Up- und Downstreamraten am DSL-Interface - lieber mal etwas weniger eintragen, als der Anschluß angeblich haben soll
BTW: hast du in der Zentrale auch QoS-Regeln - wenn nein, dann könnte das Problem auch dort liegen...
Gruß
Backslash
also 128 kBit pro Gespräch sind mehr als ausreichend...- Mindestbandbreite garantieren 256kbit/sekunde (768kbit/sekunde an Standorten mit 5 Telefonen), Global, erzwungen, bei DiffServ=EF, nur wenn VPN-Route
Wichtig ist die korrekte Einstellung der Up- und Downstreamraten am DSL-Interface - lieber mal etwas weniger eintragen, als der Anschluß angeblich haben soll
BTW: hast du in der Zentrale auch QoS-Regeln - wenn nein, dann könnte das Problem auch dort liegen...
Gruß
Backslash
-
TitanChris
- Beiträge: 18
- Registriert: 07 Mär 2009, 13:43
Hi,
also die Zentrale hat die gleiche Regel wie oben, nur mit 512kbit/sekunde als globale Reservierung.
Das mit dem weniger eintragen könnte man nochmal testen. Heute Morgen noch gesehen das ich das ich im IP-Router nicht mehr den Eintrage "DiffServer-Packete kopieren" auf ignorieren zurück gesetzt hatte, das habe ich dann noch angepasst.
Zudem habe ich für alle VPN Gegenstellen den MTU Wert auf 1492 gesetzt und will mal sehen was es heute wird.
gruß
also die Zentrale hat die gleiche Regel wie oben, nur mit 512kbit/sekunde als globale Reservierung.
Das mit dem weniger eintragen könnte man nochmal testen. Heute Morgen noch gesehen das ich das ich im IP-Router nicht mehr den Eintrage "DiffServer-Packete kopieren" auf ignorieren zurück gesetzt hatte, das habe ich dann noch angepasst.
Zudem habe ich für alle VPN Gegenstellen den MTU Wert auf 1492 gesetzt und will mal sehen was es heute wird.
gruß
Hi TitanChris
Wenn du damit aber die Tunnel meinst, dann hast du dem LANCOM jetzt noch zusätzliche Last aufgebürdet, weil es nun jedes Paket, das durch den Tunnel geht, nach der Verschlüsselung noch fragmentiert - und auf der anderen Seite wieder reassembliert - werden muß: Da ein verschlüsseltes Paket bis zu 100 Byte größer sein kann als das unverschlüsselte kommen nun auf der Internetverbindung Pakete mit bis 1592 Bytes an, die auf einer Leitung mit einer MTU von 1492 übertragen werden sollen - das geht nur mit Fragmentierung
Das LANCOM bertimmt die MTU der VPN-Verbindungen automatisch anhand der MTU der genutzen Internetverbindung - und daran solltest du auch nichts ändern.
Gruß
Backslash
Wenn du mit "VPN Gegenstellen" den Internetzugang der 1711er meinst, dann ist das sicherlich kein Problem.Zudem habe ich für alle VPN Gegenstellen den MTU Wert auf 1492 gesetzt und will mal sehen was es heute wird.
Wenn du damit aber die Tunnel meinst, dann hast du dem LANCOM jetzt noch zusätzliche Last aufgebürdet, weil es nun jedes Paket, das durch den Tunnel geht, nach der Verschlüsselung noch fragmentiert - und auf der anderen Seite wieder reassembliert - werden muß: Da ein verschlüsseltes Paket bis zu 100 Byte größer sein kann als das unverschlüsselte kommen nun auf der Internetverbindung Pakete mit bis 1592 Bytes an, die auf einer Leitung mit einer MTU von 1492 übertragen werden sollen - das geht nur mit Fragmentierung
Das LANCOM bertimmt die MTU der VPN-Verbindungen automatisch anhand der MTU der genutzen Internetverbindung - und daran solltest du auch nichts ändern.
Gruß
Backslash
-
TitanChris
- Beiträge: 18
- Registriert: 07 Mär 2009, 13:43
Hi Backslash,
ich meinte wirklich die VPN-Gegenstellen und nicht die Gegenstelle Internet, diese habe ich nicht fest definiert.
An den Aussenstellen machen die Lancoms den Traffic ins Internet für die Aussenstelle, sowie das VPN für Datenzugriffe und VOIP, in der Zentrale macht der Lancom nur Daten + Voip VPN.
Bisher gab es heute noch keine Medlungen von den Leuten, werde die MTU Werte am Montag dann wieder entfernen um zu sehen wie es läuft.
Gruß + Danke
TitanChris
ich meinte wirklich die VPN-Gegenstellen und nicht die Gegenstelle Internet, diese habe ich nicht fest definiert.
An den Aussenstellen machen die Lancoms den Traffic ins Internet für die Aussenstelle, sowie das VPN für Datenzugriffe und VOIP, in der Zentrale macht der Lancom nur Daten + Voip VPN.
Bisher gab es heute noch keine Medlungen von den Leuten, werde die MTU Werte am Montag dann wieder entfernen um zu sehen wie es läuft.
Gruß + Danke
TitanChris