mpls-linux-general — Mailing list for general discussion about MPLS for Linux

Re: [mpls-linux-general] LDP-Linux with Redhat 7.1

[JK S. <ks...@ve...>]

Hi James,
I have tried the way U have suggested but still the problem persists. i.e I am not able
to see any labels formed in /proc/net/mpls_* files.

Would U like to comment on this again.......
Thankx ....

Regards
--jkswamy


"James R. Leu" wrote:

> The real problem is that your /usr/include/linux|asm do not point to your
> current kernel source.
>
> cd /usr/include/
> mv linux linux.rehdat
> mv asm asm.redhat
> ln -s /usr/src/linux/include/linux/
> ln -s /usr/src/linux/include/asm/
>
> Also make sure to update your CVS tree,  I commit some changes 2 days ago.
>
> Jim
>
> On Wed, Jul 11, 2001 at 05:06:19PM +0530, JK Swamy wrote:
> > Hi all,
> > I have complied LDP-linux making a small change in the "Makefile" ie by incerting
> > -I/usr/src/linux/include . Also note that I was on Redhat 7.0 and with kernel
> > 2.4.5.
> > I configured two machies as given in ../linux-port/README.sample.
> > I could get labels in /proc/net/mpls_in and/proc/net/mpls_out. Label Distribution
> > was demonstrated.
> >
> > But when I did exactly the same on Redhat 7.1  , I get a compilation error that
> > " In LDP_Linux.c there is a implicit declaration of the method is blank. " and so
> > Ldp_Linux.o file is not formed. To overcome that I changed "isblank" to  "isspace"
> > in LDP_Linux.c file.  After this "ldp_linux" binary was formed.
> >
> > I configured two machies as given in ../linux-port/README.sample.
> > when I
> > bash# cat /proc/net/mpls_in
> > bash# cat /proc/net/mpls_out
> >
> > Files are empty .......
> >
> >
> >
> > U may please tell me the following:
> > 1. Is there any need to change or modify Makefile while compiling.
> > 2. What other changes I need to make to suit Redhat 7.1 linux.
> >
> > Anticipating Ur early reply.
> > Thankx ..
> >
> > Cheers ! !
> > --jkswamy
> >
> >
> >
> > --------------------------------------------------------------
> > Velankani Information Systems Ltd, Bangalore, India
> >
> >
> >
> > _______________________________________________
> > mpls-linux-general mailing list
> > mpl...@li...
> > http://lists.sourceforge.net/lists/listinfo/mpls-linux-general
>
> --
> James R. Leu

--
***********************************************************************

Krishna Swamy J
Senior Telecom Consultant
Velankani Information Systems

***********************************************************************




--------------------------------------------------------------
Velankani Information Systems Ltd, Bangalore, India

[mpls-linux-general] (no subject)

[Kent D. <ke...@pr...>]

confirm 703805

Re: [mpls-linux-general] LDP-Linux with Redhat 7.1

[James R. L. <jl...@mi...>]

The real problem is that your /usr/include/linux|asm do not point to your
current kernel source.

cd /usr/include/
mv linux linux.rehdat
mv asm asm.redhat
ln -s /usr/src/linux/include/linux/
ln -s /usr/src/linux/include/asm/

Also make sure to update your CVS tree,  I commit some changes 2 days ago.

Jim

On Wed, Jul 11, 2001 at 05:06:19PM +0530, JK Swamy wrote:
> Hi all,
> I have complied LDP-linux making a small change in the "Makefile" ie by incerting
> -I/usr/src/linux/include . Also note that I was on Redhat 7.0 and with kernel
> 2.4.5.
> I configured two machies as given in ../linux-port/README.sample.
> I could get labels in /proc/net/mpls_in and/proc/net/mpls_out. Label Distribution
> was demonstrated.
> 
> But when I did exactly the same on Redhat 7.1  , I get a compilation error that
> " In LDP_Linux.c there is a implicit declaration of the method is blank. " and so
> Ldp_Linux.o file is not formed. To overcome that I changed "isblank" to  "isspace"
> in LDP_Linux.c file.  After this "ldp_linux" binary was formed.
> 
> I configured two machies as given in ../linux-port/README.sample.
> when I
> bash# cat /proc/net/mpls_in
> bash# cat /proc/net/mpls_out
> 
> Files are empty .......
> 
> 
> 
> U may please tell me the following:
> 1. Is there any need to change or modify Makefile while compiling.
> 2. What other changes I need to make to suit Redhat 7.1 linux.
> 
> Anticipating Ur early reply.
> Thankx ..
> 
> Cheers ! !
> --jkswamy
> 
> 
> 
> --------------------------------------------------------------
> Velankani Information Systems Ltd, Bangalore, India
> 
> 
> 
> _______________________________________________
> mpls-linux-general mailing list
> mpl...@li...
> http://lists.sourceforge.net/lists/listinfo/mpls-linux-general

-- 
James R. Leu

[mpls-linux-general] LDP-Linux with Redhat 7.1

[JK S. <ks...@ve...>]

Hi all,
I have complied LDP-linux making a small change in the "Makefile" ie by incerting
-I/usr/src/linux/include . Also note that I was on Redhat 7.0 and with kernel
2.4.5.
I configured two machies as given in ../linux-port/README.sample.
I could get labels in /proc/net/mpls_in and/proc/net/mpls_out. Label Distribution
was demonstrated.

But when I did exactly the same on Redhat 7.1  , I get a compilation error that
" In LDP_Linux.c there is a implicit declaration of the method is blank. " and so
Ldp_Linux.o file is not formed. To overcome that I changed "isblank" to  "isspace"
in LDP_Linux.c file.  After this "ldp_linux" binary was formed.

I configured two machies as given in ../linux-port/README.sample.
when I
bash# cat /proc/net/mpls_in
bash# cat /proc/net/mpls_out

Files are empty .......



U may please tell me the following:
1. Is there any need to change or modify Makefile while compiling.
2. What other changes I need to make to suit Redhat 7.1 linux.

Anticipating Ur early reply.
Thankx ..

Cheers ! !
--jkswamy



--------------------------------------------------------------
Velankani Information Systems Ltd, Bangalore, India

