Calgary RHCE

A linux and open source technology blog.

Connect

Calgary OpenStack and other Meetup.com groups

By Leave a Comment

I’m a little late on this post, but last week we had an excellent presentation on OpenStack installers. Specifically, TripleO. Chris J from Red Hat gave us a good outline of TripleO’s capabilities, and kept it pretty upstream. For the presentation slide deck, see here. The group tries to keep it as vendor neutral as possible which is nice. There were a lot of questions and feedback, this is probably a topic worth going into in a little more detail, or perhaps doing some hackfest demo’ing!

Triple O by Chris J.

There’s been quite an uptick in our local OpenStack meetup group lately, it’s been fun to see and get involved with. Both this group, as well as our Red Hat User Group has brought in some high profile and very talented open source folks who’ve presented and shared their knowledge with us.

The OpenStack meetup groups across Canada have come together and created a Slack channel for easier communication and sharing among its members. If you’re interested in joining the channel, drop a comment or send me an email for an invite!

Network teaming in RHEL7

By Leave a Comment

If you’ve adopted or are just starting to read up on the new features included in Red Hat Enterprise Linux 7, you may have come across the new networking feature called teaming. It essentially is a replacement for bonding that offers more modularity, increased link monitoring features, higher network performance, and easier management of interfaces.

Habitually, network interface configuration is something I’m used to setting up once, and forgetting about it. I don’t usually re-visit my networking configuration unless some hardware changes, or I need to re-IP a system. With the advancement of SDN, this might change in the not-so-distant future, so I thought I’d give teaming a try. And hey, if it offers even marginally greater performance, why not get the most out of my OS?

I first started with reading a comparison of Network Bonding to Network Teaming, and the new network teaming daemon “teamd”, with it’s concept of “runners”. Network teaming has basically assigned a daemon to a link aggregate that allows management and monitoring of that interface through the daemon. I guess this is similar to systemd modularizing init scripts, we’ve got a daemon wrapper that will manage the config files for us in a programmatic way. After going through the docs, I found it pretty easy to get this setup and running. If you’re lazy (read efficient) like me, there’s adequate example configs in /usr/share/doc/teamd*/example-ifcfgs/ that are easily modified (there’s one for LACP).

On one of my hypervisors, I’ve got 2 NICs, an LACP bond (will be replaced by an LACP team), and a bridge device. My new interface configs look like this:

The only real differences between bonding and teaming as far the config files are concerned is that there’s new device types called “TeamPort”, and “Team”, and then inside the team config there’s a JSON formatted entry that replaces the traditional bonding options. In here you define the runner (or method of link management) you want for your slave ports, the link monitoring tool, and which interfaces are slaves (ports) of the team. You can use the same bridge options with the team as you did the bond, that doesn’t change. One important rule to note though, bringing up the team interface won’t also bring up the slave interfaces, and in order to add slaves to a team, the slaves need to be in a link down state prior to addition to the team. This is the reason my ONBOOT=no for the NICs, and when systemd brings up the network, it will add the downed slaves to the team, then link up the slaves, then link up the team. I guess this is the modularity intent, let the slaves be managed on their own, then manage the team based on the slave behaviour.

After modifying my files as above, restarting the network service, waiting a few seconds for LACP negotiation to occur, my team is up and running. You can use the new teamdctl command to query and control the interfaces:

Nice! That was less daunting than I thought it might be. The team driver also has good integration with NetworkManager, should you chose to manage your team interfaces with the GUI.

Some others have done comparison benchmarking of bonding vs teaming. Although probably quite marginal for my use-case, the benchmarking shows additional bandwidth throughput, with reduced CPU load.

Home lab switch replacement

By Leave a Comment

A few years back, I purged nearly all of my computer components that were kicking around the house, thus essentially abandoning my home lab. I had learned what I needed to with it, and had enough equipment at work to get done what I needed, so off it went. Old PCs, switches, cables, parts, etc. were all sold off, and it felt good to finally declutter. Fast forward a few years and I find myself with a different job, tackling different problems, new technology is out and the need to invest in a home lab has become important again. When I was looking at routers/switches, mikrotik came up and looked like a good option – pretty feature full and open source. I bought a couple of these, and later found out the LACP implementation had some limitations. This didn’t matter much until recently when I’ve began using 30+ VMs on a hypervisor. After some light research, and a helpful /r/homelab community, I decided on a Dell PowerConnect 6224 from ebay.

The Dell’s are pretty feature-full as well, and their OS has been modeled after Cisco’s. I’ve done work with Cisco gear in the past, so that was a good fit for me and a chance to get my hands dirty in networking again. I found a good deal from Geekfurb and spent this weekend setting it up.

When I first turned it on, it was quite a bit louder than expected. Certainly too loud to sit in the same room with. I got a few replacement fans, which managed to reduce the noise considerably from about 40 dBA, to about 18 dBA. Luckily I did some googling before replacing the fans as I ran into a known issue with the fan wiring. Dell has a different wire sequence in their fans, so you’ll want to watch this youtube video when replacing them. Because my fans are 4.53 CFM and the OEM ones were 7.5 CFM, I’ve got a red fan status light on my switch. I think the lower RPM is throwing it off. All my fans work, and the switch powers on and passes diagnostics just fine. Here’s a before and after sound comparison for the replacement:

Before:

After:

Much better. Even with three fans at 18 dBA each, it’s much quieter than before, and is easy to be in the same room as. As for connections, this switch has the old DB9 serial port on it, instead of the RJ45 management port. For clarity sake, there’s a couple ways network switches can be connected to. The older variety of gear will use the DB9 male serial port, which you’ll need a null modem cable and likely a DB9 to USB converter cable to use with a modern laptop. The newer variety of gear will have the RJ45 management port on the switch, which you’ll need a DB9 to RJ45 cross-over cable, and also DB9 to USB converter. Unless you’re using an old enough PC/laptop that has a serial port. Here’s what they look like:

db9 null modem cabledb9 to usb convertercisco db9 male to RJ45

 

 

 

 

 

 

And the rear of the switch:

dell switch serial port

 

 

 

 

You can use any terminal emulator software to connect to the switch. Putty is a popular option that’s easy to use, there’s a package available for linux. In my case, the serial tty I’m using comes up as /dev/ttyUSB0. After I connect through that to the switch, I reset it to factory settings from the boot menu, and went to work. The main configuration I’m after is setting up link aggregation groups, and configuring the switch ports:

With that work done, on each hypervisor I’ve created a linux bond with the two NICs, then a linux bridge on top of that for attaching virtual networks. The detailed steps are here, but this is what it looks like:

linux bond with bridge

All finished! Testing with iperf shows I’m getting close to line speed on the interfaces (~940 Mbit on 1 Gigabit NICs), so the setup is correct. To really test the aggregate bandwidth I’ll have to simulate multiple simultaneous connections. I’ll leave that for another day. Perhaps let this sit for a while and attach some switch statistics to back up the bandwidth numbers. All in all, for less than $150 I’ve finally got all my lab systems setup with LACP.