NetworkManager please, stay away from my docker0

To set a list of unmanaged-devices you can just do the following.

cat >> /etc/NetworkManager/NetworkManager.conf <<EOF

[keyfile]
unmanaged-devices=interface-name:vboxnet0;interface-name:virbr0;interface-name:docker0

EOF

and

sudo nmcli connection reload

Strangely I had to put this in NetworkManager.conf. Using
/etc/NetworkManager/conf.d/20-unmanaged-bridges.conf didn’t work.

Bridge management with iproute2

You can do simple management tasks on linux virtual bridges using iproute2.

While you can’t set STP or showmacs, you can create/delete bridges and add/remove interfaces.

The following commands are the same.

* add bridge

#brctl addbr ipbr0
#ip l a ipbr0 type bridge

* add interface to bridge

#brctl addif ipbr0 eth0
#ip l s eth0 master ipbr0

* remove interface from bridge

#brctl delif ipbr0 eth0
#ip l s eth0 nomaster

* remove bridge

#brctl delbr ipbr0
#ip l d ipbr0 

VIP loves privacy…with arptables!

If you want to hide your cluster vip for some time, you can play with

#ip link set eth3 arp off

But if your vip is on a virtual interface or a secondary ip, #ip link; can’t help you.

You can just

#sudo yum -y install arptables_jf
#arptables  -A IN -d $YOURVIP -j DROP

The syntax mimics iptables, so

#arptables-save ; # list rules
#arptables -F ; # flush rules

ip route cheatsheet – tunnel with assigned interfaces

When creating an ip tunnel (see ip route cheatsheet) you may let linux to find the right routing path between the nodes.

To create a tunnel between two exact ips (eg. one node has more of one ip on the same network) you have to use the `local` options.

ex. with the following configuration

# host1
eth0: 192.168.0.1/16, 192.168.1.1/16
# host2
eth2: 192.168.0.2/16

Just force host1 to use one of the source ip.

#host1
ip tun add tun0 mode ipip remote 192.168.0.2 local 192.168.1.1
# host2
ip tun add tun0 mode ipip remote 192.168.0.1 local 192.168.0.2

routes made easy

The legacy routes configuration on RH-like was ugly and error prone. You had to compile files like the following:

# route-eth0
ADDRESS0=10.10.10.0
NETMASK0=255.255.255.0
GATEWAY0=192.168.0.253
ADDRESS1=172.16.1.0
NETMASK1=255.255.255.0
GATEWAY1=192.168.0.254

You had to preserve enumeration and evaluate netmasks. This was probably due to the usage of route script, which synopsis is

route add -net $ADDRESS0 netmask $NETMASK0 gw $GATEWAY0

The “new” iproute2 suite allows a new format of route files, compatible with the route dumping.

#route-eth0
10.10.10.0/24 via 192.168.0.253 dev eth0
172.16.1.0/26 via 192.168.0.254 dev eth0

At this point it’s easy to create our route-ethX files starting from the #ip route; output.

#ip route list scope global | grep -- eth0 | grep -v 'default' > route-eth0

In this case we filtered out two kind of entries:
* the default gateway, that could be managed via DHCP or other means like /etc/sysconfig/network:GATEWAY
* non global scope routes, like the ones set by #ip; when assigning addresses.
Check

#man ip |less +/rt_scope

Eg.

#ip -4 -o a list eth2; # show the ip
8: eth2    inet 192.168.0.40/26 brd 192.168.0.63 scope global eth2

#ip route | grep eth2 # show all eth2-related routes
192.168.0.0/26 dev eth2  proto kernel  scope link  src 192.168.0.40    #scope link!
10.0.10.0/24 via 192.168.0.1 dev eth2 

ip route cheatsheet – link, address, tunnel

ip route is the new Linux ip and routing management suite.

ip l # list devices
ip l l eth0 # list only one
ip l s eth0 [down|up] # set link status
ip l s eth0 multicast [on|off] # set multicast status

ip a l # list addresses
ip -4 -o a # list just ipv4 addresses
ip a a 192.168.0.1/24 dev eth0 # set an ip
ip a d 192.168.0.1/32 dev eth0 # remove an ip
ip a f dev eth0 # remove all ips from eth0

