Bei den Meanwell Netzteilen ist bestimmt was passendes dabei. Musst halt nur rausbekommen was da aus dem Originalen Netzteil rauskommt.
Also ran ans Multimeter....
Ich arbeite ja nicht ganz so gerne an offenen Netzteilen....
Danke für den Tipp!
Um schreiben oder kommentieren zu können, benötigen Sie ein Benutzerkonto.
Sie haben schon ein Benutzerkonto? Melden Sie sich hier an.
Jetzt anmeldenHier können Sie ein neues Benutzerkonto erstellen.
Neues Benutzerkonto erstellenBei den Meanwell Netzteilen ist bestimmt was passendes dabei. Musst halt nur rausbekommen was da aus dem Originalen Netzteil rauskommt.
Also ran ans Multimeter....
Ich arbeite ja nicht ganz so gerne an offenen Netzteilen....
Danke für den Tipp!
Hallo miteinander.
Ich habe mir bei ebay ein USW Aggregation 8-Port ergattert, um Server und NAS (und die Bastelserver) entsprechend miteinander verbinden zu können. Leider kann ich den nicht auf die aktuellste Firmware updaten, da die Kiste vorher immer neustartet. Ein Hinweis gibt Unifi selber mit dem Hinweis, das Netzkabel zu tauschen. Das hat nicht den gewünschten Erfolg gebracht. ICh habe sowohl über die UDM Pro als auch über ssh das Firmwareupdate versucht.
Jetzt habe ich ein Video gefunden, wo jemand sein Netzteil eines USW 8 PoE-Switch getauscht hat. Der hat ein 158W-Netzteil eingebaut. So viel Power braucht das USW Aggr. sicher nicht, PoE gibt es da ja nicht. Da das nix angelötet ist, sondern das Netzteil mit 2 Pfostensteckern angeschlossen ist, sollte ich den Austausch auch selber bewerkstelligen können.
Nur: Welches Netzteil brauche ich??
Hat jemand Tipp für mich??
MfG
RaSti
Was genau sind denn die kleinen Änderungen am Netzwerk?
Ausfall der Telefonie bei Serverausfall ... warum dieses? Nutzt die TK-Anlage und die IP Telefone etwa den Windows Server als DNS und ggf. DHCP? Hätte man auch einfach auf den Router zeigen lassen können und die zwei Telefone mit festen IPs versehen. Dann kann bis auf Router und Switch alles abgeschaltet sein und die Telefonie läuft noch.
Ursprünglich habe ich den NoName 16-Port-Switch durch einen 48- USW-500 ersetzt, eine pfSense auf einen Black Dwarf3G gepackt und den Schrank etwas geordnet.
Von den Vorgängern habe ich in der Tat solch ei Setup übernommen. Ein ESXi 6.5. mit 2 Windows Server 2012 Standard. Der erste Server hat DNS und DHCP gemacht. Ich wollte (und werde) die Telefonie in ein VLAN hängen und dadurch unabhängig vom neuen Server machen. DHCP macht auch die Firewall, DNS fürs Praxisnetz der Windows-Server. Ist einfacher im AD, auch wenn ich ein AD für 2 Benutzer als übertrieben erachte.
Und das ich die Mitel nicht neu gestartet habe: Ich habe keinen Zugriff auf das Menü und kenne erst seit heute die Möglichkeit, das Teil trotzdem herunterzufahren.
Nochmals vielen Dank für die Hilfe!
LG
RaSti
So.
Das Problem ist identifiziert und behoben.
Ich konnte den Dienstleister überzeugen, die Anlage einmal neu zu starten. Und schon funktioniert wieder alles....
Ich wollte die nicht einfach stromlos machen, ist ja im Prinzip schon ein Linuxsystem darunter. Ich habe aber jetzt für zukünftige Experimente einen Tipp, wie ich die trotzdem runterfahren kann.
Mein Vermutung: Während des Umbaus war die Anlage mehrfach ohne LAN und hat sich da irgendwo verheddert. Oder sie war einfach bockig.
Ich möchte mich bei allen bedanken! Ich habe wieder einiges dazugelernt.
Alles anzeigenhab ich richtig verstanden das die Mittel TK Anlage in der Praxis hängt !?
Wie verhält es sich wenn du von Telefon A zu Telefon B "INTERN" telefonierst... das sollte ja nicht über Extern laufen... und auch mit der Sprache klappen!?
Was du nicht geschrieben hast, wie wird die Mittel ans TK angeschlossen? Hast du einen Trank oder nimmst du einen ISDN Anschluss von der Fritzbox?
Der Fehler liegt auf jedenfall bei den Sprachkanälen... hier muss ne richtig große Anzahl an Ports für freigeschaltet werden... Die Com-Ports laufen ja...
Wie sind die Telefone an der Mittel verbunden? die kannst du ja via "VoIP" oder via "IP" anschließen...das ist ja ein Unterschied...
Vielen Dank für Deine Antwort.
Ich merke, ich habe nicht alle Informationen angegeben.
Ja, die Mitel hängt in der Praxis.
Intern ist bei den beiden IP-Telefonen das selbe Problem: Klingeln (also die Signalisierung) funktioniert, Sprachdaten werden nicht übertragen.
Die Mitel ist genau wie die beiden Telefone per IP angeschlossen. DSL-/Telefonie-Anbieter ist die Telekom. Die Mitel registriert sich ohne Problem sofort nach Neustart mit den Telekom-Servern. Wenn ich es richtig gesehen habe, ist es kein SIP-Trunk, sondern einzelne Accounts.
Ich habe keinen Zugriff auf die Mitel-Anlage. Ich konnte dem Dienstleister nur "über die Schulter schauen", als er über Teamviewer die Einstellungen kontrolliert hat. Ansonsten kommt er auch ohne solche Software auf die Anlage. Ich vermute, die hat dafür einen Fernwartungsport oder so offen, in der FW musste ich dazu nix freigeben. In der Anleitung des Telefondienstleisters steht explizit, das von WAN => LAN nix freigegeben werden muss, sondern nur von LAN => WAN. Diese Ports habe ich freigegeben.
(Da die Problematik trotz freigegebener FW-Ports sowohl bei dem USG als auch bei der pfSense auftritt, habe ich den Telefon-Dienstleister gebeten, die Einstellungen in der Anlage zu überprüfen. Im Gegensatz zu mir arbeitet der aber nur Mo-Fr. 8:00 - 16:30 Uhr..)
LG
RaSti
Da hast Du keine von außen offenen UDP-Ports für die Sprachkanäle, zumindest keine, welche auf die Mitel zeigen.
Guten Morgen.
Ich vermute auch die Info in dieser Richtung.
Stolpern tue ich über die Tatsache, das ich diese vorher auch nicht explizit bgeöffnet habe und es hat funktionert.
Tatsächlich bin ich im Bereich VoIP nicht ganz so fit. Rudmentär: Es kommt ein Anruf rein, der von der TK-anlage angenommen und an die endgeräte signalisiert wird. Das läuft über Port 5060/5061. Diese Ports sind während der Registrierung der Telefonnummern beim Provider von LAN => WAN geöffnet worden und werden offengehalten. Die TK-anlage signalisiert an die IP-Telefone, deren IPs sie ja kennt, denn kommenden Ruf. Die klingeln auch. Jetzt müssen die IP-Telefone die RTP-Ports nach außen öffnen, um die Sprachpakete zu transportieren. Das geht dann auch von LAN => WAN.
Und an dieser Stelle hänge ich beim Verständnis. Wenn die Telefone dynamisch die Ports öffnen, dann brauche ich doch in die Frewall kein Loch bohren??
Ich hatte in der pfSense die Ports anhand der Dokumentation von Mitel geöffnet. Das hat nicht funktioniert. Ich konnte im Mitschnitt das INVITE des Anrufs lesen, habe aber leider nicht die Stelle gefunden, an der das Problem auftritt. (WireShark ist nicht mein tägliches Arbeitsgebiet).
Vielen Dank schon für den Denkanstoß.
Zur Info: Ich verdiene mein Brötchen als Krankenpfleger. Das gewerblich ist der Tatsache geschuldet, das ich nebenberuflich 3 Arztpraxen und 3 kleiner Unternehmen betreue, die sich die Preise des Systemhäuser nicht leisten wollen oder können. (auch wenn ich das gerade in solchen Fällen immer empfehle)
LG
RaSti
Hallo miteinander.
Ich sitze hier gefüllt seit 24h Arbeitszeit an einem Problem und finde die Lösung nicht...
Ich wurde letztes Jahr hier in eine (kleine) Arztpraxis gerufen, weil der Internet-Zugang nicht mehr funktioniert. Grund war ein gekündigter Wartungsvertrag mit SecurePoint, so das die Black Dwarf G3 alle Verbindungen verweigert hat. Ich habe dann ein in meinem Fundus befindliches USG 3P anstatt der Black Dwarf installiert, an das Netz-Design angepasst und es lief erst mal alles wieder.
Jetzt habe ich in den Osterferien den 10 Jahre alten DELL Server durch einen modernen EPYC getauscht und minimale Änderungen am Netzwerkdesign vorgenommen. PC-technisch funktioniert auch alles.
Hier das Netzwerkdesign:
Internet -- VIGOR 165 -- USG 3P -- USW500-48 -- Endgeräte:
Standardnetz: 192.168.178.0/24, USG ist Gataway und DHCP mit der 192.168.178.1
Praxisnetz: VLAN 20, USG 192.168.1.254; DHCP vom USG, DNS macht der alte Windowsserver mit 192.168.1.1 (historisch bedingt!!)
Achja, der Controller läuft als Dockercontainer.
Das slebe Setup hatte ich bis vor 4h auch mit pfsense so eingerichtet. VPN, Netzwerkzugriffe, WLAN. Alles fein.
ABER!!!!!!
Es hängt eine Mitel SMBC 400 samt zwei IP-Systemtelefonen sowie einer DECT-Basis (analog an der Mitel) mit im Netz. Da in der Vergangenheit bei Fehlern des Windowsservers (DNS-Server und DHCP) auch die Telefonie tot war, war (uns ist) mein Plan, die Telefonie in ein separates VLAN zu hängen und damit unabhängig vom Praxisnetz zu machen.
Ergänzung 23.4.: sowohl die Mitel als auch die beiden IP-Telefone sind an dem Switch-Ports auf Praxisnetz gesetzt, um keine Probleme vit dem VLAN zu bekommen.
Zugriff auf die TK-Anlage habe ich nicht, da muss ich mit einem Dienstleister Kontakt aufnehmen.
PROBLEM:
Ich kann reinwählen, es klingelt. Ich kann rauswählen, es klingelt. Die Signalisierung als solche funk Das Faxgerät (analog an der mitel) und das DECT-Telefon funktionieren problemlos. Die beiden Systemtelefone haben Kontakt zur Anlage, die richtige IP. Nur Sprachdaten scheinen nicht übertragen zu werden - sprich weder intern noch extern ist nach der Rufannahme irgendein Ton zu hören.
Was habe ich unternommen:
Ich habe mehrere ausführliche Dokumente des Telefondienstleisters, welche Ports die Anlage in der Firewall offen haben möchte. Da ich trotz Paketmitschnitts das Problem mit der pfSense nicht identifiezieren konnte, war mein Ansatz, wieder das USG 3P einzubinden. Mit dem hat es ja bereits über 6 Monate ohne besondere Einstellungen funktioniert. Also habe ich heute das USG wieder eingebunden, die Netzwerke wieder eingerichtet und die festen IP-Zuordnungen wieder im USG hinterlegt. Jetzt habe ich aber den selben Effekt wie mit der pfSense. Das einzige Gerät, welches ich noch ausgetauscht habe und welches ich auch nicht so einfach zurücktauschen kann, ist der 49-Port Uniti-Switch. Der alte war ein einfacher 24er, der auch nicht managbar war. Da aber der neue Server per 10Gb an dem Switch hängt, ist es nicht so einfach rückbaubar.
Hat jemand noch einen Denkanstoß?
Lt. Telefon-Dienstleister werden für die Anlage und die Telefone offene Ports benötigt. Ich betreue noch zwei Installationen mit USG-Pro, da hängen jeweils AGFEO-Anlagen dahinter, auch mit Systemtelefonen. Da habe ich keine Ports nach außen aufmachen müssen, die werden immer von innen nach außen geöffnet und am Ende des Gesprächs wieder geschlossen.
Vielen Dank. Falls Info s fehlen, ich liefere die gerne nach. Jetzt setze ich mich erst mal aufs Fahrrad....
LG
RaSti
Einfach das Docker-Netzwerk ins Management-VLAN packen. Geht auch mit einer NIC im NAS. Firewallregeln nicht vergessen und das richtige VLAN für die NAS taggen.
(Habs selber noch nicht getestet, weil ich in meinen Boxen immer mindestens 2 NICs habe und die eine exclusiv fürs Management freihalte.)
LG
RaSti
Das ist auch meine erste Vermutung, da der OT nichts weiter zu seiner Netzwerkkonfiguration geschrieben hat.
"Sogar" ich kann mein NAS in allen nötigen VLANs direkt erreichen, um genau dieses Problem nicht zu haben: Ich habe eine NIC in meinem Clients-, eine in meinem Server-LAN und zwei zu einem Trunk dirkt zum ESXi - ohne Switch. "Spart" 4 Ports.
Wie sieht Deine Config aus, RaSti ?
Das NAS hat nur 2 Netzwerkports. Es ist auch leider keine zum aufrüsten. Am ESXi werde ich morgen ein 10 GBe-Karte nachrüsten, die kommt dann an den Switch. Damit habe ich Verbindung für die VMs im Produktivnetzt und werde eine NIC vom NAS direkt mit einer NIC am ESXi verbinden. Dann ist weder der Switch noch das USG am Backup beteiligt und alles sollte sauber laufen...
Manchmal reicht es tatsächlich, "laut" zu denken und das Problem wird gefunden. Ich danke euch allen!
Läuft der zufällig ein vlan?
Als ich gestern Abend dann so im Bett lag, hat es Klick gemacht. Genau das ist das Problem. Der ESXI ist per se im Management-VLAN, die DS im Produktiv-Netz.
Da hier aber sowieso im Laufe des Jahres FttH kommt, wird wohl der Austausch des USG3 notwendig werden.
Vielen Dank!
Hallo miteinander.
Ich habe hier ein Netz, welches mir seit ca. 4 Wochen etwas Probleme gemacht hat. Täglich kurz nach 19:00 Uhr ist die CPU-Auslastung des USG-3P auf 100% gestiegen. Es war dann zeitweise nicht erreichbar im Controller (6.5.55 im Docker-Container). Das ganze geht bis ca. 2:00 Uhr, mal früher, mal später. Danach läuft das Netz 1A ohne Probleme - bis zum Abend 19:00 Uhr.
Das Problem, warum das Netzt dann nicht mehr funktioniert, sind DNS-TimeOuts. Wenn es im Produktivnetz wäre, würde ich den Windows Server verdächtigen. Es ist aber auch in den VLANS, die ihren DNS im USG haben (6 insgesamt).
Heute habe ich die Ursache gefunden, habe aber noch keine Erklärung dafür:
Im Netzwerk gibt es eine Synology DS421. Deren NICs sind beide angeschlossen mit eigenen IPs. Dort läuft das "Active Backup für Business" und sichert 4 VMs täglich vom ESXi weg. Dieser Sicherungsjob startet pünktlich 19:00 Uhr. Ich habe heute den Sicherungsjob deaktiviert und voila, das USG arbeitet vollkommen problemlos.
Ich habe den BackupJob in 2 aufgeteilt (nur eine VM muss täglich gesichert werden) und auf Nachtstunden verschoben, wo der Rest des Netzes eh schläft... Außerdem auf die Sicherung einer VM zur gleichen Zeit beschränkt.
Ich werde wahrscheinlich den ESXi mit einer separaten NIC direkt mit einer der NICs der DS verbinden und feste IPs zuweisen. Trotzdem würde mich interessieren, warum das USG während der Sicherung 100%-CPU-Auslastung hat. Eigentlich sollte das überhaupt keine Last damit haben, die Verbindung erfolgt ja auf Switch-Ebene..
Falls also jemand eine Erklärung hat, immer her damit...
LG
RaSti
Bisher wurde nur der Port 5060 für die Fritzbox weitergeleitet.
die 7490 liegt jetzt mit fester IP im Netz
Auf welchen Port weitergeleitet?
In welchem IP-Bereich hat die Fritzbox ihre IP? Ich vermute die 192.168.1.58? Das wäre der selbe IP-Bereich wie WAN und Vigor? Den kann die Fritzbox aber nicht sehen...
Ich betreibe eine ähnliche Konstellation, statt Fritzbox ist es eine AGFEO-TK-Anlage. Ich musste den Port 5060 auf die IP der TK-Anlage weiterleiten (das TK-Gedöns hat eine eigenes VLAN). Funktioniert seit mehreren Jahren Problemlos...
LG
RaSti
zur Zeit sind 92 Mitglieder (davon 4 unsichtbar) und 514 Gäste online - Rekord: 129 Benutzer ()