When the transport address is changed, all interfaces and targeted
neighbors are temporary disabled in the ldpe process until new sockets
bound to the new transport address are received from the parent.
This patch fixes a problem in which adjacencies weren't being removed
after the associated targeted neighbors were disabled. This was causing
ldpd not to set some MD5 sockoptions for new neighbors are thus preventing
MD5-protected sessions to come up after a change in the transport-address.
It's doesn't make sense to enforce that a targeted-hello is received
on an LDP-enabled interface. It should be possible, for example, to use
LDP only to signal pseudowires and other another protocol (e.g. RSVP-TE)
to create end-to-end LSPs.
ldpd: schedule the sending of label messages when necessary
Once we send a Label Withdraw, we can't send a Label Mapping for the
same FEC until we receive a Label Release from the peer. This is due to
some limitations in the LDP algorithms described in Appendix A. ("LDP
Label Distribution Procedures") of RFC 5036.
To workaround this issue, make it possible to schedule the sending of
a Label Mapping as soon as a Label Release is received for the same FEC.
The easiest way to test this patch is by typing the "label local advertise
explicit-null" command. ldpd will withdraw all null labels using a
Wildcard FEC and then send new Label Mappings as soon the corresponding
Label Releases are received.
On unstable networks, routes can be lost and relearned very often. If
we deallocate the input label every time a route is lost and allocate
a new one when the route is relearned, a lot of changes are made in vain.
This patch introduces a logic in which labels are preserved for at least
five minutes before being deallocated by the LIB garbage collector. This
is consistent with what other implementations do.
ldpd: accept notifications during the session establishment process
If we don't do this, we'll never trigger the backoff exponential timer
since it's impossible to distinguish between Initialization NAK's and
general errors.
Also:
* Implement some missing bits from RFC 5036;
* remove superfluous log message in session_shutdown()
(send_notification() logs that we're sending a fatal notification).
ldpd: use synchronous channels for sending log messages
This is necessary to guarantee that all log messages sent from the child
processes are received in the parent process right away.
Without this patch, when a child process calls fatal() or fatalx(),
the log messages don't make it to the parent because the child doesn't
have a chance to flush its buffers before exiting.
When ldpd fails to start for some reason, like failing to create a pid
file, the child processes call their shutdown functions without being
completely initialized. This patch adds some protections to prevent a
segmentation fault on such circumstances.
ldpd: simplify initialization of the child processes
In order to have separate ASLR/cookies per process, ldpd calls exec()
in the child processes after fork() (this is also known as the fork+exec
model).
This is an important security feature but it makes the initialization
of the child processes a bit more complicated as they're not a copy of
the parent anymore, so all parameters given via command line are lost.
To solve this problem, we were creating an argv array by hand with all
necessary parameters and providing it to the exec() syscall. This works
but it's a very ugly solution. This patch introduces a different approach
to solve the problem: send an IMSG_INIT message to the child processes
with all parameters they need in order to initialize properly. This
makes adding additional initialization parameters much more convenient
and less error prone.
Martin Winter [Wed, 12 Apr 2017 23:00:43 +0000 (16:00 -0700)]
snapcraft: Improve README.usage.md based on feedback received
- Fix snap connect (it's now called core, not ubuntu-core)
- Add section on MPLS configuration
- Add FAQ topic on ospfd/ospf6d crashing before privs are assigned to snap
- Add pointer to official webpage
Signed-off-by: Martin Winter <mwinter@opensourcerouting.org>
bgpd: fixes for the "show bgp large-community" command
* Fix a segfault when the "show bgp large-community" command is given
without any optional large communities;
* Fix parsing of optional large communities. Without this fix a
"Large-community malformed" error is shown even for valid large
communities.
Donald Sharp [Sat, 8 Apr 2017 12:47:59 +0000 (08:47 -0400)]
ospfd: Fix the 'show ip ospf int ...' command
Fixed output:
robot.cumulusnetworks.com# show ip ospf int
enp0s3 is up
ifindex 2, MTU 1500 bytes, BW 0 Mbit <UP,BROADCAST,RUNNING,MULTICAST>
Internet Address 10.0.2.15/24, Broadcast 10.0.2.255, Area 0.0.0.0
MTU mismatch detection:enabled
Router ID 192.168.0.1, Network Type BROADCAST, Cost: 10
Transmit Delay is 1 sec, State Waiting, Priority 1
No backup designated router on this network
Multicast group memberships: OSPFAllRouters
Timer intervals configured, Hello 10s, Dead 40s, Wait 40s, Retransmit 5
Hello due in 9.611s
Neighbor Count is 0, Adjacent neighbor count is 0
enp0s10 is up
ifindex 7, MTU 1500 bytes, BW 0 Mbit <UP,BROADCAST,RUNNING,MULTICAST>
Internet Address 192.168.201.146/24, Broadcast 192.168.201.255, Area 0.0.0.0
MTU mismatch detection:enabled
Router ID 192.168.0.1, Network Type BROADCAST, Cost: 10
Transmit Delay is 1 sec, State Waiting, Priority 1
No backup designated router on this network
Multicast group memberships: OSPFAllRouters
Timer intervals configured, Hello 10s, Dead 40s, Wait 40s, Retransmit 5
Hello due in 7.241s
Neighbor Count is 0, Adjacent neighbor count is 0
robot.cumulusnetworks.com# show ip ospf int enp0s3
enp0s3 is up
ifindex 2, MTU 1500 bytes, BW 0 Mbit <UP,BROADCAST,RUNNING,MULTICAST>
Internet Address 10.0.2.15/24, Broadcast 10.0.2.255, Area 0.0.0.0
MTU mismatch detection:enabled
Router ID 192.168.0.1, Network Type BROADCAST, Cost: 10
Transmit Delay is 1 sec, State Waiting, Priority 1
No backup designated router on this network
Multicast group memberships: OSPFAllRouters
Timer intervals configured, Hello 10s, Dead 40s, Wait 40s, Retransmit 5
Hello due in 2.915s
Neighbor Count is 0, Adjacent neighbor count is 0
Chirag Shah [Wed, 5 Apr 2017 20:14:12 +0000 (13:14 -0700)]
pimd: Pim Nexthop Tracking support with ECMP
In this patch, PIM nexthop tracking uses locally populated nexthop cached list
to determine ECMP based nexthop (w/ ECMP knob enabled), otherwise picks
the first nexthop as RPF.
Introduced '[no] ip pim ecmp' command to enable/disable PIM ECMP knob.
By default, PIM ECMP is disabled.
Intorudced '[no] ip pim ecmp rebalance' command to provide existing mcache
entry to switch new path based on hash chosen path.
Introduced, show command to display pim registered addresses and respective nexthops.
Introuduce, show command to find nexthop and out interface for (S,G) or (RP,G).
Re-Register an address with nexthop when Interface UP event received,
to ensure the PIM nexthop cache is updated (being PIM enabled).
During PIM neighbor UP, traverse all RPs and Upstreams nexthop and determine, if
any of nexthop's IPv4 address changes/resolves due to neigbor UP event.
Testing Done: Run various LHR, RP and FHR related cases to resolve RPF using
nexthop cache with ECMP knob disabled, performed interface/PIM neighbor flap events.
Executed pim-smoke with knob disabled.
Signed-off-by: Chirag Shah <chirag@cumulusnetworks.com>
Donald Sharp [Thu, 6 Apr 2017 00:07:46 +0000 (20:07 -0400)]
eigrpd: Fix massive memory leak
Each call into eigrp_topology_get_successors would leak the list
created. As routes worked their way through the FSM we would
leak memory left and right.
Modify the eigrp_topology_get_successor to return NULL when
there are no SUCCESORS.
Clean up some dead code.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
projects / mirror / frr.git / log