Cisco on BAFM

UCS blades w/ Boot-from-SAN and AutoYaST

Thu, 30 Jun 2016 14:49:01 +0000

As I wrote before about enabling multipathing for the AutoYaST installation it’s about time I write this one here.

Sadly AutoYaST needs a little push in the right direction (as to where to actually put the root device), so here’s part of my AutoYaST profile for such a Cisco blade:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54


<profile xmlns="http://www.suse.com/1.0/yast2ns" xmlns:config="http://www.suse.com/1.0/configns">

 <bootloader>
 <device_map config:type="list">
 <device_map_entry>
 <firmware>hd0</firmware>
 <linux>/dev/sda</linux>
 </device_map_entry>
 </device_map>
 </bootloader>

 <partitioning config:type="list">
 <drive>
 <device>/dev/sda</device>
 </drive>
 </partitioning>

 <scripts>
 <pre-scripts config:type="list">

 <script>
 <debug config:type="boolean">false</debug>
 <feedback config:type="boolean">false</feedback>
 <filename>config-ucs.sh</filename>
 <interpreter>shell</interpreter>
 <source><![CDATA[
cat /tmp/profile/autoinst.xml | sed "s,/dev/sda,/dev/mapper/`/sbin/multipath -ll | grep dm-0 | cut -d -f1`," > /tmp/profile/modified.xml
]]>
 </source>
 </script>

 </pre-scripts>

 <chroot-scripts config:type="list">

 <script>
 <chrooted config:type="boolean">true</chrooted>
 <debug config:type="boolean">true</debug>
 <feedback config:type="boolean">true</feedback>
 <filename>config-ucs-chroot.sh</filename>
 <interpreter>shell</interpreter>
 <location>http://install.home.barfoo.org/autoyast/scripts/config-ucs-chroot.sh</location>
 </script>

 </chroot-scripts>
 </scripts>

 <software>
 <packages config:type="list">
 <package>multipath-tools</package>
 </packages>
 </software>

</profile>

Now, the profile addition takes care of the placement of the root-device now (simply parses multipath -ll) and adjusts the pulled profile accordingly ( /tmp/profile/modified.xml), which AutoYaST then re-reads.

Nagios: Integrating Cisco switches

Wed, 20 Aug 2014 08:20:53 +0000

Well, as I wrote recently, we received a new BladeCenter a few weeks back. Now, as we slowly take it into service I was interested in watching the utilization of the back planes as well as the CPU utilization of the Cisco Catalyst 3012 network switches.

The first mistake I made, was to trust Cisco with their guide about how to get the utilization from the device using SNMP. They stated some OID’s, which I tried with snmpwalk and got a result from.

1
2


snmpwalk -v1 -c public -O n 10.0.0.35 .1.3.6.1.4.1.9.5.1.1.8
.1.3.6.1.4.1.9.5.1.1.8.0 = INTEGER: 0

Now, as I tried retrieving the SNMP data by means of the check_snmp plugin, I got some flaky results:

1
2
3
4


/usr/lib/nagios/plugins/check_snmp -H 10.0.0.35 -C public
 .1.3.6.1.4.1.9.5.1.1.8
SNMP problem - No data received from host
CMD: /usr/bin/snmpget -t 1 -r 5 -m '' -v 1 [authpriv] 10.0.0.35:161

Those of you, who read the excerpts carefully will notice the difference between snmpwalk and the OID I passed on to check_snmp.

The point being, the OID’s Cisco gave in their Design tech notes are either old, or just not accurate at all. After passing on the .0 to each value given by Cisco, the check_snmp is all honky dory and integrated into Nagios.

As usual, the Nagios definitions are further down, for those interested.

Summer - finally

Sat, 16 Aug 2014 10:25:27 +0000

Well it’s mid of July and the weather seems to be my friend. 25°C ain’t that bad. I really liked the weather last week (although everyone at work was bitching about it being tooo warm 😛) and would like to keep it (for the rest of the year of course!).

Hrm, for everyone who loved the music within Kill Bill - Volume 1: Tomoyasu Hotei really rocks (playing Battle without Honor or Humanity).

UCS 5108 power redundancy lost

Sun, 22 Jun 2014 10:41:22 +0000

Well, another day - another UCS error. Out of the blue, one of our chassis started displaying that one PSU had failed, however the UCS was showing no PSU had failed 🤷

Well, as it turns out - this is yet another known bug in 2.0.2(r). You’ll either have to unplug and plug all the power cables (that’s four) in a maintainance window - or simply change the Equipment Power Policy (found in the Root of your UCS, tab Policy)

MDS9100 firmware updates - generating copy commands

