HP Procurve 3500 with K.14 – strange MAC search issue

hphp-procurvemac address

I have strange issue with HP ProCurve J8692A 3500yl-24G.
If I display MACs on port I see it:

3500(config)# sh mac 10 | inc 5cf3fc-a53456
5cf3fc-a53456

But if I try to find where is this MAC then I have no luck:

(config)# sh mac 5cf3fc-a53456
 Status and Counters - Address Table - 5cf3fc-a53456 
MAC address 5cf3fc-a53456 not found.

Any ideas where can be the problem?

Edited:
I test another MAC:

3500# sh mac 003048-33d8f6

 Status and Counters - Address Table - 003048-33d8f6

MAC address 003048-33d8f6 not found.
3500# sh mac | inc 003048-33d8f6
  003048-33d8f6 5
3500#

so this not looks as MAC, config mode or port issue.
Also:

MAC addr count#                1241       1257       1248       1449       1391
                     Low          *          *       1229       1222       1219
                    High          *          *       1266       1897       1897

and this switch have much larger (AFAIR 64k) MAC address table size, so it not looks like full MAC address table issue.

PS.
It run on bit old K.14.41 software. I check Release notes for K.14 series, but I don't see similar problem resolved in any next release.

Best Answer

You need to upgrade to the K.15 series. I also have a 3500yl-48G, and prior to K.15 I definitely saw bugs.

sh mac-a never worked properly for me in K.14, but does in K.15.

HP-3500yl-48G# sh mac-address 46           

 Status and Counters - Port Address Table - 46

  MAC Address   VLANs       
  ------------- ------------
  00005e-00010a 100         
  00005e-000201 100         
  00005e-000202 100         
  002283-f8dff0 100         
  f8c001-c56208 100         

HP-3500yl-48G# sh mac-address 46 |inc 00005e-00010a
 00005e-00010a 100         
HP-3500yl-48G# sh mac-address 00005e-00010a | inc 46
 46       100 

HP-3500yl-48G# sh version 
Image stamp:    /ws/swbuildm/rel_knoxville_qaoff/code/build/btm(swbuildm_rel_knoxville_qaoff_rel_knoxville)
                Feb 28 2013 11:40:02
                K.15.12.0006
                639
Boot Image:     Secondary

Related Solutions

SRX DHCP client compatibility with HP Procurve DHCP Relay

I opened a case with HP concerning this issue. After escalating past the useless Level 1 tech, the Level 2 tech very alertly spotted something that I had not.

The SRX is sending its DHCPDISCOVER packet with a TTL of 1. The Procurve's apparently will decrement the TTL and use the resulting TTL in the relay'ed packet to the DHCP server. In this case, the decrement leaves the TTL at 0 meaning the packet gets dropped on the floor.

This is actually in spec for DHCP/BOOTP relay, though clearly it causes reduced interoperability. I have asked HPNetworking to treat this as a bug/RFE and change the behavior. No immediate response to that request in the case.

The SRX sending the DHCPDISCOVER with a TTL of 1 is also probably within spec, but, again, a choice of reduced interoperability, so I plan to open a case with JTAC on the same basis.

I'll add more info on the response of Juniper and HP as it becomes available.

Incidentally, I have tested the relay behavior of a Cisco 4506 (firmware version not immediately available), and a Brocade/Foundry FastIron Edge X (7.2 or 7.3 firmware, I believe, don't have immediate access to confirm) and they both handle relaying the request with TTL 1 without issue.

UPDATE There is a way to change the TTL value that the SRX uses on its DHCP requests, but its not from within the JunOS cli...its done from the underlying Unix OS.

root@% sysctl -w net.inet.ip.mcast_ttl=64

I have opened an RFE with HP to make their relaying function more resilient, but not response from them yet on if/when that will be worked on.

ProCurve CPU at 100% for several minutes after reboot

This took less than 2 seconds on Google: HP networking portal

HP ProCurve 5400zl Switch Series - High CPU Utilization (99-100%) after Startup Issue

Right after the switch is started, high (99-100%) CPU utilization is observed. Solution

When the switch boots, one of the initialization tasks is creation of encryption keys. Having the keys created in advance means that later, when a feature such as SSL or SSH that uses the keys is configured or used, there is minimal delay in the availability. This task takes a few seconds before it ramps up, depending on the switch model, the configuration being loaded, and the software revision. Even though the task consumes up to 100% of the CPU, it runs at a very low priority. Therefore, if another task requiring CPU cycles is started, this low priority task will back off. If this initialization/key generation task runs uninterrupted by higher priority tasks, it takes about 10 minutes to complete. If the CPU is busy with other tasks, the completion time will be extended.

To verify that the elevated CPU being seen is in fact what has been described here and not something else that requires troubleshooting, please use the commands documented below.
task-monitor cpu (this command was introduced in K.13.04)

show uptime

show cpu
The output will look like the following.

Switch# task-monitor cpu Switch# show uptime 0000:00:01:42.36 Switch# show cpu
99 percent busy, from 27 sec ago
1 sec ave: 100 percent busy
5 sec ave: 100 percent busy
1 min ave: 66 percent busy

Task usage for last 5 sec
 % CPU | Description
-------+--------------------------
   0.3 | Sessions & I/O
  99.7 | System Services

Best Answer

Related Solutions

SRX DHCP client compatibility with HP Procurve DHCP Relay

ProCurve CPU at 100% for several minutes after reboot

Related Topic