vivek [Thu, 29 Oct 2015 17:30:45 +0000 (10:30 -0700)]
BGP: Do appropriate cleanup on receipt of redistribute update
When there is a change to a redistributed route, either an attribute
such as the metric or the route type itself has changed, protocol clients
receive an update of the route instead of a delete and add as a result
of an earlier optimization. The update needs to be handled as an implicit
delete for any existing redistributed route, especially to handle change
in route type.
vivek [Thu, 29 Oct 2015 16:41:23 +0000 (09:41 -0700)]
BGP: Check for duplicate and overlapping listen ranges
When configuring listen ranges for allowing dynamic BGP neighbors,
ensure that there are no duplicate or overlapping ones. This is
necessary because at the time of handling an incoming connection,
the first range that matches the source of the connection (and hence,
its peer-group parameters) will be used.
Donald Sharp [Wed, 28 Oct 2015 23:59:30 +0000 (19:59 -0400)]
lib: Memory reporting fails over 2GB
Ticket: CM-8015
Reviewed by: CCR-3717
Testing: See bug
The old style mallinfo() function uses an 'int' to
report memory usage data to the program. Unfortunately
modern architectures can chew through 2gb of memory like a
buzz saw hitting some warm butter, especially in the case
of a memory leak or memory fragmentation.
When a daemon uses more than 2gb of memory, just indicate it's
gotten large and we don't know anymore.
Pre-change behavior:
Robot-1# show memory
System allocator statistics:
Total heap allocated: 16777216 TiB
Holding block headers: 1288 KiB
Used small blocks: 0 bytes
Used ordinary blocks: 535 MiB
Free small blocks: 768 bytes
Free ordinary blocks: 16777216 TiB
Ordinary blocks: 266107
Small blocks: 24
Holding blocks: 2
Post-change behavior:
Robot-1# show memory
System allocator statistics:
Total heap allocated: 1572 KiB
Holding block headers: > 2GB
Used small blocks: 0 bytes
Used ordinary blocks: 1443 KiB
Free small blocks: 32 bytes
Free ordinary blocks: 129 KiB
Ordinary blocks: 2
Small blocks: 1
Holding blocks: 2
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Daniel Walton [Fri, 23 Oct 2015 17:36:55 +0000 (17:36 +0000)]
Quagga needs better debugs in lib/sockunion.c
Signed-off-by: Daniel Walton <dwalton@cumulusnetworks.com> Reviewed-by: Donald Sharp <sharpd@cumulusnetworks.com> Reviewed-by: Dinesh G Dutt <ddutt@cumulusnetworks.com>
Ticket: CM-7233
radhika [Thu, 22 Oct 2015 17:14:00 +0000 (10:14 -0700)]
Addition of missing zebra command descriptions
Ticket: CM-7456
Reviewed By: CCR-3528
Testing Done: Unit
Porting of the patch zebra-fix-cmd-type-desc-log.patch from 2.5 branch
Last few Zebra message command types defined were not added to the command type description table used for getting logging strings. This was causing the logs to display "unknown command type" instead of the actual command type. So, added all the missing zebra commands to the command type description table. Also, changed the order of the description table to match with the actual command type definition order.
When saving an integrated config file, certain commands such as
"ipv6 protocol", "ip nht route-map" etc. ended up with a very
different group of commands making it hard to look for them. This
fixes the command grouping so that related commands are located
together.
Signed-off-by: Dinesh G Dutt <ddutt@cumulusnetworks.com> Reviewed-by: Donald Sharp <sharpd@cumulusnetworks.com> Reviewed-by: Vipin Kumar <vipin@cumulusnetworks.com>
vivek [Wed, 21 Oct 2015 05:09:58 +0000 (22:09 -0700)]
Quagga: Display useful info when doing service quagga status
Ticket: CM-7132
Reviewed By: CCR-3461
Testing Done: the usual
Today, 'service quagga status' merely sets the return code and nothing
more. Like other services, it'd be good to print some useful output as
well.
Example output:
cumulus@top1$ sudo service quagga status ospfd
[ ok ] ospfd-1 is running.
[ ok ] ospfd-2 is running.
cumulus@top1$ sudo service quagga status
[ ok ] zebra is running.
[ ok ] ospfd-1 is running.
[ ok ] ospfd-2 is running.
[ ok ] ospf6d is running.
cumulus@top1$ sudo service quagga status
[ ok ] zebra is running.
[ ok ] ospfd-1 is running.
[FAIL] ospfd-2 is not running ... failed!
[ ok ] ospf6d is running.
cumulus@top1$ echo $?
1
cumulus@top1$
Signed-off-by: Dinesh G Dutt <ddutt@cumulusnetworks.com> Reviewed-by: Donald Sharp <sharpd@cumulusnetworks.com>
BGP Unnumbered and Interface based peering can interact in some strange
ways. One of them is when there's an IPv4 address on a link on which
BGP Unnumbered session is beng attempted, but the IPv4 address is not
a /30 or /31. As per the bug report, we end up attempting to start the
BGP FSM on receiving a notification that an IPv4 address is present on
an interface. To avoid attempting to go past BGP's start state in the
absence of a valid peer address is the right thing to do. And this
simple patch does just that.
Signed-off-by: Dinesh G Dutt <ddutt@cumulusnetworks.com> Reviewed-by: Donald Sharp <sharpd@cumulusnetworks.com> Reviewed-by: Vipin Kumar <vipin@cumulusnetworks.com>
vivek [Wed, 21 Oct 2015 04:52:52 +0000 (21:52 -0700)]
Zebra: Redistribute replace handling corner cases
Ticket: CM-7309
Reviewed By: CCR-3448
Testing Done: passing route_ospf_route_thrash, the new redist test
When zebra was modified to have redistributed routes follow a replace
logic instead of the del-add, one case was missed. When a route is
replaced with a change only to the source protocol (say from static
to bgp), its possible that the new source protocol is not selected
for redistribution by a client. Since we did not delete the route
initially, if the add is not allowed for the new source protocol
for a client, we need to send a delete of that redistributed route.
This is what the patch fixes.
Signed-off-by: Dinesh G Dutt <ddutt@cumulusnetworks.com> Reviewed-by: Donald Sharp <sharpd@cumulusnetworks.com> Reviewed-by: Vivek Venkatraman <vivek@cumulusnetworks.com>
Redistributing routes goes through a del/add cycle whenever a redistributed
is updated. This del/add cycle causes disruption by causing traffic loss
for brief/long periods of time(6-8 s in case of OSPF). The modifications in
this patch remove the del/add cycle to ensure that this disruption doesn't
happen.
Also fixed sending no forwarding address when announcing IPv4 routes with IPv6
nexthops, and sending nexthop only when there is a single path.
Signed-off-by: Dinesh G Dutt <ddutt@cumulusnetworks.com> Reviewed-by: Donald Sharp <sharpd@cumulusnetworks.com> Reviewed-by: Vivek Venkatraman <vivek@cumulusnetworks.com>
vivek [Tue, 20 Oct 2015 21:32:12 +0000 (14:32 -0700)]
Zebra: Fix setting source for 5549-learnt routes via ip protocol
Ticket: CM-6854
Reviewed By: CCR-3297
Testing Done: bgpsmoke, bgpclos to verify setting source (in 2.5-br)
Two pieces prevented the user from specifying a route-map with set src on
IPv4 routes learnt via BGP's RFC 5549 model (v4 prefix with v6 nexthop):
- There was code missing in the section specific to 5549 in setting
the src in the netlink message
- During RIB processing, route-map processing was ignored when the NH
was v6 and the route itself was v4.
As per the code, all route-map processing that uses nexthop validates the
NH type before applying the route-map and so there should be no errors
as a consequence of relaxing bullet 2 above.
Signed-off-by: Dinesh G Dutt <ddutt@cumulusnetworks.com> Reviewed-by: Donald Sharp <sharpd@cumulusnetworks.com>
Donald Sharp [Tue, 13 Oct 2015 18:37:15 +0000 (11:37 -0700)]
lib: fix vty.c and smux.c static variable clash
Both vty.c and smux.c declare:
static struct thread_master *master
This is not a good thing because they are both linked into
the same library. If you want to pass different struct thread_master
pointers into smux.c and vty.c you will probably not get the result
you were looking for
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
radhika [Fri, 9 Oct 2015 20:44:32 +0000 (13:44 -0700)]
Fix for IPv6 OSPF BFD session staying down when ifdown/ifup on logical interfaces
Ticket: CM-7649
Reviewed By: Donald
Testing Done:
This is porting of the patch, ospf6d-bfd-fix-dereg-miss.patch from br2.5.
Issue: The IPv6 OSPF BFD sessions stay down after ifdown/ifup on logical interfaces. This problem doesn’t exist for BFD sessions created by BGP and IPv4 OSPF.
Root cause: When the interface is brought down the IPv6 neighbors discovered on that interface are deleted. This deletion happens without first bringing down the neighbor and the BFD deregistration happens only when the neighbor state changes. This leaves an orphaned BFD session in PTM. Also, the BFD session socket that is bound to the interface that was brought down loses connection. The socket has to be rebound to the interface when it comes up. This problem will not happen if the client deleted the sessions and re-adds it when interface goes down and come up. IPv4 OSPF and BGP work exactly like that.
Fix: Added the BFD deregistration code to IPv6 OSPF neighbor delete.
In Quagga, the ptm status is shown as pass for all the interfaces that PTM is not tracking. When ptm is enabled in Quagga all the interfaces are initialized as pass and changed to fail/pass when ptm cable check updates are received. For all the interfaces for which no status was received from PTM remain at pass status. Interface show in quagga indicates wrong status and it should be n/a for all the untracked interfaces. To fix the problem introduced a third state “unknown” and this is default ptm status for all the interfaces. The ptm status is updated accordingly to pass/fail when the updates are received from PTM. Also, reset all interface ptm status to unknown when the connection with ptm is lost and the status gets updated when the connection with PTM is re-established.
Donald Sharp [Wed, 7 Oct 2015 16:27:09 +0000 (09:27 -0700)]
Quagga: Fix some more compile warnings
The debian build process under Jessie has a 'newer' gcc
compiler that is more stringent on warnings returned.
This commit cleans up some more warnings returned.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Daniel Walton [Thu, 1 Oct 2015 18:23:00 +0000 (11:23 -0700)]
'service quagga reload' breaks with four top level keywords
Signed-off-by: Daniel Walton <dwalton@cumulusnetworks.com> Reviewed-by: Donald Sharp <sharpd@cumulusnetworks.com> Reviewed-by: Vivek Venkataraman <vivek@cumulusnetworks.com>
Ticket: CM-7757
Reviewed By: Donald and Vivek
Donald Sharp [Wed, 30 Sep 2015 22:05:19 +0000 (15:05 -0700)]
bgpd: Fix neighbor command with internal or external keyword and interface
Ticket: CM-7737 Reviewed-by: CCR-3611
Testing: See bug
When configuring a bgp peer that already has some config hung off of it,
such as 'interface v6only' and then configuring remote-as internal/external
will not cause the config to be taken.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Donald Sharp [Tue, 29 Sep 2015 13:19:30 +0000 (09:19 -0400)]
quagga: Additional centos 6 -enable-werror fixes
This commit fixes these warnings:
1) bgpd/bgp_nexthop.c - dereferencing pointer 'X' does break strict-aliasing rules
3) ripd/ripd.c - 'ifaddr.prefixlen' may be used uninitialized in this function
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Donald Sharp [Mon, 28 Sep 2015 20:17:36 +0000 (13:17 -0700)]
vtysh: Fix Quagga.conf file read in.
There exists a sequence of cli commands that are successfully read in by bgpd.conf, but
not by a consolidated Quagga.conf.
This issue stems from the fact that the consolidated config file attempts to match the
current node + 1 node up the tree, while the individual config file searches for matches
all the way up the tree.
Quagga.conf read-in relies on vtysh_cmd.c command parsing which puts all nodes
at CONFIG_NODE and if a match is found CMD_SUCCESS_DAEMON is returned. This signals to
the parser to call the appropriate daemon with the comamnd.
bgp as an example has three levels of config node's. If you are reading in a config node
at the 3rd level(say address-family ipv6) then transition to another node under bgp it will
not work in Quagga.conf because the code only looked up one node and was at CONFIG_BGP when it failed
to find a match.
Ticket: CM-7625
Reviewed by: CCR-3591
Testing: See Bug
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com> Reviewed-by: Daniel Walton <dwalton@cumulusnetworks.com>
When BGP receives an update to a redistributed route and the type of
the source has changed (e.g., from OSPF to static), the source route
type is not being updated in the RIB entry. This can lead to problems
such as the route being incorrectly deleted if redistribution for the
prior source is unconfigured.
zclient.c depended upon link time inclusion of a
extern struct thread_master *master. This is a violation of the
namespace of the calling daemon. If a library needs the pointer
pass it in and save it for future use.
This code change also makes the zclient code consistent with
the other lib functions that need to schedule work on your behalf
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Donald Sharp [Tue, 22 Sep 2015 19:00:57 +0000 (12:00 -0700)]
vtysh: Allow display of individual daemons configs
When executing a 'show run' or 'write terminal' you see the
entire integrated config. You have no way of knowing what an
individual daemon is going to write until after you do a write
of config to disk if you are not using an integrated configuration.
This change allows the end-user to do such a thing.
Ticket: CM-7597 Reviewed-by: CCR-3561
Testing: See Bug
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
When a static route has a nexthop change but the route is also learnt
through another protocol, ensure that the nexthop tracking code marks
the correct route entry (RIB) for processing.
This is a port of patch zebra-static-nht-fixes2.patch from 2.5-br.
This is a port of patch bgpd-update-groups-fix-default-originate.patch
from 2.5-br.
Even though default origination is configured for a BGP neighbor through
"neighbor default-originate" or "peer-group default-originate", the neighbor
may sometimes not receive the default route in some situations. Change to
ensure update subgroups also differentiate on default-originate sent status.
Signed-off-by: Vivek Venkatraman <vivek@cumulusnetworks.com> Reviewed-by: Donald Sharp <sharpd@cumulusnetworks.com> Reviewed-by: Daniel Walton <dwalton@cumulusnetworks.com> Reviewed-by: Vipin Kumar <vipin@cumulusnetworks.com>
Daniel Walton [Thu, 17 Sep 2015 14:24:21 +0000 (07:24 -0700)]
'service quagga reload' should not dump so much output to the log file.
It should also check that quagga is running before attempting to do
any work.
Signed-off-by: Daniel Walton <dwalton@cumulusnetworks.com> Reviewed-by: Donald Sharp <sharpd@cumulusnetworks.com>
Ticket: CM-7486
Reviewed By: Donald Sharp
Testing Done:
Verified that 'service quagga reload' exits cleanly if quagga is not
running. Also verified that it produces a minimal amount of log output
by default. The user can enable --debug in /etc/init.d/quagga if they
would like to enable debug output.
Donald Sharp [Wed, 16 Sep 2015 12:30:23 +0000 (05:30 -0700)]
Warn user in various max path edge cases
Ticket: CM-6680 Reviewed-by: CCR-3486
Testing: See bug
In these situations:
(A) user enters under bgp more 'maximum-paths' than zebra is compiled with
warn the user that there is a problem
(B) Zebra receives more maximum paths than what it can handle log the fact
that this happened
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Daniel Walton [Wed, 16 Sep 2015 02:14:06 +0000 (19:14 -0700)]
BGP: Display the right reason code for session reset
Ticket: CM-7439
Reviewed By: Donald Sharp
Testing Done:
If a session was reset due to a NOTIFICATION the "show ip bgp
neighbor" output would not display details on what the
notification actually was. This patch changes that. Example:
superm-redxp-05# show ip bgp neighbors 20.1.2.2
BGP neighbor is 20.1.2.2, remote AS 21, local AS 10, external link
[snip]
Last reset 01:05:07, due to NOTIFICATION sent (OPEN Message Error/Bad Peer AS)
Donald Sharp [Fri, 11 Sep 2015 12:44:31 +0000 (05:44 -0700)]
quagga netlink buffer size increase
Ticket: CM-7380 Reviewed-by: CCR-3478
Testing: See Bug
This is a fix to allow the netlink buffer size to grow to a reasonable number
over the current 4mb choosen. This number was choosen by running some
smoke tests that would fail and experimenting to find a number that worked
with those tests and then adding some headroom to that number.
This is a bit of a temporary fix due to timelines instead of the real fix
which is to write the code to properly recover from a netlink buffer overflow.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Daniel Walton [Fri, 11 Sep 2015 03:10:16 +0000 (20:10 -0700)]
bgpd: Exchange hostname capability and display hostnames in output
This patch adds a hostname capability. The node's hostname and
domainname are exchanged in the new capability and used in show command
outputs based on a knob enabled by the user. The hostname and domainname
can be a maximum of 64 chars long, each.
Signed-off-by: Dinesh G Dutt <ddutt@cumulusnetworks.com> Reviewed-by: Daniel Walton <dwalton@cumulusnetworks.com> Reviewed-by: Vivek Venkataraman <vivek@cumulusnetworks.com>
Ticket: CM-5660
Reviewed By: CCR-2563
Testing Done:
David Lamparter [Wed, 20 May 2015 20:34:56 +0000 (22:34 +0200)]
lib: fix "sockunion: add hash function" for BSD (9196caf)
The sockunion_hash() function uses s6_addr32, which is not defined on
BSD systems. (It only works on glibc because we set _GNU_SOURCE)
ripngd/ripng_nexthop.h already contains a workaround for this. Bump
workaround to prefix.h so it's available everywhere.
Reported-by: NetDEF CI System <mwinter@netdef.org> Fixes: 9196caf ("sockunion: add hash function") Cc: Timo Teräs <timo.teras@iki.fi> Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
Donald Sharp [Thu, 3 Sep 2015 13:50:16 +0000 (06:50 -0700)]
Fix neighbor coming up without an as specified
Ticket: CM-7012
Reviwed by: CCR-3451
Testing: See bug
When you specify a neighbor <interface> <something>
and don't specify a remote-as the neighbor relationship
will still come up with ipv6 unnumbered if you have
RA configured on the interface.
Donald Sharp [Wed, 2 Sep 2015 12:19:44 +0000 (05:19 -0700)]
Fix some more memory issues in Quagga
Ticket: CM-4109 Reviewed-by: CCR-3414
Testing: See bug
Fixup of these memory issues:
(A) peer->clear_node_queue was accidently removed. Add back in.
(B) Clean up bm->process_main_queue and bm->process_rsclient_queue initialization
(C) Some memory leaks
(D) Clean up unused threads
Steve Hill [Tue, 28 Jul 2009 20:36:14 +0000 (16:36 -0400)]
lib: Improve error reporting from broken config files
* command.h: (config_from_file) Add variable to interface for line
number reporting.
* command.c: (config_from_file) Set & increment 'line_num' while parsing.
* vty.c: (vty_read_file) Report parse errors in the correct order to
stderr, with added line numbers.
Conflicts:
lib/command.c
lib/vty.c
Integrated in changes made to continue loading code even after failure
to read a line in properly as part of this cherry-pick
Double commit of b76943235e09472ec174edcf7204fc82d27fe966 from br2.5. But, manually resolved all the compilation errors. Also, modified the shows to support the json format which was not supported in br2.5.
CM-6802 – Currently, BFD session status can be monitored only through ptmctl. There is no way to check the BFD status of a peer/neighbor through Quagga. Debugging becomes easier if BFD status is shown in Quagga too. BFD status is relevant when it is shown against the BGP peer/OSPF neighbor. For, this following code changes have been done:
- Only down messages from PTM were being propagated from Zebra daemon to clients (bgpd, ospfd and ospf6d). Now, both up and down messages are redistributed to the clients from zebra. BFD status field has been added to the messaging. Handling of BFD session up messages has been added to the client code. BGP/OSPF neighbor is brought down only if the old BFD session status is ‘Up’ to handle extra/initial down messages.
- BFD status and last update timestamp fields have been added to the common BFD info structure. Also, common show functions for showing BFD information have been added to BFD lib.
- Modified the BGP neighbor show functions to call common BFD lib functions.
- For ospf and ospf6, BFD information was maintained only at interface level. To show BFD status per neighbor, BFD information has been added at neighbor level too. “show ip ospf interface”, “show ip ospf neighbor detail”, “show ipv6 ospf6 interface” and “show ipv6 ospf6 neighbor detail” output have been modified to show BFD information.
CM-6952 - IBGP peers were always assumed to be multi-hop since there was no easy way to determine whether an IBGP peer was single hop or multihop unlike EBGP. But, this is causing problem with IBGP link local peers since BFD doesn't allow multihop BFD session with link local IP addresses. Link local peers were discovered when the interface peering was enabled. Interface peering is always singlehop. So, added checks to treat all interface based peers as single hop irrespective of whether the peer is IBGP or EBGP.
vivek [Sat, 29 Aug 2015 23:10:12 +0000 (16:10 -0700)]
BGP: Fix MD5 authentication for unnumbered neighbors
Ticket: CM-6369
Reviewed By: CCR-3318
Testing Done: Manual testing of various password scenarios.
This is a port of patch bgpd-unnumbered-nbr-fix-password.patch from
2.5-br.
In the case of BGP unnumbered, the peer IP address is derived and not
explicitly configured. If there is a password configured for the peer,
it can be set on the listen socket only after the IP address has been
derived and needs to be cleared when the IP address goes away.
vivek [Sat, 29 Aug 2015 18:40:32 +0000 (11:40 -0700)]
BGP: Handle interface or local address failure
Ticket: CM-6883
Reviewed By: CCR-3272
Testing Done: Tested on 2.5.3-SE-1
This commit is a port of the patch bgpd-handle-peer-local-address-failure.patch
from 2.5-br.
When a peering is being established, the IPv4 and IPv6 addresses of the
local end of the connection, as applicable, are obtained and stored in
the peer's 'nexthop' structure to facilitate filling of the NEXT_HOP
field in Update messages among other things. The process of obtaining the
local address involves examination of the list of interfaces to identify
a match corresponding to the socket address of the connection.
There are timing conditions, especially when BGPD starts with a config,
where the interface may not have reached BGP from Zebra at the time a
peering reaches the state to determine the local addresses. The code does
not handle this well and the result could be Updates generated with bad
(Martian) NEXT_HOP values. Resolve the issue by bringing down the connection
in this case as not identifying the local addresses is really an error.
PTM cable status updates were not being handled in the notification callback registered with the ptm lib. This results in interface ptm status mismatch between PTM and zebra when interface cable check status changes (pass->fail or fail->pass). Zebra requests PTM to send cable status updates using get-status command and PTM sends the cable status updates as command responses to get-status. This was being handled in the commmand response callback registered with ptm lib. But, the subsequent status updates come as notifications and handling of those notifications that was missing in the notification callback. Fixed the issue by making a common callback for command responses and notifications. All the command responses other than the responses to get-status are dropped/ignored.
projects / matthieu / frr.git / log