mpls-linux-devel — Mailig list for discussing the development of MPLS on Linux

[mpls-linux-devel] mpls-linux 1.950 released

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

Hello All,

I've finally complete the release of mpls-linux 1.950.  For those that watch
the File Release section of the MPLS for Linux SourceForge site you've seen
this release coming since Dec 2005.  I've forgotten how much work goes into
making a release!!!  (anyone interested in taking over the release process?)

There are many changes in mpls-linux-1.950
------------------------------------------
o I've started using the SourceForge Documentation feature.
  Check out http://sourceforge.net/docman/?group_id=3D15443
  (I'll gladly post other peoples examples which follow my
  style)
o new netlink interface using the genetlink system (this
  requires all userland apps to be modified)
o new 'shim' infrastructure replaces the old 'spec_nh'
  infrastructure for moving packets from L3 protocols
  to MPLS
o MPLS can now be compiled as modules and loaded and
  unloaded as needed (still a bug where the base 'mpls'
  module cannot be unloaded)
o creation of MPLS tunnel interfaces is done via loading
  modules
o Penultimate Hop Popping - PHP now implemented.  This same
  feature now allows you to configure the egress LER to
  bypass the IPv4 or IPv6 lookup (think PE-CE routing in
  RFC2547bis).
o support for point-to-point interfaces
o the 'mpls' command now can configure the obscure MPLS
  parameters and flags (propogate_ttl, MTU, protocol)
o Ethernet Over MPLS forwarding is now part of the standard
  mpls-linux kernel
    o the 'mpls' command now can configure egress LER
      forwarding for Ethernet over MPLS
    o ebtables has been extended to support a MPLS target,
      this is used for ingress LER forwarding for Ethernet
      over MPLS

The RPMs I've provided are built on a Fedora Core 4 system.  I have used
all of them on a Fedora Core 3 machine as well, with only minor dependency
issues (you need to install the FC4 version of db4 along side the FC3 versi=
on)

There are two flavors of RPMs for quagga.  One built to interact with
mpls-linux via netlink, and the other is built with "null" bindings (is does
nothing).  The "null" version is for use on machines that cannot for some
reason run a mpls-linux kernel.  Needless to same the "null" version will
not create or forward MPLS packets.

The kernel RPMs have mpls-linux built as a module, this means you must do a
'modprobe mpls4' or 'modprobe mpls6' before attempting any MPLS linux
configuration.
--=20
James R. Leu
jl...@mi...

[mpls-linux-devel] =?iso-8859-1?B?YXJlIHJlYWR5IHRvIHdvcmsgdG9nZXRoZXI/?=

[hastie b. <9d...@po...>]

Dear !

Our noncommercial enterprise has been engaging in 
organization and maintenance of shelters for stray 
dogs and cats for more than 12 years in one of the 
countries of the former Soviet Union. For the time 
weve constructed 18 shelters which maintenance, as 
you see, costs much. The more so we constantly 
increase the quantity of such shelters in different 
cities. And we have a lot of sponsors among 
businessmen and ordinary people who render us 
feasible material support. 

But the legislation of our country does not attribute 
our work to charitable kinds of activity. Therefore 
any our sponsor wishing to transfer the money to our 
account is exposed to the barbarous taxation which 
size makes up 48 % of the transferred sum. And it 
doesnt include taxes to which our enterprise 
undergoes when using these funds. It is quite clear 
that suffering animals reach a mere trifle of these 
donations. And it besides that our cities are full 
of the sick and hungry animals eating garbage on 
cesspits that our legislators do not care a fig. 

Therefore we have come to a decision to engage people 
who could fulfill not complicated work of short 
duration as our financial agents. Our sponsors could 
transfer means for us to your bank account and you, 
in your turn, could send the means to our agents 
addresses to Russia. The mediation doesnt require any 
investments on your part. Moreover we are ready to 
pay to you for this work not less than 8 % of the sum 
sent by you and, naturally, to cover all your expenses 
bound up with sending the money to our address. 

Our requirements are simple: you should be over 20 year 
of age and you should love animals very much. Thus we 
can avoid the barbarous taxation of our country and 
above all help poor animals. If you are ready to work 
together with us and have some spare time fill in the 
resume stated below. If you satisfy our conditions we 
send you our employment agreement with gratitude and 
explain all circumstances of your future work with us 
in details.

=============================================
Your company name:
First name:
Last name:
Country:
State:
City:
Land phone:
Cell phone:
E-mail:
Hours available for telephone interviews:

=============================================

Best wishes,

Anna Brener, 
Noncommercial Enterprise "Prioritet" 
mailto:pri...@bk...

Re: [mpls-linux-devel] Merging into the kernel?

[Steven W. <st...@ch...>]

Hi,

On Wed, Feb 15, 2006 at 09:40:57PM -0600, James R. Leu wrote:
> Hey there Steve,
>
[some things cut to avoid reposting too much] 
> 
> > One question occurs to me though... did you consider using the xfrm code
> > in order to interface with the higher layer protocols? I took a look at
> > this recently since it seems to be in the right place in the stack to
> > do this. Its fairly complicated and there seems to be at least a loose
> > fit but I can see that some changes would be required. The issue of selecting
> > a forwarding class being the biggest potential issue. Still it appears to me
> > to be a lot cleaner to modify xfrm a bit and I suspect more likely to meet
> > with more general approval.
> 
> Yes.  I recently spent a significant amount of time understanding the XFRM
> code just to realize that it cannot be tied to a specific route.  The
> selector mechanism is much like netfilter, ie it does not do longest prefix
> match.  Infact implementing a XFRM shim module would bring route based
> IPSEC VPNs to linux (without having to use a virtual interface).
> 
> I also looked at tc actions, but there too, tc is more like netfilter then
> a LPM.
>
Yes - I wonder though whether we could use a different selector mechanism
but keeping some of the general framework. When I looked at it, the main
thing which struck me was that the difficulty in changing the selector
mechanism was mostly down to the interface (via netlink) to userland.
Actually changing it on the kernel side is not impossible I think.


