Fabric Interconnect 6120xp question

I have two fabric interconnect 6120xp in cluster on one i find the ip in running config and on the partner i dont. It might be due to this i dont get the ipaddress of the fabric interconnect (shows as 0.0.0.0) on my san switch when querying fcns database. Any help is appreciated.
lhr02-wxp00-fic01-B(nxos)# sh run |inc ip
ip host lhr02-wxp00-fic01-B 10.255.96.78
  ip address 10.255.96.78/24
lhr02-wxp00-fic01-A(nxos)# sh run |inc ip
role name server-equipment
lhr02-wxp00-fic01-A(nxos)#
lhr02-wxif-san02#  show fcns database  npv
VSAN 20:
NPV NODE-NAME           NPV IP_ADDR     NPV IF  CORE SWITCH WWN         CORE IF
20:14:54:7f:ee:04:c8:01 10.255.96.78    fc2/4   20:00:54:7f:ee:07:6e:80 fc1/6
20:14:54:7f:ee:04:c8:01 10.255.96.78    fc2/2   20:00:54:7f:ee:07:6e:80 fc1/5
lhr02-wxif-san01#  show fcns database  npv
VSAN 10:
NPV NODE-NAME           NPV IP_ADDR     NPV IF  CORE SWITCH WWN         CORE IF
20:0a:54:7f:ee:03:ee:c1 0.0.0.0         fc2/1   20:00:54:7f:ee:17:eb:80 fc1/3
20:0a:54:7f:ee:03:ee:c1 0.0.0.0         fc2/3   20:00:54:7f:ee:17:eb:80 fc1/4

On the FI with the 0.0.0.0 ipaddress  run the sho npv inter info | inc IP.
Next go into UCSM and select the equipment tab.Then pick the FI in question. On the right select General tab and then Access.
What is the ipaddress? Does it also show 0.0.0.0 here as well?
If it does, try changing it to the address you wanted and check it again.
If that does not work then you can try to erase the config on that FI and reconfiguring it from the begining.
Verify they it joins the cluster and HA is ready and the ipaddress is available.