[mpls-linux-general] LDP-linux

[JK S. <ks...@ve...>]

Hi James,
I have Configured and installed LDP-linux. For label space assignment I am using "
mplsadm -L eth0:0 ". I have seen one of Ur mails stating that U have a kernel
patch from Erricsson to substitute this. Can U give me the URL or the ftp site to
download.

Thankx..
--jkswamy




--------------------------------------------------------------
Velankani Information Systems Ltd, Bangalore, India

[mpls-linux-general] mpls build with 2.4.6 kernel

[Peter B. <pet...@du...>]

Hi,

Hit a small problem building mpls-linux-0.993 with a 2.4.6 kernel. It seems
that the ARP hardware identifier used in the mpls patch, ARPHRD_MPLS_TUNNEL
= 801 has now been assigned to ARPHRD_IEEE80211 (is that wireless LAN or
something?).

I'm not sure how these dummy type numbers are arrived at - I suspect they
are somewhat arbitrary. I just changed the mpls one to 802 and hoped for the
best.

Peter.
----------------------------------------------------------------------------
----------
Peter Baxendale                                 University of Durham
pet...@du...          School of Engineering
fax +44 191 374 3838                        South Road
tel +44 191 374 3822                        Durham DH1 3LE
                                                          England
----------------------------------------------------------------------------
---------

[mpls-linux-general] Catching Vpn traffic

[Geoff D. <ge...@ci...>]

Hi all

I have been wondering if linux with MPLS is the right solution for what
I am trying to do.
Is it possible to have a linux box sit between two Cisco in the typical
Core - Access split . and have it read into the labels  when traffic
travels from the access router  to the Core router  and see that this
packet is part of a particular VPN.

based on this what I am trying to ask is if it is possible to have
Tc(iproute2) do some shaping based on extended community of the MPLS
packet or some other means that it will know that a particular packet is
part of a certain VPN

Any ideas or pointers to help create a means to manage CAR would be a
great help

Kind Regards
Geoff




.

[mpls-linux-general] MPLS on RTOS

[JK S. <ks...@ve...>]

Hi all,
I could configure and run MPLS on Linux. But now my project demands that I
need to port MPLS on an Embedded PowerPC target with ECOS Real Time
Operating System on it.
Can U tell me what I need to do ? Are there any MPLS implementation to suit
my requirment.

Cheers ! !
--jkswamy
*************************************************************
J.Krishna Swamy
Sr.Telecom Consultant
Velankani Information Systems
ks...@ve...
************************************************************



--------------------------------------------------------------
Velankani Information Systems Ltd, Bangalore, India

Re: [mpls-linux-general] ldp_linux problem

[James R. L. <jl...@mi...>]

Hello,

Are you using ldp-portable from CVS?

If so, then I need more info to debug further. I need the ouput of the 'show'
commands, and the output from ldp_linux on the LSR with 'set trace 0xffffffff'.

Jim

On Mon, Jul 09, 2001 at 09:36:39AM -0400, Yvan Pointurier wrote:
> Hi,
> 
> I tried ldp_linux on my testbed with 3 routers (2 LERs + 1 LSR) but I got
> a problem with the LSR.
> 
> Topology:
> (networks 10.0.a.0 with netmask 255.255.255.0 for each subnet 10.0.a.0)
> 
> Host1 eth1---eth1 LERA eth2---eth2 LSR eth3---eth3 LERB eth4---eth4 Host2
>        1.1    1.2       2.1    2.2      3.1    3.2       4.1    4.2
> 
> 
> The problem is that there is no label swapping at the LSR on packets from
> LER B to LER A. The LSR swaps labels correctly for packets from LER A to
> LER B:
> 
> (ping from LER A to LER B with route recording on)
> $ ping -R -c1 10.0.4.2
> PING 10.0.4.2 (10.0.4.2) from 10.0.1.1 : 56(124) bytes of data.
> 64 bytes from 10.0.4.2: icmp_seq=0 ttl=253 time=0.5 ms
> RR:     10.0.1.1
>         10.0.2.1
>         10.0.3.1   --> due to no label swapping by the LSR
>         10.0.4.1
>         10.0.4.2
>         10.0.4.2
>         10.0.3.2   --> 10.0.2.2 is absent (expected)
>         10.0.1.2
>         10.0.1.1
> 
> contents of /proc/net/mpls_*:
> * on LER A
> 
> LABELSPACE:
> eth2    0
> 
> FEC:
> 40004804 10.0.3.0/24
> 40004c04 10.0.4.0/24
> 
> TUNNEL:
> 
> IN:
> 40004000 gen 16 0 POP DLV
> 40004400 gen 17 0 POP DLV
> 40004800 gen 18 0 POP DLV
> 40004c00 gen 19 0 POP DLV
> 40005000 gen 20 0 POP DLV
> 
> OUT:
> 40004804 PUSH(gen 18) SET(eth2)
> 40004c04 PUSH(gen 19) SET(eth2)
> 
> * on LSR
> 
> LABELSPACE:
> eth2    0
> eth3    0
> 
> FEC:
> 40004404 10.0.1.0/24
> 40004805 10.0.4.0/24
> 
> TUNNEL:
> 
> IN:
> 40004000 gen 16 0 POP DLV
> 40004400 gen 17 0 POP DLV
> 40004800 gen 18 0 POP DLV
> 40004c00 gen 19 0 POP DLV
> 40005000 gen 20 0 POP DLV
> 40005400 gen 21 0 POP DLV
> 40005800 gen 22 0 POP DLV
> 40005c00 gen 23 0 POP FWD(40004404)
> 40006000 gen 24 0 POP DLV
> 40006400 gen 25 0 POP DLV
> 40006800 gen 26 0 POP DLV
> 40006c00 gen 27 0 POP DLV
> 
> OUT:
> 40004404 PUSH(gen 17) SET(eth2)
> 40004805 PUSH(gen 18) SET(eth3)
> 
> * On LER B
> 
> LABELSPACE:
> eth3    0
> 
> FEC:
> 40005c05 10.0.1.0/24
> 40006005 10.0.2.0/24
> 
> TUNNEL:
> 
> IN:
> 40004000 gen 16 0 POP DLV
> 40004400 gen 17 0 POP DLV
> 40004800 gen 18 0 POP DLV
> 40004c00 gen 19 0 POP DLV
> 40005000 gen 20 0 POP DLV
> 
> OUT:
> 40005c05 PUSH(gen 23) SET(eth3)
> 40006005 PUSH(gen 24) SET(eth3)
> 
> 
> Routing tables (only the information about subnets 10.0.x.0 is relevant):
> LER A
> $ route
> Kernel IP routing table
> Destination     Gateway         Genmask         Flags Metric Iface
> 10.0.4.0        10.0.2.2        255.255.255.0   UG    0      eth2
> 10.0.1.0        *               255.255.255.0   U     0      eth1
> 10.0.2.0        *               255.255.255.0   U     0      eth2
> 10.0.3.0        10.0.2.2        255.255.255.0   UG    0      eth2
> 
> LSR
> $ route
> Kernel IP routing table
> Destination     Gateway         Genmask         Flags Metric Iface
> 10.0.4.0        10.0.3.2        255.255.255.0   UG    0      eth3
> 10.0.1.0        10.0.2.1        255.255.255.0   UG    0      eth2
> 10.0.2.0        *               255.255.255.0   U     0      eth2
> 10.0.3.0        *               255.255.255.0   U     0      eth3
> 
> LER B
> Kernel IP routing table
> Destination     Gateway         Genmask         Flags Metric Iface
> 10.0.4.0        *               255.255.255.0   U     0      eth4
> 10.0.1.0        10.0.3.1        255.255.255.0   UG    0      eth3
> 10.0.2.0        10.0.3.1        255.255.255.0   UG    0      eth3
> 10.0.3.0        *               255.255.255.0   U     0      eth3
> 
> 
> The routing tables are symetric, but the label bindings are not !
> Do you have an explication about this behavior ? why is an entry in the
> LSR label forwarding table missing ?
> 
> Thanks,
> 
>  Yvan Pointurier
> ________________________________________________________________________
>  yv...@po...                             University of Virginia
>  http://www.pointurier.org               Department of Computer Science
> 
> 
> 
> 
> _______________________________________________
> mpls-linux-general mailing list
> mpl...@li...
> http://lists.sourceforge.net/lists/listinfo/mpls-linux-general

