Zusammenhang des Verhaltens der LAN-Bridge und VRRP

[diemoories]

Liebe Lancom-Gemeinde,
kann mir jemand kurz sagen, welchen Zusammenhang es zwischen dem VRRP-Modul und der LAN-Bridge gibt?
Ich stelle nämlich gerade fest, dass sich die LAN-Bridge unterschiedlich verhält, je nach dem ob der Router sich gerade im Slave-Modus oder im Master-Modus befindet.
Und zwar fällt vor Allem auf, dass im Slave-Modus offensichtlich keine Broadcasts zwischen LAN und W-LAN durchgeleitet werden. Sobald der Router Master wird, tut er es.
Das ist ungünstig, da der Router im Slave-Modul W-LAN aktiviert hat und somit von den Anwender erheblich Störungen berichtet werden, wehnn sie sich über W-LAN verbinden.

Vielen Dank!
Ralf

[alf29]

Moin,

>kann mir jemand kurz sagen, welchen Zusammenhang es zwischen dem VRRP-Modul und der LAN-Bridge gibt?

explizit - überhaupt keinen...

>Ich stelle nämlich gerade fest, dass sich die LAN-Bridge unterschiedlich verhält, je nach dem ob der Router sich gerade im Slave-Modus oder im >Master-Modus befindet.

Alle Pakete, die vom IP-Router des Geräte selber kommen, bekommen das Ziel-Interface explizit vorgegeben - daran entscheidet die LAN-Bridge überhaupt nichts...

>Und zwar fällt vor Allem auf, dass im Slave-Modus offensichtlich keine Broadcasts zwischen LAN und W-LAN durchgeleitet werden. Sobald der >Router Master wird, tut er es.

Hast Du einen Bridge-Trace davon?

Gruß Alfred

[diemoories]

Hallo alf, danke für Deine klare Aussage. Hier ist der Trace:

VRRP-Master:

[Bridge] 2013/06/14 11:23:36,753
Bridge frame coming from ifc WLAN-1-2:
00:16:6f:63:b9:d5 (Intel-Malaysia 63:b9:d5) to ff:ff:ff:ff:ff:ff (Broadcast), 82 bytes
VLAN Id 0x001 Prio 0
-->multi/broadcast
-->forwarding 82 bytes to ifc LAN-1
-->forwarding into own LSL stack


[Bridge] 2013/06/14 11:23:39,632
Bridge frame coming from ifc LAN-1:
00:a0:57:18:27:10 (LANCOM 18:27:10) to ff:ff:ff:ff:ff:ff (Broadcast), 60 bytes
VLAN Id 0x001 Prio 0
-->multi/broadcast
-->forwarding 60 bytes to ifc WLAN-1-2
-->forwarding into own LSL stack



VRRP-SLAVE:

[Bridge] 2013/06/14 11:30:04,235
Bridge frame coming from ifc LAN-1:
00:a0:57:18:23:9c (LANCOM 18:23:9c) to ff:ff:ff:ff:ff:ff (Broadcast), 90 bytes
VLAN Id 0x001 Prio 0
-->multi/broadcast
-->forwarding into own LSL stack


[Bridge] 2013/06/14 11:30:05,786
Bridge frame coming from ifc LAN-1:
06:a0:57:18:23:9c (LANCOM(local-1) 18:23:9c) to ff:ff:ff:ff:ff:ff (Broadcast), 56 bytes
VLAN Id 0x322 Prio 0
-->multi/broadcast
-->forwarding into own LSL stack

[Bridge] 2013/06/14 11:33:12,706
Bridge frame coming from ifc LAN-1:
00:16:6f:63:b9:d5 (Intel-Malaysia 63:b9:d5) to ff:ff:ff:ff:ff:ff (Broadcast), 110 bytes
VLAN Id 0x001 Prio 0
-->multi/broadcast
-->forwarding into own LSL stack


[Bridge] 2013/06/14 11:33:13,457
Bridge frame coming from ifc LAN-1:
00:16:6f:63:b9:d5 (Intel-Malaysia 63:b9:d5) to ff:ff:ff:ff:ff:ff (Broadcast), 227 bytes
VLAN Id 0x001 Prio 0
-->multi/broadcast
-->forwarding into own LSL stack


Viele Grüße
Ralf

[diemoories]

Nachtrag: Aufgrund des fehlenden Zusammenhanges muss ich wohl woanders suchen. Es geht darum, dass in meinem VRRP-Verbund alles bis auf die hakelnden WLAN Verbindungen funktioniert. Wenn ich einen der Router abschalte, ist alles o.k.. Nicht aber, wenn ich nur bei einem der Router das WLAN Modul abschalte.

[diemoories]