Sun, 20 Oct 2013 11:20:02 +0000

Well, I went to work today … yeah, I know it’s Sunday right ? I ended up updating two MDS9148 switches and I didn’t want to figure out everything all over again. So I put the system image and kickstart onto one of our FTP servers and ran a short bash loop on it:

1
2
3
4


root:(ftp.daheim.heimdaheim.de) PWD:~
Sun Oct 20, 08:57:24 [0] > for file in `ls /srv/ftp/firmware/mds9148/*6.2.3*`; do
echo "copy ftp://10.0.0.55/`echo $file | sed 's,/srv/ftp/,,'` bootflash:/`echo $file | sed 's,/srv/ftp/firmware/mds9148/,,'`"
done

Now that’ll generate me two lines, which in turn I can use on the MDS’n:

UCS Manager 2-0-2r KVM bug

Sun, 28 Apr 2013 19:02:56 +0000

Well, we’ve been battling with a KVM bug in our UCS installation, that’s been driving me (and apparently the Cisco L3 support and development) nuts. But lets back up a bit. If you’ve worked with UCS before, once you open up the KVM console you’ll see the KVM and a shortcut commands (Shutdown, Reset) and another tab that allows you to mount virtual media.

Once you open it up, it should look like this:

MDS9000: Setting summer time for CET

Wed, 17 Oct 2012 20:37:36 +0000

After rebuilding two MDS9148, I wanted them to correctly switch the summer/winter time for my time zone. Currently I’m in CET (or CEST during the summer), so I googled for that. The search came up with Cisco-FAQ, however that needed a slight adjustment.

Apparently the NXOS doesn’t support the feature “recurring” in the clock configuration. So I had to slightly adapt the configuration line:

1
2


clock timezone MET 2 0
clock summer-time MET 5 Sun Mar 02:00 5 Sun Oct 03:00 60

UCS 5108: VIF down

Mon, 17 Sep 2012 18:20:26 +0000

Well, I have yet another weird UCS problem. I have a single blade, that has trouble with it’s primary fabric attachment.

The problem get’s even more weird, if you look at the details.

After looking at the IO modules, the error doesn’t become any clearer:

So far, I have tried nearly everything. I’ve tried resetting the active and passive Connectivity of the vNIC, I tried resetting the DCE adapter for the vNIC, but nothing. I even tried resetting the vHBA that’s associated with this fabric, but that didn’t result to anything. Not even the usual flogi (fibre channel login) errors, that you get when either booting/resetting the blade.

UCS 5108: Power problem

Tue, 04 Sep 2012 17:09:12 +0000

Well, I recently had yet another UCS display/I2C communication problem. Somehow one of my chassis’ started to think, that the power redundancy was lost.

After looking at it a bit deeper, it seems only the GUI or the chassis did notice this power glitch:

As you can see, all PSU’s still have power. Now, since I had a big maintainance window the last weekend anyhow (and I spent ~14 hours at work), I decided to restart the IO modules in that chassis. And guess what: The error is gone! Another weird I2C communication issue with the firmware release 2.0.2 …

Setting up the BladeCenter H

Fri, 30 Jan 2009 10:50:40 +0000

Well, we finally had our maintenance window today, in which we planned the hardware exchange for our current Dell Blade Chassis (don’t ask!). The exchange went fine, but as we started exploring the components (like the IBM BladeCenter SAN switches – which are in fact Cisco MDS 9100) we hit a few road blocks.

First, the default user name/password combo for the Cisco MDS 9100 for the BladeCenter is USERID/PASSW0RD (just as the rest of the password combinations).

Shibboleth (WTF is that)

Wed, 28 Feb 2007 08:51:05 +0000

OK, I’m sitting now again in train (hrm, I get the feeling I’ve done that already in the last few days - oh wait, I was doing that just on Monday) this time to Berlin.

My boss ordered me to attend a workshop covering the implementation of Shibboleth (for those of you, who can’t associate anything with that term - it’s an implementation for single sign-on, also covering distributed authorization and authentication) somewhere in Berlin Spandau (Evangelisches Johannesstift Berlin).

Plaything

Fri, 04 Aug 2006 03:51:31 +0000

Ok, today I received another WRT54GL (yah, too much money 😛 ) and updated it to dd-wrt v23-SP1 instantly and is now (once again) powering my wireless network.

Yay! and thanks to Cisco/Linksys for that fine piece of hardware and to NewMedia-NET GmbH for providing such a great image for this hardware 😄

Ah, nearly forgot that: remember, never put the same IP twice in the static DHCP lease table, or dnsmasq is refusing to start (thus no DHCP/DNS)!