BNA not seeing AG's that straddle fabrics

[Chris.Bennett]

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.

[DennisMSmith]

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.

[Chris.Bennett]

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,

@Chris.Bennett

[kross]

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.

[Chris.Bennett]

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.

[evlonden]

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

[Chris.Bennett]

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.

[evlonden]

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.