FCoE port with untrunked VSANs

[gnijs]

Hello,

Are there any disadvantages for not removing unneeded VSANs from an FCoE port ?

Suppose i have multiple VSANs in my Nexus NPV switch.

By default, they will all be active on a vfc interface:

interface vfc2484
  bind interface Ethernet148/1/14
  no shutdown

Result:

sh int vfc2484
vfc2484 is trunking
    Bound interface is Ethernet148/1/14
    Hardware is Ethernet
    Port WWN is 29:b3:8c:60:4f:0f:83:bf
    Admin port mode is F, trunk mode is on
    snmp link state traps are enabled
    Port mode is TF
    Port vsan is 611 <-- as configure in the VSAN database
    Trunk vsans (admin allowed and active) (1,611,613) <-- by default all allowed
    Trunk vsans (up)                       (611)
    Trunk vsans (isolated)                 ()
    Trunk vsans (initializing)             (1,613) <-- these remain in "initializing". Is there any disadvantage for this ??

The port VSAN is determined in the VSAN database:

vsan database
  vsan 611 interface vfc2484

The other "initializing" VSANs can be removed by implementing the "switchport trunk allowed" command:

interface vfc2484
  bind interface Ethernet148/1/14

  switchport trunk allowed VSAN 611 <-- this will remove VSAN 1 and VSAN 613
  no shutdown

sh int vfc2484
vfc2484 is trunking
    Bound interface is Ethernet148/1/14
    Hardware is Ethernet
    Port WWN is 29:b3:8c:60:4f:0f:83:bf
    Admin port mode is F, trunk mode is on
    snmp link state traps are enabled
    Port mode is TF
    Port vsan is 611
    Trunk vsans (admin allowed and active) (611) <-- only this one allowed
    Trunk vsans (up)                       (611)
    Trunk vsans (isolated)                 ()
    Trunk vsans (initializing)             () <-- none remain in initializing

But are there any advantages/disadvantages for doing so ?

ie faster bootup or initialization of the interface ?

regards,

Geert

[Walter Dey]

Hi Geert

I assume you talk about the configuration of the peer NPIV node, having TF ports; the attached NPV node has NP ports, Correct ?

Yes, you are right ! no problem. By running a trunk with multiple VSAN's you can reduce the number of links; however, if you don't want share multiple vsan traffic on one link, you would do exactly what you propose.

The configuration remains a trunk, with pruning down to one vsan.

http://www.cisco.com/c/en/us/td/docs/switches/datacenter/nexus5000/sw/san_switching/503_n2_1/Cisco_n5k_nxos_sanswitching_config_guide_rel503_n2_1_chapter6.html

Walter.

[gnijs]

Hello Walter,

In fact, i am talking about the FCoE server port facing the server (the CNA). On initialization, the FCoE VLAN/VSAN is communicated to the CNA using LLDP/DCBX. The port must be configured as a trunk by design and the SAN VLAN cannot be the native vlan. By default, all existing VSAN on the switch are trunked towards the server CNA, but since there is only one "port" VSAN, i guess this is the one that is communicated in LLDP/DCBX. The other VSANs/VLANs remain in "initialising" state, and i wondered if there are any disadvantage in leaving this. They can be pruned by the "trunk allowed vlan" command, but i wonder why Cisco software isn't doing this by default.

regards,

Geert