Allied Telesis 54266-02 Switch User Manual


 
4 Features in 54266-02 Patch Release Note
Patch 54266-02
C613-10417-00 Rev B
When the router was the initiator in an ISAKMP Quick mode exchange with
a PC running Windows 2000 or Windows XP, the IPSEC communication
would not establish successfully. This was because the Windows PC set the
commit bit in the exchange, but sent the CONNECTED Notify payload in
the Quick mode exchange. However, the router was waiting for an
Informational Exchange containing a Notify payload (with the
CONNECTED Notify Message) as specified by RFC 2408. Because an
Informational message was expected, the device did not process the Quick
mode CONNECTED message, and so the exchange was never committed.
Although this behaviour is described as "not required by the IKE standard"
[http://www.microsoft.com/technet/community/columns/cableguy/
cg0602.mspx], the device will now process CONNECTED messages
received in Quick mode exchanges, to allow interoperability with other
vendors.
When BGP redistributed routes, locally imported routes were selected
rather than peer learnt routes. This issue has been resolved.
For OSPF-originated routes, it was possible for a route to be deleted from
the IP routing table, but still be referenced by OSPF. This could cause a
router reboot when later generating a summary LSA that contained the old
route. This occurred using the reset ip command. This issue has been
resolved.
When DHCP is enabled, it reclaims IP addresses at router startup to
determine if the addresses are in use or not. If, during this process, DHCP
was disabled then re-enabled, the router would not attempt to reclaim the
remaining IP address ranges. This would lead to the rejection of DHCP
requests for IP addresses that were still being reclaimed. This issue has been
resolved.
While initialising a range, the router acting as a DHCP server may release a
dynamic entry incorrectly. This issue has been resolved.
Multicast data could not flow from PIM to DVMRP on a PIM/DVMRP
border router. This issue has been resolved.
When both Load Balancer and Firewall were configured, the very first TCP
session was established after rebooting. Subsequent TCP session startup
packets may have been routed out to an incorrect interface causing sessions
to not be established. This issue has been resolved.
PCR: 40466 Module: ISAKMP Level: 2
PCR: 40470 Module: BGP Level: 2
PCR: 40479 Module: OSPF Level: 2
PCR: 40496 Module: DHCP Level: 2
PCR: 40516 Module: DHCP Level: 2
PCR: 40520 Module: DVMRP Level: 2
PCR: 40530 Module: IPG Level: 2