Similar Messages

  • 6248UP Fabric Interconnect Configuration Question

    We are in the middle of integrating VOIP into our enmvironment. The provider is asking for a VM to be built and a router to be connected directly to the VM. Can you integrate a GLC-T module into the 6248UP and connect the router directly to it. Configure the port and have that port provide access to the VM they are requesting? If you can, what should I configure the Interconnect port to be (Server or Appliance)? If this will not work, what will?

    Did you configure the port as 1G first ? btw. which FI are you using ? on a 62xx, each port can be 1 or 10G, on a 61xx, there are some limitations.
    Storage appliance port is used to connect IP storage Systems (NFS, iSCSI,....) not Switches / Routers.

  • UCS Fabric interconnect reboot Question:

    When you reboot an FI what is the expected behavior of UCS manager logs, faults, etc? What should we see to know what is a normal reboot and what are normal faults. We are trying to troubleshoot our FI's after an outage and can't find any info on how these normally log faults of this type.

    Hi Claudio
    I assume you talk about 10G copper, not 1G copper;
    and if 10G: CX-4 (Twinax) cables, or 10G Base-T ? 
    There is a 12-port 10GBASE-T module, but this is only supported on the Nexus 5596T so of no use on Nexus 5596UP switch, nor UCS FI.
    Anyway, it is a not recommended to connect UCS FI Uplinks to a Nexus 22xx ? just think about the oversubscription ! you would like to have as much bandwidth Northbound as possible.

  • Is there a way to see SAN luns from the UCS fabric interconnect.

                       Hello,
    I have recently added a 3rd and 4th vHBA to a B440 running RHEL5.
    Originally I had 2 vHBAs', and each created a path to 172 luns. (I was multipathed to 172 luns)
    Now I have added two additional vHBA's and my SAN admin assures me he has mapped, zoned and masked all 172 luns to the 2 new vHBA's.
    So, at this time I should have 4 paths to 172 luns....but I don't.
    What I see is 4 paths to 71 luns.
    I still see 2 paths to all 172 luns, but only see 4 paths on 71 of them.
    Its almost like my SAN admin either mapped or masked only 71 of the 172 luns to my 3rd and 4th path.
    Via the RHEL5 OS I have rescaned the FC paths, rebooted, done lsscsi, looked in the lowest level places for what devices are present on my FC channels, always I see 172 devices on the 2 original FC paths and 71 devices on the 2 new FC paths.
    My question is....is there a way to see all devices (luns) accociated with an vHBA from the command line in the Fabric Interconnect?
    My configuration is UCS w 2 FI's, using 8Gb FC connections to Cisco 9500 directors, to an EMC DMX4.
    Thanks in advance,
    Gene

    wdey,
    The link you supplied in your response is the answer.
    You can look at the devices on the FC boot paths, but not while the OS is running.
    I have a test server I could reeboot to try what you have in your document, and it does work.
    Too bad Cisco could not create a linux util rpm that would allow looking down the fabric while running. Im quit sure emulex has this kind of util, called HBAanywhere...at least for solaris.
    In any case, thanks for the link to your article, it was VERY good!
    My problem with seeing a shorter list of luns on 2 of my FC paths may get solved this afternoon by a change my SAN admin is going to make.. If it does I will post the fix.

  • Fabric Interconnect vNic Failover

    We have the following Palo vNIC allocation for an ESXi host with 1000v in our vBlock:
    VLANs on vNIC #
    1: 14;
    2: 41
    3: 42
    4 20,12,22,24;
    5: 4,3,6
    Now the statement has been made to us that this would not provide a redundant networking configuration in the event of a Fabric Interconnect failure, and there must be pairs of vNICs carrying a VLAN – one that traverses the left FIC and one the right FIC. The suggestion to us was to only use 2 vNICs and carry all VLANs.
    My understanding is that with the M81KR vNICs, they can be set to ‘Fabric Failover Mode’ which will switch the accessible path in the event of a FIC failure seamlessly to the host. Removing the host managed failover and maintaining the HA within the fabric instead.
    Is this a correct deployment when using Fabric Failover?

    I think I have found the answer to my own question:
    https://supportforums.cisco.com/docs/DOC-14992

  • UCS-Fabric Interconnect Replacement

    Hello everybody,
    I have a UCS domain with a failed Fabric Interconnect and i have to replace this Fabric. For me there is no action to do in the configuration of the new FI i just have to add it in the existing domain and give it the IP address, but i have a question about the firmware version. is the firmware automatically installing in the new Fabric or have i to install it manually ? the firmware version in my domain is 2.2(1b).
    Thanks for the answer
    Best Regards 
    François Fiocre

    Hi Claudio
    I assume you talk about 10G copper, not 1G copper;
    and if 10G: CX-4 (Twinax) cables, or 10G Base-T ? 
    There is a 12-port 10GBASE-T module, but this is only supported on the Nexus 5596T so of no use on Nexus 5596UP switch, nor UCS FI.
    Anyway, it is a not recommended to connect UCS FI Uplinks to a Nexus 22xx ? just think about the oversubscription ! you would like to have as much bandwidth Northbound as possible.

  • Connecting Fabric Interconnect to iSCSI array

    I need to connect my Fabric Interconnect to a new iSCSI array.  There are a number of UCS blades that need to connect to iSCSI LUNs. The FI is currently connected to the rest of the network through  Nexus 7000K switches.   Should I connected directly from the FI to the iSCSI array, or go through the 7000K and then to the array?

    Hi
    this is more of a design question, you have to think what will need access to the ISCCI storage array. For example, if only UCS blaes will have access to this storage array, you may want to consider connecting it directly as iscsi traffic won't have to go through your N7Ks if both fabrics are active.
    If you want another type of server such as HP or IBM to access the storage you may want to consider connecting the storage array to the N7Ks if your fabric are configured in end-host-mode. Again this will depend on your current implementation

  • Fabric Interconnect and storage solutions

    Dear
    Please I would like to clarify a question, is that a solution of storage, such as EMC VNX5300 can be connected directly to a Fabric Interconnect, but would lose functionality when connected to a Nexus 5000 switch. I would like someone to clarify this doubt indicating that functionality is lost when direct connection would be advisable to FI or the Nexus.
    Regards

    In versions of UCS earlier than 2.1, you had the  option to useDirect Attached Storage DAS with UCS. However, you needed a SAN switch connected  to the FI so the switch could push the zone database to the FI. That is,  the UCS platform was not able to build a zone database
    With the release of Version 2.1, UCS now has the  ability to build its own zone database. You can have DAS with UCS  without the need for a SAN switch to push the zoning configuration
    hope this helps

  • Fabric Interconnect Uplinks to Nexus 7710

    Can someone please help suggest how many Fabric Interconnect switches I can uplink to pair of Nexus 7710's.

    in most deployment, Fabric Interconnect is put as a pair for the redundancy.  They are either vPCed to the Nexus switches or straight-through up to non-Nexus switches.  
    i guess we would like to see more background of your questions in term of traffic requirement, what kind of line cards used on the N7710 etc.
    Regards,
    Michael

  • FAS3220 and FAS2240 direct attach on fabric interconnect 6296UP

    Hello everybody
    I have the following architecture
    1 Cisco Catalyst 6509-E
    1 Cisco Catalyst 3560-x
    2 Fabric Interconnect 6296UP
    1 FAS 3220 (principal storage)
    1 FAS2240 (vault backup)
    1 chasis cisco UCS 5108
    5 blade servers Cisco UCS B200M3
    Firmware version: 2.2(3c)
    Fabric Interconnect are direct attach on fabric interconnect 6296up and the ports are configurated as FC storage ports
    My question is the following:
    Can I zoning fabric interconnect with FAS3220 and FAS2240?
    Can I present LUNS of FAS2240 and FAS3220 at the same time on the same boot policy, same san boot policy, and the same organization?
    Thanks for your help

    Well, even if that was possible. You're accounting for a critical failure - i.e. a failure of two redundant devices (both 3220s, which I would have assume would be running in a cluster ... or 7mode). 
    While just upstream you have a single cat 6500 - which would be a single point of failure. 
    Logic would dictate to account for a single device failure all across the path before looking into multi-device failure. 

  • Fabric interconnect and Native Vlan

    Hi
    I just want to ask a simple question
    is there any precautions with native vlan between the Switched infrastructure and the Fabric interconnect ?! 
    I mean can I use any vlan as a native vlan ex.999 "anything but not 1" ?! 

    As a security best practice on trunks carrying multiple VLANs you should not allow the native vlan on the line.  When you have a single VLAN going to a device, an end node for example, the port should be configured as an access port with a single data VLAN, and potentially a voice vlan if that will be used.  
    For example, our N5Ks have a trunk to each of our UCS interconnects.  We set the native VLAN on the n5k side to 999. 999 is not in the allowed list for the trunk then, so the native VLAN never makes it to the ucs.  On the ucs then, any server that can handle VLANs (esxi for example) we send only tagged VLANs -- no VLAN is marked native, thus accomplishing the same thing as we did for the n5k to FI link.
    It is recommended to not leave your native VLAN as 1 as best practice.  It's less of a concern if the native VLAN isn't in the allowed list, but to avoid mis configuration issues you should set it to another VLAN. 

  • Can the system name of the Fabric Interconnects be changed

    I need to change the system name of the Fabric interconnects
    I have given eg. EDCD
    the FI now have EDCD-A
    EDCD-B
    I need to change it to ... ECCD-A
    ECCD-B..
    is it possible ?

    Shyam,
    You can definitely do it and for sure is not disruptive and take effect right away.    Just go to the Admin tab> All> Management Interfaces> Name > Edit it with what you need > Apply.
    It is so easy and fast that if at the same time you have an SSH session, as soon as you change the name, the system makes the change on your SSH session too.
    Note: There is no need to look for the way to do this on each fabric. The name you are changing is for both FIs and the system will then add the xya-A or xya-B by itself.
    Rate ALL helpful answers.
    -Kenny

  • Fabric Interconnect B, management services are unresponsive

    Hi,
    We have configured Call Home option in UCSM and we are getting below error from Call Home option since last Saturday. We have open TAC with Cisco to troubleshoot this error but as per TAC "The error is a transient error from which the fabric interconnects can automatically recover."
    Below is the error messages we are getting
    E-mail-1:
    Subject:
    System Notification from System-A - diagnostic:GOLD-major - 2011-12-27 17:54:09 GMT-00:00 Fabric Interconnect B, management services are unresponsive
    Body Message:
    System Name:System-A
    Time of Event:2011-12-27 17:54:09 GMT-00:00
    Event Description:Fabric Interconnect B, management services are unresponsive
    Severity Level:6
    E-mail-2:
    Subject:
    System Notification from System-A - diagnostic:GOLD-major - 2011-12-27 17:54:09 GMT-00:00 Fabric Interconnect B, management services are unresponsive
    Body Message:
    <?xml version="1.0" encoding="UTF-8" ?>
    <soap-env:Envelope xmlns:soap-env="http://www.w3.org/2003/05/soap-envelope">
    <soap-env:Header>
    <aml-session:Session xmlns:aml-session="http://www.cisco.com/2004/01/aml-session" soap-env:mustUnderstand="true" soap-env:role="http://www.w3.org/2003/05/soap-envelope/role/next">
    <aml-session:To>http://tools.cisco.com/neddce/services/DDCEService</aml-session:To>
    <aml-session:Path>
    <aml-session:Via>http://www.cisco.com/appliance/uri</aml-session:Via>
    </aml-session:Path>
    <aml-session:From>http://www.cisco.com/appliance/uri</aml-session:From>
    <aml-session:MessageId>1058:SSI1442BFRC:4EFA0641</aml-session:MessageId>
    </aml-session:Session>
    </soap-env:Header>
    <soap-env:Body>
    <aml-block:Block xmlns:aml-block="http://www.cisco.com/2004/01/aml-block">
    <aml-block:Header>
    <aml-block:Type>http://www.cisco.com/2005/05/callhome/diagnostic</aml-block:Type>
    <aml-block:CreationDate>2011-12-27 17:54:09 GMT-00:00</aml-block:CreationDate>
    <aml-block:Builder>
    <aml-block:Name>UCS 6100 Series Fabric Interconnect</aml-block:Name>
    <aml-block:Version>4.2(1)N1(1.43q)</aml-block:Version>
    </aml-block:Builder>
    <aml-block:BlockGroup>
    <aml-block:GroupId>1059:Serial Number:4EFA0641</aml-block:GroupId>
    <aml-block:Number>0</aml-block:Number>
    <aml-block:IsLast>true</aml-block:IsLast>
    <aml-block:IsPrimary>true</aml-block:IsPrimary>
    <aml-block:WaitForPrimary>false</aml-block:WaitForPrimary>
    </aml-block:BlockGroup>
    <aml-block:Severity>6</aml-block:Severity>
    </aml-block:Header>
    <aml-block:Content>
    <ch:CallHome xmlns:ch="http://www.cisco.com/2005/05/callhome" version="1.0">
    <ch:EventTime>2011-12-27 17:54:09 GMT-00:00</ch:EventTime>
    <ch:MessageDescription>Fabric Interconnect B, management services are unresponsive</ch:MessageDescription>
    <ch:Event>
    <ch:Type>diagnostic</ch:Type>
    <ch:SubType>GOLD-major</ch:SubType>
    <ch:Brand>Cisco</ch:Brand>
    <ch:Series>UCS 6100 Series Fabric Interconnect</ch:Series>
    </ch:Event>
    <ch:CustomerData>
    <ch:UserData>
    <ch:Email>[email protected]</ch:Email>
    </ch:UserData>
    <ch:ContractData>
    <ch:CustomerId>[email protected]</ch:CustomerId>
    <ch:ContractId>ContractID</ch:ContractId>
    <ch:DeviceId>N10-S6100@C@SSI1442BFRC</ch:DeviceId>
    </ch:ContractData>
    <ch:SystemInfo>
    <ch:Name>System-A</ch:Name>
    <ch:Contact>Name</ch:Contact>
    <ch:ContactEmail>[email protected]</ch:ContactEmail>
    <ch:ContactPhoneNumber>+00-0000000000</ch:ContactPhoneNumber>
    <ch:StreetAddress>Office Address</ch:StreetAddress>
    </ch:SystemInfo>
    </ch:CustomerData>
    <ch:Device>
    <rme:Chassis xmlns:rme="http://www.cisco.com/rme/4.0">
    <rme:Model>N10-S6100</rme:Model>
    <rme:HardwareVersion>0.0</rme:HardwareVersion>
    <rme:SerialNumber>SerialNumber</rme:SerialNumber>
    </rme:Chassis>
    </ch:Device>
    </ch:CallHome>
    </aml-block:Content>
    <aml-block:Attachments>
    <aml-block:Attachment type="inline">
    <aml-block:Name>sam_content_file</aml-block:Name>
    <aml-block:Data encoding="plain">
    <![CDATA[
    <faultInst
    ack="no"
    cause="management-services-unresponsive"
    changeSet=""
    code="F0452"
    created="2011-12-27T23:24:09.681"
    descr="Fabric Interconnect B, management services are unresponsive"
    dn="sys/mgmt-entity-B/fault-F0452"
    highestSeverity="critical"
    id="2036245"
    lastTransition="2011-12-27T23:24:09.681"
    lc=""
    occur="1"
    origSeverity="critical"
    prevSeverity="critical"
    rule="mgmt-entity-management-services-unresponsive"
    severity="critical"
    status="created"
    tags=""
    type="management"/>]]>
    </aml-block:Data>
    </aml-block:Attachment>
    </aml-block:Attachments>
    </aml-block:Block>
    </soap-env:Body>
    </soap-env:Envelope>
    We want to understand that what is the impact of this error and is there anything that we can do to prevent this error? Also want to know what might be the cause get this error?
    Let me know if anything else is needed from my side
    show-tech file uploaded.

    Padma,
    TAC Engineer sent below mail
    Hi Amit,
    I’ve checked through the show tech you’ve uploaded and have not found any indicators of errors for the error message you are seeing.
    As I mentioned in the call, the error is a transient error from which the fabric interconnects can automatically recover from. The recommended action is to wait for a few (10-15min) to see if the error clears automatically. If the error does not clear then we will need to do further troubleshooting. This error on its own is not a cause for worry. As you have HA in your system the management services would have failed over the to the other fabric interconnect and would not affect your system performance.
    We can leave the system under observation for a few days to see if other errors occur concurrently with this error.
    I will upload show-tech logs here, find my reply below
    Is the alert generated only for FI B or both FIs ->> Amit: Alert generated for FI-B only
    Any change in cluster state corresponding to alert time stamp ->> Amit: Unfortunately when this error generating we are unable to see the cluster state because of timing. If you can guide / suggest from any other location I can find the state that will be helpful
    Cluster physical link status ->> Amit: Cluster link is OK
    Does FI have any core dumps ->> Amit: I don't have any idea about this. How can check this ?
    Regards,
    Amit Vyas

  • Info about Cisco Fabric Interconnect 6140 Operating System

    Hello. We're looking for tech specs about Cisco Fabric Interconnect 6140 Operating System. For us is important to know if the os is NX-OS or not.
    Posted by WebUser Federica Rossi

    The underlying OS is built on NX-OS, but there is a lot of software running on top that is the actual UCSM itself.
    The UCSM software controls the NXOS portions directly - there is no ability to actually configure the system from an NXOS level.
    UCS-250-A(nxos)# sh ver
    Cisco Nexus Operating System (NX-OS) Software
    TAC support: http://www.cisco.com/tac
    Software
      BIOS:      version 1.5.0
      loader:    version N/A
      kickstart: version 5.0(3)N2(2.1m)
      system:    version 5.0(3)N2(2.1m)

  • Why would Fabric Interconnects populate in fabric topology?

    If the Fabric Interconnects are configured in End-Host mode, why would it be sending management traffic through an F port link making it populate on our fabric topology.  We don’t have this on our existing Blades centers and would expect that we would be able to suppress this for these UCS interconnect devices.  These devices are not managed by the SAN teams and they would prefer them NOT to appear as though they are.
    Any advice?

    Release notes in 2.0(5a) showed 
    CSCua91672
    The fcoe_mgr hap reset will no longer cause FI reboot.
    http://www.cisco.com/c/en/us/td/docs/unified_computing/ucs/release/notes/OL_25363.html
    I am really never on the Fiber Interconnects to execute any CLI commands.  But a memory leak for some other reason would certainly be a possibility. The fact that its own High Availability process causes double reset in its own High Availability architecture is troubling. 

Maybe you are looking for