08.03.2019

2483

Lancom WLC4025+ - Zweite Management IP vergeben, jedoch gleiche MAC-Adresse (IP-Netzwerke)

Ich möchte meinem Lancom-Controller eine zweite Management-Adresse in einem VLAN zuweisen.

Dazu habe ich lediglich ein neues IP-Netzwerk mit der neuen Management-Adresse angelegt und mit auf das Bundle-1 gelegt.

Erreichbar ist das Ganze, jedoch sind die MAC-Adressen auf den beiden Interfaces gleich und deshalb habe ich auf meinem Switch ein MAC-Flapping.

Unter Schnittstellen -> LAN -> Port-Tabelle, habe ich LAN-2, LAN-3, BUNDLE-1 (der LAN-2 und LAN-3 beinhaltet), und die entsprechenden WLC-Tunnel auf BRG-2 gelegt.

Ist das korrekt?

Es funktioniert auch alles soweit, nur leider unsauber Aufgrund der MAC-Flapps.

Kann mir jemand einen Denkanstoß geben?

Danke!

Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben

Content-ID: 426290

Url: https://administrator.de/forum/lancom-wlc4025-zweite-management-ip-vergeben-jedoch-gleiche-mac-adresse-ip-netzwerke-426290.html

Ausgedruckt am: 22.12.2024 um 13:12 Uhr

16 Kommentare

Neuester Kommentar

Beide IP-Adressen im selben VLAN?

Nein, die bisherige war im Default-VLAN und die neue ist im VLAN 500.

Mal das mal auf oder erzeug mal eine Support-Konfigurationsdatei, weil so wie du es beschrieben hast, klingt es so, als hättest du nen dreifachen Loop gebaut.

jedoch sind die MAC-Adressen auf den beiden Interfaces gleich

Was ja auch normal ist !
Wenn du das sauber getrennt hast in VLANs ist das auch kein Problem, denn die Mac Addresstabelle ist in einem VLAN Switch immer vollkommen getrennt. Es kann also eigentlich niemals zu irgendwelchen Problemen kommen denn ein VLAN "sieht" die Mac Adressen des anderen VLANs nicht. Deshalb nutzen alle Hersteller identische Macs in den VLANs.
Dein Verhalten zeigt also eher das du was falsch konfiguriert hast !

Hier erstmal eine Übersicht:

Konfiguration Switch-Seite:

interface GigabitEthernet1/0/37
 description WLC-4025-P1
 spanning-tree portfast

interface GigabitEthernet1/0/38
 description WLC-4025-P2
 switchport mode trunk
 switchport nonegotiate
 channel-group 37 mode active
 spanning-tree portfast
 spanning-tree bpduguard enable

interface GigabitEthernet2/0/37
 description WLC-4025-P3
 switchport mode trunk
 switchport nonegotiate
 channel-group 37 mode active

interface Port-channel37
 description WLC-4025
 switchport mode trunk
 switchport nonegotiate

Etherchannel Summary:

37     Po37(SU)        LACP        Gi1/0/38(P)   Gi2/0/37(P)

Aktuell ist das neue IP-Netzwerk wieder gelöscht, heute früh aber dennoch MAC-Flaps aufgetreten. Also scheint es prinzipiell nicht an den beiden IP-Netzwerken zu liegen.

P1 = Für Management, im Default-VLAN-1
P2+3 = LAG für alle WLC-Tunnel bzw. VLANs

Port-Tabelle:

2019-03-11 12_14_39-admin2stb - remotedesktopverbindung

LAN-4 war vorher das, was jetzt das LAG sein soll. Deshalb sieht man auch bei vielen Einträgen noch "BRG-1".

VLAN-Tabelle:

2019-03-11 12_18_01-admin2stb - remotedesktopverbindung

VLAN-Port-Tabelle:

2019-03-11 12_19_13-admin2stb - remotedesktopverbindung

Gruß

EDIT:

Ein

show mac address-table address mac-adresse

zeigt die geflappte MAC ausschließlich auf dem richtigen Port (1/0/37).

