14 | SHOW IGMPSNOOPING ROUTERADDRESS | Patch Release Note |
•The Proposal flag is not set in a BPDU sent by a designated port once the port has reached the forwarding state.
PCR: 31159 Module: FW, VLAN | Level: 2 |
Static ARP entries sometimes prevented the firewall from working correctly. This is because when an VLAN interface is added to the firewall, the CPU takes over the routing from the switch silicon in order to inspect the packet. Hence all the Layer 3 route entries must be deleted. However, static ARP Layer 3 entries were not being deleted from the silicon. This issue has been resolved. When interface is added to the firewall, all hardware layer 3 routing is now turned off to allow the firewall to inspect packets.
PCR: 31162 | Module: SWI | Level: 2 |
A STP topology change incorrectly deleted static ARP entries. This issue has been resolved.
PCR: 31167 | Module: IPG | Level: 2 |
IP MVR member ports were not timing out. MVR member ports now timeout in the same way as IP IGMP ports. The timeout values are configured by IGMP. Also, IGMP interfaces were incorrectly being enabled and disabled by MVR. This issue has been resolved.
PCR: 31174 | Module: IPG | Level: 2 |
If a device had IPSec and firewall enabled, it could not handle long ICMP packets even when enhanced fragment handling was enabled on the firewall. If a long packet is passed to the firewall for processing, the firewall chains the fragmented packets. The firewall can process chained packets, but IPSec could not process these packets, and dropped them. This was only an issue for packets between 1723 and 1799 bytes long. This issue has been resolved. The way IP processes fragmented packets has been changed so that IPsec no longer drops chained packets.
PCR: 31177 | Module: SWI | Level: 2 |
On a Rapier 48, after an IP interface was added to a protected VLAN, the switch's MAC address was registered as static in the switch forwarding database, and had an incorrect port number. This information was shown in the output of the SHOW SWITCH FDB command. This issue has been resolved.
PCR: 31180 | Module: USER | Level: 2 |
The following commands did not require security officer privilege when the device was in security mode, but this privilege should have been required:
•ADD USER
•SET USER
•DELETE USER
•PURGE USER
•ENABLE USER
•DISABLE USER
•RESET USER
This issue has been resolved. Security officer privilege is now required for these commands when security mode is enabled with the ENABLE SYSTEM SECURITY_MODE command.
Patch
