Hallo,
ich habe bei meinem T-Entertain-Anschluss meinen 1722 durch einen 1783VAW ersetzt.
Hierzu habe ich die funktionsfähige Konfiguration des 1722 in den 1783VAW hochgeladen und anschließend zusätzlich den DSL-Anschluss über den Wizard erneut eingerichtet sowie auch die Einstellungen entsprechend der Lancom Knowledgebase (Konfiguration eines IP-TV Anschlusses beim LANCOM-Router) kontrolliert/angepasst.
Anmeldung an DSL (VLAN7 für Internet, VLAN 8 für Entertain), ISDN, SIP funktionieren nach der Übernahme der Konfiguration in den 1783 wie erwartet.
Ich habe jedoch nun das Problem, dass sich in einem IP-Netzwerk sich DHCP-Server des 1783 nicht mehr so verhält, wie beim 1722, so dass ein IPTV-Client keine IP mehr zugewiesen bekommt.
Nun zu meinem Problem im Detail:
In der übernommenen Konfiguration habe ich zwei Netzwerke (192.168.0.*, 192.168.5.*) eingerichtet und jeweils an die Schnittstellen LAN-1 bzw. LAN-2 gebunden.
Der Router ist mit den IP-Adressen 192.168.0.254 sowie 192.168.5.254 für diese beiden Netzwerke konfiguriert.
Darüber hinaus ist das erste Netzwerk so eingerichtet, dass DHCP-Anfragen für LAN-1 an einen weiteren DHCP-Server (192.168.0.5) weitergereicht werden.
In LAN-2 fungiert der 1783 als DHCP-Server.
Wenn nun ein IPTV-Client aus LAN-2 versucht, sich über DHCP eine IP-Adresse abzuholen, wird diese zwar vom 1783 entgegengenommen, gemäß Trace-Auswertung jedoch offenbar über LAN-1 beantwortet:
[code]
[DHCP] 2015/09/20 12:30:55,388 Devicetime: 2015/09/20 12:30:57,577
DHCP Rx (LAN-2, IPTV):
DHCP Client Message (request) from 0.0.0.0: DHCPDISCOVER
Op = 01 | HType = 01 | HLen = 06 | Hops = 00
XId = 3FF37C1F | Secs = 0000 | Flags = 0000
CIAdr = 0.0.0.0 | YIAdr = 0.0.0.0
SIAdr = 0.0.0.0 | GIAdr = 0.0.0.0
CHAdr = 00 1a c3 4f 1d 2f 00 00 00 00 00 00 00 00 00 00
Client-ID: 01:00:1a:c3:4f:1d:2f
Option List 1 3 6 15 44 46 47
Vendor-Class-ID: MSFT_IPTV
=> Tx ARP-Request for 192.168.5.6
[DHCP] 2015/09/20 12:30:55,388 Devicetime: 2015/09/20 12:30:57,588
DHCP Rx (LAN-1, VOIP):
DHCP Server Message (reply) from 192.168.0.5: DHCPOFFER
Op = 02 | HType = 01 | HLen = 06 | Hops = 00
XId = 3FF37C1F | Secs = 0000 | Flags = 0000
CIAdr = 0.0.0.0 | YIAdr = 192.168.0.42
SIAdr = 192.168.0.5 | GIAdr = 0.0.0.0
CHAdr = 00 1a c3 4f 1d 2f 00 00 00 00 00 00 00 00 00 00
=> forwarded to internal DHCP-Client
[DHCP] 2015/09/20 12:30:55,388 Devicetime: 2015/09/20 12:30:57,592
DHCP Rx (LAN-2, IPTV):
DHCP Client Message (request) from 0.0.0.0: DHCPREQUEST
Op = 01 | HType = 01 | HLen = 06 | Hops = 00
XId = 3FF37C1F | Secs = 0000 | Flags = 0000
CIAdr = 0.0.0.0 | YIAdr = 0.0.0.0
SIAdr = 0.0.0.0 | GIAdr = 0.0.0.0
CHAdr = 00 1a c3 4f 1d 2f 00 00 00 00 00 00 00 00 00 00
Server-ID: 192.168.0.5
(wrong server) => Discard
[DHCP] 2015/09/20 12:30:55,450 Devicetime: 2015/09/20 12:30:57,603
DHCP Rx (LAN-1, VOIP):
DHCP Server Message (reply) from 192.168.0.5: DHCPACK
Op = 02 | HType = 01 | HLen = 06 | Hops = 00
XId = 3FF37C1F | Secs = 0000 | Flags = 0000
CIAdr = 0.0.0.0 | YIAdr = 192.168.0.42
SIAdr = 0.0.0.0 | GIAdr = 0.0.0.0
CHAdr = 00 1a c3 4f 1d 2f 00 00 00 00 00 00 00 00 00 00
MAC:00 1a c3 4f 1d 2ffor IP address 192.168.0.42 not found in BOOTP table:, discard[/code]
Wie lässt sich dieses Verhalten erklären?
Da die Konfiguration bisher auf dem 1722 funktioniert hat, gehe ich nicht von einem generellen Problem in der Konfiguration aus.
Ich habe zur Sicherheit auch einen Abgleich der Konfigurationseinstellungen zwischen dem 1722 und dem 1783 im Lanconfig durchgeführt, dort aber leider keinen Hinweis auf eine fehlerhafte Einstellung/Datenübernahme entdecken können.
Viele Grüße
Dirk
P.S.: Für die Konfiguration habe ich LANConfig in der Version 9.18.0016-REL eingesetzt
DHCP und Router-Virtualisierung (1783VAW)
Moderator: Lancom-Systems Moderatoren
Re: DHCP und Router-Virtualisierung (1783VAW)
Hi DirkG
du hast da noch einen weiteren DHCP-Server in deinem Netz VOIP... und offenbar auch einen Switch, der deinen beide Netze (VOIP und IPTV) zu einer Broadcast-Domain verbindet...
Dein 1783 empfängt die Anfage auf IPTV (LAN-2) und will ihm die 192.168.5.6 zuweisen... Irgendwie ist die Anfrage auch auf das andere Netz (VOIP, LAN-1) gekommen und dort gibt es einen DHCP-Server mit der IP-Adresse 192.168.0.5, der dem Receiver die 192.168.0.42 zuweist.
Hier solltest du wohl mal dein Netz aufräumen...
Gruß
Backslash
du hast da noch einen weiteren DHCP-Server in deinem Netz VOIP... und offenbar auch einen Switch, der deinen beide Netze (VOIP und IPTV) zu einer Broadcast-Domain verbindet...
Dein 1783 empfängt die Anfage auf IPTV (LAN-2) und will ihm die 192.168.5.6 zuweisen... Irgendwie ist die Anfrage auch auf das andere Netz (VOIP, LAN-1) gekommen und dort gibt es einen DHCP-Server mit der IP-Adresse 192.168.0.5, der dem Receiver die 192.168.0.42 zuweist.
Hier solltest du wohl mal dein Netz aufräumen...
Gruß
Backslash
Re: DHCP und Router-Virtualisierung (1783VAW)
Hallo Backslash,
erst einmal vielen Dank für Deine Rückmeldung!
Wenn ich die beiden Netze direkt oder indirekt über einen zusätzlichen Switch verbunden hätte, wäre dies die Erklärung für das beobachtete Verhalten.
Leider ist jedoch der IPTV-Client ausschließlich direkt mit der Schnittstelle LAN-2 des 1783 verbunden und es gibt keine weitere physikalische Verbindungen (außer über den 1783) zu weiteren Netzwerken.
An Schnittstelle LAN-1 hängt mein restliches Netzwerk mit weiteren Switchen und auch dem DHCP-Server (192.168.0.5).
Zudem ist das Netzwerk 192.168.0.* direkt der Schnittstelle LAN-1 zugewiesen, das Netzwerk 192.168.5.* LAN-2
[attachment=1]IP-Netzwerke.JPG[/attachment]
[attachment=0]DHCP-Netzwerke.JPG[/attachment]
1783 Ethernet-1 (192.168.0.254) ==> 192.168.0.* (DHCP Weiterleiten) ==> Switch ==> Weiterleitung an DHCP Server 192.168.0.5
1783 Ethernet-2 (192.168.5.254) ==> 192.168.5.* (DHCP aktiv) ==> IPTV-Client
Folglich sollte im ersten Schritt die DHCP-Anfrage über die Schnittstelle LAN-2 im 1783 ankommen und an den internen DHCP-Server des Netzes 192.168.5.* weitergeleitet werden. ==> Dies funktioniert gemäß Trace-Ausgabe.
Im folgenden Schritt sollte nun der 1783 seine Antwort auch wieder an die Schnittstelle LAN-2 zugeordnete Netz 192.168.5.* zurückgeben und nicht an die Schnittstelle LAN-1 weiterleiten.
==> Hier liegt offensichtlich das Problem.
Dies auch vor dem Hintergrund, der 1783 so konfiguriert ist, dass keine Kommunikation zwischen den Ethernet Ports des 1783 stattfinden darf (Private Mode).
Zusätzlich der Hinweis, dass im 1722 dieses funktioniert hat und ich bis auf den Austausch des 1722 durch den 1783 keine Änderung in meinem Netz vorgenommen habe.
Auch der 1783 ist bezogen auf die Ports identisch zum bisherigen 1722 verkabelt.
Wie erreiche ich, dass der 1783 eine DHCP-Anfrage auf LAN-2 auch wieder über diese beantwortet und dafür seinen eigenen DHCP-Server nutzt?
Viele Grüße
Dirk
erst einmal vielen Dank für Deine Rückmeldung!
Wenn ich die beiden Netze direkt oder indirekt über einen zusätzlichen Switch verbunden hätte, wäre dies die Erklärung für das beobachtete Verhalten.
Leider ist jedoch der IPTV-Client ausschließlich direkt mit der Schnittstelle LAN-2 des 1783 verbunden und es gibt keine weitere physikalische Verbindungen (außer über den 1783) zu weiteren Netzwerken.
An Schnittstelle LAN-1 hängt mein restliches Netzwerk mit weiteren Switchen und auch dem DHCP-Server (192.168.0.5).
Zudem ist das Netzwerk 192.168.0.* direkt der Schnittstelle LAN-1 zugewiesen, das Netzwerk 192.168.5.* LAN-2
[attachment=1]IP-Netzwerke.JPG[/attachment]
[attachment=0]DHCP-Netzwerke.JPG[/attachment]
1783 Ethernet-1 (192.168.0.254) ==> 192.168.0.* (DHCP Weiterleiten) ==> Switch ==> Weiterleitung an DHCP Server 192.168.0.5
1783 Ethernet-2 (192.168.5.254) ==> 192.168.5.* (DHCP aktiv) ==> IPTV-Client
Folglich sollte im ersten Schritt die DHCP-Anfrage über die Schnittstelle LAN-2 im 1783 ankommen und an den internen DHCP-Server des Netzes 192.168.5.* weitergeleitet werden. ==> Dies funktioniert gemäß Trace-Ausgabe.
Im folgenden Schritt sollte nun der 1783 seine Antwort auch wieder an die Schnittstelle LAN-2 zugeordnete Netz 192.168.5.* zurückgeben und nicht an die Schnittstelle LAN-1 weiterleiten.
==> Hier liegt offensichtlich das Problem.
Dies auch vor dem Hintergrund, der 1783 so konfiguriert ist, dass keine Kommunikation zwischen den Ethernet Ports des 1783 stattfinden darf (Private Mode).
Zusätzlich der Hinweis, dass im 1722 dieses funktioniert hat und ich bis auf den Austausch des 1722 durch den 1783 keine Änderung in meinem Netz vorgenommen habe.
Auch der 1783 ist bezogen auf die Ports identisch zum bisherigen 1722 verkabelt.
Wie erreiche ich, dass der 1783 eine DHCP-Anfrage auf LAN-2 auch wieder über diese beantwortet und dafür seinen eigenen DHCP-Server nutzt?
Viele Grüße
Dirk
Du hast keine ausreichende Berechtigung, um die Dateianhänge dieses Beitrags anzusehen.
Re: DHCP und Router-Virtualisierung (1783VAW)
Hi DirkG
Schau dir die Traces ganz genau an. Sie sagen dir, was passiert ist. Und zwar folgendes
Irgendwie ist der Broadcast mit dem DHCP-Discover des Receivers in dein VOIP-Netz gekommen. Der dort stehende DHCP-Server schickt ein Offer als Broadcast, weshalb das LANCOM ihn überhaupt sieht:
Der Receiver hat diesen Broadcast aber auch bekommen - und zwar über die angeblich nicht vorhandere Brücke zwischen den beiden Netzen - und schickt ein DHCP-Request - auch wieder als Briadcast, weshalb der DHCP-Server des LANCOMs dieses sieht:
Auch dieser Request ist wieder über die - angeblich nicht vorhandene - Brücke zwischen den beiden Netzesn ins VOIP-Netz gelangt und der DHCP-Server dort weist endgültig eine IP-Adrssse zu:
Der Recveiver bekommt das ACK aber über die Brücke und verwendet fortan die 192.168.0.42...
Nun stellt sich die Frage, wo die Brücke zwischen den Netzen ist... Dein 1722 hatte keine LAN-Bridge, das 1783VAW hat sie hingegen, wegen des WLANs... Hast du zufällig im LANCOM die beiden Netze in der gleichen Bridgegruppe hängen? Die sind nämlich alle im Default in BRG-1 und wenn du einfach nur die Konfig übernommen hast, dann hast du damit eine Brücke zwischen den Netzen gebaut. Stell das IPTV-Netz in *Keine* Bridgegruppe, d.h. trag unter Schnittstellen -> LAN -> Port-Tabelle -> LAN-2 als Bridgegruppe "keine" ein...
Gruß
Backslash
es ist genaugenommen die einzige...Wenn ich die beiden Netze direkt oder indirekt über einen zusätzlichen Switch verbunden hätte, wäre dies die Erklärung für das beobachtete Verhalten.
genau...Folglich sollte im ersten Schritt die DHCP-Anfrage über die Schnittstelle LAN-2 im 1783 ankommen und an den internen DHCP-Server des Netzes 192.168.5.* weitergeleitet werden. ==> Dies funktioniert gemäß Trace-Ausgabe.
und des ist eben *nicht* was passiert...Im folgenden Schritt sollte nun der 1783 seine Antwort auch wieder an die Schnittstelle LAN-2 zugeordnete Netz 192.168.5.* zurückgeben und nicht an die Schnittstelle LAN-1 weiterleiten.
==> Hier liegt offensichtlich das Problem.
Schau dir die Traces ganz genau an. Sie sagen dir, was passiert ist. Und zwar folgendes
Irgendwie ist der Broadcast mit dem DHCP-Discover des Receivers in dein VOIP-Netz gekommen. Der dort stehende DHCP-Server schickt ein Offer als Broadcast, weshalb das LANCOM ihn überhaupt sieht:
Da der DHCP-Server des LANCOMs nichts damit anfangen kann, schickt er das DHCPOFFER an den internen DHCP-Client (also den das LANCOMs!). Da diese absgeschaltet ist, wird das Paket verworfen. Es geht nicht ins LAN![DHCP] 2015/09/20 12:30:55,388 Devicetime: 2015/09/20 12:30:57,588
DHCP Rx (LAN-1, VOIP):
DHCP Server Message (reply) from 192.168.0.5: DHCPOFFER
Op = 02 | HType = 01 | HLen = 06 | Hops = 00
XId = 3FF37C1F | Secs = 0000 | Flags = 0000
CIAdr = 0.0.0.0 | YIAdr = 192.168.0.42
SIAdr = 192.168.0.5 | GIAdr = 0.0.0.0
CHAdr = 00 1a c3 4f 1d 2f 00 00 00 00 00 00 00 00 00 00
=> forwarded to internal DHCP-Client
Der Receiver hat diesen Broadcast aber auch bekommen - und zwar über die angeblich nicht vorhandere Brücke zwischen den beiden Netzen - und schickt ein DHCP-Request - auch wieder als Briadcast, weshalb der DHCP-Server des LANCOMs dieses sieht:
In diesem DHCPREQUEST fordert der Receiver explizit den DHCP-Server 192.168.0.5 (also den aus dem VOIP-Netz) auf, ihm eine IP-Adresse zuzuweisen. Daher fühlt sich der DHCP-Server des LANCOMs im Netz IPTV nicht für diesen Request zuständig: (wrong server) => Discard[DHCP] 2015/09/20 12:30:55,388 Devicetime: 2015/09/20 12:30:57,592
DHCP Rx (LAN-2, IPTV):
DHCP Client Message (request) from 0.0.0.0: DHCPREQUEST
Op = 01 | HType = 01 | HLen = 06 | Hops = 00
XId = 3FF37C1F | Secs = 0000 | Flags = 0000
CIAdr = 0.0.0.0 | YIAdr = 0.0.0.0
SIAdr = 0.0.0.0 | GIAdr = 0.0.0.0
CHAdr = 00 1a c3 4f 1d 2f 00 00 00 00 00 00 00 00 00 00
Server-ID: 192.168.0.5
(wrong server) => Discard
Auch dieser Request ist wieder über die - angeblich nicht vorhandene - Brücke zwischen den beiden Netzesn ins VOIP-Netz gelangt und der DHCP-Server dort weist endgültig eine IP-Adrssse zu:
Auch für dieses ACK fühlt sich der DHCP-Server im Netz VOIP nicht zusändig, weshalb er das Paket verwirft.[DHCP] 2015/09/20 12:30:55,450 Devicetime: 2015/09/20 12:30:57,603
DHCP Rx (LAN-1, VOIP):
DHCP Server Message (reply) from 192.168.0.5: DHCPACK
Op = 02 | HType = 01 | HLen = 06 | Hops = 00
XId = 3FF37C1F | Secs = 0000 | Flags = 0000
CIAdr = 0.0.0.0 | YIAdr = 192.168.0.42
SIAdr = 0.0.0.0 | GIAdr = 0.0.0.0
CHAdr = 00 1a c3 4f 1d 2f 00 00 00 00 00 00 00 00 00 00
MAC:00 1a c3 4f 1d 2ffor IP address 192.168.0.42 not found in BOOTP table:, discard
Der Recveiver bekommt das ACK aber über die Brücke und verwendet fortan die 192.168.0.42...
Nun stellt sich die Frage, wo die Brücke zwischen den Netzen ist... Dein 1722 hatte keine LAN-Bridge, das 1783VAW hat sie hingegen, wegen des WLANs... Hast du zufällig im LANCOM die beiden Netze in der gleichen Bridgegruppe hängen? Die sind nämlich alle im Default in BRG-1 und wenn du einfach nur die Konfig übernommen hast, dann hast du damit eine Brücke zwischen den Netzen gebaut. Stell das IPTV-Netz in *Keine* Bridgegruppe, d.h. trag unter Schnittstellen -> LAN -> Port-Tabelle -> LAN-2 als Bridgegruppe "keine" ein...
Gruß
Backslash
Re: DHCP und Router-Virtualisierung (1783VAW)
Hallo Backslash,
vielen Dank für diesen Hinweis!
Das Thema mit der BRG-Gruppe war die Ursache für mein Problem.
Da ich bisher nur getrennte LANCOM Router und Access Points im Einsatz habe, hatte ich dieses als mögliche Ursache nicht auf dem Schirm.
Ich bin vielmehr davon ausgegangen, dass die Port-Zuordnungen und der Public Mode eindeutig sind und eine solche Kommunikation erst gar nicht zulassen.
Noch einmal vielen Dank für diese Hinweis und viele Grüße
Dirk
vielen Dank für diesen Hinweis!
Das Thema mit der BRG-Gruppe war die Ursache für mein Problem.
Da ich bisher nur getrennte LANCOM Router und Access Points im Einsatz habe, hatte ich dieses als mögliche Ursache nicht auf dem Schirm.
Ich bin vielmehr davon ausgegangen, dass die Port-Zuordnungen und der Public Mode eindeutig sind und eine solche Kommunikation erst gar nicht zulassen.
Noch einmal vielen Dank für diese Hinweis und viele Grüße
Dirk