[mpls-linux-general] Configuration of bi-directional LSPs on the same physical path traversing singl
Status: Beta
Brought to you by:
jleu
Menu
▾
▴
[mpls-linux-general] Configuration of bi-directional LSPs on the same physical path traversing single router
|
From: Muhammad R. S. <sa...@cc...> - 2004-07-13 01:25:23
|
While configuring bi-directional LSPs on the same physical path, I encountered a problem; actually my LSR could not get the second label space. Due to this (probably) LSP going in the opposite direction is not functional. Below is the output of the mpls/out, mpls/in and mpls/labelspace files. Can anyone please let me know how to configure bi-directional LSPs going through one LSR? mpls/out: MOI key: 0x00000002 Instruction Set PUSH PUSH (gen 17) SET SET (eth1, 172.17.2.2) MOI key: 0x00000003 Instruction Set PUSH PUSH (gen 19) SET SET (eth1, 172.16.3.1) ******************************** mpls/in MII key: 0x00010005 Instruction Set POP FWD FWD (0x00000002) MII key: 0x00012004 Instruction Set POP FWD FWD (0x00000003) ******************************** mpls/labelspaces Iface LSpc Refcnt eth0 1 10 l0 -1 5 Eth1 -1 10 ********************************* 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: Monday, July 12, 2004 7:53 AM To: sa...@cc... Cc: MPLS Linux List Subject: Re: [mpls-linux-general] Problems in configuring multiple LSPs on same physical link On Mon, Jul 12, 2004 at 04:40:31AM +0300, sa...@cc... wrote: > Yes, I am marking the packets using the nfmark, and I want to assign packets > to different LSPs based on their marks and EXP, but I could not find much > information on nffwd, expfwd and nf2exp. niether can I find any example > instructions that use these utilities. How could I for example, assign a > packet marked as 10 to LSP1 with EXP value 2 using these commands. > regards, mplsadm2 -A -O 0 Key: 0x2 mplsadm2 -A -O 0 Key 0x3 mplsadm2 -A -O 0 Key 0x4 mplsadm2 -O 0x2 -o nffwd:0xf:0x3:0x3:0x4:0x4 mplsadm2 -O 0x3 -o set_exp:0x1:push:gen:16:set:eth1:ipv4:192.168.2.1 mplsadm2 -O 0x3 -o set_exp:0x7:push:gen:17:set:eth1:ipv4:192.168.2.1 ip route add 10.0.0.0/8 via 192.168.2.1 spec_nh 0x8847 0x2 Packets marked with 0x3 heading to destination 10.0.0.0/8 get label 16 with EXP 0x1 Packets marked with 0x4 heading to destination 10.0.0.0/8 get label 17 with EXP 0x7 > Quoting "James R. Leu" <jl...@mi...>: > > > On Sun, Jul 11, 2004 at 07:24:54PM +0300, Muhammad R. Sami wrote: > > > I want to setup multiple LSPs with different labels and EXP values > > destined > > > to the same host either on the same physical link or one link per LSP. > > But I > > > am unable to do so because whenever I add the second route through the > > > iproute2 command, I get an error message stating "RTNETLINK answers: > > file > > > exists". If anyone knows the reason for this and how to solve this > > problem. > > > This is very urgent so any help will be highly appreciated. > > > > How are you determining what packets go to which LSP? > > > > > Regards, > > > > In general, if you can't do it with just IP, then you won't be able > > to do it with MPLS.... for example: > > > > [root jleu-laptop 6:36pm] ~-> ip route add 10.0.0.0/8 via 192.168.2.1 > > [root jleu-laptop 6:37pm] ~-> ip route add 10.0.0.0/8 via 192.168.2.1 > > RTNETLINK answers: File exists > > > > The spec_nh is just an attribute on a nexthop, not an entire new > > nexthop, > > therefore if you can't configure it without spec_nh, then you won't be > > able > > to configure it with spec_nh. > > > > BUT!!! The nexthop specified in the IPv4 nexthop has nothing to > > do with the nexthop of the LSP. So in theory you could do: > > > > [root jleu-laptop 6:45] ~-> ip route add 10.0.0.0/8 nexthop via > > 192.168.2.1 spec_nh 0x8847 0x2 nexthop via 192.168.2.2 spec_nh 0x8847 > > 0x3 > > > > I'm not sure what your goal is, but if you are marking the packets > > some how, I think you could use the nffwd or dsfwd to achieve what you > > want > > much more effeciently. > > > > -- > > James R. Leu > > jl...@mi... > > > > On Sun, Jul 11, 2004 at 02:46:37PM +0300, Muhammad R. Sami wrote: > > > 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... > > > > > > > -- > > James R. Leu > > jl...@mi... > > > > -- James R. Leu jl...@mi... |
