| |
|
Alert Type: | Updated * |
Bug Id: | CSCuw60767 | Title: | SSTE: C9396PX node not sending arp reply to the host |
|
Status: | Fixed |
|
Severity: | 1 Catastrophic |
Description: | Symptom:
node not sending arp reply to the host
Conditions:
image load
Workaround:
NA
Further Problem Description:
|
|
Last Modified: | 18-NOV-2015 |
|
Known Affected Releases: | 7.1(0)I3(0.48) |
|
Known Fixed Releases: * | 7.0(3)I3(0.97), 7.0(3)I3(1), 7.0(3)IDP3(1.12), 7.0(3)IDP3(2) |
|
|
| |
| |
|
Alert Type: | New |
Bug Id: | CSCux15010 | Title: | DHCP packet drop after enable the dhcp snooping in N9k. |
|
Status: | Open |
|
Severity: | 1 Catastrophic |
Description: | Symptom:
DHCP offer drop, after enabling the dhcp snooping
Conditions:
DHCP snooping
Workaround:
Disable DHCP snooping
Further Problem Description:
|
|
Last Modified: | 14-NOV-2015 |
|
Known Affected Releases: | 7.0(3)I1(3), 7.0(3)I2(1a), 7.0(3)I2(2) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuw40773 | Title: | Copy R S failed due to "eth_port_channel" |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
copy r s failing on nexus 9508.
switch# copy r s
[########################################] 98% Configuration update aborted: timed out
Following errors seen in logs:
2015 Sep 22 20:37:44 MDFLD-MVD1 %SYSMGR-2-CFGWRITE_ABORTED_CONFELEMENT_RETRIES: Copy R S failed as config-failure retries are ongoing. Type "show nxapi retries" for checking the ongoing retries.
2015 Sep 22 20:37:44 MDFLD-MVD1 %SYSMGR-3-CFGWRITE_SRVFAILED: Service "confelem" failed to store its configuration (error-id 0x00000079).
2015 Sep 22 20:38:14 MDFLD-MVD1 %SYSMGR-3-BASIC_TRACE: process_show_running_req: PID 11354 with message rvcd on vdc 1 .
2015 Sep 22 20:38:14 MDFLD-MVD1 %SYSMGR-3-BASIC_TRACE: process_show_running_req: PID 11354 with message last vdc = 1 .
2015 Sep 22 20:38:14 MDFLD-MVD1 %SYSMGR-2-CFGWRITE_USER_ABORT: Configuration copy aborted by the user.
2015 Sep 22 20:38:44 MDFLD-MVD1 %SYSMGR-3-CFGWRITE_SRVFAILED: Service "ethpm" failed to store its configuration (error-id 0x0000007C).
2015 Sep 22 20:42:44 MDFLD-MVD1 %SYSMGR-3-CFGWRITE_SRVTIMEOUT: Service "eth_port_channel" failed to store its configuration in the timeout period
2015 Sep 22 20:42:44 MDFLD-MVD1 %SYSMGR-2-CFGWRITE_ABORTED: Configuration copy aborted.
2015 Sep 22 20:42:45 MDFLD-MVD1 %SYSMGR-3-CFGWRITE_FAILED: Configuration copy failed (error-id 0x401E0045).
Conditions:
configuring switchport on an L3 port-channel with sub-interfaces
Workaround:
1) to recover, we need to reload the box
2) to avoid hitting the bug, please do not change the L3 port-channel to switchport with sub-interfaces configured. If needed, delete sub-interfaces first and then change it.
Further Problem Description:
|
|
Last Modified: | 18-NOV-2015 |
|
Known Affected Releases: | 7.0(3)I2(1) |
|
Known Fixed Releases: * | 7.0(3)I2(1.21), 7.0(3)I2(1a), 7.0(3)I2(2) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuv37825 | Title: | arp packets looped back through vpc leg of peer when TCN |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
ARP packets might get looped back through vpc leg of peer when mac address table churn, in turn causing mac move events in the L2 network.
Conditions:
TCN/clear mac address-table manually.
Workaround:
n/a
Further Problem Description:
|
|
Last Modified: | 24-NOV-2015 |
|
Known Affected Releases: | 6.1(2)I3(4b), 7.0(3)I1(2) |
|
Known Fixed Releases: * | 7.0(3)I2(0.523), 7.0(3)I2(1), 7.0(3)ITI2(1), 7.0(3)ITI2(1.36), 8.3(0)CV(0.123) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuv35406 | Title: | Nexus 9300 does not learn MAC addresses on FEX HIF ports |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
Nexus 9300 switches may not learn MAC addresses on FEX HIF ports
Conditions:
Nexus 9300 running 7.0(3)I1(2) with FEX attached.
Workaround:
None
Further Problem Description:
|
|
Last Modified: | 18-NOV-2015 |
|
Known Affected Releases: | 7.0(3)I1(2) |
|
Known Fixed Releases: * | <7.1(0)I>, 7.0(3)I1(2.4), 7.0(3)I1(3), 7.0(3)I2(0.487), 7.0(3)I2(0.496), 7.0(3)I2(1), 7.0(3)IMK2(1), 7.0(3)IMK2(1.15), 7.0(3)ITI2(1), 7.0(3)ITI2(1.36) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuv06108 | Title: | %IPFIB-SLOT1-4-UFIB_ROUTE_CREATE: Unicast route create failed for VRF |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
%IPFIB-SLOT1-4-UFIB_ROUTE_CREATE: Unicast route create failed for VRF message will be in syslog
Conditions:
As part of the above syslog following error should be seen:
Error: Internal error(-1)
Workaround:
To clear the condition reload of the specific slot reporting the error is necessary.
If it is a ToR, the ToR has to be reloaded.
Further Problem Description:
This is seen only on T2 instances operating in ALPM mode
|
|
Last Modified: | 18-NOV-2015 |
|
Known Affected Releases: | 6.1(2)I3(4), 6.1(2)I3(4b) |
|
Known Fixed Releases: * | <6.1(2)I>, 6.1(2)I3(4.6), 6.1(2)I3(4.7), 6.1(2)I3(4b), 6.1(2)I3(5), 7.0(3)I1(2.5), 7.0(3)I1(3), 7.0(3)I2(0.456), 7.0(3)I2(0.487), 7.0(3)I2(0.510) |
|
|
| |
| |
|
Alert Type: | New |
Bug Id: | CSCux25159 | Title: | URIB Core by constant churn of add/del/move of COOP EP into RIB of Spine |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
URIB Crash on the two spines is caused because of constant churn of add/del/move of COOP End-Points into RIB on spine and hitting the 4 Billion updates.
Conditions:
1. There is a MAC/Server which is connected to two different Leafs and sending packets with the same MAC. This is not expected and this will result in continuous move of this MAC In the fabric.
2. We are hitting a known bug which is causing the EP Programming failure on two leafs pairs and that is resulting in churn on spine, this is due to CSCuu55855
Workaround:
You can use the below command on spine to check if the counters are huge and if they are approaching 4B then we can proactively use the clear command to clear it so that we don't hit the issue.
Vsh
show routing ipv4 unicast profile funcstats
show routing ipv4 unicast profile funcstats clear ==> This will reset the counters.
Note that we have this issue only with 1.0.x/11.0.x releases and the above commands are not visible in 1.1.x/11.1.x releases.
Further Problem Description:
|
|
Last Modified: | 22-NOV-2015 |
|
Known Affected Releases: | 11.0(4) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | New |
Bug Id: | CSCux23312 | Title: | Fretta-camden: QoS policy not applied for mac-acl match |
|
Status: | Terminated |
|
Severity: | 2 Severe |
Description: | Symptom:
For bridged packets the action of set dscp and set precedence is not supported in hardware of Jericho Asic when the forwarding decision is bridging and not routing.
Conditions:
On a L2 interface apply qos policy which is doing a set dscp or set precedence in its action just like mentioned in the summary section of this bug. The packet should be bridged and not routed. In that case the rewrite of ToS will not happen.
Workaround:
Further Problem Description:
|
|
Last Modified: | 21-NOV-2015 |
|
Known Affected Releases: | 7.0(3)F1(0.75) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuq09078 | Title: | Hsrp move active/standby from vpc domain to another leaves gmac |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
Two different symptoms have been seen:
1) Traffic destined to VIP is looped on a backup/ listening/ standby switch
2) VMAC is programmed in hardware as a gateway MAC on backup/ listening/ standby switch
Conditions:
Two vPC pairs are L2 adjacent to each other, each pair is enabled for FHRP in the same group.
Traffic destined to VIP is received on backup/ listening/ standby which has gateway MAC configured in hardware, at this point the traffic will loop in software. No operational impact.
Workaround:
7.0(3)I2(1) and later versions of NXOS support 4-way HSRP.
Further Problem Description:
This design is not supported on the Nexus 9000 at this time.
|
|
Last Modified: | 18-NOV-2015 |
|
Known Affected Releases: | 6.1(2)I2(2b), 6.1(2)I3(0.178), 7.0(3)I1(1), 7.0(3)I2(1) |
|
Known Fixed Releases: * | 7.0(3)I1(2.5), 7.0(3)I1(2.8), 7.0(3)I1(3), 7.0(3)I2(0.350), 7.0(3)I2(1), 7.0(3)ITI2(1), 7.0(3)ITI2(1.36), 8.3(0)CV(0.72) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuw07942 | Title: | Bud Node: Mcast encap packets duplicated with VPC leg down scenarios |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
Duplicate VxLAN encapsulated packets are received on certain ports
Conditions:
When an IGMP join is present on a local vPC or orphan port from a VTEP, duplicate packets will be sent when a native frame is received and encapsulated with a multicast VxLAN header.
This behavior is observed for vPC ports with remote leg down, or for orphan ports when the native frame is received on the vPC peer switch.
Workaround:
There is no workaround
Further Problem Description:
|
|
Last Modified: | 18-NOV-2015 |
|
Known Affected Releases: | 7.0(3)I2(0.598) |
|
Known Fixed Releases: * | .0(3)I1(3b, .0(3)I1(3b(3b.1), 7.0(3)I1(3a), 7.0(3)I1(3b), 7.0(3)I2(0.601), 7.0(3)I2(1), 7.0(3)ITI2(1), 7.0(3)ITI2(1.37) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuw82350 | Title: | SSTE: C9396PX Node failing to learn Local Host MAC on VXLAN VLANs |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
Local Host MAC for VLAN 4 that is connected to n9396-2 eth 1/43 is 00:10:95:00:00:02, but the mac address is not seen in the mac address table. However, remote host mac from another VTEP n9396-1 is seen in the table. Actually, it happens with all the configured VXLAN VLAN.
Conditions:
The sequence of steps to get into this issue seems to be below:
1) Write erase
2) copy scp//root@image-vm/root/startup1_config startup-config
3) Reload
Another sequence of steps to get into this issue is below:
1) shutdown for incoming interface to be connected to hosts
2) no shutdown for the incoming interface to be connected to hosts
Workaround:
clear mac address-table dynamic
Further Problem Description:
|
|
Last Modified: | 18-NOV-2015 |
|
Known Affected Releases: | 7.0(3)I3(0.96), 7.0(3)I3(0.99), 7.0(3)I3(1) |
|
Known Fixed Releases: * | 7.0(3)I3(0.115), 7.0(3)I3(1), 7.0(3)IDP3(1.12), 7.0(3)IDP3(2) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuw31368 | Title: | N9K: shut down for PC memeber interfaces not working |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
Not able to shut down physical interfaces part of port-channel
Conditions:
NX-OS upgrade to 7.0(3)I2(1)
Workaround:
Configure "switchport" (or "no switchport" - depending on what the correct layer of the PC interface should be) under PC interface, then member physical interface can be shut down.
Also, please check the output of "show running-config po all" and get the value of MTU configured on the PC.
Configure that also on the PC.
Further Problem Description:
|
|
Last Modified: | 18-NOV-2015 |
|
Known Affected Releases: | 7.0(3)I2(1) |
|
Known Fixed Releases: * | 7.0(3)I2(1.19), 7.0(3)I2(1a), 7.0(3)I2(2) |
|
|
| |
| |
|
Alert Type: | New |
Bug Id: | CSCux15109 | Title: | Clock Time zone Commands Not Saved Upon Downgrade |
|
Status: | Open |
|
Severity: | 3 Moderate |
Description: | Symptom:
On a Nexus 9000 the clock timezone commands aren't saved and present in the start-up configuration when you downgrade software versions. Requiring the user to manually re-enter these commands to ensure the timezone is set correctly.
Conditions:
Nexus 9K running 7.0(3)I2(1a) downgrading to software release 6.1(2)I3(1).
Workaround:
The below command must be manually entered for the requested timezone after the downgrade.
N9K(config)# clock timezone ?
WORD Name of time zone, such as PST, MST, CST, EST, etc.. (Max Size 8)
Further Problem Description:
|
|
Last Modified: | 14-NOV-2015 |
|
Known Affected Releases: | 7.0(3)I2(1a) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCux13081 | Title: | TSW: atomic counters does not work with mac although in 2 leaves |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: * | Symptom:
While running counters for this pair of macs in 1.1.3(f) i am getting "Source and Destination cannot be on the same leaf" although the end points were on two different leaves.
Conditions:
Running TSW atomic counters with two MAC addresses residing on two leaf switches.
Workaround:
None
Further Problem Description:
|
|
Last Modified: | 14-NOV-2015 |
|
Known Affected Releases: | 1.1(3f) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCux11285 | Title: | N9k | Stale SSH sessions are seen if client is not sending close ack |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: * | Symptom:
n9k# show processes cpu sort | egrep -i ssh
745 60 119 509 0.00% dcos_sshd
925 65 132 497 0.00% dcos_sshd
1159 63 140 453 0.00% dcos_sshd
1334 63 129 495 0.00% dcos_sshd
1490 61 118 521 0.00% dcos_sshd
1559 61 118 524 0.00% dcos_sshd
1723 62 132 473 0.00% dcos_sshd
2182 67 126 535 0.00% dcos_sshd
2869 61 121 510 0.00% dcos_sshd
3224 63 121 521 0.00% dcos_sshd
3333 62 132 473 0.00% dcos_sshd
3685 91 115 796 0.00% dcos_sshd
3749 64 140 457 0.00% dcos_sshd
3958 61 119 512 0.00% dcos_sshd
4377 68 283 242 0.00% dcos_sshd
4498 62 118 529 0.00% dcos_sshd
4699 64 137 469 0.00% dcos_sshd
4743 61 123 502 0.00% dcos_sshd
5376 62 115 539 0.00% dcos_sshd
5509 80 459 175 0.00% dcos_sshd
Conditions:
Stale ssh sessions on N9K are using VTY lines and once all VTY lines are used ,clients would not be able to establish SSH session with the server.
Workaround:
1.Disable/Enable feature ssh to clear stale sessions.
2.Enable telnet as temporary access to the device. [optional]
Further Problem Description:
Stale ssh sessions will keep piling up even after the workaround.
New SSH sessions would not be established when vty lines are full.
Resolution:
Error condition (stale SSH session) was caused by the code not checking if the shell exited. The code fix for serverloop.c includes checking if the shell_exited variable is true and if variable client_wait_counter grows too large so that the SSH session is terminated.
|
|
Last Modified: | 14-NOV-2015 |
|
Known Affected Releases: | 6.1(2)I3(1) |
|
Known Fixed Releases: * | 6.1(2)I2(2c), 6.1(2)I2(3), 7.0(3)I1(1) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCux11016 | Title: | DOC: N9k - Sub-interface > 511 is not supported on physical interfaces |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: * | Symptom:
Physical Sub interfaces >511 is not supported on N93xx/N95xx platforms.
Example:
switch(config-subif)# inter ethernet 1/1.512
^
Invalid interface format at '^' marker.
switch(config-subif)#
switch# sh ver | i image
NXOS image file is: bootflash:///nxos.7.0.3.I2.1.bin
switch# conf ter
Enter configuration commands, one per line. End with CNTL/Z.
switch(config)# inter ethernet 1/1. ?
<1-511> Sub-Interface number (<1-63> for SI on satellite port)
Conditions:
only on physical interfaces.
Workaround:
please bind the interface in port-channel if subinterface >511 needs to be created.
switch(config)# inter port-channel 100
switch(config-if)# no switchport
switch(config-if)#
switch(config-if)# inter port-channel 100.4093
switch(config-subif)# sh run inter port-channel 100.4093
!Command: show running-config interface port-channel100.4093
!Time: Tue Nov 10 18:26:36 2015
version 7.0(3)I2(1)
interface port-channel100.4093
switch(config-subif)#
Further Problem Description:
|
|
Last Modified: | 14-NOV-2015 |
|
Known Affected Releases: | 7.0(3)I2(1) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | New |
Bug Id: | CSCux10371 | Title: | Traffic flows on vxlan tunnel when VNID is not programmed on interface |
|
Status: | Open |
|
Severity: | 3 Moderate |
Description: | Symptom:
Traffic is learnt in the fabric when the VNID is not on the interface
Conditions:
You have 2 AEP's that have hosts added to the AVS, but only one of them has the domain associated.
Workaround:
n/a
Further Problem Description:
|
|
Last Modified: | 11-NOV-2015 |
|
Known Affected Releases: | 11.1(3f) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | New |
Bug Id: | CSCux11108 | Title: | Bidir BSR RP prefix grp change failed to propagate through the network |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
BSR RP to grp-range mappings are out-of sync in network.
Conditions:
change in BSR PR prefix list.
Workaround:
Remove RP config on RP-candidate and re-apply.
Further Problem Description:
|
|
Last Modified: | 28-NOV-2015 |
|
Known Affected Releases: | 7.0(3)I3(0.123) |
|
Known Fixed Releases: | 7.0(3)I3(0.153), 7.0(3)I3(1) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCul95981 | Title: | Nexus 9000 - Missing SNMP IF information for loopbacks |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: * | Symptom:
MIB information will not be displayed for loopbacks by use of SNMP walk. IF table will not list Loopback interfaces when an SNMP walk is done.
IP table will list Loopbacks that an IP address has been assigned to, but not in the IF table (ifdescr = no loopbacks)
This may affect device discovery.
Conditions:
NX-OS 6.1(2)I1(1) when queried for tree of information.
Workaround:
N/A
Further Problem Description:
|
|
Last Modified: | 04-NOV-2015 |
|
Known Affected Releases: | 6.1(2)I1(1) |
|
Known Fixed Releases: | 6.1(2)I1(1.87), 6.1(2)I1(2), 6.1(2)I1(3.30), 6.1(2)I1(4), 6.1(2)I2(1) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCux00422 | Title: | ACI: removed taboo contract remains on Leaf when vzAny is used |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
Deny contract rule by Taboo contract remains on Leaf even after the taboo contract was removed from the EPG.
Conditions:
When vzAny is used and taboo contract overwrites the existing permit contract rule by deny.
Workaround:
It will be resolved by flushing the overwritten stale contract rule and reprogramming it.
To do so we have following options
Option 1 : remove the overwritten contract from EPG and re-add it.
Option 2 : unenforce VRF and enforce it again
Further Problem Description:
We can check if we are hitting this issue or not by following commands.
From following example, we see that deny rule by taboo contract remains even after taboo contract was removed.
Fab2-Leaf1# show zoning-rule scope 2359296 | grep "ID\|16387"
Rule ID SrcEPG DstEPG FilterID operSt Scope Action Priority
4117 16387 0 13 enabled 2359296 permit src_any_filter(9)
4116 0 16387 12 enabled 2359296 permit any_dest_filter(10)
Fab2-Leaf1#
Fab2-Leaf1#
Fab2-Leaf1# # Add taboo contract in EPG
Fab2-Leaf1#
Fab2-Leaf1# show zoning-rule scope 2359296 | grep "ID\|16387"
Rule ID SrcEPG DstEPG FilterID operSt Scope Action Priority
4117 16387 0 13 enabled 2359296 permit src_any_filter(9)
4116 0 16387 12 enabled 2359296 deny black_list(1) <----------
Fab2-Leaf1#
Fab2-Leaf1#
Fab2-Leaf1# # Remove taboo contract from EPG
Fab2-Leaf1#
Fab2-Leaf1# show zoning-rule scope 2359296 | grep "ID\|16387"
Rule ID SrcEPG DstEPG FilterID operSt Scope Action Priority
4117 16387 0 13 enabled 2359296 permit src_any_filter(9)
4116 0 16387 12 enabled 2359296 deny black_list(1) <----------
|
|
Last Modified: | 07-NOV-2015 |
|
Known Affected Releases: | 11.1(3f) |
|
Known Fixed Releases: * | 1.2(0.228a), 1.2(0.231b) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCux20519 | Title: | EPM log file is not wrapping |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
The EPM log file has stopped logging and is a very large size (4Gb for example)
Conditions:
/mnt/ifc/ is about 79% full or greater
Workaround:
Call TAC to remove the following files:
/mnt/ifc/log/epm*trace*
Further Problem Description:
|
|
Last Modified: | 26-NOV-2015 |
|
Known Affected Releases: | 11.1(2h) |
|
Known Fixed Releases: * | 11.2(0.91), 11.2(1.148) |
|
|
| |
| |
|
Alert Type: | New |
Bug Id: | CSCux29124 | Title: | ACI: duplicate packets with L3out with same VLAN on different BLeafs |
|
Status: | Terminated |
|
Severity: | 3 Moderate |
Description: | Symptom:
Packets destined to L3out are duplicated within ACI Fabric.
Conditions:
All should be met at the same time.
+ When there are 1 BLeaf pair with vPC and another BLeaf. (latter could be single or vPC pair)
+ When those BLeafs are using same VLAN for L3out with same subnet. <----- KEY CONDITION !!!
-> There is a case we try to use Act/Stb FW as L3out.
That is the reason why 2 L3out on different BLeafs are using same VLAN/subnet.
+ When destination is behind L3out with vPC
+ When source resides in different BLeaf from the dest BLeaf vPC pair
-> even though source is on BLeaf, source is normal EPG not L3out.
note : BLeaf = Boarder Leaf
Workaround:
1) Create two L3out with external svi. Two SVI's in those L3outs can share same subnet and Encap Vlan.
2)use different VLAN on each BLeaf pair.
3)or use same BLeaf pair for both Act and Stb FW(L3out)
Further Problem Description:
You may be hitting this defect when you see L3out destination nexthop on source BLeaf as external device IP which is not directory connected to that BLeaf.
From source BLeaf perspective, if that L3out destination should be reachable only through ACI Spine, then the next hop address should be TEP IP for egress BLeaf instead of the address for external L3out device.
Ex)
+ You may be hitting this defect
Leaf3# show ip route 192.168.100.1 vrf tk:vrf1
192.168.100.1/32, ubest/mbest: 1/0
*via 192.168.200.1, vlan21, [110/5], 00:00:24, ospf-default, intra
+ You should be fine with this defect
Leaf3# show ip route 192.168.100.1 vrf tk:vrf1
192.168.100.1/32, ubest/mbest: 2/0
*via %overlay-1, [200/5], 12:31:30, bgp-100, internal, tag 100
recursive next hop: /32%overlay-1
*via %overlay-1, [200/5], 12:31:30, bgp-100, internal, tag 100
recursive next hop: /32%overlay-1
|
|
Last Modified: | 26-NOV-2015 |
|
Known Affected Releases: | 11.1(2h), 11.1(3f), 11.1(4e) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCux20639 | Title: | N9k enabling remote-span on a L2 vlan disables mac learning. |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: * | Symptom:
L2 vlan no longer learning mac addresses after remote-span configuration.
Conditions:
When remote-span is configured on a L2 vlan and then removed, mac addresses are no longer learned on that vlan.
Workaround:
Remove and re-add the L2 vlan OR reload the N9k.
Further Problem Description:
remote-span is not supported in N9k.
Removed the config which is not supposed to appear in N9k.
|
|
Last Modified: | 20-NOV-2015 |
|
Known Affected Releases: | 7.0(3)I1(2), 7.0(3)I2(2) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | New |
Bug Id: | CSCux20637 | Title: | VXLAN Loadbalancing, when a vmk is removed, opflex does not re-negotiate |
|
Status: | Open |
|
Severity: | 3 Moderate |
Description: | Symptom:
Opflex channel stays permanently disconnected
Conditions:
a vmk was removed from the host acting as a VTEP, but there is still another vmk that can be used (multiple vmk's were configured for vxlan load balancing).
Workaround:
re-add the vmk that was removed
Further Problem Description:
|
|
Last Modified: | 19-NOV-2015 |
|
Known Affected Releases: | 1.1(3f) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | New |
Bug Id: | CSCux20641 | Title: | SVI IP not programmed in LST_SA if subnet prefix check is enabled |
|
Status: | Open |
|
Severity: | 3 Moderate |
Description: | Symptom:
BD Subnet address is not programmed in LST SA. As a result, traffic from remote leafs (that do not have the BD configured) may learn the subnet address with an incorrect pcTag which may cause packet drops due to policy deny. Note, this affects pings to the SVI only, hosts within the subnet are not affected
Conditions:
1) Enable 'enforce subnet check for ip learning' under the BD
2) Configure a new subnet under the BD.
The new subnet will not correctly be programmed on leaf LST
Workaround:
1) Disable 'enforce subnet check for ip learning'
2) Delete and re-add problem subnet
3) Re-enable 'enforce subnet check for ip learning'
Further Problem Description:
|
|
Last Modified: | 19-NOV-2015 |
|
Known Affected Releases: | 11.1(3f) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuu66830 | Title: | 100M connectivity issues after link shut/no shut with QSA and GLC-T |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
After link flap there is a chance that connectivity will be impacted on 100M link
Conditions:
This is seen when 3164 is connected to a partner device that does not support AN and the connection is via QSA using GLC-T. This is seen with AN disabled or enabled on 3164 and AN disabled on peer side.
This is not seen when AN is enabled on both sides
Workaround:
Shut/no shut the link
Further Problem Description:
|
|
Last Modified: | 18-NOV-2015 |
|
Known Affected Releases: | 6.1(2)I3(4) |
|
Known Fixed Releases: * | 6.1(2)I3(4b), 7.0(3)I2(0.533), 7.0(3)I2(1), 8.3(0)CV(0.123) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCux14919 | Title: | ACI - VMM Domain Security Policies cannot be modified from APIC |
|
Status: | Fixed |
|
Severity: | 4 Minor |
Description: | Symptom:
Whenever the need arises for Policy Settings to be changed, APIC doesn't have the option to change the settings for (Allow Promiscuous, Forged Transmits, or MAC changes).
Only way to change them is through vCenter, however, this triggers a Major fault shows up on the APIC:
Fault F0135
Unsupported remote operation detected on EPG: uni/tn/ap/epg detected in Controller: X.X.X.X with name NAME in datacenter DATACENTER in domain VMM_DOMAIN , error: [Portgroup MAC Changes security policy has been changed on external VMM controller].
Conditions:
Workaround:
Remove VMM Domain name, and add it again under the EPG, and while adding it, manually change the Security Policies.
Further Problem Description:
|
|
Last Modified: | 15-NOV-2015 |
|
Known Affected Releases: | 1.2(0.239a) |
|
Known Fixed Releases: * | 1.2(0.250b) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCux11137 | Title: | Extended fix for CSCuw40668 to fabrics with existing objects |
|
Status: | Fixed |
|
Severity: | 4 Minor |
Description: | Symptom:
In some cases, ACI fabrics with existing objects may not apply the right set of filters in the operational tab of an EPG nested under an application profile.
Conditions:
An ACI fabric running 1.1(4f) or later which was upgraded from a previous version with pre-existing objects
Workaround:
Use the following RESTFUL API call to ensure the fabric behaves as expected
1. Obtain root access to the APIC (please call into Cisco TAC to do this)
2. Enable test_api (please ask Cisco TAC for instructions)
3. Post the following data:
URL: https://a.p.i.c/testapi/policymgr/mo/.xml
Further Problem Description:
The problem should be rectified automatically (i.e. without the need for the above POST) in versions of APIC software that are after the release referenced in the integrated release for this defect.
|
|
Last Modified: | 24-NOV-2015 |
|
Known Affected Releases: | 1.1(4e) |
|
Known Fixed Releases: * | 1.2(0.245), 1.2(1.53a), 1.2(1.55a), 1.2(1.57a) |
|
|
| |
| |
|
Alert Type: | New |
Bug Id: | CSCux10348 | Title: | UI: SNMP Security Field should not be mandatory |
|
Status: | Fixed |
|
Severity: | 4 Minor |
Description: | Symptom:
The "Security Name" (secName) property is currently a mandatory field when creating a SNMP trap destination.
Conditions:
All APIC versions up and including 1.1(4)
Workaround:
NA. Populate this field with a 'dummy' value. This field value will be change to optional in a future release.
Further Problem Description:
|
|
Last Modified: | 11-NOV-2015 |
|
Known Affected Releases: | 1.1(3f), 1.1(4e), 1.2(0.139l) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | New |
Bug Id: | CSCux12388 | Title: | ACI: Need Fault when Node and I/F mismatch on L3out config |
|
Status: | Open |
|
Severity: | 4 Minor |
Description: | Symptom:
When Node-ID on Logical Node Profile and Logical I/F Profile for L3out doesn't match, ACI doesn't show any faults, it just doesn't work.
Fault should be raised against this to let users know configurations is wrong.
Conditions:
When Node-ID on Logical Node Profile and Logical I/F Profile for L3out doesn't match
Workaround:
none
Further Problem Description:
|
|
Last Modified: | 12-NOV-2015 |
|
Known Affected Releases: | 1.1(4e) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | New |
Bug Id: | CSCux30828 | Title: | Requested data is too large to process - L4-L7 Parameters |
|
Status: | Open |
|
Severity: | 4 Minor |
Description: | Symptom:
When making changes to a deployed service graph, a "Requested data is too large to process" error pops up in the APIC GUI.
The configuration change made to the L4-L7 Service Parameters does successfully get applied to the L4-L7 device.
Conditions:
Changes are made to a deployed service graph via the GUI.
Workaround:
No known workaround.
Further Problem Description:
|
|
Last Modified: | 26-NOV-2015 |
|
Known Affected Releases: | 1.1(4e) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuu66187 | Title: | EEM event timer cron does not trigger |
|
Status: | Fixed |
|
Severity: | 6 Enhancement |
Description: | Symptom:
EEM event with cron timer does not trigger
Conditions:
Workaround:
Use scheduler as a workaround
Further Problem Description:
|
|
Last Modified: | 18-NOV-2015 |
|
Known Affected Releases: | 7.0(3)I1(2) |
|
Known Fixed Releases: * | 7.0(3)I3(0.113), 7.0(3)I3(1), 7.0(3)IDP3(1.12), 7.0(3)IDP3(2) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuw96929 | Title: | Techsupports and cores should show file sizes |
|
Status: | Fixed |
|
Severity: | 6 Enhancement |
Description: | Symptom:
When viewing the Operations tab of Techsupports, On-demand Techsupports and Core files, the administrator is unable to view the files sizes of successful exports.
Conditions:
An export of a Techsupport, On-demand Techsupport or Core file has completed successfully.
Workaround:
There are currently no known workarounds.
Further Problem Description:
|
|
Last Modified: | 15-NOV-2015 |
|
Known Affected Releases: | 1.1(1o) |
|
Known Fixed Releases: * | 1.2(0.250b) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCux00564 | Title: | Log enhancement for SUP switchover |
|
Status: | Fixed |
|
Severity: | 6 Enhancement |
Description: | Symptom:
When SUP switchover happens, the original active SUP does not save log to permanent memory for root cause analysis.
Conditions:
Workaround:
Further Problem Description:
|
|
Last Modified: | 17-NOV-2015 |
|
Known Affected Releases: | 11.1(2h) |
|
Known Fixed Releases: * | 11.2(0.80), 11.2(0.86) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuw84116 | Title: | Idle Fan Speed increase in 1RU and 2RU ACI switches |
|
Status: | Fixed |
|
Severity: | 6 Enhancement |
Description: | Symptom:
SFPs are abnormally hot to the touch while the switch is operating normally.
Conditions:
1 or 2RU 9k switch running in ACI mode
Workaround:
Further Problem Description:
|
|
Last Modified: | 19-NOV-2015 |
|
Known Affected Releases: | 11.1(2h) |
|
Known Fixed Releases: * | 11.2(0.88) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuu59965 | Title: | Request to have EPG Description show up in Port Group Description of DVS Port |
|
Status: | Fixed |
|
Severity: | 6 Enhancement |
Description: * | Symptom:
Request to have EPG Description show up in Port Group Description of DVS Port
Conditions:
This is requested by customer for ease of use
Workaround:
Further Problem Description:
|
|
Last Modified: | 11-NOV-2015 |
|
Known Affected Releases: | 1.0(3h) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCut24538 | Title: | Port config failure warning PhysIfspeed_failed_flag needs detail |
|
Status: | Open |
|
Severity: | 6 Enhancement |
Description: * | Symptom:
PhysIfspeed_failed_flag needs detail
There are currently no Explanation/Recommended Action for this fault
Conditions:
When N9K-C9332PQ added to the ACI Fabric, we will get the following configuration failure on all e1/1 to e1/26 ports
Port configuration failure. Reason: 2 Failed Config: l1:PhysIfspeed_failed_flag
Workaround:
No known workaround at this time.
Further Problem Description:
|
|
Last Modified: | 18-NOV-2015 |
|
Known Affected Releases: | 7.2(99)ZZ(99.1) |
|
Known Fixed Releases: | |
|
|
| |
2015 Cisco and/or its affiliates. All rights reserved. 
没有评论:
发表评论