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

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...