Thread: [mpls-linux-devel] A few problems with ldpd
Status: Beta
Brought to you by:
jleu
Menu
▾
▴
mpls-linux-devel
|
From: Scott A. Y. <sy...@im...> - 2008-03-24 21:18:10
|
Hi James. I've been able to get ldpd working quite well with 3 routers in my testbed. Even
the targeted ldp sessions now appear to be working. I have a left LSR, middle, LSR and right LSR. The
targeted session is between the left and right routers.
I've found a few problems and want to get your take on how best to fix them.
1) The xconnect command needs to have the destination IP address stored in host byte order.
--- ldp_vty.c Tue Mar 25 01:19:59 2008
+++ ldp_vty-new.c Wed Mar 19 01:55:44 2008
@@ -1618,6 +1618,7 @@
dest.port = 646;
VTY_GET_UINT32_RANGE("VCID",vcid,argv[1],0,255);
+ dest.addr.u.ipv4 = ntohl(dest.addr.u.ipv4);
if (ldp_remote_peer_find(ldp, &dest)) {
return CMD_WARNING;
2) I found a couple of memory leaks with valgrind:
--- ldp_session.c Fri Jan 4 23:58:59 2008
+++ ldp_session-new.c Tue Mar 25 01:25:32 2008
@@ -252,6 +252,8 @@
{
LDP_PRINT(NULL, "session delete");
MPLS_REFCNT_ASSERT(s, 0);
+ ldp_buf_delete(s->tx_buffer);
+ ldp_mesg_delete(s->tx_message);
mpls_free(s);
}
--- ldp_buf.c Tue Mar 25 01:29:01 2008
+++ ldp_buf-new.c Fri Mar 21 21:18:06 2008
@@ -49,6 +49,8 @@
void ldp_buf_delete(ldp_buf * b)
{
MPLS_ASSERT(b);
+ if (b->buffer)
+ mpls_free(b->buffer);
mpls_free(b);
}
These 2 leaks caused ldpd to grow several megabytes per hour on my system.
3) ldpd cannot establish more than 1 session at a time.
I don't know if I have a config error but I keep getting a "ldp_addr_process: session X already advertised this address"
error when the 2nd router attempts to start up a session. I think the address is 127.0.0.1. I tried changing the lsr-id and
transport address but that caused ldpd to crash. The neighbor's status is stuck in the discovery state.
Just to get around this problem and keep going I stuck a return MPLS_SUCCESS in ldpd/ldp_addr.c line 315:
/* the addr is in the tree */
if (addr->session) {
LDP_PRINT(g->user_data,
"ldp_addr_process: session (%d) already advertised this address\n",
addr->session->index);
return MPLS_SUCCESS;
return MPLS_FAILURE;
}
Is there something I'm missing with the config to support multiple peers?
Thanks,
Scott Yoder
Support Engineer
ImageStream Internet Solutions, Inc.
E-mail: sy...@im...
|
|
From: James R. L. <jl...@mi...> - 2008-03-25 01:35:53
|
Good stuff. Thank you for working with ldp-portable and taking the
time to dig into the code. I've incorporated your fixes for the memory
leaks and I'm double checking the byte order fix you suggest.
As far as the multiple session issue, I think the fix is to never
send any 127.0.0.0/8 addresses in the address message. One way to
accomplish this is to never register 127.0.0.0/8 addresses with
LDP by modifing ldp_interface_address_add() in ldp_zebra.c.
On Mon, Mar 24, 2008 at 04:58:20PM -0400, Scott A. Yoder wrote:
> Hi James. I've been able to get ldpd working quite well with 3 routers in my testbed. Even
> the targeted ldp sessions now appear to be working. I have a left LSR, middle, LSR and right LSR. The
> targeted session is between the left and right routers.
>
> I've found a few problems and want to get your take on how best to fix them.
>
> 1) The xconnect command needs to have the destination IP address stored in host byte order.
>
> --- ldp_vty.c Tue Mar 25 01:19:59 2008
> +++ ldp_vty-new.c Wed Mar 19 01:55:44 2008
> @@ -1618,6 +1618,7 @@
> dest.port = 646;
>
> VTY_GET_UINT32_RANGE("VCID",vcid,argv[1],0,255);
> + dest.addr.u.ipv4 = ntohl(dest.addr.u.ipv4);
>
> if (ldp_remote_peer_find(ldp, &dest)) {
> return CMD_WARNING;
>
>
> 2) I found a couple of memory leaks with valgrind:
>
> --- ldp_session.c Fri Jan 4 23:58:59 2008
> +++ ldp_session-new.c Tue Mar 25 01:25:32 2008
> @@ -252,6 +252,8 @@
> {
> LDP_PRINT(NULL, "session delete");
> MPLS_REFCNT_ASSERT(s, 0);
> + ldp_buf_delete(s->tx_buffer);
> + ldp_mesg_delete(s->tx_message);
> mpls_free(s);
> }
>
> --- ldp_buf.c Tue Mar 25 01:29:01 2008
> +++ ldp_buf-new.c Fri Mar 21 21:18:06 2008
> @@ -49,6 +49,8 @@
> void ldp_buf_delete(ldp_buf * b)
> {
> MPLS_ASSERT(b);
> + if (b->buffer)
> + mpls_free(b->buffer);
> mpls_free(b);
> }
>
>
> These 2 leaks caused ldpd to grow several megabytes per hour on my system.
>
>
> 3) ldpd cannot establish more than 1 session at a time.
>
> I don't know if I have a config error but I keep getting a "ldp_addr_process: session X already advertised this address"
> error when the 2nd router attempts to start up a session. I think the address is 127.0.0.1. I tried changing the lsr-id and
> transport address but that caused ldpd to crash. The neighbor's status is stuck in the discovery state.
>
> Just to get around this problem and keep going I stuck a return MPLS_SUCCESS in ldpd/ldp_addr.c line 315:
>
> /* the addr is in the tree */
> if (addr->session) {
> LDP_PRINT(g->user_data,
> "ldp_addr_process: session (%d) already advertised this address\n",
> addr->session->index);
> return MPLS_SUCCESS;
> return MPLS_FAILURE;
> }
>
> Is there something I'm missing with the config to support multiple peers?
>
> Thanks,
> Scott Yoder
> Support Engineer
> ImageStream Internet Solutions, Inc.
> E-mail: sy...@im...
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2008.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> mpls-linux-devel mailing list
> mpl...@li...
> https://lists.sourceforge.net/lists/listinfo/mpls-linux-devel
--
James R. Leu
jl...@mi...
|
|
From: Chris R. <Chr...@nr...> - 2008-03-25 16:17:41
|
James
Where are you with working toward kernel-2.6.24.4-51/53? There are
changes with the debug tags, causing some grief that the pull from the
P4 mpls-linux-1.1 repository (which is still at 2.6.23) are not
addressing. If you're close, I'll stop pulling my hair
out......:-D..... it seems the method to create the tags (aka
/proc/net/mpls or shim) have changed. For example, the routine wont
compile because:
proc_net_remove("mpls");
required 2 parameters which I thing should be:
proc_net_remove(&init_net, "mpls");
and the "dev_get_by_???" I think change to:
dev_get_by_??? (&init_net, name);
but I still get a complaint at boot time about not finding "/net/mpls"
(yeah I need to get more info and will soon).
Note, there are other changes but those are cosmetic such as simple
locations.
thanks....chris
James R. Leu wrote:
> Good stuff. Thank you for working with ldp-portable and taking the
> time to dig into the code. I've incorporated your fixes for the memory
> leaks and I'm double checking the byte order fix you suggest.
>
> As far as the multiple session issue, I think the fix is to never
> send any 127.0.0.0/8 addresses in the address message. One way to
> accomplish this is to never register 127.0.0.0/8 addresses with
> LDP by modifing ldp_interface_address_add() in ldp_zebra.c.
>
> On Mon, Mar 24, 2008 at 04:58:20PM -0400, Scott A. Yoder wrote:
>
>> Hi James. I've been able to get ldpd working quite well with 3 routers in my testbed. Even
>> the targeted ldp sessions now appear to be working. I have a left LSR, middle, LSR and right LSR. The
>> targeted session is between the left and right routers.
>>
>> I've found a few problems and want to get your take on how best to fix them.
>>
>> 1) The xconnect command needs to have the destination IP address stored in host byte order.
>>
>> --- ldp_vty.c Tue Mar 25 01:19:59 2008
>> +++ ldp_vty-new.c Wed Mar 19 01:55:44 2008
>> @@ -1618,6 +1618,7 @@
>> dest.port = 646;
>>
>> VTY_GET_UINT32_RANGE("VCID",vcid,argv[1],0,255);
>> + dest.addr.u.ipv4 = ntohl(dest.addr.u.ipv4);
>>
>> if (ldp_remote_peer_find(ldp, &dest)) {
>> return CMD_WARNING;
>>
>>
>> 2) I found a couple of memory leaks with valgrind:
>>
>> --- ldp_session.c Fri Jan 4 23:58:59 2008
>> +++ ldp_session-new.c Tue Mar 25 01:25:32 2008
>> @@ -252,6 +252,8 @@
>> {
>> LDP_PRINT(NULL, "session delete");
>> MPLS_REFCNT_ASSERT(s, 0);
>> + ldp_buf_delete(s->tx_buffer);
>> + ldp_mesg_delete(s->tx_message);
>> mpls_free(s);
>> }
>>
>> --- ldp_buf.c Tue Mar 25 01:29:01 2008
>> +++ ldp_buf-new.c Fri Mar 21 21:18:06 2008
>> @@ -49,6 +49,8 @@
>> void ldp_buf_delete(ldp_buf * b)
>> {
>> MPLS_ASSERT(b);
>> + if (b->buffer)
>> + mpls_free(b->buffer);
>> mpls_free(b);
>> }
>>
>>
>> These 2 leaks caused ldpd to grow several megabytes per hour on my system.
>>
>>
>> 3) ldpd cannot establish more than 1 session at a time.
>>
>> I don't know if I have a config error but I keep getting a "ldp_addr_process: session X already advertised this address"
>> error when the 2nd router attempts to start up a session. I think the address is 127.0.0.1. I tried changing the lsr-id and
>> transport address but that caused ldpd to crash. The neighbor's status is stuck in the discovery state.
>>
>> Just to get around this problem and keep going I stuck a return MPLS_SUCCESS in ldpd/ldp_addr.c line 315:
>>
>> /* the addr is in the tree */
>> if (addr->session) {
>> LDP_PRINT(g->user_data,
>> "ldp_addr_process: session (%d) already advertised this address\n",
>> addr->session->index);
>> return MPLS_SUCCESS;
>> return MPLS_FAILURE;
>> }
>>
>> Is there something I'm missing with the config to support multiple peers?
>>
>> Thanks,
>> Scott Yoder
>> Support Engineer
>> ImageStream Internet Solutions, Inc.
>> E-mail: sy...@im...
>>
>> -------------------------------------------------------------------------
>> This SF.net email is sponsored by: Microsoft
>> Defy all challenges. Microsoft(R) Visual Studio 2008.
>> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
>> _______________________________________________
>> mpls-linux-devel mailing list
>> mpl...@li...
>> https://lists.sourceforge.net/lists/listinfo/mpls-linux-devel
>>
>
>
> ------------------------------------------------------------------------
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2008.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> ------------------------------------------------------------------------
>
> _______________________________________________
> mpls-linux-devel mailing list
> mpl...@li...
> https://lists.sourceforge.net/lists/listinfo/mpls-linux-devel
>
--
Christopher Robson
Senior Computer Scientist, GS-15
Naval Research Laboratory
Center for Computational Science
Networking, Code 5591
4555 Overlook ave.
Washington, D.C. 20375-5320
(COM) 202-404-3138
(VoIP) 2024043138@ATDNet
(CHAT) Chris.Robson@ATDNet
|
|
From: Chris R. <Chr...@nr...> - 2008-04-14 10:30:30
|
James
The really great news is, the auto yum-update caught this mpls based
kernel updated notice this morning and the kernel update is in sync with
the latest released fedora 8 kernel cycle ( 2.6.24.4-64). Further, the
mpls code compiles and at least boots up with even the latest CVS pulls
(at least release 2.6.24.4-80). The even better news, for me at least,
is this new yum-update build has a compatible nvidia driver, a really
annoying problem with Lenovo T61 and new kernels.
The , still, bad news is sysctl is still crashing from, what I believe,
is with the mpls_procfs.c program at the code listed below. Following
the code is the crash at bootup time. Whats interesti is a home-grown
build of the mpls code just gets the message "Unknown sysctl binary path".
I had removed the sysctl code and was going to test the high speed
interface issue that was plaguing successful testing but will delay that
and just test with this yum distro of the kernel.
.....Chris
+int __init mpls_procfs_init(void)
+{
+ if (!proc_net_fops_create(&init_net, "mpls", S_IRUGO,
+ &mpls_seq_fops)) {
+ printk(MPLS_ERR "MPLS: failed to register with procfs\n");
+ return -ENOMEM;
+ }
+ return 0;
sysctl table check failed: /net/mpls .3.21 Unknown sysctl binary path
Pid: 1, comm: swapper Not tainted 2.6.24.4-64.fc8.mpls.1.959 #1
[<c0442bef>] set_fail+0x3b/0x43
[<c0443006>] sysctl_check_table+0x40f/0x460
[<c04352d5>] sysctl_head_finish+0x18/0x22
[<c044301a>] sysctl_check_table+0x423/0x460
[<c043429d>] sysctl_set_parent+0x19/0x2a
[<c076ff12>] sysctl_init+0x16/0x19
[<c075d536>] kernel_init+0x1ed/0x360
[<c0405096>] ret_from_fork+0x6/0x1c
[<c075d349>] kernel_init+0x0/0x360
[<c075d349>] kernel_init+0x0/0x360
[<c0405e0b>] kernel_thread_helper+0x7/0x10
=======================
sysctl table check failed: /net/mpls/debug .3.21.1 Unknown sysctl binary
path
Pid: 1, comm: swapper Not tainted 2.6.24.4-64.fc8.mpls.1.959 #1
[<c0442bef>] set_fail+0x3b/0x43
[<c0443006>] sysctl_check_table+0x40f/0x460
[<c044301a>] sysctl_check_table+0x423/0x460
[<c04352d5>] sysctl_head_finish+0x18/0x22
[<c044301a>] sysctl_check_table+0x423/0x460
[<c043429d>] sysctl_set_parent+0x19/0x2a
[<c076ff12>] sysctl_init+0x16/0x19
[<c075d536>] kernel_init+0x1ed/0x360
[<c0405096>] ret_from_fork+0x6/0x1c
[<c075d349>] kernel_init+0x0/0x360
[<c075d349>] kernel_init+0x0/0x360
[<c0405e0b>] kernel_thread_helper+0x7/0x10
=======================
sysctl table check failed: /net/mpls/default_ttl .3.21.2 Unknown sysctl
binary path
Pid: 1, comm: swapper Not tainted 2.6.24.4-64.fc8.mpls.1.959 #1
[<c0442bef>] set_fail+0x3b/0x43
[<c0443006>] sysctl_check_table+0x40f/0x460
[<c044301a>] sysctl_check_table+0x423/0x460
[<c04352d5>] sysctl_head_finish+0x18/0x22
[<c044301a>] sysctl_check_table+0x423/0x460
[<c043429d>] sysctl_set_parent+0x19/0x2a
[<c076ff12>] sysctl_init+0x16/0x19
[<c075d536>] kernel_init+0x1ed/0x360
[<c0405096>] ret_from_fork+0x6/0x1c
[<c075d349>] kernel_init+0x0/0x360
[<c075d349>] kernel_init+0x0/0x360
[<c0405e0b>] kernel_thread_helper+0x7/0x10
=======================
Time: 9:52:08 Date: 04/14/08
NET: Registered protocol family 16
--
Christopher Robson
Senior Computer Scientist, GS-15
Naval Research Laboratory
Center for Computational Science
Networking, Code 5591
4555 Overlook ave.
Washington, D.C. 20375-5320
(COM) 202-404-3138
(VoIP) 2024043138@ATDNet
(CHAT) Chris.Robson@ATDNet
|
|
From: James R. L. <jl...@mi...> - 2008-04-15 02:21:21
|
Thanks for the report. I'm able to duplicate the message and have found
the source. I had forgotten to add the MPLS values to sysctl_check().
I'll post new RPMs after I rebuild.
On Mon, Apr 14, 2008 at 06:29:55AM -0400, Chris Robson wrote:
>
> James
>
> The really great news is, the auto yum-update caught this mpls based kernel
> updated notice this morning and the kernel update is in sync with the
> latest released fedora 8 kernel cycle ( 2.6.24.4-64). Further, the mpls
> code compiles and at least boots up with even the latest CVS pulls (at
> least release 2.6.24.4-80). The even better news, for me at least, is this
> new yum-update build has a compatible nvidia driver, a really annoying
> problem with Lenovo T61 and new kernels.
> The , still, bad news is sysctl is still crashing from, what I believe, is
> with the mpls_procfs.c program at the code listed below. Following the
> code is the crash at bootup time. Whats interesti is a home-grown build of
> the mpls code just gets the message "Unknown sysctl binary path".
> I had removed the sysctl code and was going to test the high speed
> interface issue that was plaguing successful testing but will delay that
> and just test with this yum distro of the kernel.
>
> .....Chris
>
> +int __init mpls_procfs_init(void)
> +{
> + if (!proc_net_fops_create(&init_net, "mpls", S_IRUGO,
> + &mpls_seq_fops)) {
> + printk(MPLS_ERR "MPLS: failed to register with procfs\n");
> + return -ENOMEM;
> + }
> + return 0;
>
>
> sysctl table check failed: /net/mpls .3.21 Unknown sysctl binary path
> Pid: 1, comm: swapper Not tainted 2.6.24.4-64.fc8.mpls.1.959 #1
> [<c0442bef>] set_fail+0x3b/0x43
> [<c0443006>] sysctl_check_table+0x40f/0x460
> [<c04352d5>] sysctl_head_finish+0x18/0x22
> [<c044301a>] sysctl_check_table+0x423/0x460
> [<c043429d>] sysctl_set_parent+0x19/0x2a
> [<c076ff12>] sysctl_init+0x16/0x19
> [<c075d536>] kernel_init+0x1ed/0x360
> [<c0405096>] ret_from_fork+0x6/0x1c
> [<c075d349>] kernel_init+0x0/0x360
> [<c075d349>] kernel_init+0x0/0x360
> [<c0405e0b>] kernel_thread_helper+0x7/0x10
> =======================
> sysctl table check failed: /net/mpls/debug .3.21.1 Unknown sysctl binary
> path
> Pid: 1, comm: swapper Not tainted 2.6.24.4-64.fc8.mpls.1.959 #1
> [<c0442bef>] set_fail+0x3b/0x43
> [<c0443006>] sysctl_check_table+0x40f/0x460
> [<c044301a>] sysctl_check_table+0x423/0x460
> [<c04352d5>] sysctl_head_finish+0x18/0x22
> [<c044301a>] sysctl_check_table+0x423/0x460
> [<c043429d>] sysctl_set_parent+0x19/0x2a
> [<c076ff12>] sysctl_init+0x16/0x19
> [<c075d536>] kernel_init+0x1ed/0x360
> [<c0405096>] ret_from_fork+0x6/0x1c
> [<c075d349>] kernel_init+0x0/0x360
> [<c075d349>] kernel_init+0x0/0x360
> [<c0405e0b>] kernel_thread_helper+0x7/0x10
> =======================
> sysctl table check failed: /net/mpls/default_ttl .3.21.2 Unknown sysctl
> binary path
> Pid: 1, comm: swapper Not tainted 2.6.24.4-64.fc8.mpls.1.959 #1
> [<c0442bef>] set_fail+0x3b/0x43
> [<c0443006>] sysctl_check_table+0x40f/0x460
> [<c044301a>] sysctl_check_table+0x423/0x460
> [<c04352d5>] sysctl_head_finish+0x18/0x22
> [<c044301a>] sysctl_check_table+0x423/0x460
> [<c043429d>] sysctl_set_parent+0x19/0x2a
> [<c076ff12>] sysctl_init+0x16/0x19
> [<c075d536>] kernel_init+0x1ed/0x360
> [<c0405096>] ret_from_fork+0x6/0x1c
> [<c075d349>] kernel_init+0x0/0x360
> [<c075d349>] kernel_init+0x0/0x360
> [<c0405e0b>] kernel_thread_helper+0x7/0x10
> =======================
> Time: 9:52:08 Date: 04/14/08
> NET: Registered protocol family 16
>
> --
> Christopher Robson
> Senior Computer Scientist, GS-15
> Naval Research Laboratory
> Center for Computational Science
> Networking, Code 5591
> 4555 Overlook ave.
> Washington, D.C. 20375-5320
> (COM) 202-404-3138
> (VoIP) 2024043138@ATDNet
> (CHAT) Chris.Robson@ATDNet
>
--
James R. Leu
jl...@mi...
|
|
From: James R. L. <jl...@mi...> - 2008-05-12 03:31:44
|
I've submitted an alternate patch to solve this issue. I make
a call checking if_is_loopback() on the ifp and skip accordingly.
In addition the quagga-mpls tree in my development depot has been
update to solve a couple of nagging bugs.
Anyone working with quagga-mpls will want to pull the latest
updates.
On Tue, Mar 25, 2008 at 03:33:03PM -0400, Scott A. Yoder wrote:
> Yeah that did solve the problem but isn't there some way to control which addresses
> are announced to peers? It seems like the address-mode lsr-id doesn't cause ldpd to only announce
> the configured lsr-id.
>
> Here's a little patch to stop registering loopback addresses. Does Quagga have a LOOPBACK() macro
> like the kernel? I could only find an INADDR_LOOPBACK define.
>
> --- ldp_zebra.c Wed Mar 26 00:05:22 2008
> +++ ldp_zebra-new.c Tue Mar 25 23:44:43 2008
> @@ -201,16 +201,20 @@
> c = zebra_interface_address_read(command, zclient->ibuf);
> if (c == NULL || c->address->family != AF_INET) {
> return 0;
> }
>
> ifp = c->ifp;
> p = c->address;
>
> + /* Don't register loopback addresses */
> + if (((p->u.prefix4.s_addr) & htonl(0xff000000)) == htonl(0x7f000000))
> + return 0;
> +
> zlog_info("address add %s to interface %s",inet_ntoa(p->u.prefix4),
> ifp->name);
>
> if (ldp) {
> prefix2mpls_inet_addr(p, &addr.address);
> iff.handle = ifp;
> ldp_cfg_if_addr_set(ldp->h, &iff, &addr, LDP_CFG_ADD);
>
>
> Scott Yoder
> Support Engineer
> ImageStream Internet Solutions, Inc.
> E-mail: sy...@im...
>
> James R. Leu wrote:
> > Good stuff. Thank you for working with ldp-portable and taking the
> > time to dig into the code. I've incorporated your fixes for the memory
> > leaks and I'm double checking the byte order fix you suggest.
> >
> > As far as the multiple session issue, I think the fix is to never
> > send any 127.0.0.0/8 addresses in the address message. One way to
> > accomplish this is to never register 127.0.0.0/8 addresses with
> > LDP by modifing ldp_interface_address_add() in ldp_zebra.c.
> >
> > On Mon, Mar 24, 2008 at 04:58:20PM -0400, Scott A. Yoder wrote:
> >> Hi James. I've been able to get ldpd working quite well with 3 routers in my testbed. Even
> >> the targeted ldp sessions now appear to be working. I have a left LSR, middle, LSR and right LSR. The
> >> targeted session is between the left and right routers.
> >>
> >> I've found a few problems and want to get your take on how best to fix them.
> >>
> >> 1) The xconnect command needs to have the destination IP address stored in host byte order.
> >>
> >> --- ldp_vty.c Tue Mar 25 01:19:59 2008
> >> +++ ldp_vty-new.c Wed Mar 19 01:55:44 2008
> >> @@ -1618,6 +1618,7 @@
> >> dest.port = 646;
> >>
> >> VTY_GET_UINT32_RANGE("VCID",vcid,argv[1],0,255);
> >> + dest.addr.u.ipv4 = ntohl(dest.addr.u.ipv4);
> >>
> >> if (ldp_remote_peer_find(ldp, &dest)) {
> >> return CMD_WARNING;
> >>
> >>
> >> 2) I found a couple of memory leaks with valgrind:
> >>
> >> --- ldp_session.c Fri Jan 4 23:58:59 2008
> >> +++ ldp_session-new.c Tue Mar 25 01:25:32 2008
> >> @@ -252,6 +252,8 @@
> >> {
> >> LDP_PRINT(NULL, "session delete");
> >> MPLS_REFCNT_ASSERT(s, 0);
> >> + ldp_buf_delete(s->tx_buffer);
> >> + ldp_mesg_delete(s->tx_message);
> >> mpls_free(s);
> >> }
> >>
> >> --- ldp_buf.c Tue Mar 25 01:29:01 2008
> >> +++ ldp_buf-new.c Fri Mar 21 21:18:06 2008
> >> @@ -49,6 +49,8 @@
> >> void ldp_buf_delete(ldp_buf * b)
> >> {
> >> MPLS_ASSERT(b);
> >> + if (b->buffer)
> >> + mpls_free(b->buffer);
> >> mpls_free(b);
> >> }
> >>
> >>
> >> These 2 leaks caused ldpd to grow several megabytes per hour on my system.
> >>
> >>
> >> 3) ldpd cannot establish more than 1 session at a time.
> >>
> >> I don't know if I have a config error but I keep getting a "ldp_addr_process: session X already advertised this address"
> >> error when the 2nd router attempts to start up a session. I think the address is 127.0.0.1. I tried changing the lsr-id and
> >> transport address but that caused ldpd to crash. The neighbor's status is stuck in the discovery state.
> >>
> >> Just to get around this problem and keep going I stuck a return MPLS_SUCCESS in ldpd/ldp_addr.c line 315:
> >>
> >> /* the addr is in the tree */
> >> if (addr->session) {
> >> LDP_PRINT(g->user_data,
> >> "ldp_addr_process: session (%d) already advertised this address\n",
> >> addr->session->index);
> >> return MPLS_SUCCESS;
> >> return MPLS_FAILURE;
> >> }
> >>
> >> Is there something I'm missing with the config to support multiple peers?
> >>
> >> Thanks,
> >> Scott Yoder
> >> Support Engineer
> >> ImageStream Internet Solutions, Inc.
> >> E-mail: sy...@im...
> >>
> >> -------------------------------------------------------------------------
> >> This SF.net email is sponsored by: Microsoft
> >> Defy all challenges. Microsoft(R) Visual Studio 2008.
> >> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> >> _______________________________________________
> >> mpls-linux-devel mailing list
> >> mpl...@li...
> >> https://lists.sourceforge.net/lists/listinfo/mpls-linux-devel
> >
--
James R. Leu
jl...@mi...
|
|
From: 刘磊 <orp...@ms...> - 2008-05-12 04:10:51
|
How to get the latest updates? Only by p4? I have tried many dns-server to resolve p4.dangermen.com, but none success. Can you give me another way? Thank you much. ---------------------------------------- > Date: Sun, 11 May 2008 22:31:35 -0500 > From: jl...@mi... > To: mpl...@li... > Subject: Re: [mpls-linux-devel] A few problems with ldpd > > I've submitted an alternate patch to solve this issue. I make > a call checking if_is_loopback() on the ifp and skip accordingly. > > In addition the quagga-mpls tree in my development depot has been > update to solve a couple of nagging bugs. > > Anyone working with quagga-mpls will want to pull the latest > updates. > > On Tue, Mar 25, 2008 at 03:33:03PM -0400, Scott A. Yoder wrote: >> Yeah that did solve the problem but isn't there some way to control which addresses >> are announced to peers? It seems like the address-mode lsr-id doesn't cause ldpd to only announce >> the configured lsr-id. >> >> Here's a little patch to stop registering loopback addresses. Does Quagga have a LOOPBACK() macro >> like the kernel? I could only find an INADDR_LOOPBACK define. >> >> --- ldp_zebra.c Wed Mar 26 00:05:22 2008 >> +++ ldp_zebra-new.c Tue Mar 25 23:44:43 2008 >> @@ -201,16 +201,20 @@ >> c = zebra_interface_address_read(command, zclient->ibuf); >> if (c == NULL || c->address->family != AF_INET) { >> return 0; >> } >> >> ifp = c->ifp; >> p = c->address; >> >> + /* Don't register loopback addresses */ >> + if (((p->u.prefix4.s_addr) & htonl(0xff000000)) == htonl(0x7f000000)) >> + return 0; >> + >> zlog_info("address add %s to interface %s",inet_ntoa(p->u.prefix4), >> ifp->name); >> >> if (ldp) { >> prefix2mpls_inet_addr(p, &addr.address); >> iff.handle = ifp; >> ldp_cfg_if_addr_set(ldp->h, &iff, &addr, LDP_CFG_ADD); >> >> >> Scott Yoder >> Support Engineer >> ImageStream Internet Solutions, Inc. >> E-mail: sy...@im... >> >> James R. Leu wrote: >>> Good stuff. Thank you for working with ldp-portable and taking the >>> time to dig into the code. I've incorporated your fixes for the memory >>> leaks and I'm double checking the byte order fix you suggest. >>> >>> As far as the multiple session issue, I think the fix is to never >>> send any 127.0.0.0/8 addresses in the address message. One way to >>> accomplish this is to never register 127.0.0.0/8 addresses with >>> LDP by modifing ldp_interface_address_add() in ldp_zebra.c. >>> >>> On Mon, Mar 24, 2008 at 04:58:20PM -0400, Scott A. Yoder wrote: >>>> Hi James. I've been able to get ldpd working quite well with 3 routers in my testbed. Even >>>> the targeted ldp sessions now appear to be working. I have a left LSR, middle, LSR and right LSR. The >>>> targeted session is between the left and right routers. >>>> >>>> I've found a few problems and want to get your take on how best to fix them. >>>> >>>> 1) The xconnect command needs to have the destination IP address stored in host byte order. >>>> >>>> --- ldp_vty.c Tue Mar 25 01:19:59 2008 >>>> +++ ldp_vty-new.c Wed Mar 19 01:55:44 2008 >>>> @@ -1618,6 +1618,7 @@ >>>> dest.port = 646; >>>> >>>> VTY_GET_UINT32_RANGE("VCID",vcid,argv[1],0,255); >>>> + dest.addr.u.ipv4 = ntohl(dest.addr.u.ipv4); >>>> >>>> if (ldp_remote_peer_find(ldp, &dest)) { >>>> return CMD_WARNING; >>>> >>>> >>>> 2) I found a couple of memory leaks with valgrind: >>>> >>>> --- ldp_session.c Fri Jan 4 23:58:59 2008 >>>> +++ ldp_session-new.c Tue Mar 25 01:25:32 2008 >>>> @@ -252,6 +252,8 @@ >>>> { >>>> LDP_PRINT(NULL, "session delete"); >>>> MPLS_REFCNT_ASSERT(s, 0); >>>> + ldp_buf_delete(s->tx_buffer); >>>> + ldp_mesg_delete(s->tx_message); >>>> mpls_free(s); >>>> } >>>> >>>> --- ldp_buf.c Tue Mar 25 01:29:01 2008 >>>> +++ ldp_buf-new.c Fri Mar 21 21:18:06 2008 >>>> @@ -49,6 +49,8 @@ >>>> void ldp_buf_delete(ldp_buf * b) >>>> { >>>> MPLS_ASSERT(b); >>>> + if (b->buffer) >>>> + mpls_free(b->buffer); >>>> mpls_free(b); >>>> } >>>> >>>> >>>> These 2 leaks caused ldpd to grow several megabytes per hour on my system. >>>> >>>> >>>> 3) ldpd cannot establish more than 1 session at a time. >>>> >>>> I don't know if I have a config error but I keep getting a "ldp_addr_process: session X already advertised this address" >>>> error when the 2nd router attempts to start up a session. I think the address is 127.0.0.1. I tried changing the lsr-id and >>>> transport address but that caused ldpd to crash. The neighbor's status is stuck in the discovery state. >>>> >>>> Just to get around this problem and keep going I stuck a return MPLS_SUCCESS in ldpd/ldp_addr.c line 315: >>>> >>>> /* the addr is in the tree */ >>>> if (addr->session) { >>>> LDP_PRINT(g->user_data, >>>> "ldp_addr_process: session (%d) already advertised this address\n", >>>> addr->session->index); >>>> return MPLS_SUCCESS; >>>> return MPLS_FAILURE; >>>> } >>>> >>>> Is there something I'm missing with the config to support multiple peers? >>>> >>>> Thanks, >>>> Scott Yoder >>>> Support Engineer >>>> ImageStream Internet Solutions, Inc. >>>> E-mail: sy...@im... >>>> >>>> ------------------------------------------------------------------------- >>>> This SF.net email is sponsored by: Microsoft >>>> Defy all challenges. Microsoft(R) Visual Studio 2008. >>>> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ >>>> _______________________________________________ >>>> mpls-linux-devel mailing list >>>> mpl...@li... >>>> https://lists.sourceforge.net/lists/listinfo/mpls-linux-devel >>> > > -- > James R. Leu > jl...@mi... _________________________________________________________________ 新年换新颜，快来妆扮自己的MSN给心仪的TA一个惊喜！ http://im.live.cn/emoticons/?ID=18 |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X