Weitergesucht und GELÖST!
Das seltsame Verhalten kam daher, dass der DHCP-Clusterverbund nicht richtig konfiguriert war. (Einer der Lancoms als DHCP Operating = ein und der andere als DHCP Operating = automatic).
Fieser Fehler, weil "eigentlich" alles zu funktioniern scheint. Aber im LanCONFIG stehts ja: "Schalten Sie den DHCP-Server nur dann fest ein, wenn sichergestellt ist, dass dieses Gerät der einzige DHCP- Server im Netzwerk ist. Anderfalls wird die Netzwerkkommunikation erheblich gestört."

Sichtbar wurde der Fehler nur durch diese seltsame DHCP/ARP-Meldung (die "..." sind von mir):
[DHCP] ...
DHCP Rx (LAN-1, ...
DHCP Client Message (request) from 0.0.0.0: DHCPDISCOVER
Op = 01 | HType = 01 | HLen = 06 | Hops = 00
XId = 8E84EB6D | Secs = 0002 | Flags = 8000
CIAdr = 0.0.0.0 | YIAdr = 0.0.0.0
SIAdr = 0.0.0.0 | GIAdr = 0.0.0.0
CHAdr = 00 a0 57 18 27 10 00 00 00 00 00 00 00 00 00 00

Hostname: ...
Leasetime: 10
(ARP in progress) => Discard


Jetzt habe ich beide DHCP-Server für die entsprechenden LAN's gleichermaßen konfiguriert:


{Operating} Auto
{Broadcast-Bit} Yes
{Cache} No
{Adaption} No
{Cluster} Yes


Eine Frage noch zu Sicherheit: Ist das richtig, dass der DHCP-Server, der sich automatisch abschaltet, beim aktiven DHCP-Server eine Client-IP holt. Zusätzlich zu seiner Router-IP? Anpingen kann man die IP nicht...

Viele Grüße
Ralf

[alf29]

Moin,

Ist das richtig, dass der DHCP-Server, der sich automatisch abschaltet, beim aktiven DHCP-Server eine Client-IP holt. Zusätzlich zu seiner Router-IP? Anpingen kann man die IP nicht...

Nicht ganz- er schickt einen DHCP Discover (anders kann man nicht feststellen, ob ein DHCP-Server im Netz ist), aber wenn einer da ist, wird kein Request für die angebotene Adresse geschickt.

Gruß Alfred

[diemoories]

Moin Alfred,
danke.

Gerade dachte ich, alles richtig zu haben, da taucht dieses Paket auf:

[DHCP] ...
DHCP Rx (LAN-1, xxx_LAN1):
DHCP Client Message (request) from 0.0.0.0: DHCPREQUEST
Op = 01 | HType = 01 | HLen = 06 | Hops = 00
XId = B1B51481 | Secs = 0002 | Flags = 8000
CIAdr = 0.0.0.0 | YIAdr = 0.0.0.0
SIAdr = 0.0.0.0 | GIAdr = 0.0.0.0
CHAdr = 00 a0 57 18 23 9c 00 00 00 00 00 00 00 00 00 00

Hostname: ... <x09>4<x10>LANCOM 1780EW-3G<x00>
Leasetime: 10
Server-ID: 192.168.42.196 >>> erste LAN-IP "ruhenden" DHCP-Servers
Req.-IP: 192.168.42.215 >>> vom aktiven DHCP-Server zugewiesene IP desselben
(other server in cluster) => cache


Die Frage bleibt : Ist das richtig, dass im LANmonitor der ruhende DHCP-Server als Client mit dieser speziellen IP-Adresse ...215 gelistet wird oder deutet das auf eine Fehlkonfiguration hin?
Habe ich die Clusterfunktion vielleicht falsch eingestellt?

Irgendwie wedre ich nicht schlau daraus, wie der "ruhende" DHCP-Server sich nun verhält.

Viele Grüße
Ralf

[backslash]

Hi diemoories,

der Trick am "auto"-Modus ist, daß der "ruhende" DHCP-Server zwar einen Request als Broadcast schickt, aber mit seiner eigenen IP als Server-ID, damit der andere DHCP-Server ihn wieder aus seiner Tabelle herausnimmt (er sagt ihm dadurch, daß er einen anderen Server ausgewählt hat). Im DHCP-Cluster hast du dadurch ein Problem, weil der Cluster die vermeindliche Vergabe in jedem Fall cached... Im Cluster-Betrieb, darf die "auto"-Einstellung daher eigentlich nicht verwendet werden...

Gruß
Backslash

[diemoories]

Hallo backslash,
danke! Das erklärt es. Ich wähle dann wohl am Besten "Cluster No" und "Betrieb Auto", da in meiner Umgebung lokale DNS Auflösung kein Thema ist. Ich werde das mal eine Weile beobachten.

Viele Grüße Ralf