> 
> > This also brings me neatly on to the forwarding code. I see that this has
> > been implemented in three parts, which if you'll excuse my ascii artistry,
> > or lack of it, interact as follows:
> > 
> > 
> >                 /-----\   /----\   /-------\
> >  input from ----| ILM |---| XC |---| nhlfe |---- output to
> >  netdevice      \-----/   \----/   \-------/     netdevice
> >                    |                   |
> >                    |                   |
> >                  to higher          from higher
> >                  protocols          protocols
> >
> > Now both the ILM and nhlfe are composed of radix tree tables and I'm
> > curious as to why you chose this particular system over (say, for example)
> > a plain hash table. The cross connect interface which updates the final
> > instruction in the ILM entry to point to an nhlfe entry is also confusing
> > me slightly as I don't see why the ILM can't have a forwarding instruction
> > added to it directly when its created via the netlink message. Why the
> > extra interface?
> 
> The XC netlink interface is there to assist signaling protocols.  It is
> very common to create an ILM that terminates locally and then at a later
> time XCs to a NHLFE, and at even a later time, swing the XC to a different
> NHLFE.  With that being said, there is nothing that the XC netlink interface
> does that cannot be done by just modifying the instructions via the ILM
> netlink interface.
> 
> Why use a radix tree?  Originally it was just for ease of implementation.
> Now it is because the radix tree lookup for the ILM provides deterministic
> search times.  That being said, I have no problem with changing to a
> multi tier hash scheme as long as it can provide better performance (including
> corner cases).
>
And of it occured to me that in order to find this out we'd need some
tools to test against. Please find attached a patch for pktgen (as
current in davem's net-2.6.17 git tree at kernel.org) to generate
MPLS packets.

The extension allows you to add a stack of labels onto the packets its
sending out. There is one extra hack which I included: since we know
how many labels there are in the stack, I've used the bottom of stack
bit to indicate whether the label should be randomly generated or not.

You can thus push a stack of (up to 16 labels) where each label in the
stack is either a fixed value or random.

pgset "mpls 0001000a,0002000a,0000000a"

for example pushes labels 16, 32 and 0 (ipv4 null) each with a ttl of 10.
If you set the bottom of stack bit in one of the labels it will turn on
the MPLS_RND flag. You can also set and/or reset that flag in the 
normal way as well.

Patches to pktgen have become very popular of late it seems
so I'm going to wait until the latest set which are pending at the
moment have made it into Dave's tree before making a final diff to send
to Robert Olsson, the maintainer of pktgen.

Also if anyone has feedback about this feature, please let me know.
 
> > I have been giving some thought as to the efficiency of the forwarding
> > process itself recently, with the idea of "transcoding" the instructions
> > as provided via netlink into an efficient byte code to allow faster
> > execution. The would appear to be considerable scope for merging certain
> > instructions (e.g. a pull followed by a push) into one internal instruction
> > (i.e. the interface would be the same and the effect the same so it
> > wouldn't break the protocol at all).
> 
> I like the idea.  This is much like what I'm used to in the hardware
> forwarding world. What you're kind of hinting at it a packet translation
> engine, this would make it easier to map the forwarding of packets onto FPGA
> or ASIC based hardware (isn't there a couple of projects doing this
> for packet filtering? nf-HIPAC)
>
Its possible it might make it easier. I have to say that although I'm a
hardware engineer by training I've never really got into details of
network interfaces and what its possible to do on the cards. I wouldn't
be at all surprised if it was the case though and it would be nice to
do :-)
 
> 
> > The various instructions to set/get tcindex and nfmark seem like a
> > very good plan. I'm considering writing a patch to add setting nfmark
> > through the ipv4/6/decnet routing tables which I think would be a
> > generally useful plan. I wonder also if using one or the other or both
> > of nfmark and/or tcindex as a key in looking up the nhlfe and/or ilm
> > isn't a bad idea either.
> 
> That might be against the RFCs.  I know I'm already overstepping the
> RFCs by allowing the EXP bits to determine a NHLFE.
>
I wouldn't worry too much about overstepping what the RFCs say so long
as the result makes sense and the stack can still comply with them on
all the required points. The main worry with schemes like this is really
just a question of forwarding speed and whether it will slow things down
too much.

> > If nfmark could be 1:1 with mpls fec, then it might be possible to use
> > it together with xfrm as the interface for higher level protocols.
> 
> Not sure I follow you here.  Currently with the shim setup there is no
> NHLFE lookup in the forward path, the NHLFE is bound to the IPv4|6 route or
> the eb|iptables rule.
>
Ok, let me explain a bit more then.... I'm assuming a scenario where the
NHFLE is determined based upon nfmark and nfmark is set in the route
(of whatever protocol). If nfmark were also a key for xfrm then it
should be possible to "bundle" a set of dst_entry with the MPLS nhlfe
as the last entry in the stack.


I haven't got any further with the DECnet interface since I last posted
but I may well make that my next project,

Steve.

Re: [mpls-linux-devel] Merging into the kernel?

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

Hey there Steve,

On Wed, Feb 15, 2006 at 09:07:50PM +0000, root wrote:
>=20
> Hi,
>=20
> Sorry for taking so long to respond, here are a number of comments and
> questions.... this is also an opportunity for me to express all the ideas
> I've had over the last few weeks, so please excuse me if I ramble on too
> much :-)
>=20
> Firstly thanks for sending me the two patches. I've spoken to Jamal and
> the genetlink solution is certainly the right way to go, so I'll talk
> only about that particular patch from now on. You mentioned that RCU
> needed looking at in a previous email and I've taken a quick look over
> it and I'd agree that it looks like the current code is part way between
> RCU and a fully locked solution.

Agreed.  My understand of RCU is not complete.  I've been trying to
use the existing implementations throughout the kernel as examples,
but none seem to fit my scenario exactly.  I thought I had the shim_*
stuff correct (I used the dev_remove_pack/dev_add_pack as a guide).

> Probably the simplest thing to do is just to change the list_add_rcu()
> in shim.c:shim_proto_add() back to a standard list_add() until the list
> can be converted completely (and likewise list_del_rcu() in=20
> shim.c:shim_proto_remove()) although I'd agree that an RCU implementation
> would be much preferable, and possibly even a prerequisite for kernel
> inclusion due to the already (mostly) lockless routing code.

Understood.  I've converted back to list_del() and list_add().

> One question occurs to me though... did you consider using the xfrm code
> in order to interface with the higher layer protocols? I took a look at
> this recently since it seems to be in the right place in the stack to
> do this. Its fairly complicated and there seems to be at least a loose
> fit but I can see that some changes would be required. The issue of selec=
ting
> a forwarding class being the biggest potential issue. Still it appears to=
 me
> to be a lot cleaner to modify xfrm a bit and I suspect more likely to meet
> with more general approval.

Yes.  I recently spent a significant amount of time understanding the XFRM
code just to realize that it cannot be tied to a specific route.  The
selector mechanism is much like netfilter, ie it does not do longest prefix
match.  Infact implementing a XFRM shim module would bring route based
IPSEC VPNs to linux (without having to use a virtual interface).

I also looked at tc actions, but there too, tc is more like netfilter then
a LPM.

> One thing which struck me about the patch was although it does put
> in place a lot of the groundwork, I think a more ambitious approach would
> be more likely to be accepted. Going for small patches is good, but also
> the initial patch should add some (standalone) functionality to the kerne=
l,
> so there is also "too small". I'd suggest going for the minimum sized pat=
ch
> which can add a useful feature, say for example, adding just enough code =
to do
> MPLS forwarding and leaving other bits (the tunnel device which makes a n=
ice
> patch on its own and the interface with the higher level protocols) until
> later.

Agreed.  The first patch should contain the minimal MPLS implementation.

> This also brings me neatly on to the forwarding code. I see that this has
> been implemented in three parts, which if you'll excuse my ascii artistry,
> or lack of it, interact as follows:
>=20
>=20
>                 /-----\   /----\   /-------\
>  input from ----| ILM |---| XC |---| nhlfe |---- output to
>  netdevice      \-----/   \----/   \-------/     netdevice
>                    |                   |
>                    |                   |
>                  to higher          from higher
>                  protocols          protocols
>
> Now both the ILM and nhlfe are composed of radix tree tables and I'm
> curious as to why you chose this particular system over (say, for example)
> a plain hash table. The cross connect interface which updates the final
> instruction in the ILM entry to point to an nhlfe entry is also confusing
> me slightly as I don't see why the ILM can't have a forwarding instruction
> added to it directly when its created via the netlink message. Why the
> extra interface?

The XC netlink interface is there to assist signaling protocols.  It is
very common to create an ILM that terminates locally and then at a later
time XCs to a NHLFE, and at even a later time, swing the XC to a different
NHLFE.  With that being said, there is nothing that the XC netlink interface
does that cannot be done by just modifying the instructions via the ILM
netlink interface.

Why use a radix tree?  Originally it was just for ease of implementation.
Now it is because the radix tree lookup for the ILM provides deterministic
search times.  That being said, I have no problem with changing to a
multi tier hash scheme as long as it can provide better performance (includ=
ing
corner cases).

