26
SHOW IGMPSNOOPING ROUTERADDRESS
Patch Release Note
Patch 86253-07 for Software Release 2.5.3
C613-10382-00 REV E
When adding a port to a VLAN, any STP ports that had been disabled in the
default STP were re-enabled. This issue has been resolved.
When the DELETE DHCP RANGE command was executed, DHCP
attempted to reclaim the addresses in that range. It also tried to reclaim
addresses in that range that were not allocated at that time, resulting in
duplicate addresses appearing on the free list for allocation. This has been
resolved by allowing DHCP to reclaim only those addresses that are
currently in use by one of its clients.
When changing from RSTP to STP mode, the STPCOMPATIBLE option for
the RSTPTYPE parameter incorrectly appeared in the dynamic
configuration. Also, when changing from RSTP to STP mode or vice versa,
disabled STP ports did not remain in the disabled state. These issues have
been resolved.
If a port went down, the port was deleted from the appropriate static IGMP
associations but was not added back again when it came back up. Similarly,
static IGMP associations were automatically deleted but not added back
when IP or IGMP was disabled. These issues have been resolved. You can
now create IGMP associations before enabling IGMP, and they will become
active when IGMP is enabled.
The maximum number of firewall sessions had decreased since software
release 86s-241. This issue has been resolved.
Previously, an incorrect source address was used for router advertisements
that were sent over an IPv6 tunnel. The source address of the tunnel
(specified by the IPADDRESS parameter of the ADD IPV6 TUNNEL
command) was used instead of a link local address. This caused an
interoperability problem, which has been resolved. Now, if the specified IP
address is not a link local address, then a link local address will be created
based on the IPv4 tunnel source address and used for router
advertisements.
If a ping was active and the IP configuration was reset, subsequent pings
were sent out the wrong interface. This issue has been resolved.
Executing a ping to the IP address 0.0.0.0 did not return an
invalid
destination address
error message. Also, when the TRACE command
was executed for local addresses, it timed out after 90 seconds. These issues
have been resolved.
PCR: 03707
Module: STP
Level: 2
PCR: 03708
Module: DHCP
Level: 2
PCR: 03720
Module: STP
Level: 2
PCR: 03738
Module: IPG
Level: 2
PCR: 03741
Module: FIREWALL
Level: 3
PCR: 03742
Module: IPV6
Level: 2
PCR: 03743
Module: IP
Level: 3
PCR: 03744
Module: PING
Level: 3
