* redhat/quagga.spec.in: remove with_ipv6, it should just be the norm now.
The actual pimd binary wasn't being packaged, fix.
Remove deprecated pam.stack support.
Paul Jakma [Fri, 4 Sep 2015 13:25:13 +0000 (14:25 +0100)]
distro: fix redhat/quagga.spec.in
* quagga.spec.in: Add default for with_pimd macro.
Remove ancient condtional on quagga_buildreqs.
More recent rpmbuild complains about too many levels of recursion in
quagga_buildreqs, so use %{expand:..}.
Actually use quagga_buildreqs in BuildRequires!
groff is needed for build.
texi2html --number argument has disappeared, split into 2.
Don Slice [Fri, 10 Jun 2016 13:58:03 +0000 (06:58 -0700)]
bgpd: remove vrf->iflist deleted to avoid a crash
Ticket: CM-11327 Signed-off-by: Don Slice Reviewed-by: Donald Sharp
Testing Done: Manual testing, bgp-min, vrf-min, bgp-smoke, vrf-smoke all successful
When bgp was configured in a vrf and then deleted, the vrf->iflist
was being deleted from the vrf. Since the vrf itself was not deleted,
it was assumed in later calls that the vrf->iflist was still there
and when it was referenced, the crash occurred.
Issue: bgpd is not replaying the BFD registrations to PTM after quagga restart.
Root Cause: This problem happens when BFD configuration is part of the peer group template. Currently, the BFD configuration is being copied to the peer from template as part of the AF (address family) configuration. But, when the saved config is used after the quagga restart the peer group template is applied to the peer before the AF configuration is configured for the template. Due to this the BFD configuration never gets copied from the template to the peer and the BGP peers have no BFD configuration after the restart
Donald Sharp [Thu, 19 May 2016 13:56:35 +0000 (09:56 -0400)]
lib: Fix some poll semantics
Two Fixes:
1) When a fd has both read and write as a .events.
(POLLHUP | POLLIN | POLLOUT) and a
thread_cancel_read_write call is executed
from a protocol, the code was blindly removing
the fd from consideration at all.
2) POLLNVAL was being evaluated before POLLIN|POLLOUT
were being evaluated. While I didn't see a case
of POLLNVAL being included with other .revent flags
I decided to move the POLLNVAL and POLLHUP handling
to the same section of code.
Additionally the function thread_cancel_read_write
was poorly named and let me to poorly implement
the poll version of it. I've renamed the function
thread_cancel_read_or_write in an attempt to
make this problem moot in the future.
Ticket: CM-11027 Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
vivek [Wed, 18 May 2016 21:08:55 +0000 (14:08 -0700)]
Quagga: Make sure order of route-maps in list and hash table matches
Quick create/delete actions on a route-map can result in the same route-map
entity having multiple entries created for it — because BGP hasn't run the
update processing to complete prior delete action. The route-map is present
in both a hash table as well as a linked list and the order in each is
different. This can lead to problems when the BGP route-map update processing
runs and finds the same route-map entity present for deletion multiple times.
For example, while processing instance-2 of rmap-A, the code may end up
freeing the hash bucket corresponding to instance-1 of rmap-A.
The fix works by ensuring the list is ordered the same way as the hash
buckets.
vivek [Sat, 14 May 2016 21:48:18 +0000 (14:48 -0700)]
BGP: Unlink BGP instance from VRF only at the end of deletion
When a BGP instance including the default instance is deleted, it needs to be
unlinked from the corresponding VRF structure. However, instance deletion does
not happen in one shot but needs a lot of threads to run - peer event handling,
route processing etc. - before it can complete. Premature unlinking of the
instance from underlying VRF would result in BGP routes not being deleted from
the zebra RIB.
Daniel Walton [Sat, 14 May 2016 02:29:11 +0000 (02:29 +0000)]
OSPF ANVL failures in 3.0
Signed-off-by: Daniel Walton <dwalton@cumulusnetworks.com> Reviewed-by: Donald Sharp <sharpd@cumulusnetworks.com>
Ticket: CM-10088
When we pulled this patch from upstream there was one spot where we
incorrectly used min_ls_interval (5s) instead of min_ls_arrival (1s).
commit ac7424f9dec0d49d891e0b457afa8e31c2b854fe
Author: Michael Rossberg <michael.rossberg@tu-ilmenau.de>
Date: Mon Jul 27 21:05:44 2015 +0200
configuration options for faster OSPF convergence
Allow configuration of faster OSPF convergence via the
min_ls_interval and min_ls_arrival timer lengths.
This patch was originated by Michael, and cross-ported
to Cumulus's Quagga.
vivek [Fri, 13 May 2016 05:57:40 +0000 (22:57 -0700)]
zebra: Accept and process RAs with lifetime of zero
Fix code to not discard received RAs with a lifetime of 0. The router lifetime
is only applicable for default router processing which is not relevant here.
For the purposes of BGP unnumbered, the neighbor should be learnt without
consideration of the value of router lifetime in received RA.
Note: This patch brings in a portion of the earlier commit 690baa53592320dddee5c729f959150cc9a72699 - this included some additional
changes which have been reverted.
Making the router lifetime in the IPv6 RAs as 0 by default would break BGP
unnumbered when this version of Quagga goes up against a 2.5.x Quagga. This
is because of a defect in the Quagga code that ignores any received RAs with
a lifetime of 0.
Don Slice [Wed, 11 May 2016 15:47:02 +0000 (08:47 -0700)]
zebra: Add route-map support to ip import-table
Added the ability to supply a route-map to the ip import-table command,
which greatly improves filtering between the kernel prefixes in a
non-default table that are imported into the zebra rib.
Ticket:CM-8168 Signed-off-by: Donald Slice
Reviewed By: Donald Sharp
vivek [Thu, 12 May 2016 23:51:43 +0000 (16:51 -0700)]
BGP: Set advertisement interval when triggering IPv6 RAs
This change extends the earlier change which added the ability in BGP to
trigger IPv6 Router Advertisements when an unnumbered neighbor is configured.
In addition to triggering the RAs, the advertisement interval is also set to
10 seconds. This is needed to handle the scenario where the peer may start
later.
Donald Sharp [Thu, 12 May 2016 01:31:30 +0000 (21:31 -0400)]
Fix unprotected debugs to warns and fix
In the case of a route replace failing we
saw two issues with the logging:
1) The route replace was a debug instead of a warn
-> In this case change code to zlog_warn
2) The buf in the route replace was not being initialized
because buf initialization was protected by a debug check.
-> In this case move the buf initialization to inside
the failure case.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com> Reviewed-by: Daniel Walton <dwalton@cumulusnetworks.com> Reviewed-by: Vivek Venkatraman <vivek@cumulusnetworks.com>
Donald Sharp [Thu, 12 May 2016 00:22:45 +0000 (20:22 -0400)]
Fix non initialized usage of data in zebra_rnh.c
In zebra_deregister_rnh_static_nexthops the nh_p
structure was not being properly initialized for
all the cases that we could be storing a nexthop
for. This was causing code later to retrieve
the table from an nh_p->family which was garbage.
In the case of BLACKHOLE and Ifindex based routes
do nothing because they shouldn't be a nexthop
considered for NHT.
==2239== Conditional jump or move depends on uninitialised value(s)
==2239== at 0x4E5F6CE: family2afi (prefix.c:217)
==2239== by 0x155F7C: get_rnh_table (zebra_rnh.c:83)
==2239== by 0x156194: zebra_lookup_rnh (zebra_rnh.c:148)
==2239== by 0x15655E: zebra_deregister_rnh_static_nh (zebra_rnh.c:242)
==2239== by 0x156681: zebra_deregister_rnh_static_nexthops
(zebra_rnh.c:280)
==2239== by 0x12F3DF: rib_unlink (zebra_rib.c:2210)
==2239== by 0x12E9CE: rib_process (zebra_rib.c:1843)
==2239== by 0x12EA8A: process_subq (zebra_rib.c:1873)
==2239== by 0x12ECAF: meta_queue_process (zebra_rib.c:1936)
==2239== by 0x4E89625: work_queue_run (workqueue.c:298)
==2239== by 0x4E63230: thread_call (thread.c:1577)
==2239== by 0x125830: main (main.c:432)
==2239==
==2239== Conditional jump or move depends on uninitialised value(s)
==2239== at 0x4E5F6DB: family2afi (prefix.c:220)
==2239== by 0x155F7C: get_rnh_table (zebra_rnh.c:83)
==2239== by 0x156194: zebra_lookup_rnh (zebra_rnh.c:148)
==2239== by 0x15655E: zebra_deregister_rnh_static_nh (zebra_rnh.c:242)
==2239== by 0x156681: zebra_deregister_rnh_static_nexthops
(zebra_rnh.c:280)
==2239== by 0x12F3DF: rib_unlink (zebra_rib.c:2210)
==2239== by 0x12E9CE: rib_process (zebra_rib.c:1843)
==2239== by 0x12EA8A: process_subq (zebra_rib.c:1873)
==2239== by 0x12ECAF: meta_queue_process (zebra_rib.c:1936)
==2239== by 0x4E89625: work_queue_run (workqueue.c:298)
==2239== by 0x4E63230: thread_call (thread.c:1577)
==2239== by 0x125830: main (main.c:432)
Donald Sharp [Wed, 11 May 2016 23:11:06 +0000 (19:11 -0400)]
lib: Fix connected lookup
When looking up the connected route, the delete was
causing crashes in OSPF due to the oi having copies
of the freshly deleted connected interface. Fix
code to first lookup the connected route and use that
instead of just deleting it.
Valgrind Findings:
==24112== Invalid read of size 1
==24112== at 0x4E8283F: ospf_intra_add_stub (ospf_route.c:614)
==24112== by 0x4E80B15: ospf_spf_process_stubs (ospf_spf.c:1064)
==24112== by 0x4E80F74: ospf_spf_calculate (ospf_spf.c:1269)
==24112== by 0x4E811C9: ospf_spf_calculate_timer (ospf_spf.c:1339)
==24112== by 0x5126230: thread_call (thread.c:1577)
==24112== by 0x401E00: main (ospf_main.c:377)
==24112== Address 0x7f56a09 is 9 bytes inside a block of size 40 free'd
==24112== at 0x4C29E90: free (in
/usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==24112== by 0x51290B3: zfree (memory.c:132)
==24112== by 0x51287F0: connected_free (if.c:987)
==24112== by 0x514406A: zebra_interface_address_read (zclient.c:1146)
==24112== by 0x4E5A81C: ospf_interface_address_add (ospf_zebra.c:262)
==24112== by 0x5144838: zclient_read (zclient.c:1397)
==24112== by 0x5126230: thread_call (thread.c:1577)
==24112== by 0x401E00: main (ospf_main.c:377)
Ticket: CM-10890 Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com> Reviewed-by: Vivek Venkatraman <vivek@cumulusnetworks.com> Reviewed-by: Daniel Walton <dwalton@cumulusnetworks.com>
Daniel Walton [Wed, 11 May 2016 13:12:08 +0000 (13:12 +0000)]
"ip protocol" is missing ospf as an option
Signed-off-by: Daniel Walton <dwalton@cumulusnetworks.com> Reviewed-by: Donald Sharp <sharpd@cumulusnetworks.com>
Ticket: CM-10849
We were incorrectly listing protocols that supported ipv6 for "ip
protocol" instead of listing the protocols that supported ipv4.
With the fix
superm-redxp-05(config)# ip protocol ?
any Any of the above protocols
bgp Border Gateway Protocol (BGP)
connected Connected routes (directly attached subnet or host)
isis Intermediate System to Intermediate System (IS-IS)
kernel Kernel routes (not installed via the zebra RIB)
ospf Open Shortest Path First (OSPFv2)
rip Routing Information Protocol (RIP)
static Statically configured routes
table Non-main Kernel Routing Table
superm-redxp-05(config)#
superm-redxp-05(config)#
superm-redxp-05(config)# ipv6 protocol ?
any Any of the above protocols
bgp Border Gateway Protocol (BGP)
connected Connected routes (directly attached subnet or host)
isis Intermediate System to Intermediate System (IS-IS)
kernel Kernel routes (not installed via the zebra RIB)
ospf6 Open Shortest Path First (IPv6) (OSPFv3)
ripng Routing Information Protocol next-generation (IPv6) (RIPng)
static Statically configured routes
table Non-main Kernel Routing Table
superm-redxp-05(config)#
superm-redxp-05(config)#
vivek [Tue, 10 May 2016 16:29:25 +0000 (09:29 -0700)]
BGP: Fix nexthop setting for default originate
The nexthop setting for IPv6 default origination was incorrect, resulting in
the same (incorrect) IPv6 link-local nexthop being advertised to multiple
peers. The issue was also present for IPv4 default origination when IPv4
routes are advertised with IPv6 nextops (RFC 5549).
For default origination, we should just reset the nexthop when forming the
update for the update-group and let the outbound update/nexthop setting code
set it correctly.
Signed-off-by: Vivek Venkatraman <vivek@cumulusnetworks.com> Reviewed-by: Daniel Walton <dwalton@cumulusnetworks.com> Reviewed-by: Donald Sharp <sharpd@cumulusnetworks.com> Reviewed-by: Don Slice <dslice@cumulusnetworks.com>
Ticket: CM-10623
Reviewed By: CCR-4677
Testing Done: Manual, bgp-min
vivek [Mon, 9 May 2016 22:53:06 +0000 (15:53 -0700)]
Quagga: Check and cleanup prior address when processing address add on interface
IPv4 addresses can be learnt from the kernel even when the interface is down.
Quagga notifis clients of addresses upon learning of them (initial read or
upon NEWADDR) as well as when the interface comes up. The problem is that
while zebra code itself has checks to ensure duplicate addresses aren't added
to an interface, that is not true for the clients.
This patch checks for duplicates when the client receives the address add.
Upon this, the patch does a delete and add as done in zebra - because there
is a possibility that some other parameter could have changed. The fix also
takes care of the extra memory allocation for 'connected' in clients.
radhika [Mon, 9 May 2016 03:11:18 +0000 (20:11 -0700)]
zebra - BFD client de-registration support
CM-10680
Issue: When BGP daemon is stopped, all the BGP BFD sessions are not getting deleted from PTM.
Root cause: BGP daemon stop causes BFD de-register message to be sent for every peer on which BFD is enabled. But, all the de-register messages from bgpd to zebra are not processed before the socket close. This results in some stale BGP BFD sessions.
Fix: Support for client de-register message has been added in PTM/BFD. Changes in Quagga to support BFD client de-registrations:
− The BFD clients de-registration is sent directly from zebra daemon when zebra client (bgpd, ospfd and ospf6d) socket close is detected.
− Introduced a BFD flag for the zebra clients to prevent BFD de-registration messages from being sent to zebra daemon when the client is shutting down. This reduces the BFD messaging.
CM-10540
Issue: Invalid ptm status “fail” instead of “n/a” being displayed for VRF interfaces.
Root cause: ptm status is not being initialized to “unknown” status when VRF interface is added or changed. The uninitialized value is ‘0’ which is the value for “fail”
Fix: Initialized the ptm status to the correct value.
Donald Sharp [Wed, 4 May 2016 01:04:00 +0000 (01:04 +0000)]
zebra: Fix show vrf and show run to use the zvrf_list
The show vrf and show run commands were iterating
over the vrf_list. Use the zvrf_list instead
so that we can understand the differences
between something configed -vs- created
Ticket: CM-10139 Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com> Reviewed-by: Vivek Venkatraman <vivek@cumulusnetworks.com> Reviewed-by: Don Slice <dslice@cumulusnetworks.com>
Donald Sharp [Mon, 2 May 2016 19:30:55 +0000 (15:30 -0400)]
lib: Rework vrf_get
vrf_get has these possible lookup/creation ways of being called.
name = NULL, vrf_id = VRF_UNKNOWN
Nothing to do here.
name = NULL, vrf_id != VRF_UNKNOWN
Look up the vrf_id in the table. Return that created vrf.
If not found create a struct vrf to hold it properly.
name = <something>, vrf_id = VRF_UNKNOWN
Look up the name in the vrf list, if found return that vrf.
If not found create the vrf and zvrf
name = <something>, vrf_id != VRF_UNKNOWN
Look up the name in the vrf list, if found check to see
if the vrf->vrf_id is VRF_UNKNOWN, if so match up and return
If not found, create the vrf and table entry and return
Ticket: CM-10139 Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com> Signed-off-by: Don Slice <dslice@cumulusnetworks.com> Signed-off-by: Vivek Venkatraman <vivek@cumulusnetworks.com>
vivek [Tue, 3 May 2016 19:10:22 +0000 (12:10 -0700)]
Zebra: Update/fix router_lifetime in IPv6 RAs
BGP Unnumbered relies on IPv6 Router Advertisements (RAs) to advertise our
link-local IPv6 address and learn of the peer's address in order to initiate
the BGP peering. When IPv6 RAs are enabled on an interface, Quagga currently
advertises a non-zero router lifetime which causes hosts receiving the RAs
to install the router as the default router. This may not be desirable in
many situations - the IPv6 RAs may be turned on just to get BGP unnumbered
peering up.
There is a sysctl available to control the host behavior (net.ipv6.conf.all.
accept_ra_defrtr). However, this requires setting on all hosts and this may
mean many hosts, especially if Quagga is run on the hosts.
An alternate solution arrived at was to modify Quagga to advertise a zero
router lifetime, unless a value is specifically set by the operator. This
patch implements this change. The change may not meet a strict interpretation
of the RFC, so it is under HAVE_CUMULUS. When hosts see an IPv6 RA with a
router lifetime of 0, they won't make that router a default router. The
patch also fixes an incorrect check in handling of received RAs which would
have caused us to drop RAs with a lifetime of 0.
Signed-off-by: Vivek Venkatraman <vivek@cumulusnetworks.com> Reviewed-by: Daniel Walton <dwalton@cumulusnetworks.com>
Ticket: CM-9815
Reviewed By: CCR-4611
Testing Done: Manual, bgp-min etc. (defails in defect)
root [Tue, 3 May 2016 17:54:01 +0000 (17:54 +0000)]
zebra: Allow vrfs to be defined and displayed before netlink vrf add
Displays vrfs using the vrf_list rather than the route-nodes. This allows "show vrf"
to display inactive (or not yet active) vrfs. Also, IPv6 static routes are now
allowed to be defined and displayed prior to the netlink vrf add.
Ticket: CM-10139 Signed-off-by: Don Slice Reviewed-by: Donald Sharp
vivek [Mon, 2 May 2016 20:53:38 +0000 (13:53 -0700)]
BGP: Trigger IPv6 router advertisements upon config of unnumbered neighbor
Instead of turning on IPv6 RA on every interface as soon as it has an IPv6
address, only enable it upon configuration of BGP neighbor. When the BGP
neighbor is deleted, signal that RAs can be turned off.
To support this, introduce new message interaction between BGP and Zebra.
Also, take appropriate actions in BGP upon interface add/del since the
unnumbered neighbor could exist prior to interface creation etc.
Only unnumbered IPv6 neighbors require RA, the /30 or /31 based neighbors
don't. However, to keep the interaction simple and not have to deal with
too many dynamic conditions (e.g., address deletes or neighbor change to/from
'v6only'), RAs on the interface are triggered upon any unnumbered neighbor
configuration.
BGP-triggered RAs will cause RAs to be initiated on the interface; however,
if BGP asks that RAs be stopped (upon delete of unnumbered neighbor), RAs
will continue to be exchanged if the operator has explicitly enabled.
Signed-off-by: Vivek Venkatraman <vivek@cumulusnetworks.com> Reviewed-by: Donald Sharp <sharpd@cumulusnetworks.com>
Ticket: CM-10640
Reviewed By: CCR-4589
Testing Done: Various manual and automated (refer to defect)
Donald Sharp [Thu, 28 Apr 2016 00:03:35 +0000 (20:03 -0400)]
debian: Debian fixups
This commit does two things:
1) Fixes package name to have ...+cl3u1
2) Allows the build to determine if we are building
a debian package on a init.d or systemd style system
and to do the right thing.
3) Fixed quagga service file naming
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com> Reviewed-by: Dave Olson <olson@cumulusnetworks.com> Reviewed-by: Don Slice <dslice@cumulusnetworks.com> Reviewed-by: Daniel Walton <dwalton@cumulusnetworks.com>
The JSON outputs of a bunch of BGP commands were broken due to the
addition of VRF support. This fixes them all. Also replaces the use
of "-" in some of the JSON variable names with camel case names.
zebra: Implement recovery for route install failure
Quagga does not have proper recovery for route install failure (in
the kernel). The lack of this may not be a significant issue if the
failure is only an exception. However, the introduction of route
replace presents a new failure scenario which was not there earlier.
Before replace, the update operation involved a delete followed by
add; the failure of add would not leave hanging route entries in the
kernel as they would've got deleted first. With route replace, if
the replace fails, recovery action to delete the route is needed, else
the route remains hanging in the kernel.
In particular, with VRFs and in the presence of ECMP/multipath, a
failure mode exists where Quagga thinks that routes have been cleaned
up and deleted from the kernel but the kernel continues to retain them.
This happens when multiple VRF interfaces are moved from one VRF to
another.
This patch addresses this scenario by implementing proper recovery for
route install failure.
To allow for faster convergence, modify transmission of IPv6 RA so
that on link transitions(link up, change VRF, link add etc.), we
transmit RA fast to ensure faster convergence with BGP Unnumbered.
But we don't enable Fast RA if RA interval is in msecs as we've
fixed the fast RA interval to be 1s. We retransmit RA 4 times, once
each second on link events and when RA is first enabled.
Donald Sharp [Mon, 25 Apr 2016 15:34:35 +0000 (11:34 -0400)]
quagga: Fixup startup to allow consistency between sysV and systemd
We want the ability to start up quagga in a varied set of
environments. This needs to be done in SysV and systemd
startups. As such refactor the code to allow us to
allow end users to easily switch between the two
sysV:
edit the /etc/quagga/daemons file
service quagga [start|stop|reload|restart]
Systemd:
edit the /etc/quagga/daemons file
systemctl [start|stop|reload|restart] quagga
Ticket: CM-10634 Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com> Reviewed-by: Daniel Walton <dwalton@cumulusnetworks.com>
Daniel Walton [Mon, 25 Apr 2016 20:19:08 +0000 (20:19 +0000)]
BGP peers remain in active while rdnbrd is running.
Signed-off-by: Daniel Walton <dwalton@cumulusnetworks.com> Reviewed-by: Donald Sharp <sharpd@cumulusnetworks.com>
Ticket: CM-7789, CM-8806
If the route-map for an "ip import-table" denied a route it only flagged
the nexthop as inactive, it did not actually delete the route. This
breaks all directly connected EBGP peers that peer via IPv4 because NHT
finds this /32 with an inactive nexthop.
Update last reset reason on interface down or neighbor addr loss.
Ticket:
Reviewed By:
Testing Done:
For interface-based peering, we don't update the reset reason to be
interface down. Similarly, we don't update the reason to be loss of
neighbor address (maybe due to RA loss). This patch addresses these
limitations.
Don Slice [Fri, 22 Apr 2016 00:12:26 +0000 (17:12 -0700)]
zebra: Change interface handling so non-vrf aware protocols correctly handle them
Changed interaction between zebra and routing protocols so that they correctly
fill in the vrf_iflist even for vrfs they're not responsible for. In that way,
when they get callbacks from zebra they can correctly understand whether they need
to create them or not.
Ticket: CM-10427 Signed-off-by: Don Slice
Reviewed-by:
Addition on hidden command "bfd multihop/singlehop" and "ptm-enable" per interface command
CM-10435
Issue: IBGP BFD sessions are created as multi-hop even though peer is single-hop away. This is causing an interop issue with ICOS.
Root Cause: By design all IBGP peers are registered with BFD as multi-hop.
Fix:
• Changed the default behavior of always treating IBGP BFD sessions as mult-hop. shared_network variable is used to determine whether the IBGP peer is single hop or multi-hop away. The logic for determining whether EBGP peer is single hop or multi-hop has not been changed.
• Since the default behavior has been changed, it will cause interop issues between 2.5 and 3.0 IBGP BFD sessions. A new hidden command “bfd multihop/singlehop” has been introduced to overcome the interop issues.
CM-10260
Issue: “Unable to connect to socket” message keeps getting logged when ptmd process doesn’t exist.
Root Cause: BFD clients (bgpd, ospfd and ospf6d) during initialization try to register with BFD/PTM by default. This results in continuous logging If PTM does not exist since there is no max on number of retries.
Fix:
• Stop the retries to connect to PTM after max reconnect timer of 5 mins is reached.
• Added zebra debug event wrapper to message logging to prevent it from showing by default.
CM-4541
Issue: Addition of a new command "ptm-enable" or "no ptm-enable" per interface to enable/disable PTM link status checks for an interface.
Fix: Currently there is only one ptm-enable global command that enables/disables PTM status updates for all interfaces. This new command will give the handle to individually stop interface from reacting on the PTM status updates.
• by default interface uses the ptm-enable global configuration
• "no ptm-enable" on an interface will disable PTM status updates from taking affect for that interface. This can bring the interface up if it was brought down due to PTM status update.
• "ptm-enable" on an interface will cause the interface to fallback to the global ptm-enable configuration value and will bring the interface up or down based on the last stored PTM status update if global ptm is enabled.
Ticket: CM-10435, CM-10260 and CM-4541 Signed-off-by: Radhika Mahankali Reviewed-by: Donald Sharp, Kanna Rajagopal
Don Slice [Thu, 21 Apr 2016 16:15:07 +0000 (16:15 +0000)]
zebra: Only create vrf route-node if in the kernel
Changed vrf_get to only create a route-node if the kernel has enabled the vrf,
supplying a table-id. If the quagga configuration contains vrfs that have not
yet been enabled by the kernel, the vrf is created with a vrf_id of VRF_UNKNOWN.
These vrfs are added to the vrf_list so they contain a zvrf and configuration,
but the route-node is not created until the kernel has signalled that the vrf
has been defined and enabled.
Ticket: CM-10481 Signed-off-by: Don Slice Reviewed-by: Donald Sharp
Donald Sharp [Thu, 21 Apr 2016 02:08:49 +0000 (22:08 -0400)]
bgp: Anti-Yammer Patch
When you shutdown interfaces with ifdown -a -X eth0
bgp would still attempt to talk to it's configured
neighbors but since the interface is down it would
just complain and complain. Now that we have
somewhat aggressive timers the error message
really starts to show up.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com> Reviewed-by: Daniel Walton <dwalton@cumulusnetworks.com>
Donald Sharp [Wed, 20 Apr 2016 20:12:29 +0000 (16:12 -0400)]
zebra: Fix zebra_rnh_register crash
Zebra is crashing inside of zserv_rnh_register when it attempts to
lookup a vrf that was just deleted:
Imagine this series of events:
Pre (A): ifdown -a -X eth0
(A) zebra notification from kernel that vrf is goneroo
(B) zebra notifies all daemons
(C) bgpd is churning because we have been removing interfaces and we
have an new path and it hasn't handled the vrf goneroo event yet from
zebra so it sends to zebra a new rnh with an old vrf_id.
(D) zebra attempts to lookup the zvrf and crashes because of pointer
dereference.
zebra handles all callbacks in one function. Convert that function to
check to see if we have a valid zvrf. If so make the callback
Ticket: CM-10482 Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com> Reviewed-by: Don Slice <dslice@cumulusnetworks.com> Reviewed-by: Vivek Venkatraman <vivek@cumulusnetworks.com>
Change-Id: Iff33d70089d1393bf3e9c757d9e9faf134699121 Signed-off-by: kitty <khiruthigai.balasubramanian@hpe.com> Tested-by: NetDEF CI System <cisystem@netdef.org> Acked-by: Donald Sharp <sharpd@cumulusnetworks.com>
Donald Sharp [Fri, 15 Apr 2016 13:15:21 +0000 (09:15 -0400)]
vtysh: Allow file read in to continue in more cases
When a duplicate command is read in from a file,
there are cases where daemons return CMD_WARNING
this causes the command to not be send to subsuquent
daemons( if any ).
Allow the read in of commands to continue in this
situation.
Ticket: CM-10393 Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com> Reviewed-by: Don Slice <dslice@cumulusnetworks.com>
Donald Sharp [Fri, 15 Apr 2016 17:09:58 +0000 (13:09 -0400)]
quagga: Check for existence of IFLA_INFO_SLAVE_KIND
IFLA_INFO_SLAVE_KIND is a new type of netlink message
If the kernel makes it available compile in support
else we'll just silently do the right thing.
Additionally reduce the test cases for netlink by 1 Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com> Reviewed-by: David Ahern <dsa@cumulusnetworks.com> Reviewed-by: Don Slice <dslice@cumulusnetworks.com> Reviewed-by: Vivek Venkatraman <vivek@cumulusnetworks.com>
Donald Sharp [Fri, 15 Apr 2016 01:46:44 +0000 (21:46 -0400)]
lib, bgpd: Refactor vrf handling through zclient
Protocols receive zclient vrf creation events from zebra.
This data was being handed to the protocol to decode and
then to hand back to zclient to create the vrf to then
handle appropriately. This is a bad idea.
Modify the code such that when zclient.c receives a vrf
event from zebra that it decodes the data and just creates
the vrf. Individual protocols just need to handle the
appropriate vrf events.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com> Reviewed-by: Daniel Walton <dwalton@cumulusnetworks.com> Reviewed-by: Don Slice <dslice@cumulusnetworks.com>
Donald Sharp [Wed, 13 Apr 2016 16:21:47 +0000 (12:21 -0400)]
zebra: Refactor struct zebra_t
We were including 'extern struct zebra_t zebrad;' all
over the place. This made no sense. Refactor
into zserv.h where the definition was and remove resulting
unnecessary code.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com> Reviewed-by: Don Slice <dslice@cumulusnetworks.com> Reviewed-by: Vivek Venkatraman <vivek@cumulusnetworks.com>
Donald Sharp [Wed, 13 Apr 2016 14:06:36 +0000 (10:06 -0400)]
lib, zebra: Rework vrf_add_update
The vrf_add_update function does not need to exist.
Move it's constituent parts into the appropriate
vrf_create/vrf_enable functionality as well as
move the zebra_vrf_add_update() function call
into zebra_vrf_enable()
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com> Reviewed-by: Don Slice <dslice@cumulusnetworks.com> Reviewed-by: Vivek Venkatraman <vivek@cumulusnetworks.com>
Daniel Walton [Thu, 14 Apr 2016 18:16:43 +0000 (18:16 +0000)]
quagga: "set community x:y" needs bounds checking
Signed-off-by: Daniel Walton <dwalton@cumulusnetworks.com> Reviewed-by: Donald Sharp <sharpd@cumulusnetworks.com>
Ticket: CM-10002
superm-redxp-05# conf t
superm-redxp-05(config)# route-map FOO permit 10
superm-redxp-05(config-route-map)# set community ?
AA:NN Community number in AA:NN format (where AA and NN are <0-65535>) or local-AS|no-advertise|no-export|internet or additive
none No community attribute
superm-redxp-05(config-route-map)# set community 2:2
superm-redxp-05(config-route-map)# set community 2:70000
% Malformed communities attribute
superm-redxp-05(config-route-map)# set community 70000:2
% Malformed communities attribute
superm-redxp-05(config-route-map)#
projects / matthieu / frr.git / log