> I have been giving some thought as to the efficiency of the forwarding
> process itself recently, with the idea of "transcoding" the instructions
> as provided via netlink into an efficient byte code to allow faster
> execution. The would appear to be considerable scope for merging certain
> instructions (e.g. a pull followed by a push) into one internal instructi=
on
> (i.e. the interface would be the same and the effect the same so it
> wouldn't break the protocol at all).

I like the idea.  This is much like what I'm used to in the hardware
forwarding world. What you're kind of hinting at it a packet translation
engine, this would make it easier to map the forwarding of packets onto FPGA
or ASIC based hardware (isn't there a couple of projects doing this
for packet filtering? nf-HIPAC)

> It should be possible to calculate, for any given instruction sequence
> the maximum headroom required (in the skb) to execute it in advance
> such that it would be possible to guarantee that only a single call
> to skb_realloc_headroom would be required for any particular packet.
> A future development might even request that device drivers always send
> packets with a certain amount of headroom to prevent even this call
> being required. Currently I see that its assumed that 32 bytes will
> cover all eventualities, which seems a reasonable bet for most uses.

Currently the size of the stack is being tracked to handle MTU issues.
The really painful case for head allocation is ethernet over MPLS (22 bytes=
).

> Another feature of transcoding would be to remove useless instructions
> (NOP) from the execution path. Is there actually any practical purpose
> for this instruction? I'm afraid I can't see one.

There is no purpose to the NOOP code.  It is left over cruft that
can be removed.

> The various instructions to set/get tcindex and nfmark seem like a
> very good plan. I'm considering writing a patch to add setting nfmark
> through the ipv4/6/decnet routing tables which I think would be a
> generally useful plan. I wonder also if using one or the other or both
> of nfmark and/or tcindex as a key in looking up the nhlfe and/or ilm
> isn't a bad idea either.

That might be against the RFCs.  I know I'm already overstepping the
RFCs by allowing the EXP bits to determine a NHLFE.

> If nfmark could be 1:1 with mpls fec, then it might be possible to use
> it together with xfrm as the interface for higher level protocols.

Not sure I follow you here.  Currently with the shim setup there is no
NHLFE lookup in the forward path, the NHLFE is bound to the IPv4|6 route or
the eb|iptables rule.

> I also have the basics of a DECnet interface to mpls (not tested yet,
> I'm afraid) which I've roughed out. I'll send that to you if you are
> interested. It doesn't look a lot different to the ipv4 one which is
> no surprise since thats where DECnet's routing code comes from.

Cool.  Having another person implement to the shim interface is a good test
of the functionality.  Like I mentioned above, I have the beginning of a
XFRM shim implementation for the purpose of route based IPSEC VPNs.

> Steve.
>=20
>=20
>=20
> -------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc. Do you grep through log fi=
les
> for problems?  Stop!  Download the new AJAX search engine that makes
> searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
> http://sel.as-us.falkag.net/sel?cmd=3Dlnk&kid=3D103432&bid=3D230486&dat=
=3D121642
> _______________________________________________
> mpls-linux-devel mailing list
> mpl...@li...
> https://lists.sourceforge.net/lists/listinfo/mpls-linux-devel

--=20
James R. Leu
jl...@mi...

Re: [mpls-linux-devel] Merging into the kernel?

[root <ro...@so...>]

Hi,

Sorry for taking so long to respond, here are a number of comments and
questions.... this is also an opportunity for me to express all the ideas
I've had over the last few weeks, so please excuse me if I ramble on too
much :-)

Firstly thanks for sending me the two patches. I've spoken to Jamal and
the genetlink solution is certainly the right way to go, so I'll talk
only about that particular patch from now on. You mentioned that RCU
needed looking at in a previous email and I've taken a quick look over
it and I'd agree that it looks like the current code is part way between
RCU and a fully locked solution.

Probably the simplest thing to do is just to change the list_add_rcu()
in shim.c:shim_proto_add() back to a standard list_add() until the list
can be converted completely (and likewise list_del_rcu() in 
shim.c:shim_proto_remove()) although I'd agree that an RCU implementation
would be much preferable, and possibly even a prerequisite for kernel
inclusion due to the already (mostly) lockless routing code.

One question occurs to me though... did you consider using the xfrm code
in order to interface with the higher layer protocols? I took a look at
this recently since it seems to be in the right place in the stack to
do this. Its fairly complicated and there seems to be at least a loose
fit but I can see that some changes would be required. The issue of selecting
a forwarding class being the biggest potential issue. Still it appears to me
to be a lot cleaner to modify xfrm a bit and I suspect more likely to meet
with more general approval.

One thing which struck me about the patch was although it does put
in place a lot of the groundwork, I think a more ambitious approach would
be more likely to be accepted. Going for small patches is good, but also
the initial patch should add some (standalone) functionality to the kernel,
so there is also "too small". I'd suggest going for the minimum sized patch
which can add a useful feature, say for example, adding just enough code to do
MPLS forwarding and leaving other bits (the tunnel device which makes a nice
patch on its own and the interface with the higher level protocols) until
later.

This also brings me neatly on to the forwarding code. I see that this has
been implemented in three parts, which if you'll excuse my ascii artistry,
or lack of it, interact as follows:


                /-----\   /----\   /-------\
 input from ----| ILM |---| XC |---| nhlfe |---- output to
 netdevice      \-----/   \----/   \-------/     netdevice
                   |                   |
                   |                   |
                 to higher          from higher
                 protocols          protocols


Now both the ILM and nhlfe are composed of radix tree tables and I'm
curious as to why you chose this particular system over (say, for example)
a plain hash table. The cross connect interface which updates the final
instruction in the ILM entry to point to an nhlfe entry is also confusing
me slightly as I don't see why the ILM can't have a forwarding instruction
added to it directly when its created via the netlink message. Why the
extra interface?

I have been giving some thought as to the efficiency of the forwarding
process itself recently, with the idea of "transcoding" the instructions
as provided via netlink into an efficient byte code to allow faster
execution. The would appear to be considerable scope for merging certain
instructions (e.g. a pull followed by a push) into one internal instruction
(i.e. the interface would be the same and the effect the same so it
wouldn't break the protocol at all).

It should be possible to calculate, for any given instruction sequence
the maximum headroom required (in the skb) to execute it in advance
such that it would be possible to guarantee that only a single call
to skb_realloc_headroom would be required for any particular packet.
A future development might even request that device drivers always send
packets with a certain amount of headroom to prevent even this call
being required. Currently I see that its assumed that 32 bytes will
cover all eventualities, which seems a reasonable bet for most uses.

Another feature of transcoding would be to remove useless instructions
(NOP) from the execution path. Is there actually any practical purpose
for this instruction? I'm afraid I can't see one.

The various instructions to set/get tcindex and nfmark seem like a
very good plan. I'm considering writing a patch to add setting nfmark
through the ipv4/6/decnet routing tables which I think would be a
generally useful plan. I wonder also if using one or the other or both
of nfmark and/or tcindex as a key in looking up the nhlfe and/or ilm
isn't a bad idea either.

If nfmark could be 1:1 with mpls fec, then it might be possible to use
it together with xfrm as the interface for higher level protocols.

I also have the basics of a DECnet interface to mpls (not tested yet,
I'm afraid) which I've roughed out. I'll send that to you if you are
interested. It doesn't look a lot different to the ipv4 one which is
no surprise since thats where DECnet's routing code comes from.

Steve.

Re: [mpls-linux-devel] Update to 1.950 release

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

The src RPM has a patch against 2.6.15.

On Tue, Feb 14, 2006 at 02:41:29PM -0500, Bob Beers wrote:
> On 2/1/06, James R. Leu <jl...@mi...> wrote:
> > For those of you following the ongoing release of mpls-linux 1.950, I've
> > release updated kernel RPMs based on 2.6.15.  These RPMs also contain a
> > fix for 'mpls' show commands.
> >
>=20
> Does one of these RPMs have a 2.6.15.X kernel diff? I have completely
>  forgotten how to use perforce ...
>=20
> -Bob

--=20
James R. Leu
jl...@mi...

Re: [mpls-linux-devel] Update to 1.950 release

[Bob B. <bob...@gm...>]

On 2/1/06, James R. Leu <jl...@mi...> wrote:
> For those of you following the ongoing release of mpls-linux 1.950, I've
> release updated kernel RPMs based on 2.6.15.  These RPMs also contain a
> fix for 'mpls' show commands.
>

Does one of these RPMs have a 2.6.15.X kernel diff? I have completely
 forgotten how to use perforce ...

-Bob

[mpls-linux-devel] Update to 1.950 release

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

For those of you following the ongoing release of mpls-linux 1.950, I've
release updated kernel RPMs based on 2.6.15.  These RPMs also contain a
fix for 'mpls' show commands.

The official release of 1.950 should be coming soon.

--=20
James R. Leu
jl...@mi...

Re: [mpls-linux-devel] Merging into the kernel?

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

On Tue, Jan 31, 2006 at 05:44:14PM +0000, Steven Whitehouse wrote:
> Hi,
>=20
> Thanks for the info on the current situation. I'm sorry for the slow
> reply (this is a spare-time project for me at least at the moment so it h=
as to
> fill odd moments that I can find).

Understood.  Same here.

> I've started to take a more in depth look at the code. I'll send a
> patch or two once I get a chance to do a bit of testing. In the
> meantime, here are a few more questions/comments:
>=20
> On Mon, Jan 23, 2006 at 10:39:41AM -0600, James R. Leu wrote:
> > Before the holidays I had started down path to getting mpls-linux
> > into the kernel (again).  I emailed jamal.  My first goal is to get the
> > infrastructure that mpls-linux needs to interact with L3 protocols put
> > in place.  Im my implementation this is the 'shim' infrastructure (look
> > in the devel achieves for a patch I've posted).
> >
> This sounds like a good plan. Its always better to break things in to
> smaller units provided each is useful in its own right, when submitting
> to the kernel.
> =20
> > I sent two patches for jamal's review, davem's technique for
> > interacting with L3 and the mpls-linux technique.  They are very simila=
r,
> > if you ask me I think the mpls-linux method is more elegant and less
> > intrusive.
> >
> What is davem's technique in this context?

I'll send you two patches, one showing the shim technique the other
showing the equivalent code from DaveM's implementation.

> > That is where we stand.  I'm sure jamal forgot about it with the holida=
ys
> > and all.  I plan on picking up this task again soon.  I was trying to g=
et
> > 1.950 finished (quagga support is broken still), but there is not reason
> > this process can't be done at the same time.

I've talked with Jamal, and he is working on a way to help out in this
effort.

> > So how can others help?  Review the code.  Test the code.  In particular
> > the locking scheme (RCU) needs to be reviewed.  In addition there is
> > some known issues with the netdevice notification handler (the list of =
NHLFE
> > is not being maintained correctly with respect to instructions, add/del=
ete,
> > and device changes).  There was a bug report posted to general late last
> > summer that had some details.
> >
> Ok. I will take a look at those as soon as I can get properly familiar
> with the code. Can I presume that your perforce archive contains in
> the mpls-kernel-1.1 directory all your latest kernel code so that I can j=
ust
> do a sync from time to time to keep uptodate? Or are there any patches
> elsewhere I should know about?

Head of line from my perforce tree is the latest greatest.=20
If you use a view of:
   =20
    //depot/iproute2-mpls-1.1/... //client-name/iproute2/...
    //depot/mpls-kernel-1.1/... //client-name/kernel/...

You would get the minimum tools needed to setup basic MPLS LSPs
and map IPv4/6 traffic to them.
   =20
>=20
> Steve.
> =20

--=20
James R. Leu
jl...@mi...

Re: [mpls-linux-devel] Merging into the kernel?

[Steven W. <st...@ch...>]

Hi,

Thanks for the info on the current situation. I'm sorry for the slow
reply (this is a spare-time project for me at least at the moment so it has to
fill odd moments that I can find).

I've started to take a more in depth look at the code. I'll send a
patch or two once I get a chance to do a bit of testing. In the
meantime, here are a few more questions/comments:

On Mon, Jan 23, 2006 at 10:39:41AM -0600, James R. Leu wrote:
> Before the holidays I had started down path to getting mpls-linux
> into the kernel (again).  I emailed jamal.  My first goal is to get the
> infrastructure that mpls-linux needs to interact with L3 protocols put
> in place.  Im my implementation this is the 'shim' infrastructure (look
> in the devel achieves for a patch I've posted).
>
This sounds like a good plan. Its always better to break things in to
smaller units provided each is useful in its own right, when submitting
to the kernel.
 
> I sent two patches for jamal's review, davem's technique for
> interacting with L3 and the mpls-linux technique.  They are very similar,
> if you ask me I think the mpls-linux method is more elegant and less
> intrusive.
>
What is davem's technique in this context?
 
> That is where we stand.  I'm sure jamal forgot about it with the holidays
> and all.  I plan on picking up this task again soon.  I was trying to get
> 1.950 finished (quagga support is broken still), but there is not reason
> this process can't be done at the same time.
> 
> So how can others help?  Review the code.  Test the code.  In particular
> the locking scheme (RCU) needs to be reviewed.  In addition there is
> some known issues with the netdevice notification handler (the list of NHLFE
> is not being maintained correctly with respect to instructions, add/delete,
> and device changes).  There was a bug report posted to general late last
> summer that had some details.
>
Ok. I will take a look at those as soon as I can get properly familiar
with the code. Can I presume that your perforce archive contains in
the mpls-kernel-1.1 directory all your latest kernel code so that I can just
do a sync from time to time to keep uptodate? Or are there any patches
elsewhere I should know about?

Steve.
 

Re: [mpls-linux-devel] RSVP-TE

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

Hello Joan and Ramon,

Its great o here that both of you are interested in working on a RSVP-TE
implementation.  I have not yet looked at vadim's code, so I do not know
the quality.

Vadim has done a lot of work that could be a time saver for Ramon,
so you can concentrate just one GMPLS extentions (maybe upstream label
allocation to :-)

Ramon are you open to atleast looking at vadim's code to see if it
is useful to you?

I would prefer that the RSVP-TE code eventually be made to work on the
same porting layer that I have put into ldp-portable, so that two
protocol could easily be ported to a new plateform, but at this point I'd
just be happy with a GPL or LGPL version that works with quagga :-)

BTW Joan, I have started working on quagga + mpls-linux 1.950.  I also
updated to quagga 0.99.2.  Make sure to update your quagga-mpls tree if
that is what your using.

On Mon, Jan 23, 2006 at 12:30:53PM +0100, Joan Ruiz wrote:
>=20
> Hi,
>=20
> As some of you might remember... there was a post some time ago from Vadim
> Suarev, who offered his RSVP-TE implementation to the Open source communi=
ty.
>=20
> I've spent some time over last months testing vadim's implementation, whi=
ch
> consisted on two new daemons for quagga (a patched 0.96 version): a te
> daemon and a rsvp daemon.
>=20
> Vadim's implementation was able to signal MPLS tunnels between Linux and
> Cisco boxes, but the code was not tightened with the MPLS forwarding. As =
far
> as I know this code is not being mantained any more.
>=20
> I've been trying to extract vadim's code from his release in order to make
> it work with newer quagga versions (starting by 98.5) but my work is on a
> very early stage.
>=20
> Maybe some parts of the already existing code would feet in your brand new
> RSVP-TE implementation. I would like to contribute to the development.
>=20
> Joan Ruiz
> jr...@sa...
>=20
>=20
> ----------------------
>=20
> Excellent news, thanks :)
>=20
> Myself, I have started a new implementation of RSVP-TE, focus is to
> implement also the GMPLS extensions as well, and add it to the MPLS for
> Linux project umbrella when it gets usable.
>=20
>=20
> Thanks
>=20
> Ramon
>=20
>=20
>=20
>=20
> -------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc. Do you grep through log fi=
les
> for problems?  Stop!  Download the new AJAX search engine that makes
> searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
> http://sel.as-us.falkag.net/sel?cmd=3Dlnk&kid=3D103432&bid=3D230486&dat=
=3D121642
> _______________________________________________
> mpls-linux-general mailing list
> mpl...@li...
> https://lists.sourceforge.net/lists/listinfo/mpls-linux-general
>=20
>=20
>=20
> -------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc. Do you grep through log fi=
les
> for problems?  Stop!  Download the new AJAX search engine that makes
> searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
> http://sel.as-us.falkag.net/sel?cmd=3Dlnk&kid=3D103432&bid=3D230486&dat=
=3D121642
> _______________________________________________
> mpls-linux-devel mailing list
> mpl...@li...
> https://lists.sourceforge.net/lists/listinfo/mpls-linux-devel

--=20
James R. Leu
jl...@mi...

Re: [mpls-linux-devel] Merging into the kernel?

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

Before the holidays I had started down path to getting mpls-linux
into the kernel (again).  I emailed jamal.  My first goal is to get the
infrastructure that mpls-linux needs to interact with L3 protocols put
in place.  Im my implementation this is the 'shim' infrastructure (look
in the devel achieves for a patch I've posted).

I sent two patches for jamal's review, davem's technique for
interacting with L3 and the mpls-linux technique.  They are very similar,
if you ask me I think the mpls-linux method is more elegant and less
intrusive.

That is where we stand.  I'm sure jamal forgot about it with the holidays
and all.  I plan on picking up this task again soon.  I was trying to get
1.950 finished (quagga support is broken still), but there is not reason
this process can't be done at the same time.

So how can others help?  Review the code.  Test the code.  In particular
the locking scheme (RCU) needs to be reviewed.  In addition there is
some known issues with the netdevice notification handler (the list of NHLFE
is not being maintained correctly with respect to instructions, add/delete,
and device changes).  There was a bug report posted to general late last
summer that had some details.

On Mon, Jan 23, 2006 at 11:13:14AM +0000, Steven Whitehouse wrote:
> Hi,
>=20
> I've been looking recently at the MPLS for Linux project as I'd like
> to see an implementation of MPLS merged into the standard Linux kernel.
> I've read a number of the mailing list archives and googled what I
> can find on the subject.
>=20
> I spotted an item in Dave M's network TODO list indicating that currently
> plans were "stuck in the mud". Is this currently still the case?
>=20
> If so then I'd like to help lend a hand in moving things forward, always
> assuming that adding another developer would be helpful of course! :-)
>=20
> Steve.
>=20
>=20
>=20
> -------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc. Do you grep through log fi=
les
> for problems?  Stop!  Download the new AJAX search engine that makes
> searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
> http://sel.as-us.falkag.net/sel?cmd=3Dlnk&kid=3D103432&bid=3D230486&dat=
=3D121642
> _______________________________________________
> mpls-linux-devel mailing list
> mpl...@li...
> https://lists.sourceforge.net/lists/listinfo/mpls-linux-devel

--=20
James R. Leu
jl...@mi...

[mpls-linux-devel] RSVP-TE

[Joan R. <jr...@sa...>]

Hi,

As some of you might remember... there was a post some time ago from Vadim
Suarev, who offered his RSVP-TE implementation to the Open source community.

I've spent some time over last months testing vadim's implementation, which
consisted on two new daemons for quagga (a patched 0.96 version): a te
daemon and a rsvp daemon.

Vadim's implementation was able to signal MPLS tunnels between Linux and
Cisco boxes, but the code was not tightened with the MPLS forwarding. As far
as I know this code is not being mantained any more.

I've been trying to extract vadim's code from his release in order to make
it work with newer quagga versions (starting by 98.5) but my work is on a
very early stage.

Maybe some parts of the already existing code would feet in your brand new
RSVP-TE implementation. I would like to contribute to the development.

Joan Ruiz
jr...@sa...


----------------------

Excellent news, thanks :)

Myself, I have started a new implementation of RSVP-TE, focus is to
implement also the GMPLS extensions as well, and add it to the MPLS for
Linux project umbrella when it gets usable.


Thanks

Ramon




-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642
_______________________________________________
mpls-linux-general mailing list
mpl...@li...
https://lists.sourceforge.net/lists/listinfo/mpls-linux-general

Re: [mpls-linux-devel] Merging into the kernel?

[Ramon C. <cas...@in...>]

On Mon, 23 Jan 2006, Steven Whitehouse wrote:

> Hi,
>
> I spotted an item in Dave M's network TODO list indicating that currently
> plans were "stuck in the mud". Is this currently still the case?

there were some issues with regard to two concurrent implementations. I
assume you read some exchanged emails, but James would be in a better
position to discuss this.

> If so then I'd like to help lend a hand in moving things forward, always
> assuming that adding another developer would be helpful of course! :-)

I must admit I did not follow what happened after, work seems to have
focused on James' implementation. Afaik, DaveM and Jamal proposed some
code, and James applied some of their ideas to mpls-linux


James?

R.

[mpls-linux-devel] Merging into the kernel?

[Steven W. <st...@ch...>]

Hi,

I've been looking recently at the MPLS for Linux project as I'd like
to see an implementation of MPLS merged into the standard Linux kernel.
I've read a number of the mailing list archives and googled what I
can find on the subject.

I spotted an item in Dave M's network TODO list indicating that currently
plans were "stuck in the mud". Is this currently still the case?

If so then I'd like to help lend a hand in moving things forward, always
assuming that adding another developer would be helpful of course! :-)

