[Info] be.ip/be.ip plus neue Firmware

Edit:
Firmware Release 10.2. Rev.9 Patch 4 verfügbar.
(05/08/21)
http://www.bintec-elmeg.com/downloads/

Probleme mit diesem Release? Gerne hier im Thread posten.

Die FW 10.1.21.107 habe ich gerade auf dem FTP-Server bei bintec entdeckt. Sie dürfte dann in den nächsten Tagen auch auf der Website auftauchen.

Edit: Hab sie natürlich mal aufgespielt und kann keine Probleme momentan bemerken.

Hast Du SIP- und RTP-Daten priorisiert?
Genau das Problem hatte ich vor kurzem auf Patch 3, allerdings nur bei hoher Uploadauslastung. Daraufhin habe ich QoS wieder eingerichtet und das Problem war weg.

Mit "wieder einrichten" meine ich: Ich hatte das schonmal auf der Digitalisierungsbox eingerichtet, nach einem Wechsel auf die be.ip plus aber diese Einstellung noch nicht wieder für nötig erachtet.
Nachdem jetzt mehrere Telefonate etwas zerhackt waren (vermtl. Uploadauslastung) habe ich QoS wieder eingferichtet.

1. Filter erstellen
Netzwerk-->QoS-->IPv4/IPv6-Filter

Einen Filter für Sip-Daten, einen für RTP-Daten erstellen.


2. Netwerk-->QoS-->QoS-Klassifizierung-->NEU

- feld oben rechts bleibt auf neu, beschreibung z.B. voip
-filter auswählen sip
-richtung beide oder ausgehend
-high-priority aktivieren
-klassenid ist egal
-dscp und cos-wert erhalten
-schnittstelle: telekom-entertain, oder wie auch immer Deine externe heißt

mit ok bestätigen. um die rtp-daten hinzuzubringen:
nochmal Netwerk-->QoS-->QoS-Klassifizierung-->NEU
-feld oben rechts: klassenplan voip auswählen
alles wie oben, nur den filter rtp auswählen

3. Netwerk-->QoS-->QoS-Schnittstellen/Richtlinien


Die SIP und rtp-Daten sollten werksseitig schon mit dem korrekten DSCP-Wert versehen sein. Kontrollieren kannst Du das unter VoIP->Einstellungen->Optionen (SIP-Daten DSCP Binär:110000) bzw im jeweiligen Standort für RTP (Binär:101110)
Den Erfolg der Aktion kannst Du unter Monitoring-QoS sehen. Hier sollten dann in der HP-Queue Pakete schnell hochgezählt werden, wenn telefoniert wird. Im Ruhezustand zählt der HP-Zähler langsam (SIP-Registrierungspakete).
In einigen Screens siehst Du bei mir aktiviertes Traffic-Shaping. Das ist am 10MBit-Upload optional.

- - - Aktualisiert - - -

Werner_1959 schrieb:

Verschwinden bestimmte Einstellungen durch ein Firmwareupdate?
Ich hab im Upload 10 MBit, da dürfte gar nichts ausgelastet sein,

Zum Vergrößern anklicken....

Hab ich bis jetzt nur einmal erlebt und war eine Fehlerkorrektur (nach Erläuterung nachvollziehbar).

Der Upload kann schon bei Teilauslastung Timingprobleme bei den RTP-Paketen verursachen.

- - - Aktualisiert - - -

Gemäß dieser Anleitung kannst Du die Filter aus 1. auch in einem neuen Klassenplan für die interne Schnittstelle adaptieren (Schritt 2 und 3) um Deine Yealinks gegenüber dem internen Traffic zu priorisieren.
Das hängt von Deinem internen Traffic ab ob Du das in Erwägung ziehen solltest.

