mpls-linux-general Mailing List for MPLS for Linux (Page 159)
Status: Beta
Brought to you by:
jleu
Menu
▾
▴
mpls-linux-general — Mailing list for general discussion about MPLS for Linux
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: James R. L. <jl...@mi...> - 2001-11-06 14:34:25
|
You will not see any direct calls to any of the platform specific functions. Only calls to the "published" API found in the the _impl.h files will be seen in the ldp-portable library. Timers, memmory allocation, sockets, mpls forwarding, binary tree, tracing etc are all implmented in the "porting layer". The API in the _impl.h files is implement in the porting layer. The porting layers live in linux and zebra directories. On Tue, Nov 06, 2001 at 04:23:40AM -0800, Mouli T wrote: > Hello, > > I am going throgh the code of LDP. > In that i can not able to find where the Label > stacking is implemented. > > Basically to implement label stack we need to push > a label on a labeled packet by calling > "send_instr()" function()(in ldp_netlink.c). > But in LDP code nobody is calling this function. > > Please, let me know about how Label stacking is > implemented in LDP. > > > bye > Venu > > > > __________________________________________________ > Do You Yahoo!? > Find a job, post your resume. > http://careers.yahoo.com > > _______________________________________________ > mpls-linux-general mailing list > mpl...@li... > https://lists.sourceforge.net/lists/listinfo/mpls-linux-general -- James R. Leu |
|
From: Mouli T <mou...@ya...> - 2001-11-06 12:23:43
|
Hello, I am going throgh the code of LDP. In that i can not able to find where the Label stacking is implemented. Basically to implement label stack we need to push a label on a labeled packet by calling "send_instr()" function()(in ldp_netlink.c). But in LDP code nobody is calling this function. Please, let me know about how Label stacking is implemented in LDP. bye Venu __________________________________________________ Do You Yahoo!? Find a job, post your resume. http://careers.yahoo.com |
|
From: Anand K. P. <par...@en...> - 2001-11-03 13:23:13
|
Hello, What would it take to implement explicit routing using the current mpls-linux and ldp-portable distributions? I am currently working on fetching explicit routes (based on distance) from Zebra OSPF and would like to use these packages for ER-LDP or maybe later, CR-LDP. Thanks, Anand |
|
From: James R. L. <jl...@mi...> - 2001-11-02 14:52:42
|
On Thu, Nov 01, 2001 at 09:48:32PM -0800, Mouli T wrote:
> Hai,
Hello,
> I am doing code study of LDP. I got the flow but
> i can not able to find the relation between data
> structures
>
> particularly for
> Session <-> fs <-> inlabel <-> outlabel <-> fec
Heh heh, good to see someone actually looks at that document :-)
> -----
> in | |
> .------------------| Fec |-out
> | | | |
> | | -----
> ------ ------
> | FS |-------| FS |
> ------ ------
> | |
> ---------
> .----| session |----.
> | --------- |
> ------ ------ ------
> | Attr |---| Attr |---| Attr |
> ------ ------ ------
> | | |
> in label in label in label
>
> Could someone please help me,is there any document
> for the above and for "LDP code".
The problem is that there is a N:M relationship between a FEC and the
sessions. For each FEC in the database, LDP can hear info about it from
multiple sessions. Each session can will hear info about many FECs. The
info being stored for each FEC,session pair is the FEC attributes.
There are many ways to store this type of info, I choose to build
a tree based on the FECs and store a list of sessions that have heard info
about this FEC. Each session also keeps track of the full list of FECs that
it has received info about. So the one thing missing from the picture
above is a line between a FS and an Attr. Each FS has a link to the session
and the attr that the session has learne for the FEC in question.
-----
| |
.---------| Fec |---------.
| | | |
| ----- |
| Downstream FS list |
| ------ ------ |
'-| FS |-------| FS |-'
------\ ------
| `-------------------.
| \---------
.--------------------------------. | session |
| | ---------
| ------ ------ ------ |
`-| Attr |---| Attr |---| Attr |-'
------ ------ ------
This piture is a more accurate picture of the FEC <-> Attr relationship.
Each FEC has multiple FS. Each FE represents one session that has learned
info about this FEC. More then one piece of info can be learned by a session
for a particular FEC, so each FS can have a list of Attr, which is all of the
info learned about this FEC by this session. Take note that each FEC entry
has a list of FS for upstream and downstream sessions.
>
> regards
> Mouli
>
> __________________________________________________
> Do You Yahoo!?
> Find a job, post your resume.
> http://careers.yahoo.com
>
> _______________________________________________
> mpls-linux-general mailing list
> mpl...@li...
> https://lists.sourceforge.net/lists/listinfo/mpls-linux-general
--
James R. Leu
|
|
From: Mouli T <mou...@ya...> - 2001-11-02 08:16:59
|
Hai,
I am doing code study of LDP
In that i can not able to find the relation between
data structures
particularly Session <-> fs <-> inlabel <->
outlabel <-> fec
out
-----
in | |
.------------------| Fec |-
| | | |
| | -----
------ ------
| FS |-------| FS |
------ ------
| |
---------
.----| session |----.
| --------- |
------ ------ ------
| Attr |---| Attr |---| Attr |
------ ------ ------
| | |
in label in label in label
Could someone please help me is there any document
i can get for the above and for
LDP code.
regards
Mouli
__________________________________________________
Do You Yahoo!?
Find a job, post your resume.
http://careers.yahoo.com
|
|
From: Mouli T <mou...@ya...> - 2001-11-02 05:48:34
|
Hai,
I am doing code study of LDP. I got the flow but
i can not able to find the relation between data
structures
particularly for
Session <-> fs <-> inlabel <-> outlabel <-> fec
-----
in | |
.------------------| Fec |-out
| | | |
| | -----
------ ------
| FS |-------| FS |
------ ------
| |
---------
.----| session |----.
| --------- |
------ ------ ------
| Attr |---| Attr |---| Attr |
------ ------ ------
| | |
in label in label in label
Could someone please help me,is there any document
for the above and for "LDP code".
regards
Mouli
__________________________________________________
Do You Yahoo!?
Find a job, post your resume.
http://careers.yahoo.com
|
|
From: Anil H <a_h...@ec...> - 2001-11-01 18:14:28
|
Hi all, I am interested in doing research in the area of->scalable QoS in IP networks. Could someone please suggest a few topics which could be researched in the above area or in MPLS in particular or any other alternate newsgroup wherein I can get some information regarding the same. Regards, Anil.H |
|
From: Yvan P. <yp...@cs...> - 2001-10-31 20:05:14
|
Hi, I would like to add the capability of your MPLS layer to forward packets on several interfaces (multicast...). I have read the code and found that the best way to do that was to add entries in the mii_instruction array in your mpls_in_info structure. The length of this array would be 2*N where N is the max number of interfaces to send the packet through instead of 2, and I plan to add a loop in the mpls_input routine to duplicate the packet and send it to several interfaces. Do you think this is the correct way to handle the problem ? Also, I have never coded inside the kernel, hence this (obvious) question: what tool do you use to debug your code except printk ? Thanks, Yvan ________________________________________________________________________ yv...@po... University of Virginia http://www.pointurier.org Department of Computer Science |
|
From: Sandeep S. <san...@it...> - 2001-10-31 05:34:56
|
Hi, I don't know much about GRE tunnels right now .But thanx anyway I can look into that and learn. Actually , I have already created a MPLS pkt in my own MPLS over ATM forwarding code. I actually need to do MPLS in IP encapsulation followed by encryption of the MPLS pkt by IPSEC. So I was wondering whether I could pass the skb containing my MPLS pkt to ip_queue_xmit(skb) in ip_output.c for wrapping the packet in IP . Am I getting it right and thinking along the correct lines ? Thanx. Sandeep. Sandeep Subramaniam Graduate Research Assistant ITTC, Raymond Nichols Hall, University of Kansas On Tue, 30 Oct 2001, Steven Van den Berghe wrote: > You can use GRE tunnels to accomplish that. I think the latest > mpls-linux shouldn't have a problem with that. > Just create the tunnel over the IP network, and use the created > pseudo-device as a normal device. > > bye, > Steven > > Sandeep Subramaniam wrote: > > > Hi, > > > > Has anyone tried to implement MPLS in IP encapsulation in the kernel? > > > > ie wrapping the MPLS pkt created at the ingress with an IP hdr. > > > > Any ideas ? > > > > Thanx. > > Sandeep. > > > > Sandeep Subramaniam > > Graduate Research Assistant > > ITTC, Raymond Nichols Hall, > > University of Kansas > > > > _______________________________________________ > > mpls-linux-general mailing list > > mpl...@li... > > https://lists.sourceforge.net/lists/listinfo/mpls-linux-general > > -- > Steven Van den Berghe > ste...@in... > Workgroup Broadband Communication Networks > Department Information Technology > Ghent University - Belgium > Phone: +32 (0)9 267 35 86 | Fax : +32 (0)9 267 35 99 > *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* > DiffServ over MPLS for Linux: http://dsmpls.atlantis.rug.ac.be > *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* > If engineers built buildings the way programmers wrote > programs, the first woodpecker to come along would > destroy civilization. > > *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* > > > |
|
From: James R. L. <jl...@mi...> - 2001-10-30 23:46:04
|
> An analysis with tethereal shows that the labelstack received on the last > node is not plain ip. tethereal still seems to recognize a mpls header and > shows a corrupt MPLS labelstack. The mpls header seems to be correct > except on the last node. etherreal and tcpdump do not get a valid versionof the packet. This is a known bug. Make sure you have IPv4 forwarding turned on on the last node other wise you will lose the packet in the IPv4 stack. Turn on MPLS kernel debugging by doing a 'mplsadm -d' then look at the kernel debuggin in your 'messages' log file or do a 'dmesg' and you will see the output as well. Jim > > i.e.: > tethereal seems to show on the node B a correct MPLS header. > > Capturing on eth1 (the outgoing interface at node B): > Frame 1 (56 on wire, 56 captured) > Arrival Time: Oct 30, 2001 13:12:10.817675000 > Time delta from previous packet: 0.000000000 seconds > Time relative to first packet: 0.000000000 seconds > Frame Number: 1 > Packet Length: 56 bytes > Capture Length: 56 bytes > Ethernet II > Destination: 00:02:b3:1f:0b:a2 (00:02:b3:1f:0b:a2) > Source: 00:02:b3:1f:0b:96 (00:02:b3:1f:0b:96) > Type: MPLS label switched packet (0x8847) > MultiProtocol Label Switching Header > MPLS Label: Unknown (99) > MPLS Experimental Bits: 0 > MPLS Bottom Of Label Stack: 1 > MPLS TTL: 255 > Internet Protocol, Src Addr: denise-3 (10.0.3.8), Dst Addr: 10.1.2.6 > (10.1.2.6) > Version: 4 > Header length: 20 bytes > Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00) > 0000 00.. = Differentiated Services Codepoint: Default (0x00) > .... ..0. = ECN-Capable Transport (ECT): 0 > .... ...0 = ECN-CE: 0 > Total Length: 35 > Identification: 0x7d8f > Flags: 0x04 > .1.. = Don't fragment: Set > ..0. = More fragments: Not set > Fragment offset: 0 > Time to live: 64 > Protocol: UDP (0x11) > Header checksum: 0xa42c (correct) > Source: denise-3 (10.0.3.8) > Destination: 10.1.2.6 (10.1.2.6) > User Datagram Protocol, Src Port: 1024 (1024), Dst Port: 9876 (9876) > Source port: 1024 (1024) > Destination port: 9876 (9876) > Length: 15 > Checksum: 0x91e5 (correct) > Data (7 bytes) > > Thanks in advance for new ideas solving this problem. > > Andreas & Marc. > > -------------------------- > University Of Paderborn > > > > _______________________________________________ > mpls-linux-general mailing list > mpl...@li... > https://lists.sourceforge.net/lists/listinfo/mpls-linux-general -- James R. Leu |
|
From: James R. L. <jl...@mi...> - 2001-10-30 23:34:16
|
If you use my most recent patch posted to the mailing list GRE tunnels will work. Jim On Tue, Oct 30, 2001 at 09:54:47AM +0100, Steven Van den Berghe wrote: > You can use GRE tunnels to accomplish that. I think the latest > mpls-linux shouldn't have a problem with that. > Just create the tunnel over the IP network, and use the created > pseudo-device as a normal device. > > bye, > Steven > > Sandeep Subramaniam wrote: > > > Hi, > > > > Has anyone tried to implement MPLS in IP encapsulation in the kernel? > > > > ie wrapping the MPLS pkt created at the ingress with an IP hdr. > > > > Any ideas ? > > > > Thanx. > > Sandeep. > > > > Sandeep Subramaniam > > Graduate Research Assistant > > ITTC, Raymond Nichols Hall, > > University of Kansas > > > > _______________________________________________ > > mpls-linux-general mailing list > > mpl...@li... > > https://lists.sourceforge.net/lists/listinfo/mpls-linux-general > > -- > Steven Van den Berghe > ste...@in... > Workgroup Broadband Communication Networks > Department Information Technology > Ghent University - Belgium > Phone: +32 (0)9 267 35 86 | Fax : +32 (0)9 267 35 99 > *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* > DiffServ over MPLS for Linux: http://dsmpls.atlantis.rug.ac.be > *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* > If engineers built buildings the way programmers wrote > programs, the first woodpecker to come along would > destroy civilization. > > *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* > > > > > _______________________________________________ > mpls-linux-general mailing list > mpl...@li... > https://lists.sourceforge.net/lists/listinfo/mpls-linux-general -- James R. Leu |
|
From: James R. L. <jl...@mi...> - 2001-10-30 23:30:54
|
On Mon, Oct 29, 2001 at 11:27:04AM +0530, Adithya S Bhat wrote: > Hi All, > > How can I force the MPLS forwarding engine to carry a label stack ? ( > i.e. push a label L1, push another label L2 and soon... and send the > packet out.) Do I have to make any change in the code for this ??? > Please give me some pointers on this. Read mpls-linux/docs/README.hierarchy Jim > > Thanks in Advance > -- > Adithya > > > > _______________________________________________ > mpls-linux-general mailing list > mpl...@li... > https://lists.sourceforge.net/lists/listinfo/mpls-linux-general -- James R. Leu |
|
From: Marc Droste-F. <md...@un...> - 2001-10-30 17:02:55
|
Hallo,
while trying to create a Hop-to-Hop route via MPLS unexpected problems
appeared.
i.e.: <A>-<B>-<C> = route via 3 nodes
Our system works like this.
On each node a MPLS-forwarding is initialized:
i.e.: forwarding at node B
MPLS_LABELSPACE
---------------------------------------------
lo 0
eth0 0
eth1 0
eth2 0
.
---------------------------------------------
MPLS_IN
---------------------------------------------
40018c00 gen 99 0 POP DLV
40019000 gen 100 0 POP FWD(40019002)
40019400 gen 101 0 POP FWD(40019403)
40019800 gen 102 0 POP FWD(40019804)
.
---------------------------------------------
MPLS_OUT
---------------------------------------------
40019002 SET(eth0)
40019403 SET(eth1)
40019804 SET(eth2)
The nodes on path got the task to pop just one label from the incoming
stack before forwarding it to the next node. If the node recognizes label
99 on the top of the stack, it pops it away and forwards it to the
ip-layer.
The whole route is defined by the labelstack generated on the first node
on path.
i.e:
MPLS_OUT
---------------------------------------------
408e5803 PUSH(gen 101) SET(eth1)
408e5c03 PUSH(gen 99) FWD(408e5803)
408e6003 FWD(408e5c03)
.
---------------------------------------------
MPLS_TUNNEL
---------------------------------------------
mpls0 408e6003
An analysis with tethereal shows that the labelstack received on the last
node is not plain ip. tethereal still seems to recognize a mpls header and
shows a corrupt MPLS labelstack. The mpls header seems to be correct
except on the last node.
i.e.:
tethereal seems to show on the node B a correct MPLS header.
Capturing on eth1 (the outgoing interface at node B):
Frame 1 (56 on wire, 56 captured)
Arrival Time: Oct 30, 2001 13:12:10.817675000
Time delta from previous packet: 0.000000000 seconds
Time relative to first packet: 0.000000000 seconds
Frame Number: 1
Packet Length: 56 bytes
Capture Length: 56 bytes
Ethernet II
Destination: 00:02:b3:1f:0b:a2 (00:02:b3:1f:0b:a2)
Source: 00:02:b3:1f:0b:96 (00:02:b3:1f:0b:96)
Type: MPLS label switched packet (0x8847)
MultiProtocol Label Switching Header
MPLS Label: Unknown (99)
MPLS Experimental Bits: 0
MPLS Bottom Of Label Stack: 1
MPLS TTL: 255
Internet Protocol, Src Addr: denise-3 (10.0.3.8), Dst Addr: 10.1.2.6
(10.1.2.6)
Version: 4
Header length: 20 bytes
Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00)
0000 00.. = Differentiated Services Codepoint: Default (0x00)
.... ..0. = ECN-Capable Transport (ECT): 0
.... ...0 = ECN-CE: 0
Total Length: 35
Identification: 0x7d8f
Flags: 0x04
.1.. = Don't fragment: Set
..0. = More fragments: Not set
Fragment offset: 0
Time to live: 64
Protocol: UDP (0x11)
Header checksum: 0xa42c (correct)
Source: denise-3 (10.0.3.8)
Destination: 10.1.2.6 (10.1.2.6)
User Datagram Protocol, Src Port: 1024 (1024), Dst Port: 9876 (9876)
Source port: 1024 (1024)
Destination port: 9876 (9876)
Length: 15
Checksum: 0x91e5 (correct)
Data (7 bytes)
Thanks in advance for new ideas solving this problem.
Andreas & Marc.
--------------------------
University Of Paderborn
|
|
From: Steven V. d. B. <ste...@in...> - 2001-10-30 08:55:29
|
You can use GRE tunnels to accomplish that. I think the latest mpls-linux shouldn't have a problem with that. Just create the tunnel over the IP network, and use the created pseudo-device as a normal device. bye, Steven Sandeep Subramaniam wrote: > Hi, > > Has anyone tried to implement MPLS in IP encapsulation in the kernel? > > ie wrapping the MPLS pkt created at the ingress with an IP hdr. > > Any ideas ? > > Thanx. > Sandeep. > > Sandeep Subramaniam > Graduate Research Assistant > ITTC, Raymond Nichols Hall, > University of Kansas > > _______________________________________________ > mpls-linux-general mailing list > mpl...@li... > https://lists.sourceforge.net/lists/listinfo/mpls-linux-general -- Steven Van den Berghe ste...@in... Workgroup Broadband Communication Networks Department Information Technology Ghent University - Belgium Phone: +32 (0)9 267 35 86 | Fax : +32 (0)9 267 35 99 *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* DiffServ over MPLS for Linux: http://dsmpls.atlantis.rug.ac.be *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* If engineers built buildings the way programmers wrote programs, the first woodpecker to come along would destroy civilization. *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* |
|
From: Sandeep S. <san...@it...> - 2001-10-30 06:41:19
|
Hi, Has anyone tried to implement MPLS in IP encapsulation in the kernel? ie wrapping the MPLS pkt created at the ingress with an IP hdr. Any ideas ? Thanx. Sandeep. Sandeep Subramaniam Graduate Research Assistant ITTC, Raymond Nichols Hall, University of Kansas |
|
From: <ad...@sa...> - 2001-10-29 08:53:31
|
On Mon, 29 Oct 2001, Adithya S Bhat wrote:
> Hi All,
>
> How can I force the MPLS forwarding engine to carry a label stack ? (
^^^^ to make a packet
> i.e. push a label L1, push another label L2 and soon... and send the
> packet out.) Do I have to make any change in the code for this ???
> Please give me some pointers on this.
>
> Thanks in Advance
> --
> Adithya
>
>
>
> _______________________________________________
> mpls-linux-general mailing list
> mpl...@li...
> https://lists.sourceforge.net/lists/listinfo/mpls-linux-general
>
|
|
From: Adithya S B. <ad...@sa...> - 2001-10-29 05:59:59
|
Hi All, How can I force the MPLS forwarding engine to carry a label stack ? ( i.e. push a label L1, push another label L2 and soon... and send the packet out.) Do I have to make any change in the code for this ??? Please give me some pointers on this. Thanks in Advance -- Adithya |
|
From: James R. L. <jl...@mi...> - 2001-10-22 13:34:04
|
On Mon, Oct 22, 2001 at 09:44:19AM +0000, Vino Thomas wrote:
> Hello,
>
>
> On Sun, 21 Oct 2001, Iyer, Venkatesh wrote:
> > I have the following package
> > > mpls-linux-0.993
> > I unzipped the package in the usr/src directory and then patched the kernel
> > using linux-mpls.diff found in the patches directory of the untar.
> > I am not being able to find mpls.h
> > Do I need to recompile the kernel or should I be able to find
> > mpls.h after the patch??
>
> Applying the patch will add the include file 'mpls.h' in the directory
> 'linux-kernel/include/linux'
> eg. /usr/src/linux/include/linux
>
> You need to re-configure and re-compile the kernel code to get the feature
> included in the kernel.
In addition you may need to "fix" your include directories. RedHad and many
other distribution do not link /usr/include/{linux,asm} to the kernel, you
will need to do this by hand.
cd /usr/include
mv linux linux.old
mv asm asm.old
ln -s /usr/src/linux/include/linux
ln -s /usr/src/linux/include/asm
>
> Regards,
> Vino
>
>
>
> _______________________________________________
> mpls-linux-general mailing list
> mpl...@li...
> https://lists.sourceforge.net/lists/listinfo/mpls-linux-general
--
James R. Leu
|
|
From: Vino T. <jv...@te...> - 2001-10-22 04:14:49
|
Hello, On Sun, 21 Oct 2001, Iyer, Venkatesh wrote: > I have the following package > > mpls-linux-0.993 > I unzipped the package in the usr/src directory and then patched the kernel > using linux-mpls.diff found in the patches directory of the untar. > I am not being able to find mpls.h > Do I need to recompile the kernel or should I be able to find > mpls.h after the patch?? Applying the patch will add the include file 'mpls.h' in the directory 'linux-kernel/include/linux' eg. /usr/src/linux/include/linux You need to re-configure and re-compile the kernel code to get the feature included in the kernel. Regards, Vino |
|
From: Iyer, V. <Ven...@NA...> - 2001-10-22 02:54:54
|
Hello: I am trying to build James R. Leu's MPLS implementation on linux RH 7.1 Kernel version 2.4.2-2. I have the following package > mpls-linux-0.993 I unzipped the package in the usr/src directory and then patched the kernel using linux-mpls.diff found in the patches directory of the untar. I am not being able to find mpls.h Do I need to recompile the kernel or should I be able to find mpls.h after the patch?? Please let me know. -venkat -----Original Message----- From: mpl...@li... To: vi...@na... Sent: 10/21/01 7:45 PM Subject: Welcome to the "mpls-linux-general" mailing list Welcome to the mpl...@li... mailing list! To post to this list, send your email to: mpl...@li... General information about the mailing list is at: https://lists.sourceforge.net/lists/listinfo/mpls-linux-general If you ever want to unsubscribe or change your options (eg, switch to or from digest mode, change your password, etc.), visit your subscription page at: https://lists.sourceforge.net/lists/options/mpls-linux-general/viyer%40n ai.com You can also make such adjustments via email by sending a message to: mpl...@li... with the word `help' in the subject or body (don't include the quotes), and you will get back a message with instructions. You must know your password to change your options (including changing the password, itself) or to unsubscribe. It is: shilu77 If you forget your password, don't worry, you will receive a monthly reminder telling you what all your lists.sourceforge.net mailing list passwords are, and how to unsubscribe or change your options. There is also a button on your options page that will email your current password to you. You may also have your password mailed to you automatically off of the Web page noted above. |
|
From: James R. L. <jl...@mi...> - 2001-10-19 17:32:56
|
Are you using the CVS version? Off the top of my head I can't remember if I handled this in the ldp-portable library correctly or not. I don't think so. I'm not sure what the correct thing to do is. The only way to truly handle this would be to recognize that the socket is not accepting data. Add it to the write-fd list so we are notified when it is availble for writing. But What do you do with the buffer in the meantime? How log do you hold on to it? How many times do you retry? The simple answer is to treat it as a critical error and shut down the session. If this happens simply because the amount of data being sent (lot of label mapping) is so large, then maybe packet pacing is needed. My gut reaction is that these are all detail s that should be left in the porting layer. So with that, maybe a PDU queue(s) needs to be created in the linux porting layer that drains at a specific rate by utilizing a timer. It can handle the write failure cases then. This introduces all sorts of complication though. ugh. If you're interested in implementing a fix for this, let me know. I'd be more then happy to discuss different solutions with you. Jim On Fri, Oct 19, 2001 at 10:05:45AM -0700, Scott Lee wrote: > Should ldp_socket_tcp_write() handle cases > where write() system call returns number of > bytes written which is less than the number of bytes > requested? This is a normal situation where kernel > cannot accept the entire buffer requested to send. > > Has anyone experience problem with not able > to send the entire packet because of some > kind of congestion in the link? > > Thanks. > > Scott > > __________________________________________________ > Do You Yahoo!? > Make a great connection at Yahoo! Personals. > http://personals.yahoo.com > > _______________________________________________ > mpls-linux-general mailing list > mpl...@li... > https://lists.sourceforge.net/lists/listinfo/mpls-linux-general -- James R. Leu |
|
From: Scott L. <nat...@ya...> - 2001-10-19 17:05:47
|
Should ldp_socket_tcp_write() handle cases where write() system call returns number of bytes written which is less than the number of bytes requested? This is a normal situation where kernel cannot accept the entire buffer requested to send. Has anyone experience problem with not able to send the entire packet because of some kind of congestion in the link? Thanks. Scott __________________________________________________ Do You Yahoo!? Make a great connection at Yahoo! Personals. http://personals.yahoo.com |
|
From: Elio F. <el...@ti...> - 2001-10-18 14:19:51
|
Hi Jim, I'm developing a module snmp to create a LSP using the MPLS-LSR-MIB, but I've a problem when I read the file /proc/net/mpls_out to create an entry on the mplsOutSegmentTable , because I can't find the next-hop used to send the outcoming packet The /proc/net/mpls_out contains: 40005003 PUSH(gen 20) SET(eth0) You have specified only the interface but if the connection isn't peer to peer you're not able to know the nexthop. How can I resolve it? It's possible to modify the /proc/net/mpls_out file adding the next-hop address? Thanks in advance! Elio Francesconi |
|
From: <aj...@ko...> - 2001-10-17 05:27:29
|
Hello all (Jim)
We just started working on MPLS-Linux.
My problem is when I pinged C from A , how to know that packet is MPLS or normal
IP. I used tcpdump and ethereal to check it(if the packet going from A to B is
MPLS).I didn't see any mpls packet..
My network is as
eth0
202.141.151.78 (gw)
----- LSP -----
| A | ----------------- | B |
----- -----
202.141.151.76 \ -----
eth0 \---------| C |
-----
202.141.152.3
Where Host A and B MPLS enabled. I have created route and FEC at A. The packet
originating from A to C , B act as gateway.
I have created static route ( not used LDP) , the command used are ..
On host A gave following commands--------
route add -host 202.141.152.3 gw 202.141.151.78
mplsadm -A -B -O gen:16:eth0:ipv4:202.141.151.78 -f 202.141.152.3/32
mplsadm -A -I gen:17:0
mplsadm -L eth0:0
There are enteries in /procs/net/mpls* files.
Can u please tell me what is problem here (in network or in our method of
checking ) , and method to check MPLS packets.
I am having Red Hat Linux 7.1 and mpls-linux-0.993.
Thanks in advance..
Ajit & Team
Staff Scientist NCST,( R & D Division Govt Of India) Mumbai, India.
|
|
From: James R. L. <jl...@mi...> - 2001-10-16 18:11:14
|
Hey folks, I know it's been WAY too long since I've released a patch. It's not like I'm not add bug fixes or features, I just haven't had a chance to test them all. So with that in mind, here is a diff against my development tree that is untested. It compiles, it runs, I just haven't regression tested the the MPLS code. What's different? -packet and bytes counters on incoming and outgoing structures (results seen in /proc/net/mpls*) -ttl processing should now be correct -added yon's bug fix for TCP failures -updated to 2.4.10 I would apreciate if someone could verify that the TTL processing works and that the couters are correct. Ofcourse let me know if anything breaks. Laters, Jim -- James R. Leu |
533 messages has been excluded from this view by a project administrator.