Steve.

[mpls-linux-devel] Re: [mpls-linux-general] SNMP Agent for Mpls for Linux V0 released

[Ramon C. <cas...@in...>]

On Sat, 21 Jan 2006, Josdeyvi Russi wrote:

> Hello,
>
> I just released the first version of a SNMP Agent for MPLS for Linux. You
> can find it at:
>
> http://sourceforge.net/projects/mpls-agent/



Excellent news, thanks :)

Myself, I have started a new implementation of RSVP-TE, focus is to
implement also the GMPLS extensions as well, and add it to the MPLS for
Linux project umbrella when it gets usable.


Thanks

Ramon

[mpls-linux-devel] SNMP Agent for Mpls for Linux V0 released

[Josdeyvi R. <jr...@uo...>]

Hello,

I just released the first version of a SNMP Agent for MPLS for Linux. You
can find it at:

http://sourceforge.net/projects/mpls-agent/

For now it has support for RFC 3813 (MPLS-LSR-STD) and  RFC 3814
(MPLS-FTN-STD). There is a lot of work to be done, but right now it is very
stable and works well. One can create and manage LSPs, FECs, LSR and FTN at
LER routers.

I hope this can contribute for the development of MPLS for Linux.

Thank you!

Josdeyvi Russi

Re: [mpls-linux-devel] The different between LER and LSR in MPLS-Linux-1.1

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

