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.
vtysh: fix a compile error when user/group are disabled
If FRR is configured explicilty with --disable-user and
--disable-group, FRR_USER and FRR_GROUP will not be defined
and can be safely skipped in vtysh.
Renato Westphal [Fri, 19 May 2017 13:51:00 +0000 (10:51 -0300)]
bgpd: fix sending of invalid nexthops on the wire
The bpacket_reformat_for_peer() function rewrites the nexthop of outgoing
route updates on a per-peer basis in order to handle route-maps ("set
ip next-hop") and locally-originated routes missing a nexthop.
In the latter case, RFC 4271 says the following: "When announcing a
locally-originated route to an internal peer, the BGP speaker SHOULD use
the interface address of the router through which the announced network
is reachable for the speaker as the NEXT_HOP".
We were doing this for regular IPv4/IPv6 routes, but not for
VPN/EVPN/ENCAP routes, which were being announced with invalid nexthops
(0.0.0.0 or ::).
Chirag Shah [Fri, 12 May 2017 19:05:46 +0000 (12:05 -0700)]
pimd: Fix to Tx S,G Join when SGRpt->Join state
-Upon Rx (*,G) Join w/o SGRpt at RP, trigger (S,G) Join
towards FHR, unset SGRpt flag from channel,
add (*,G) oif to (S,G) entry.
-Add I am not RP check to triger SGRpt on *,G path otherwise,
send S,G Prune on SPT path from RP to FHR upon receving *,G Prune.
-Upon Rx SGRpt receive, remove OIF(downstream where Prune received) from specific S,G.
Testing Done:
pim-smoke
Ran 95 tests in 11790.552s
FAILED (SKIP=10, failures=4)
Signed-off-by: Chirag Shah <chirag@cumulusnetworks.com>
Donald Sharp [Wed, 16 Nov 2016 17:00:40 +0000 (12:00 -0500)]
bgpd: More Extended nexthop fixing
Basically if we are reading in a cli with a extended-nexthop
and we have not received from zebra the interface we are working
on I believe we have a race condition where we are not
propagating the PEER_FLAG_CAPABILITY_ENHE in this case.
Modify the code to propagate even if we haven't found the
interface yet.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Donald Sharp [Tue, 15 Nov 2016 14:39:35 +0000 (09:39 -0500)]
bgpd: Fix occassional turn off of extended-nexthop for an if
Sometimes, like once every 400 iterations, when you restart
Quagga, extended-nexthop has been turned off for interface
based config( for 5549 ).
Examining the code, there is only 1 real path to setting
the PEER_FLAG_CAPABILITITY_ENHE and that is through
peer_conf_interface_get. Modify this code path
to always set the PEER_FLAG_CAPABILITY_ENHE if it is
not already set.
In addition, fix a possible pointer dereference.
Ticket: CM-12929 Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Don Slice [Tue, 14 Feb 2017 17:15:40 +0000 (09:15 -0800)]
zebra: stop deregistering static nexthops unless removing the static
Problem reported was that with some overlapping static route configurations,
when the link went down the less specific static was not re-installed after
the link came back up. Determined that with the overlapping statics, we
would recursively resolve the next-hop temporarily thru the more specific
static route, but since the next-hop wasn't actually reachable, we would go
through the code that clears the nht information for the static completely.
This caused the nht code to no longer process the static route.
After reviewing the process, there doesn't seem to be any reason that the
static should be deregistered in that section of code. Removed the
deregister and the problem is resolved and not addional failures seen in
manual testing. zebra_test.py completed successfully and ospf and bgp smokes
completed with no new failures.
Ticket: CM-14873 Signed-off-by: Don Slice <dslice@cumulusnetworks.com> Reviewed-by: CCR-5696
Don Slice [Wed, 23 Nov 2016 19:58:27 +0000 (11:58 -0800)]
zebra: Move interfaces to default before deleting
Encountered a crash in zebra due to getting a delete on an SVI with
VRR configured. Since we don't actually do a delete but flag the interface
as inactive, slag VRR interfaces would remain on the vrf_iflist with a lock
count of zero, causing the crash. Since all other interface types are moved
to the default table before deleting, doing the same thing for any interfaces
that were left in the vrf.
Testing includes manual testing, bgp-min, ospf-min, vrf-min, bgp-smoke, and ospf-smoke.
All passed (first time or on rerun) or match known failures.
Ticket: CM-13288 Signed-off-by: Don Slice Reviewed-by: Donald Sharp
Chirag Shah [Tue, 24 Jan 2017 01:39:54 +0000 (17:39 -0800)]
pimd: fix ip pim hello option does not take in effect
If frr.conf file has pim hello option setup prior to pim sm under an interface, upon frr start/restart hello option cli replayed prior to sm command
from vtysh. Added a code in pim hello option cli handler to create pim vif if it does not exist.
Testing Done:
configure pim hello options before pim sm in frr.conf file and restart frr
Signed-off-by: Chirag Shah <chirag@cumulusnetworks.com>
Daniel Walton [Wed, 17 May 2017 00:16:09 +0000 (00:16 +0000)]
tools: reload handle removal of entire address-family section under BGP
Signed-off-by: Daniel Walton <dwalton@cumulusnetworks.com>
When an entire address-family section is removed from under BGP, we
cannot just issue 'no address-family foo bar' as address-family line
doesn't support 'no'. We have to delete the individual lines under the
address-family.
Daniel Walton [Tue, 16 May 2017 23:58:34 +0000 (23:58 +0000)]
bgpd: 'redistribute' triggers both IPv4 and IPv6 code paths
Signed-off-by: Daniel Walton <dwalton@cumulusnetworks.com>
Whenever you did "redistribute" zebra would kick this off for ipv4 and
ipv6. No real issue other than this is sub-optimal
Daniel Walton [Tue, 16 May 2017 23:54:46 +0000 (23:54 +0000)]
bgpd: "neighbor swpX interface remote-as XYZ" is ignored
Signed-off-by: Daniel Walton <dwalton@cumulusnetworks.com> Reviewed-by: Don Slice <dslice@cumulusnetworks.com>
If you did:
neighbor swp1 interface
neighbor swp1 interface remote-as external
we would not set the remote-as. You could however still do
neighbor swp1 remote-as external
Don Slice [Wed, 5 Apr 2017 14:13:45 +0000 (07:13 -0700)]
bgpd: resolve ipv6 ecmp issue with vrfs and ll nexthop
Problem reported that ecmp wasn't working correctly in a vrf with
ipv6. Issue was that originator of the routes were sending the updates
with a link-local nexthop and nhlen of 16. In this particular case,
bgp_zebra_announce was using the wrong call to get the ifindex and
was not supplying the vrf. This caused ecmp to work only in the case
of the default vrf.
Ticket: CM-15545 Signed-off-by: Don Slice <dslice@cumulusnetworks.com> Reviewed-by: CCR-6017
projects / mirror / frr.git / log