Edit:
Nach aktuellen Informationen sind die Schritte 1&2 überflüssig und u.U. sogar kontraproduktiv weil diese Schritte bereits intern, nicht sichtbar in der FW realisiert werden. Kontraproduktiv, weil die doppelte Queuezuordnung zu einer Überlastung des Mechanismus führen kann.
Mit Schritt 3 wird die bereits durchgeführte Priorisierung sichtbar gemacht.

besser so?
Ich wurde in der Nacht beim Schreiben automatisch ausgeloggt. Daher wohl der defekte Link

Ich versuche mich mal in einer Antwort.

Werner_1959 schrieb:

Wie kommst Du auf die bei den Filtern eingetragenen Daten (SIP 48, RTP 46)? Irgendeinen Grund wird es schon haben, dass du genau DIESE Werte eingetragen hast. Es mag ja alles richtig und optimal sein, aber nachvollziehen kann ich das leider nicht, auch nicht, ob diese Werte auch für meinen Bedarf passen. Welche Bandbreite an Möglichkeiten gibt es hier und was bewirkt welcher Wert?

Zum Vergrößern anklicken....

Ich bin Telekom-Kunde. Diese Werte sind die offiziell von der Telekom kommunizierten Dienste-Kennungen, die auch im Telekom-Netz für SIP-und rtp-Daten verwendet werden für die Priorisierung. Bist Du bei einem anderen Provider, musst Du ggf. dort Erkundigungen einholen.

Werner_1959 schrieb:

Warum bei 3. im Upload Begrenzung auf 4000 (von (bei mir möglichen max.) 10000)? Wie hoch kann bei z. B. vier gleichzeitig geführten Gesprächen bzw. ausgehenden Faxen maximal das anfallende Uploadvolumen sein? Wenn mehr als 4000 benötigt werden, dann will ich im Geschäftsbetrieb immer Vorrang aller Telefone vor allem anderen haben. Bzw., große emails sollen trotzdem auch rausgehen können, egal wieviel Telefonate geführt werden. Abends und Nachts kann das wieder anders sein. Aber eine Tag-Nachtschaltung werde ich allein deswegen keinesfalls machen wollen.

Zum Vergrößern anklicken....

Der Wert von 4000 ist hier willkürlich gewählt. Gemäß Bintec-Hilfe gilt er auch nur für die HP-Queue. Ich versteh es also als Obergrenze. Der Wert hat nix mit Deiner Uploadbandbreite zu tun, sondern ist gewissermaßen ein Sicherheitslimit, um den nicht priorisierten Diensten Raum zu lassen. Pro Gespräch fallen bei G.711 rund 128 kBit jeweils im Up- und Download an.
Links für die SChnitstelle hab ich meine Uploadbandbreite eingetragen.

Werner_1959 schrieb:

Den „neuen Klassenplan für die interne Schnittstelle adaptieren (Schritt 2 und 3) um die Yealinks gegenüber dem internen Traffic zu priorisieren“, wo mache ich das nun wieder? Interne Schnittstelle, ist das dann en1-4 oder br0? Und wie kann ich speziell die Yealinks priorisieren (gegenüber z.B. PC-Netzwerk-Traffic, Streaming (also Download), Telefonen im Privatbereich, usw.)? Ist es möglich einzelne Telefone (z.B. anhand der IP) zu priorisieren?

Zum Vergrößern anklicken....

Da der Traffic nur ausgehend in einer Queue eingeordnet wird ist das einfach zu erklären:
Der Filter mit den DSCP-Werten bleibt der gleiche, da der Verkehr aus dem öffentl. Netz ja bereits getaggt ist. Es ist lediglich ein Klassenplan zu erstellen, der komplett identisch ist mit dem vorhergehenden, lediglich die Schnittstelle ist eine andere. Als Schnittstelle ist die zu wählen, wo Deine Yealinks dranhängen. Das kann ich Dir verständlicherweise genauer nicht sagen

Hast Du jetzt noch einen managed Switch mit QoS-Funktionen dazwischen hängen, ist der nach dem gleichen Prinzip zu behandeln.

