Generated routes are very similar to aggregate routes, with one exception: generated routes inherit a real next-hop interface, while aggregate routes only allow discard or reject as next-hops.
For example, the following config:
lab@lab> show route protocol aggregate
inet.0: 57 destinations, 60 routes (57 active, 0 holddown, 0 hidden)
+ = Active Route, – = Last Active, * = Both
10.0.0.0/16 *[Aggregate/130] 00:00:04
> via so-0/0/0.0 <<<<<<REAL NEXT HOP (inherited from contributor)
192.168.16.0/21 *[Aggregate/130] 1d 08:33:02
Reject <<<<<<Reject is the default (can be configured to discard)
Note that they both show up in the routing table as protcol type Aggregate.
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
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:
change mac-lookup-length to a number (8 or 12) higher than default 4
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
Checking pending install on fpc1
Checking pending install on fpc0
Pushing bundle to fpc1
Validating on fpc1
Validating on fpc0
Done with validate of </var/tmp/mchassis-4500-install.tgz> on VC members
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/emailAddressfirstname.lastname@example.org
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