8
Cisco SG500 Layer 3 Switch - LACP Flapping
Guten Tag,
wir haben folgende Netzwerkumgebung: 2x Mikrotik Router mit VRRP dienen als Firewall/Router um ins Internet zu kommen. Dahinter sind zwei Cisco SG500-28 als Stack und daran hängen dann einige Layer 3 Switches. Die Verbindung zu den Mikrotik Routern erfolgt über LACP (d.h. jeder Stack Teilnehmer der beiden Switches ist mit jedem Router verbunden). Außerdem verwenden wir LACP zwischen den Layer 3 Switch und den Layer 2 Switches. Die Layer 2 Switches sind teilweise auch noch untereinander verbunden (Redundanz). RTSP ist überall aktiviert.
Im Moment habe ich LACP bei den LAGs 1-5 deaktivert.
LAG6 ist eine Verbindung mit einem HP 1920-28P Switch.
LAG7 ist die Verbindung zum ersten Mikrotik Router.
LAG8 ist die Verbindung zum zweiten Mikrotik Router.
Auf den Mikrotik Routern ist jeweils ein Bonding mit Mode "802.3ad" aktiviert.
Nun zum Problem:
Lt. Log vom Layer 3 Switch werden laufend die Ports dem LACP-LAG entfernt und wieder hinzugefügt. Damit kommt es teilweise lt. Check_Mk zu Paketverlusten und zu teilweise langen Reaktionszeiten (>200ms). Ich vermute, dass es daran liegt, dass RTSP durch das Aktivieren und Deaktivieren der LAG Ports arbeitet.
Hat von euch jemand eine Idee, woran dieses Verhalten liegen kann?
Hier mal ein Auszug des Logs vom SG500:
Edit: Aja, Firmware auf den Mikrotiks (stable) und auf allen Switches ist aktuell.
Vielen Dank!
wir haben folgende Netzwerkumgebung: 2x Mikrotik Router mit VRRP dienen als Firewall/Router um ins Internet zu kommen. Dahinter sind zwei Cisco SG500-28 als Stack und daran hängen dann einige Layer 3 Switches. Die Verbindung zu den Mikrotik Routern erfolgt über LACP (d.h. jeder Stack Teilnehmer der beiden Switches ist mit jedem Router verbunden). Außerdem verwenden wir LACP zwischen den Layer 3 Switch und den Layer 2 Switches. Die Layer 2 Switches sind teilweise auch noch untereinander verbunden (Redundanz). RTSP ist überall aktiviert.
Im Moment habe ich LACP bei den LAGs 1-5 deaktivert.
LAG6 ist eine Verbindung mit einem HP 1920-28P Switch.
LAG7 ist die Verbindung zum ersten Mikrotik Router.
LAG8 ist die Verbindung zum zweiten Mikrotik Router.
Auf den Mikrotik Routern ist jeweils ein Bonding mit Mode "802.3ad" aktiviert.
Nun zum Problem:
Lt. Log vom Layer 3 Switch werden laufend die Ports dem LACP-LAG entfernt und wieder hinzugefügt. Damit kommt es teilweise lt. Check_Mk zu Paketverlusten und zu teilweise langen Reaktionszeiten (>200ms). Ich vermute, dass es daran liegt, dass RTSP durch das Aktivieren und Deaktivieren der LAG Ports arbeitet.
Hat von euch jemand eine Idee, woran dieses Verhalten liegen kann?
Hier mal ein Auszug des Logs vom SG500:
2018-Mar-01 16:03:24 Warning %NT_GREEN-W-EeeLldpMultiNeighbours: Multiple LLDP neighbours on port gi2/1/3 - EEE operational state is FALSE
2018-Mar-01 16:03:24 Warning %NT_GREEN-W-EeeLldpSingleNeighbour: Single LLDP neighbour on port gi2/1/3 - EEE operational state can be TRUE
2018-Mar-01 16:03:08 Warning %NT_GREEN-W-EeeLldpMultiNeighbours: Multiple LLDP neighbours on port gi1/1/22 - EEE operational state is FALSE
2018-Mar-01 15:56:24 Warning %NT_GREEN-W-EeeLldpMultiNeighbours: Multiple LLDP neighbours on port gi2/1/3 - EEE operational state is FALSE
2018-Mar-01 15:56:08 Warning %NT_GREEN-W-EeeLldpSingleNeighbour: Single LLDP neighbour on port gi1/1/22 - EEE operational state can be TRUE
2018-Mar-01 15:55:24 Warning %NT_GREEN-W-EeeLldpSingleNeighbour: Single LLDP neighbour on port gi2/1/3 - EEE operational state can be TRUE
2018-Mar-01 15:55:15 Informational %TRUNK-I-PORTADDED: Port gi1/1/2 added to Po8
2018-Mar-01 15:55:15 Warning %TRUNK-W-PORTREMOVED: Port gi1/1/2 removed from Po8
2018-Mar-01 15:53:15 Informational %AAA-I-DISCONNECT: http connection for user cisco, source 10.150.50.100 destination 10.150.162.254 TERMINATED
2018-Mar-01 15:51:08 Warning %NT_GREEN-W-EeeLldpMultiNeighbours: Multiple LLDP neighbours on port gi1/1/22 - EEE operational state is FALSE
2018-Mar-01 15:50:07 Informational %TRUNK-I-PORTADDED: Port gi1/1/3 added to Po7
2018-Mar-01 15:50:07 Warning %TRUNK-W-PORTREMOVED: Port gi1/1/3 removed from Po7
2018-Mar-01 15:49:40 Informational %AAA-I-CONNECT: New http connection for user cisco, source 10.150.50.100 destination 10.150.162.254 ACCEPTED
2018-Mar-01 15:49:08 Warning %NT_GREEN-W-EeeLldpSingleNeighbour: Single LLDP neighbour on port gi1/1/22 - EEE operational state can be TRUE
2018-Mar-01 15:48:08 Informational %TRUNK-I-PORTADDED: Port gi1/1/3 added to Po7, aggregated (3)
2018-Mar-01 15:48:07 Warning %TRUNK-W-PORTREMOVED: Port gi1/1/3 removed from Po7, aggregated (3)
2018-Mar-01 15:45:36 Informational %TRUNK-I-PORTADDED: Port gi1/1/7 added to Po6, aggregated (1)
2018-Mar-01 15:45:36 Warning %TRUNK-W-PORTREMOVED: Port gi1/1/7 removed from Po6, aggregated (1)
2018-Mar-01 15:45:36 Informational %TRUNK-I-PORTADDED: Port gi2/1/5 added to Po6, aggregated (1)
2018-Mar-01 15:45:35 Warning %TRUNK-W-PORTREMOVED: Port gi2/1/5 removed from Po6, aggregated (1)
2018-Mar-01 15:44:06 Warning %STP-W-PORTSTATUS: Po6: STP status Forwarding
2018-Mar-01 15:44:06 Informational %TRUNK-I-PORTADDED: Port gi2/1/5 added to Po6
2018-Mar-01 15:44:05 Informational %LINK-I-Up: Po6
2018-Mar-01 15:44:05 Informational %TRUNK-I-PORTADDED: Port gi1/1/7 added to Po6
2018-Mar-01 15:44:05 Warning %LINK-W-Down: Po6
2018-Mar-01 15:44:05 Warning %TRUNK-W-PORTREMOVED: Port gi1/1/7 removed from Po6
2018-Mar-01 15:44:05 Warning %TRUNK-W-PORTREMOVED: Port gi2/1/5 removed from Po6
2018-Mar-01 15:43:37 Informational %TRUNK-I-PORTADDED: Port gi1/1/3 added to Po7
2018-Mar-01 15:43:37 Warning %TRUNK-W-PORTREMOVED: Port gi1/1/3 removed from Po7
2018-Mar-01 15:38:07 Informational %TRUNK-I-PORTADDED: Port gi1/1/3 added to Po7
2018-Mar-01 15:38:07 Warning %TRUNK-W-PORTREMOVED: Port gi1/1/3 removed from Po7
2018-Mar-01 15:31:08 Informational %TRUNK-I-PORTADDED: Port gi2/1/3 added to Po7, aggregated (1)
2018-Mar-01 15:31:08 Warning %TRUNK-W-PORTREMOVED: Port gi2/1/3 removed from Po7, aggregated (1)
2018-Mar-01 15:30:37 Informational %TRUNK-I-PORTADDED: Port gi1/1/3 added to Po7
2018-Mar-01 15:30:37 Warning %TRUNK-W-PORTREMOVED: Port gi1/1/3 removed from Po7
2018-Mar-01 15:29:38 Informational %TRUNK-I-PORTADDED: Port gi2/1/3 added to Po7, aggregated (1)
2018-Mar-01 15:29:36 Warning %TRUNK-W-PORTREMOVED: Port gi2/1/3 removed from Po7, aggregated (1)
2018-Mar-01 15:28:45 Informational %TRUNK-I-PORTADDED: Port gi1/1/2 added to Po8
2018-Mar-01 15:28:45 Warning %TRUNK-W-PORTREMOVED: Port gi1/1/2 removed from Po8
2018-Mar-01 15:28:24 Warning %NT_GREEN-W-EeeLldpMultiNeighbours: Multiple LLDP neighbours on port gi2/1/3 - EEE operational state is FALSE
2018-Mar-01 15:28:24 Warning %NT_GREEN-W-EeeLldpSingleNeighbour: Single LLDP neighbour on port gi2/1/3 - EEE operational state can be TRUE
2018-Mar-01 15:27:37 Informational %TRUNK-I-PORTADDED: Port gi2/1/3 added to Po7, aggregated (2)
2018-Mar-01 15:27:37 Warning %TRUNK-W-PORTREMOVED: Port gi2/1/3 removed from Po7, aggregated (2)
2018-Mar-01 15:24:37 Informational %TRUNK-I-PORTADDED: Port gi2/1/3 added to Po7
2018-Mar-01 15:24:36 Warning %TRUNK-W-PORTREMOVED: Port gi2/1/3 removed from Po7
2018-Mar-01 15:21:37 Informational %TRUNK-I-PORTADDED: Port gi2/1/5 added to Po6 Edit: Aja, Firmware auf den Mikrotiks (stable) und auf allen Switches ist aktuell.
Vielen Dank!
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Content-Key: 366616
Url: https://administrator.de/contentid/366616
Printed on: April 26, 2024 at 07:04 o'clock
8 Comments
Latest comment
jeder Stack Teilnehmer der beiden Switches ist mit jedem Router verbunden
Mmmhhh.. Das solltest du nochmal näher beschreiben und zwar derart WO deine LACP Member genau liegen.OK ein Stack verhält sich wie ein einzelner Switch, in der Beziehung kannst du dort dein LAG Member frei verteilen.
Aber auf den Mikrotiks geht das logischerweise nicht, denn die supporten keine LAG Virtualisierung wie man das von Cisco vPC oder Brocade MCT usw. kennt.
Dort MÜSSEN die LAGs zwangsweise auch einem Gerät landen ! Ein Splitting ist NICHT supportet. Logisch, denn VRRP ist eine reine Gateway Redundanz hat aber nichts mit LAG Virtualisierung zu tun !!
Hoffe du hast das im Hinterkopf.
Praktisch gesprochen kannst du z.B. auf einem SG500 2er Stack einen LAG von einem Port auf Member 1 und einem Port auf Member 2 bilden den aber NICHT mit einem Bein dann auf MT 1 und dem anderen Bein auf MT2 enden lassen. Das geht NICHT !
Der LAG muss also mit beiden Links zwingend auch MT1 oder MT2 enden.
Du bräuchtest dann also 2 LAGs wenn du mit LAGs zum Router arbeitetst. Sprich also einen LAG von einem Port auf Switch Member 1 und einem Port auf Switch Member 2 der zum MT1 geht und dann einen weiteren, separaten LAG von einem Port auf Switch Member 1 und einem Port auf Switch Member 2 der dann zum MT2 geht.
Anders geht das nicht.
Diese Beschreibung ist also etwas verwirrend oben.
Hilfreich wäre mal ein Winbox Screenshot der MT LACP Konfig und der Switches.
Hier findest du ein paar Infos dazu:
Netzwerk Management Server mit Raspberry Pi
VRRP zum MT hier:
VRRP Einrichtung
Es sollte klar sein das die Ciscos und die MT die jeweils aktuellste Firmware haben.
Zitat von @aqui:
OK ein Stack verhält sich wie ein einzelner Switch, in der Beziehung kannst du dort dein LAG Member frei verteilen.
Aber auf den Mikrotiks geht das logischerweise nicht, denn die supporten keine LAG Virtualisierung wie man das von Cisco vPC oder Brocade MCT usw. kennt.
Dort MÜSSEN die LAGs zwangsweise auch einem Gerät landen ! Ein Splitting ist NICHT supportet. Logisch, denn VRRP ist eine reine Gateway Redundanz hat aber nichts mit LAG Virtualisierung zu tun !!
Hoffe du hast das im Hinterkopf.
Praktisch gesprochen kannst du z.B. auf einem SG500 2er Stack einen LAG von einem Port auf Member 1 und einem Port auf Member 2 bilden den aber NICHT mit einem Bein dann auf MT 1 und dem anderen Bein auf MT2 enden lassen. Das geht NICHT !
Der LAG muss also mit beiden Links zwingend auch MT1 oder MT2 enden.
Du bräuchtest dann also 2 LAGs wenn du mit LAGs zum Router arbeitetst. Sprich also einen LAG von einem Port auf Switch Member 1 und einem Port auf Switch Member 2 der zum MT1 geht und dann einen weiteren, separaten LAG von einem Port auf Switch Member 1 und einem Port auf Switch Member 2 der dann zum MT2 geht.
Genau das hätten wir eigentlich.jeder Stack Teilnehmer der beiden Switches ist mit jedem Router verbunden
Mmmhhh.. Das solltest du nochmal näher beschreiben und zwar derart WO deine LACP Member genau liegen.OK ein Stack verhält sich wie ein einzelner Switch, in der Beziehung kannst du dort dein LAG Member frei verteilen.
Aber auf den Mikrotiks geht das logischerweise nicht, denn die supporten keine LAG Virtualisierung wie man das von Cisco vPC oder Brocade MCT usw. kennt.
Dort MÜSSEN die LAGs zwangsweise auch einem Gerät landen ! Ein Splitting ist NICHT supportet. Logisch, denn VRRP ist eine reine Gateway Redundanz hat aber nichts mit LAG Virtualisierung zu tun !!
Hoffe du hast das im Hinterkopf.
Praktisch gesprochen kannst du z.B. auf einem SG500 2er Stack einen LAG von einem Port auf Member 1 und einem Port auf Member 2 bilden den aber NICHT mit einem Bein dann auf MT 1 und dem anderen Bein auf MT2 enden lassen. Das geht NICHT !
Der LAG muss also mit beiden Links zwingend auch MT1 oder MT2 enden.
Du bräuchtest dann also 2 LAGs wenn du mit LAGs zum Router arbeitetst. Sprich also einen LAG von einem Port auf Switch Member 1 und einem Port auf Switch Member 2 der zum MT1 geht und dann einen weiteren, separaten LAG von einem Port auf Switch Member 1 und einem Port auf Switch Member 2 der dann zum MT2 geht.
Anders geht das nicht.
Diese Beschreibung ist also etwas verwirrend oben.
Hilfreich wäre mal ein Winbox Screenshot der MT LACP Konfig und der Switches.
Hier die Screenshots:Diese Beschreibung ist also etwas verwirrend oben.
Hilfreich wäre mal ein Winbox Screenshot der MT LACP Konfig und der Switches.
Kabelverbindungen:
MT1 eth4 - L3-Switch 1/1/3
MT1 eth5 - L3-Switch 2/1/3
MT2 eth4 - L3-Switch 1/1/2
MT2 eth5 - L3-Switch 2/1/2
Hier findest du ein paar Infos dazu:
Netzwerk Management Server mit Raspberry Pi
VRRP zum MT hier:
VRRP Einrichtung
Es sollte klar sein das die Ciscos und die MT die jeweils aktuellste Firmware haben.
Ja, das haben sie. Ist mir später auch eingefallen, dass ich das in den Beitrag einfügen könnte und hab es dann noch hinzugefügt.Netzwerk Management Server mit Raspberry Pi
VRRP zum MT hier:
VRRP Einrichtung
Es sollte klar sein das die Ciscos und die MT die jeweils aktuellste Firmware haben.
OK, soweit sieht das OK aus mit dem LACP.
Hast du die LACP Timer mal verglichen im Cisco und im MT ob es da Unterschiede gibt ? Wäre ggf. auch noch eine Fehlerquelle.
Nimmt der MT auch am RSTP Prozess teil bzw. ist dort auf dem LAG Interfaces zum Switch RSTP aktiviert ?
Solltest du machen !
Was noch wichtig ist, ist dem Core Switch, was ja vermutlich der Stack bei dir ist eine RSTP Priority zu verpassen die höher ist als der default. Damit erzwingt man in der Root Switch Selection das der Core Switch immer Root Switch wird.
Die Priority wird modulo 4096 vergeben. Kleinere Werte als der default = höhere Prio. Dem SG500 Stack solltest du das unbedingt so einstellen wenn der der Core Switch bei dir ist !
Hast du die LACP Timer mal verglichen im Cisco und im MT ob es da Unterschiede gibt ? Wäre ggf. auch noch eine Fehlerquelle.
Nimmt der MT auch am RSTP Prozess teil bzw. ist dort auf dem LAG Interfaces zum Switch RSTP aktiviert ?
Solltest du machen !
Was noch wichtig ist, ist dem Core Switch, was ja vermutlich der Stack bei dir ist eine RSTP Priority zu verpassen die höher ist als der default. Damit erzwingt man in der Root Switch Selection das der Core Switch immer Root Switch wird.
Die Priority wird modulo 4096 vergeben. Kleinere Werte als der default = höhere Prio. Dem SG500 Stack solltest du das unbedingt so einstellen wenn der der Core Switch bei dir ist !
Zitat von @aqui:
OK, soweit sieht das OK aus mit dem LACP.
Hast du die LACP Timer mal verglichen im Cisco und im MT ob es da Unterschiede gibt ? Wäre ggf. auch noch eine Fehlerquelle.
OK, soweit sieht das OK aus mit dem LACP.
Hast du die LACP Timer mal verglichen im Cisco und im MT ob es da Unterschiede gibt ? Wäre ggf. auch noch eine Fehlerquelle.
Bei Cisco steht der LACP Timer auf "Long" bei den Mikrotiks auf 30s. Das müsste passen.
Nimmt der MT auch am RSTP Prozess teil bzw. ist dort auf dem LAG Interfaces zum Switch RSTP aktiviert ?
Solltest du machen !
Solltest du machen !
Nein die MTs nehmen nicht am RSTP Prozess teil. Wie kann ich das am besten konfigurieren? Mikrotik kann ja m.E. nur auf Bridges STP. Muss ich also eine neue Bridge anlegen und das Bonding dahinein werfen?
Was noch wichtig ist, ist dem Core Switch, was ja vermutlich der Stack bei dir ist eine RSTP Priority zu verpassen die höher ist als der default. Damit erzwingt man in der Root Switch Selection das der Core Switch immer Root Switch wird.
Die Priority wird modulo 4096 vergeben. Kleinere Werte als der default = höhere Prio. Dem SG500 Stack solltest du das unbedingt so einstellen wenn der der Core Switch bei dir ist !
Die Priority wird modulo 4096 vergeben. Kleinere Werte als der default = höhere Prio. Dem SG500 Stack solltest du das unbedingt so einstellen wenn der der Core Switch bei dir ist !
Das ist meine Konfig: (relativ ähnlich
)
Vielen Dank!
Mikrotik kann ja m.E. nur auf Bridges STP.
Das stimmt, da hast du Recht. Macht ja auch nur Sinn auf Bridges 
Die Frage ist wie der MT mit RSTP BPDU Frames auf einem LAG umgeht. Sollte er diese forwarden zw. den LAG Member hat man natürlich ein gravierendes Problem mit flappenden Links auf dem Switch, da die dann abwechselnd dort ins Blocking gehen. Wäre ein möglicher Fehler.
Das kannst du aber ganz schnell mal querchecken indem du auf dem Switch an den jeweiligen LAG Member Ports zum MT mal das RSTP Spanning Tree abschaltest.
Dann kann der MT nicht mehr die BPDUs loopen (da ja keine mehr kommen
) und es sollte ruhig werden im Netz.Wär mal einen Versuch wert....
Zitat von @aqui:
Die Frage ist wie der MT mit RSTP BPDU Frames auf einem LAG umgeht. Sollte er diese forwarden zw. den LAG Member hat man natürlich ein gravierendes Problem mit flappenden Links auf dem Switch, da die dann abwechselnd dort ins Blocking gehen. Wäre ein möglicher Fehler.
Das kannst du aber ganz schnell mal querchecken indem du auf dem Switch an den jeweiligen LAG Member Ports zum MT mal das RSTP Spanning Tree abschaltest.
Dann kann der MT nicht mehr die BPDUs loopen (da ja keine mehr kommen ) und es sollte ruhig werden im Netz.
Wär mal einen Versuch wert....
Mikrotik kann ja m.E. nur auf Bridges STP.
Das stimmt, da hast du Recht. Macht ja auch nur Sinn auf Bridges Die Frage ist wie der MT mit RSTP BPDU Frames auf einem LAG umgeht. Sollte er diese forwarden zw. den LAG Member hat man natürlich ein gravierendes Problem mit flappenden Links auf dem Switch, da die dann abwechselnd dort ins Blocking gehen. Wäre ein möglicher Fehler.
Das kannst du aber ganz schnell mal querchecken indem du auf dem Switch an den jeweiligen LAG Member Ports zum MT mal das RSTP Spanning Tree abschaltest.
Dann kann der MT nicht mehr die BPDUs loopen (da ja keine mehr kommen
) und es sollte ruhig werden im Netz.Wär mal einen Versuch wert....
Hab die Konfiguration vom Cisco Switch mal so angepasst, dass RSTP auf den betreffenden Ports und den LAGs ausgeschaltet ist.
Mal sehen, ob es ruhiger wird....
Danke jedenfalls!
Das Flapping ist geringer geworden aber leider immer noch nicht weg.
Weiß jemand, was es mit diesen "%NT_GREEN-W-EeeLldpMultiNeighbours: Multiple LLDP neighbours on port" Warnings auf sich hat?
Hier der aktuelle Log vom Cisco L3-Switch:
Weiß jemand, was es mit diesen "%NT_GREEN-W-EeeLldpMultiNeighbours: Multiple LLDP neighbours on port" Warnings auf sich hat?
Hier der aktuelle Log vom Cisco L3-Switch:
2147483585 2018-Mar-02 12:26:50 Informational %AAA-I-CONNECT: New http connection for user cisco, source 10.150.100.102 destination 10.150.162.254 ACCEPTED
2147483586 2018-Mar-02 12:24:32 Warning %NT_GREEN-W-EeeLldpMultiNeighbours: Multiple LLDP neighbours on port gi1/1/7 - EEE operational state is FALSE
2147483587 2018-Mar-02 12:24:32 Warning %NT_GREEN-W-EeeLldpSingleNeighbour: Single LLDP neighbour on port gi1/1/7 - EEE operational state can be TRUE
2147483588 2018-Mar-02 12:23:27 Warning %NT_GREEN-W-EeeLldpMultiNeighbours: Multiple LLDP neighbours on port gi2/1/3 - EEE operational state is FALSE
2147483589 2018-Mar-02 12:20:27 Informational %TRUNK-I-PORTADDED: Port gi2/1/3 added to Po7
2147483590 2018-Mar-02 12:20:27 Warning %NT_GREEN-W-EeeLldpSingleNeighbour: Single LLDP neighbour on port gi2/1/3 - EEE operational state can be TRUE
2147483591 2018-Mar-02 12:20:27 Warning %TRUNK-W-PORTREMOVED: Port gi2/1/3 removed from Po7
2147483592 2018-Mar-02 12:04:27 Warning %NT_GREEN-W-EeeLldpMultiNeighbours: Multiple LLDP neighbours on port gi2/1/3 - EEE operational state is FALSE
2147483593 2018-Mar-02 11:54:57 Informational %TRUNK-I-PORTADDED: Port gi2/1/3 added to Po7, aggregated (2)
2147483594 2018-Mar-02 11:54:57 Warning %TRUNK-W-PORTREMOVED: Port gi2/1/3 removed from Po7, aggregated (2)
2147483595 2018-Mar-02 11:50:57 Informational %TRUNK-I-PORTADDED: Port gi2/1/3 added to Po7
2147483596 2018-Mar-02 11:50:57 Warning %TRUNK-W-PORTREMOVED: Port gi2/1/3 removed from Po7
2147483597 2018-Mar-02 11:49:27 Warning %NT_GREEN-W-EeeLldpSingleNeighbour: Single LLDP neighbour on port gi2/1/3 - EEE operational state can be TRUE
2147483598 2018-Mar-02 11:45:47 Informational %TRUNK-I-PORTADDED: Port gi1/1/2 added to Po8
2147483599 2018-Mar-02 11:45:47 Warning %TRUNK-W-PORTREMOVED: Port gi1/1/2 removed from Po8
2147483600 2018-Mar-02 11:45:13 Warning %NT_GREEN-W-EeeLldpMultiNeighbours: Multiple LLDP neighbours on port gi1/1/22 - EEE operational state is FALSE
2147483601 2018-Mar-02 11:44:27 Warning %NT_GREEN-W-EeeLldpMultiNeighbours: Multiple LLDP neighbours on port gi2/1/3 - EEE operational state is FALSE
2147483602 2018-Mar-02 11:42:27 Informational %TRUNK-I-PORTADDED: Port gi2/1/3 added to Po7
2147483603 2018-Mar-02 11:42:27 Warning %TRUNK-W-PORTREMOVED: Port gi2/1/3 removed from Po7
2147483604 2018-Mar-02 11:42:27 Warning %NT_GREEN-W-EeeLldpSingleNeighbour: Single LLDP neighbour on port gi2/1/3 - EEE operational state can be TRUE
2147483605 2018-Mar-02 11:42:13 Warning %NT_GREEN-W-EeeLldpSingleNeighbour: Single LLDP neighbour on port gi1/1/22 - EEE operational state can be TRUE
2147483606 2018-Mar-02 11:36:30 Informational %TRUNK-I-PORTADDED: Port gi2/1/5 added to Po6
2147483607 2018-Mar-02 11:36:30 Warning %TRUNK-W-PORTREMOVED: Port gi2/1/5 removed from Po6
2147483608 2018-Mar-02 11:36:27 Warning %NT_GREEN-W-EeeLldpMultiNeighbours: Multiple LLDP neighbours on port gi2/1/3 - EEE operational state is FALSE
2147483609 2018-Mar-02 11:36:13 Warning %NT_GREEN-W-EeeLldpMultiNeighbours: Multiple LLDP neighbours on port gi1/1/22 - EEE operational state is FALSE
2147483610 2018-Mar-02 11:34:27 Informational %TRUNK-I-PORTADDED: Port gi2/1/3 added to Po7
2147483611 2018-Mar-02 11:34:27 Warning %TRUNK-W-PORTREMOVED: Port gi2/1/3 removed from Po7
2147483612 2018-Mar-02 11:34:27 Warning %NT_GREEN-W-EeeLldpSingleNeighbour: Single LLDP neighbour on port gi2/1/3 - EEE operational state can be TRUE
2147483613 2018-Mar-02 11:34:13 Warning %NT_GREEN-W-EeeLldpSingleNeighbour: Single LLDP neighbour on port gi1/1/22 - EEE operational state can be TRUE
2147483614 2018-Mar-02 11:21:27 Warning %NT_GREEN-W-EeeLldpMultiNeighbours: Multiple LLDP neighbours on port gi2/1/3 - EEE operational state is FALSE
2147483615 2018-Mar-02 11:19:27 Warning %NT_GREEN-W-EeeLldpSingleNeighbour: Single LLDP neighbour on port gi2/1/3 - EEE operational state can be TRUE
2147483616 2018-Mar-02 11:19:13 Warning %NT_GREEN-W-EeeLldpMultiNeighbours: Multiple LLDP neighbours on port gi1/1/22 - EEE operational state is FALSE
2147483617 2018-Mar-02 11:19:13 Warning %NT_GREEN-W-EeeLldpSingleNeighbour: Single LLDP neighbour on port gi1/1/22 - EEE operational state can be TRUE
2147483618 2018-Mar-02 11:18:57 Informational %TRUNK-I-PORTADDED: Port gi2/1/3 added to Po7
2147483619 2018-Mar-02 11:18:57 Warning %TRUNK-W-PORTREMOVED: Port gi2/1/3 removed from Po7
2147483620 2018-Mar-02 11:12:13 Warning %NT_GREEN-W-EeeLldpMultiNeighbours: Multiple LLDP neighbours on port gi1/1/22 - EEE operational state is FALSE
2147483621 2018-Mar-02 11:12:13 Warning %NT_GREEN-W-EeeLldpSingleNeighbour: Single LLDP neighbour on port gi1/1/22 - EEE operational state can be TRUE
2147483622 2018-Mar-02 11:11:27 Warning %NT_GREEN-W-EeeLldpMultiNeighbours: Multiple LLDP neighbours on port gi2/1/3 - EEE operational state is FALSE
2147483623 2018-Mar-02 11:11:27 Warning %NT_GREEN-W-EeeLldpSingleNeighbour: Single LLDP neighbour on port gi2/1/3 - EEE operational state can be TRUE
2147483624 2018-Mar-02 11:07:31 Warning %NT_GREEN-W-EeeLldpMultiNeighbours: Multiple LLDP neighbours on port gi1/1/7 - EEE operational state is FALSE
2147483625 2018-Mar-02 11:07:31 Warning %NT_GREEN-W-EeeLldpSingleNeighbour: Single LLDP neighbour on port gi1/1/7 - EEE operational state can be TRUE
2147483626 2018-Mar-02 11:04:27 Warning %NT_GREEN-W-EeeLldpMultiNeighbours: Multiple LLDP neighbours on port gi2/1/3 - EEE operational state is FALSE
2147483627 2018-Mar-02 11:04:27 Warning %NT_GREEN-W-EeeLldpSingleNeighbour: Single LLDP neighbour on port gi2/1/3 - EEE operational state can be TRUE
2147483628 2018-Mar-02 11:03:27 Informational %TRUNK-I-PORTADDED: Port gi2/1/3 added to Po7
2147483629 2018-Mar-02 11:03:27 Warning %TRUNK-W-PORTREMOVED: Port gi2/1/3 removed from Po7
2147483630 2018-Mar-02 10:57:31 Warning %NT_GREEN-W-EeeLldpMultiNeighbours: Multiple LLDP neighbours on port gi2/1/5 - EEE operational state is FALSE
2147483631 2018-Mar-02 10:57:31 Warning %NT_GREEN-W-EeeLldpMultiNeighbours: Multiple LLDP neighbours on port gi1/1/7 - EEE operational state is FALSE
2147483632 2018-Mar-02 10:57:31 Warning %NT_GREEN-W-EeeLldpSingleNeighbour: Single LLDP neighbour on port gi2/1/5 - EEE operational state can be TRUE
2147483633 2018-Mar-02 10:57:31 Warning %NT_GREEN-W-EeeLldpSingleNeighbour: Single LLDP neighbour on port gi1/1/7 - EEE operational state can be TRUE
2147483634 2018-Mar-02 10:56:27 Warning %NT_GREEN-W-EeeLldpMultiNeighbours: Multiple LLDP neighbours on port gi2/1/3 - EEE operational state is FALSE Weiß jemand, was es mit diesen "%NT_GRE
Ja, das sind Clients die per LLDP dem Switch ein EEE Interface (Energy Efficient Ethernet) signalisieren. Da das eh (fast) keiner durchgehend kann solltest du das mal deaktivieren.