mpls-linux-general Mailing List for MPLS for Linux (Page 172)
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-05-21 21:37:40
|
I found the problem. I'm not handling the case where multiple LDP PDU come in the same TCP buffer. I will work on this. Jim > Hi, > The latest CVS ldp_zebra seems to dump core quite cosistently after an > assertion failure once the 2 neighbours start a session. > Attached is a log of the (end of the) console output, and a backtrace. > It seems to depend on the timing of events - if I reduce the trace level > on the failing neighbour the other one would abort instead (althugh in a > little earlier - after a keep-alive message). > -- > Eran Mann Direct : 972-4-9936230 > Senior Software Engineer Fax : 972-4-9890430 > Optical Access Email : em...@op... > ENTER: ldp_event > TCP_DATA > ->>>>>>>>>>>>>>>>>>>> SOCK: ldp_socket_tcp_read fd 8 > TCP_DATA 62 > Before header decode: size = 62 > OUT: Found type 300 > OUT: 03 00 00 0e 00 00 00 04 01 01 00 06 00 01 0a 0b > OUT: 0c b5 00 01 00 1e 0a 0b 0c b5 00 00 04 00 00 14 > OUT: 00 00 00 05 01 00 00 04 02 00 01 00 02 00 00 04 > OUT: 00 00 01 b2 > OUT: decodedSize for Adr msg = 18 > OUT: LPD Header : protocolVersion = 1 > OUT: pduLength = 24 > OUT: lsrAddress = a0b0cb5 > OUT: labelSpace = 0 > OUT: ADDRESS MSG ***START***: > OUT: baseMsg : uBit = 0 > OUT: msgType = 300 > OUT: msgLength = 14 > OUT: msgId = 4 > OUT: adrListTlv: > OUT: Tlv: > OUT: BaseTlv: uBit = 0 > OUT: fBit = 0 > OUT: type = 101 > OUT: length = 6 > OUT: adrListTlv data: addrFamily = 1 > OUT: adrListTlv addresses (with 1 addresses) : > OUT: > a0b0cb5 > OUT: ADDRESS MSG ***END***: > OUT: Mesg size: 18 (52) > ENTER: ldp_state_machine > OUT: FSM: state 5, event 4 > ENTER: ldp_state_process > ENTER: ldp_addr_process > OUT: Addr Recv: session(1) > EXIT: ldp_addr_process > EXIT: ldp_state_process > EXIT: ldp_state_machine > OUT: Found type 1 > OUT: 00 01 00 1e 0a 0b 0c b5 00 00 04 00 00 14 00 00 > OUT: 00 05 01 00 00 04 02 00 01 00 02 00 00 04 00 00 > OUT: 01 b2 > OUT: decodedSize for Notif msg = -63 > ENTER: ldp_state_machine > OUT: FSM: state 5, event 6 > Entered notif state > ENTER: ldp_state_notif > ENTER: ldp_notif_process > ldp_zebra: ldp_notif.c:160: ldp_notif_process: Assertion `0' failed. > Aborted (core dumped) > > (gdb) bt > #0 0x400624e1 in __kill () from /lib/libc.so.6 > #1 0x40062156 in raise (sig=6) at ../sysdeps/posix/raise.c:27 > #2 0x40063868 in abort () at ../sysdeps/generic/abort.c:88 > #3 0x4005c3ce in __assert_fail (assertion=0x8083be3 "0", > file=0x8083bd7 "ldp_notif.c", line=160, > function=0x8083bc5 "ldp_notif_process") at assert.c:59 > #4 0x8064a7a in ldp_notif_process (g=0x80ace70, s=0x80bba70, a=0x0, e=0x0, > r_attr=0x80bfe88) at ldp_notif.c:160 > #5 0x805f1c0 in ldp_state_notif (g=0x80ace70, s=0x80bba70, adj=0x0, > entity=0x0, event=6, msg=0xbfffbc64, from=0xbffffc54) > at ldp_state_funcs.c:437 > #6 0x805e40e in ldp_state_machine (g=0x80ace70, session=0x80bba70, adj=0x0, > entity=0x0, event=6, msg=0xbfffbc64, from=0xbffffc54) > at ldp_state_machine.c:358 > #7 0x805e230 in ldp_event (g=0x80ace70, socket=0x80ad8c8, user_from=0x0, > if_handle=0x0, buf=0x8091840, extra=0x80bba70, event=LDP_EVENT_NOTIF) > at ldp_state_machine.c:288 > #8 0x806999c in zldp_socket_read_handler (t=0xbffffce4) > at zldp_socket_impl.c:73 > #9 0x80759a6 in thread_call (thread=0xbffffce4) at thread.c:728 > #10 0x804a266 in main (argc=1, argv=0xbffffd54, envp=0xbffffd5c) > at ldp_zebra.c:613 > (gdb) -- James R. Leu |
|
From: James R. L. <jl...@mi...> - 2001-05-20 18:28:18
|
On Sun, May 20, 2001 at 05:56:37PM +0300, Eran Mann wrote: > Hi, > The latest CVS ldp_zebra seems to dump core quite cosistently after an > assertion failure once the 2 neighbours start a session. > Attached is a log of the (end of the) console output, and a backtrace. > It seems to depend on the timing of events - if I reduce the trace level > on the failing neighbour the other one would abort instead (althugh in a > little earlier - after a keep-alive message). LDP is sending some sort of notification message, most likly an unknown mesg (an error in encoding of decoding the message). I have submitted a quick little hack to help figure out which notification messag is being sent. Update your CVS tree, compile, try it again, and let me know which unknown notification type is being sent. I will try this myself but probably not until this evening. Send me your results. Jim > -- > Eran Mann Direct : 972-4-9936230 > Senior Software Engineer Fax : 972-4-9890430 > Optical Access Email : em...@op... > ENTER: ldp_event > TCP_DATA > ->>>>>>>>>>>>>>>>>>>> SOCK: ldp_socket_tcp_read fd 8 > TCP_DATA 62 > Before header decode: size = 62 > OUT: Found type 300 > OUT: 03 00 00 0e 00 00 00 04 01 01 00 06 00 01 0a 0b > OUT: 0c b5 00 01 00 1e 0a 0b 0c b5 00 00 04 00 00 14 > OUT: 00 00 00 05 01 00 00 04 02 00 01 00 02 00 00 04 > OUT: 00 00 01 b2 > OUT: decodedSize for Adr msg = 18 > OUT: LPD Header : protocolVersion = 1 > OUT: pduLength = 24 > OUT: lsrAddress = a0b0cb5 > OUT: labelSpace = 0 > OUT: ADDRESS MSG ***START***: > OUT: baseMsg : uBit = 0 > OUT: msgType = 300 > OUT: msgLength = 14 > OUT: msgId = 4 > OUT: adrListTlv: > OUT: Tlv: > OUT: BaseTlv: uBit = 0 > OUT: fBit = 0 > OUT: type = 101 > OUT: length = 6 > OUT: adrListTlv data: addrFamily = 1 > OUT: adrListTlv addresses (with 1 addresses) : > OUT: > a0b0cb5 > OUT: ADDRESS MSG ***END***: > OUT: Mesg size: 18 (52) > ENTER: ldp_state_machine > OUT: FSM: state 5, event 4 > ENTER: ldp_state_process > ENTER: ldp_addr_process > OUT: Addr Recv: session(1) > EXIT: ldp_addr_process > EXIT: ldp_state_process > EXIT: ldp_state_machine > OUT: Found type 1 > OUT: 00 01 00 1e 0a 0b 0c b5 00 00 04 00 00 14 00 00 > OUT: 00 05 01 00 00 04 02 00 01 00 02 00 00 04 00 00 > OUT: 01 b2 > OUT: decodedSize for Notif msg = -63 > ENTER: ldp_state_machine > OUT: FSM: state 5, event 6 > Entered notif state > ENTER: ldp_state_notif > ENTER: ldp_notif_process > ldp_zebra: ldp_notif.c:160: ldp_notif_process: Assertion `0' failed. > Aborted (core dumped) > > (gdb) bt > #0 0x400624e1 in __kill () from /lib/libc.so.6 > #1 0x40062156 in raise (sig=6) at ../sysdeps/posix/raise.c:27 > #2 0x40063868 in abort () at ../sysdeps/generic/abort.c:88 > #3 0x4005c3ce in __assert_fail (assertion=0x8083be3 "0", > file=0x8083bd7 "ldp_notif.c", line=160, > function=0x8083bc5 "ldp_notif_process") at assert.c:59 > #4 0x8064a7a in ldp_notif_process (g=0x80ace70, s=0x80bba70, a=0x0, e=0x0, > r_attr=0x80bfe88) at ldp_notif.c:160 > #5 0x805f1c0 in ldp_state_notif (g=0x80ace70, s=0x80bba70, adj=0x0, > entity=0x0, event=6, msg=0xbfffbc64, from=0xbffffc54) > at ldp_state_funcs.c:437 > #6 0x805e40e in ldp_state_machine (g=0x80ace70, session=0x80bba70, adj=0x0, > entity=0x0, event=6, msg=0xbfffbc64, from=0xbffffc54) > at ldp_state_machine.c:358 > #7 0x805e230 in ldp_event (g=0x80ace70, socket=0x80ad8c8, user_from=0x0, > if_handle=0x0, buf=0x8091840, extra=0x80bba70, event=LDP_EVENT_NOTIF) > at ldp_state_machine.c:288 > #8 0x806999c in zldp_socket_read_handler (t=0xbffffce4) > at zldp_socket_impl.c:73 > #9 0x80759a6 in thread_call (thread=0xbffffce4) at thread.c:728 > #10 0x804a266 in main (argc=1, argv=0xbffffd54, envp=0xbffffd5c) > at ldp_zebra.c:613 > (gdb) -- James R. Leu |
|
From: Eran M. <er...@nb...> - 2001-05-20 14:54:45
|
Hi, The latest CVS ldp_zebra seems to dump core quite cosistently after an assertion failure once the 2 neighbours start a session. Attached is a log of the (end of the) console output, and a backtrace. It seems to depend on the timing of events - if I reduce the trace level on the failing neighbour the other one would abort instead (althugh in a little earlier - after a keep-alive message). -- Eran Mann Direct : 972-4-9936230 Senior Software Engineer Fax : 972-4-9890430 Optical Access Email : em...@op... |
|
From: Yan, X. Q. (Rex) <re...@lu...> - 2001-05-18 15:38:02
|
Steven, I am going to do something with MPLS and Diffserv. Would you please tell me the url from which I can down load your mpls-tc.2.4.1-0502? or just send it to me via email. Thanks a lot. Rex |
|
From: James R. L. <jl...@mi...> - 2001-05-18 13:02:11
|
On Fri, May 18, 2001 at 03:51:19PM +0530, nomit kalidhar wrote: > Hello > > I am new to MPLS. > I wanted to know how can I see the ILM on a Linux box. > Do I have to install some extra files to make it MPLS enabled. I am > using Linux 7.0 ( 2.2.16-22 ). Short answer yes. Long answer: -get the linux kernel source for version 2.4.2 or higher -get the mpls-linux package from http://sf.net/mpls-linux/ -follow QUICK.START in the mpls-linux package. Jim > Thanks in advance > > Nomit > > _______________________________________________ > mpls-linux-general mailing list > mpl...@li... > http://lists.sourceforge.net/lists/listinfo/mpls-linux-general -- James R. Leu |
|
From: <Cla...@sw...> - 2001-05-18 10:41:00
|
Hi Jim,
Thanks for your response,
I'm not so familiar with the serial console method, and have no suitable
serial cable at the moment. But I noticed that the konsole output was
written in my /var/log/warn file.
So I can provide provide you this file...
at 16:64 I set up the mpls on A
at 16:55 I did a ping from A to C
at 16:56 I try to open do ftp between A and C
(but A hanged up and nothing was written to the file)
I'd like to mention that I cannot send traffic with ftp, since the
A host hangs up during the establishment of the TCP session. I also
tried to send UDP traffic with Mgen and this worked fine.
Hope it'll be useful. I'll try to find this serial cable somewhere...
Claude Germanier
----------------------------------------------------------------------------
-
/var/log/warn file :
May 17 16:54:02 A kernel: mpls_add_out_label: enter
May 17 16:54:02 A kernel: mpls_make_dst: enter
May 17 16:54:02 A kernel: mpls_make_dst: before bind neighbor
May 17 16:54:02 A kernel: mpls_make_dst: bind neighbor succeeded
May 17 16:54:02 A kernel: mpls_make_dst: exit(c2d3e080)
May 17 16:54:02 A kernel: mpls_info_default_moi_instruction: enter
May 17 16:54:02 A kernel: mpls_info_default_moi_instruction: exit
May 17 16:54:02 A kernel: Label GEN 16
May 17 16:54:02 A kernel: Key GEN 16 4
May 17 16:54:02 A kernel: mpls_add_out_label: exit
May 17 16:54:02 A kernel: mpls_prep_out2fec: enter
May 17 16:54:02 A kernel: Label GEN 16
May 17 16:54:02 A kernel: Key GEN 16 4
May 17 16:54:02 A kernel: mpls_fill_key_res: enter
May 17 16:54:02 A kernel: mpls_fill_key_res: exit
May 17 16:54:02 A kernel: mpls_bind_out2fec: copied label to the FIB_NODE
May 17 16:54:02 A kernel: mpls_bind_out2fec: Added FEC to list
May 17 16:54:02 A kernel: mpls_bind_out2fec: exit
May 17 16:54:02 A kernel: mpls_add_in_label: enter
May 17 16:54:02 A kernel: mpls_info_default_in_instruction: enter
May 17 16:54:02 A kernel: mpls_info_default_in_instruction: exit
May 17 16:54:02 A kernel: mpls_add_in_label: exit
May 17 16:55:10 A kernel: rt_set_nexthop: adding label to dst
May 17 16:55:10 A kernel: rt_set_nexthop: before - mtu = 1500
May 17 16:55:10 A kernel: rt_set_nexthop: after - mtu = 1496
May 17 16:55:10 A kernel: mpls_output: enter
May 17 16:55:10 A kernel: mpls_output2: enter
May 17 16:55:10 A kernel: mpls_output2: push
May 17 16:55:10 A kernel: mpls_opcode_push: enter
May 17 16:55:10 A kernel: mpls_opcode_push: using tailroom
May 17 16:55:10 A kernel: mpls_opcode_push: done using tailroom
May 17 16:55:10 A kernel: mpls_opcode_push: exit
May 17 16:55:10 A kernel: mpls_output2: set GEN
May 17 16:55:10 A kernel: mpls_output2: output device = eth0
May 17 16:55:10 A kernel: mpls_finish: enter
May 17 16:55:10 A kernel: mpls_finish: exit
May 17 16:55:10 A kernel: mpls_output2: GEN
May 17 16:55:10 A kernel: mpls_output2: using neighbour (c1a3cb20)
May 17 16:55:10 A kernel: mpls_output2: exit(0)
May 17 16:55:10 A kernel: mpls_output: exit
May 17 16:55:10 A kernel: mpls_rcv: enter
May 17 16:55:10 A kernel: mpls_opcode_peek: enter
May 17 16:55:10 A kernel: mpls_opcode_peek: exit
May 17 16:55:10 A kernel: mpls_input: enter
May 17 16:55:10 A kernel: mpls_input:
labelspace=0,label=17,exp=0,B.O.S=1,TTL=255
May 17 16:55:10 A kernel: mpls_input: pop
May 17 16:55:10 A kernel: mpls_opcode_pop: enter
May 17 16:55:10 A kernel: mpls_opcode_pop: exit
May 17 16:55:10 A kernel: mpls_input: mii_proto 8
May 17 16:55:10 A kernel: mpls_finish: enter
May 17 16:55:10 A kernel: mpls_finish: exit
May 17 16:55:10 A kernel: mpls_input: setting ttl 255
May 17 16:55:10 A kernel: mpls_input: sending to IPv4
May 17 16:55:10 A kernel: skb_dump: from eth0 with len 88 (292) headroom=32
tailroom=4
May 17 16:55:10 A kernel:
060000c04fb4f15d0010a4951d5988470001*0010a4951d5900c04fb4f15d8847{#|45000054
00004000ff01647f0a0101140a01021400009768990200003b03e64e0000c33f08090a0b0c0d
0e0f101112131415161718191a1b1c1d1e1f202122232425262728292a2b2c2d2e2f30313233
343536375ab42cb15ab42cb100}
May 17 16:55:10 A kernel: mpls_input: retval from ip_rcv 0
May 17 16:55:10 A kernel: mpls_input: finished executing in label program
May 17 16:55:10 A kernel: mpls_input: exit
May 17 16:55:10 A kernel: mpls_rcv: exit
May 17 16:55:11 A kernel: mpls_output: enter
May 17 16:55:11 A kernel: mpls_output2: enter
May 17 16:55:11 A kernel: mpls_output2: push
May 17 16:55:11 A kernel: mpls_opcode_push: enter
May 17 16:55:11 A kernel: mpls_opcode_push: using tailroom
May 17 16:55:11 A kernel: mpls_opcode_push: done using tailroom
May 17 16:55:11 A kernel: mpls_opcode_push: exit
May 17 16:55:11 A kernel: mpls_output2: set GEN
May 17 16:55:11 A kernel: mpls_output2: output device = eth0
May 17 16:55:11 A kernel: mpls_finish: enter
May 17 16:55:11 A kernel: mpls_finish: exit
May 17 16:55:11 A kernel: mpls_output2: GEN
May 17 16:55:11 A kernel: mpls_output2: using hh
May 17 16:55:11 A kernel: mpls_output2: exit(0)
May 17 16:55:11 A kernel: mpls_output: exit
May 17 16:55:11 A kernel: mpls_rcv: enter
May 17 16:55:11 A kernel: mpls_opcode_peek: enter
May 17 16:55:11 A kernel: mpls_opcode_peek: exit
May 17 16:55:11 A kernel: mpls_input: enter
May 17 16:55:11 A kernel: mpls_input:
labelspace=0,label=17,exp=0,B.O.S=1,TTL=255
May 17 16:55:11 A kernel: mpls_input: pop
May 17 16:55:11 A kernel: mpls_opcode_pop: enter
May 17 16:55:11 A kernel: mpls_opcode_pop: exit
May 17 16:55:11 A kernel: mpls_input: mii_proto 8
May 17 16:55:11 A kernel: mpls_finish: enter
May 17 16:55:11 A kernel: mpls_finish: exit
May 17 16:55:11 A kernel: mpls_input: setting ttl 255
May 17 16:55:11 A kernel: mpls_input: sending to IPv4
May 17 16:55:11 A kernel: skb_dump: from eth0 with len 88 (292) headroom=32
tailroom=4
May 17 16:55:11 A kernel:
000000c04fb4f15d0010a4951d5988470001*0010a4951d5900c04fb4f15d8847{#|45000054
00004000ff01647f0a0101140a010214000065ac990200013b03e64f0000f4f908090a0b0c0d
0e0f101112131415161718191a1b1c1d1e1f202122232425262728292a2b2c2d2e2f30313233
34353637446a40f3446a40f300}
May 17 16:55:11 A kernel: mpls_input: retval from ip_rcv 0
May 17 16:55:11 A kernel: mpls_input: finished executing in label program
May 17 16:55:11 A kernel: mpls_input: exit
May 17 16:55:11 A kernel: mpls_rcv: exit
May 17 16:55:12 A kernel: mpls_output: enter
May 17 16:55:12 A kernel: mpls_output2: enter
May 17 16:55:12 A kernel: mpls_output2: push
May 17 16:55:12 A kernel: mpls_opcode_push: enter
May 17 16:55:12 A kernel: mpls_opcode_push: using tailroom
May 17 16:55:12 A kernel: mpls_opcode_push: done using tailroom
May 17 16:55:12 A kernel: mpls_opcode_push: exit
May 17 16:55:12 A kernel: mpls_output2: set GEN
May 17 16:55:12 A kernel: mpls_output2: output device = eth0
May 17 16:55:12 A kernel: mpls_finish: enter
May 17 16:55:12 A kernel: mpls_finish: exit
May 17 16:55:12 A kernel: mpls_output2: GEN
May 17 16:55:12 A kernel: mpls_output2: using hh
May 17 16:55:12 A kernel: mpls_output2: exit(0)
May 17 16:55:12 A kernel: mpls_output: exit
May 17 16:55:12 A kernel: mpls_rcv: enter
May 17 16:55:12 A kernel: mpls_opcode_peek: enter
May 17 16:55:12 A kernel: mpls_opcode_peek: exit
May 17 16:55:12 A kernel: mpls_input: enter
May 17 16:55:12 A kernel: mpls_input:
labelspace=0,label=17,exp=0,B.O.S=1,TTL=255
May 17 16:55:12 A kernel: mpls_input: pop
May 17 16:55:12 A kernel: mpls_opcode_pop: enter
May 17 16:55:12 A kernel: mpls_opcode_pop: exit
May 17 16:55:12 A kernel: mpls_input: mii_proto 8
May 17 16:55:12 A kernel: mpls_finish: enter
May 17 16:55:12 A kernel: mpls_finish: exit
May 17 16:55:12 A kernel: mpls_input: setting ttl 255
May 17 16:55:12 A kernel: mpls_input: sending to IPv4
May 17 16:55:12 A kernel: skb_dump: from eth0 with len 88 (292) headroom=32
tailroom=4
May 17 16:55:12 A kernel:
000000c04fb4f15d0010a4951d5988470001*0010a4951d5900c04fb4f15d8847{#|45000054
00004000ff01647f0a0101140a01021400003ea0990200023b03e65000011c0308090a0b0c0d
0e0f101112131415161718191a1b1c1d1e1f202122232425262728292a2b2c2d2e2f30313233
343536378d848e3b8d848e3b00}
May 17 16:55:12 A kernel: mpls_input: retval from ip_rcv 0
May 17 16:55:12 A kernel: mpls_input: finished executing in label program
May 17 16:55:12 A kernel: mpls_input: exit
May 17 16:55:12 A kernel: mpls_rcv: exit
May 17 16:55:13 A kernel: mpls_output: enter
May 17 16:55:13 A kernel: mpls_output2: enter
May 17 16:55:13 A kernel: mpls_output2: push
May 17 16:55:13 A kernel: mpls_opcode_push: enter
May 17 16:55:13 A kernel: mpls_opcode_push: using tailroom
May 17 16:55:13 A kernel: mpls_opcode_push: done using tailroom
May 17 16:55:13 A kernel: mpls_opcode_push: exit
May 17 16:55:13 A kernel: mpls_output2: set GEN
May 17 16:55:13 A kernel: mpls_output2: output device = eth0
May 17 16:55:13 A kernel: mpls_finish: enter
May 17 16:55:13 A kernel: mpls_finish: exit
May 17 16:55:13 A kernel: mpls_output2: GEN
May 17 16:55:13 A kernel: mpls_output2: using hh
May 17 16:55:13 A kernel: mpls_output2: exit(0)
May 17 16:55:13 A kernel: mpls_output: exit
May 17 16:55:13 A kernel: mpls_rcv: enter
May 17 16:55:13 A kernel: mpls_opcode_peek: enter
May 17 16:55:13 A kernel: mpls_opcode_peek: exit
May 17 16:55:13 A kernel: mpls_input: enter
May 17 16:55:13 A kernel: mpls_input:
labelspace=0,label=17,exp=0,B.O.S=1,TTL=255
May 17 16:55:13 A kernel: mpls_input: pop
May 17 16:55:13 A kernel: mpls_opcode_pop: enter
May 17 16:55:13 A kernel: mpls_opcode_pop: exit
May 17 16:55:13 A kernel: mpls_input: mii_proto 8
May 17 16:55:13 A kernel: mpls_finished executing in label program
May 17 16:55:13 A kernel: mpls_input: exit
May 17 16:55:13 A kernel: mpls_rcv: exit
>-----Original Message-----
>From: James R. Leu [mailto:jl...@mi...]
>Sent: Donnerstag, 17. Mai 2001 15:46
>To: Germanier Claude, SGS-CT-SSM
>Cc: mpl...@li...
>Subject: Re: [mpls-linux-general] Problem for establishing a TCP session
>
>
>Can one of you get a serial console setup on the offending machine then
>use that to capture the output from the kernel.
>
>In particular I want you to do "mplsadm -d" before sending traffic. THis
>will turn on the MPLS debugging in the kernel.
>
>Thanks.
>
>Jim
|
|
From: nomit k. <nom...@in...> - 2001-05-18 10:25:36
|
Hello I am new to MPLS. I wanted to know how can I see the ILM on a Linux box. Do I have to install some extra files to make it MPLS enabled. I am using Linux 7.0 ( 2.2.16-22 ). Thanks in advance Nomit |
|
From: Steven V. d. B. <ste...@in...> - 2001-05-18 07:35:39
|
Hi Filip, Please see my comments inline (i'm on some time pressure here, so they're really short), Filip Rosenbaum wrote: > Thanks for your quick answer, > No problemo > > I checked the actual EXP field with ethereal as suggested, and only the first > label/EXP will be used. In fact, the second FEC will be mapped to the first > label/EXP. > Oops, another bug on the wall > > Question: > Is there any way to base the label-selection at the ingress LER on anything > else than the so called FEC which appears to be just an masked IP-destination > address in the linux-mpls? > The "multiple table patch" can solve this. Here you can set up different routing tables for different sources, firewalling results, etc. I mostly use iptables for setting up firewalling rules (that do the classification on whatever you want) and iproute2 for more the routing table configs. You can find more info on http://snafu.freedom.org/linux2.2/iproute-notes.html http://netfilter.samba.org/ So, i hope this helps a little, Best regards, Steven -- Steven Van den Berghe ste...@in... Workgroup Broadband-Networks Department Information Technology Ghent University - Belgium Phone: +32 (0)9 267 35 86 | Fax : +32 (0)9 267 35 99 *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* If your computer says: Printer out of Paper, this problem cannot be resolved by continuously clicking the 'OK' button. *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* |
|
From: Filip R. <fi...@cs...> - 2001-05-18 06:57:14
|
Thanks for your quick answer, I checked the actual EXP field with ethereal as suggested, and only the first label/EXP will be used. In fact, the second FEC will be mapped to the first label/EXP. Question: Is there any way to base the label-selection at the ingress LER on anything else than the so called FEC which appears to be just an masked IP-destination address in the linux-mpls? It is a bit limiting not to be able to distinguish different flows going to the same destination network/host from each other. Will the coming patch allow tc to do both the classification and label-selection/assigning? Regards, Filip Rosenbuam Steven Van den Berghe wrote: > Hi Filip (and all MPLSers), > > First of all, my excuses for the late response and the follow-up on the > mpls patches. It's been quite busy lately, and although the patches are > almost stable now, i haven't put them through the final test phase. This > will be done asap. These will hopefully resolve all the remaining problems > (i'll release 3 patches: the DS patch, multiple table support and > statistics support). > > Concerning your problem: > - i think both labels/exp combinations get registered but don't get > printed (this is just from the top of my hat). > - if this isn't so, i'm very sorry but the patch used was indeed a > dreadful thing with lots of bugs in it. I'll check if it works with the new > patches and release them asap. > > To be certain, could you check with: > > mplsadm -v -A -B -O gen:120/1:eth0:ipv4:10.1.1.2 -f <some fec> > mplsadm -v -A -B -O gen:120/2:eth0:ipv4:10.1.1.2 -f <another fec> > > that there is indeed no possibility to set multiple EXPs (PS use ethereal > to check which EXP the packets are getting) > > Thanks, > Steven > > Filip Rosenbaum wrote: > > > Hi, > > > > I've just updated my mpls configuration to mpls-linux-0.990 on kernel > > 2.4.2 patched with Van Den Berghe's tc patch mpls-tc.2.4.1-0502. > > > > Questions: > > 1. When I try to configure a LER with two outgoing label-entries with > > the very same label but different EXP values, the second one doesn't get > > registered. Aren't I supposed to have one label/EXP entry for each > > aggregated flow that I wish to support at the LER? Whats wrong? > > > > mplsadm -v -A -O gen:120/1:eth0:ipv4:10.1.1.2 > > mplsadm -v -A -O gen:120/2:eth0:ipv4:10.1.1.2 > > > > 2. Same holds when I want to configure the LSR to do label swapping > > based on label/EXP pairs. The second one doesn't get registered, is it > > supposed to be like this? > > > > mplsadm -v -A -I gen:113/4:0 -O gen:122/2:eth0:ipv4:10.1.1.2 -B > > mplsadm -v -A -I gen:113/3:0 -O gen:122/3:eth0:ipv4:10.1.1.2 -B > > > > Thankful for any help, hints or pointers! > > > > /Filip Rosenbaum > > > > _______________________________________________ > > mpls-linux-general mailing list > > mpl...@li... > > http://lists.sourceforge.net/lists/listinfo/mpls-linux-general > > -- > Steven Van den Berghe > ste...@in... > Workgroup Broadband-Networks > Department Information Technology > Ghent University - Belgium > Phone: +32 (0)9 267 35 86 | Fax : +32 (0)9 267 35 99 > *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* > Unix is user friendly - it's just picky about it's > friends. > > *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* |
|
From: Steven V. d. B. <ste...@in...> - 2001-05-17 15:21:04
|
Hi Filip (and all MPLSers), First of all, my excuses for the late response and the follow-up on the mpls patches. It's been quite busy lately, and although the patches are almost stable now, i haven't put them through the final test phase. This will be done asap. These will hopefully resolve all the remaining problems (i'll release 3 patches: the DS patch, multiple table support and statistics support). Concerning your problem: - i think both labels/exp combinations get registered but don't get printed (this is just from the top of my hat). - if this isn't so, i'm very sorry but the patch used was indeed a dreadful thing with lots of bugs in it. I'll check if it works with the new patches and release them asap. To be certain, could you check with: mplsadm -v -A -B -O gen:120/1:eth0:ipv4:10.1.1.2 -f <some fec> mplsadm -v -A -B -O gen:120/2:eth0:ipv4:10.1.1.2 -f <another fec> that there is indeed no possibility to set multiple EXPs (PS use ethereal to check which EXP the packets are getting) Thanks, Steven Filip Rosenbaum wrote: > Hi, > > I've just updated my mpls configuration to mpls-linux-0.990 on kernel > 2.4.2 patched with Van Den Berghe's tc patch mpls-tc.2.4.1-0502. > > Questions: > 1. When I try to configure a LER with two outgoing label-entries with > the very same label but different EXP values, the second one doesn't get > registered. Aren't I supposed to have one label/EXP entry for each > aggregated flow that I wish to support at the LER? Whats wrong? > > mplsadm -v -A -O gen:120/1:eth0:ipv4:10.1.1.2 > mplsadm -v -A -O gen:120/2:eth0:ipv4:10.1.1.2 > > 2. Same holds when I want to configure the LSR to do label swapping > based on label/EXP pairs. The second one doesn't get registered, is it > supposed to be like this? > > mplsadm -v -A -I gen:113/4:0 -O gen:122/2:eth0:ipv4:10.1.1.2 -B > mplsadm -v -A -I gen:113/3:0 -O gen:122/3:eth0:ipv4:10.1.1.2 -B > > Thankful for any help, hints or pointers! > > /Filip Rosenbaum > > _______________________________________________ > mpls-linux-general mailing list > mpl...@li... > http://lists.sourceforge.net/lists/listinfo/mpls-linux-general -- Steven Van den Berghe ste...@in... Workgroup Broadband-Networks Department Information Technology Ghent University - Belgium Phone: +32 (0)9 267 35 86 | Fax : +32 (0)9 267 35 99 *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* Unix is user friendly - it's just picky about it's friends. *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* |
|
From: James R. L. <jl...@mi...> - 2001-05-17 14:14:24
|
I'm not going to be very usefull in debugging this. Maybe Steven could help out? Jim On Thu, May 17, 2001 at 10:01:39PM +1000, Filip Rosenbaum wrote: > Hi, > > I've just updated my mpls configuration to mpls-linux-0.990 on kernel > 2.4.2 patched with Van Den Berghe's tc patch mpls-tc.2.4.1-0502. > > Questions: > 1. When I try to configure a LER with two outgoing label-entries with > the very same label but different EXP values, the second one doesn't get > registered. Aren't I supposed to have one label/EXP entry for each > aggregated flow that I wish to support at the LER? Whats wrong? > > mplsadm -v -A -O gen:120/1:eth0:ipv4:10.1.1.2 > mplsadm -v -A -O gen:120/2:eth0:ipv4:10.1.1.2 > > > 2. Same holds when I want to configure the LSR to do label swapping > based on label/EXP pairs. The second one doesn't get registered, is it > supposed to be like this? > > mplsadm -v -A -I gen:113/4:0 -O gen:122/2:eth0:ipv4:10.1.1.2 -B > mplsadm -v -A -I gen:113/3:0 -O gen:122/3:eth0:ipv4:10.1.1.2 -B > > > Thankful for any help, hints or pointers! > > /Filip Rosenbaum > > > _______________________________________________ > mpls-linux-general mailing list > mpl...@li... > http://lists.sourceforge.net/lists/listinfo/mpls-linux-general -- James R. Leu |
|
From: James R. L. <jl...@mi...> - 2001-05-17 14:02:35
|
On Wed, May 16, 2001 at 02:09:00PM -0700, Scott Lee wrote: > Hi James, > > Can I ask you a question on LDP? If you have the > following topology: > > A-----B > | | > C-----D > > >From A's perspective, there are two equal cost paths > to D. That means when A receives label mappings from > B and C, it can use the label value learnt from B when > forwarding the packet to D via B and use the label > value learnt from C when forwarding packet to D via C. > Let's assume that A can perform load-balancing based > on source IP address so that you would not get out > of order packets at the final destination. > > Question1: Is this supported in LDP? > LDP mentioned somthing like multipath is not supported > in this version. What does that mean? The draft say no. BUT... In unsolicited mode A will recieve labels from B and C for FECs reachably by D. It is upto A how it would like to handle these labels. It is a local descision so as long as A can add labels to the route for each next hop it should work. Does my code support this? No. Can I add it, yeah. Up until now I've been ignoring multipath. > Question2: In ordered control mode, when A receives > the label mapping from B, does A sends another label > mapping message to C (because the mapping came from > the next hop)? I guess C would not send another > mapping > message to D because the mapping message did not > come from the next hop? Correct. A has no way of knowing whether C has a route to D that doesn not go through A. So A must send forward the mappings. As you said C will realize that the mapping isn't along the shortest path and will not forward it. > Question3: Does B advertise label for FEC whose next > hop is C to C also? (I think in the ind control mode, > B does and the ordered control mode, B does not.) When running LDP over ethernet with Cisco I see this behavior. It is quite odd, I'm not of the rational, but it doesn't break anything. Jim > Thanks again, James. > > Scott > > __________________________________________________ > Do You Yahoo!? > Yahoo! Auctions - buy the things you want at great prices > http://auctions.yahoo.com/ > > _______________________________________________ > mpls-linux-general mailing list > mpl...@li... > http://lists.sourceforge.net/lists/listinfo/mpls-linux-general -- James R. Leu |
|
From: James R. L. <jl...@mi...> - 2001-05-17 13:45:55
|
Can one of you get a serial console setup on the offending machine then use that to capture the output from the kernel. In particular I want you to do "mplsadm -d" before sending traffic. THis will turn on the MPLS debugging in the kernel. Thanks. Jim On Mon, May 14, 2001 at 03:49:45PM +0200, Cla...@sw... wrote: > Hi all, > > I have the same problem as Marcello described in his > "Kernel Panic with TCP flows" message. > > I configured the following topology : > > # subnets: 10.1.2.0/24 10.1.1.0/24 > # hosts: A===================B=====================C > # interf: eth0 eth0 eth2 eth2 > # IPaddr: 10.1.2.20 | 10.1.1.10 | > # 10.1.2.10 10.1.1.20 > # > # labels ->->->->->->->->->16>->->->->->->->->->-> > # & LSP : <-<-<-<-<-<-<-<-<-17-<-<-<-<-<-<-<-<-<-<- > > I'm using the mpls-linux-0.990, with the 2.4.1 linux kernel. > > Everthing's working fine for ICMP or UDP flows. I'm using > Ethereal to observe traffic and I see the labels, datas > are transmitted correctly... > > But when I try to establish a TCP session, the client hangs up. > On the router B, I see the first TCP segment [SYN] > going from the client to the host. I also see the 2nd segment > [SYN,ACK] going from the host to the client. But the 3rd segment > is never emitted from the dead client... R.I.P. > > Did you solve the problem Marcello ? Does anyone have an idea ?? > > Thanks > > > Claude Germanier > > > > BTW here are the commands I used to set up the topology : > > SUBN1=``10.1.1.0'' > SUBN2=``10.1.2.0'' > NMSK=``255.255.255.0'' > IP1=``10.1.2.20'' > IP2=``10.1.2.10'' > IP3=``10.1.1.10'' > IP4=``10.1.1.20'' > LBL1=``16'' > LBL2=``17'' > #on A > route add -net $SUBN2 netmask $NMSK dev eth0 > route add -host $IP4 gw $IP2 > mplsadm -vd -A -B -O gen:$LBL1:eth0:ipv4:$IP2 -f $IP4/32 > mplsadm -vd -L eth0:0 > mplsadm -vd -A -I gen:$LBL2:0 > #on B > route add -net $SUBN2 netmask $NMSK gw $IP2 > mplsadm -vd -L eth0:0 > mplsadm -vd -A -B -I gen:$LBL1:0 -O gen:$LBL1:eth2:ipv4:$IP4 > route add -net $SUBN1 netmask $NMSK gw $IP3 > mplsadm -vd -L eth2:0 > mplsadm -vd -A -B -I gen:$LBL2:0 -O gen:$LBL2:eth0:ipv4:$IP1 > #on C > mplsadm -vd -L eth2:0 > mplsadm -vd -A -I gen:$LBL1:0 > route add -net $SUBN1 netmask $NMSK dev eth2 > route add -host $IP1 gw $IP3 > mplsadm -vd -A -B -O gen:$LBL2:eth2:ipv4:$IP3 -f $IP1/32 > > _______________________________________________ > mpls-linux-general mailing list > mpl...@li... > http://lists.sourceforge.net/lists/listinfo/mpls-linux-general -- James R. Leu |
|
From: Filip R. <fi...@cs...> - 2001-05-17 12:03:08
|
Hi, I've just updated my mpls configuration to mpls-linux-0.990 on kernel 2.4.2 patched with Van Den Berghe's tc patch mpls-tc.2.4.1-0502. Questions: 1. When I try to configure a LER with two outgoing label-entries with the very same label but different EXP values, the second one doesn't get registered. Aren't I supposed to have one label/EXP entry for each aggregated flow that I wish to support at the LER? Whats wrong? mplsadm -v -A -O gen:120/1:eth0:ipv4:10.1.1.2 mplsadm -v -A -O gen:120/2:eth0:ipv4:10.1.1.2 2. Same holds when I want to configure the LSR to do label swapping based on label/EXP pairs. The second one doesn't get registered, is it supposed to be like this? mplsadm -v -A -I gen:113/4:0 -O gen:122/2:eth0:ipv4:10.1.1.2 -B mplsadm -v -A -I gen:113/3:0 -O gen:122/3:eth0:ipv4:10.1.1.2 -B Thankful for any help, hints or pointers! /Filip Rosenbaum |
|
From: devy g. <de...@ya...> - 2001-05-17 09:08:08
|
please post mpls mailing list to my mail thanks __________________________________________________ Do You Yahoo!? Yahoo! Auctions - buy the things you want at great prices http://auctions.yahoo.com/ |
|
From: Scott L. <nat...@ya...> - 2001-05-16 21:09:04
|
Hi James, Can I ask you a question on LDP? If you have the following topology: A-----B | | C-----D From A's perspective, there are two equal cost paths to D. That means when A receives label mappings from B and C, it can use the label value learnt from B when forwarding the packet to D via B and use the label value learnt from C when forwarding packet to D via C. Let's assume that A can perform load-balancing based on source IP address so that you would not get out of order packets at the final destination. Question1: Is this supported in LDP? LDP mentioned somthing like multipath is not supported in this version. What does that mean? Question2: In ordered control mode, when A receives the label mapping from B, does A sends another label mapping message to C (because the mapping came from the next hop)? I guess C would not send another mapping message to D because the mapping message did not come from the next hop? Question3: Does B advertise label for FEC whose next hop is C to C also? (I think in the ind control mode, B does and the ordered control mode, B does not.) Thanks again, James. Scott __________________________________________________ Do You Yahoo!? Yahoo! Auctions - buy the things you want at great prices http://auctions.yahoo.com/ |
|
From: James R. L. <jl...@mi...> - 2001-05-16 13:00:23
|
(could you please use the mpl...@li... list) On Wed, May 16, 2001 at 01:04:37AM -0700, yt...@12... wrote: > Hi all, > I have a Qn in LDP. When LDP receives label mapping message from its adjacent peer, is it required to install the label in FTN table eventhough its not ingress?. How u define Ingress?. The one which generates label request message is the Ingress. Am i right?. Each LSR needs decieds whether it will be ingress for a particular FEC. The rules that it uses for this will change based on policies created by the administrator of the network. For example, in the core of your network you may not want to be ingress for ANY FECs, but at the edge you want to be ingress for every FEC. This is normally controlled through access-lists route-maps or policy statments. > In MPLS linux LDP code, during label mapping message the function "ldp_policy_ingress_check" is invoked. If u walk through this function it is just returns TRUE. Thats all. If one want to install label always in FTN table why it need to call this func?. Pls let me know. Remeber that ldp-portable is meant to be run on other environments then the linux-port. For example the zebra-port may add access-list processing to ldp_policy_ingress_check(). The linux-port is only an example of how to implement a porting layer. Jim -- James R. Leu |
|
From: James R. L. <jl...@mi...> - 2001-05-14 20:13:10
|
On Tue, May 08, 2001 at 03:52:15PM +0300, Eran Mann wrote: > Hi, > The first patch below fixes FEC prefix encoding (well, at least for me). I have question about this, see below: > The second fixes an informational printf. Applied. > (the patches are against the CVS tree with the message length patch > from http://www.geocrawler.com/archives/3/7968/2001/4/0/5654868/ > applied). I think that the above patch is applied in the CVS tree. With that patch were you only seeing mesg length problems when a FEC TLV existed or did you see mesg length problems across the board. You can easily check this out by turning on all tracing and compare the numbers at the end of the output coming from line 208 of ldp_buf.c or 428 of the same file. Thanks, Jim > > -- > Eran Mann Direct : 972-4-9936230 > Senior Software Engineer Fax : 972-4-9890430 > Optical Access Email : em...@op... > Index: ldp_label_mapping.c > =================================================================== > RCS file: /cvsroot/mpls-linux/ldp-portable/lib/ldp_label_mapping.c,v > retrieving revision 1.6 > diff -u -r1.6 ldp_label_mapping.c > --- ldp_label_mapping.c 2001/04/21 07:21:32 1.6 > +++ ldp_label_mapping.c 2001/05/08 11:57:25 > @@ -120,7 +120,7 @@ > if(ldp_fib_get_route(g->fib_handle,1,&dest,&route) != 1) { > /* JLEU: how to handle the multipath case */ > LDP_TRACE_LOG(g->user_data,LDP_TRACE_STATE_ALL,LDP_TRACE_FLAG_NORMAL, > - "No route to FEC (%08x/%d)\n",route.network.u.ipv4,route.prefix_len); > + "No route to FEC (%08x/%d)\n",dest.network.u.ipv4,dest.prefix_len); > return LDP_NO_ROUTE; > } > if(route.next_hop.protocol != 0) { > Index: ldp_nortel.c > =================================================================== > RCS file: /cvsroot/mpls-linux/ldp-portable/lib/ldp_nortel.c,v > retrieving revision 1.1.1.1 > diff -u -r1.1.1.1 ldp_nortel.c > --- ldp_nortel.c 2000/12/02 01:31:52 1.1.1.1 > +++ ldp_nortel.c 2001/05/08 11:49:44 > @@ -2707,14 +2707,14 @@ > } > case MPLS_PREFIX_FEC: > { > - fecAdrEl->addressEl.addressFam = htons(fecAdrEl->addressEl.addressFam); > - fecAdrEl->addressEl.address = htonl(fecAdrEl->addressEl.address); > + int preLenOctets = (int)(fecAdrEl->addressEl.preLen / 8) + > + ((int)(fecAdrEl->addressEl.preLen % 8) > 0 ? 1 : 0); > + > + fecAdrEl->addressEl.addressFam = htons(fecAdrEl->addressEl.addressFam); > + > + encodedSize = MPLS_FEC_ADRFAMLEN + MPLS_FEC_ELEMTYPELEN + > + MPLS_FEC_PRELENLEN + preLenOctets; > > - encodedSize = MPLS_FEC_ADRFAMLEN + MPLS_FEC_ELEMTYPELEN + > - MPLS_FEC_PRELENLEN + > - (int)(fecAdrEl->addressEl.preLen / 8) + > - ((int)(fecAdrEl->addressEl.preLen % 8) > 0 ? 1 : 0); > - > if (encodedSize > bufSize) > { > return MPLS_ENC_BUFFTOOSMALL; > @@ -2731,9 +2731,8 @@ > tempBuf++; /* for MPLS_FEC_PRELENLEN */ > > MEM_COPY( tempBuf, > - (u_char*)&(fecAdrEl->addressEl.address), > - (int)(fecAdrEl->addressEl.preLen / 8) + > - ((int)(fecAdrEl->addressEl.preLen % 8) > 0 ? 1 : 0)); > + (u_char*)(&(fecAdrEl->addressEl.address)), > + preLenOctets ); > break; > } > case MPLS_HOSTADR_FEC: -- James R. Leu |
|
From: <Cla...@sw...> - 2001-05-14 13:50:02
|
Hi all, I have the same problem as Marcello described in his "Kernel Panic with TCP flows" message. I configured the following topology : # subnets: 10.1.2.0/24 10.1.1.0/24 # hosts: A===================B=====================C # interf: eth0 eth0 eth2 eth2 # IPaddr: 10.1.2.20 | 10.1.1.10 | # 10.1.2.10 10.1.1.20 # # labels ->->->->->->->->->16>->->->->->->->->->-> # & LSP : <-<-<-<-<-<-<-<-<-17-<-<-<-<-<-<-<-<-<-<- I'm using the mpls-linux-0.990, with the 2.4.1 linux kernel. Everthing's working fine for ICMP or UDP flows. I'm using Ethereal to observe traffic and I see the labels, datas are transmitted correctly... But when I try to establish a TCP session, the client hangs up. On the router B, I see the first TCP segment [SYN] going from the client to the host. I also see the 2nd segment [SYN,ACK] going from the host to the client. But the 3rd segment is never emitted from the dead client... R.I.P. Did you solve the problem Marcello ? Does anyone have an idea ?? Thanks Claude Germanier BTW here are the commands I used to set up the topology : SUBN1=``10.1.1.0'' SUBN2=``10.1.2.0'' NMSK=``255.255.255.0'' IP1=``10.1.2.20'' IP2=``10.1.2.10'' IP3=``10.1.1.10'' IP4=``10.1.1.20'' LBL1=``16'' LBL2=``17'' #on A route add -net $SUBN2 netmask $NMSK dev eth0 route add -host $IP4 gw $IP2 mplsadm -vd -A -B -O gen:$LBL1:eth0:ipv4:$IP2 -f $IP4/32 mplsadm -vd -L eth0:0 mplsadm -vd -A -I gen:$LBL2:0 #on B route add -net $SUBN2 netmask $NMSK gw $IP2 mplsadm -vd -L eth0:0 mplsadm -vd -A -B -I gen:$LBL1:0 -O gen:$LBL1:eth2:ipv4:$IP4 route add -net $SUBN1 netmask $NMSK gw $IP3 mplsadm -vd -L eth2:0 mplsadm -vd -A -B -I gen:$LBL2:0 -O gen:$LBL2:eth0:ipv4:$IP1 #on C mplsadm -vd -L eth2:0 mplsadm -vd -A -I gen:$LBL1:0 route add -net $SUBN1 netmask $NMSK dev eth2 route add -host $IP1 gw $IP3 mplsadm -vd -A -B -O gen:$LBL2:eth2:ipv4:$IP3 -f $IP1/32 |
|
From: Edward P. <epa...@ya...> - 2001-05-13 20:17:15
|
__________________________________________________ Do You Yahoo!? Yahoo! Auctions - buy the things you want at great prices http://auctions.yahoo.com/ |
|
From: James R. L. <jl...@mi...> - 2001-05-12 16:16:12
|
Hello all, Sorry for not answering any questions for the last couple of weeks, I've been at the Networld+InterOp MPLS iLab working like a dog. I'll try to catch up on all of the e-mails over the next week. Jim -- James R. Leu |
|
From: Elio F. <el...@ti...> - 2001-05-10 06:41:35
|
Hello,
I've followed the Readme.cli instruction about ldp-portable but the ldp
don't bind the FEC to the outgoing label.
If I look into /proc/net/mpls_out or /proc/net/mpls_fec I don't find
nothing.
Here is my net:
lo 10.0.0.1 lo 10.0.0.2
-------- -------
| A | | B |
-------- -------
.200| 131.114.33.0/24 |.172
------------------------------------------
Host A's table routing :
Destination Gateway Genmask Flags
Metric Ref Use Iface
10.0.0.1 0.0.0.0 255.255.255.255 UH 0
0 0 lo
10.0.0.2 131.114.33.172 255.255.255.255 UGH 0 0
0 eth0
131.114.33.128 0.0.0.0 255.255.255.128 U 0 0
0 eth0
192.168.4.0 0.0.0.0 255.255.255.0 U 0
0 0 eth1
10.0.1.0 131.114.33.172 255.255.255.0 UG 0 0
0 eth0
127.0.0.0 0.0.0.0 255.0.0.0 U
0 0 0 lo
0.0.0.0 131.114.33.129 0.0.0.0 UG 1
0 0 eth0
Host B's table routing:
Destination Gateway Genmask Flags
Metric Ref Use Iface
10.0.0.1 131.114.33.200 255.255.255.255 UGH 0 0
0 eth0
10.0.0.2 0.0.0.0 255.255.255.255 UH
0 0 0 lo
131.114.33.128 0.0.0.0 255.255.255.128 U 0
0 0 eth0
192.168.4.0 131.114.33.200 255.255.255.0 UG 0 0
0 eth0
10.0.1.0 0.0.0.0 255.255.255.0 U
0 0 0 eth1
127.0.0.0 0.0.0.0 255.0.0.0 U
0 0 0 lo
0.0.0.0 131.114.33.129 0.0.0.0 UG
1 0 0 eth0
ldp_linux command:
Host A:
add global 10.0.0.1
add i eth0
show session
1 837221ac 45 5
show database
1 0a000001/32 3 via 2
2 0a000002/32 3 via 2
3 0a000100/24 3 via 2
4 7f000000/8 3 via 2
5 83722180/31 3 via 2
6 c0a80400/24 3 via 2
7 0a000001/32 2 via 2
8 0a000002/32 2 via 2
9 0a000100/24 2 via 2
10 7f000000/8 2 via 2
11 83722180/31 2 via 2
12 c0a80400/24 2 via 2
Host B:
add global 10.0.0.2
add i eth0
show session
1 837221ac 45 5
show database
1 0a000001/32 3 via 2
2 0a000002/32 3 via 2
3 0a000100/24 3 via 2
4 7f000000/8 3 via 2
5 83722180/31 3 via 2
6 c0a80400/24 3 via 2
7 0a000001/32 2 via 2
8 0a000002/32 2 via 2
9 0a000100/24 2 via 2
10 7f000000/8 2 via 2
11 83722180/31 2 via 2
12 c0a80400/24 2 via 2
Thank you for an answer,
Elio
|
|
From: Elio F. <el...@ti...> - 2001-05-09 22:25:58
|
Hello,
I've followed the Readme.cli instruction about ldp-portable but the ldp
don't bind the FEC to the outgoing label.
If I look into /proc/net/mpls_out or /proc/net/mpls_fec I don't find
nothing.
Here is my net:
lo 10.0.0.1 lo 10.0.0.2
-------- -------
| A | | B |
-------- -------
.200| 131.114.33.0/24 |.172
------------------------------------------
Host A's table routing :
Destination Gateway Genmask Flags
Metric Ref Use Iface
10.0.0.1 0.0.0.0 255.255.255.255 UH 0
0 0 lo
10.0.0.2 131.114.33.172 255.255.255.255 UGH 0 0
0 eth0
131.114.33.128 0.0.0.0 255.255.255.128 U 0 0
0 eth0
192.168.4.0 0.0.0.0 255.255.255.0 U 0
0 0 eth1
10.0.1.0 131.114.33.172 255.255.255.0 UG 0 0
0 eth0
127.0.0.0 0.0.0.0 255.0.0.0 U
0 0 0 lo
0.0.0.0 131.114.33.129 0.0.0.0 UG 1
0 0 eth0
Host B's table routing:
Destination Gateway Genmask Flags
Metric Ref Use Iface
10.0.0.1 131.114.33.200 255.255.255.255 UGH 0 0
0 eth0
10.0.0.2 0.0.0.0 255.255.255.255 UH
0 0 0 lo
131.114.33.128 0.0.0.0 255.255.255.128 U 0
0 0 eth0
192.168.4.0 131.114.33.200 255.255.255.0 UG 0 0
0 eth0
10.0.1.0 0.0.0.0 255.255.255.0 U
0 0 0 eth1
127.0.0.0 0.0.0.0 255.0.0.0 U
0 0 0 lo
0.0.0.0 131.114.33.129 0.0.0.0 UG
1 0 0 eth0
ldp_linux command:
Host A:
add global 10.0.0.1
add i eth0
show session
1 837221ac 45 5
show database
1 0a000001/32 3 via 2
2 0a000002/32 3 via 2
3 0a000100/24 3 via 2
4 7f000000/8 3 via 2
5 83722180/31 3 via 2
6 c0a80400/24 3 via 2
7 0a000001/32 2 via 2
8 0a000002/32 2 via 2
9 0a000100/24 2 via 2
10 7f000000/8 2 via 2
11 83722180/31 2 via 2
12 c0a80400/24 2 via 2
Host B:
add global 10.0.0.2
add i eth0
show session
1 837221ac 45 5
show database
1 0a000001/32 3 via 2
2 0a000002/32 3 via 2
3 0a000100/24 3 via 2
4 7f000000/8 3 via 2
5 83722180/31 3 via 2
6 c0a80400/24 3 via 2
7 0a000001/32 2 via 2
8 0a000002/32 2 via 2
9 0a000100/24 2 via 2
10 7f000000/8 2 via 2
11 83722180/31 2 via 2
12 c0a80400/24 2 via 2
Thank you for an answer,
Elio
|
|
From: eliofr <el...@ti...> - 2001-05-09 14:04:49
|
-- TiscaliNet, libero accesso ad Internet. http://www.tiscalinet.it |
|
From: eliofr <el...@ti...> - 2001-05-09 14:04:35
|
-- TiscaliNet, libero accesso ad Internet. http://www.tiscalinet.it |
533 messages has been excluded from this view by a project administrator.
