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.
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
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
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
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 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
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
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
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
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:
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:
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!