6
CISCO LACP Portchannel - SNMP Trap bei Änderung eines Members
Hallo zusammen,
ich stecke gerade fest bei folgendem Problem: Ich habe einen Portchannel (je 2 Ports, LACP) zwischen zwei CISCO Switches (Cat 2960-X und Nexus 55xx). Es geht hier um eine WAN-Strecke (über zwei verschiedene Carrier), über die L2-Protokolle getunnelt werden. An den Interfaces der Switches steckt jeweils ein NT-Interface eines Carriers. Der Portchannel funktioniert absolut problemlos. Nun möchte ich den Portchannel überwachen, und zwar dahingehend, dass ich wissen möchte, wenn eine Leitung (also ein Carrier) down geht.
Nun das Problem: Der Link-Status der Interfaces wird sich nicht ändern, denn da hängt ja der jeweilige NT dran. Wohl aber läuft der Portchannel dann nur noch über ein Member, und die LACP Messages werden dann ja auch nicht mehr getunnelt. Wie kriege ich es hin, dass ein SNMP Trap geschickt wird, wenn sich der Status des PC ändert, obwohl die Interfaces darunter beide up bleiben und auch der PC weiter funktioniert?
Danke vorab!
ich stecke gerade fest bei folgendem Problem: Ich habe einen Portchannel (je 2 Ports, LACP) zwischen zwei CISCO Switches (Cat 2960-X und Nexus 55xx). Es geht hier um eine WAN-Strecke (über zwei verschiedene Carrier), über die L2-Protokolle getunnelt werden. An den Interfaces der Switches steckt jeweils ein NT-Interface eines Carriers. Der Portchannel funktioniert absolut problemlos. Nun möchte ich den Portchannel überwachen, und zwar dahingehend, dass ich wissen möchte, wenn eine Leitung (also ein Carrier) down geht.
Nun das Problem: Der Link-Status der Interfaces wird sich nicht ändern, denn da hängt ja der jeweilige NT dran. Wohl aber läuft der Portchannel dann nur noch über ein Member, und die LACP Messages werden dann ja auch nicht mehr getunnelt. Wie kriege ich es hin, dass ein SNMP Trap geschickt wird, wenn sich der Status des PC ändert, obwohl die Interfaces darunter beide up bleiben und auch der PC weiter funktioniert?
Danke vorab!
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: 325105
Url: https://administrator.de/contentid/325105
Printed on: April 20, 2024 at 03:04 o'clock
6 Comments
Latest comment
Eventuell mit "ip sla"
Das habe ich auf die schnelle gefunden:
https://supportforums.cisco.com/discussion/11093796/ip-sla-snmp-traps
Damit hast du schon mal ein Konfigurations Beispiel.
Ansonsten die entsprechenden Command Reference oder den Configuration Guide verwenden.
have fun
Das habe ich auf die schnelle gefunden:
https://supportforums.cisco.com/discussion/11093796/ip-sla-snmp-traps
Damit hast du schon mal ein Konfigurations Beispiel.
Ansonsten die entsprechenden Command Reference oder den Configuration Guide verwenden.
have fun
Mache UDLD auf dem Interface, das funktioniert Point to Point über den NT.
Du bekommst aber auch ohne UDLD sofort eine Syslog Message wenn einer der LACP Links down ist. Syslog geht also immer.
Du bekommst aber auch ohne UDLD sofort eine Syslog Message wenn einer der LACP Links down ist. Syslog geht also immer.
Hi,
zumindest von den EthernetConnect der Telekom mit ADVA-NTs kenn ichs so, dass der Link zum Switch down geht, wenn der Carrierlink weg ist. Was für NTs hast du?
zumindest von den EthernetConnect der Telekom mit ADVA-NTs kenn ichs so, dass der Link zum Switch down geht, wenn der Carrierlink weg ist. Was für NTs hast du?
Nützt aber auch nix wenn innerhalb der Carrierverbindung ein Links ausfällt. Solche Dienste werden als VLL oder VPLS im MPLS Backbone des Providers realisiert.
Solange also der Link zum Provider Access System UP ist ist auch der Switchlink UP. Der merkt eben nicht wenn in der Backbone Wolke beim Provider was ausfällt. Dort hilt nur ein Keepalive Programm wie UDLD oder der LACP Keepalive beim LAG.
Solange also der Link zum Provider Access System UP ist ist auch der Switchlink UP. Der merkt eben nicht wenn in der Backbone Wolke beim Provider was ausfällt. Dort hilt nur ein Keepalive Programm wie UDLD oder der LACP Keepalive beim LAG.
Ja guut, das ist in dem Fall natürlich so. Dazu kann ich bei den Systemen auch nichts sagen, das waren Direktverbindungen RZ -> Customer, da funktioniert es.
Danke für den Hinweis mit UDLD, das werde ich hier intern mal nachbauen und dann im Erfolgsfall ausrollen.
