turn on suggestions
![]() Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
Showing results for
|
05-10-2015 06:41 PM
Hi All,
We are running BNA 12.1.0. We have an environment that involves DCX and M5424 switches in Access Gateway mode. We have four fabrics (two A and B fabrics) and the Access Gateway switches span both (either A or B) fabrics.
Looking at only Fabric A the mapping is like this:
AG Port 17,18,19,20,21,22 -> Fabric 1A
AG Port 23, 0 -> Fabric 2A
Historically we have had no trunking set up, and the Access Gateway switches show up in both fabrics in BNA without issue. We have recently started trunking in order to balance our load from the Access Gateway switches. The newly connected Access Gateways show up only in Fabric 2A.
I think this is due to BNA linking the physical ports only, and finding the first available fabric (which is on Port 0 of the AG). It doesn't seem to map the Logical Port WWN that is used to identify the trunk, even though these can be found in the correct fabric within BNA (showing up as a disconnected port).
Is there anything I can do to force adding the switch to the specific fabric? Or is there an upgrade that targets this specific issue (I've done some searching, but couldn't find anything)?
Thanks,
Chris.
05-12-2015 07:32 AM
Hey @Chris.Bennett,
I have reached out to our product team to see if they can help. As soon as they get back to me I'll let you know.
05-12-2015 06:44 PM
Thanks @DennisMSmith,
Further information that may be of use:
The DCXs are on FOS v7.2.1d
The AGs are mostly FOS v7.1.0a, with a few at v7.2.0a.
The few chassis I was referring to originally in my scenario are all at v7.1.0a.
Thanks,
05-14-2015 06:40 PM
Chris,
It should show the connections so would raise a TAC case. Can we get the supportsave from BNA server and client with indicating the AG in topology. Also the cli command output of “agshow” on both the fabrics will help.
Ken.
05-14-2015 09:22 PM
Thanks Ken,
I'll raise a case so that the supportsaves can be looked at.
To drill into more information here for the sake of completeness: There are 10 Access Gateway switches connected to each fabric on FID128. There are only 9 Chassis that are connected to FID2, however they are split over two sites on the Stretched Fabric..
Interestingly, running agshow on FID 128 lists only 8 of the Access Gateways that are actually connected excluding only the two that aren't showing up in that Fabric in BNA. All 9 show up in FID2.
PDCFabricA:FID128:user> agshow Worldwide Name Ports Enet IP Addr Firmware Local/Remote Name ------------------------------------------------------------------------------------------------------ 10:00:00:05:33:a6:66:66 24 IPAddress1.6 v7.1.0a local PDCChassis06_C1 10:00:00:05:33:a5:55:55 24 IPAddress1.5 v7.1.0a local PDCChassis05_C1 10:00:00:05:33:a1:11:11 24 IPAddress1.1 v7.1.0a local PDCChassis01_C1 10:00:00:27:f8:a4:44:44 24 IPAddress1.4 v7.1.0a local PDCChassis04_C1 10:00:00:27:f8:a3:33:33 24 IPAddress1.3 v7.1.0a local PDCChassis03_C1 10:00:00:27:f8:a2:22:22 24 IPAddress1.2 v7.1.0a local PDCChassis02_C1 10:00:00:27:f8:a8:88:88 24 IPAddress1.8 v7.2.0a local PDCChassis08_C1 10:00:50:eb:1a:a7:77:77 24 IPAddress1.7 v7.2.0a local PDCChassis07_C1 PDCStretchedFabricA:FID2:user> agshow Worldwide Name Ports Enet IP Addr Firmware Local/Remote Name ------------------------------------------------------------------------------------------------------ 10:00:00:05:33:a9:99:99 24 IPAddress1.9 v7.1.0a local PDCChassis09_C1 10:00:00:05:33:a5:55:55 24 IPaddress1.5 v7.1.0a local PDCChassis05_C1 10:00:00:05:33:c8:88:88 24 IPAddress3.8 v7.1.0a remote SDCChassis08_C1 10:00:00:05:33:aa:aa:aa 24 IPAddress1.10 v7.1.0a local PDCChassis10_C1 10:00:00:27:f8:c4:44:44 24 IPAddress3.4 v7.1.0a remote SDCChassis04_C1 10:00:00:27:f8:a8:88:88 24 IPAddress1.8 v7.2.0a local PDCChassis08_C1 10:00:50:eb:1a:c7:77:77 24 IPAddress3.7 v7.2.0a remote SDCChassis07_C1 10:00:50:eb:1a:a7:77:77 24 IPAddress1.7 v7.2.0a local PDCChassis07_C1 10:00:50:eb:1a:c6:66:66 24 IPAddress3.6 v7.2.0a remote SDCChassis06_C1
This is strange because the Access Gateways PDCChassis09_C1 and PDCChassis10_C1 both are successfully sending data through their trunked ports on the DCX (Slot 4 ports 32-37):
PDCFabricA:FID128:user> porttrunkarea --show all|grep 304 4 32 F-port Slave 4/33 304 304 4 33 F-port Master 4/33 304 305 4 34 F-port Slave 4/33 304 306 4 35 F-port Slave 4/33 304 307 4 36 F-port Slave 4/33 304 308 4 37 F-port Slave 4/33 304 309 PDCFabricA:FID128:user> porttrunkarea --show trunk Trunk Index 304: 305->18 sp: 8.000G bw: 48.000G deskew 15 MASTER Tx: Bandwidth 48.00Gbps, Throughput 221.60Kbps (0.00%) Rx: Bandwidth 48.00Gbps, Throughput 151.09Mbps (0.37%) Tx+Rx: Bandwidth 96.00Gbps, Throughput 151.32Mbps (0.18%) 307->20 sp: 8.000G bw: 8.000G deskew 15 Tx: Bandwidth 48.00Gbps, Throughput 221.60Kbps (0.00%) Rx: Bandwidth 48.00Gbps, Throughput 151.09Mbps (0.37%) Tx+Rx: Bandwidth 96.00Gbps, Throughput 151.32Mbps (0.18%) 304->17 sp: 8.000G bw: 8.000G deskew 15 Tx: Bandwidth 48.00Gbps, Throughput 221.60Kbps (0.00%) Rx: Bandwidth 48.00Gbps, Throughput 151.09Mbps (0.37%) Tx+Rx: Bandwidth 96.00Gbps, Throughput 151.32Mbps (0.18%) 306->19 sp: 8.000G bw: 8.000G deskew 15 Tx: Bandwidth 48.00Gbps, Throughput 221.60Kbps (0.00%) Rx: Bandwidth 48.00Gbps, Throughput 151.09Mbps (0.37%) Tx+Rx: Bandwidth 96.00Gbps, Throughput 151.32Mbps (0.18%) 308->21 sp: 8.000G bw: 8.000G deskew 15 Tx: Bandwidth 48.00Gbps, Throughput 221.60Kbps (0.00%) Rx: Bandwidth 48.00Gbps, Throughput 151.09Mbps (0.37%) Tx+Rx: Bandwidth 96.00Gbps, Throughput 151.32Mbps (0.18%) 309->22 sp: 8.000G bw: 8.000G deskew 15 Tx: Bandwidth 48.00Gbps, Throughput 221.60Kbps (0.00%) Rx: Bandwidth 48.00Gbps, Throughput 151.09Mbps (0.37%) Tx+Rx: Bandwidth 96.00Gbps, Throughput 151.32Mbps (0.18%)
If I portshow the master port for this I can see that there are devices logged on through it:
PDCFabricA:FID128:user> portshow 4/33 portIndex: 304 portName: PDCChassis10_C1_18 portHealth: UNKNOWN Authentication: None portDisableReason: None portCFlags: 0x1 portFlags: 0x58024b03 PRESENT ACTIVE T_FPORT T_FMASTER F_PORT G_PORT U_PORT NPIV LOGICAL_ONLINE LOGIN NOELP LED ACCEPT FLOGI AOQ AOQ_AG LocalSwcFlags: 0x0 portType: 17.0 portState: 1 Online Protocol: FC portPhys: 6 In_Sync portScn: 32 F_Port Trunk master port port generation number: 6036 state transition count: 2 portId: 01b8c0 portIfId: 43420809 shareIfId: 43420819 portWwn: 2e:31:00:05:33:00:00:00 Logical portWwn: 50:00:53:30:00:0f:71:c7 portWwn of device(s) connected: 21:00:00:24:ff:00:49:98 21:00:00:24:ff:00:49:90 21:00:00:24:ff:00:58:0c 21:00:00:24:ff:00:58:a2 21:00:00:24:ff:00:1c:6e 21:00:00:24:ff:00:6c:16 21:00:00:24:ff:00:1e:7a 21:00:00:24:ff:00:ba:26 21:00:00:24:ff:00:18:06 21:00:00:24:ff:00:08:04 21:00:00:24:ff:00:b9:c6 21:00:00:24:ff:00:ba:ba 21:00:00:24:ff:00:df:1c 21:00:00:24:ff:00:dc:da 25:00:00:05:33:aa:aa:aa Distance: normal portSpeed: N8Gbps ...
No errors exist on the ports on either the Access Gateway or the DCX.
I'll get on with lodging a case with supportsaves from BNA, the DCX, a working AG and another AG that does not show up, but I'm intrigued as to why they aren't displayed in agshow, when they clearly are connected. I wonder if it's because the ag is doing a FLOGI with it's Trunk WWN of 25:00:00:05:33:aa:aa:aa instead of it's Switch WWN of 10:00:00:05:33:aa:aa:aa, or if it is the mapping to the Logical portWwn instead of a Physical Port WWN.
Also, why does this seem to be an issue for PDCChassis09 and PDCChassis10 and not PDCChassis07 and PDCChassis08?
PDCFabricA:FID128:user> porttrunkarea --show enabled Slot Port Type State Master TI DI ------------------------------------------- 4 16 F-port Master 4/16 176 176 4 17 F-port Slave 4/16 176 177 4 18 F-port Slave 4/16 176 178 4 19 F-port Slave 4/16 176 179 4 20 F-port Slave 4/16 176 180 4 21 -- -- -- 176 181 ------------------------------------------- 4 32 F-port Slave 4/33 304 304 4 33 F-port Master 4/33 304 305 4 34 F-port Slave 4/33 304 306 4 35 F-port Slave 4/33 304 307 4 36 F-port Slave 4/33 304 308 4 37 F-port Slave 4/33 304 309 ------------------------------------------- 10 16 F-port Slave 10/20 208 208 10 17 F-port Slave 10/20 208 209 10 18 F-port Slave 10/20 208 210 10 19 F-port Slave 10/20 208 211 10 20 F-port Master 10/20 208 212 10 21 F-port Slave 10/20 208 213 ------------------------------------------- 10 32 F-port Slave 10/37 336 336 10 33 F-port Slave 10/37 336 337 10 34 F-port Slave 10/37 336 338 10 35 F-port Slave 10/37 336 339 10 36 F-port Slave 10/37 336 340 10 37 F-port Master 10/37 336 341 ------------------------------------------- PDCFabricA:FID128:user> portname|grep 336 port 336: PDCChassis07_C1_17 PDCFabricA:FID128:user> portname|grep 176 port 176: PDCChassis09_C1_17 PDCFabricA:FID128:user> portname|grep 208 port 208: PDCChassis08_C1_17
Thanks,
Chris.
05-25-2015 09:41 PM
There is an issue when connecting AG's to shared-area id core-ports. (See below)
Either upgrade FOS to 7.3.0+ and enable "F-port device update mode" via the "configure" command or move the F-ports to non-shared area id. (ie a core-switch poirt that ends in 00.
PDCFabricA:FID128:user> portshow 4/33 portIndex: 304 portName: PDCChassis10_C1_18 portHealth: UNKNOWN Authentication: None portDisableReason: None portCFlags: 0x1 portFlags: 0x58024b03 PRESENT ACTIVE T_FPORT T_FMASTER F_PORT G_PORT U_PORT NPIV LOGICAL_ONLINE LOGIN NOELP LED ACCEPT FLOGI AOQ AOQ_AG LocalSwcFlags: 0x0 portType: 17.0 portState: 1 Online Protocol: FC portPhys: 6 In_Sync portScn: 32 F_Port Trunk master port port generation number: 6036 state transition count: 2 portId: 01b8c0 portIfId: 43420809 shareIfId: 43420819 portWwn: 2e:31:00:05:33:00:00:00 Logical portWwn: 50:00:53:30:00:0f:71:c7 portWwn of device(s) connected: 21:00:00:24:ff:00:49:98 21:00:00:24:ff:00:49:90 21:00:00:24:ff:00:58:0c 21:00:00:24:ff:00:58:a2 21:00:00:24:ff:00:1c:6e 21:00:00:24:ff:00:6c:16 21:00:00:24:ff:00:1e:7a 21:00:00:24:ff:00:ba:26 21:00:00:24:ff:00:18:06 21:00:00:24:ff:00:08:04 21:00:00:24:ff:00:b9:c6 21:00:00:24:ff:00:ba:ba 21:00:00:24:ff:00:df:1c 21:00:00:24:ff:00:dc:da 25:00:00:05:33:aa:aa:aa Distance: normal
05-25-2015 09:55 PM
Thanks Erwin,
Looking into it further though, the other Blade Chassis are on shared port areas without issues.
eg.
PDCFabricA:FID128:user> portshow 10/37 portIndex: 336 portName: PDCChassis07_C1_22 portHealth: UNKNOWN Authentication: None portDisableReason: None portCFlags: 0x1 portFlags: 0x58024b03 PRESENT ACTIVE T_FPORT T_FMASTER F_PORT G_PORT U_PORT NPIV LOGICAL_ONLINE LOGIN NOELP LED ACCEPT AOQ AOQ_AG LocalSwcFlags: 0x0 portType: 17.0 portState: 1 Online Protocol: FC portPhys: 6 In_Sync portScn: 32 F_Port Trunk master port port generation number: 0 state transition count: 0 portId: 01d8c0 portIfId: 43a2080d shareIfId: 43a2081d portWwn: 2e:55:00:05:33:00:00:00 Logical portWwn: 50:00:53:30:00:cf:71:c0 portWwn of device(s) connected: 21:00:00:24:ff:00:b9:f6 21:00:00:24:ff:00:75:b6 25:00:50:05:33:aa:aa:aa 21:00:00:24:ff:00:07:f0 21:00:00:24:ff:00:69:8a 21:00:00:24:ff:00:6b:f2 21:00:00:24:ff:00:a0:a4 21:00:00:24:ff:00:a0:f6 Distance: normal portSpeed: N8Gbps
So there really has to be something else going on here.
Thanks,
Chris.
05-25-2015 10:12 PM
Nope, this one may have bounced once or twice woth an active NPIV mapping on it. Give it a try and move it to a non-shared port. I'm 99% certain this will resolve your issue.