|
|
|
|
|
|
|
| Features in |
|
|
| 18 | ||||
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
CR | Module | Level | Description | AR400 | AR7x5 | AR7x0S | Rapier i |
| Rapier w | AT8800- |
| x90048- | ||||
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
CR00017368 | QoS, | 2 | Some small memory access violations existed in DHCP snooping. | - | - | - | Y |
| Y | Y | Y |
| Y | Y | Y | - |
| DHCP |
| These violations have been resolved. |
|
|
|
|
|
|
|
|
|
|
|
|
|
| Snooping |
| Also, a new console error message is displayed if a user tries to add a |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
|
|
| duplicate classifier to a QoS policy. For example, if traffic class 101 belongs |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| to policy 2 and a user tries to add a flow group to traffic class 101 when |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| the flow group’s classifier is number 54 and already belongs to policy 2, the |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| following message is displayed: |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Error (3099297): Duplicate classifier (54) on policy 2. |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| A similar new log message has also been added, which says: |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Duplicate classifier (<number>) found on <string> <number> |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Note that a classifier can exist in two separate policies but cannot exist |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| twice in the same policy. |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
CR00017456 | IP Gateway | 2 | The router or switch could reboot when the local interface address had | Y | Y | Y | Y |
| Y | Y | Y |
| Y | Y | Y | Y |
|
|
| been specified by using the set ip local command, and then the underlying |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| interface from which the local interface took its address was either deleted |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| or had its address changed. In both these cases, the local interface was |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| correctly reset back to an undefined address, but a route to this address was |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| not deleted. This could cause routing difficulties and a reboot when packets |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| for that address were received. |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| This issue has been resolved. The route is now correctly deleted. |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
CR00017488 | Firewall | 2 | When a VoIP call using SIP was initiated from the public side of the firewall, | Y | Y | Y | Y |
| Y | Y | - |
| - | - | - | Y |
|
|
| occasionally the firewall created two UDP sessions for the call with different |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| UDP source ports. This happened if the first packets of the STP (voice data) |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| stream arrived earlier than the 200 OK message that was supposed to |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| establish the session. The result was that the public side caller could not |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| hear the call. |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| This issue has been resolved. |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Version