| |
|
Alert Type: | Updated * |
Bug Id: | CSCuz16842 | Title: | PN - VNE auto recovery following loss of telnet is not working |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
VNE cannot restore Telnet/SSH connectivity to device after it was temporarily lost.
Conditions:
Temporary loss of Telnet connectivity to device
Workaround:
Manually restart VNE
Further Problem Description:
|
|
Last Modified: | 25-APR-2016 |
|
Known Affected Releases: | 4.2(2.0)PP6 |
|
Known Fixed Releases: * | 4.2(2.0)PP6 |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCus04397 | Title: | Default polling mode changes in registry,not getting updated in VNE |
|
Status: | Open |
|
Severity: | 3 Moderate |
Description: | Symptom:
1) Changed the default polling mode in registry controller to 0 instead of 1 and applied it .
2) Checked in site.xml , default polling mode has been changed .
3) When adding a new VNE , default polling mode is still in 1 (Used reduced polling mode if possible )
4) Existing VNE 7606 is in regular polling (2 ) -- restarted it and then restarted the PN .
5) Logged into the PN admin , still VNE 7606 is in regular polling (2) , instead of default polling mode 0 (which was always use reduced polling )
6) when adding new VNE also , the default polling mode should be the same set in the registry .
Conditions:
1) Install 4.0.0.2.0
2) Model a 7606 VNE with the pollig mode as regualar polling .
3) Go to Tools --> Registry controller --> change the default polling mode as 0 .
4) Resart the VNE and and restart the PN
5) Login to PN admin and check the VNE Pollig status
Workaround:
Further Problem Description:
|
|
Last Modified: | 11-APR-2016 |
|
Known Affected Releases: * | 4.0(0.2)PP0, 4.1(0)PP4, 4.2(3.0)PP1 |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuo58371 | Title: | PN: MPLS-TP "LSP down" even not corr card down/out - link down |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: * | MPLS-TP peer device "LSP down" ticket not correlate to ASR9K card down
Symptom:
MPLS-TP "LSP down" ticket not correlate to ASR9K card down.
After card down ASR9K MOD80 card, card down ticket appear, but "LSP down" event not correlate to "Card down" ticket.
"LSP down" event root cause time is 11 seconds before "Card down" ticket.
Conditions:
1. Model MPLS TP lab
2. Shutdown MOD80 card
hw-module shutdown location 0/1/CPU0
Workaround:
Further Problem Description:
|
|
Last Modified: | 19-APR-2016 |
|
Known Affected Releases: | 3.11(0)PP3, 4.0(0.1)PP3, 4.1(0)PP1 |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCut23090 | Title: | ArrayIndexOutOfBoundsException flood AVM 11 log |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: * | Symptom:
ArrayIndexOutOfBoundsException flood AVM 11 log.
Example:
ERROR [03 05 2015 16:46:53.541 IST] - NotificationProcessor.handleNotification - Handler: com.sheer.metromission.plugin.alarm.TicketTreeNotificationHandler@1fa233c got an exception when handling oid: {[NewAlarm(Id=90)]}
java.lang.ArrayIndexOutOfBoundsException: 1
at com.sheer.metromission.plugin.alarm.NotificationHandler.handleNotifications(NotificationHandler.java:45)
at com.sheer.metromission.plugin.alarm.NotificationProcessor.handleNotification(NotificationProcessor.java:68)
at com.sheer.metromission.plugin.alarm.NotificationProcessor.processNotifications(NotificationProcessor.java:99)
at com.sheer.metromission.plugin.alarm.NotificationAgent.processWakeUpMessage(NotificationAgent.java:230)
at com.sheer.metromission.plugin.alarm.NotificationAgent.processMessage(NotificationAgent.java:208)
at com.sheer.system.agentshell.AgentBase.run(AgentBase.java:306)
at com.sheer.system.os.services.scheduler.OSAgent.run(OSAgent.java:168)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:724)
Conditions:
1. Model ASR9K
2. Get a ticket
for example ticket for authentication error, the device will send the following syslog
<36>6595: RP/0/RSP0/CPU0:Mar 5 01:16:40.908 : exec[65930]: %SECURITY-login-4-AUTHEN_FAILED : Failed authentication attempt by user 'xxxx' from 'x.x.x.x' on 'vty2'
Workaround:
NA
Further Problem Description:
|
|
Last Modified: | 20-APR-2016 |
|
Known Affected Releases: | 4.1(0.1)PP0, 4.2(2.0)PP2 |
|
Known Fixed Releases: | 4.2(0.1)PP5, 4.2(2.0)PP2, 4.2(3.0)PP1 |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuv40300 | Title: | Port down/Link down ticket is not cleaned after Nexus7K reload |
|
Status: | Open |
|
Severity: | 3 Moderate |
Description: | Symptom:
Port down ticket is not cleaned after Nexus7K reload.
In Invtenory the port status is "OK" but the ticket stay down.
This is not GUI update issue because the ticket stay the same after map close/open
Conditions:
1. Model Nexus7K
2. reload device
Workaround:
Further Problem Description:
|
|
Last Modified: | 20-APR-2016 |
|
Known Affected Releases: * | 4.1(0.1)PP1, 4.2(2.0)PP6 |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCus36751 | Title: | NEXUS7K card content disappear after card down |
|
Status: | Open |
|
Severity: | 3 Moderate |
Description: | Symptom:
NEXUS7K content disappear after card down
Conditions:
1. Model Nexus7K
2. Card down Nexus7K ((config)# poweroff module 1)
Workaround:
Further Problem Description:
|
|
Last Modified: | 22-APR-2016 |
|
Known Affected Releases: * | 4.1(0X)DP1411.0.502, 4.2(0X)DP1503.0.581, 4.2(0X)DP1509.0.702, 4.2(1)DP1505.0.622, 4.2(2)DP1603.0.822 |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuw81643 | Title: | Registration "vc counters" is loaded multiple times for ATM DC |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
AVM high CPU when ATM port in physical inventory contains many VC encapsulations and the "VC Encapsulation" icon is clicked on.
Conditions:
ATM port in physical inventory contains many VC encapsulations and the "VC Encapsulation" icon is clicked on.
Workaround:
N.A.
Further Problem Description:
|
|
Last Modified: | 03-APR-2016 |
|
Known Affected Releases: | 4.1(0.1)PP2 |
|
Known Fixed Releases: * | 4.1(0.1)PP3, 4.2(0.1)PP5, 4.2(2.0)PP3, 4.2(3.0)PP1 |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuw34406 | Title: | PN - NetworkVlanDiscoveryPlugin - Placeholder OID not found exception |
|
Status: | Open |
|
Severity: | 3 Moderate |
Description: | Symptom:
Network VLAN Discovery Logs are rolling over with constant notifications when Nexus7k device is modeled from lab. Also these notifcication excetions are being written to 35.out log as well causing them to fill up as well.
Notification is coming from the following: java.lang.IllegalArgumentException: Placeholder OID not found
Conditions:
None
Workaround:
None
Further Problem Description:
|
|
Last Modified: | 06-APR-2016 |
|
Known Affected Releases: * | 4.2(0.1)PP5, 4.2(1), 4.2(2), 4.2(2.0)PP2, 4.2(2.0)PP6, 4.2(3) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | New |
Bug Id: | CSCuz43632 | Title: | cardOut starPortDown/starPortUp traps go to standard instead of v2 trap |
|
Status: | Open |
|
Severity: | 3 Moderate |
Description: | Symptom:
starPortDown/starPortUp traps are going to standard tab.
Conditions:
For an ASR 5500 device when the card is out.
Workaround:
Further Problem Description:
|
|
Last Modified: | 29-APR-2016 |
|
Known Affected Releases: | 4.2 |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCut10068 | Title: | Unable to model device to SNMPv3 with AES256 or AES192. |
|
Status: | Terminated |
|
Severity: | 3 Moderate |
Description: | Symptom:
Unable to model device to SNMPv3 with AES256 or AES192.
Conditions:
1. Model ASR9K with SNMPv3 with AES256 or AES 192.
Workaround:
We have several workarounds:
Option 1: Only need to model few VNE with SNMPv3, then this option is good and set per VNE.
======
Step 1:
runRegTool.sh -gs 127.0.0.1 get 127.0.0.1 avm<#>/agents/da//ips//contexts/generic
The above command returns XML format where you don't see "snmpv3_keycalcclassname" key and value.
Step 2:
To set the new value to "snmpv3_keycalcclassname":
runRegTool.sh -gs 127.0.0.1 set 127.0.0.1 avm<#>/agents/da//ips//contexts/generic/snmpv3_keycalcclassname com.sheer.net.protocols.snmp.CiscoSecurityKeyCalculator
Step 3:
Repeat the Step 1 and check the the key "snmpv3_keycalcclassname" is added.
Step 4:
Restart the VNE.
Set the following property in device level:
Option 2: If the user wants to model all the VNEs with SNMPv3, then set in site level.
======
In option 1, replace step 2 with following procedure.
runRegTool.sh -gs 127.0.0.1 set 0.0.0.0 site/agentdefaults/da/ip_default/contexts/generic/snmpv3_keycalcclassname com.sheer.net.protocols.snmp.CiscoSecurityKeyCalculator
Option 3:
======
1. Model VNE with SNMPv2 and after that move to SNMPv3 with AES256/192.
Further Problem Description:
|
|
Last Modified: | 27-APR-2016 |
|
Known Affected Releases: * | 4.2(0.1)PP1, 4.2(1), 4.2(2), 4.2(2.0)PP6 |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | New |
Bug Id: | CSCuz30001 | Title: | P-PN: Nexsus 7700 port status doesn't model after card down/up |
|
Status: | Other |
|
Severity: | 3 Moderate |
Description: | Symptom:
interfaces status don't model after card down/up
Conditions:
perform card down/up and interfaces status stay as gray.
Workaround:
restart vne and make poll now in order to model port status
Further Problem Description:
|
|
Last Modified: | 27-APR-2016 |
|
Known Affected Releases: | 4.2(2)DP1603.0.822 |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuy32792 | Title: | KeepAlive link protocol erroneously removes physical link from topology |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
In PN4.2.2 the physical links get periodically removed from topology and then rediscovered back.
Conditions:
Not specific
Workaround:
There is no workaround for this issue.
Further Problem Description:
|
|
Last Modified: | 25-APR-2016 |
|
Known Affected Releases: | 4.2(2.0)PP4, 4.2(3) |
|
Known Fixed Releases: * | 4.2(2.0)PP6 |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCux92634 | Title: | Tech Changes for 'DNS PGW Context' attribute in MRME service. |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: |
Symptom:
Tech Changes for 'DNS PGW Context' attribute in MRME service. (MRME attribute - 'DNS PGW Context' should come as a Hyperlink in PN)
Conditions:
Confiugure DnsPgwContext attribute in MRME service as XID.
Workaround:
There is no workaround for this issue.
Further Problem Description:
(release notes added by addprefcs-org.ksh)
|
|
Last Modified: | 25-APR-2016 |
|
Known Affected Releases: | 4.2(3), 4.2(3.791) |
|
Known Fixed Releases: * | 4.2(2.0)PP6, 4.2(3) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuy39072 | Title: | SNMP track reachability does not reset retry counter when device reload |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
SNMP track reachability command does not reset retry counter when device is reloaded. As a result the VNE creates Device Unreachable alarm prematurely.
Conditions:
Number of retries for SNMP track reachability command is changed to more than 1
Workaround:
There is no workaround for this issue.
Further Problem Description:
|
|
Last Modified: | 25-APR-2016 |
|
Known Affected Releases: | 4.2(2.0)PP4, 4.2(3) |
|
Known Fixed Releases: * | 4.2(2.0)PP6 |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuu89131 | Title: | Missing OSPF v2 interfaces in NV if configured with IPV6 addr also. |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
If OSPF interfaces with same Process ID but are configured with both IPV4 and IPV6 addresses, then the interfaces will not show up in OSPF Processes V2 logical inventory, but the same interfaces will show up in OSPF Processes V3 logical inventory.
Conditions:
OSPF interfaces with same Process ID but are configured with both IPV4 and IPV6 addresses
Workaround:
N.A.
Further Problem Description:
|
|
Last Modified: | 25-APR-2016 |
|
Known Affected Releases: | 4.2(0.1)PP3 |
|
Known Fixed Releases: * | 4.1(0.1)PP2, 4.2(0.1)PP3, 4.2(2.0)PP6 |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCup02906 | Title: | adding parsing command for delay all registrations |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: |
Symptom:
Need to add a parsing command to have the ability for delaying all registrations when receiving relevant syslog/trap (for example warm start trap).
Conditions:
Workaround:
none
Further Problem Description:
(release notes added by addprefcs-org.ksh)
|
|
Last Modified: | 25-APR-2016 |
|
Known Affected Releases: | 4.0(0.1)PP0 |
|
Known Fixed Releases: * | 4.0(0.1)PP5, 4.1(0.1)PP1, 4.2(0.1)PP1, 4.2(2.0)PP6, 4.2(3.0)PP1 |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuv06547 | Title: | Nexus7K do not show OSPF v2 neighborswhen OSPF v2 and v3 has the same id |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
Nexus7K do not show OSPF v2 neighbors when OSPF v2 and v3 has the same process id
Conditions:
1. Model Nexus7K that has OSPF v2 and v3 with the same process id
2. Open Nexus7K inventory
2. Go to OSPF v3 and see if it has neighbors
Workaround:
NA
Further Problem Description:
|
|
Last Modified: | 25-APR-2016 |
|
Known Affected Releases: | 4.2, 4.2(1), 4.2(2), 4.2(3) |
|
Known Fixed Releases: * | 4.2(2.0)PP6 |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuy22568 | Title: | CDPTest fails to match link endpoint between Nexus-5K VNEs |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
PN fails to discover Ethernet and physical links using CDP Test when link endpoint is located on Nexus-5K device. If link discovery can be accomplished only with CDP Test, the links will not be discovered.
Conditions:
At least one endpoint of the physical link originates on Nexus-5K device and CDP enabled.
Workaround:
Further Problem Description:
|
|
Last Modified: | 25-APR-2016 |
|
Known Affected Releases: | 4.2(2.0)PP4, 4.2(3) |
|
Known Fixed Releases: * | 4.2(2.0)PP6 |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuv66897 | Title: | Alarm "Clear and Remove" operation in Network Vision is broken |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: |
Symptom:
The "Clear and Remove" operation is not working in Network Vision.
Conditions:
Manual clearing and removing of alarms in Network Vision
Workaround:
Apply separately "Clear" then "Remove" operations
Further Problem Description:
(release notes added by addprefcs-org.ksh)
|
|
Last Modified: | 25-APR-2016 |
|
Known Affected Releases: | 4.2(2.0)PP1, 4.2(2.0)PP2, 4.2(2.0)PP3, 4.2(2.0)PP4 |
|
Known Fixed Releases: * | 4.2(2.0)PP6 |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCur65803 | Title: | Starting path trace from ethFlowPoint (EFP) doesn't take inner VLAN |
|
Status: | Open |
|
Severity: * | 4 Minor |
Description: | Symptom:
When starting path trace from ethFlowPoint in EVC (in the service view map), choosing start and end point, path tracer does not include inner VLAN (if exist).
When doing the same from VNE inventory, starting from the EFP, it does take the inner VLAN.
Need to retrieve the inner VLAN in OpenPathToolBeginEthFlowPointCommandAction and in penPathToolEthFlowPointCommandAction.
Conditions:
Strat path trace from ethFLowPoint in EVC choosing start and end point with inner VLAN configuration.
Workaround:
None.
Further Problem Description:
|
|
Last Modified: | 29-APR-2016 |
|
Known Affected Releases: | 4.1, 4.1(0)PP3, 4.2, 4.2(1), 4.2(2), 4.2(3) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | New |
Bug Id: | CSCuz27540 | Title: | NV failed show Memory Usage in VNE inventory due NumberFormatException |
|
Status: | Open |
|
Severity: | 4 Minor |
Description: | Symptom:
Client PC/MAC computers fail to show properly VNE inventory due to NumberFormatException in the NV client application while trying to display Memory Usage
Conditions:
Spanish Argentina and similar localization of client computer.
Workaround:
Alter localization for displaying numbers: use dot (.) for decimal point and comma (,) for number grouping.
Further Problem Description:
|
|
Last Modified: | 26-APR-2016 |
|
Known Affected Releases: | 4.2(2.0)PP5 |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | New |
Bug Id: | CSCuz33633 | Title: | VNE sends bogus XBgpRouterIDAdvertiseMsg when BGP router ID not changed |
|
Status: | Fixed |
|
Severity: | 4 Minor |
Description: | Symptom:
VNE creates flood of XBgpRouterIDAdvertiseMsg messages, which then cause NullPointerException in the message handler
Conditions:
BGP technology is disabled in the VNE scheme.
Workaround:
None
Further Problem Description:
|
|
Last Modified: | 26-APR-2016 |
|
Known Affected Releases: | 4.1(0.1)PP3 |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | New |
Bug Id: | CSCuz34971 | Title: | FATAL NullPointerException in MPBgpTest.hashCode() |
|
Status: | Fixed |
|
Severity: | 4 Minor |
Description: | Symptom:
AVM log file is flooded with NullPointerException originated in MPBgpTest.hashCode() after BGP interface status got changed.
Conditions:
To be determined
Workaround:
None
Further Problem Description:
|
|
Last Modified: | 24-APR-2016 |
|
Known Affected Releases: | 4.1(0.1)PP3 |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuq70018 | Title: | user import from ldap ldif file fails, gives null ptr error |
|
Status: | Fixed |
|
Severity: | 6 Enhancement |
Description: | Symptom:
ldap ldif import fails with null ptr error on cmd line and jvm trace in avm 11 log
Conditions:
* start import from a directory that is not ~/Main
* give absolute path for ldif file, or any path that is not current directory for ldif file
Workaround:
Steps:
login as prime network user
cd ~/Main
copy your ldif file to ~/Main
import_users_from_LDIF_file.pl yourfile.ldif
param-list you used: userPrincipalName description displayName email
This list of parameters don't appear to be correct.
The parameters required are as follows: [roleName]
ensure you use the correct parameters, and order of parameter, if it is not correct the import will not be correct.
Further Problem Description:
|
|
Last Modified: | 25-APR-2016 |
|
Known Affected Releases: | 4.1(0)PP2 |
|
Known Fixed Releases: * | 4.1(0)PP3, 4.2(2.0)PP6 |
|
|
| |
没有评论:
发表评论