HPE Switch 1820 Fortigate VLAN VoIP Gesprächsabbrüche
Hallo an Alle,
ich muss mich mal an euch wenden, da ich in einem übernommenem Netzwerk ständige Gesprächsabbrüche verzeichne die ich nicht gelöst bekomme. Die Abbrüche sind willkürlich sowohl bei eingehenden als auch ausgehenden Gesprächen zu verzeichnen. Mal nach 10 Sekunden mal nach 5 Minuten oder auch mal erst nach 15-20 Minuten. Der Anschluss ist von der Telekom mit dem Tarif DeutschlandLAN IP Voice/Data L Premium.
Zur aktuellen Konfiguration (die sicherlich extrem verbesserungswürdig ist)
Geräte:
1x HPE Server (Hyper-V mit 4 VMs) 192.168.1.1
1x LANCOM Router - 192.168.100.1
1x HPE "Schrott" Switch 1820 - 192.168.1.11
1x Fortigate 60F - 192.168.1.254
1x Auerswald COMpact 4000 - 192.168.2.240
3x Systemtelefone - 192.168.2.xx
1x DECT mit Handtelefonen - 192.168.2.xx
VLANs:
1 default
10 Intern
20 VoIP
30 Clients - 192.168.3.xx
40 Gast - 192.168.4.xx
100 Management 192.168.100.xx
777 Dead End
Konfiguration Switch:
Port Mirroring / Jumbo Frames / Flow Control / Loop Protection / IGMP Snooping alles auf Disabled
Storm Control und Auto DoS Features alle Disabled
Spanning Tree Enabled
Protocol Version: RSTP (802.1w)
Switch Priority: 4096
Max Age: 20
Forward Delay: 15
LLDP / LLDP-Med ist auf allen Ports enabled! Denke das das schon in korrekt ist, da der Schrott an Switch kein Voice-VLAN kann. Die Auerswald selbst nutzt DiffServ welches aktiviert ist.
Bereits durchgeführt habe ich folgendes:
Der LANCOM in Bridge-Mode versetzt und die PPPoE-Einwahl wird auf der Fortigate terminiert. Auf der Fortigate die SIP-ALG (proxy-based) deaktiviert und den default-voip-alg-mode kernel-helper-based gesetzt. Leider ohne jeglichen Erfolg!
Aktuelle Firewallregel für VoIP.
Weiterhin habe ich gesehen, dass im Grunde alle VLANs untereinander (ausgenommen Gast) alle Dienste ohne jegliche Einschränkung freigegeben haben. Das ist doch ziemlich Sinnfrei oder nicht?
Übersicht Firewallregeln.
Ich hoffe es können mir einige versierte Netzwerker einige Hilfestellungen geben um das gesamte Netzwerk zu verbesseren.
ich muss mich mal an euch wenden, da ich in einem übernommenem Netzwerk ständige Gesprächsabbrüche verzeichne die ich nicht gelöst bekomme. Die Abbrüche sind willkürlich sowohl bei eingehenden als auch ausgehenden Gesprächen zu verzeichnen. Mal nach 10 Sekunden mal nach 5 Minuten oder auch mal erst nach 15-20 Minuten. Der Anschluss ist von der Telekom mit dem Tarif DeutschlandLAN IP Voice/Data L Premium.
Zur aktuellen Konfiguration (die sicherlich extrem verbesserungswürdig ist)
Geräte:
1x HPE Server (Hyper-V mit 4 VMs) 192.168.1.1
1x LANCOM Router - 192.168.100.1
1x HPE "Schrott" Switch 1820 - 192.168.1.11
1x Fortigate 60F - 192.168.1.254
1x Auerswald COMpact 4000 - 192.168.2.240
3x Systemtelefone - 192.168.2.xx
1x DECT mit Handtelefonen - 192.168.2.xx
VLANs:
1 default
10 Intern
20 VoIP
30 Clients - 192.168.3.xx
40 Gast - 192.168.4.xx
100 Management 192.168.100.xx
777 Dead End
Konfiguration Switch:
Port Mirroring / Jumbo Frames / Flow Control / Loop Protection / IGMP Snooping alles auf Disabled
Storm Control und Auto DoS Features alle Disabled
Spanning Tree Enabled
Protocol Version: RSTP (802.1w)
Switch Priority: 4096
Max Age: 20
Forward Delay: 15
LLDP / LLDP-Med ist auf allen Ports enabled! Denke das das schon in korrekt ist, da der Schrott an Switch kein Voice-VLAN kann. Die Auerswald selbst nutzt DiffServ welches aktiviert ist.
Bereits durchgeführt habe ich folgendes:
Der LANCOM in Bridge-Mode versetzt und die PPPoE-Einwahl wird auf der Fortigate terminiert. Auf der Fortigate die SIP-ALG (proxy-based) deaktiviert und den default-voip-alg-mode kernel-helper-based gesetzt. Leider ohne jeglichen Erfolg!
Aktuelle Firewallregel für VoIP.
Weiterhin habe ich gesehen, dass im Grunde alle VLANs untereinander (ausgenommen Gast) alle Dienste ohne jegliche Einschränkung freigegeben haben. Das ist doch ziemlich Sinnfrei oder nicht?
Übersicht Firewallregeln.
Ich hoffe es können mir einige versierte Netzwerker einige Hilfestellungen geben um das gesamte Netzwerk zu verbesseren.
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 3653622798
Url: https://administrator.de/forum/hpe-switch-1820-fortigate-vlan-voip-gespraechsabbrueche-3653622798.html
Ausgedruckt am: 22.12.2024 um 10:12 Uhr
28 Kommentare
Neuester Kommentar
Wenn DiffServ aktiviert ist bei der Auerswald bedeutet das ja erstmal nur das diese die Voice Pakete klassifiziert, was per se schonmal sehr gut ist.
QoS funktioniert aber immer ausschliesslich Hop basierend!
Bedeutet also das du dafür sorgen musst sowohl auch dem Switch als auch auf dem Router den Voice Traffic zu priorisieren.
Das ist vermutlich bei dir nicht der Fall so das der Voice Traffic wie aller anderer Traffic behandelt wird (best efford) ohne jegliche Priorisierung was dann in einem Laufzeit kritischen Voice Netz ohne ein Voice VLAN zu solchen Problemen führt.
Ein automatisches Voice VLAN brauchst du auch gar nicht, wichtig ist lediglich nur DAS es ein Voice VLAN gibt.
Das kannst du dann auch wie ein gewöhnliches VLAN statisch einrichten um alle Voice Komponenten darin zu betreiben inklusive QoS.
QoS klassifizieren tun die Endgeräte ja schon wie du ja sagst, also musst du Switch und Router nur sagen das sie auf die DiffServ Pakete achten sollen (DiffServ ist Layer 3 QoS im IP Header) und wie sie damit umgehen sollen.
In der Regel haben billige Switches und Router 4 Priority Queues, bessere derer 8.
In den DiffServ QoS Settings sagst du dann einfach nur das der entsprechende DiffServ TDSCP/ToS Wert den die Auerswald setzt in die Prio Queue 4 (oder 8) priorisiert wird so das dieser Traffic immer bevorzugt VOR allem anderen Traffic geforwardet wird und schon gehören deine Abbrüche und Aussetzer der Vergangenheit an.
FW Regelwerke spielen bei Voice QoS eher eine untergeordnete bis keine Rolle sofern die Voice relevanten Pakete passieren können und die UDP Timer (Spache wird in RTP auf UDP Basis transportiert) in der FW entsprechend customized sind.
Nebenbei gesagt sind das im Voice Netz und dessen Setup einfachste Standardprozeduren die ein guter Netzwerker wie du eigentlich kennen sollte!
QoS funktioniert aber immer ausschliesslich Hop basierend!
Bedeutet also das du dafür sorgen musst sowohl auch dem Switch als auch auf dem Router den Voice Traffic zu priorisieren.
Das ist vermutlich bei dir nicht der Fall so das der Voice Traffic wie aller anderer Traffic behandelt wird (best efford) ohne jegliche Priorisierung was dann in einem Laufzeit kritischen Voice Netz ohne ein Voice VLAN zu solchen Problemen führt.
Ein automatisches Voice VLAN brauchst du auch gar nicht, wichtig ist lediglich nur DAS es ein Voice VLAN gibt.
Das kannst du dann auch wie ein gewöhnliches VLAN statisch einrichten um alle Voice Komponenten darin zu betreiben inklusive QoS.
QoS klassifizieren tun die Endgeräte ja schon wie du ja sagst, also musst du Switch und Router nur sagen das sie auf die DiffServ Pakete achten sollen (DiffServ ist Layer 3 QoS im IP Header) und wie sie damit umgehen sollen.
In der Regel haben billige Switches und Router 4 Priority Queues, bessere derer 8.
In den DiffServ QoS Settings sagst du dann einfach nur das der entsprechende DiffServ TDSCP/ToS Wert den die Auerswald setzt in die Prio Queue 4 (oder 8) priorisiert wird so das dieser Traffic immer bevorzugt VOR allem anderen Traffic geforwardet wird und schon gehören deine Abbrüche und Aussetzer der Vergangenheit an.
FW Regelwerke spielen bei Voice QoS eher eine untergeordnete bis keine Rolle sofern die Voice relevanten Pakete passieren können und die UDP Timer (Spache wird in RTP auf UDP Basis transportiert) in der FW entsprechend customized sind.
Nebenbei gesagt sind das im Voice Netz und dessen Setup einfachste Standardprozeduren die ein guter Netzwerker wie du eigentlich kennen sollte!
Hi,
gibt es auch Softphones? Bei 3 Telefonen + 1x DECT sieht mit das nach einer kleinen Butze mit vll. 10 Leuten aus, dafür ist das Netzwerk schon erstaunlich stark strukturieret und ich finde dass es da recht wenig gibt was dringend verbessert werden muss.
Grundsätzlich: Wo brechen die Gespräche ab, was steht in den Auerswald logs?
Ist das Problem die Verbindung Telefon - TK-Anlage oder TK-Anlage -Telekom?
Wenn es keine Softphones gibt, dann reicht ein eigenes VLAN völlig aus, da braucht es keine extra Markierung für VoIP-Pakete. Wenn man wirklich QoS braucht (kommt jetzt auf den Traffic an, der da erzeugt wird), dann würde es ohne SoftPhones reichen das VLAN VoIP zu bevorzugen.
Gruß
Drohnald
gibt es auch Softphones? Bei 3 Telefonen + 1x DECT sieht mit das nach einer kleinen Butze mit vll. 10 Leuten aus, dafür ist das Netzwerk schon erstaunlich stark strukturieret und ich finde dass es da recht wenig gibt was dringend verbessert werden muss.
Grundsätzlich: Wo brechen die Gespräche ab, was steht in den Auerswald logs?
Ist das Problem die Verbindung Telefon - TK-Anlage oder TK-Anlage -Telekom?
Wenn es keine Softphones gibt, dann reicht ein eigenes VLAN völlig aus, da braucht es keine extra Markierung für VoIP-Pakete. Wenn man wirklich QoS braucht (kommt jetzt auf den Traffic an, der da erzeugt wird), dann würde es ohne SoftPhones reichen das VLAN VoIP zu bevorzugen.
Weiterhin habe ich gesehen, dass im Grunde alle VLANs untereinander (ausgenommen Gast) alle Dienste ohne jegliche Einschränkung freigegeben haben. Das ist doch ziemlich Sinnfrei oder nicht?
Sicherheitstechnisch ja, aber um den Broadcast zu minimieren ist das schon mal nicht schlecht.Gruß
Drohnald
Hi,
ich habe ein ähnliches System (Fortigate, Auerswald, Telekom) vor kurzem eingerichtet.
Den session-helper für SIP habe ich in meinem Fall deaktiviert.
Sollte
vorhanden sein würde ich den Eintrag mal mit
entfernen (Achtung! muss nicht unbedingt die 13 sein)
Viele Grüße
ich habe ein ähnliches System (Fortigate, Auerswald, Telekom) vor kurzem eingerichtet.
Bereits durchgeführt habe ich folgendes:
Der LANCOM in Bridge-Mode versetzt und die PPPoE-Einwahl wird auf der Fortigate terminiert. Auf der Fortigate die SIP-ALG (proxy-based) deaktiviert und den default-voip-alg-mode kernel-helper-based gesetzt. Leider ohne jeglichen Erfolg!
Der LANCOM in Bridge-Mode versetzt und die PPPoE-Einwahl wird auf der Fortigate terminiert. Auf der Fortigate die SIP-ALG (proxy-based) deaktiviert und den default-voip-alg-mode kernel-helper-based gesetzt. Leider ohne jeglichen Erfolg!
Den session-helper für SIP habe ich in meinem Fall deaktiviert.
show system session-helper
Sollte
...
edit 13 set name sip set port 5060 set protocol 17
...
config system session-helper
delete 13
end
Viele Grüße
das dieser gruselige Switch....
Das stimmt leider:https://support.hpe.com/hpesc/public/docDisplay?docId=c04622710
In einem VoIP Netzwerk ist dieser Switch damit eine völlig ungeeignete Hardware da er immer ein Risiko bei der Übertragung der Voice Daten darstellt ohne Priorisierung. Hop by Hop....
Für eine langfristige und befriedigende Lösung solltest du den ersetzen.
Ich habe das Netz dort erst kürzlich übernommen und den alten Router gegen eine Fortigate getauscht.
Die Auerswald ist noch nicht ins neue VoIP VLAN umgezogen.
Für den SIP Service habe ich daher eine eigene Policy ohne Security Profile angelegt.
In der Fortigate sind öffentliche DNS Server fest eingetragen und der DNS-Service wird auf den internen Interfaces im Mode "Forward to System DNS" bereitgestellt.
In der Auerswald ist hier die Fortigate als DNS Server eingetragen.
auf welchem Stand ist den das FortiOS?
Ich meine
ist nur für FortiOS < 6.2.2.
Bei neueren muss der session-helper wie oben beschrieben gelöscht werden.
Falls es keine Besserung bringt kann man den ja problemlos wieder hinzufügen
Die Auerswald ist noch nicht ins neue VoIP VLAN umgezogen.
Für den SIP Service habe ich daher eine eigene Policy ohne Security Profile angelegt.
In der Fortigate sind öffentliche DNS Server fest eingetragen und der DNS-Service wird auf den internen Interfaces im Mode "Forward to System DNS" bereitgestellt.
In der Auerswald ist hier die Fortigate als DNS Server eingetragen.
auf welchem Stand ist den das FortiOS?
Ich meine
set sip-helper disable
set sip-nat-trace disable
Bei neueren muss der session-helper wie oben beschrieben gelöscht werden.
Falls es keine Besserung bringt kann man den ja problemlos wieder hinzufügen
config system session-helper edit 0
set name sip set port 5060 set protocol 17
end
Welche öffentlichen DNS-Server hast du in der Fortigate stehen? Wie gesagt, bei mir steht der interne Windows DNS Server drin.
In der Fortigate habe ich Quad9 eingetragen und in der Auerswald die Fortigate.Der Windows Server als DNS sollte, sofern korrekt eingerichtet aber auch problemlos nutzbar sein.
Soll ich diesen mal komplett umgehen oder kann ich dem VoIP-Netz einen anderen DNS-Server hinterlegen? Wenn ja, wo wir dies in der Fortigate konfiguriert?
Gui:
System > Feature Visibility > DNS Database auswählen.
Network > DNS Servers. Einstellungen nach deinen Anforderung
DNS Halte ich aber für unwahrscheinlich.
Sollte der session-helper jetzt wirklich aus sein würde ich mich auch erst einmal um den Switch kümmern.
Keine gute Idee wenn der Provider auch der VoIP Provider ist. Dort sollte dann immer der DNS des Providers gesetzt sein. Ob US DNS wegen der Datensicherheit generell eine gute Wahl ist muss jeder für sich selbst entscheiden...
Du hast völlig recht.
Meine Empfehlung wäre auch den DNS Server des Providers zu nutzen.
Hier hatte ich nur den Sonderfall den SIP-Trunk der Telekom über den Internetanschluss des lokalen Glasfaser Anbieters zu nutzen (Die Telekom liefert dort nur wackelige 16/2 Mbit/s). Dessen DNS Server hatte sich in der Vergangenheit nicht gerade als zuverlässig erwiesen.
Die Info hatte ich nicht mitgeteilt, da ich Sie für das Fehlerbild von @BigAndyT nicht relevant hielt.
könnte aber den Nachfolger CBS250-48PP-4G-EU zu guten Konditionen erhalten.
Dann zuschlagen, das ist der Nachfolger der SG Serie.Es gibt keine Unterschiede. Zumal das letzte Image ein Hybridimage ist was auf SG und CBS rennt.
Als DNS Server nimmst du logischerweise immer den, den du dynamisch auf deinem Router von der Telekom per PPPoE zugewiesen bekommen hast. Der Router ist dann Proxy DNS mit seiner lokalen IP. Der immerwährende Klassiker...
Als DNS Server nimmst du logischerweise immer den, den du dynamisch auf deinem Router von der Telekom per PPPoE zugewiesen bekommen hast. Der Router ist dann Proxy DNS mit seiner lokalen IP. Der immerwährende Klassiker...
In der Fortigate wäre das:
Network > Interface > WAN Interface auswählen und prüfen ob"Override internal DNS" AN ist. Damit werden die DNS Server verwendet welche via PPPoE zugeteilt wurden.
Damit die Fortigate die DNS anfragen auch intern beantwortet, müssen noch folgende Einstellungen gemacht werden:
Network > DNS Servers > Service on Interface > Create New
Die gewünschten (internen) Interfaces auswählen und jeweils "Forward to System DNS" einstellen.
Damit verhält sich die Fortigate fast wie ne FritzBox
Wenn es das denn nun war bitte dann nicht vergessen deinen Thread auch als erledigt zu schliessen!
Zitat von @BigAndyT:
Die Verbindungsabbrüche haben sich in der Tat erledigt und gehören der Vergangenheit an.
Die Verbindungsabbrüche haben sich in der Tat erledigt und gehören der Vergangenheit an.
Das klingt doch gut.
Kannst Du noch nachvollziehen woran es denn jetzt lag?
Was für einer denn?? Ein Catalyst mit IOS oder ein einfaches SoHo Modell SG oder CBS??
Diese Aussage ist wenig zielführend, denn die QoS Konfigs unterscheiden sich fundamental zwischen diesen Modellen.
Beim CBS oder SG Modell musst du zusätzlich zum LLDP Setup zwingend auch noch die QoS Variante aktivieren die du nutzen möchtest. Das ist entweder auf L2 Basis 802.1p was dann ein Tagging des Telefonieports erzwingt, da .1p immer Teil des .1q VLAN Headers ist.
Oder DSCP Priorisierung auf IP Header Basis wo kein Tagging erforderlich ist. Beides zusammen geht nicht bzw. macht keinen Sinn.
Frage ist also: WELCHES QoS willst DU nutzen??
Diese Aussage ist wenig zielführend, denn die QoS Konfigs unterscheiden sich fundamental zwischen diesen Modellen.
Beim CBS oder SG Modell musst du zusätzlich zum LLDP Setup zwingend auch noch die QoS Variante aktivieren die du nutzen möchtest. Das ist entweder auf L2 Basis 802.1p was dann ein Tagging des Telefonieports erzwingt, da .1p immer Teil des .1q VLAN Headers ist.
Oder DSCP Priorisierung auf IP Header Basis wo kein Tagging erforderlich ist. Beides zusammen geht nicht bzw. macht keinen Sinn.
Frage ist also: WELCHES QoS willst DU nutzen??