DHCP im VLAN und L3 Switch

Moin,

einen Trunk brauchst du dafür nicht, aber einen Helper... Wenn dein Rechner im VLAN160 am Anfang nen Broadcast macht um seinen DHCP zu finden is ja im eignen Netz nix. Der Helper sorgt dafür das dein DHCP gefunden wird.
Im DHCP musst du dann natürlich noch die passende Range anlegen - sonst wird der auch nich glücklich...

Deine Konfig ist soweit genau richtig. Sie entspricht auch dem hier im Tutorial beschriebenen Standard Layer 3 Switchkonzept:
Verständnissproblem Routing mit SG300-28
Also erstmal alles richtig gemacht !
Das Einzige was etwas verwirrend ist, ist die Tatsache das in der Skizze oben das VLAN 132 und 232 benannt ist welche aber im gesamten Netzwerk nicht vorkommen. Vermutlich soll das wohl eine Planung sein oder was auch immer..?!
So ist es aber dennoch hast du alles genau richtig gemacht und dein Weg der Segmentierung ist in jedem Falle der richtige !!
Das ist auch richtig !
Auch das ist richtig. Alles andere wäre ja sinnfrei. Stell dir eine Firma vor mit 20 VLANs. Da willst du ja nicht in jedem einzelnen VLAN einen DHCP Server am werkeln haben !
Das macht man dann logischerweise mit einem zentralen DHCP Server und den entsprechenden Scopes.
Siehe dazu auch hier: Netzwerk Management Server mit Raspberry Pi
Das ist also ein klassisches und auch gängiges Design und du hast bei dir alles richtig konfiguriert.
Man kann nur vermuten das der DHCP Server im ER das nicht supportet und nur IP Adresen rausgibt für Netze die an ihm selber auch direkt angeschlossen sind. Bei solchen Billigroutern die von Firmen kommen dessen Kernkompetenz eben gerade NICHT das Routing oder Firewalling ist muss man sich da dann nicht groß wundern....

Erleuchtung wird dir in der Tat sofort der Wireshark geben.
Sieh dir die DHCP Pakete an die der Switch mit seiner Helper IP an den DHCP Server 192.168.1.1 forwardet und ganz wichtig, ob der Server da dann auch überhaupt ein DHCP Offer als Antwort schickt zu diesem IP Netz:
https://de.wikipedia.org/wiki/Dynamic_Host_Configuration_Protocol#Ablauf ...
Vermutlich empfängt der Server die geforwardeten DHCP Requests des Switches aber schickt dann aus dem obigen Grund keine Offers.
Das siehst du genau wenn du den Wireshark in das Kabel zum Router mal einschleifst.
Dazu genierierst du einen Mirror (Spiegel) Port mit dem Switch um den Router Port auf den Wireshark Port zu spiegeln.
Das nennt man "SPAN" Port (Switched Port ANalyzer)
https://www.cisco.com/c/dam/en/us/td/docs/switches/lan/csbss/sf_sg250/ad ...
Seite 45, Kapitel 4
Damit kannst du den Router Port komplett auf einen freien Port am Switch spiegeln und hier genau sehen was am Router ankommt. (Und nebenbei wer so alles in deinem Netz ins Internet "telefoniert" !)
Ideal ist es wenn du im Wireshark Capture Filter (Aufzeichnungs Filter) noch auf DHCP filterst:
https://en.wikiversity.org/wiki/Wireshark/DHCP
Damit blendest du dann allen anderen Traffic aus den du nicht sehen willst und der ggf. verwirrt.

Der Buhmann wird vermutlich der ER Router bzw. dessen DHCP Funktion sein...
Kannst du testweise ja mal verifizieren wenn du mal einen Raspberry Pi als zentralen DHCP Server im VLAN 110 aufsetzt nach dem o.a. Tutorial.
Idealerweise ist der RasPi dann zusätzlich gleich ein PiHole Server: Raspberry Pi Zero W als Pi-hole Adblocker der dir dein gesamtes Netzwerk dann gleich global von Malware, Trojanern und lästiger Werbung befreit !!!

