Using vconfig to set vlan tagged interface with 802.1p CoS priority bits set

tux This is just quick how-to on setting up vlan interface on a Linux system. As this is in lengths described elsewhere I will stick just to the commands and brief explanations.

The first thing to do is to get the “vlan” package as it is not normally installed. The other bit is the 8021q kernel module which is not normally loaded but is present on Debian-based systems by defualt.

Checking the state of the module:

lsmod | grep 8021q

if this will return empty result you must load the module using mordprobe

modprobe 8021q

and verify again with lsmod as before.

Now the system is ready to get new tagged interfaces

vconfig add eth0 X

Where eth0 is your physical interface and X is the VLAN ID you want the new interface to be tagged with. The command will have an output saying that interface eth0.X has been created. This is great but you also must now somehow specify what pbit setting do you want in there as by default egress traffic is by default priority 0. In order to make lets say ping ICMP packets marked with CoS we must create an egress map for the default priority (o) in which we will re-map it to whatever we want.

vconfig set_egress_map eth0.X 0 7

In this example I have re-mapped the default priority 0 to egress priority 7

This setup can be made permanent by adding the module name in /etc/modules and adding the relevant lines in the interfaces file e.g.:

auto eth0.100
iface eth0.100 inet static
vlan-raw-device eth0


Multiple permanent linux interfaces with dhcp allocated addresses

tuxRecently I have been doing some on the HP 5500EI including a port security feature limiting the number of MAC addresses to 8. This is not a difficult configuration at all – in fact it is just one command on the interface itself .

mac-address max-mac-count 5

So now with the limit in place I would like to test it. The first thought was to use Linux alias as a fast and dirty way of doing this but unfortunately I soon found out that tit doesn’t allow for the requirements I had in mind.

  • There have to be 5 or more virtual interfaces on one physical interface
  • Each virtual interface must have its own individual MAC address
  • All virtual interfaces must be getting their own IP addresses from the DHCP server
  • All the virtual interfaces must receive an IP address from the same subnet (as they as plugged into an access port)

The main issue with just aliasing the interface is that it is a L3 interface only (uses the same MAC) and definitely doesn’t allow for DHCP allocations from the same subnet. But fortunately on Linux this is not an issue and this can be done via “ip link” feature which is part of the iproute package in Debian. The usage is rather simple:

ip link add dev intX link eth0 type macvlan
ip link del dev intX link eth0 type macvlan

Where int will be name and X the number of the new interface and eth0 is the physical interface you want to bind to. This can be repeated multiple times and the MAC address will be generated randomly. There is also a way for setting it up to whatever you want by changing the syntax to this:

ip link add dev intX link eth0 address aa:aa:aa:aa:aa:aa type macvlan

If you run this couple times and get some IP addresses on those interfaces from DHCP server you will soon notice the following messages on your switches.

%Jun 7 11:03:01:411 2000 Core1 ARP/5/ARP_DUPLICATE_IPADDR_DETECT: Detected an IP address conflict.
The device with MAC address 6e99-1b38-2b8c connected to Bridge-Aggregation2 in VLAN 100 and the device with MAC address d6b2-1ac8-9bd2 connected to Bridge-Aggregation2 in VLAN 100 are using the same IP address

Quick check will reveal that there are no duplicate addresses assigned nor allocated so what is the system complaining about? The answer is that the defaul behavior of linux kernel is that it will repli to ARP from the first interface in the list (eth0) also it can reply from all interfaces /and or random interface making the Comware go crazy.

Fortunately this default behavior can be adjusted by the following commands:

echo 1 > /proc/sys/net/ipv4/conf/eth0/arp_ignore
echo 8 > /proc/sys/net/ipv4/conf/eth0/arp_announce

There has been a lot of people around the net suggesting the second value should be 5 but that didn’t work for me at all. If you want to make these changes persistent add the line with the values into /etc/sysctl.conf

There is some more explanation of the values above here

How to test IPv6 with iperf

logo-ianaLately there has been yet again a big surge of interest in IPv6 and I did find to my surprise that even thought IPerf supports IPv6 for quite some time no-one actually has written how to actually do this rather trivial test.
First thing about IPv6 is that your interface on the end-point PCs will auto-assign a link-local address to itself. The link local address is in fe80::macaddress format (where one bit of the mac address can be changed depending on the implementation). So this looks fine – no problems. You should be able to ping between those ip addresses using ipv6 ping. so lets try to ping localhost’s ipv6 link-local address. In order to do this you need to specify the interface you are using as ping can’t lookup the address automatically as it can with IPv4.

$ ping -I eth0 fe80::7983:2bdc:4a2a:61b9
Pinging fe80::7983:2bdc:4a2a:61b9 with 32 bytes of data:
Reply from fe80::7983:2bdc:4a2a:61b9: time < 1ms
Reply from fe80::7983:2bdc:4a2a:61b9: time < 1ms
Reply from fe80::7983:2bdc:4a2a:61b9: time < 1ms
Reply from fe80::7983:2bdc:4a2a:61b9: time < 1ms

Ping statistics for fe80::7983:2bdc:4a2a:61b9:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 0ms, Maximum = 0ms, Average = 0ms

OK so far so good – lets assign a public ip address to the eth0 interface as unfortunately we cannot use the link-local addresses for anything except ping. This is very important to note – as iperf will not work over link-local addresses (starting with fe80:). the testing machines I was using are running debian stable so the assignment of ip addresses is linux-style (but I think widows PCs would do the same thing through the GUI somehow).

$ ifconfig eth0 inet6 2012::1/64 up

Interesting thing to note that you need to specify the “inet6” ip address as ifconfig is not smart enough to recognize the IP address family from its syntax.
The next thing to do is obviously to bring the other PC’s interface up. So as before:

