Thread: [mpls-linux-general] Debian GNU/Linux MPLS installation problem

SourceForge Headquarters 1320 Columbia Street Suite 310 San Diego, CA 92101 +1 (858) 422-6466

       Hi everybody,

we are trying to install MPLS support on some Linux machines and to get as
many things working as we can; we began with configuring the kernel an test=
ing
the mpls utility using the iproute2 application suite; we chose the Debian
GNU/Linux distribution because we are quite accustomed to it and we can pro=
ceed
much faster with this project.

However we ran into many problems some of which we were able to solve.
I will make quite a detailed presentation of the things we did so far becau=
se
we don't want to miss anything important, in case anyone can help us.

First of all, if anyone has managed to install a functional MPLS support on=
 a
Debian GNU/Linux distribution we kindly ask him/her to tell us the steps th=
at
he/she followed and where we went wrong.

Ok, here it goes.

We used Debian GNU/Linux 3.1 Sarge as our base system. We used the network
install minimal CD available at
http://cdimage.debian.org/debian-cd/3.1_r0a/i386/iso-cd/debian-31r0a-i386-n=
etinst.iso

After the installation, the first thing we had to do was compiling the kern=
el
with MPLS support. We used the latest available patch mpls-linux-1.946a.
We used (as a test) 4 different kernel versions, namely 2.6.9, 2.6.10,
2.6.11.12 and 2.6.12.2.

This is where we ran into some of our problems: only the 2.6.9 version of t=
he
kernel could be successfully patched; these are the links where you can fin=
d
output for the patch applied to the 2.6.9, 2.6.10, 2.6.11.12 and 2.6.12.2 k=
ernel
versions.

2.6.9:          http://atlantis.cs.pub.ro/~razvand/output-2.6.9
2.6.10:         http://atlantis.cs.pub.ro/~razvand/output-2.6.10
2.6.11.12:      http://atlantis.cs.pub.ro/~razvand/output-2.6.11.12
2.6.12.2:       http://atlantis.cs.pub.ro/~razvand/output-2.6.12.2

       Because we didn't want to loose to much time, we chose the 2.6.9
kernel version. We did a
       # make menuconfig
and added all the options presented in the QUICK.START help file.

       Afterwards, we compiled the kernel the Debian way (via make-dpkg)
and created a debian package containing the compiled kernel image. We insta=
lled
the image, restarted the machine and booted the new kernel. Everything went
smoothly. The next step was testing our kernel for MPLS support.
       By the way, we also tried compiling the 2.6.11.12 kernel (even thoug=
h
the patching failed). But, as we anticipated, the mpls files attached in th=
e
net/mpls directory were not compiled within the kernel (due to the fact tha=
t
the Makefile in the net/ directory itself couldn't be patched).

       Back to our 2.6.9 kernel, we browsed to the net/mpls/ directory
and found that the mpls files were indeed compiled and thus inserted in the
new kernel. We were left with testing mpls support inside this new kernel.
As the mplsadm utility is now obsolete, we decided to try the iproute2 with
MPLS patching (in order to use the mpls command).

       We used the RPM source package available at
       http://sourceforge.net/projects/mpls-linux

       Because Debian also has RPM support we could install the iproute2
rpm source package; this contained iproute2-2.6.9 and also various patches.
We patched iproute2 (everything went fine).

       But when we tried to compile it, a lot of compilation errors emerged=
.
All of them were: "_SOME_KIND_OF_VARIABLE_OR_MACRO_ undeclared". We
soon found that the header files mpls.h and gen_spec.h were not present
in /usr/include/linux.
       I don't know why this happened (or maybe this usually happens). So
we copied both files from /usr/src/linux/include/linux to /usr/include/linu=
x.
We also had to install the db library as our system lacked it.
A simple command:
       # apt-get install lidb4.2-dev
solved that problem.

       After that we managed to compile and install all the iproute2 utilit=
ies,
including mpls.

       What we had to do now was test the mpls utility. We used the example
of James Leu located at http://mpls-linux.sourceforge.net/simple.php. We ha=
ve
four computers connected in a network, so there was no problem choosing two
of them to test mpls.
       The command for uml1 went fine. However the fifth one, namely:
               # mpls nhlfe show
lacked the "push gen 10000 set eth0 ipv4 xxx.xxx.xxx.xxx" part
(obviously we were using the eth0 network interface and a private ip addres=
s)
       The next command:
               # ip route show
       clearly showed the new route being added (but we were left with the
missing part from the previous command)

       We moved to the second machine (this is where our problems increase)=
.
The third command:
               # mpls ilm add label gen 10000 labelspace 0
give us "Segmentation fault"
       the next time we try to run it it just blocks and does nothing. We
were left with debugging these problems.

       Although, somehow empirical, we used printing in order to get a grip
of the code flow. Thus we managed to find out exactly where our problems ta=
ke
place.

       I will show the sequence of function call that finally give us
Segmentation fault, and then the sequence that give us the blocking command=
.

       We are referring to the iproute2-2.6.9 patched source code.

segmentation fault:
       mpls/mpls.c
       int main (void) -> do_ilm -> mpls_ilm_modify -> rtnl_talk
       (lib/libnetlink.c) -> status =3D send_msg (rtnl->fd, &msg, 0);
                               this is the line where it cracks :-)

blocking command:
       mpls/mpls.c
       int main (void) -> ll_init_map (&rth1) (lib/ll_map.c) ->
       -> rtnl_dump_filter (lib/libnetlink.c) ->
       -> status =3D recvmsg (rth->fd, &msg, 0);
               this is the line where it blocks

we am not sure if the failure of this command has anything to do with the
failure of the command for uml1 (# mpls nhlfe show - which lacks part of th=
e
message)

to make matter worse, we think the problem may affect the kernel; after the
segmentation fault message, any attempt to shut down or reboot the machine
will end up in a block with the following message:
       Deactivating swap ... umount: tmps busy
       - remounted read-only
       done.
       unmounting local filesystems ... umount:
       tmpfs busy - remounted read only
       umount: /: device is busy
       done.
       mount: / is busy
       Rebooting ...

       right here it hangs (have to restart it manually)

       Many other thing stop working actually, so the problem may
affect the kernel
a bit more.

       We are sorry for the long message, but we wanted to show in detail
everything we have done so that it may be easier for others to spot the pro=
blem
and help us.

Thank you very much,
Razvan & Dorin