-- 
James R. Leu

Re: [mpls-linux-general] LDP-portable Compiling problem

[James R. L. <jl...@mi...>]

On Fri, Jul 06, 2001 at 04:11:07PM +0000, Haidong Xia wrote:
> 
> Hi, All,
> 
> Probably this question is mentioned before, but I am still confused.
> 
> I can't successfuly compile ldp-portable. The compiler told me: "ld failed, 
> segmentation fault" when I tried to compile it. It seems it already compiled 
> all the .o and .a files, but it failed to link them together.

You are the second person to mention that this is happening.  It doesn't
happen for me.  Could you provide me the output when you compile it?

Thanks,
Jim

> I have red-hat linux 7.0, kernel 2.4.5, and I already installed 
> mpls-linux-0.993.
> 
> I found James answered somebody by getting mpls-linux-0.992. Do you have to 
> switch to mpls-linux-0.992?
> 
> I am using these packages for one of my class. Thanks in advance.
> 
> sincerely
> Haidong
> _________________________________________________________________________
> Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com.
> 
> 
> _______________________________________________
> mpls-linux-general mailing list
> mpl...@li...
> http://lists.sourceforge.net/lists/listinfo/mpls-linux-general

-- 
James R. Leu

[mpls-linux-general] ldp_linux problem

[Yvan P. <yv...@vi...>]

Hi,

I tried ldp_linux on my testbed with 3 routers (2 LERs + 1 LSR) but I got
a problem with the LSR.

Topology:
(networks 10.0.a.0 with netmask 255.255.255.0 for each subnet 10.0.a.0)

Host1 eth1---eth1 LERA eth2---eth2 LSR eth3---eth3 LERB eth4---eth4 Host2
       1.1    1.2       2.1    2.2      3.1    3.2       4.1    4.2


The problem is that there is no label swapping at the LSR on packets from
LER B to LER A. The LSR swaps labels correctly for packets from LER A to
LER B:

(ping from LER A to LER B with route recording on)
$ ping -R -c1 10.0.4.2
PING 10.0.4.2 (10.0.4.2) from 10.0.1.1 : 56(124) bytes of data.
64 bytes from 10.0.4.2: icmp_seq=0 ttl=253 time=0.5 ms
RR:     10.0.1.1
        10.0.2.1
        10.0.3.1   --> due to no label swapping by the LSR
        10.0.4.1
        10.0.4.2
        10.0.4.2
        10.0.3.2   --> 10.0.2.2 is absent (expected)
        10.0.1.2
        10.0.1.1

contents of /proc/net/mpls_*:
* on LER A

LABELSPACE:
eth2    0

FEC:
40004804 10.0.3.0/24
40004c04 10.0.4.0/24

TUNNEL:

IN:
40004000 gen 16 0 POP DLV
40004400 gen 17 0 POP DLV
40004800 gen 18 0 POP DLV
40004c00 gen 19 0 POP DLV
40005000 gen 20 0 POP DLV

OUT:
40004804 PUSH(gen 18) SET(eth2)
40004c04 PUSH(gen 19) SET(eth2)

* on LSR

LABELSPACE:
eth2    0
eth3    0

FEC:
40004404 10.0.1.0/24
40004805 10.0.4.0/24

TUNNEL:

IN:
40004000 gen 16 0 POP DLV
40004400 gen 17 0 POP DLV
40004800 gen 18 0 POP DLV
40004c00 gen 19 0 POP DLV
40005000 gen 20 0 POP DLV
40005400 gen 21 0 POP DLV
40005800 gen 22 0 POP DLV
40005c00 gen 23 0 POP FWD(40004404)
40006000 gen 24 0 POP DLV
40006400 gen 25 0 POP DLV
40006800 gen 26 0 POP DLV
40006c00 gen 27 0 POP DLV

OUT:
40004404 PUSH(gen 17) SET(eth2)
40004805 PUSH(gen 18) SET(eth3)

