Hello to all of you experts.

I'm sorry if this is a dumb question (I usually don't ask those, but I'm human), but I haven't a clue of what's wrong in this environment.

I wish to permit all my VLANs to just comunicate with VLAN 1 and the internet.

All internal traffic is inside range like:
. VLAN 1: (ip addr
. VLAN 2: (ip addr
. VLAN 3: (ip addr

This is the only routing-activated layer3 switch on campus 
and is the default gateway for everybody

So, I created the "acl_default" and applied it at the inbound of every VLAN (except VLAN 1, obviously)

ip access-list extended "acl_default"
   10 permit ip
   900 deny ip 
   950 permit ip 

It works...but, every morning, all the users in the VLANs (not VLAN 1) cannot communicate with some servers on VLAN 1.

If I traceroute to a server from VLAN 120 (, I see a loop:

traceroute to ,
          1 hop min, 30 hops max, 5 sec. timeout, 3 probes
 1        1 ms      1 ms      1 ms
 2        0 ms      1 ms *
 3        1 ms      1 ms      1 ms
 4        1 ms      1 ms *
 5        1 ms      1 ms      1 ms
 6        1 ms      1 ms *
 7        1 ms      1 ms      1 ms
 8        1 ms      1 ms *
 9        0 ms      2 ms      0 ms
10        1 ms      1 ms *
11        1 ms      1 ms      1 ms

But...If I go to server_69 and ping back the 120_gateway, everything starts to work!!

That's why only certain servers can't be reached in the morning: The ones that don't communicate very often with the other-than-vlan1 subnets.

Chassis info: HP Procurve 5400Rzl2 Software: KB.15.17.0003

What am I missing?

Thank you all in advance (even if just for reading this long post)



I'm not sure that's a loop. I'm not really sure what that is. The ACL looks fine so you probably want to talk to HP about this.

I had a case similar to this where a procurve based L3 switch would not manage its arp table properly. I think it was on the same software branch as you too. Called HP and 5 minutes later it was confirmed as a known issue and due to be fixed in next release.

If you check the release notes for the next firmware version does it mention anything about ARP being fixed? Or is it listed as a known issue in the current firmware release notes (firmware release you're running now). The next morning it happens, try clearing the arp table/cache with clear arp. Try to ping from vlan 120 to a server again and see if it works.

I think the firmware versions are free from HP (at least on the lower end models). We were looking at the 5400 to use at the core and ended up going with a Comware based HP switch instead and its been solid. Procurve is great (we have customers using a lot of them at the access layer) but I've seen odd issues like this crop up, especially on the newer firmware versions.

  • It's a bug corrected 5 software versions later, on KB.15.17.0008 (see link. Search for CR_0000176140 ). The switch wasn't requesting ARP to the next hop. After expiring, the entry was never recreated until the servers on VLAN 1 contacted the gateway themselves. Thank you, @Mark for analyzing the problem and letting me know that I wasn't doing anything wrong. – user3095809 Sep 2 '16 at 11:03

Got it!

It's a software bug on releases prior to KB.15.17.0008.

From the Release Notes:

CR_0000174881, CR_0000176140 The switch does not initiate an ARP request to the next hop IPv4 address for routed IPv4 traffic entering a VLAN that has a Routed Access List (RACL) (....)

As a result, the IPv4 routed traffic does not reach its destination because the switch does not create an ARP entry in the switch ARP Table for the next hop IPv4 address, (....)

The issue may be intermittent because there could be other sources trying to reach the same next hop IPv4 address which will result in creating an ARP entry. Due to the ARP age-out time of 20 minutes, the issue may reoccur after 20 minutes.

And they give an example just like mine:

For example, if the routed IPv4 traffic also enters the switch via a VLAN that does not have RACL or if you ping it from the affected switch. Pinging from the switch to the unreachable IPv4 destination address temporarily resolves the reachability issue; however, it may reoccur after the APR age-out expire or after invoking the CLI command clear arp.

Dispite I could have started by checking the software releases before posting this question, I wasn't sure that it wasn't some mistake of mine on the ACL implementation. It's always Something could have slipped-by unnoticed. Like it did to everyone using it for 5 software releases.

I leave it here in case someone else runs into this.

Thank you to @Mark for letting me know that I was doing the things right. His 2nd opinion led me to the next step: look for software releases. If I didn't find anything on it, I would open a case on HP (HPE division).

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.