Mit dem Ansatz hast du absolut recht !
Kleine Ursache, große.... Der Klassiker
Na ja...kommt wie immer drauf an welche Erwartungshaltung man hat... Auf dem Niveau einer FritzBox dürfte er wohl sein.
Wieso ?
Die Fragestellung ist etwas unklar ??
Du weist doch am Switch dediziert den Endgeräte Ports das VoIP VLAN 232 zu. Folglich sind also diese Endgeräte zwangsweise immer dediziert in diesem VLAN und nirgendwo anders.
Den Ports denen du die VLAN Information an den Paketen zwangsweise mitgeben musst, die Taggst du dann in diesem VLAN. Sprich versiehst sie mit einem 802.1q konformen VLAN Tag im Paket:
https://de.wikipedia.org/wiki/IEEE_802.1Q
Damit haben dann ausgehende Pakete aus diesem VoIP VLAN ein 802.1q VLAN Tag am Paket und können von einem empfangenden Switch oder Router so wieder einem VLAN zugeordnet werden und in diesem geforwardet werden. Eigentlich doch ganz logisch und einfach.

Nur um es nochmals klarzustellen:
VLANs ist eine reine Layer 2 Technologie und spielt sich auf Mac Adress Ebene ab !
Niemals auf IP Ebene. Sihe Wiki Eintrag oben zu 802.1q.
Mit Routing hat das rein gar nix zu tun und kann auch deshalb niemals über Routing Grenzen übertragen werden, da es eben ein reines Layer 2 Merkmal ist. Grundlagen erklärt auch das hiesige VLAN Tutorial und seine weiterführenden Links:
VLAN Installation und Routing mit pfSense, Mikrotik, DD-WRT oder Cisco RV Routern
Möglich das du evtl. das Tagging am WAN Port meinst wie z.B. hier beschrieben:
Preiswerte, VPN fähige Firewall im Eigenbau oder als Fertiggerät
Cisco 880, 890 und ISR Router Konfiguration mit xDSL, Kabel oder FTTH Anschluss plus VPN und IP-TV
Das ist aber wieder eine ganz andere Baustelle, wenn auch mit der gleichen Technik.

Normal erstmal gar nicht. Das wäre ja auch von Fritzchen Müller ohne IT Kenntnisse etwas viel verlangt und aus normaler Sicht wenn es da um ein oder 2 Telefone in der heimischen Wohnung geht ja auch nicht zwingend nötig.
Oft sind das alte analoge Telefone oder welche mit ISDN die dann so oder an im Router integrierte Medienwandler angeschlossen sind weil sich auch die VoIP Telefonanlage meist integriert im Router findet.
So sieht ja das Gros der Heiminstallation aus. Der Router tagged dann die ausgehenden Voice Pakete und gut iss.
Nur etwas anspruchsvollere Nutzer machen sich ja oft dann auch zu recht Gedanken über eine sinnvollere Segmentierung und den Einsatz von VoIP Telefonen oder auch Anlagen im lokalen LAN.
Aber auch da ist es sehr einfach. Man klassifiziert den Voice Traffic dann aus dem lokalen Netzwerk sei es geroutet oder flach mit einer Access Liste im Router und sagt selbigem dann das er diesen Traffic dann bitte mit Tag xy am Ausgangsport raussenden soll.
Eigentlich ganz einfach
Guckst du hier:
Warum gibt es PVID bei VLANs?
Weitere VLAN Grundlagen wie immer auch hier:
VLAN Installation und Routing mit pfSense, Mikrotik, DD-WRT oder Cisco RV Routern

