Comware

We have a Procurve 5300XL switch. While in the test bench the syslog logging was working fine. Now that I configured the switch as our production device, it is not logging anymore. Are there some kind of VLAN limitations or something?

Some settings:
sw E.07.22
logging 192.168.135.91 (that is in VLAN 235)
Primary VLAN: 1
Management VLAN: (none)

onni# sh debug

Debug Logging

Destination:
Logging --
192.168.135.91

Enabled debug types:
event
acl log

onni# ping 192.168.135.91
192.168.135.91 is alive, time = 1 ms

Syslog daemon is running and working with other devices.

Did you check that your VLAN 235 was reachable from this swicth ? Is the server IP tagged to the default VLAN ?
J

The syslog server is reachable from the switch, as the ping output shows, and the syslog server as well as other hosts in the same subnet (and VLAN) can fully communicate with other hosts. Routing is working properly.

The syslog server is not directly connected to the 5300XL, there is a switch in between, and the VLAN 235 is untagged between the 5300XL and the syslog server.

Servers from any VLAN (routed by the 5300XL) can log to the syslog server.

I find this very strange because syslogging was working in the testing phase.

Mmmm... strange indeed.
In some swicthes (don't know if 500XL is concerned), management VLAN must be left on VLAN 1 for any distant administration related process to occur. Check that.
Besides, don't you have in between access lists set somewhere, refusing port 514 UDP ? This could also be an issue.
Last, try reseting and re-setting your config. Sounds like a m$ trick, but works often.
hth
J

Currently the VLAN 1 is not in use, meaning that there are no devices connected to VLAN 1 ports. I did the following:

- defined an IP address for VLAN 1 (192.168.99.1/24)
- attached a syslog server (192.168.99.2) to a VLAN 1 member port
- logging 192.168.99.2 (leaving the old 192.168.135.91 still there)

Surprise: logging worked fine on that new syslog server.

But, additionally, there were logging also on the old server! Source IP was shown to be 192.168.99.1, address of VLAN 1 router interface.

Then I disconnected the new server, removed the logging 192.168.99.2 statement, and removed the IP address of VLAN 1.

Result: The old syslog server is receiving *some* of the messages, and the source IP is still 192.168.99.1, which is not in the 5300XL running-config anymore!

So, the next thing I will do is changing the primary vlan to 235. Let's see.

That seem to confirm this management VLAN... I saw also in an old HP switch stuff the necessity to have one management VLAN, even if it's not N??1.
It seems to be confirmed here...
Glad to see it's working. Let us know the end of the story !
J

Changing the primary VLAN did not change syslogging.

I think everything is not correct in this software (newest image).

1. Why syslogging was enabled to a server in VLAN 235 when VLAN 1 was connected another syslog server? (btw there were some messages dated Jan 1 even though the switch has been running with correct date and time several days)

2. Why did only some of the messages arrive to the original syslog server when the new server was removed? (the same server gets all other messages from other sources)

3. Why the source address was 192.168.99.1 which was not in use in any configuration?

Management VLAN has not been set in any case.

Primary VLAN setting did not affect the situation.

Is anyone willing to share some facts about syslogging and 5300XL? The configuration manual does not say anything about syslog limitations (except that max 6 servers can be set).

Markku,
You are right in saying that it's a strange issue. But VLAN 1 must exist if you define other vlans... So does its connecting IP. That is why you get this source address. If you have a VLAN compatible network, then there must be a switch acting as a server, which identifies the source even after you unset it... up to the time you set another IP to this port.
The partial messages remain strange.
A dump somewhere will show you why. My theory is that something has an ARP resolution able configuration, and route part of your messages properly, but I do not know your network and do not figure out which item play this role.
J

Now I have verified the behaviour.

If there is no IP address in VLAN 1, the syslogging won't fully work.

When I enter an IP address in VLAN 1, the syslogging works (in VLAN 235). Note that the VLAN 1 does not need to be up or have to have any active ports. Just having the IP address configured enables the logging.

As the VLAN 1 does not have any active ports in my configuration, that VLAN does not even appear in the routing table. This is correct by definition.

Once the logging is working, removing the IP address from VLAN 1 disables the syslogging after 2 messages.

When entering the VLAN 1 IP address, the switch sends some (10-20 maybe) *old* messages to the syslog server, and starts logging of new messages. Today, for example, when I entered the IP address, the switch sent syslog messages from last Friday to the server.

I was wrong when I said that the source address was the old IP address of the VLAN 1. This is not true. The source address is the address of the VLAN interface where the syslog server is located (this is how it should be). I was mislead by the fact the the 5300XL switch includes the IP address of VLAN 1 in the syslog message, for some reason (and the switch logs two messages even after removing the IP address from VLAN 1).

So, to conclude:
- 5300XL and E.07.22
- VLAN 1 has to have an IP address for syslogging to work
- No active ports in VLAN 1 are needed
- Management VLAN is not needed
- Primary VLAN setting does not affect
- Logging server can be in any VLAN
- This feature is not listed in the Management and Configuration Guide (for E.07.2x). Please correct me if this can be implied from some chapter.

I reported this on HP support and they are to contact me after testing it theirselves.

I will post the final responses here also.

Today I got the confirmation from a HP guy that this is a bug.

It won't be fixed in the soon-coming E.07.27, as the bug has just been logged.

Until that, keeping an IP address in VLAN 1 (even if there aren't any hosts) will keep syslog working.

Thank you for your interest.

Thanks for posting your conclusions.
Do you have cisco switches also ? As far as I remember from my CCNA courses, the issue is teh same, and not considered as a bug. But I do not have swicthes here to test it myself.
RGDS
J

It is natural that any IP related functions (like sending syslog messages with UDP/IP) fail if the switch does not have any IP address configured for the correct VLAN. It should not be related to any specific VLAN number.

I guess that's the fact that you are referring to.

In Layer 2 switches, there is only one IP address to be configured, and it is assigned to a certain VLAN that is used for the management. That VLAN is not necessarily #1. (Okay in certain switches it actually is forced to be #1 but I'm trying to avoid those devices.)

Choosing the correct VLAN for the management (in L2 switches) is important because the switch is not able to route any traffic.

In Layer 3 switches (like 5300XL), the IP addresses of the switch are not primarily used for management, but as the next-hop addresses in IP routing. If the L3 switch itself is generating and sending some IP packets (like the syslog messages), it uses the IP address of the destination VLAN interface as the source address. (If the packet exits the switch through VLAN 235, the source address is the configured IP address of VLAN 235.)

A Layer 3 switch should basically be able to reach any host in the network (and be reachable from any host in the network as well): if it does not have a direct connectivity with the target subnet, it should at least know who knows the way there (next-hop router).

Long explanation, and probably most redundant:-)

Tx fr your precisions :-)
I'm still a little boy ;-((
J

It is quite interesting to see that in the latest E.07.37 firmware there is still no mention in the Release Notes about this bug. Probably it has not been fixed, even though HP support verified the issue in May.