[mpls-linux-general] Problems in configuring multiple LSPs on same physical link
Status: Beta
Brought to you by:
jleu
Menu
▾
▴
[mpls-linux-general] Problems in configuring multiple LSPs on same physical link
|
From: Muhammad R. S. <sa...@cc...> - 2004-07-10 02:12:37
|
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 |