Kein Problem, dafür ist ja ein Forum da das man technische Fragen final klären kann. Allerdings bleibt unklar WELCHE der zahllosen Antworten dir nicht weitergeholfen hat...aber egal.
Zu deinen Punkten:
1.) LLDP ist primär keine Lösung zur Priorisierung der Voice Daten im Netz. Das machen L2 QoS Policies mit 802.1p oder eben Layer 3 Policies mit DSCP. Letztlich ist das davon abhängig WIE deine Voice Endgeräte eingestellt sind und welche Priorisierung sie nutzen. Richtig ist das LLDP zu Klassifizierung und Übermittling des Voice VLANs unsw. quasi Standard ist und ein Einsatz natürlich sinnvoll sofern deine Endgeräte es supporten.
2.) Ja ! .1p QoS ist immer ein Teil des .1q Tags. Sprich also keine .1p Layer 2 Priorisierung ohne ein .1q Tag am Paket. Layer 2 Priorisierung erzwingt dann immer ein .1q Tagging der Voice Daten.
3.) Richtig ! DSCP ist immer Teil des IP Headers ! Nimm dir einen Wireshark wie oben, dann siehst du es !
4.) Richtig !
5.) Jein. Muss nicht sein, wenn man generell in allen VLANs ein DSCP Honouring konfiguriert.
Normal macht man das abe rniemals global sondern immer Port bezogen, sprich man gibt explizit an wo an welchem Port man möchte das der Switch eine Priorisierung auf DSCP Basis machen soll.
Switch arbeiten ja normal auf Layer 3, sehen also niemals in den Layer 3. Deshalb muss man ihnen explizit sagen: Siehe in den Layer 3 und lese die Priorisierungs Settings dort !. Da ist es dann egal ob Tag oder No Tag an diesen Ports und egal welches VLAN.
6.) Ja, CDP (Cisco Discovery Protokoll) ist Cisco proprietär, das kann also nicht jeder. Viele Mitbewunderer im netzwerk Markt haben sich da aber angeschlossen und es mehr oder minder vollständig ebenfalls implementiert. Letztlich ist das aber tot, da es eine Abhängigkeit schafft. Wenn dann sollte man den Standard benutzen, wie immer, und das ist LLDP.
Gar nicht. Die PVID zeigt immer auf die VLAN ID in das ungetaggte Pakete an diesem Port geforwardet werden. Viele Hersteller haben das intelligent mit Auto PVID implementiert, die meisten Billigheimer aber nicht (kla,r kostet Geld was der normale Blödmarkt Verbrauche nicht zahlen will). Da muss es dann immer explizit nochmal gesetzt werden am Port.
Das ist auch richtig und so sollte es auch immer sein. Man kann aber natürlich an verschiedenen Ports auch verschiedene PVID sprich Native VLAN Settings haben.

So sollte es auch sein in einem "Administrator" Forum
Viel Erfolg weiterhin !

Ja, was den Daten Transport der VoIP Daten rein nur im Switch anbetrifft. Auf jedem anderen Gerät sieht das natürlich wieder anders aus. Den die wissen ja nicht was du am Switch eingestellt hast. Der Internet Router macht also keine Priorisierung wenn die Voice Pakete da ankommen und er keine entsprechende DSCP Konfig hat.
Das geht immer pro Hop.
Nein !
"Eingestellt" wird das ja logischerweise am Endgerät ! DAS sendet die Voice Pakete mit einem entsprechend gesetztem DSCP Wert. Jeder Hop der das Paket "sieht" und eine Forwarding Entscheidung dafür treffen muss musst du explizit sagen das er den DSCP Wert ansehen soll und je nach Wert etwas mit dem Paket machen muss. Hellsehen können solche Geräte nicht.
Wenn du es also nur am Switch eingestellt hast aber nicht am Router priorisiert es der Switch, der Router aber weiss logischerweise von nix und "sieht" nur die IP Adressen, nicht aber den DSCP Wert. Für ihn ist das also ein stinknormales IP Paket wie alles anderen auf was mit best efford geforwardet wird ohne entsprechendes DSCP Honoring !
Eigentlich doch eine gaz einfache Logik !
Fazit: Auch der Router braucht, wie jedes Gerät im Netz was eine Forwarding Entscheidung treffen muss, immer eine entsprechende QoS Konfig. Hop by Hop eben.