Are you using the management port? If so, did you also set up the management IP? It's under the last tab in the group configuration.
There would be 2 management IP addresses; one for eth2 and one will be the actual management IP (it's similar in design to the iSCSI setup; each port has an IP and then you have the 'overall IP').
For testing, first enable informational messages, then logout and log back into the group to see if the event was sent to the syslog server (once you confirm you can see the information messages, then set to your desired priorities)
The Syslog Protocol uses UDP Port 514 from the group IP address, so if you have switches or routers set to block these protocols, you may need to unblock them to allow management or I/O operations to work correctly.
Also you should test that you can trace route and ping the syslog server from each member in the group (not just the current group lead).
Telnet/SSH to each member and test the following:
GrpName>support traceroute
To traceroute out of a specific ETH port interface (like the management interface) add a switch to choose the interface IP as shown below:
GrpName>support traceroute -s [ETH port source IP] [destination IP to traceroute to]
The ping command is as follows:
GrpName>ping
or
Ping from the PS array using a specific ETH port interface (like the management interface)
No events are being sent to the syslog server, there isn't even an arp request for the IP address. The switches are not configured to block anything. The traceroute seems OK and ping works, except that I couldn't ping from the group management address ("cli-child: Can't set source interface/address: Can't assign requested address") which I assume is normal?
That would be correct; only one member in a multi-member group will have the group IP alias assigned to it (this is the group lead). When you login in to the group (via the GUI or CLI), if you review the event log, you will see the login event, it will also list the name of the member that accepted the login, that will be the member you can ping the group IP from (the sourceIP).
Regarding the syslog, if you have checked to ensure nothing is blocking the array from reaching the syslog server, than I think the next step is to open a support case so we can look at the array diags.
Prior to opening the case if you can run the diags from both members, that could help expedite the case.
No, there are no built in command line options to trigger an event. The log in/out events (security) are usually the safest to test with. There are others, like pulling a spare drive, disconnecting a power supply, control module failover that also trigger events, but on a production system, I wouldn't recommend it. You could also setup a dummy volume with the ACL to include CHAP, the try to connect to the volume without CHAP.
Not sure if you tried it yet, but did you temporarily setup the syslog server directly into the same vlan as the Arrays to see if it works on the same subnet?
As soon as I added ALL the MGMT IPs, not just the MGMT VIP, I started getting my messages... Seems to come from the group lead's IP and NOT the VIP. Plz better documentation on this.
Dev Mgr
4 Operator
•
9.3K Posts
0
September 25th, 2011 07:00
Are you using the management port? If so, did you also set up the management IP? It's under the last tab in the group configuration.
There would be 2 management IP addresses; one for eth2 and one will be the actual management IP (it's similar in design to the iSCSI setup; each port has an IP and then you have the 'overall IP').
harryjohnston
1 Rookie
•
25 Posts
0
September 25th, 2011 12:00
Yes, the management IP is configured. The web browser and SMTP notification are both working properly on the management network.
Joe S586
7 Technologist
•
729 Posts
0
September 26th, 2011 07:00
For testing, first enable informational messages, then logout and log back into the group to see if the event was sent to the syslog server (once you confirm you can see the information messages, then set to your desired priorities)
The Syslog Protocol uses UDP Port 514 from the group IP address, so if you have switches or routers set to block these protocols, you may need to unblock them to allow management or I/O operations to work correctly.
Also you should test that you can trace route and ping the syslog server from each member in the group (not just the current group lead).
Telnet/SSH to each member and test the following:
GrpName>support traceroute
To traceroute out of a specific ETH port interface (like the management interface) add a switch to choose the interface IP as shown below:
GrpName>support traceroute -s [ETH port source IP] [destination IP to traceroute to]
The ping command is as follows:
GrpName>ping
or
Ping from the PS array using a specific ETH port interface (like the management interface)
GrpName>ping "-I "
Note: the above is a Capital eye "I"
Regards,
Joe
harryjohnston
1 Rookie
•
25 Posts
0
September 26th, 2011 12:00
No events are being sent to the syslog server, there isn't even an arp request for the IP address. The switches are not configured to block anything. The traceroute seems OK and ping works, except that I couldn't ping from the group management address ("cli-child: Can't set source interface/address: Can't assign requested address") which I assume is normal?
harryjohnston
1 Rookie
•
25 Posts
0
September 26th, 2011 12:00
Addendum: pinging from the group management address works from one of the members but not the other.
harryjohnston
1 Rookie
•
25 Posts
0
September 26th, 2011 14:00
Is there a command that explicitly generates an event, as opposed to logging in and out?
Joe S586
7 Technologist
•
729 Posts
0
September 26th, 2011 14:00
That would be correct; only one member in a multi-member group will have the group IP alias assigned to it (this is the group lead). When you login in to the group (via the GUI or CLI), if you review the event log, you will see the login event, it will also list the name of the member that accepted the login, that will be the member you can ping the group IP from (the sourceIP).
Regarding the syslog, if you have checked to ensure nothing is blocking the array from reaching the syslog server, than I think the next step is to open a support case so we can look at the array diags.
Prior to opening the case if you can run the diags from both members, that could help expedite the case.
Regards,
Joe
Joe S586
7 Technologist
•
729 Posts
0
September 27th, 2011 06:00
No, there are no built in command line options to trigger an event. The log in/out events (security) are usually the safest to test with. There are others, like pulling a spare drive, disconnecting a power supply, control module failover that also trigger events, but on a production system, I wouldn't recommend it. You could also setup a dummy volume with the ACL to include CHAP, the try to connect to the volume without CHAP.
Not sure if you tried it yet, but did you temporarily setup the syslog server directly into the same vlan as the Arrays to see if it works on the same subnet?
Joe
harryjohnston
1 Rookie
•
25 Posts
0
September 27th, 2011 18:00
OK, login and logout look like the best bet.
I've tried specifying a syslog server in both the management VLAN and the iSCSI VLAN, neither worked.
devino
1 Message
0
January 2nd, 2014 09:00
As soon as I added ALL the MGMT IPs, not just the MGMT VIP, I started getting my messages... Seems to come from the group lead's IP and NOT the VIP. Plz better documentation on this.