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
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 [Wed, 16 Nov 2016 16:28:11 +0000 (11:28 -0500)]
ospfd: Fix possible crash and wrong data being shown
When you have more than one ospf interface configured
to be used, we were attempting to reuse the
json_interface_sub pointer after we added it
to the json data structure.
Ticket: CM-13597 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>
projects / mirror / frr.git / log