Prinzipiell ist das mit dem Provider erstmal egal.
Die bislang eingerichtete Priorisierung bezieht sich erstmal nur auf die abgehenden Verbindungen in den Upstream. Der Telefonanlagenteil der be.ip taggt die Daten und der Router behandelt die getaggten Daten vorrangig bei der Auslieferung.

Wenn Du nur br0 und en1-4 zur Auswahl hast, dann tippe ich mal auf br0. en1-4 ist im Auslieferungszustand die blaue Buchse.

Werner_1959 schrieb:

An br0 hängt, so betrachtet, allerdings letztlich ja alles, nicht nur die Telefone.

Zum Vergrößern anklicken....

Das ist jetzt genau der Sinn der Priorisierung. An der Netzwerkschnittstelle werden die einlaufenden Pakete sequentiell ausgeliefert. Ohne Prio also stur in eingehender Folge. Mit Prio werden die höher priorisierten Pakete zuerst ausgeliefert und ddie anderen kommen in die Queue.
Das oben beschriebene Prozedere macht das erstmal auf der ausgehenden Schnittstelle in den Upstream des DSL-Anschlusses. Im Downstream und intern in Deinem Netz sollte eeigentlich genug "Wumms" sein, um da keinen Engpass aufkommen zu lassen. Wenn natürlich viel interner Verkehr läuft, kann die Priorisierung eingehender VoIP-Pakete ebenfalls sinnvoll sein. Ich hab das bei mir mal Testweise so umgesetzt: Nur für deen DSL-Upstream wird gelegentlich der Queue-Zähler für den nichtpriorisierten Verkehr hochgeezählt.

Die Priorisierung gegenüber dem netzinternen Traffic kannst Du auch auf Basis der Ziel-IP vornehmen. Ich würde aber erstmal den Filter für DSCP beibehalten, weil dann brauchst Du keinen neuen definieren.

Das Upgrade auf 10.1.27 hat erstmal funktioniert und ich kann keine Probleme bemerken.

Gerade auf dem ftp-Server die Version 10.1.27 p03 entdeckt.
Laut Readme sind da einige kleine Fehlerbehebungen drin.

Deutsch
Fehlerbehebungen

System – Schnittstellenliste falsch (# 674):
Es konnte vorkommen, dass
einem SNMP Manager eine falsc
he Liste von Schnittstellen übertr
agen wurde.

GUI – Anrufliste leer (# 688):
Es konnte vorkommen, dass die Liste der Anrufe
im Menü
Anwendungen > Anrufliste
leer war, obwohl Rufe ein- bzw.
ausgegangen waren.

Voice Mail: Fehlerhaft
e Aufnahmen (# 635):
Bei der Aufnahme eigener
Ansagen waren diese fehlerhaft. V
oreingespielte Ansagen auf der
SD-Karte
waren nicht betroffen.

IPSec –
Verbindungsaufbau schlug fehl (# 662):
Es konnte vorkommen, dass
der Aufbau der Phase 2 nur von einem Tunnelendpunkt aus erfolge
n konnte.

CAPI –
Keine Faxübertragung (# 197):
Nach dem Umschalten der CAPI von
Sprach- auf Faxübertragung, schlug die Faxübertragung fehl.

System –
ifconfig
-Befehl bei IPSec-Schnittstelle (n/a):
Der Befehl
ifconfig
reset
funktionierte bei IPSec-Schnittstellen nicht wie erwartet: Die
Schnittstelle
blieb im Zustand
down
.

ISDN – Keine Sprachüber
tragung nach Fax (# 788):
Im Betrieb eines All-IP-
Geräts als Telefonanlage stand nach der Übertragung eines Faxes
der erste
ISDN-Anschluss nicht zur Sprachübertragung zur Verfügung. Er wu
rde erst nach
einem Neustart wieder freigegeben.

Zum Vergrößern anklicken....