Thread: FW: [mpls-linux-general] Problems in configuring multiple LSPs on multiple physical paths for the sa
Status: Beta
Brought to you by:
jleu
Menu
▾
▴
mpls-linux-general
|
From: Muhammad R. S. <sa...@cc...> - 2004-07-19 16:22:23
|
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...
|
|
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...
|
|
From: <sa...@cc...> - 2004-07-20 00:11:47
|
I got your point regarding the iptables marking and then using the nffwd. Thank yopu very much for elaborating on that with an example. But what if in the diagram below B is the ingress and one LSP is C->D->G and the other is E- >F->G, i.e, 2 different LSPs on 2 different physical paths headed to the same destination which is H. then I am facing the RTNETLINK problem. Regards, Quoting "James R. Leu" <jl...@mi...>: > 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. |
|
From: James R. L. <jl...@mi...> - 2004-07-20 03:10:03
|
On Tue, Jul 20, 2004 at 03:28:15AM +0300, sa...@cc... wrote:
> I got your point regarding the iptables marking and then using the nffwd.
> Thank yopu very much for elaborating on that with an example. But what if in
> the diagram below B is the ingress and one LSP is C->D->G and the other is E-
> >F->G, i.e, 2 different LSPs on 2 different physical paths headed to the same
> destination which is H. then I am facing the RTNETLINK problem.
> Regards,
No your not. I guess I need to continue the example .... note my changes
to the drawing, and B's configuration below
> Quoting "James R. Leu" <jl...@mi...>:
>
> > I would use iptables to set the nfmark, then use nffwd to forward down
> > the
> > different LSPs based on nfmark.
> >
> > C-------------D
> > .2 / \
> > /2.0/24 \
> > 192.168.1.0/24 / \ 2.2.2.2
> > A--------------B G----------H
> > .1 .2 \ /
> > \3.0/24 /
> > .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.
Configuration on B
------------------
mplsadm2 -L eth1:0
eth1 is connected to A
mplsadm2 -A -I gen:16:0
mplsadm2 -A -O 0
Key: 0x2
mplsadm2 -O 0x2 -o push:gen:16:set:eth2:ipv4:192.168.2.2
mplsadm2 -B -I gen:16:0 -O 0x2
LSP #1 comes in eth1 with label 16 and goes out eth2 with label 16
eth2 is connected to C
mplsadm2 -A -O 0
Key: 0x3
mplsadm2 -O 0x3 -o push:gen:17:set:eth3:ipv4:192.168.3.2
mplsadm2 -A -I gen:17:0
mplsadm2 -B -I gen:17:0 -O 0x3
LSP #2 comes in eth1 with label 17 and goes out eth3 with label 17
eth3 is connected to E
Notice I did not add any routes via 'ip route' nor do I add and filters
via 'iptables'. On B (and C,D,E,F,G) we only label switch no IPv4 route
configuration is required.
If B was going to act as ingress LER (as opposed to LSR) here is how you
would configure the the 2.2.2.2/32 route:
ip route add 2.2.2.2/32 nexthop via 192.168.2.2 spec_nh 0x8847 0x2 \
nexthop via 192.168.3.2 spec_nh 0x8847 0x3
NOTE: that is one big long command that specifies multiple nexthops
--
James R. Leu
jl...@mi...
|
|
From: James R. L. <jl...@mi...> - 2004-07-21 13:28:15
|
On Wed, Jul 21, 2004 at 03:59:47PM +0300, Muhammad R. Sami wrote: > I used the following command on the ingress > > ip route add 192.168.11.2/32 nexthop via 192.168.12.2 spec_nh 0x8847 0x2 \ > nexthop via 192.168.15.2 spec_nh 0x8847 0x3 > > and got the response as > > RTNETLINK answers: invalid argument We've already went over this, but to re-iterate: spec_nh is just a tag on a nexthop. Therefore it will not make a nexthop unique. If you remove the spc_nh tag from the command you'll see why 'ip' is complaining, your telling it to add the exact same nexthop twice. You cannot do that. You must have, at the very minimum, a different nexthop IP address. This is completly orthoganl to your problem though. You do not need to add the multiple nexthops on 'A'. In my sample config I only had one nexthop specified for the route to 2.2.2.2. The process of assigning packets to the different LSPs is done by the MPLS layer NOT the IPv4 layer. > However a similar command executes without any trouble on the egress. When I > run the following command on the ingress > > ip route add 192.168.11.2/32 via 192.168.12.2 spec_nh 0x8847 0x2 > > it executes without trouble showing that "ip route" command is working. Can > you kindly tell me the possible reason for this. > -- James R. Leu jl...@mi... |
|
From: baim <j0...@te...> - 2004-07-22 17:34:52
|
Hello Pim and all, i need suggestion here. I want to make a test between MPLS and Intserv RSVP-TE (with FF style) this is what i used : is_config at all node : ..... #$TC class add dev $i parent 1:1 classid 1:3 cbq rate 8Mbit \ #bandwidth 10Mbit weight 800Kbit prio 5 allot 1514 cell 8 \ #maxburst 20 avpkt 1000 $TC class add dev $i parent 1:1 classid 1:7ffe cbq \ bandwidth 10Mbit \ rate 10Mbit weight 1Mbit prio 5 allot 1514 cell 8 \ maxburst 20 avpkt 1000 isolated bounded done ..... The configuration : host1--||--Ingress--|--4 router--|--Egress--||--host2 I am using rapirecv_auto dan rtest2 -f file. I want to use Intserv with FF style : At Ingress : #cat file 13.13.13.2 11.11.11.1 200 1 0 11.11.11.2:12.12.12.2:0 0 Can i make rsvp-te intserv with FF style by that configuration.... ? In my plan, i want to make FTP and HTTP connection between host1 and host2 (downloading file), while TG will be generate traffic at network between Ingress and Egress as the disturber. Like u see at the is_config file i just creating one parent, is this sufficient to my plan.. ? And when i run ./tunnel -L -c after mapping a traffik to the LSPID, i found that a parameter is BE, is this okay.. ? Sorry i have many question. I really puzzled since there is no comperhensive guide to set up intserv rsvp network. =========================================================================================== Netkuis Instan untuk wilayah Bandung (kode area 022) - SD,SMP,SMA berhadiah total puluhan juta rupiah... periode I dimulai 1 April 2004 =========================================================================================== |
|
From: Muhammad R. S. <sa...@cc...> - 2004-07-21 15:06:22
|
I used the following command on the ingress ip route add 192.168.11.2/32 nexthop via 192.168.12.2 spec_nh 0x8847 0x2 \ nexthop via 192.168.15.2 spec_nh 0x8847 0x3 and got the response as RTNETLINK answers: invalid argument However a similar command executes without any trouble on the egress. When I run the following command on the ingress ip route add 192.168.11.2/32 via 192.168.12.2 spec_nh 0x8847 0x2 it executes without trouble showing that "ip route" command is working. Can you kindly tell me the possible reason for this. |
Thanks for helping keep SourceForge clean.
X