On Fri, Dec 09, 2005 at 10:03:38AM +0800, yaya wrote:
>=20
> hello, everyone   =09
>=20
> >
> 	We have downloaded the newest code--mpls-linux-1.1 from p4 server.  Duri=
ng debuging  the source code, we have already realize the ldp between two L=
ER for IPv4 and IPv6. the topo as below: 		        =20

Your drawing does not display cleanly in a 80 column text email client.
Please try again (hint don't use <tabs>)

>                                            ldp
>    						  =20
> 										--10000-->  key:0x2	                 =20
> 					3ffe:0:0:1::3	3ffe:0:0:1::1  3ffe:0:0:3::1
> 								|	  |					| =20
> 							host1------LER1--------LER2------host2
> 										   |      |          |
> 								3ffe:0:0:2::1 3ffe:0:0:2::2  3ffe:0:0:3::2
> 									key:0x2	<--10001---	=09
>=20
>                                                     =20
>     but when we add the enetry LSR as follow figure, we can't create XC t=
o mapping the  label. We want to know if LER and LSR have respective codes =
in the source code of mpls-linux-1.1 got from p4. How we distinguish LER an=
d LSR.

Yes ldp-portable has code to handle creating cross connects.  A simple revi=
ew
of the structures and the functions will show that.  For example=20
ldp_label_mapping_with_xc() sends a label mapping to the peer while cross
connecting it to an existing label mapping.  My guess is that the issue your
seeing is in the porting layer (the part that hooks to MPLS linux).  If
you are running this inside of quagga-mpls then simply issuing a
show mpls forwarding-table will show what LDP _wanted_ to create.

If that still doesn't look right you could try implementing a quagga
command that walks the inlabel table (ldp_cfg_inlabel_getnext()) and
looking at it's outlabel_index and then does a ldp_cfg_outlabel_get() on
that.

> 	     =20
>  					   host1------LER1--------LSR--------LER2------host2
>=20
> 	For serveral months working, we have some progress in the mpls-linux sou=
rce code. We  also want to publicize our work to everyone care the mpls lin=
ux project. How can we do?

Send me a diff between your tree and a clean ldp-portable or quagga-mpls tr=
ee.

--=20
James R. Leu
jl...@mi...

[mpls-linux-devel] The different between LER and LSR in MPLS-Linux-1.1

[yaya <ya...@ru...>]

DQpoZWxsbywgZXZlcnlvbmUgICAJDQoNCj4NCglXZSBoYXZlIGRvd25sb2FkZWQgdGhlIG5ld2Vz
dCBjb2RlLS1tcGxzLWxpbnV4LTEuMSBmcm9tIHA0IHNlcnZlci4gIER1cmluZyBkZWJ1Z2luZyAg
dGhlIHNvdXJjZSBjb2RlLCB3ZSBoYXZlIGFscmVhZHkgcmVhbGl6ZSB0aGUgbGRwIGJldHdlZW4g
dHdvIExFUiBmb3IgSVB2NCBhbmQgSVB2Ni4gdGhlIHRvcG8gYXMgYmVsb3c6IAkJICAgICAgICAg
DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgbGRwDQogICAJCQkJ
CQkgICANCgkJCQkJCQkJCQktLTEwMDAwLS0+ICBrZXk6MHgyCSAgICAgICAgICAgICAgICAgIA0K
CQkJCQkzZmZlOjA6MDoxOjozCTNmZmU6MDowOjE6OjEgIDNmZmU6MDowOjM6OjENCgkJCQkJCQkJ
fAkgIHwJCQkJCXwgIA0KCQkJCQkJCWhvc3QxLS0tLS0tTEVSMS0tLS0tLS0tTEVSMi0tLS0tLWhv
c3QyDQoJCQkJCQkJCQkJICAgfCAgICAgIHwgICAgICAgICAgfA0KCQkJCQkJCQkzZmZlOjA6MDoy
OjoxIDNmZmU6MDowOjI6OjIgIDNmZmU6MDowOjM6OjINCgkJCQkJCQkJCWtleToweDIJPC0tMTAw
MDEtLS0JCQ0KDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgIA0KICAgIGJ1dCB3aGVuIHdlIGFkZCB0aGUgZW5ldHJ5IExTUiBhcyBmb2xsb3cgZmln
dXJlLCB3ZSBjYW4ndCBjcmVhdGUgWEMgdG8gbWFwcGluZyB0aGUgIGxhYmVsLiBXZSB3YW50IHRv
IGtub3cgaWYgTEVSIGFuZCBMU1IgaGF2ZSByZXNwZWN0aXZlIGNvZGVzIGluIHRoZSBzb3VyY2Ug
Y29kZSBvZiBtcGxzLWxpbnV4LTEuMSBnb3QgZnJvbSBwNC4gSG93IHdlIGRpc3Rpbmd1aXNoIExF
UiBhbmQgTFNSLg0KCSAgICAgIA0KIAkJCQkJICAgaG9zdDEtLS0tLS1MRVIxLS0tLS0tLS1MU1It
LS0tLS0tLUxFUjItLS0tLS1ob3N0Mg0KDQoJRm9yIHNlcnZlcmFsIG1vbnRocyB3b3JraW5nLCB3
ZSBoYXZlIHNvbWUgcHJvZ3Jlc3MgaW4gdGhlIG1wbHMtbGludXggc291cmNlIGNvZGUuIFdlICBh
bHNvIHdhbnQgdG8gcHVibGljaXplIG91ciB3b3JrIHRvIGV2ZXJ5b25lIGNhcmUgdGhlIG1wbHMg
bGludXggcHJvamVjdC4gSG93IGNhbiB3ZSBkbz8NCgkJDQoNCg0KICANCqGhoaGhoaGhoaGhoaGh
oaFseW4NCqGhoaGhoaGhoaGhoaGhoaFseW5AbTE2NS5jb20NCqGhoaGhoaGhoaGhoaGhoaGhoaGh
MjAwNS0xMi0wOSANCg==

Re: [mpls-linux-devel] LSP Ping

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

I'm not sure you need a dst structure. (maybe I'm missing something
though)  Are you using the latest code from my development tree or are
you looking at 1.946 code?