ip r # list routes
ip r l m 172.23.0.4 # show the route for the given ip

ip ne # list arp table (ipv4 neighbour table)

# create a tunnel between two host
host1: ip tun add tunnel0 mode ipip remote 192.168.0.2
host1: ip a a 10.0.0.1/24 dev tunnel0
host1: ip l s tunnel0 up
host2: ip tun add tunnel0 mode ipip remote 192.168.0.1
host1: ip a a 10.0.0.2/24 dev tunnel0
host2: ip l s tunnel0 up

vconfig off-by-one?

Vlan tagging (aka RFC 802.1q) is a Layer2 protocol enabling more VLAN on a single ethernet connection. It works tagging ethernet frames so that each port accepts only the configured frames.

The vlan id is a 12bit value (from 0 to 4095), and usually network devices use the 4095 value (0xFFF) for the management network.
But the following command gave me an error
# vconfig add eth1 4095

And I discovered that – actually – the last valid VLAN ID is 4094. Here’s a brief discussion on the subject

Enterprisely sending your hostname to DHCP

DHCP protocol supports sending the client host name to the server via the DHCP HOST NAME option.
See RFC2132 appendix and the original
DHCP Vendor Extension at RFC1497

Further info on the option structure is in the bootp documentation:

You can configure it

On debian:
uncomment the ‘send host-name’ directive in /etc/dhcp3/dhclient.conf

In RHEL:
add the following line to the interface with the ip you want to associate

vim /etc/sysconfig/network-scripts/ifcfg-eth0
DHCP_HOSTNAME=your-nice-hostname

Finding real MAC addresses for bonding NICs on RedHat

I spent some time trying to find out the real MAC addresses for all NICs on RedHat AS3 and RedHat 5.3 since the HWADRR entry was deleted on all the ifcfg-ethX original files.

The ifconfig tool displays the real mac for the ACTIVE nic on the bond:

# ifconfig -a|grep HW
bond0     Link encap:Ethernet  HWaddr 00:50:8B:FB:5E:DA
bond1     Link encap:Ethernet  HWaddr 00:02:A5:4E:1F:E2
eth0      Link encap:Ethernet  HWaddr 00:50:8B:FB:5E:DA
eth1      Link encap:Ethernet  HWaddr 00:50:8B:FB:5E:DA
eth2      Link encap:Ethernet  HWaddr 00:02:A5:4E:1F:E2
eth3      Link encap:Ethernet  HWaddr 00:02:A5:4E:1F:E2

ethtool, dmidecode, etc, doesn’t report real MACs.

So the solutions is on these files:

/proc/net/bonding/bond0
/proc/net/bonding/bond1

Indeed:

$ cat /proc/net/bonding/bond0

bonding.c:v2.4.1 (September 15, 2003)
Bonding Mode: fault-tolerance (active-backup)

Currently Active Slave: eth0
MII Status: up
MII Polling Interval (ms): 100
Up Delay (ms): 0
Down Delay (ms): 0
Multicast Mode: active slave only

Slave Interface: eth1
MII Status: up
Link Failure Count: 0
Permanent HW addr: 00:50:8b:fb:5e:db

Slave Interface: eth0
MII Status: up
Link Failure Count: 0
Permanent HW addr: 00:50:8b:fb:5e:da

TCP to UDP: a top-down focus on the differences – I

While writing a simple UDP server, I had the idea to focus on the differences with a TCP one.

The standard TCP Server flow is the following:

  1. create TCP socket()
  2. bind() it to an ip:port address
  3. listen() for incoming connection
  4. accept() them

The 1. is done via a socket(.., STREAM, TCP) system call. Replacing STREAM, TCP with DATAGRAM, UDP, and going thru point 2. to 4. we’ll get the following errors:

  • listen(): Operation not supported
  • accept(): Operation not supported

What happened? Yep, easy: as UDP is a connection-less protocol, we cannot “listen for” or “accept” connection.

While TCP establishes a fixed connection between client and server, an UDP server just gets every single packet which arrives from a client.

You can check this behavior running netcat in udp mode:

#nc -u localhost 12345

This command is successful even if there’s nothing listening on that port: it’s like a cannon ready to fire everything against a castle’s port.

Each time you send something, it fires. And you need to switch it off to “close” it!