Config parsing

A quick post so I can reference later. I’m starting to play with RANCID after a suggestion from a coworker. While I’m not necessarily doing config diffs it does provide a platform to quickly connect to a variety of Cisco devices and spit out desired output. In the last week I’ve used this to enumerate some devices and find autonomous access points. I’ll write up a proper post on how I did that sometime in the future (hopefully) but for now let’s just look at what I did tonight to get an IP listing for RANCID.

Starting from about 10-15 backed up switch config files, I wanted to get a quick management IP address listing to use with my RANCID stuff. I did not configure these switches myself and the network is not well known to me at all so this was a gem lurking in my configs that I couldn’t just pluck from my brain. Knowing that my management vlan is 150 I figured I could just grep out the IP set on that SVI from each file. From the directory with all my switch configs (in a Linux VM) I ran the following to parse out my VLAN 150 line and the line after that containing the IP address. (In retrospect I should make this first command a bit more intelligent. I got lucky in the fact that there weren’t switches with description or some other command right after the interface.)

ubuntu-vm:~$ grep -A1 Vlan150 * > step1

Output looks like this:

--
switch-poe2960-confg:interface Vlan150
switch-poe2960-confg- ip address 192.168.150.53 255.255.255.0
--

Then I use grep again with some regex to strip out stuff that looks like IP addresses and place it on it’s own line.

ubuntu-vm:~$ grep -Eo '([0-9]{1,3}\.){3}[0-9]{1,3}' step1 > step2

Output looks like this:

192.168.150.53
255.255.255.0
192.168.150.54
255.255.255.0
192.168.150.51
255.255.255.0

One more grep to get rid of the subnet masks that I don’t care about. Initially I matched on a specific /24 but I realized maybe someone could fat finger or there could be other masks. I settled on this command which was quick enough to do the job.

ubuntu-vm:~$ grep -v 255.* step2 > step3

Output looks like this:

192.168.150.53
192.168.150.54
192.168.150.51

Finally for good measure sort and remove any dupes

ubuntu-vm:~$ sort step3 | uniq > final

Output looks like this:

192.168.150.51
192.168.150.53
192.168.150.54

What I have in the end is a listing of the IP addresses of the SVIs for vlan 150. This is then used as input for a script that does a few for loops with rancid. One file for IPs and one for commands letting RANCID do the harder login work and providing me with a single file as an output. In this case I was doing a show cdp neighbor to look for my APs.

This was a pretty quick operation while watching a movie so I know it’s not as tight as it could be. It relies on regex pretty heavily so if you aren’t familiar it could be confusing. Google it and take some time to learn, it’s a very useful method of parsing data. I could probably string it all together in one massively long piped command but it’s not something I’ll hopefully be repeating often so it’s not needed. I also like to do things in steps like this so I can verify my output along the way. Typically I’ll run the command and watch what it spits out and if it looks good I’ll run again using the output modifier to write to a file. If I pushed it all together in one string from the get go, It’d be quite difficult to figure out what the heck went wrong when something unexpected shows up. This also gives me some checks and balances along the way if steps 1 to X look good but X+1 is funky. I don’t have to throw away everything I did previously, just look at what happened at X+1.

This is pretty basic stuff but hopefully someone else finds this useful. If not at least I can come back to grab and reuse the regex and grep flags :)

Is the world ready for 802.11ac?

Just a quick post from the road with a screenshot of the state of hotel wireless in the area I’m in currently. It’s a bank of hotels near a mini-mall type area just over the major highway. I find these types of spots to be pretty typical in most towns that are not of a large size and thus a good barometer. Over the last 2 or so years I’ve slowly seen some hotel chains improving their networks due to the high demand (and expectation) from their customers. When I fired up Metageek’s inSSIDer to take a look at my survey AP’s channels I was pleasantly surprised. It would seem that the two hotels within moderate RF range (truth be told there are 2 others along this strip) are primarily using Ruckus and have their channel distribution set properly. After spending a good amount of time on the road in the last 1-1.5 years I can also state that this isn’t usually what I see. It would also appear that the retail chain across the street using Cisco gear not only has their power cranked up pretty high but they’re also not using the nice and clean 1/6/11 scheme. Insert facepalm and red faces here (do note this wasn’t *my* client).

Getting back to my post title, the other major thing of note is that there wasn’t a single 5ghz channel within range. Now I can’t be sure that our wayward Cisco AP didn’t have one due to distance but that would still only reveal one in many. While I’m happy to see channels being utilized properly (even if it’s not with the gear I use) I wonder why we’re still not seeing much 5 GHz. Is this the next step in the slow adoption of the service industry market? Will this piece of the market finally adopt 5ghz after vendors begin pushing 802.11ac? Finally, something I’ve been dwelling on for a while now. Once 802.11ac is out upon the masses will we have to wait several years before people are doing it “right” and be forced to live in the channel stomping reality that has plagued (and continues to plague in many cases) us in 2.4 GHz for so long? I’ll borrow a bit from Stan Lee and begin to say it now “With great bandwidth, comes great responsibility”. Are we ready for all that?

I certainly hope so….

Cisco MSE pains

I (and many others) have bumped in to problems when installing a Cisco MSE 3300 in a customer environment. Being a Linux zealot in my free time I’ve tried to make things easier on myself by tweaking some of the setup process.