If you're looking at the latest unreleased code (1.950) look at how
ebt_mpls.c(**) works.  This module is use by ebtables to do Ethernet over
MPLS.  The only piece of config coming from userland is the nhlfe key.
=46rom that I lookup the NHLFE and store a reference to the NHLFE.  Traffic
handled by ebtables does not have a skb->dst pointer.  To forward the
packet on a LSP it simply calls mpls_output_shim().

(**) linux/net/bridge/netfilter/ebt_mpls.c

On Wed, Dec 07, 2005 at 05:50:50AM -0800, Timothy Vann wrote:
> I'm starting to work through this and I'm not sure the best place to get =
the
> dst structure from for self originated LSP ping packets.  Any thoughts?
> Ideally, I think user space code would send down a fully formatted packet
> that just needs to have the appropriate NHLFE applied and sent out.  Coul=
d I
> get the dst struct needed if the user code supplied a dev index?
>=20
> Thanks,
> Tim
>=20
> -----Original Message-----
> From: James R. Leu [mailto:jl...@mi...]=20
> Sent: Thursday, November 17, 2005 10:27 AM
> To: Timothy Vann
> Cc: mpl...@li...
> Subject: Re: [mpls-linux-devel] LSP Ping
>=20
> As far as I know nothing can from those discussions.  I would be
> happy to help someone who is willing to work on it.
>=20
> On Thu, Nov 17, 2005 at 07:21:58AM -0800, Timothy Vann wrote:
> > I saw an earlier post where someone was asking about how to do LSP ping.
> > Just wondering if anyone knows if any work has been done toward that?  =
And
> > if so, where can I find the code?
> >=20
> > =20
> >=20
> > Thanks,
> >=20
> > Tim
> >=20
>=20
> --=20
> James R. Leu
> jl...@mi...

--=20
James R. Leu
jl...@mi...

Re: [mpls-linux-devel] linux-kernel-2.6.14

[Bob B. <bob...@gm...>]

On 12/7/05, James R. Leu <jl...@mi...> wrote:
> The bug you're seeing is one I fixed in change 1310.  Could you make sure=
 your
> iproute-mpls tree has that change.
>
>     cd iproute-mpls
>     p4 changes ... | more
>
> The '...' tells p4 to only consider files in this part of the depot
> (remember your client has just a small view of the depot, without '...'
>  you would get all changes submitted to the depot)