$ ifconfig eth0 inet6 2012::2/64 up

Yet again check the connectivity with ping:

$ ping -I eth0 2012::2
Pinging 2012::2 with 32 bytes of data:
Reply from 2012::2: time < 1ms
Reply from 2012::2: time < 1ms
Reply from 2012::2: time < 1ms
Reply from 2012::2: time < 1ms

Ping statistics for 2012::2:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 1ms, Maximum = 1ms, Average = 1ms

Ok now we have a working connectivity over IPv6 so the last step is to actually configure and run iperf. The one thing to remember is to use -V switch which sets iperf to IPv6 mode. All the remaining parameters are used as in IPv4.

Server side:
iperf -V -s -u -B 2012::2

-s is for server, -u for udp, -B bind to specific, IP -V for IPv6

The Client side:
iperf -u -t 30 -i 1 -V -c 2012::2 -b 5M
-c is for client, -u for udp, -V for IPv6,t for 30 seconds duration, -i for 1 second reporting interval, -b 5M for 5mbps of test traffic

Well obviously you can tweak the parameters as much as you want and I haven’t noticed any significant difference in behavior between IPv4 and IPv6 iperf (and that includes dual test and TCP instead of UDP).

Prolific USB-to-serial on debian sid howto

As it happens over the time I came across a situation where I was using a Linux machine to connect to some networking boxes. Unfortunately the fact was that the only serial connection available was my personal usb-to-serial cable which I have bought quite some time ago and which was a major pain in the behind to make work under windows 7 64bit. Well long story short making it work under Debian was almost as “happy” and painful experience.

To start with there is enough information all around the Internet but the problems are as usually inconsistency and some Debian specifics. So let us have a look on the pre-requisities for this small exercise. My machine was running Debian Sid/Wheezy with 2.6.32 kernel but it works with the 2.6.38 as well and will probably work wit almost anything. The reason why I am mentioning this is that the first thing you need to find out is if you have the proper driver.  The way to see that is your driver type/make etc. you would need to plug it in and search in the dmessages (dunning the dmesg command) or in the messages file located in /var/log/messages.

May 16 22:26:26 Hell kernel: [ 351.649316] usb 2-1.3: new full speed USB device using ehci_hcd and address 3
May 16 22:26:26 Hell kernel: [ 351.742481] usb 2-1.3: New USB device found, idVendor=067b, idProduct=2303
May 16 22:26:26 Hell kernel: [ 351.742488] usb 2-1.3: New USB device strings: Mfr=1, Product=2, SerialNumber=0
May 16 22:26:26 Hell kernel: [ 351.742494] usb 2-1.3: Product: USB-Serial Controller D
May 16 22:26:26 Hell kernel: [ 351.742498] usb 2-1.3: Manufacturer: Prolific Technology Inc.
May 16 22:26:26 Hell kernel: [ 351.830383] USB Serial support registered for pl2303
May 16 22:26:26 Hell kernel: [ 351.830418] pl2303 2-1.3:1.0: pl2303 converter detected
May 16 22:26:26 Hell kernel: [ 351.831987] usbcore: registered new interface driver pl2303
May 16 22:26:26 Hell kernel: [ 351.831990] pl2303: Prolific PL2303 USB to serial adaptor driver

As it happens in my case the usb-toserial reduction is the pl2303 and the driver included in the Debian stock kernel which is nice but not sufficient for anything to work. Now there are two possible things that might have happened when you plug the USB connector in. Either the module has been recognized an loaded automatically or you would need to load it manually (it depends on your udev configuration). The command to find out if the module is loaded already is this:

$ modprobe -l | grep pl2303

As it is obvious that we do work on rather low level of the OS I don’t think that reminding the necessity of being logged in as a root is really needed. If the returned result is empty then the module has not been loaded. In which case it is necessary  to load it manually with the following command:

$ modprobe pl2303

and then verify

$ lsmod | grep pl2303

If the result is satisfactory and the module is loaded the next step is to verify that the proper device in the /dev directory has been created. This is a point where various tutorials will claim different things as this is one of the distribution-and-version-specific things. Anyway in the system I’ve described above the file is under /dev/ttyUSB0 Again this might and probably will be different on different systems. You can find what device has been created by the same means as you’ve used for finding out of the driver options – with dmesg command or in the /var/log/messages file

May 16 22:26:26 Hell kernel: [ 351.831964] usb 2-1.3: pl2303 converter now attached to ttyUSB0

Once you find out the what is the device created by udev you’ll need to change two things. If you want to use the console as unprivileged user you need to add this user to the group “dialout” the second and actually more important thing is to change the group ownership of the device file in /dev The reason behind this is that all hardware is by default owned by root and the group root unless specified otherwise. that is fairly good point as normal users don’t normally have the need to access the hardware directly except for few cases and this i exactly one of those.

So the final ownership is owner:root group:dialout

root@Hell:/dev# ls -lah ./tty0
crw-rw-rw- 1 root dialout 4, 0 Jun 11 21:07 ./ttyUSB0

The last step in connecting to the remote system. As in this instance the logic is the same as with dialed connection we need some small software to handle in my case I picked the “cu” software which behaves best amongst those I’ve tested. As the package is in the standard repository you can use the

$ apt-get install cu

or if you think that it might be already installed just try

$ dpkg -l cu

which will give you the following result

$ dpkg -l cu
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name Version Description
ii cu 1.07-20 call up another system

So the last step is to use cu to connect to the device. This can be achieved by

cu -s 9600 -l /dev/ttyUSB0

Where -s parameter is obviously for speed in bauds and th -l parameter is for the line interface.
After this you should be able to communicate with the networking device. Hope this was helpful – I believe I will enhance this article but as t quick & dirty howto it should be all right.