Ein

show mac address-table interface po37

zeigt nicht die geflappte MAC.

EDIT2:

Im BUNDLE-1 steht die gleiche MAC-Adresse. Diese lässt sich an der Stelle allerdings editieren. Welchen Sinn hat das an dieser Stelle?

Die Cisco Etherchannel Konfig hat einen schweren Kardinalsfehler !
Die LAG Member Ports müssen immer zwingen identisch konfiguriert sein, sonst kommt der LAG nicht aktiv hoch. Ebenso das dazu korrespondierende PC Interface muss eine identische Port Syntax haben. Ist auch klar, denn diese müssen ja zwingend identisch sein.
Vermutlich hast du dir das noch niemals mit show lacp neigh oder ""show port-channel 37" angesehen ?!
Abgesehen davon hast du den ja als Trunk (LAG) definiert aber NICHT die VLANs die darüber transportiert werden sollen. Der Trunk kann so also niemals funktionieren !!
Syntaktisch richtig und korrekt wäre:
!
interface GigabitEthernet1/0/37
description WLC-LAG Member 1
switchport mode trunk
switchport-trunk allowed vlan all
switchport nonegotiate
channel-group 37 mode active
spanning-tree portfast
spanning-tree bpduguard enable
!
interface GigabitEthernet1/0/38
description WLC-LAG Member 2
switchport mode trunk
switchport-trunk allowed vlan all
switchport nonegotiate
channel-group 37 mode active
spanning-tree portfast
spanning-tree bpduguard enable
!
interface Port-channel37
description LAG auf WLC-4025
switchport mode trunk
switchport-trunk allowed vlan all
switchport nonegotiate
spanning-tree portfast
spanning-tree bpduguard enable
!
Nur so arbeitet der korrekt !
Durch das aktivierte BPDU Guard sollte dir klar sein das auf diesem Port dann keinerlei Spanning Tree Pakete kommen dürfen ! Das musst du sicherstellen das das dortige Endgerät also KEIN STP sendet.
Andernfalls geht der Port und damit auch der Port Channel sofort in den Error Disable Mode, sprich auf "shutdown".
Vermutlich sind diese Fehler der Grund für den flappenden Link weil gar kein LACP LAG zustande gekommen ist ?!

P1 = Für Management, im Default-VLAN-1

Auch das ist eigentlich kompletter Quatsch, denn das Default VLAN 1 wird, wie immer bei Cisco, im Port Channel automatisch mit übertragen.
Es ist also mehr oder minder völlig sinnfrei dafür nochmal eine extra Strippe zu ziehen !

Die Ports sind nun gleich:

interface GigabitEthernet1/0/38
 description WLC-4025-P2
 switchport mode trunk
 switchport nonegotiate
 channel-group 37 mode active

interface GigabitEthernet2/0/37
 description WLC-4025-P3
 switchport mode trunk
 switchport nonegotiate
 channel-group 37 mode active

interface Port-channel37
 description WLC-4025
 switchport mode trunk
 switchport nonegotiate

Ich habe die Member-Ports + den Port-Channel einmal neugestartet (shut, no shut), jedoch treten die MAC-Flaps weiterhin auf.

switchport trunk allowed vlan all

wurde von mir auf allen Members + PortChannel konfiguriert, taucht aber hier nicht auf, weil vermutlich auf den 9300ern Standard?

show etherchannel 37 summary

zeigt mir doch aber, dass LACP normal arbeitet!?

37     Po37(SU)        LACP        Gi1/0/38(P)   Gi2/0/37(P)

Zitat von @aqui:

P1 = Für Management, im Default-VLAN-1

LAN-1 wurde von mir erst einmal so übernommen, da ich erst einmal den Etherchannel aufbauen wollte, bevor ich diese Leitung eliminiere.

weil vermutlich auf den 9300ern Standard?

Das mag so sein. Wäre ungewöhnlich weil es auf keinem der nicht 9x00 Catalysten so ist. Möglich aber das das bei den neuen DNA Kisten angepasst wurde ?!