bbeers@alakazam:~/download/perforce/p4client/iproute2$ ../../p4 -c
bbeers:iproute2-mpls changes ... | more
Change 1311 on 2005/11/23 by jleu@jleu:iproute2-mpls 'Fixes to compile
against 2.6.15'
Change 1310 on 2005/11/23 by jleu@jleu:iproute2-mpls 'Finish
converting from SHIM to '
Change 1302 on 2005/11/17 by jleu@jleu:iproute2-mpls 'Allow for using
an environment '
Change 1301 on 2005/11/17 by jleu@jleu:iproute2-mpls 'Convert to
generic netlink syst'
Change 1288 on 2005/11/01 by jleu@jleu:iproute2-mpls 'Update mpls.h to
latest from mp'
Change 1285 on 2005/10/25 by jleu@jleu:iproute2-mpls 'Correctly parse
the args for 'p'
Change 1280 on 2005/10/21 by jleu@jleu:iproute2-mpls 'Add support for
packet nexthops'
Change 1278 on 2005/10/21 by jleu@jleu:iproute2-mpls 'Update the help
to reflect the '
Change 1277 on 2005/10/21 by jleu@jleu:iproute2-mpls 're-enable tunnel
commands, but '
Change 1268 on 2005/10/15 by jleu@jleu:iproute2-mpls 'make sure
mpls/mpls get added t'
Change 1264 on 2005/10/14 by jleu@jleu:iproute2-mpls 'integ RPM build
infrastructure '
Change 1258 on 2005/10/14 by jleu@jleu:iproute2-mpls 'my currenty shim
target work gr'
Change 1249 on 2005/10/09 by jleu@jleu:iproute2-mpls 'Change shim
parsing.  Now the d'
Change 1248 on 2005/10/09 by jleu@jleu:iproute2-mpls 'Use the new
change flag to conv'
Change 1236 on 2005/10/04 by jleu@jleu:iproute2-mpls 'Fix the dump processi=
ng '
Change 1229 on 2005/09/19 by jleu@jleu:iproute2-mpls 'Switch from
RTA_SPEC_* to RTA_S'
Change 1227 on 2005/09/16 by jleu@jleu:iproute2-mpls 'Convert
mpls_monitor to SHIM '
Change 1226 on 2005/09/16 by jleu@jleu:iproute2-mpls 'Modify makefile
to compile the '
Change 1225 on 2005/09/16 by jleu@jleu:iproute2-mpls 'Convert mpls
utility to use SHI'
Change 1224 on 2005/09/16 by jleu@jleu:iproute2-mpls 'Add MPLS and
SHIM related userl'
Change 1223 on 2005/09/16 by jleu@jleu:iproute2-mpls 'Update rtnetlink
with RTM_SHIM '
Change 1192 on 2005/08/25 by jleu@jleu:iproute2-mpls 'Integrate
changes for FC4's ipr'
Change 1157 on 2005/05/25 by jleu@jleu:iproute2-mpls-1.1 'This patch
is from Vincent Untz'
Change 1076 on 2005/01/22 by jleu@jleu:iproute2-mpls-1.1 'Add
mpls-linux version to the o'
Change 1066 on 2005/01/13 by jleu@jleu:iproute2-mpls-1.1 'I forgot to
convert ALL the tun'
Change 1056 on 2005/01/08 by jleu@jleu:iproute2-mpls-1.1 'Clean up the
traffic stats outp'
Change 1053 on 2005/01/06 by jleu@jleu:iproute2-mpls-1.1 'Convert to
use mpls_tunnel_req '
Change 1051 on 2005/01/05 by jleu@jleu:iproute2-mpls-1.1 'remove
mpls_util.[ch] we do not'
Change 1045 on 2005/01/04 by jleu@jleu:iproute2-mpls-1.1 'Implement
the rest of the MPLS '
Change 1040 on 2004/12/30 by jleu@jleu:iproute2-mpls-1.1
'Conditionally define AF_MPLS '
Change 1039 on 2004/12/30 by jleu@jleu:iproute2-mpls-1.1 'Switch to
use AF_MPLS instead o'
Change 1038 on 2004/12/30 by jleu@jleu:iproute2-mpls-1.1 'use AF_MPLS
instead of PF_MPLS '
Change 1037 on 2004/12/30 by jleu@jleu:iproute2-mpls-1.1 'Add special
nexthop defines and'
Change 1036 on 2004/12/22 by jleu@jleu:iproute2-mpls-1.1 'Integrate
changes for iproute 2'
Change 988 on 2004/11/02 by jleu@jleu:iproute2-mpls-1.1 'Only get an
answer when adding '
Change 987 on 2004/11/02 by jleu@jleu:iproute2-mpls-1.1 'Correct
handling of command lin'
Change 931 on 2004/10/10 by jleu@jleu:iproute2-mpls-1.1 'mpls monitor
will only show net'
Change 930 on 2004/10/10 by jleu@jleu:iproute2-mpls-1.1 'Fix the
install target for the '
Change 912 on 2004/09/29 by jleu@jleu:iproute2-mpls-1.1 'get rid of
do_mpls(), do the do'
Change 906 on 2004/09/23 by jleu@jleu:iproute2-mpls-1.1 'First cut at
a mpls monitor '
Change 867 on 2004/09/09 by jleu@jleu:iproute2-mpls-1.1 'Submitted by
Christophe Fillot '
Change 832 on 2004/08/25 by jleu@jleu:iproute2-mpls-1.1 'Fix nexthop
address handling Re'
Change 819 on 2004/08/04 by jleu@jleu:iproute2-mpls-1.1 'Add dumping
instructions to the'
Change 817 on 2004/08/04 by jleu@jleu:iproute2-mpls-1.1 'Add netlink
support for add/del'
Change 769 on 2004/07/13 by jleu@jleu:iproute2-mpls-1.1 'Update to
iproute-2.4.7-14 (fed'
Change 459 on 2003/11/18 by jleu@jleu:iproute2-mpls-1.1 'Branch from
iproute2-mpls for c'
bbeers@alakazam:~/download/perforce/p4client/iproute2$

does this mean I do or don't have the changes????

>
> Also I did some work tonight on modules.  I was able to compile
> mpls, mpls_tunnel, mpls4, mpls6, ipt_mpls, ebt_mpls as modules
> and load them in the correct order and get a functional MPLS stack.
> So make sure to sync your mpls-kernel tree and rebuild (optionally
> with MPLS compiled as a module)

Great! I'll give it a try, I would prefer modules, as I have different
 targets with only one (so far) wanting MPLS.

This thread no longer matches the subject, would you prefer I
 start anew in mpls-linux-users?

--
-Bob

RE: [mpls-linux-devel] LSP Ping

[Timothy V. <tv...@ex...>]

I'm starting to work through this and I'm not sure the best place to get the
dst structure from for self originated LSP ping packets.  Any thoughts?
Ideally, I think user space code would send down a fully formatted packet
that just needs to have the appropriate NHLFE applied and sent out.  Could I
get the dst struct needed if the user code supplied a dev index?

Thanks,
Tim

-----Original Message-----
From: James R. Leu [mailto:jl...@mi...] 
Sent: Thursday, November 17, 2005 10:27 AM
To: Timothy Vann
Cc: mpl...@li...
Subject: Re: [mpls-linux-devel] LSP Ping

As far as I know nothing can from those discussions.  I would be
happy to help someone who is willing to work on it.

On Thu, Nov 17, 2005 at 07:21:58AM -0800, Timothy Vann wrote:
> I saw an earlier post where someone was asking about how to do LSP ping.
> Just wondering if anyone knows if any work has been done toward that?  And
> if so, where can I find the code?
> 
>  
> 
> Thanks,
> 
> Tim
> 

-- 
James R. Leu
jl...@mi...

Re: [mpls-linux-devel] linux-kernel-2.6.14

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

The bug you're seeing is one I fixed in change 1310.  Could you make sure y=
our
iproute-mpls tree has that change.

    cd iproute-mpls
    p4 changes ... | more

The '...' tells p4 to only consider files in this part of the depot
(remember your client has just a small view of the depot, without '...'
 you would get all changes submitted to the depot)

Also I did some work tonight on modules.  I was able to compile
mpls, mpls_tunnel, mpls4, mpls6, ipt_mpls, ebt_mpls as modules
and load them in the correct order and get a functional MPLS stack.
So make sure to sync your mpls-kernel tree and rebuild (optionally
with MPLS compiled as a module)

On Tue, Dec 06, 2005 at 05:06:03PM -0500, Bob Beers wrote:
> On 12/6/05, James R. Leu <jl...@mi...> wrote:
> > You're getting bitten by my lack of new documentation.
> >
> > With the iproute2 that is in the dev tree there is a new
> > syntax.  Looking at the output of 'ip route help' would have helped you,
> > but here it the new syntax you want to use:
> >
> >     ip route add 10.0.0.0/16 via 192.168.1.1 mpls 0x2
> >
>=20
> ok, thanks, I get a step further
>=20
> root@alakazam:~# /usr/sbin/ip route add 172.16.87.21/32 via
> 172.16.87.21 mpls 0x2
>=20
> does not complain but,
>=20
> root@alakazam:~# /usr/sbin/mpls nhlfe show
>=20
> just sits there and doesn't return.
>=20
> root@alakazam:~# tail -n 30 /var/log/debug
> Dec  6 16:59:51 alakazam kernel: MPLS DEBUG
> net/mpls/mpls_netlink.c:398:genl_mpls_nhlfe_dump: Enter: entry 0
> Dec  6 16:59:51 alakazam kernel: MPLS DEBUG
> net/mpls/mpls_netlink.c:402:genl_mpls_nhlfe_dump: Dump: entry 0
> Dec  6 16:59:51 alakazam kernel: MPLS DEBUG
> net/mpls/mpls_netlink.c:249:mpls_fill_nhlfe: enter
> Dec  6 16:59:51 alakazam kernel: MPLS DEBUG
> net/mpls/mpls_netlink.c:49:mpls_copy_instr: enter
> Dec  6 16:59:51 alakazam kernel: MPLS DEBUG
> net/mpls/mpls_opcode.c:364:mpls_unbuild_opcode_push: enter
> Dec  6 16:59:51 alakazam kernel: MPLS DEBUG
> net/mpls/mpls_opcode.c:369:mpls_unbuild_opcode_push: exit
> Dec  6 16:59:51 alakazam kernel: MPLS DEBUG
> net/mpls/mpls_opcode.c:1109:mpls_unbuild_opcode_set: enter
> Dec  6 16:59:51 alakazam kernel: MPLS DEBUG
> net/mpls/mpls_opcode.c:1115:mpls_unbuild_opcode_set: exit
> Dec  6 16:59:51 alakazam kernel: MPLS DEBUG
> net/mpls/mpls_netlink.c:63:mpls_copy_instr: exit
> Dec  6 16:59:51 alakazam kernel: MPLS DEBUG
> net/mpls/mpls_netlink.c:266:mpls_fill_nhlfe: exit
> Dec  6 16:59:51 alakazam kernel: MPLS DEBUG
> net/mpls/mpls_netlink.c:419:genl_mpls_nhlfe_dump: Exit: entry 1
> Dec  6 16:59:51 alakazam kernel: MPLS DEBUG
> net/mpls/mpls_netlink.c:398:genl_mpls_nhlfe_dump: Enter: entry 1
> Dec  6 16:59:51 alakazam kernel: MPLS DEBUG
> net/mpls/mpls_netlink.c:402:genl_mpls_nhlfe_dump: Dump: entry 0
> Dec  6 16:59:51 alakazam kernel: MPLS DEBUG
> net/mpls/mpls_netlink.c:419:genl_mpls_nhlfe_dump: Exit: entry 1
>=20
>=20
>=20
> > If you plan on using the iptables from my dev tree, there is a new
> > syntax for that as well:
> >
> >     iptables -A OUTPUT -d 10.0.0.1/32 -j mpls --nhlfe=3D0x2
> >
>=20
> yes, I will need this as well, but first things first. :)
>=20
> > In the dev tree there is also support for ebtables, if you plan
> > on doing ethernet over MPLS.  I have an example I can send you if
> > you're interested.
> >
> > Version 1.950 also supports PHP. The same feature can
> > be used to prevent an IP lookup on the egress LER.
> >
> > The mpls_tunnel interface has also changed in 1.950.  Since I told
> > you to make MPLS static in the kernel, you will only have one
> > tunnel interface.  Once I fix the module loading (or add a new config
> > item for the MPLS tunnel interface) then you will be able to load the
> > module multiple times for multiple tunnel interfaces.
> >
>=20
> I will live with one tunnel while I get to know this stuff.
>=20
> > I'm probably forgetting something, let me know if you run into more
> > problems.
> >
> > BTW look at the output of 'dmesg' for some insight as to what is
> > happening inside of the MPLS code.  If you want to turn that off
> > just do 'echo 0 > /sys/mpls/debug'
> >
>=20
> wilco.
> <snip old message>
>=20
>=20
> -------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc. Do you grep through log fi=
les
> for problems?  Stop!  Download the new AJAX search engine that makes
> searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
> http://ads.osdn.com/?ad_idv37&alloc_id=16865&op?k
> _______________________________________________
> mpls-linux-devel mailing list
> mpl...@li...
> https://lists.sourceforge.net/lists/listinfo/mpls-linux-devel

