Blogs

Introduction

Racktables version 0.20.1 has new feature support for Cisco UCS environments. Racktables is a structured and robust open-source solution for datacenter asset management, that helps document hardware assets, network addresses, space in racks and network configuration.
...Read More

 

I just added a new section to the UCS PowerTool section on the UCS CDN site that will provide a central repository of PoSh scripts, examples, and videos that detail use cases and examples for UCS PowerTool.

Here is the link:
http://developer.cisco.com/web/unifiedcomputing/powertool-examples
...Read More

 

I would like to announce the general availability of goUCS version 2.0 on Cisco Developer Network. A lot of time and effort has been put into the newest goUCS release, with some of the main features being detailed below.

 

Lest anyone thinks I have forgotten about my blogging on the UCS API, I have not, but I have written a blog recently for the Data Center blog and it is applicable to the UCS so I thought I would share the link here along with the blog into.

Early in my career I moved quite a bit, new job, growing family, whatever the reason it seemed like every two or three years we were packing up and going to a new place and meeting our new neighbors.
...Read More

 

Updated and completely revised version 2.0 MP for Cisco UCS is now available for download. Please check the release notes for the complete list of bug fixes ...Read More

 

Showing 1 - 5 of 16 results.
Items per Page 5
of 4

Forums

« Back to Microsoft Discussions

PowerTool - Get-UcsFabricPort output bug?

Combination View Flat View Tree View
Threads [ Previous | Next ]
I was trying to map between FI's server port and Chassis IOM's fabric port, using Get-UcsFabricPort cmdlet.
The output of the cmdlet has PeerChassisId as N/A, while PeerDn clearly shows the Chassis id:
PeerChassisId : N/A
PeerDn : sys/chassis-1/slot-1/fabric/port-1
Could it be a bug at the output of this cmdlet?

I was trying to map between FI's server port and Chassis IOM's fabric port, using Get-UcsFabricPort cmdlet.
The output of the cmdlet has PeerChassisId as N/A, while PeerDn clearly shows the Chassis id:
PeerChassisId : N/A
PeerDn : sys/chassis-1/slot-1/fabric/port-1
Could it be a bug at the output of this cmdlet?


 
Hi Jason,
 
it's not a bug in Get-UcsFabricPort, that cmdlet is faithfully retreiveing the etherPIo objects in the UCS Managment Information Tree. Take alook at the output below, it is probably very similar to what you are seeing 
 
 
PS C:\> Get-UcsFabricPort -Dn sys/switch-B/slot-1/switch-ether/port-1
 
 
AdminState     : enabled
AdminTransport : ether
ChassisId      : 1
Encap          : unknown
EpDn           : fabric/server/sw-B/slot-1-port-1
IfRole         : server
IfType         : physical
Lc             : available
LicGP          : 0
LicState       : unknown
Locale         : internal
Mac            : 00:07:85:00:00:01
Mode           : fabric
Model          :
Name           :
OperSpeed      : 188
OperState      : up
PeerChassisId  : N/A
PeerDn         : sys/chassis-1/slot-2/fabric/port-1
PeerPortId     : 1
PeerSlotId     : 2
PortId         : 1
Revision       : 0
Serial         :
SlotId         : 1
StateQual      :
SwitchId       : B
Transport      : {ether}
Ts             : 1970-01-01T01:00:00.000
Type           : lan
UnifiedPort    : no
UsrLbl         :
Vendor         :
XcvrType       : unknown
Dn             : sys/switch-B/slot-1/switch-ether/port-1
Rn             : port-1
Status         :
Ucs            : machine
 
 
Now you can add the -Xml option to the cmdlet and your can see the raw XML that goes to and is returned from the Fabric Interconnect.  If you do that for Get-UcsFabricPort you'll see that the XML does not contain a value either. I formated the output a little bit for easier reading.
 
 
PS C:\> Get-UcsFabricPort -Dn sys/switch-B/slot-1/switch-ether/port-1 -Xml
==>machine:
<configResolveClass classId="etherPIo" inHierarchical="false">
  <inFilter>
    <eq class="etherPIo" property="dn" value="sys/switch-B/slot-1/switch-ether/port-1" />
  </inFilter>
</configResolveClass>
 
<==machine:
<configResolveClass cookie="" response="yes" classId="etherPIo">
  <outConfigs>  
    <etherPIo adminState="enabled" adminTransport="ether" chassisId="1"  dn="sys/switch-B/slot-1/switch-ether/port-1" encap="unknown" epDn="fabric/server/sw-B/slot-1-port-1" fltAggr="0" fsmDescr="" fsmPrev="nop" fsmProgr="100" fsmRmtInvErrCode="none" fsmRmtInvErrDescr="" fsmRmtInvRslt="" fsmStageDescr="" fsmStamp="never" fsmStatus="nop" fsmTry="0" ifRole="server" ifType="physical" lc="available" licGP="0" licState="unknown" locale="internal" mac="00:07:85:00:00:01" mode="fabric" model="" name="" operSpeed="52" operState="up" peerChassisId="N/A" peerDn="sys/chassis-1/slot-2/fabric/port-1" peerPortId="1" peerSlotId="2" portId="1" revision="0"  serial="" slotId="1" stateQual=""  switchId="B" transport="ether" ts="1970-01-01T01:00:00.000" type="lan" unifiedPort="no" usrLbl="" vendor="" xcvrType="unknown"/>
  </outConfigs>
</configResolveClass>
 
Hope that helps, what the peerChassisId attribute is intended for and why it says "N/A"? I don't know, perhaps a future feature.
 
Regards,
John

Thanks John. I agree it may not be a bug in the cmdlet itself, but I'm puzzled by the N/A notation of the PeerChssisId.

Maybe a Cisco developer can tell us what the value of PeerChassisId should be. It seems the other Peer properties are populated.

Cheers,
Jason

Collateral


No files available