Cisco

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. ...

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.

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). ...

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) ...

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: ...

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: ...

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

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. ...

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 …

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). ...