RE: [mpls-linux-general] Problems in configuring multiple LSPs on same physical link

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

When I give another route to the same destination IP address with different
label, then I get the RTNETLINK error message: file exists. So I assume that
there is something wrong with iproute2. below are my configuration commands:

---MPLS commands @ ingress-----

./mplsadm2 -A -0 0
./mplsadm2 -0 0x2 -o push:gen:60:set:eth0:ipv4: 172.16.1.2
./mplsadm2 -A -0 0
./mplsadm2 -0 0x3 -o push:gen:70:set:eth0:ipv4: 172.16.1.2

------iproute2 commands @ ingress-----

./ip route add 192.168.11.2/32 via 172.16.1.2 spec_nh 0x8847 0x2
./ip route add 192.168.11.2/32 via 172.16.1.2 spec_nh 0x8847 0x3
RTNETLINK answers: file exists

Is this because in both cases, the next hop is same, but for me this is
necessary, cuz this is what I want to do:

Ingress------------------LSR---------LSR1
			\
			  \
			    \
  			      \
		            	    LSR2

Muhammad R. Sami 
Research Assistant, 
Computer Engineering Department 
P.O.Box 354 
King Fahd University of Petroleum & Minerals 
Dhahran 31261 
Saudi Arabia. 
Tel: +96638601423 
Cell: +96657982951 
www.ccse.kfupm.edu.sa/sami
-----Original Message-----
From: James R. Leu [mailto:jl...@mi...] 
Sent: Sunday, July 11, 2004 5:52 AM
To: Muhammad R. Sami
Cc: mpl...@li...
Subject: Re: [mpls-linux-general] Problems in configuring multiple LSPs on
same physical link

Can you send me the commands you are issuing and the MPLS kernel debugging
from when thoses commads are issued?