--=20
James R. Leu
jl...@mi...

Re: [mpls-linux-devel] linux-kernel-2.6.14

[Bob B. <bob...@gm...>]

On 12/6/05, James R. Leu <jl...@mi...> wrote:
> You're getting bitten by my lack of new documentation.
>
> With the iproute2 that is in the dev tree there is a new
> syntax.  Looking at the output of 'ip route help' would have helped you,
> but here it the new syntax you want to use:
>
>     ip route add 10.0.0.0/16 via 192.168.1.1 mpls 0x2
>

ok, thanks, I get a step further

root@alakazam:~# /usr/sbin/ip route add 172.16.87.21/32 via
172.16.87.21 mpls 0x2

does not complain but,

root@alakazam:~# /usr/sbin/mpls nhlfe show

just sits there and doesn't return.

root@alakazam:~# tail -n 30 /var/log/debug
Dec  6 16:59:51 alakazam kernel: MPLS DEBUG
net/mpls/mpls_netlink.c:398:genl_mpls_nhlfe_dump: Enter: entry 0
Dec  6 16:59:51 alakazam kernel: MPLS DEBUG
net/mpls/mpls_netlink.c:402:genl_mpls_nhlfe_dump: Dump: entry 0
Dec  6 16:59:51 alakazam kernel: MPLS DEBUG
net/mpls/mpls_netlink.c:249:mpls_fill_nhlfe: enter
Dec  6 16:59:51 alakazam kernel: MPLS DEBUG
net/mpls/mpls_netlink.c:49:mpls_copy_instr: enter
Dec  6 16:59:51 alakazam kernel: MPLS DEBUG
net/mpls/mpls_opcode.c:364:mpls_unbuild_opcode_push: enter
Dec  6 16:59:51 alakazam kernel: MPLS DEBUG
net/mpls/mpls_opcode.c:369:mpls_unbuild_opcode_push: exit
Dec  6 16:59:51 alakazam kernel: MPLS DEBUG
net/mpls/mpls_opcode.c:1109:mpls_unbuild_opcode_set: enter
Dec  6 16:59:51 alakazam kernel: MPLS DEBUG
net/mpls/mpls_opcode.c:1115:mpls_unbuild_opcode_set: exit
Dec  6 16:59:51 alakazam kernel: MPLS DEBUG
net/mpls/mpls_netlink.c:63:mpls_copy_instr: exit
Dec  6 16:59:51 alakazam kernel: MPLS DEBUG
net/mpls/mpls_netlink.c:266:mpls_fill_nhlfe: exit
Dec  6 16:59:51 alakazam kernel: MPLS DEBUG
net/mpls/mpls_netlink.c:419:genl_mpls_nhlfe_dump: Exit: entry 1
Dec  6 16:59:51 alakazam kernel: MPLS DEBUG
net/mpls/mpls_netlink.c:398:genl_mpls_nhlfe_dump: Enter: entry 1
Dec  6 16:59:51 alakazam kernel: MPLS DEBUG
net/mpls/mpls_netlink.c:402:genl_mpls_nhlfe_dump: Dump: entry 0
Dec  6 16:59:51 alakazam kernel: MPLS DEBUG
net/mpls/mpls_netlink.c:419:genl_mpls_nhlfe_dump: Exit: entry 1



> If you plan on using the iptables from my dev tree, there is a new
> syntax for that as well:
>
>     iptables -A OUTPUT -d 10.0.0.1/32 -j mpls --nhlfe=3D0x2
>

yes, I will need this as well, but first things first. :)

> In the dev tree there is also support for ebtables, if you plan
> on doing ethernet over MPLS.  I have an example I can send you if
> you're interested.
>
> Version 1.950 also supports PHP. The same feature can
> be used to prevent an IP lookup on the egress LER.
>
> The mpls_tunnel interface has also changed in 1.950.  Since I told
> you to make MPLS static in the kernel, you will only have one
> tunnel interface.  Once I fix the module loading (or add a new config
> item for the MPLS tunnel interface) then you will be able to load the
> module multiple times for multiple tunnel interfaces.
>

I will live with one tunnel while I get to know this stuff.

> I'm probably forgetting something, let me know if you run into more
> problems.
>
> BTW look at the output of 'dmesg' for some insight as to what is
> happening inside of the MPLS code.  If you want to turn that off
> just do 'echo 0 > /sys/mpls/debug'
>

wilco.
<snip old message>

Re: [mpls-linux-devel] linux-kernel-2.6.14

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

You're getting bitten by my lack of new documentation.

With the iproute2 that is in the dev tree there is a new
syntax.  Looking at the output of 'ip route help' would have helped you,
but here it the new syntax you want to use:

    ip route add 10.0.0.0/16 via 192.168.1.1 mpls 0x2

If you plan on using the iptables from my dev tree, there is a new
syntax for that as well:

    iptables -A OUTPUT -d 10.0.0.1/32 -j mpls --nhlfe=3D0x2

In the dev tree there is also support for ebtables, if you plan
on doing ethernet over MPLS.  I have an example I can send you if
you're interested.

Version 1.950 also supports PHP. The same feature can
be used to prevent an IP lookup on the egress LER.

The mpls_tunnel interface has also changed in 1.950.  Since I told
you to make MPLS static in the kernel, you will only have one
tunnel interface.  Once I fix the module loading (or add a new config
item for the MPLS tunnel interface) then you will be able to load the
module multiple times for multiple tunnel interfaces.

I'm probably forgetting something, let me know if you run into more
problems.

BTW look at the output of 'dmesg' for some insight as to what is
happening inside of the MPLS code.  If you want to turn that off
just do 'echo 0 > /sys/mpls/debug'

On Tue, Dec 06, 2005 at 04:31:46PM -0500, Bob Beers wrote:
> Hi James,
>=20
> Thanks for the p4 hints.
>=20
> I have made some progress in your dev tree.
> I have built and booted into an mpls enabled kernel.
>=20
> But when I try to run through the MPLS-Linux example, here
>  are the results:
>=20
> bash-3.00# cat /sys/mpls/version
> 1.950
> bash-3.00# cat /sys/mpls/debug
> 1
> bash-3.00# /usr/sbin/mpls nhlfe add key 0
> NHLFE entry key 0x00000002 mtu 0 propagate_ttl
>          (0 bytes, 0 pkts)
> bash-3.00# /usr/sbin/mpls nhlfe change key 0x2 instructions push gen
> 10000 nexthop eth0 ipv4 172.16.87.21
> bash-3.00# /usr/sbin/ip route add 172.16.87.21/32 via 172.16.87.21
> spec_nh 0x8847 0x2
> Error: either "to" is duplicate, or "spec_nh" is a garbage.
> bash-3.00#
>=20
>=20
> I did recompile the iproute2 files after rebooting into my new kernel.
> I did edit the Makefile, ran make and make install (as root).
> What did I miss? How do I troubleshoot?
>=20
> Thanks,
>=20
> --
> -Bob

--=20
James R. Leu
jl...@mi...