| Age | Commit message (Collapse) | Author |
|---|
|
titles (including flags) to distinguish between daemons, this makes it
possible to manage multiple copies of a daemon using the normal infrastructure
by symlinking rc.d scripts to a new name. ok jung@ ajacoutot@, smtpd ok gilles@
|
|
|
|
This is almost identical to the eigrpd(8) pledge diff, with the exception
that the parent process can not be pledged bacause of a SIOCSETMPWCFG
ioctl used to configure pseudowires.
Looks good to deraadt@.
|
|
And some ifmedia64 fixes.
"move forward" deraadt@
|
|
ok jmc@
|
|
ok claudio@
|
|
ok claudio@
|
|
ok claudio@
|
|
Under some rare circumstances the following can happen:
1 - one neighbor sends a label withdraw followed by a fatal notification
message;
2 - ldpe parses the label withdraw and sends it to lde;
3 - ldpe parses the fatal notification message and closes the session;
4 - lde processes the label withdraw and asks ldpe to send a label release;
5 - at around the same time, ldpe restarts the session with the neighbor;
6 - ldpe processes the lde message and then sends a label release to the new
neighbor.
The problem is that we don't want a message enqueue to a neighbor to be sent
after the session is restarted. If a session is closed, all the enqueued
messages should be discarded.
To acomplish this, we update the peerid of the nbr structure everytime the
session is established.
ok claudio@
|
|
ok claudio@
|
|
This patch introduces full support for pseudowire signaling in ldpd(8),
including Control Word and Status TLV negotiation.
As of now it's not possible to configure a VPWS, but the signaling is
the same. In the future, when VPWS support is available in the kernel,
ldpd(8) can be extended to support VPWS with only a few modifications.
Limitations:
* No support for FEC 129, only FEC 128 (more widely deployed);
* No support for group withdraws (not widely deployed);
* No support for MAC withdraws (not widely deployed).
Related RFCs:
* RFC 3916: Requirements for Pseudo-Wire Emulation Edge-to-Edge (PWE3)
* RFC 3985: Pseudo Wire Emulation Edge-to-Edge (PWE3) Architecture
* RFC 4385: Pseudowire Emulation Edge-to-Edge (PWE3) Control Word for
Use over an MPLS PSN
* RFC 4446: IANA Allocations for Pseudowire Edge to Edge Emulation (PWE3)
* RFC 4447: Pseudowire Setup and Maintenance Using the Label Distribution
Protocol (LDP)
* RFC 4448: Encapsulation Methods for Transport of Ethernet over MPLS
Networks
* RFC 4905: Encapsulation Methods for Transport of Layer 2 Frames over
MPLS Networks
* RFC 4906: Transport of Layer 2 Frames Over MPLS
ok claudio@
|
|
Since we implement the Liberal Label Retention mode, we need to record
all fields of the received label mappings so the messages can be processed
later when there is a matching nexthop for the advertised FECs.
This will be important when we implement VPLS because we need to retain
information like the pseudowire's interface MTU and Group ID.
ok claudio@
|
|
ok claudio@
|
|
This patch introduces full support for pseudowire signaling in ldpd(8),
including Control Word and Status TLV negotiation.
As of now it's not possible to configure a VPWS, but the signaling is
the same. In the future, when VPWS support is available in the kernel,
ldpd(8) can be extended to support VPWS with only a few modifications.
Limitations:
* No support for FEC 129, only FEC 128 (more widely deployed);
* No support for group withdraws (not widely deployed);
* No support for MAC withdraws (not widely deployed).
Related RFCs:
* RFC 3916: Requirements for Pseudo-Wire Emulation Edge-to-Edge (PWE3)
* RFC 3985: Pseudo Wire Emulation Edge-to-Edge (PWE3) Architecture
* RFC 4385: Pseudowire Emulation Edge-to-Edge (PWE3) Control Word for
Use over an MPLS PSN
* RFC 4446: IANA Allocations for Pseudowire Edge to Edge Emulation (PWE3)
* RFC 4447: Pseudowire Setup and Maintenance Using the Label Distribution
Protocol (LDP)
* RFC 4448: Encapsulation Methods for Transport of Ethernet over MPLS
Networks
* RFC 4905: Encapsulation Methods for Transport of Layer 2 Frames over
MPLS Networks
* RFC 4906: Transport of Layer 2 Frames Over MPLS
ok claudio@
|
|
LDP work with FECs, where a FEC can be a prefix, a pseudowire and so on.
ok claudio@
|
|
ok claudio@
|
|
ok claudio@
|
|
ok claudio@
|
|
This is a preliminary work for the the next patch (sigup config
reload). We want to make sure that the ldpe process can handle duplicated
addresses.
The idea is to alloc two different if_addr structures for each address,
and link one in the global list of addresses (used to send address
messages) and link the other to the associated interface list of
addresses.
Doing that we will be able to call kif_redistribute() after reloading
the config file and activate the new LDP enabled interfaces.
NOTE: Interfaces are created at config parse time and the child
processes inherit them on fork() so there's no need to send a status
update at startup.
ok claudio@
|
|
|
|
ok claudio@
|
|
ok claudio@
|
|
This patch presents a thoroughly review of the label mapping
algorithms. Most of the changes are minor bug fixes in the handling of
received label messages.
Additional improvements:
* Add a few more references to the Appendix A of the RFC5036 ("LDP
Label Distribution Procedures") into the code;
* Add full multipath support;
* Send label withdraws when appropriate;
* Add label withdraw/release wildcard support.
NOTE: As a result of implementing only the "Liberal Label Retention" and
"Downstream Unsolicited" modes, we will never send a label request
("Request Never"). And that means that we can ignore the following
notification messages: "Label Request Aborted", "No Label Resources",
"No Route" and "Label Resources Available". The following algorithms
mentioned in the RFC can also be ignored: "Timeout of Deferred Label
Request", "Detect Local Label Resources Have Become Available" and
"Receive Label Abort Request".
Now, considering that we only support one combination of all modes of
operation, we can say that we have an almost complete implementation of
the protocol.
ok claudio@
|
|
LDP has several modes of operation, it was designed in that way so it
could run on legacy equipment like ATM/FR switches with very strict
memory limitations.
For modern hardware there's no point on using either the "Conservative
Label Retention" or "Downstream On Demand" modes of operation since they
save memory at cost of blackholing traffic when routing changes. Major
vendors implement only the "Liberal Label Retention" and "Downstream
Unsolicited" modes for non ATM/FR hardware. Let's do that too.
As for using either "Independent Control" or "Ordered Control", let's
stick with the first option mainly because it's easier to implement
and because it doesn't really matter which control mode is used. For
reference, Cisco implements only "Independent Control" and Juniper only
"Ordered Control". Both modes are interoperable.
The point of supporting only one combination of all modes of operation
is that it will allow for the writing of a simpler code without removing
useful functionality.
ok claudio@
|
|
ok claudio@
|
|
This is major rework of the kroute.c code. The idea is remove complexity
from the lde process by making kroute.c advertise only the lowest priority
routes of each prefix.
kroute.c now keeps track of all routes using three different structures:
kroute_prefix, kroute_priority and kroute_node.
kroute_prefix represents a prefix and contains an ordered list of
priorities (kroute_priority) and for each priority there is a list of
nexthops (kroute_node). Arranging the routes using these three structures
allows for the writing of a simpler code, easier to understand.
Whenever a route is removed, if there's another route for the same prefix,
but with a lower priority, this route is immediately sent to lde.
Additional fixes:
* On RTM_CHANGE, remove the old route before installing the new one;
* On IMSG_CTL_KROUTE_ADDR, show all nexthops for multpath routes;
|
|
to properly track connected routes on -current.
|
|
|
|
There's no need to protect the 127/8 network on ldpd since this network
is filtered before being sent to lde.
If we receive a label mapping for this network, it won't be installed
because lde has no nexthop for it, and thus the code will always fall
into the LMp.13 case of the RFC "Receive Label Mapping" algorithm:
the mapping will be recorded but not used.
ok claudio@
|
|
The LIB is a table where the router keeps all known MPLS labels. So,
we should loop over all the received label mappings from all neighbors
to show the full LIB.
The lde_nbr_is_nexthop() function was introduced to verify if a lib
entry is supposed to be installed in the fib (according to the fib entry's
nexthop and the addresses advertised by the lib entry's nexthop). This is
better than keeping track of lib<->fib entries with pointers and back
pointers because it keeps the lib/fib structures independent of each
other, which in turn makes the code less prone to bugs.
OK claudio@
|
|
The adjacency holdtime is set in recv_hello().
OK claudio@
|
|
|
|
|
|
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).
Additional notes:
1 - s/if_act_/if_/
2 - Remove the IMSG_IFUP and IMSG_IFDOWN events. Now whenever an
interface changes its state a IMSG_IFSTATUS event will be generated
with the new status.
kroute.c ldpd.h ldpe.c ldpe.h CVS:
----------------------------------------------------------------------
|
|
after an address removal in the system.
|
|
for whatever reason.
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.
|
|
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 implement advanced solutions like
MPLS L2/L3 VPNs. Some implementations (e.g. JunOS) go further and
only assign labels for /32 loopback routes advertised in the IGP.
If Inter-AS LSPs are necessary, BGP itself should be used for
distributing IPv4 labeled routes (e.g. option C. of section 10 in
RFC 4364).
|
|
|
|
are less then sizeof(*rtm) bytes long (e.g. interface announcements).
Found the hard way by phessler@
|
|
|
|
sleep on a socket.
|
|
|
|
|
|
int to an aligned variable before operating on it.
ok claudio
|
|
possible. Annotate <sys/param.h> lines with their current reasons. Switch
to PATH_MAX, NGROUPS_MAX, HOST_NAME_MAX+1, LOGIN_NAME_MAX, etc. Change
MIN() and MAX() to local definitions of MINIMUM() and MAXIMUM() where
sensible to avoid pulling in the pollution. These are the files confirmed
through binary verification.
ok guenther, millert, doug (helped with the verification protocol)
|
|
Fixes a pfctl crash with an anchor name containing
an embedded nul found with the afl fuzzer.
pfctl parse.y patch from and ok deraadt@
|
|
ok deraadt@ millert@ tedu@
|
|
No yyerror() calls needed to be changed.
ok bluhm@
|
|
format string, create a temporary message.
OK claudio@
|
|
ok millert@
|
