MAC address learning problem in Juniper EX switch

Juniper EX switche has one port configured as trunked ports, when there are two many mac address learned from that port,
some of mac address may failed to be learned by the port. This is due to hash index collision that can be fixed by changing the value
of mac-lookup-length

In case you are encoutering the problem that
1, eth port of the host failed to work, and that host is connecting to a switch trunk port via hub/vmware platform,
2, switch port is showing up/up
3, switch port has learned massive mac address from that port, and a lot of learned mac addresses from different vlans are exactly identical

You should consider this may be hash index collision problem that has been reported by Juniper as PR842439. ”

For EX3200, EX4200, EX4500, EX4550, EX6200 and EX8200 Series switches, hash index collisions were causing problems with the learning of MAC addresses in the forwarding database (FDB). You can now increase the maximum number of searchable hash indexes in increments of 4, from 4 to a maximum of 32 entries, using the CLI command "set ethernet-switching-options mac-lookup-length".

By checking it, you may use command
> show system statistics bridge | match “learning failures”
the real problems occur in a repeated Learn log followed immediately by a Deleted log in the mac-learning log:
> show ethernet-switching mac-learning-log

Solution is indicated as the link below:
https://www.juniper.net/documentation/en_US/junos/topics/reference/configuration-statement/mac-lookup-length-edit-ethernet-switching-options.html

To summarize:
change mac-lookup-length to a number (8 or 12) higher than default 4

Juniper ex4550 upgrading

Normal upgrading of Juniper switches could follow the following steps:
request system software add http://path/image
request system reboot

I have encountered the following error twice when tried to upgrading software for those newly installed switches:
Ex4550> request system software add http://path/image
Ex4550> …00-15.1R4.6-domestic-signed.tgz
Checking pending install on fpc1
Checking pending install on fpc0
Fetching package…
Pushing bundle to fpc1
Validating on fpc1
Validating on fpc0
Done with validate of </var/tmp/mchassis-4500-install.tgz> on VC members

fpc1:
Verify the signature of the new package
verify-sig: cannot validate certs.pem
certificate is not yet valid: /C=US/ST=CA/L=Sunnyvale/O=Juniper Networks/OU=Juniper CA/CN=PackageProductionRSA_2016/emailAddress=ca@juniper.net

ERROR: Package signature validation failed. Aborting install.

The problem is that the date of the switch is set to a date earlier than the date on which the jloader was built, therefore the certificate for the file is not yet valid. The solution is to either synchronize the date on the switch to a NTP server or to manually set the date.

After configured NTP server, the software image was verified successfully, can upgrading done as always should be.

This problem and solution can be found from the following link
https://kb.juniper.net/InfoCenter/index?page=content&id=KB21424&actp=search