nd the connection attempt has not yet
> been completed.
> +.It Bq Er EPERM
> +A TCP connection on a socket with socket option TCP_MD5SIG was
> +attempted without configuring the security parameters correctly.
> .El
> .Pp
> The following errors are specific to connecting names in the
OK renato@
--
Renato Westphal
---
init.c | 67 +-
labelmapping.c | 72 ++
lde.c | 40
lde.h | 3 +++
lde_lib.c | 43 +++
ld
RFC 4762 says that MAC address withdrawal messages can be used to
improve convergence time in VPLS networks. This patch makes ldpd send
MAC withdrawals whenever a non-pseudowire interface pertaining to a VPLS
goes down.
The processing of received MAC withdrawals will be implemented later (need
to
We were aborting the session upon receipt of MAC Address Withdrawal
messages. Now make the parser aware that optional TLVs are possible in
address messages.
---
address.c | 73 +++
1 file changed, 59 insertions(+), 14 deletions(-)
diff -
---
init.c | 68 +++-
labelmapping.c | 120 -
lde.c | 14 +++
lde.h | 3 ++
lde_lib.c | 56 +++
ldp.h | 8
ldpd.8 | 9 +
---
l2vpn.c| 22 +-
labelmapping.c | 23 +++
lde.c | 14 ++
lde.h | 2 ++
lde_lib.c | 7 +++
ldp.h | 3 +++
ldpd.8 | 9 +
ldpd.h | 1 +
logmsg.c | 8
9 files
This patch per-se doesn't introduce any useful functionality, but prepares
the ground for new enhancements to ldpd (i.e. implementation of new RFCs
that make use of LDP capabilities).
---
init.c | 152 +++--
labelmapping.c | 8 +--
ldp.
This was missing from our original RFC 4447 VPLS implementation. Now
ldpd understands group wildcards as mandated by the RFC, but we still
don't send them ourselves. I can't see any case in which sending a group
wildcard would be useful, but nonetheless this patch provides a function
called lde_sen
T;
> rtm->rtm_msglen = len;
> sin6 = (struct sockaddr_in6 *)&buf[sizeof(struct rt_msghdr)];
> @@ -2772,7 +2756,7 @@ getroute(struct netinfo6 *np, struct in6
> }
> rtm = (struct rt_msghdr *)buf;
> } while (rtm->rtm_version != RTM_VERSION ||
> - rtm->rtm_seq != myseq || rtm->rtm_pid != pid);
> + rtm->rtm_seq != seq || rtm->rtm_pid != pid);
> sin6 = (struct sockaddr_in6 *)&buf[sizeof(struct rt_msghdr)];
> if (rtm->rtm_addrs & RTA_DST) {
> sin6 = (struct sockaddr_in6 *)
>
>
> --
ok renato@
I just think it would make more sense to add v6 capabilities to ripd
and remove route6d from base. But yes, nobody cares about RIP anymore,
motivation would be a problem.
--
Renato Westphal
This also finishes the missing bits from our RFC 7552 implementation
because GTSM is mandatory for LDPv6.
To avoid any kind of interoperability problems, I included a few
knobs to enable/disable GTSM on a per-address-family and per-neighbor
basis. Cisco's LDPv6 implementation, for instance, doesn'
2016-06-27 20:30 GMT-03:00 Jeremie Courreges-Anglas :
> Renato Westphal writes:
>
>> 2016-06-27 19:01 GMT-03:00 Alexander Bluhm :
>>> On Mon, Jun 27, 2016 at 11:57:08PM +0200, J??r??mie Courr??ges-Anglas wrote:
>>>> Alexander Bluhm writes:
>>>> >
nicast" from the man page, I'd go
further and rename "datagrams" to "packets", which is a more generic
term.
--
Renato Westphal
> 2.3.3
Hi,
I don't think that this is necessary. Yacc includes a skeleton C code
when generating a parser from a grammar specification file (.y) and
the stdlib header is in there:
char *banner[] =
{
"#include ",
"#include ",
"#define YYBYACC 1",
"#define YYMAJOR 1",
"#define YYMINOR 9",
"#define YYLEX yylex()",
"#define YYEMPTY -1",
"#define yyclearin (yychar=(YYEMPTY))",
"#define yyerrok (yyerrflag=0)",
"#define YYRECOVERING() (yyerrflag!=0)",
NULL
};
If you include the stdlib header in the .y file you will end up with
two includes for the same header in the .c file.
--
Renato Westphal
2015-03-11 22:30 GMT-03:00 Claudio Jeker :
> On Wed, Mar 11, 2015 at 04:41:08PM -0300, Renato Westphal wrote:
>> In the name of simplicity, remove the interface FSM that was inherited
>> from ospfd. In ldpd interfaces are just up or down, so keeping a FSM
>> for that is an ove
2015-03-11 22:18 GMT-03:00 Claudio Jeker :
> On Wed, Mar 11, 2015 at 04:41:05PM -0300, Renato Westphal wrote:
>> Although RFC 5036 is not explicit about this, LDP should not assign
>> labels for BGP routes. Doing that would be very resource consuming in
>> some scenarios and
Although RFC 5036 is not explicit about this, LDP should not assign
labels for BGP routes. Doing that would be very resource consuming in
some scenarios and unnecessary. The goal is generally only to establish
LSPs among all PEs in the AS since LDP is not used as an end in itself
but as a means to
---
ldpe.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/ldpe.c b/ldpe.c
index afba919..f643272 100644
--- a/ldpe.c
+++ b/ldpe.c
@@ -279,6 +279,7 @@ ldpe_shutdown(void)
}
close(leconf->ldp_discovery_socket);
+ close(leconf->ldp_ediscovery_socket);
close(leconf
2015-03-09 12:45 GMT-03:00 Martin Pieuchot :
> Hi Renato,
>
> On 06/03/15(Fri) 15:03, Renato Westphal wrote:
>> Hi all,
>>
>> I've done a lot of work on ldpd(8) a long time ago but only now I
>> found time to organize my patches and send them to review. The
---
kroute.c | 2 --
lde.c | 5 -
ldp.h | 6 --
ldpe.h | 4
neighbor.c | 27 ---
5 files changed, 44 deletions(-)
diff --git a/kroute.c b/kroute.c
index a962ea1..033 100644
--- a/kroute.c
+++ b/kroute.c
@@ -113,8 +113,6 @@ RB_HEAD(kif_t
In the name of simplicity, remove the interface FSM that was inherited
from ospfd. In ldpd interfaces are just up or down, so keeping a FSM
for that is an overkill. Now instead of calling if_fsm(), just call
if_update() whenever a relevant event occurs (status change, address
addition/removal).
Ad
If one interface is disabled, the holdtimer of the attached adjacencies
will eventually timeout after a few seconds. But there's no need to wait
when we know that the interface is disabled. In these cases, remove the
attached adjacencies to speedup the convergence process.
---
interface.c | 14 +++
---
ldpe.c | 11 ++-
1 file changed, 6 insertions(+), 5 deletions(-)
diff --git a/ldpe.c b/ldpe.c
index f643272..d422603 100644
--- a/ldpe.c
+++ b/ldpe.c
@@ -414,17 +414,18 @@ ldpe_dispatch_main(int fd, short event, void *bula)
break;
lease his patches anytime soon.
Suggestions, comments and feedback are welcome.
Regards,
--
Renato Westphal
Hello everybody,
First of all, let me introduce myself. I am Renato Westphal, I work as a
computer engineer in Brazil and I'm a maintainer of the MPLS-Linux project.
A couple of years ago I accidentally found that OpenBSD already had
built-in support for MPLS and, surprisingly, a fully wo
24 matches
Mail list logo