zeigt mir doch aber, dass LACP normal arbeitet!?

Sofern du auf beiden Members einen LACP Neighbor aktiv und negotiated siehst und der mit show int po 37 als auch mit show port-channel 37 der Interface Status auf UP / UP ist und das auch bleibt, dann ja.

Flappende Links bzw. Macs zeigt eher ein Problem mit dem Spanning Tree !! Kann es sein da dir hier doch wieder ein Mix zw. PVSTP+ und dem Rest der Welt passiert. Spricht vieles der Symptome dafür... Aber das Thema hatten wir ja schon

Zitat von @aqui:

weil vermutlich auf den 9300ern Standard?

Das mag so sein. Wäre ungewöhnlich weil es auf keinem der nicht 9x00 Catalysten so ist. Möglich aber das das bei den neuen DNA Kisten angepasst wurde ?!

zeigt mir doch aber, dass LACP normal arbeitet!?

Channel group 37 neighbors

                   LACP port                      Admin  Oper   Port    Port
Port        Flags  Priority  Dev ID          Age  key    Key    Number  State
Gi1/0/38    FA     32768     00a0.5714.85fa  29s  0x0    0x2A03 0x1     0x3F
Gi2/0/37    FA     32768     00a0.5714.85fa   9s  0x0    0x2A03 0x2     0x3F

Flappende Links bzw. Macs zeigt eher ein Problem mit dem Spanning Tree !! Kann es sein da dir hier doch wieder ein Mix zw. PVSTP+ und dem Rest der Welt passiert. Spricht vieles der Symptome dafür... Aber das Thema hatten wir ja schon

Das wäre noch eine Option, ja. Es funktioniert auch soweit alles, mir ist das halt nur aufgefallen. Dann muss ich wohl oder übel noch warten bis wir die Migration auf den neuen Core komplett abgeschlossen haben und dann nochmal schauen.

Sieht soweit gut aus was LACP anbetrifft. Auffällig ist das drastisch unterschiedliche Aging der LACP Timer auf dem Member Ports !!
Achte darauf das das LACP Timeout an allen Port und auf beiden Seiten auf "Long" gesetzt ist, das ist der Default.
https://community.cisco.com/t5/switching/lacp-partner-s-port-state-0x3d- ...
hex 0x3F ist eigentlich Short was etwas ungewöhnlich ist.
Das darf nicht unterschiedlich sein, damit es keinen LACP Timer Mismatch gibt. Wenn der WLC-4025 auf Long gesetzt ist kann das auch in flappenden LAG Member Ports resultieren !
Ggf. solltest du auf dem Cisco dann mit lacp rate normal das anpassen auf den LAG Member Port des Catalysten.

Ich habe das nun auf dem Portchannel auf "short" umgestellt, da ich nicht weiß, wie ich das auf dem WLC ändern kann. Dort scheint "short" eingestellt zu sein:

 Ports in the group:
                -------------------
Port: Gi1/0/38
------------

Port state    = Up Mstr Assoc In-Bndl
Channel group = 37          Mode = Active          Gcchange = -
Port-channel  = Po37        GC   =   -             Pseudo port-channel = Po37
Port index    = 0           Load = 0x00            Protocol =   LACP

Flags:  S - Device is sending Slow LACPDUs   F - Device is sending fast LACPDUs.
        A - Device is in active mode.        P - Device is in passive mode.

Local information:
                            LACP port  Admin     Oper    Port        Port
Port     Flags   State     Priority   Key       Key     Number      State
Gi1/0/38    FA      bndl      32768        0x25      0x25    0x127       0x3F

 Partner's information:  

                   LACP port                      Admin  Oper   Port    Port
Port        Flags  Priority  Dev ID          Age  key    Key    Number  State
Gi1/0/38    FA     32768     00a0.5714.xxxx   0s  0x0    0x2A03 0x1     0x3F

Port: Gi2/0/37
------------