On Sat, Jul 10, 2004 at 05:10:37AM +0300, Muhammad R. Sami wrote:
> I am having problems in configuring multiple LSPs on the same physical
link
> destined to a single IP address (hop).  The message I get is "RTNETLI NK:
> File exists". Am I doing something wrong or is this not possible. If it is
> not possible to configure multiple LSPs to a single IP address on the same
> physical link, can I use virtual links to accomplish this task?
> Regards,
> 
> Muhammad R. Sami 
> Research Assistant, 
> Computer Engineering Department 
> P.O.Box 354 
> King Fahd University of Petroleum & Minerals 
> Dhahran 31261 
> Saudi Arabia. 
> Tel: +96638601423 
> Cell: +96657982951 
> www.ccse.kfupm.edu.sa/sami
> -----Original Message-----
> From: mpl...@li...
> [mailto:mpl...@li...] On Behalf Of James
> R. Leu
> Sent: Thursday, July 08, 2004 5:34 PM
> To: Rafael Paoliello Guimaraes
> Cc: mpl...@li...
> Subject: Re: [mpls-linux-general] Trying to understand mpls-linux...
> 
> Hello Rafael,
> 
> See my response inline ....
> 
> On Thu, Jul 08, 2004 at 01:29:54PM +0200, Rafael Paoliello Guimaraes
wrote:
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> > 
> > Hello,
> > 
> > First of all, thanks for the prompt reply! Second, sorry for the
> > tag-switching, but the MPLS mechanism is somehow similar to a
> > tag-switching and that's why I used the expression...
> > 
> > Well, in fact I am looking at the 1.922 version, which is the last
> > available at sourceforge. But it was quite simple to follow the code
> > using your instructions. Thank you. But there are a couple of things I
> > still didn't understand.
> > 
> > 1 - In the mpls_output2 function, the output interface is supposed to be
> > known and to complete the forwarding process, you just need to switch
> > the label and send the packet to the destination interface. Is it
> > correct? I didn't understand why could we have an operation that returns
> > MPLS_RESULT_FWD.
> 
> This is a piece of code that is needed to support more sophisticated label
> forwarding.  When you see MPLS_RESULT_FWD in the output path, it is there
> to handle the case where a NHLFE uses a NHLFE as the next hop (ie
> hierarchical LSPs).  There are two ways to achieve hierarchy, one way is
> to push multiple labels, the other is to chain NHLFE.  The later fits well
> with the case where different MPLS signaling protocols learn about a
> separate
> label in hierarchy.
> 
> > 2 - Probably a stupid question, but why are the MOIs organized in a
> > radix tree if they are directly linked to a MII? I mean, once the MII is
> > ~ identified, the MOI can be directly obtained without searching in the
> > MOI radix tree...
> 
> They need to be stored some where so the user interface can find them :-)
> (ie add/delete/bind all refer to NHLFE via an index, the index is the
> key in to the tree)
> 
> > 3 - In the MII structure there is a list of MOIs (struct list_head
> > ~       moi_entry). What is this? The same happens in the MOIs
structure,
> > where there is a list o MOIs? I thought that for each MII there was only
> > one associated MOI...
> 
> This is not part of the forwarding path, these lists are required as part
> of the error handling.  If the outgoing interface used by a NHLFE is
> removed from the system, the NHLFE must be deleted and we need to notify
> all of the ILM that link to the NHLFE that it is going away.
> 
> > Sorry for bothering you so much, but I would really link to understand
> > this topics... And thank you again.
> > 
> > Best regards,
> > 
> > ===========================================
> > ~ Rafael Paoliello Guimaraes
> > ~ PhD Student - Computer Networking Group
> > ~ Department of Computer Architecture (DAC)
> > ~ Polytechnic University of Catalonia (UPC)
> > ~ Phone: +34-934017187   Fax: +34-934017055
> > ~ URL: http://people.ac.upc.es/rpaoliel
> > ===========================================
> > 
> > 
> > James R. Leu wrote:
> > | Hello,
> > |
> > | First of all it's not 'tag-switching' ;-)
> > |
> > | Your basic understanding of what is happening is correct.
> > | What version of mpls linux are you working with?  I'm going to point
you
> > | at code in 1.930.
> > |
> > | When mpls-linux initialized (see
> net/mpls/mpls_init.c:mpls_init_module())
> > | it registers with the network stack that any packets with protocol ID
> > | 0x8847 are to be sent to the function
> > net/mpls/mpls_input.c:mpls_skb_recv().
> > | After mpls_skb_recv() has prepared the necessary data structures and
> > extracted
> > | the top label (not popped, just extracts) it hands the skb off to
> > mpls_input().
> > | mpls_input() does an ILM lookup, then processes the instructions for
> > the ILM.
> > | (one of the instructions is probably a POP) If the last instruction
> > was DLV
> > | or PEEK and there are no more labels, the packet is delivered locally
to
> > | layer 3.  If the last instruction is FWD, the packet is label
> > switched.  The
> > | FWD instructions contains a pointer to the NHLFE that will push the
> > new label
> > | and TX the skb on the outgoing interface.  The FWD instruction is
built
> in
> > | net/mpls/mpls_opcode_all.c:mpls_build_opcode_fwd(), which is called
> > when the
> > | users binds a ILM to a NHLFE.  mpls_build_opcode_fwd() looks up a
> > NHLFE via
> > | the index the user provides.  So as you see there is not a NHLFE
lookup
> > | while the packet is being forwarded.  The only lookup that occurs is
to
> > | find the ILM, from that point no further lookups will occur until the
> > packet
> > | hits layer 3 (or the next hop does it's ILM lookup).
> > |
> > | I hope this give you a better understanding of how a packet gets to
> > | mpls_output().  Let me know if you have any further questions.
> > |
> > |
> > | On Wed, Jul 07, 2004 at 05:24:57PM +0200, Rafael Paoliello Guimaraes
> > wrote:
> > |
> > | Hello All,
> > |
> > | I am trying to figure out the basic idea of the mpls-linux
> > | implementation. I have read the "MPLS for Linux Developers' Guide" but
I
> > | still have some doubts, in fact I didn't understand how label
switching
> > | is done (I think I missed the more important part!).
> > |
> > | Well, as far as I understood, the device struct of network interfaces
> > | are extended, so that whenever a packet arrives, a callback function
> > | (mpls_in) is called. This function looks for the received label in the
> > | MII radix tree and gets information about the label. Then, if the
> > | packet's destination is the current node, it sends the packet to upper
> > | layers. But if the packet should be forwarded, it somehow finds it's
> > | output label and switchs this value in the packet. Then it sends the
> > | packet to the outgoing interface.
> > |
> > | Is this the correct process? How does it find new label? In what data
> > | structure is it stored (I suppose it is in the MOI radix tree)? Could
> > | somebody please detail me how this tag switching is done in the
current
> > | implementation?
> > |
> > | Thank you very much!!!
> > |
> > | Best regards,
> > |
> > 
> > - -------------------------------------------------------
> > This SF.Net email sponsored by Black Hat Briefings & Training.
> > Attend Black Hat Briefings & Training, Las Vegas July 24-29 -
> > digital self defense, top technical experts, no vendor pitches,
> > unmatched networking opportunities. Visit www.blackhat.com
> > _______________________________________________
> > mpls-linux-general mailing list
> > mpl...@li...
> > https://lists.sourceforge.net/lists/listinfo/mpls-linux-general
> > 
> > 
> > -----BEGIN PGP SIGNATURE-----
> > Version: GnuPG v1.2.2 (GNU/Linux)
> > Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
> > 
> > iD8DBQFA7TAy8Y15Z+P2WUARAp18AJ9rgoSCjdmUBbx4cHh9mKdRvZO84QCgw0vi
> > ml2eS5UuvL43sGCfJWWPObg=
> > =2+7v
> > -----END PGP SIGNATURE-----
> 
> -- 
> James R. Leu
> jl...@mi...
> 
> 
> -------------------------------------------------------
> This SF.Net email sponsored by Black Hat Briefings & Training.
> Attend Black Hat Briefings & Training, Las Vegas July 24-29 - 
> digital self defense, top technical experts, no vendor pitches, 
> unmatched networking opportunities. Visit www.blackhat.com
> _______________________________________________
> mpls-linux-general mailing list
> mpl...@li...
> https://lists.sourceforge.net/lists/listinfo/mpls-linux-general
> 

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