Re: FW: [mpls-linux-general] Problems in configuring multiple LSPs on multiple physical paths for th
Status: Beta
Brought to you by:
jleu
Menu
▾
▴
Re: FW: [mpls-linux-general] Problems in configuring multiple LSPs on multiple physical paths for the same destination
|
From: James R. L. <jl...@mi...> - 2004-07-19 18:02:42
|
I would use iptables to set the nfmark, then use nffwd to forward down the
different LSPs based on nfmark.
C-------------D
/ \
/ \
192.168.1.0/24 / \ 2.2.2.2
A--------------B G----------H
.1 .2 \ /
\ /
\ /
E-------------F
Configuration on A
------------------
mplsadm2 -A -O 0
Key: 0x2
mplsadm2 -A -O 0
Key: 0x3
mplsadm2 -A -O 0
Key: 0x4
mplsadm2 -O 0x2 -o nffwd:0xF:0x1:0x3:0x2:0x4
mplsadm2 -O 0x3 -o push:gen:16:set:eth1:ipv4:192.168.1.2
mplsadm2 -O 0x4 -o push:gen:17:set:eth1:ipv4:192.168.1.2
ip route add 2.2.2.2/32 via 192.168.1.1 spec_nh 0x8847 0x2
iptables -d 2.2.2.2/32 -p tcp -j MARK --set-mark 0x1
iptables -d 2.2.2.2/32 -p udp -j MARK --set-mark 0x2
iptables sets the nfmark to 0x1 for TCP packets heading to 2.2.2.2 and
and 0x2 for UDP packets heading to 2.2.2.2.
All packets heading to 2.2.2.2 use the 0x2 NHLFE. The 0x2 NHLFE looks
at the nffmark. If the nfmark is 0x1 it continues to process the packet
via NHLFE 0x3, if the nfmark is 0x2 it continues to process the packet
via NHLFE 0x4. All other nfmarks result in the packet being dropped.
On Mon, Jul 19, 2004 at 01:41:26PM +0300, Muhammad R. Sami wrote:
>
>
> 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:
>
>
> 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...
>
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by BEA Weblogic Workshop
> FREE Java Enterprise J2EE developer tools!
> Get your free copy of BEA WebLogic Workshop 8.1 today.
> http://ads.osdn.com/?ad_id=4721&alloc_id=10040&op=click
> _______________________________________________
> mpls-linux-general mailing list
> mpl...@li...
> https://lists.sourceforge.net/lists/listinfo/mpls-linux-general
--
James R. Leu
jl...@mi...
|
