Tag Archives: networking

Linux ethernet bonding

by R.I. Pienaar on 26. Nov, 2004 in Usefull Things

I purchased a IBM BladeCenter for a number of our systems. It is a compact blade system that puts 14 servers in 7U.

My typical server config is a dual P4 3Ghz, 2Gig RAM, 2 x 40 Gb IDE drives and the machines come with a AMI IDE Raid card. The RAID card is very impressive in that it presents the OS with a single SCSI device, much nicer than the Promise cards etc.

Individual servers have dual gigabit Ethernet cards that goes out the back through dual Layer 7 Nortel switches. Obviously I wanted to bond these for high availability and load sharing

Read on for details on how this was done using RedHat Enterprise

First thing to know is that this stuff is in the kernel and there is a good doc in your kernel source tree under Documentation/networking/bonding.txt this has a lot more detail than I am going to provide here.

A virtual network interface gets created, bond0 in my case, this gets done in /etc/modules.conf

alias bond0 bonding
options bond0 miimon=100 mode=balance-rr

The above creates the bond0 interface and sets some options. It will check the MII state of the card every 100 milliseconds for state change notification. It will also use their round robin balancing policy. More on the various options for these and many more in bonding.txt

RedHat’s RC scripts support this bonding configuration without much modification though there aren’t any GUI tool to configure it. RedHat network config gets stored in /etc/sysconfig/network-scripts/ifcfg-int

You need to create a config file for the bond0 interface, ifcfg-bond0

DEVICE=bond0
BOOTPROTO=none
ONBOOT=yes
IPADDR=192.168.70.101
NETMASK=255.255.255.0
NETWORK=192.168.70.0
BROADCAST=192.168.70.255
GATEWAY=192.168.70.1

And for each network card that belongs to this group you need to modify the existing files to look more or less like this:

DEVICE=eth0
BOOTPROTO=none
ONBOOT=yes
TYPE=Ethernet
MASTER=bond0
SLAVE=yes

Once you created these for each of your ethernet cards you can reboot or restart your networking using service network restart and you should see something like this:

bond0     Link encap:Ethernet  HWaddr 00:0D:60:9D:24:68
inet addr:192.168.70.101  Bcast:192.168.70.255 Mask:255.255.255.0
UP BROADCAST RUNNING MASTER MULTICAST  MTU:1500  Metric:1
RX packets:58071 errors:0 dropped:0 overruns:0 frame:0
TX packets:1465 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:4315472 (4.1 Mb)  TX bytes:120360 (117.5 Kb)
eth0      Link encap:Ethernet  HWaddr 00:0D:60:9D:24:68
UP BROADCAST RUNNING SLAVE MULTICAST  MTU:1500  Metric:1
RX packets:26447 errors:0 dropped:0 overruns:0 frame:0
TX packets:1262 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:1992430 (1.9 Mb)  TX bytes:95078 (92.8 Kb)
Interrupt:16
eth1      Link encap:Ethernet  HWaddr 00:0D:60:9D:24:68
UP BROADCAST RUNNING SLAVE MULTICAST  MTU:1500  Metric:1
RX packets:31624 errors:0 dropped:0 overruns:0 frame:0
TX packets:203 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:2323042 (2.2 Mb)  TX bytes:25282 (24.6 Kb)
Interrupt:17

You can tcpdump the individual interfaces to confirm that traffic goes shared between them, weirdly though on my machine my tcpdump on eth0 and eth1 does not show incoming traffic just outgoing, dumping bond0 works a charm though.

To test it I just turned the power off to one of my switch modules, the networking dies for a couple of seconds but soon resumes without a problem. I am sure I could tweak the times a bit but for now this is all I need.

Read full story • Comments { 14 }

TCP Header Analysis

by R.I. Pienaar on 14. Sep, 2004 in Usefull Things

I have been spending a lot of time looking at network dumps of SMPP traffic to assist in debugging some network issues. I was a bit rusty on some of the finer details of all the various TCP packet headers and my reference was at home. Google found an amazing resource on firewall.cx titled Anylising the TCP header.
The document spans 7 sections covering the following:

Section 1: Source & Destination Port Number
Section 2: Sequence & Acknowledgement Numbers
Section 3: Header Length
Section 4: TCP Flag Options
Section 5: Window Size, Checksum & Urgent Pointer
Section 6: TCP Options
Section 7: Data

It is beautifully colorful and well written. Something that can easily be passed on to someone who does not know a lot about networking or as a simple resource to just catch up on forgotten knowledge.
Firewall.cx has huge amounts of very good documentation on it, well worth poking around in for networking people.

Read full story • Comments { 0 }

IPSec Simplified

by R.I. Pienaar on 24. Aug, 2004 in Usefull Things

I am again spending some time figuring out the workings of IPSec, this time I was interested in how to get it all going on PIX machines. While looking for information I came across 2 great articles about IPSec. They provide a simple introduction and were written by Dr. Peter J. Welcher.

IPsec phobia is caused by confusion. To cure that, we need some background information and terminology. Believe me, with a little orientation, this stuff makes a whole lot more sense! By the way, there’s lots of mathematics theory behind all this, but you won’t see it here. After all, you don’t need to know any of that to use IPsec.

It is split across 2 articles: IPSec Simplified and IPSec Simplified – Part 2.
The authors site has a large number of security and network related articles that seem of a very high quality and well worth checking out.

Read full story • Comments { 0 }

Calculating CIDR notation from IP ranges

by R.I. Pienaar on 13. Aug, 2004 in Code

Following from my previous post about blocking some more countries I discovered a bit of a short coming in the code I used to calculate CIDR notation from ranges of IP’s. So a bit of searching on CPAN got me Net::CIDR.

use Net::CIDR;
$range = shift;
print (join(“\n”, Net::CIDR::range2cidr(“$range”)) . “\n” );

This will take any given range of ip address in format a.b.c.d-w.x.y.z and spew out a list of subnets required to cover the whole range:

# ./range2cidr.pl 64.139.147.0-64.139.170.255
64.139.147.0/24
64.139.148.0/22
64.139.152.0/21
64.139.160.0/21
64.139.168.0/23
64.139.170.0/24

So with this I now have hopefully a more accurate set of rules that will not block bits of New Zeeland as well by accident.

Read full story • Comments { 1 }

List of Microsoft TCP/IP Ports

by R.I. Pienaar on 13. Nov, 2003 in Usefull Things

Microsoft has published a list of ports used by its applications in XLS format, very handy for trying to figure out firewall requirements. If the link stops working search for “Port Requirements for Microsoft Windows Server System”

Read full story • Comments { 0 }
« Newer Entries