11
HP Procurve 2920 2530 snmp-server nicht erreichbar
Hallo zusammen,
ich hoffe diese Frage wurde nicht schon gestellt. Gefunden hab ich leider nichts.
Wir überwachen unsere Switche über snmp v2c mit PRTG. Bisher ohne Probleme.
Da die Verwaltungszugänge aber vom Client-Netz aus erreichbar waren haben wir jetzt ein Management-VLAN eingerichtet.
Dort sind alle Switche drin und der Monitoring-Server hat auch ein Standbein in diesem VLAN.
Nachdem nun die Switche aber neue IPs( im Management-VLAN) bekommen haben sind diese nicht mehr per SNMP erreichbar. Selbst wenn ich meinen Laptop direkt am Switch anschließe(am entsprechenden VLAN) nicht.
Ausgabe eines SNMP-Testers. Der Server hat die IPs: 172.20.3.198, 172.20.2.35, das Switch in diesem Fall die 172.20.3.106
Ausgabe von show snmp-server
Ich hab auch den snmp-server deaktiviert und aktiviert oder snmpv3 einzurichten. Nichts hat wirklich erfolg gezeigt.
Meine Vermutung ist, dass ich dem Dienst irgendwie sagen muss, dass er in dem Management-VLAN hören soll und auch darüber antworten. Aber ich finde einfach keinen Weg wie.
Vielleicht kann mir da jemand helfen?
ich hoffe diese Frage wurde nicht schon gestellt. Gefunden hab ich leider nichts.
Wir überwachen unsere Switche über snmp v2c mit PRTG. Bisher ohne Probleme.
Da die Verwaltungszugänge aber vom Client-Netz aus erreichbar waren haben wir jetzt ein Management-VLAN eingerichtet.
Dort sind alle Switche drin und der Monitoring-Server hat auch ein Standbein in diesem VLAN.
Nachdem nun die Switche aber neue IPs( im Management-VLAN) bekommen haben sind diese nicht mehr per SNMP erreichbar. Selbst wenn ich meinen Laptop direkt am Switch anschließe(am entsprechenden VLAN) nicht.
Ausgabe eines SNMP-Testers. Der Server hat die IPs: 172.20.3.198, 172.20.2.35, das Switch in diesem Fall die 172.20.3.106
----------------------- New Test -----------------------
Paessler SNMP Tester 5.2.3 Computername: xxxx Interface: (172.20.3.198, 172.20.2.35)
29.04.2020 11:17:25 (7 ms) : Device: 172.20.3.106
29.04.2020 11:17:25 (10 ms) : SNMP V2c
29.04.2020 11:17:25 (13 ms) : Uptime
29.04.2020 11:17:25 (22 ms) : SNMP Datatype: ASN_TIMETICKS
29.04.2020 11:17:25 (25 ms) : -------
29.04.2020 11:17:25 (28 ms) : DISMAN-EVENT-MIB::sysUpTimeInstance = 2780270415 ( 0 seconds )
29.04.2020 11:17:25 (36 ms) : SNMP Datatype: SNMP_EXCEPTION_NOSUCHOBJECT
29.04.2020 11:17:25 (41 ms) : HOST-RESOURCES-MIB::hrSystemUptime.0 = No such object (SNMP error # 222) ( 0 seconds )
29.04.2020 11:17:25 (45 ms) : DoneAusgabe von show snmp-server
SNMP Communities
Community Name MIB View Write Access
-------------------------------- -------- ------------
public Manager Unrestricted
Trap Receivers
Link-Change Traps Enabled on Ports [All] : All
Traps Category Current Status
_____________________________ __________________
SNMP Authentication : Extended
Password change : Enabled
Login failures : Enabled
Port-Security : Enabled
Authorization Server Contact : Enabled
DHCP-Snooping : Enabled
Dynamic ARP Protection : Enabled
Dynamic IP Lockdown : Enabled
Startup Config change : Disabled
Running Config Change : Disabled
MAC Address Count : Disabled
Address Community Events Type Retry Timeout
---------------------- ---------------------- -------- ------ ------- -------
Excluded MIBs
Snmp Response Pdu Source-IP Information
Selection Policy : rfc1517
Trap Pdu Source-IP Information
Selection Policy : rfc1517Ich hab auch den snmp-server deaktiviert und aktiviert oder snmpv3 einzurichten. Nichts hat wirklich erfolg gezeigt.
Meine Vermutung ist, dass ich dem Dienst irgendwie sagen muss, dass er in dem Management-VLAN hören soll und auch darüber antworten. Aber ich finde einfach keinen Weg wie.
Vielleicht kann mir da jemand helfen?
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: 568408
Url: https://administrator.de/contentid/568408
Printed on: April 18, 2024 at 22:04 o'clock
11 Comments
Latest comment
Moin,
Du hast sicher schon getestet, ob die Kommunikation von dem einen VLAN in das andere funktioniert?
Gruß
Looser
Du hast sicher schon getestet, ob die Kommunikation von dem einen VLAN in das andere funktioniert?
Gruß
Looser
Hallo,
das VLAN soll komplett abgetrennt sein. Kommunikation ins oder aus dem Management VLAN wird nicht geroutet.
das VLAN soll komplett abgetrennt sein. Kommunikation ins oder aus dem Management VLAN wird nicht geroutet.
Und wie erreicht der PRTG Rechner die Switche?
Moin,
Du könnest auch mal Wireshark anwerfen und sehen was auf der Leitung passiert.
lg,
Slainte
Paessler SNMP Tester 5.2.3 Computername: xxxx Interface: (172.20.3.198, 172.20.2.35)
du stellst schon sicher, das der PRTG mit der korrekten IP zum Switch hin kommuniziert, oder?Du könnest auch mal Wireshark anwerfen und sehen was auf der Leitung passiert.
lg,
Slainte
Und wie erreicht der PRTG Rechner die Switche?
Er sagt ja das der Mgmt Server ein NIC Bein in diesem Management VLAN hat und damit dann IP Connectivity.Interessant wäre zu wissen:
- Kann der Management Server die Switch IP Adressen pingen ?
- Kann der Switch die Management Server IP pingen ?
- Ist der SNMP Community String für die RO und die RW Community noch gültig und auf Mgmt Server und Switch identisch gesetzt ?
Konfig Auszug der Switch SNMP Settings wäre auch hilfreich gewesen aber dazu hats ja leider nicht gereicht.
Moin,
wenn ich mich recht entsinne hat da HPE eine "interessante" Sicherheitslogik, wenn man ein management-VLAN angibt:
der Zugriff auf die IP des Switches ist dann nur noch aus dem selben VLAN möglich.
Sprich: Management-VLAN = 999, so muss euer PRTG-Server auch im VLAN 999 beheimatet sein.
HP-Aruba Management VLAN
€dit: Die Erkenntnis hast du ja bereits getestet, in dem du ein Laptop explizit in das selbige VLAN gehangen hast...
Dann siehe obiges nur als Erklärung an
Gruß
em-pie
wenn ich mich recht entsinne hat da HPE eine "interessante" Sicherheitslogik, wenn man ein management-VLAN angibt:
der Zugriff auf die IP des Switches ist dann nur noch aus dem selben VLAN möglich.
Sprich: Management-VLAN = 999, so muss euer PRTG-Server auch im VLAN 999 beheimatet sein.
HP-Aruba Management VLAN
€dit: Die Erkenntnis hast du ja bereits getestet, in dem du ein Laptop explizit in das selbige VLAN gehangen hast...
Dann siehe obiges nur als Erklärung an
Gruß
em-pie
eine "interessante" Sicherheitslogik, wenn man ein management-VLAN angibt: der Zugriff auf die IP des Switches ist dann nur noch aus dem selben VLAN möglich.
Das ist nicht nur bei den HP Billigswitches so. Das machen viele Hersteller auch im Premium Segment so.Im Default "hängt" aus Layer 2 Sicht das Management Bein in jedem VLAN des Switches. D.h. mit der richtigen IP Adresse kann man die Management IP des Switches aus jedem beliebigen VLAN erreichen was natürlich ein erhebliches Sicherheitsrisiko ist.
Das Konfig Kommando management-vlan xyz im Layer 2 Mode blockiert den Layer 2 Zugang auf die Switch Mgmt IP für alle anderen VLANs und gibt das nur für VLAN xyz frei.
Der Hinweis ist generell wichtig und richtig, sollte sich aber bei einem simplen Wechsel der Switch Management IP Adresse nicht ändern.
Obwohl...bei Billigheimer HP ist ja alles möglich...
wenn ich mich recht entsinne hat da HPE eine "interessante" Sicherheitslogik, wenn man ein management-VLAN angibt:
der Zugriff auf die IP des Switches ist dann nur noch aus dem selben VLAN möglich.
Ist bei Cisco und Alcatel nicht anders...der Zugriff auf die IP des Switches ist dann nur noch aus dem selben VLAN möglich.
Erstmal danke für die vielen Reaktionen 
Ich gebe zu im Bereich Netzwerktechnik bin nicht sooo der Experte. Aber ich sehe natürlich ein, dass public als Community doof ist. Ich bin realtiv neu in dem Unternehmen und versuche gerade 5 Jahre von Provisorien aufzuräumen^^
Ping geht vom PRTG-Server zu den Switchen und zurück. Auch die Switche untereinander können sich per Ping erreichen.
Der PRTG-Server selbst ist nicht auf dem aktuellsten Stand. Den werde ich erstmal Updaten. Aber dennoch hätte der SNMP-Tester ja funktionieren müssen wenn ich mich direkt an das Switch hänge.
Ich gebe zu im Bereich Netzwerktechnik bin nicht sooo der Experte. Aber ich sehe natürlich ein, dass public als Community doof ist. Ich bin realtiv neu in dem Unternehmen und versuche gerade 5 Jahre von Provisorien aufzuräumen^^
Ping geht vom PRTG-Server zu den Switchen und zurück. Auch die Switche untereinander können sich per Ping erreichen.
Der PRTG-Server selbst ist nicht auf dem aktuellsten Stand. Den werde ich erstmal Updaten. Aber dennoch hätte der SNMP-Tester ja funktionieren müssen wenn ich mich direkt an das Switch hänge.
Aber dennoch hätte der SNMP-Tester ja funktionieren müssen wenn ich mich direkt an das Switch hänge.
Aber nur wenn du den richtigen SNMP Community String zwischen Switch und Tester verwendest.Der Community String ist sowas wie ein Passwort. Stimmt der nicht ode rist keiner definiert gibts keine SNMP Daten. Du kannst das mit show logg auch immer im Switch Log selber sehen.
Das gibt sofort einen Security Log Eintrag wenn mit fehlendem oder falschem Community String auf den Switch zugegriffen wird. Leider hast du das wohl auch versäumt und es fehlte wieder der Konfig Auszug um das zu kontrollieren.
Infrastruktur kannst du sicher ausschliessen wenn Pingen fehlerfrei klappt.
Das der PRTG Server sofern der unter Winblows werkelt entsprechende Firewall Freigaben für UDP 161 und UDP 162 hat setzen wir jetzt mal voraus.
Holla,
Falls das Problem weiterhin besteht könntest Du folgenden Befehl probieren:
RH-ACC-2530-EG(config)# snmp-server response-source dst-ip-of-request
Hintergrund:
Source IP address for SNMP notifications
The switch uses an interface IP address as the source IP address in IP headers when sending SNMP notifications (traps and informs) or responses to SNMP requests.
For multi-netted interfaces, the source IP address is the IP address of the outbound interface of the SNMP reply, which may differ from the destination IP address in the IP header of the received request. For security reasons, it may be desirable to send an SNMP reply with the IP address of the destination interface (or a specified IP address) on which the corresponding SNMP request was received.
snmp-server response-source dst-ip-of-request (= Destination IP address of the SNMP request PDU that is used as the source IP address in an SNMP response PDU.)
Grüße...
Falls das Problem weiterhin besteht könntest Du folgenden Befehl probieren:
RH-ACC-2530-EG(config)# snmp-server response-source dst-ip-of-request
Hintergrund:
Source IP address for SNMP notifications
The switch uses an interface IP address as the source IP address in IP headers when sending SNMP notifications (traps and informs) or responses to SNMP requests.
For multi-netted interfaces, the source IP address is the IP address of the outbound interface of the SNMP reply, which may differ from the destination IP address in the IP header of the received request. For security reasons, it may be desirable to send an SNMP reply with the IP address of the destination interface (or a specified IP address) on which the corresponding SNMP request was received.
snmp-server response-source dst-ip-of-request (= Destination IP address of the SNMP request PDU that is used as the source IP address in an SNMP response PDU.)
Grüße...
