mpls-linux-general Mailing List for MPLS for Linux (Page 96)
Status: Beta
Brought to you by:
jleu
You can subscribe to this list here.
| 2000 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(3) |
Dec
(26) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2001 |
Jan
(22) |
Feb
(19) |
Mar
(19) |
Apr
(45) |
May
(52) |
Jun
(101) |
Jul
(79) |
Aug
(24) |
Sep
(43) |
Oct
(54) |
Nov
(71) |
Dec
(53) |
| 2002 |
Jan
(111) |
Feb
(123) |
Mar
(67) |
Apr
(61) |
May
(75) |
Jun
(26) |
Jul
(36) |
Aug
(41) |
Sep
(79) |
Oct
(85) |
Nov
(58) |
Dec
(39) |
| 2003 |
Jan
(26) |
Feb
(61) |
Mar
(80) |
Apr
(56) |
May
(39) |
Jun
(44) |
Jul
(28) |
Aug
(25) |
Sep
(4) |
Oct
(20) |
Nov
(38) |
Dec
(9) |
| 2004 |
Jan
(14) |
Feb
(14) |
Mar
(68) |
Apr
(17) |
May
(45) |
Jun
(42) |
Jul
(41) |
Aug
(23) |
Sep
(46) |
Oct
(89) |
Nov
(55) |
Dec
(33) |
| 2005 |
Jan
(74) |
Feb
(39) |
Mar
(105) |
Apr
(96) |
May
(43) |
Jun
(48) |
Jul
(21) |
Aug
(22) |
Sep
(33) |
Oct
(28) |
Nov
(29) |
Dec
(81) |
| 2006 |
Jan
(37) |
Feb
(32) |
Mar
(147) |
Apr
(37) |
May
(33) |
Jun
(28) |
Jul
(15) |
Aug
(20) |
Sep
(15) |
Oct
(23) |
Nov
(30) |
Dec
(40) |
| 2007 |
Jan
(20) |
Feb
(24) |
Mar
(65) |
Apr
(69) |
May
(41) |
Jun
(53) |
Jul
(39) |
Aug
(76) |
Sep
(53) |
Oct
(43) |
Nov
(26) |
Dec
(24) |
| 2008 |
Jan
(19) |
Feb
(67) |
Mar
(91) |
Apr
(75) |
May
(47) |
Jun
(63) |
Jul
(68) |
Aug
(39) |
Sep
(44) |
Oct
(33) |
Nov
(62) |
Dec
(84) |
| 2009 |
Jan
(14) |
Feb
(39) |
Mar
(55) |
Apr
(63) |
May
(16) |
Jun
(9) |
Jul
(4) |
Aug
(6) |
Sep
(1) |
Oct
(2) |
Nov
(10) |
Dec
(5) |
| 2010 |
Jan
(3) |
Feb
(1) |
Mar
(5) |
Apr
(13) |
May
(4) |
Jun
(5) |
Jul
(2) |
Aug
(8) |
Sep
(6) |
Oct
(1) |
Nov
(2) |
Dec
(2) |
| 2011 |
Jan
(1) |
Feb
(21) |
Mar
(1) |
Apr
|
May
|
Jun
|
Jul
(3) |
Aug
(6) |
Sep
|
Oct
|
Nov
(2) |
Dec
(6) |
| 2012 |
Jan
(5) |
Feb
(3) |
Mar
|
Apr
|
May
|
Jun
(1) |
Jul
(5) |
Aug
(3) |
Sep
(6) |
Oct
|
Nov
|
Dec
|
| 2013 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(1) |
Jun
|
Jul
|
Aug
|
Sep
(1) |
Oct
|
Nov
|
Dec
|
| 2014 |
Jan
|
Feb
(1) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2015 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(2) |
Dec
|
|
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...
|
|
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: 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-15 14:35:22
|
On Thu, Jul 15, 2004 at 12:14:43PM +0300, Peter Shtinkov wrote:
> Hello,
> I got latest quagga-mpls, ldp-portable and kernel with mpls
Did you get them via p4, if so what change number are you at?
('p4 changes ... | more' tell me the first change number that appears)
If not, what versions?
> implemetation. Compiled/run all the things and tried to do
> "mpls ip" in global configuration of ldpd.
> Here is output:
>
> 2004/07/15 12:05:23 informational: LDP: route 212.50.13.38/32
> 2004/07/15 12:05:23 informational: LDP: num nexthop 1
> 2004/07/15 12:05:23 informational: LDP: nexthop 212.36.10.81
> 2004/07/15 12:05:23 informational: LDP: num ifindex 1
> 2004/07/15 12:05:23 informational: LDP: ifindex 6
> 2004/07/15 12:05:23 informational: LDP: delete
> ldpd: ldp.c:212: ldp_add_ipv4: Assertion `0' failed.
> Aborted
What does your routing table look like before you issue 'mpls ip'.
(go to a linux shell and type 'ip route show')
--
James R. Leu
jl...@mi...
|
|
From: Peter S. <sht...@sp...> - 2004-07-15 09:48:34
|
Hello, I got latest quagga-mpls, ldp-portable and kernel with mpls implemetation. Compiled/run all the things and tried to do "mpls ip" in global configuration of ldpd. Here is output: 2004/07/15 12:05:23 informational: LDP: route 212.50.13.38/32 2004/07/15 12:05:23 informational: LDP: num nexthop 1 2004/07/15 12:05:23 informational: LDP: nexthop 212.36.10.81 2004/07/15 12:05:23 informational: LDP: num ifindex 1 2004/07/15 12:05:23 informational: LDP: ifindex 6 2004/07/15 12:05:23 informational: LDP: delete ldpd: ldp.c:212: ldp_add_ipv4: Assertion `0' failed. Aborted Any suggestion what's wrong ? |
|
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... |
|
From: Muhammad R. S. <sa...@cc...> - 2004-07-11 16:24:22
|
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. 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 |
|
From: Muhammad R. S. <sa...@cc...> - 2004-07-11 11:49:48
|
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... |
|
From: James R. L. <jl...@mi...> - 2004-07-11 02:53:15
|
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... |
|
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 |
|
From: baim <j0...@te...> - 2004-07-09 13:24:48
|
On Sat, 03 Jul 2004 18:57:40 +0300 Itrat Rasod Quadri <iq...@cc...> wrote: >Hello, > >Sorry to bother you on this subject once again but I have >rechecked the >configurations again and again and I cannot find anything >wrong there. If I >can send the packet from one PC to another using the MPLS >backbone then it is >obvious that I can do the same in the reverse direction >but unfortunately this >is not happening. I will now have to use another physical >path for the >response. > >Thanks for all the help. You have to configure your router in both direction. example " R1 ||-----------|| R2 ||------------|| R3 eth0 eth0 eth1 eth0 In your previus configuration R1 can send to R3 over MPLS but R3 couldn't send to the R1 over the same MPLS path. This because you just configure : eht0 R1 : as outgoing label eth0 R2 : as incoming eth1 R2 : as outgoing eth0 R3 : as incoming To make R3 send packet through same MPLS path, just configure your with the same way that you have done, but in opposite direction. Its mean : eth0 R3 : plus outgoing eth1 R2 : plus incoming eth0 R2 : plus outgoing eth0 R1 : plus incoming But becarefull when you try to binding the route to the label key (example : 0x2, 0x3). Make sure that you have bind to the right key. May be Prim could give you more satisfy answer =========================================================================================== Netkuis Instan untuk wilayah Bandung (kode area 022) - SD,SMP,SMA berhadiah total puluhan juta rupiah... periode I dimulai 1 April 2004 =========================================================================================== |
|
From: James R. L. <jl...@mi...> - 2004-07-08 14:33:53
|
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... |
|
From: Rafael P. G. <raf...@ac...> - 2004-07-08 11:30:09
|
-----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. 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... 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... 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----- |
|
From: James R. L. <jl...@mi...> - 2004-07-07 22:47:47
|
On Thu, Jul 08, 2004 at 01:42:24AM +0300, Mohammad Rehan Sami wrote: > Both I do not know the details of using tcindex to setup queuing. Take a look at: http://www.opalsoft.net/qos/DS-210.htm ... for more info. As for using exp2tc and tc2exp ... Here is how to use exp2tc, directly translating EXP bits to TCINDEX: mplsadm2 -A -I gen:16:0 mplsadm2 -I gen:16:0 -i exp2tc:0x0:0x0:0x1:0x1:0x2:0x2:0x3:0x3:0x4:0x4:0x5:0x5:0x6:0x6:0x7:0x7:pop:peek Here is how to use tc2exp to directly translate TCINDEX to EXP bits: mplsadm2 -A -O 0 Key: 0x00000002 mplsadm2 -O 0x2 -o tc2exp:0x7:0x0:0x0:0x1:0x1:0x2:0x2:0x3:0x3:0x4:0x4:0x5:0x5:0x6:0x6:0x7:0x7:push:gen:17:set:eth0:ipv4:192.168.1.1 NOTE: the first number after tc2exp is a mask against TCINDEX. > > Quoting "James R. Leu" <jl...@mi...>: > > > On Wed, Jul 07, 2004 at 10:12:08PM +0300, Muhammad R. Sami wrote: > > > I am unable to find any information on how to use tcindex filter nor > > are > > > there any examples (or at least I could not find them:-(). Can any one > > > please provide me with a short tutorial and some examples particularly > > on > > > how to use exp2tc or tc2exp instructions. > > > > Do you mean "howto use tcindex for queuing" or "howto use tcindex for > > EXP mapping"? > > > > > 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 > > > > > > > > > > > > > > > > > > > > > > > > ------------------------------------------------------- > > > 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... |
|
From: James R. L. <jl...@mi...> - 2004-07-07 22:28:07
|
It never made it to the web site it can only be downloaded from my personal
tree. Although now my personal tree is 1.935.
If you want the lastest MPLS linux code (including quagga+mpls) use the
following p4 'View:':
//depot/mpls-linux-1.1/... //<your client name>/mpls-linux/...
//depot/iproute2-mpls-1.1/... //<your client name>/iproute2/...
//depot/iptables-mpls/... //<your client name>/iptables/...
//depot/ppp-mpls/... //<your client name>/ppp/...
//depot/quagga-mpls/... //<your client name>/quagga-mpls/...
//depot/ldp-portable/... //<your client name>/ldp-portable/...
//depot/mpls-kernel-1.1/... //<your client name>/kernel/...
NOTE: I put the kernel entry at the end on purpose, because it is ~220MB
and will take a long time to download over my pathetically slow link.
If you get the code via p4, ignore the patches in the mpls-linux/patches
directory and in ldp-portable.
If you do not want the code that is at the head of line you can use:
p4 sync @<change number>
Change number 722 is a safe one to work on. You can see what changes I have
been sbumitting by using:
p4 changes
If you only want to see teh changes to a particular directory go into that
directory and do:
p4 changes ...
On Wed, Jul 07, 2004 at 11:40:06PM +0200, wod...@po... wrote:
> I started to play with mpls-linus a month ago. I was able to install and run it on several versions of kernel. Just for fun I unpacked SRPMs to realize what does it mean "download the the newest version of iptables/iproute and apply the patch".
> I installed Perforce software and used it (to be honest I haven't read the full manual) and I still have one unanswered question:
> "what is it this mpls-linux version 1.930?". Does it really exist (if so, where?) or it is only a myth?
> I hate writting documentation, so I understand mpls-linux developers and don't want to complain. But where? Please. I'm not even asking for description.
>
>
> -------------------------------------------------------
> 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...
|
|
From: Mohammad R. S. <sa...@cc...> - 2004-07-07 22:27:52
|
Both Quoting "James R. Leu" <jl...@mi...>: > On Wed, Jul 07, 2004 at 10:12:08PM +0300, Muhammad R. Sami wrote: > > I am unable to find any information on how to use tcindex filter nor > are > > there any examples (or at least I could not find them:-(). Can any one > > please provide me with a short tutorial and some examples particularly > on > > how to use exp2tc or tc2exp instructions. > > Do you mean "howto use tcindex for queuing" or "howto use tcindex for > EXP mapping"? > > > 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 > > > > > > > > > > > > > > > > ------------------------------------------------------- > > 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... > > |
|
From: Mohammad R. S. <sa...@cc...> - 2004-07-07 22:27:51
|
Both Quoting "James R. Leu" <jl...@mi...>: > On Wed, Jul 07, 2004 at 10:12:08PM +0300, Muhammad R. Sami wrote: > > I am unable to find any information on how to use tcindex filter nor > are > > there any examples (or at least I could not find them:-(). Can any one > > please provide me with a short tutorial and some examples particularly > on > > how to use exp2tc or tc2exp instructions. > > Do you mean "howto use tcindex for queuing" or "howto use tcindex for > EXP mapping"? > > > 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 > > > > > > > > > > > > > > > > ------------------------------------------------------- > > 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... > > |
|
From: <wod...@po...> - 2004-07-07 21:40:32
|
I started to play with mpls-linus a month ago. I was able to install and run it on several versions of kernel. Just for fun I unpacked SRPMs to realize what does it mean "download the the newest version of iptables/iproute and apply the patch". I installed Perforce software and used it (to be honest I haven't read the full manual) and I still have one unanswered question: "what is it this mpls-linux version 1.930?". Does it really exist (if so, where?) or it is only a myth? I hate writting documentation, so I understand mpls-linux developers and don't want to complain. But where? Please. I'm not even asking for description. |
|
From: James R. L. <jl...@mi...> - 2004-07-07 19:33:29
|
On Wed, Jul 07, 2004 at 10:12:08PM +0300, Muhammad R. Sami wrote: > I am unable to find any information on how to use tcindex filter nor are > there any examples (or at least I could not find them:-(). Can any one > please provide me with a short tutorial and some examples particularly on > how to use exp2tc or tc2exp instructions. Do you mean "howto use tcindex for queuing" or "howto use tcindex for EXP mapping"? > 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 > > > > > > > > ------------------------------------------------------- > 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... |
|
From: Muhammad R. S. <sa...@cc...> - 2004-07-07 19:12:49
|
I am unable to find any information on how to use tcindex filter nor are there any examples (or at least I could not find them:-(). Can any one please provide me with a short tutorial and some examples particularly on how to use exp2tc or tc2exp instructions. 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 |
|
From: James R. L. <jl...@mi...> - 2004-07-07 18:06:37
|
On Wed, Jul 07, 2004 at 08:46:22PM +0300, Muhammad R. Sami wrote: > I am using qdiscs and tc filters to classify and queue packets at my > ingress, and then assigning different label/EXP pairs to different flows. My > question is that do I require to maintain my QoS policies even at the LSRs, > also I want to maintain the EXP bits value throughout till the egress, for > this do I have to tell the LSR to do it or by default it would swap the > label and keep the EXP value as is. > Regards, > In a fully diffserv aware MPLS network every node (even LSRs) apply some sort of PHB to the packets as they traverse the LSPs. So the short answer is yes, I would think you would want to want to install QoS policies on the LSRs. I have not verified this, but it is my theory that the EXP values will be preserved at LSRs that do not interpret them. Looking at the code it looks like I "pop" the EXP bits from the top label and popogate then to the "pushed" label. I'm not sure I thought through the hierachy cases though, so if you plan on popping or pushing more then one label your results may vary :-) Also, after you have a working setup, I know I, and I'm sure others, would like to see any scripts or examples of your configuration that you can provide. Thanks > 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: Wednesday, July 07, 2004 7:20 PM > To: Rafael Paoliello Guimaraes > Cc: mpl...@li... > Subject: Re: [mpls-linux-general] Trying to understand mpls-linux... > > 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: > > -----BEGIN PGP SIGNED MESSAGE----- > > Hash: SHA1 > > > > 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, > > > > - -- > > > > =========================================== > > ~ 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 > > =========================================== > > -----BEGIN PGP SIGNATURE----- > > Version: GnuPG v1.2.2 (GNU/Linux) > > Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org > > > > iD8DBQFA7BXJ8Y15Z+P2WUARAivoAKDDhqAmlMDxqt349TFOX4XzsRTkwQCfWXdV > > zhL/opdcrMqY4Nb5QnJ3JMI= > > =l87y > > -----END PGP SIGNATURE----- > > > > > > ------------------------------------------------------- > > 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... > > > ------------------------------------------------------- > 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... |
|
From: Muhammad R. S. <sa...@cc...> - 2004-07-07 17:51:41
|
I am using qdiscs and tc filters to classify and queue packets at my ingress, and then assigning different label/EXP pairs to different flows. My question is that do I require to maintain my QoS policies even at the LSRs, also I want to maintain the EXP bits value throughout till the egress, for this do I have to tell the LSR to do it or by default it would swap the label and keep the EXP value as is. 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: Wednesday, July 07, 2004 7:20 PM To: Rafael Paoliello Guimaraes Cc: mpl...@li... Subject: Re: [mpls-linux-general] Trying to understand mpls-linux... 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: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > 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, > > - -- > > =========================================== > ~ 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 > =========================================== > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.2.2 (GNU/Linux) > Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org > > iD8DBQFA7BXJ8Y15Z+P2WUARAivoAKDDhqAmlMDxqt349TFOX4XzsRTkwQCfWXdV > zhL/opdcrMqY4Nb5QnJ3JMI= > =l87y > -----END PGP SIGNATURE----- > > > ------------------------------------------------------- > 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... ------------------------------------------------------- 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 |
|
From: James R. L. <jl...@mi...> - 2004-07-07 16:20:27
|
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: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > 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, > > - -- > > =========================================== > ~ 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 > =========================================== > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.2.2 (GNU/Linux) > Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org > > iD8DBQFA7BXJ8Y15Z+P2WUARAivoAKDDhqAmlMDxqt349TFOX4XzsRTkwQCfWXdV > zhL/opdcrMqY4Nb5QnJ3JMI= > =l87y > -----END PGP SIGNATURE----- > > > ------------------------------------------------------- > 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... |
|
From: Rafael P. G. <raf...@ac...> - 2004-07-07 15:25:05
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 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, - -- =========================================== ~ 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 =========================================== -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFA7BXJ8Y15Z+P2WUARAivoAKDDhqAmlMDxqt349TFOX4XzsRTkwQCfWXdV zhL/opdcrMqY4Nb5QnJ3JMI= =l87y -----END PGP SIGNATURE----- |
|
From: Itrat R. Q. <iq...@cc...> - 2004-07-03 15:44:33
|
Hello, Sorry to bother you on this subject once again but I have rechecked the configurations again and again and I cannot find anything wrong there. If I can send the packet from one PC to another using the MPLS backbone then it is obvious that I can do the same in the reverse direction but unfortunately this is not happening. I will now have to use another physical path for the response. Thanks for all the help. |