* On LER B

LABELSPACE:
eth3    0

FEC:
40005c05 10.0.1.0/24
40006005 10.0.2.0/24

TUNNEL:

IN:
40004000 gen 16 0 POP DLV
40004400 gen 17 0 POP DLV
40004800 gen 18 0 POP DLV
40004c00 gen 19 0 POP DLV
40005000 gen 20 0 POP DLV

OUT:
40005c05 PUSH(gen 23) SET(eth3)
40006005 PUSH(gen 24) SET(eth3)


Routing tables (only the information about subnets 10.0.x.0 is relevant):
LER A
$ route
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Iface
10.0.4.0        10.0.2.2        255.255.255.0   UG    0      eth2
10.0.1.0        *               255.255.255.0   U     0      eth1
10.0.2.0        *               255.255.255.0   U     0      eth2
10.0.3.0        10.0.2.2        255.255.255.0   UG    0      eth2

LSR
$ route
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Iface
10.0.4.0        10.0.3.2        255.255.255.0   UG    0      eth3
10.0.1.0        10.0.2.1        255.255.255.0   UG    0      eth2
10.0.2.0        *               255.255.255.0   U     0      eth2
10.0.3.0        *               255.255.255.0   U     0      eth3

LER B
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Iface
10.0.4.0        *               255.255.255.0   U     0      eth4
10.0.1.0        10.0.3.1        255.255.255.0   UG    0      eth3
10.0.2.0        10.0.3.1        255.255.255.0   UG    0      eth3
10.0.3.0        *               255.255.255.0   U     0      eth3


The routing tables are symetric, but the label bindings are not !
Do you have an explication about this behavior ? why is an entry in the
LSR label forwarding table missing ?

Thanks,

 Yvan Pointurier
________________________________________________________________________
 yv...@po...                             University of Virginia
 http://www.pointurier.org               Department of Computer Science

[mpls-linux-general] LDP-portable Compiling problem

[Haidong X. <hd...@ho...>]

Hi, All,

Probably this question is mentioned before, but I am still confused.

I can't successfuly compile ldp-portable. The compiler told me: "ld failed, 
segmentation fault" when I tried to compile it. It seems it already compiled 
all the .o and .a files, but it failed to link them together.

I have red-hat linux 7.0, kernel 2.4.5, and I already installed 
mpls-linux-0.993.

I found James answered somebody by getting mpls-linux-0.992. Do you have to 
switch to mpls-linux-0.992?

I am using these packages for one of my class. Thanks in advance.

sincerely
Haidong
_________________________________________________________________________
Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com.

Re: [mpls-linux-general] New version of MPLS-Linux+iptables

[Olivier D. <Oli...@rd...>]

Hi,

I just put the patch and the archive on the patch section of sourceforge
:

 http://sourceforge.net/tracker/?group_id=15443&atid=315443

Have fun,

Olivier
-- 
 FTR&D/DAC/CPN
 Technopole Anticipa     | mailto:Oli...@fr...
 2, Avenue Pierre Marzin | Phone:  +(33) 2 96 05 28 80
 F-22307 LANNION         | Fax:    +(33) 2 96 05 18 52

[mpls-linux-general] New version of MPLS-Linux+iptables

[Olivier D. <Oli...@rd...>]

Hi all,

We just release mpls-linux+iptables version 0.3

ChangeLog:
----------
07-05-2001 : Olivier Dugeon <Oli...@rd...>
             Alexandre Dagan <Ale...@li...>

- Use fwmark aka ROUTE with MARK to setup the key in net/ipv4/
route.c(rt_set_nexthop) instead of mpls_output
- reverse mpls_ouput to the mpls-0.993 version
- Add fwmpls to act like fwmark but with a different variable to
let the user have both MARK and MPLS iptables stuff
- Split the path in two branch
        - small : use netfilter MARK behaviour
        - full  : use a separate netfilter MPLS behaviour


Let us know if you have some pb. with it.

Olivier & Alexandre
-- 
 FTR&D/DAC/CPN
 Technopole Anticipa     | mailto:Oli...@fr...
 2, Avenue Pierre Marzin | Phone:  +(33) 2 96 05 28 80
 F-22307 LANNION         | Fax:    +(33) 2 96 05 18 52

Re: [mpls-linux-general] bug: mpls/tc and mpls/netfilter, the same problem ?

[Vincent J. <ja...@en...>]

> I look to the tc code examples, and i'm a doubt. TC expect after the
> flowid a CLASSID
> value. But, CLASSID is of form X:Y where X and Y are unsigned short.
> Moreover, CLASSID represent a cbq where the packet is enqueue, and
> flowid tell tc to put the packet into the CLASSID class if it's
> accepted. Finally, i'm serious doubt about the mpls README.ingress
> example. Look again to the source, let me know that tc_index is setup
> when you specify the keyword "set_tc_index" in the tc command line. So,
> i'm totally confused with the tc behaviour. Have some doc about tc in
> addition to the "2.4 Advance Routing HOWTO" ?

see http://snafu.freedom.org/linux2.2/docs/howto-qos/

2 months ago, I had started to write one from a user point of view. I will 
post it this afternoon or next week. But I do not think that it will answer 
to your question.

> I just finish a new patch for mpls+netfilter (i send it to the mailing
> list this afternoon).

Great, I will not test it for a long time, I am going back home in Bretagne.

> Now we use nfmark+fwmark (aka
> CONFIG_IP_ROUTE_FWMARK) to setup the label or mpls_index+fwmpls (same
> behaviour than fwmark but only for mpls). So, you can put a mark (nfmark
> or mpls_index) to a packet with iptables and then use this mark as a
> filter for tc. My test (both on atm and eth) work for iptables but not
> with tc. Again, i'm a doubt about tc and i don't know (in the packet
> processing) when the ip stack call the sched stuff. Do you know that ?

It is called by the enqueue function of the main interface. And then 
according to a QoS hierachy on this interface (the classifiers), the 
specifique enqueue function is called. Then it is this function that chooses
to enqueue or to drop the packet. see 
http://snafu.freedom.org/linux2.2/docs/howto-qos/node3.html

