Calgary RHCE

A linux and open source technology blog.

Connect

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.

Motivating Employees and Strategies of Influence

By Leave a Comment

I know, I know. Another management topic. Haven’t we heard enough leadership buzzwords? Seen enough trendy motivational topics? Like probably most of you, I dread the elevator pitch of anyone about to give me a spiel on the latest and greatest industry buzzword topic. Especially if all they did was read an article on LinkedIn. And especially if it’s about DevOps. But! Hear me out. This one resonated deeply for me, so I think (and hope!) you’ll relate to this one. This information is taken from a book on the subject, “Developing Management Skills”, by David A. Whetten, and Kim S. Cameron.

In a project management class I’m taking, the professor refers to Principles of Influence and describes them as the guiding fundamentals in which people consider when deciding whether or not to be influenced by another person. Further to that are the Strategies of Influence, based on these principles, that one can take when looking to influence others around them. For most of us, this occurs in our working lives. Let me list them here, I think they’ll make more sense once you read them. The Strategies of Influence are:

  • Retribution (based on fear or threats of what the influencer can withhold from you or punish you with. Intimidation, coercion, etc.)
  • Rationality (based on persuasion and logical thought formed from facts or appeals to personal values)
  • Reciprocity (based on mutual exchange or offerings between you and the influencer)

Where do these apply? Well, when one enters a situation where they need to influence somebody to act, one must decide which of the three influence strategies they will use. Now, why should you care? You should care because these strategies are being used in your business today, and there are situations where each of them are most effective, and also exceptionally ineffective. Depending on your business environment and your task at hand, one strategy may offer far more than the other two. As employees and managers who are constantly pressured to do more with less, I believe it is our duty to understand the strategies in order to identify which one is most appropriate for the situation at hand or possibly for the particular business environment that you’re in. Taken from a PDF of the book, these tables provide examples and summarize the pros and cons to each strategy:

Example strategies:

"Developing Management Strategies", David A. Whetten, and Kim S. Cameron. pg 325
“Developing Management Strategies”, David A. Whetten, and Kim S. Cameron. pg 325

Pros/Cons:

"Developing Management Strategies", David A. Whetten, and Kim S. Cameron. pg 323
“Developing Management Strategies”, David A. Whetten, and Kim S. Cameron. pg 323

These influence strategies manifest from managerial preferences, and are shaped and influenced by corporate culture.  Personally, I do my best work and am most effective when the rationality strategy is used. Occasionally, reciprocity and retribution are effective, but aren’t sustainable long-term due to the need to maintain respectful relationships with colleagues and co-workers. If I were to quantify the most effective balance of the strategies for my business environment, I’d say it would be 80% rationality, 5% retribution, and 15% reciprocity.

The reason I think this is so interesting is that the rationality strategy is relied upon heavily in open source, and is fundamental to effective mass collaboration. Decision making may take a little longer, however the quality of decisions are often much higher compared to the other strategies. That being said, the retribution strategy is relied upon heavily in the military, and is very effective in that quick, direct action environment. Additionally, reciprocity is vital in a political environment where parties are heavily mutually dependent and compromises need to be made.

Consider the situation or environment you are in today:

  • Are any of these strategies present in your organization or reporting structure?
  • Can you think of examples where they have been effective or ineffective?
  • Which one inspires you to do your best work?