Re: [mpls-linux-general] Some questions
Status: Beta
Brought to you by:
jleu
Menu
▾
▴
Re: [mpls-linux-general] Some questions
|
From: Javier L. <jml...@gm...> - 2008-02-18 14:12:47
|
James,
Thank you for your answer.
2008/2/16, James R. Leu <jl...@mi...>:
> Javier,
>
> Thank you for trying MPLS Linux. I've answered your questions in-line.
> Please continue to send any questions you have to the mpls-linux-general
> mailing list and I or others will do our best to answer your questions.
>
> On Fri, Feb 15, 2008 at 03:55:47PM +0100, Javier Lorenzo wrote:
> > First of all, I'm working with mpls-1.950 on fc4 and I think these
> > things aren't working well.
> > I don't know if they work on newer releases.
> >
> > 1.
> > I can add instructions to labelspace 0, but I can't to others:
> > [root@localhost ~]# mpls ilm add label gen 100 labelspace 0
> > instructions forward 0x2
> > [root@localhost ~]# mpls ilm add label gen 100 labelspace 2
> > instructions forward 0x2
> > RTNETLINK answers: No such process
>
> I encourage you to upgrade to Fedora 7 or 8 and use the latest
> packages available.
>
> [root@mpls8-1 ~]# mpls ilm add label gen 100 labelspace 2
> [root@mpls8-1 ~]# mpls ilm add label gen 100 labelspace 0
> [root@mpls8-1 ~]# mpls ilm show
> ILM entry label gen 100 labelspace 0 proto ipv4
> pop peek (0 bytes, 0 pkts)
> ILM entry label gen 100 labelspace 2 proto ipv4
> pop peek (0 bytes, 0 pkts)
> [root@mpls8-1 ~]# uname -a
> Linux mpls8-1 2.6.23.15-137.fc8.mpls.1.960 #1 SMP Thu Feb 14 00:08:42 EST 2008 i686 i686 i386 GNU/Linux
> [root@mpls8-1 ~]#
>
I don't mind if it don't work in this release, but I thougth it could
help with debugging.
If I do
mpls ilm add label gen 200 labelspace 2
it works well, but when I try to add some instructions:
[root@localhost ~]# mpls ilm add label gen 200 labelspace 2
instructions pop set-exp 0x3 forward 0x2
RTNETLINK answers: No such process
[root@localhost ~]# mpls ilm add label gen 200 labelspace 0
instructions pop set-exp 0x3 forward 0x2
[root@localhost ~]# mpls ilm add label gen 200 labelspace 2
instructions pop set-exp 0x3 forward 0x2
[root@localhost ~]# mpls ilm show
ILM entry label gen 200 labelspace 2 proto ipv4
pop peek (0 bytes, 0 pkts)
ILM entry label gen 200 labelspace 0 proto ipv4
pop set-exp 3 forward key 0x00000002 (0 bytes, 0 pkts)
If I want to add the label to a labelspace per interface, and I want
to do something (not the default pop), I get an error. If I add that
label to the labelspace 0 before, I don't get the error, but the
result is the default pop.
> > 2.
> > I have a problem when I try to add a label to a packet that already
> > carries one (only one).
> > In the LSR, I do:
> > mpls nhlfe add key 0 instructions push gen 2000 nexthop eth0 ipv4 10.6.44.6
> > mpls ilm add label gen 1000 instructions forward 0x2
> >
> > And in the ingress LER I do:
> > mpls nhlfe change key 0x2 instructions push gen 500 push gen 1000
> > nexthop eth0 ipv4 10.6.44.2
> > or:
> > mpls nhlfe change key 0x2 instructions push gen 1000 nexthop eth0 ipv4 10.6.44.2
> >
> > In the first case, there isn't any problems, but in the second, the S
> > bit in the MPLS header
> > with the label 2000 is set to 1. And it must be 0.
> > I know that I can pop the label 1000 and push it again, solving the
> > problem; but if I want
> > to merge some LSP in that tunnel, I have to repeat the nhlfe line for each LSP.
> > And I think it isn't the desired behaviour.
>
> push without pop is not supported and it against RFC 3031. By doing
> a push without pop your exposing nodes further along the LSP to labels
> they have not assigned.
>
> A ----> B -----> C
>
> In this picture the arrows represent the direction the packets are flowing.
> Currently the only form of label allocation that is standardized is down
> stream label allocation which mean the next hop peer assigns the label
> on which a MPLS speaker can sent traffic. In other words, B assigns labels
> for which A can send traffic to B. By doing a push without pop, you are
> exposing some node beyond B to labels for which it did do assign.
>
> If you are trying to accomplish label stacking such as is found in MPLS BGP
> VPNs or by-pass tunnels, then you will want to utilize the the 'forward'
> instruction on a NHLFE to product layers of indirection.
>
> ILM (peek,pop,fwd) -> NHLFE (push,fwd) -> NHLFE (push,nexthop)
>
>
Ok. All right.
> > 3.
> > I don't know how to use
> > set-rx-if <NAME> forward <KEY>
> > I tried this:
> > [root@localhost ~]# mpls ilm add label gen 255 instructions set-rx-if
> > eth0 forward 0x2
> > RTNETLINK answers: Operation not permitted
>
> set-rx-if is used to set the interface you want to the kernel to believe
> the packet arrived on. It can be used in combination with the MPLS tunnel
> interface to provide a bi-direction interface (MPLS tunnel interfaces are
> uni-directional since they represent a uni-directional LSP).
>
> I believe set-rx-if must be the last instruction.
>
I'm sorry. The command I wrote was right, but I forgot to set the
interface into the labelspace. I've tried it with the tunnel interface
and it works well. Thank you very much.
But I'm a bit confused with the tunnel interface. When or why is it useful?
If I send traffic trought the mpls0 interface I have to do,
mpls tunnel set dev mpls0 nhlfe KEY
but I can forward traffic to that nhlfe key without the mpls0 interface.
And when I use set-rx-if and the kernel thinks the traffic comes
throught the mpls0 interface:
if I'm going to do a MPLS forward I don't need the information;
if I'm going to do a IP forward, I can do it with ILM(pop,
forward)-->NHLFE(nexthop) or ILM(pop) and after an IP search.
> > Thank you.
> > --
> > Javier Lorenzo
> >
> > -------------------------------------------------------------------------
> > This SF.net email is sponsored by: Microsoft
> > Defy all challenges. Microsoft(R) Visual Studio 2008.
> > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> > _______________________________________________
> > mpls-linux-general mailing list
> > mpl...@li...
> > https://lists.sourceforge.net/lists/listinfo/mpls-linux-general
>
> --
> James R. Leu
> jl...@mi...
>
|