The dequeuing process is controlled by the main interface too. When the 
interface is ready to send a new packet, it calls its dequeue function that 
looks for the right packet to dequeue in order to provide bandwidth 
limitation and/or delay support.

> I'm afraid that mpls stuff strap the sched stuff.

Everything is always possible ;-)

Vincent

Re: [mpls-linux-general] bug: mpls/tc and mpls/netfilter, the same problem ?

[Olivier D. <Oli...@rd...>]

Vincent Jardin wrote:
> 
> Hi,
> 
> > Why ? Can you tell me to what value mpls_index is set ? It's a parameter
> > pb. or a filter pb. ? Perhaps the label key must be preceed by 'Ox' like
> > with iptables to tell sch_ingress that the key is an hexadecimal value.
> 
> If you read my patch, I just do like you, I have removed the TC_H_MIN mask.

TC_H_MIN mask just skip the 16 MSB of mpls_index. The potential pb. (i
see it with iptables) is that tc filter .... get the value as a decimal
value and not an hexadecimal value. So, to avoid this in iptables, you
must put '0x' before the key. I don't know if it the same with tc. Can
you check this ?

> 
> > No. If you do this, you strap many packet processing like header
> > verification, hearder option treatment, fragment ... If ip_route_input
> > doesn't find an entry in rt_hash_table, it call ip_route_input_slow
> > which compute a dst entry and insert it in the rt_hash_table for the
> > subsequent call.
> 
> I agree. But I do not understand the idea of James. I am missing too many
> points ;-).

Jim use the dst (aka rt table) field to retrieve the moi for label
processing. The  mpls_bind2fec function init the moi in the fib
structure. So, in rt_set_nexthop i can retrieve this information and put
it into the dst field for further processing.

> How could he process properly the ingress filter with ip_route_input_slow ?

I don't think that Jim handle properly the ingress filter. I'm not sure,
but this fonctionnality come from another personn (don't remember who).
In fact, the ingress filter doesn't work with the original mpls-0.993
patch. Jim can you confirm that ?

> 
> > > Moreover, I have tested my mpls/tc patch with the MPLS/netfilter patch.
> > > It works too ;-) If anyone wants to try it, you should add the following
> > > line into mpls_output.c:
> > > int mpls_output(struct sk_buff *skb) {
> > >   static const char *fn_name = "mpls_output";
> > >   struct mpls_push_data *mpr = (struct mpls_push_data*)kmem_cache_alloc(
> > >     mpls_mpr_cachep,GFP_ATOMIC);
> > > [... ]
> > >   mpr->bos = 1;
> > >   mpr->exp = 0;
> > >
> > > #ifdef CONFIG_MPLS_INGRESS_POLICING
> > >   if (skb->mpls_index) {
> > >     unsigned int key = skb->mpls_index;
> > >
> > >     MPLS_DEBUG(("%s: selecting moi with mpls_index 0x%x\n",fn_name,key));
> > >     RADIX_GET(&moi_tree,mpls_out_info_node,next,MPLS_TREE_BITS,unsigned
> > > int, key,MPLS_TREE_DEPTH,moi,moi,retval);
> > >     if(retval || !moi) {
> > >       MPLS_DEBUG(("%s: unknown mpls_index\n",fn_name));
> > >       kmem_cache_free(mpls_mpr_cachep,mpr);
> > >       return -ESRCH;
> > >     }
> > >
> > > mpls_again:
> > > +     skb->dst = moi->moi_dst; // XXX <- add this line
> >
> > This is already done in mpls_output2 (line 100) which is call from
> > mpls_output, for the GEN label type only.
> 
> NOP, I get a panic if you do not add this line. Because in your patch, you
> try to access to skb->dst before mpls_output2. See skb->dst->pmtu.
>        case MPLS_OP_PUSH:
>            skb->dst->pmtu -= 4;
>            break;
>        }
>     }

The skb->dst field is setup by ip_route_input or ip_route_input_slow if
it has not been set previously (test is made in ip_rcv_finish). So, if
you strap (like you suggest in your pacth) this processing, the skb->dst
field is empty when mpls_output is call. You can refine this by adding :

mpls_again:
+	if (skb->dst == NULL)
+		skb->dst = moi->moi_dst;

> 
> Vincent
> 
> PS: I am thinking about how to integrate all the Linux's schedulers (and
> mainly CBQ because it supports some hierachical classes) with the MPLS code
> in order to do TE. For example, a leaf node of an egress hiearchy could be
> mapped into an LSP. And another leaf node could be a Best Effort one with any
> regular IP routing.
> 
>          5 Mbps
>       +-----+
>       | eth |
>       +-----+
>          |
>      ----+----
>     |         |
>    ---       ---
>   2 Mbps      3 Mbps
> Real time     Best Effot
> 
> UDP port      regular routing
>   5000
>  -> push
> label 32
> 
> tc qdisc ingress is not the right solution because it is "input" QoS.
> 
> For example, it would be nice to get something like:
>  tc qdisc parent 2:1 [...] mplstag 32 [...] cbq [...]

Yes, it would be very nice. Have you some ideas to start coding ?

> 
> I would appreciate any suggestion.
> 

What we intend to do is using iptables to mark packet, then use the tc
'fw' classifier (based on iptables mark) to enqueue the packets.

Olivier
-- 
 FTR&D/DAC/CPN
 Technopole Anticipa     | mailto:Oli...@fr...
 2, Avenue Pierre Marzin | Phone:  +(33) 2 96 05 28 80
 F-22307 LANNION         | Fax:    +(33) 2 96 05 18 52

[mpls-linux-general] ldp_zebra

[Vincent J. <ja...@en...>]

Hi

I have been testing ldp_linux with success in a very simple case that is 
described in the README.
1/ the sessions was opened between LSR
2/ the advertisement messages are sent to open LSP

I have tried ldp_zebra with the same configuration. 
1/ the discovery messages are sent and the LSR detect the peers.
2/ The TCP session is not opened. 
3/ then the advertisement messages cannot be sent and therefore the LSPs 
cannot be opened.

Who had some successful tests with ldp_zebra in order to open the LSPs and to 
initiate the FECs ?

