| Age | Commit message (Collapse) | Author |
|---|
|
ok claudio@
|
|
ok claudio@
|
|
ok claudio@
|
|
ok claudio@
|
|
|
|
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@
|
|
copyright and use $Mdocdate$.
|
|
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@
|
|
server and radiusctl(8) is to control the server. radiusd(8) currently
supports bsdauth and radius (upstream radius servers) as authentication
backends.
fixes from jsg blambert
ok deraadt
|
|
imsg_init() exposed by the second part of this diff which makes
carp(4) interfaces be recognized to be in "backup" mode on start-up.
Problem analyzed and fix provided by Johan Ymerson, thanks!
ok claudio@, mpi@
|
|
varbinds received from subagents
ok reyk@
|
|
case the receiver closes the connection, wait for a second to give
him a chance to recover.
OK benno@
|
|
Poined out by Yuuichi Someya at IIJ.
|
|
From Yuuichi Someya at IIJ.
|
|
changed.
From Yuuichi Someya at IIJ.
|
|
From Yuuichi Someya at IIJ.
|
|
limit. Instead disable the listen event and wait for a second.
Keep a reserve of 5 file descriptors.
OK benno@
|
|
This way ASLR and stack cookies are per process.
With input from benno@ and deraadt@
OK benno@
|
|
OK reyk@
|
|
fmemopen for the rest of the code to chew on, rather than having
special casing for seed generation in the sending code.
this also means our fake random.seed files will get proper netascii
encoding by being read via the fgetc api instead of directly from
a buffer.
ok deraadt@ mcbride@
|
|
|
|
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@
|
|
octet counting or non transparent framing.
OK benno@
|
|
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;
|
|
b64_{ntop,pton} remain for now, they are in libc as __b64_{ntop,pton}
but to use this we either need to pull in resolv.h (which does "#define
b64_ntop __b64_ntop") or access the __ versions directly (as done in ssh).
|
|
|
|
|
|
ok florian@
|
|
don;t think the colon needs marked up.
|
|
ok benno@
|
|
OK florian@
|
|
mofified version by jmc@, ok phessler@ and claudio@ is fine with it
(but notes that the details are more complicated)
|
|
instead of showing just the primary one and "above" or "below" for secondary.
ok sthen
|
|
Properly handle carp(4) interfaces in "backup" mode on start-up.
Problem analyzed and fix provided by Johan Ymerson, thanks!
ok claudio@, benno@
it breaks on systems without carp because iev_ospfe is not initiallized
at the time kif_init() is called in main.
|