Cisco’s setup script (in 7.0 at least) does some things to the network init scripts that are not nice and are not what I’d consider best practices. One problem people have run in to is after reboot the NICs will swap assignment (e.g. eth0 is now eth1). From my understanding the main reason for the instability is that the initial setup script rewrites the network config file and the new version doesn’t contain the MAC anymore. If I understand the udev process correctly, Linux dynamically allocates hardware assignment which is useful for things like plugging in a flash drive. The network hardware also goes through this process so if the network script doesn’t try to remember which NIC is eth0 and which is eth1 it’s basically a race condition for that assignment. I suspect that a lot of people are actually in this state but don’t realize it because they only configure one of the NICs via Cisco’s script. If you leave eth1 alone, it retains the original network script (which still contains the MAC) and basically eth1 always gets the MAC it wants and eth0 gets “the other one”. Things going poorly without anyone knowing….or at least this is what I suspect.

To fix this neat little issue you’ll want to add HWADDR=11:22:33:44:55:66 (subbing out your appropriate MAC) somewhere in the network config file located at /etc/sysconfig/network-scripts/ifcfg-eth0. The same obviously goes for eth1 and it’s corresponding MAC if you’ve set that up as well. I use a bit of CLI parsing to get that in there without using much effort. It’s probably not as pretty as it could be but it was quick and dirty and works.

[root@MSE /]# echo HWADDR=`ifconfig eth0 | grep -o -E '([[:xdigit:]]{1,2}:){5}[[:xdigit:]]{1,2}'` >> /etc/sysconfig/network-scripts/ifcfg-eth0
[root@MSE /]#
[root@MSE /]# echo HWADDR=`ifconfig eth1 | grep -o -E '([[:xdigit:]]{1,2}:){5}[[:xdigit:]]{1,2}'` >> /etc/sysconfig/network-scripts/ifcfg-eth1
[root@MSE /]#

It’s probably worth checking this just to be sure. Even when copying and pasting things you never know when something went wrong.

[root@MSE /]# cat /etc/sysconfig/network-scripts/ifcfg-eth0
DEVICE=eth0
BOOTPROTO=none
BROADCAST=172.16.30.255
IPADDR=172.16.30.5
NETMASK=255.255.255.0
NETWORK=172.16.30.0
ONBOOT=yes
TYPE=Ethernet
USERCTL=no
HWADDR=00:42:17:D1:B6:14
[root@MSE /]#

Another neat little thing the setup script does is clobber the gateway parameter. Obviously this will be dynamic based on your environment so sub out your appropriate IP for my example.

[root@MSE /]# echo GATEWAY=172.16.30.1 >;>; /etc/sysconfig/network-scripts/ifcfg-eth0
[root@MSE /]#
[root@MSE /]# echo GATEWAY=172.16.50.1 >;>; /etc/sysconfig/network-scripts/ifcfg-eth1
[root@MSE /]#

Let’s check again to make sure things look correct.

[root@CDW-MSE /]# cat /etc/sysconfig/network-scripts/ifcfg-eth0
DEVICE=eth0
BOOTPROTO=none
BROADCAST=172.16.30.255
IPADDR=172.16.30.5
NETMASK=255.255.255.0
NETWORK=172.16.30.0
ONBOOT=yes
TYPE=Ethernet
USERCTL=no
HWADDR=00:42:17:D1:B6:14
GATEWAY=172.16.30.1
[root@CDW-MSE /]#

See this link for a description of this behavior:

Another little interesting gotcha for this problem is that the markings on the server casing don’t actually read eth0 and eth1 but could be listed as GE1 or BMC1. I’ve seen a small paper tag listing the MACs affixed to the back of the MSE which makes it much easier to figure out which is which. Finding the current binding in Linux is as easy as the following.

[root@MSE /]# ifconfig eth0
eth0      Link encap:Ethernet  HWaddr 00:42:17:D1:B6:14
          inet addr:172.16.30.5  Bcast:172.16.30.255  Mask:255.255.255.0
          inet6 addr: fe80::215:17ff:fed0:b444/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:100 errors:0 dropped:0 overruns:0 frame:0
          TX packets:33 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:12386 (12.0 KiB)  TX bytes:2410 (2.3 KiB)
          Base address:0x2000 Memory:e8180000-e81a0000
[root@MSE /]#

After all that is sorted out, I like to restart the network services on the box rather than doing a reboot. This lets me check to see if things are working without possibly putting my NICs back in an unknown state if I messed something up.

[root@MSE /]# network service restart
[root@MSE /]#

If the MSE is unreachable from WCS/NCS make sure the service is running using one or all of these:

[root@MSE /]# /opt/mse/setup/msed status
[root@MSE /]# /opt/mse/setup/msed start
[root@MSE /]# /opt/mse/setup/msed restart

After that you should be good to go.

Some other notes
A lot of the following is found in the Cisco guide, make sure you read that thoroughly. These are just some of the things I see brought up repeatedly and felt worth mentioning.

  • According to Cisco the MSE services are not supported on both interfaces at once. The second interface can be used for heartbeat services but I’m not aware of any other further official use. SSHD should bind to both interfaces so you could use it for remote access.

  • When asked for the hostname during the setup script put in only the hostname and not the FQDN.

  • If you’re starting from scratch and have to download the software from CCO, keep an eye on how you transfer the file over to your MSE. If using an ftp client this should be done in binary mode so avoid ASCII and possibly any sort of auto mode. Binary will copy a stream (bit for bit) so you end up with what you started with. ASCII mode might strip out some characters in the stream for control purposes which will break your file. Description found right here. Alternately consider using something like scp which is typically native in Linux and OSX. I like Winscp for Windows. To decompress and make the file executable:

    gzip -d filename.bin.gz *or* gunzip filename.bin.gz
    chmod 755 filename.bin *or* chmod +x filename.bin