Vincent

PS: I have been looking for a long time to find a segmentation fault in 
ldp_zebra.
The fix is to break the last loop of ldp_socket_udp_recvfrom :
int
ldp_socket_udp_recvfrom(ldp_socket_mgr_handle handle,
  ldp_socket_handle socket, uint8_t * buffer, int size, ldp_dest * from)
{                                                                             
              
  ...
      }
    } else {                    /* not p2p */
      LIST_LOOP(iff->ads, c, n2) {
        tmp.s_addr = 0;
        masklen2ip(c->address->prefixlen, &tmp);
 
        if ((((struct sockaddr_in *)&addr)->sin_addr.s_addr & tmp.s_addr) ==
          (c->address->u.prefix4.s_addr & tmp.s_addr)) {
          from->if_handle = (ldp_if_handle) iff;
          break;
        }
        if (n2 == (void *)0xffffffff) {
          break; // !?!?! XXX <--- FIX But n2 should be NULL. I did not
// figure out where the element is set to 0xfff...
// This fix might works only for me.
        }
 
      }
    }
 
  }
 
  return retval;
} 

Re: [mpls-linux-general] bug: mpls/tc and mpls/netfilter, the same problem ?

[Vincent J. <ja...@en...>]

Hi,

> Why ? Can you tell me to what value mpls_index is set ? It's a parameter
> pb. or a filter pb. ? Perhaps the label key must be preceed by 'Ox' like
> with iptables to tell sch_ingress that the key is an hexadecimal value.

If you read my patch, I just do like you, I have removed the TC_H_MIN mask.

> No. If you do this, you strap many packet processing like header
> verification, hearder option treatment, fragment ... If ip_route_input
> doesn't find an entry in rt_hash_table, it call ip_route_input_slow
> which compute a dst entry and insert it in the rt_hash_table for the
> subsequent call.

I agree. But I do not understand the idea of James. I am missing too many 
points ;-).
How could he process properly the ingress filter with ip_route_input_slow ?

> > Moreover, I have tested my mpls/tc patch with the MPLS/netfilter patch.
> > It works too ;-) If anyone wants to try it, you should add the following
> > line into mpls_output.c:
> > int mpls_output(struct sk_buff *skb) {
> >   static const char *fn_name = "mpls_output";
> >   struct mpls_push_data *mpr = (struct mpls_push_data*)kmem_cache_alloc(
> >     mpls_mpr_cachep,GFP_ATOMIC);
> > [... ]
> >   mpr->bos = 1;
> >   mpr->exp = 0;
> >
> > #ifdef CONFIG_MPLS_INGRESS_POLICING
> >   if (skb->mpls_index) {
> >     unsigned int key = skb->mpls_index;
> >
> >     MPLS_DEBUG(("%s: selecting moi with mpls_index 0x%x\n",fn_name,key));
> >     RADIX_GET(&moi_tree,mpls_out_info_node,next,MPLS_TREE_BITS,unsigned
> > int, key,MPLS_TREE_DEPTH,moi,moi,retval);
> >     if(retval || !moi) {
> >       MPLS_DEBUG(("%s: unknown mpls_index\n",fn_name));
> >       kmem_cache_free(mpls_mpr_cachep,mpr);
> >       return -ESRCH;
> >     }
> >
> > mpls_again:
> > +     skb->dst = moi->moi_dst; // XXX <- add this line
>
> This is already done in mpls_output2 (line 100) which is call from
> mpls_output, for the GEN label type only.

NOP, I get a panic if you do not add this line. Because in your patch, you 
try to access to skb->dst before mpls_output2. See skb->dst->pmtu.
       case MPLS_OP_PUSH:
           skb->dst->pmtu -= 4;
           break;
       }
    }

Vincent

PS: I am thinking about how to integrate all the Linux's schedulers (and 
mainly CBQ because it supports some hierachical classes) with the MPLS code 
in order to do TE. For example, a leaf node of an egress hiearchy could be 
mapped into an LSP. And another leaf node could be a Best Effort one with any 
regular IP routing.

         5 Mbps
      +-----+
      | eth |
      +-----+
         |
     ----+----
    |         |
   ---       ---
  2 Mbps      3 Mbps
Real time     Best Effot
 
UDP port      regular routing
  5000
 -> push
label 32

tc qdisc ingress is not the right solution because it is "input" QoS.

For example, it would be nice to get something like:
 tc qdisc parent 2:1 [...] mplstag 32 [...] cbq [...]

I would appreciate any suggestion.

Re: [mpls-linux-general] bug: mpls/tc and mpls/netfilter, the same problem ?

[Olivier D. <Oli...@rd...>]

Hi Vincent,

Vincent Jardin wrote:
> 
> Find enclosed my patch in order to get mpls/tc that is working now ;-)))
> 
> The ingress filter was not working because:
> 1/ mpls_index was not set to the right value in sch_ingress.c

Why ? Can you tell me to what value mpls_index is set ? It's a parameter
pb. or a filter pb. ? Perhaps the label key must be preceed by 'Ox' like
with iptables to tell sch_ingress that the key is an hexadecimal value.

> 
> 2/ mpls_output needs to be called from ip_rcv_finish (ip_input.c) otherwise
> ip_route_input could not find the right entry and then the skb was delivered
> to ip_error().

No. If you do this, you strap many packet processing like header
verification, hearder option treatment, fragment ... If ip_route_input
doesn't find an entry in rt_hash_table, it call ip_route_input_slow
which compute a dst entry and insert it in the rt_hash_table for the
subsequent call.
We thought that we can call directly mpls_output from the netfilter
ipt_MPLS.c function, but it strap too much packet processing.