Port state    = Up Mstr Assoc In-Bndl
Channel group = 37          Mode = Active          Gcchange = -
Port-channel  = Po37        GC   =   -             Pseudo port-channel = Po37
Port index    = 0           Load = 0x00            Protocol =   LACP

Flags:  S - Device is sending Slow LACPDUs   F - Device is sending fast LACPDUs.
        A - Device is in active mode.        P - Device is in passive mode.

Local information:
                            LACP port  Admin     Oper    Port        Port
Port     Flags   State     Priority   Key       Key     Number      State
Gi2/0/37    FA      bndl      32768        0x25      0x25    0x226       0x3F

 Partner's information:  

                   LACP port                      Admin  Oper   Port    Port
Port        Flags  Priority  Dev ID          Age  key    Key    Number  State
Gi2/0/37    FA     32768     00a0.5714.xxxx   0s  0x0    0x2A03 0x2     0x3F

Age of the port in the current state: 0d:00h:06m:14s

                Port-channels in the group:
                ---------------------------

Port-channel: Po37    (Primary Aggregator)

------------

Age of the Port-channel   = 1d:02h:22m:41s
Logical slot/port   = 11/37          Number of ports = 2
HotStandBy port = null
Port state          = Port-channel Ag-Inuse
Protocol            =   LACP
Port security       = Disabled

Ports in the Port-channel:

Index   Load   Port     EC state        No of bits
------+------+------+------------------+-----------
  0     00     Gi1/0/38    Active             0
  0     00     Gi2/0/37    Active             0

Time since last port bundled:    0d:00h:06m:17s    Gi2/0/37
Time since last port Un-bundled: 0d:00h:06m:18s    Gi2/0/37

Obwohl die Rates nun gleich sind, bekomme ich nach wie vor MAC-Flapping.

Sehr ungewöhnlich denn short ist in der Regel vollkommen unüblich im Default. Es wird immer Long verwendet und Short müsste man explizit immer aktivieren.
Das ist gewollt Default um eben Port Flappings mit nicht gleichen LACP Timern zu verhindern...aber nungut. Mag wirklich sein das der WLC das tatsächlich so macht. Ungewöhnlich ist es trotzdem...aber egal.

Kannst du parallel zu den Mac Flappings STP Topology Changes sehen ??
Wenn du Topo Changes siehst, zeigt das show Kommando auch wer das auslöst. (Port) das ist immer ein Indiz das dort auch der Fehler ist.
Das wird vermutlich der Fall sein was dann auf Spanning Tree Probleme schliessen lässt.

Denkbar wäre auch das 2 unterschiedliche VLANs irgendwo über eine Backdoor Bridge oder Kabel miteinander verbunden sind, was natürlich tödlich wäre.
Auch das reslultiert in solchen Mac Flaps.

Ich habe nun den einzelnen Link eliminiert und das VLAN1 mit auf den Trunk gesetzt. Fehler war vorher, dass ich den Portmodus auf dem Lancom Controller auf Trunk hatte. Es wurde also auch VLAN1 getagged.

Jetzt läuft es auf "Hybrid" und VLAN1 wird untagged übertragen.

MAC-Flaps sind jetzt weg, jedoch bleibt es doch ein Rätsel.

Vielen Dank euch!

Es wurde also auch VLAN1 getagged.

Eigentlich ungewöhnlich, denn die Welt verhält sich da in der Regel wie Cisco die auf Tagged Links das VLAN 1 immer untagged haben.
Der IEEE 802.1q Standard beschreibt das aber nicht explizit und überlässt den Herstellern wie sie das handhaben.
Bisschen komisch das Lancom da nicht Cisco und HP kompatibel ist, denn die meisten deren Kunden haben sicher diese HW. Übrigens kurioserweise auch deren eigene Switch Hardware

Aber egal...alles richtig gemacht !
Case closed.

Grüß' dich!

Gestern haben wir nun den alten Core komplett ablösen können. Ist wirklich super gelaufen. Jetzt nur noch Stück für Stück die Lancoms durch Cisco Switches tauschen und ich bin glücklich

Vielen Dank für deine Unterstützung!

Viele Grüße