[mpls-linux-general] Problems in configuring multiple LSPs on multiple physical paths for the same d
Status: Beta
Brought to you by:
jleu
Menu
▾
▴
[mpls-linux-general] Problems in configuring multiple LSPs on multiple physical paths for the same destination
|
From: Muhammad R. S. <sa...@cc...> - 2004-07-19 18:31:51
|
I was successful in using the nffwd instruction, thanks for that. But I am
still facing problems in configuring 2 different LSPs on two different
physical links destined to the SAME host. The same message of "RTNETLINK:
file exists" appears even when I try to associate different hops and
different keys to the same destination. This is my topology:
O-------------O
/ \
/ \
/ \
O--------- O O-----------------O
\ /
\ /
\ /
O-------------O
I have two alternate physical paths to the same host. I want to configure 2
different LSPs on each path, can you help me on this one.
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: 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...
|