> 
> Moreover, I have tested my mpls/tc patch with the MPLS/netfilter patch. It
> works too ;-) If anyone wants to try it, you should add the following line
> into mpls_output.c:
> int mpls_output(struct sk_buff *skb) {
>   static const char *fn_name = "mpls_output";
>   struct mpls_push_data *mpr = (struct mpls_push_data*)kmem_cache_alloc(
>     mpls_mpr_cachep,GFP_ATOMIC);
> [... ]
>   mpr->bos = 1;
>   mpr->exp = 0;
> 
> #ifdef CONFIG_MPLS_INGRESS_POLICING
>   if (skb->mpls_index) {
>     unsigned int key = skb->mpls_index;
> 
>     MPLS_DEBUG(("%s: selecting moi with mpls_index 0x%x\n",fn_name,key));
>     RADIX_GET(&moi_tree,mpls_out_info_node,next,MPLS_TREE_BITS,unsigned int,
>       key,MPLS_TREE_DEPTH,moi,moi,retval);
>     if(retval || !moi) {
>       MPLS_DEBUG(("%s: unknown mpls_index\n",fn_name));
>       kmem_cache_free(mpls_mpr_cachep,mpr);
>       return -ESRCH;
>     }
> 
> mpls_again:
> +     skb->dst = moi->moi_dst; // XXX <- add this line

This is already done in mpls_output2 (line 100) which is call from
mpls_output, for the GEN label type only.

>     for(i=0;i<moi->moi_instruction_length;i++) {
>        switch(moi->moi_instruction[i].mi_opcode) {
>        case MPLS_OP_FWD:
> 
> [...]
> 
> Please Olivier, could you tell me if both work with your ATM boards too ? (I
> do not have any ;-( )
> 

We can make the test, but we find a big bug in our patch : the
skb->dst->pmtu is decrement by 4 for each call of mpls_output, so for
each packet, resulting in a negative pmtu after sending hundreds of
packets. We find a beginning of solution based on the FWMARK route
capability. We provide a new patch ASAP.

> Thanks,
>   Vincent
> 

Olivier
-- 
 FTR&D/DAC/CPN
 Technopole Anticipa     | mailto:Oli...@fr...
 2, Avenue Pierre Marzin | Phone:  +(33) 2 96 05 28 80
 F-22307 LANNION         | Fax:    +(33) 2 96 05 18 52

Re: [mpls-linux-general] bug: mpls/tc and mpls/netfilter, the same problem ?

[Vincent J. <ja...@en...>]

Find enclosed my patch in order to get mpls/tc that is working now ;-)))

The ingress filter was not working because:
1/ mpls_index was not set to the right value in sch_ingress.c

2/ mpls_output needs to be called from ip_rcv_finish (ip_input.c) otherwise 
ip_route_input could not find the right entry and then the skb was delivered 
to ip_error().

Moreover, I have tested my mpls/tc patch with the MPLS/netfilter patch. It 
works too ;-) If anyone wants to try it, you should add the following line 
into mpls_output.c:
int mpls_output(struct sk_buff *skb) {
  static const char *fn_name = "mpls_output";
  struct mpls_push_data *mpr = (struct mpls_push_data*)kmem_cache_alloc(
    mpls_mpr_cachep,GFP_ATOMIC);
[... ]
  mpr->bos = 1;
  mpr->exp = 0;
 
#ifdef CONFIG_MPLS_INGRESS_POLICING
  if (skb->mpls_index) {
    unsigned int key = skb->mpls_index;
 
    MPLS_DEBUG(("%s: selecting moi with mpls_index 0x%x\n",fn_name,key));
    RADIX_GET(&moi_tree,mpls_out_info_node,next,MPLS_TREE_BITS,unsigned int,
      key,MPLS_TREE_DEPTH,moi,moi,retval);
    if(retval || !moi) {
      MPLS_DEBUG(("%s: unknown mpls_index\n",fn_name));
      kmem_cache_free(mpls_mpr_cachep,mpr);
      return -ESRCH;
    }
 
mpls_again:
+     skb->dst = moi->moi_dst; // XXX <- add this line
    for(i=0;i<moi->moi_instruction_length;i++) {
       switch(moi->moi_instruction[i].mi_opcode) {
       case MPLS_OP_FWD:

[...]

Please Olivier, could you tell me if both work with your ATM boards too ? (I 
do not have any ;-( )

Thanks,
  Vincent

PS: Enclosed the configuration files of my testbed.


Le Mardi  3 Juillet 2001 10:07, Olivier Dugeon a écrit :
> Hi Vincent,
>
> You must use MPLS/tc OR MPLS/netfilter, but not both at the same time.
> So, verify that :
>
> 1/ when you use MPLS/tc iptables are flush
> # iptables -v -F -t mangles            to flush the mangle table
> # iptables -v -L -t mangle             to list the mangle table
>
> 2/ when you use MPLS/netfilter tc ingress are disable
> # tc qdisc del dev eth0 handle ffff: ingress          to delete ingress
> on eth0
> # tc qdisc dev eth0 show                              to list qdisc
> ingress on eth0
>
> When you pass mpls_index to iptables, don't forget to preceed the key by
> 0x to let iptables know the value has Hexadecimal.
>
> We have test our patch on atm card and not on ethernet. MPLS/tc doesn't
> work for us with atm card.
>
> Hope you this help,
>
> Olivier

[mpls-linux-general] Re: a simple question

[Venisa C. <vca...@ho...>]

Jim,

>From: "James R. Leu" <jl...@mi...>
>Reply-To: jl...@mi...
>To: Venisa Cabrilla <vca...@ho...>
>Subject: Re: a simple question
>Date: Tue, 3 Jul 2001 10:13:26 -0500
>
>On Tue, Jul 03, 2001 at 03:08:17PM -0000, Venisa Cabrilla wrote:
> > Jim,
> >
> > Just a simple question, has CVS version of ldp_linux supported ORDERED 
>label
> > distribution control and DOWNSTREAM ON DEMAND label advertisement mode ? 
>I
> > just wonder when we use label request code (ldp_label_request.c) in
> > ldp_linux (uups, CR-related work :-)).
>
>Yes.  The defaults for ldp-portable are defined in lib/ldp_defaults.h
>Also each entity that is created can be specified to be DoD or UN, I just
>haven't add that level control to the ldp_linux command prompt.
>I haven't tested DoD very much and I don't think the initial label request
>code is finished.  You will most likly run into problems. :-)
>

It sounds that I have to create some CLIs to test DoD right ? To send label 
request message manually ?

BTW, I see some efforts concerning CR-LDP in some of your codes 
(ldp_struct.c, etc), but I think it has not been implemented in ldp_linux 
right ? Unfortunately, I cannot make ldp_zebra run in order to see what 
crldp_path CLIs can do.

>Let me know what you run into and I'll see if I can help out.
>

Certainly ... :-)

regards,
~Venisa Cabrilla


>Jim
>
> > Thanks in advance.
> >
> > regards,
> > ~Venisa Cabrilla
> > 
>_________________________________________________________________________
> > Get Your Private, Free E-mail from MSN Hotmail at 
>http://www.hotmail.com.
>
>--
>James R. Leu
_________________________________________________________________________
Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com.

[mpls-linux-general] a simple question

[Venisa C. <vca...@ho...>]

Jim,

Just a simple question, has CVS version of ldp_linux supported ORDERED label 
distribution control and DOWNSTREAM ON DEMAND label advertisement mode ? I 
just wonder when we use label request code (ldp_label_request.c) in 
ldp_linux (uups, CR-related work :-)).

Thanks in advance.

regards,
~Venisa Cabrilla
_________________________________________________________________________
Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com.

Re: [mpls-linux-general] bug: mpls/tc and mpls/netfilter, the same problem ?

[Olivier D. <Oli...@rd...>]

Hi Vincent,

You must use MPLS/tc OR MPLS/netfilter, but not both at the same time.
So, verify that :

1/ when you use MPLS/tc iptables are flush
# iptables -v -F -t mangles            to flush the mangle table
# iptables -v -L -t mangle             to list the mangle table 

2/ when you use MPLS/netfilter tc ingress are disable
# tc qdisc del dev eth0 handle ffff: ingress          to delete ingress
on eth0
# tc qdisc dev eth0 show                              to list qdisc
ingress on eth0

When you pass mpls_index to iptables, don't forget to preceed the key by
0x to let iptables know the value has Hexadecimal.

We have test our patch on atm card and not on ethernet. MPLS/tc doesn't
work for us with atm card.

Hope you this help,

Olivier
-- 
 FTR&D/DAC/CPN
 Technopole Anticipa     | mailto:Oli...@fr...
 2, Avenue Pierre Marzin | Phone:  +(33) 2 96 05 28 80
 F-22307 LANNION         | Fax:    +(33) 2 96 05 18 52

[mpls-linux-general] bug: mpls/tc and mpls/netfilter, the same problem ?

[Vincent J. <ja...@en...>]

Hi,

I can see the following problem that could explain why MPLS/tc and 
MPLS/netfilter do not work for me:

1/ 
in sch_ingress.c:
...
  sch_ingress.c:  skb->mpls_index = res.classid;
...
I could check that skb->mpls_index = res.classid = 0x0x40005006 
but in ip_output, skb->mpls_index remains always to 0x0.

2/
When I was doing another test, I could see the same problem with netfilter:
in ipt_MPLS.c, the skb's mpls_index is set to 0x40005006, 
ipt_MPLS.c:
...
        if((*pskb)->mpls_index != mplsinfo->index) {
                (*pskb)->mpls_index = mplsinfo->index; <- It is set properly.
                (*pskb)->nfcache |= NFC_ALTERED;
        }
...
But in ip_output, skb->mpls_index remains always to 0x0 ;-(


Then the skb is not processed by mpls_output in ip_output, but it is 
processed by the regular ip_output. The datagram is not labeled and is not 
sent in the LSP.

Who would have an idea in order to get the right skb->mpls_index in ip_output 
?

Vincent

Re: [mpls-linux-general] Iptables Extension to MPLS-LINUX

[Olivier D. <Oli...@rd...>]

Hi Vincent,

Vincent Jardin wrote:
> 
> 1/ bug in ip_output.c:ip_output()
> 
> #ifdef CONFIG_MPLS_INGRESS_POLICING
>         if (skb->mpls_index)
>                 return mpls_output(skb);
> #endif
> 
> should be after
> 
> #ifdef CONFIG_IP_ROUTE_NAT
>         struct rtable *rt = (struct rtable*)skb->dst;
> #endif
> 

Ok we see the error.

> 2/ bug in libipt_MPLS.c
> static void
> save(const struct ipt_ip *ip, const struct ipt_entry_target *target)
> {
>         const struct ipt_mpls_target_info *mplsinfo =
>                 (const struct ipt_mpls_target_info *)target->data;
> 
>         printf("--set-mpls 0x%lx ", mplsinfo->index);
> }
> It should be --set-index
> Moreover, there is the same error in your README, set-index should be used
> instead of set-mpls. Or you should update libipt_MPLS.c and replace the
> parsing of all the set-index with set-mpls. Otherwise it is not consistent.

The error is in the README file. All the code are consisent : We use
--set-mpls
> 
> 3/ it does not work with my testbed. I am still workin on it ;-(
> 
> Vincent
> 
> PS:
> int ip_output(struct sk_buff *skb)
> {
> 
> #ifdef CONFIG_IP_ROUTE_NAT
>         struct rtable *rt = (struct rtable*)skb->dst;
> #endif
> 
> /* OD & AD : call mpls_output routine if mpls_index has been set in PREROUTING
>  * or LOCAL_OUT hook both by netfilter or tc ingress.
>  */
> #ifdef CONFIG_MPLS_INGRESS_POLICING
>         if (skb->mpls_index)
>                 return mpls_output(skb);
> #endif
> 
>         IP_INC_STATS(IpOutRequests);
> 
> PPS: Please, could you post a more recent diff ?

We have used a Mandrake kernel source with mpls patch and not a full
clean linux kernel. This explain why there is some hunk. For the error
on the patch for the route.c file, you just need to add a blank line
after the last line (i.e. after the line 256). We made another patch
ASAP, but we found a bug in the code, so we have to correct them before.

> PPPS: I am sorry if this mail is delayed, we have some routing loops in our
> local network ;-(
> 

Olivier & Alexandre

-- 
 FTR&D/DAC/CPN
 Technopole Anticipa     | mailto:Oli...@fr...
 2, Avenue Pierre Marzin | Phone:  +(33) 2 96 05 28 80
 F-22307 LANNION         | Fax:    +(33) 2 96 05 18 52