Lu Feng [Wed, 25 Jun 2014 07:43:15 +0000 (07:43 +0000)]
ripd: use only one constant for derivation
RIP_MAX_RTE is defined in ripd.h as 25 but is in fact the
result of a formula. More over it is not used in the code:
the code itself includes the fomula. This makes it un-clear
for maintenance.
Signed-off-by: Feng Lu <lu.feng@6wind.com> Reviewed-by: Alain Ritoux <alain.ritoux@6wind.com> Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
(cherry picked from commit 342a31bfda21616209366679ac522471e5772a2f)
Paul Jakma [Thu, 20 Aug 2015 20:30:17 +0000 (21:30 +0100)]
build: Remove the old PIC/PIE patch, let libtool sort it out
* Remove the old change from '08 to add in PIE arguments at automake level.
Versions of libtool since then know how to deal with -fpie and do the right
thing according to whether its building shared or executable objects.
So just pass '-fpie' as CFLAG and let libtool do its thing.
Donald Sharp [Thu, 29 Oct 2015 13:35:12 +0000 (06:35 -0700)]
pimd: Create special pimreg interface
The linux kernel wants a pimreg vif device. The pimd
code wants a 'struct interface *' for anything it works
with. Since the pimreg vif device is not a real linux
device that zebra knows about. Cheat by creating
a pimreg interface pointer and setup the code to
properly be able to handle the registration of the vif
device.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Donald Sharp [Wed, 28 Oct 2015 17:14:06 +0000 (10:14 -0700)]
pimd: Add New Source type for where a (S,G) mroute is learned
Add Source type for (S,G) mroute. This will allow us to know that
a (S,G) route came from an actual Source( ie the kernel called us
back with information about a multicast packet it received with
no mroute for it ).
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Donald Sharp [Fri, 23 Oct 2015 14:10:30 +0000 (07:10 -0700)]
pimd: Add some code to intelligently handle WHOLEPKT generation
When we get a NOCACHE call from the kernel, there is
no point generating a mcast route for the packet if
there is no RP configured, or if PIM-SSM is configured
on the interface.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Donald Sharp [Fri, 23 Oct 2015 12:58:39 +0000 (05:58 -0700)]
pimd: Add some debug code to unknown packet upcalls
When receiving data from the kernel from the kernel socket,
some calls that are received are not known what they are.
Provide some more debug code to handle appropriately
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Donald Sharp [Tue, 20 Oct 2015 15:36:37 +0000 (08:36 -0700)]
pimd: Start handling of pim REGISTER packet type
This code starts the handling of the pim register type. No guarantees that
it works correctly, just that it compiles and the start of the code is in there.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Donald Sharp [Tue, 20 Oct 2015 15:26:24 +0000 (08:26 -0700)]
pimd: Cause NOCACHE event to create WHOLEPKT events for pimd
pimd needs the ability to send the multicast packet to the RP.
This code causes the incoming unknown multicast packet to
be send to pimd so it can be sent as a REGISTER packet towards
the RP.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Donald Sharp [Tue, 20 Oct 2015 13:00:02 +0000 (06:00 -0700)]
pimd: Fixup kernel callbacks to handle them better
This patch sets up the handling of the 3 basic kernel callbacks:
IGMPMSG_WRONGVIF - When a multicast message comes in the wrong vif
IGMPMSG_NOCACHE - There is no multicast route associated with a received(S,G)
IGMPMSG_WHOLEPKT - There is no outgoing interface for a packet.
The code's debugs are cleaned up to be covered by debug statements
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
This crept in as part of the MRIB improvements and I missed the compiler
warning between other noise. Unfortunately, printing an uninitialised
variable can in fact make zebra crash, so this is not trivial.
Fixes: 3b02fe8 ("zebra: add "show ip rpf" to get result of RPF lookup") Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
Donald Sharp [Wed, 21 Oct 2015 20:13:51 +0000 (16:13 -0400)]
pimd: Limit pim hello log messages
pimd was outputting allot of data surrounding pim hello packets.
In addition the debugging was inconsistent and not all turned
on via 'debug pim packet hello'.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Nicolas Dichtel [Wed, 16 Sep 2015 07:42:36 +0000 (09:42 +0200)]
bgpd/pimd: fix zAPI parsing
Commit c99f3481a598 has changed the API. Now, the vrfid has been added in
the header, thus we must read it before parsing the rest of the message.
To ease code maintenance, let's add a new function to read a zAPI header.
Fixes: c99f3481a598 ("*: add VRF ID in the API message header") Reported-by: Martin Winter <mwinter@opensourcerouting.org> Signed-off-by: Nicolas Dichtel <nicolas.dichtel@6wind.com> Acked-by: Donald Sharp <sharpd@cumulusnetworks.com> Tested-by: Martin Winter <mwinter@opensourcerouting.org>
Donald Sharp [Fri, 21 Aug 2015 23:35:27 +0000 (19:35 -0400)]
pimd: Create ability to modify hell and hold timers per interface
Create new per interface command:
'ip pim hello <1-180> {<1-180>}'
The first number is the Hello Timer for this interface
The second number is the Hold Timer to pass to neighbors on this interface.
The second number is optional.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Donald Sharp [Thu, 2 Jul 2015 13:53:59 +0000 (09:53 -0400)]
pimd: Change ioctl call failure from vty_out to zlog_warn
The command 'show ip multicast' when run, iterates over all interfaces
on the router, if you do not have pim configured on that interface
it would generate an error message:
Donald Sharp [Thu, 2 Jul 2015 17:22:49 +0000 (13:22 -0400)]
pimd: Ensure new generation_id is different from previous
The RFC states that an interfaces generation_id must be changed
if it experiences an if down. From 4.3.1:
The GenID option contains a randomly generated
32-bit value that is regenerated each time PIM forwarding is started
or restarted on the interface, including when the router itself
restarts.
Since we are only grabbing a new generation_id without comparing
it to the previous generation_id, it is possible that random
can generate the exact same number.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Donald Sharp [Tue, 16 Jun 2015 20:19:56 +0000 (13:19 -0700)]
pimd: Stop DR election on every hello
The DR election is occurring on every hello received.
This is because the hello receive packet returns a 0
for any successfully received packet. PIMD then looked
at the 0 returned and did a DR election.
Code was inspected for the cases where DR should happen:
(A) Interface ip address change
(B) DR priority in hello packet changes
(C) Received a new neighbor on an interface
(D) Neighbor timer pops.
Each of these initiate a DR election in the code currently.
Testing was initiated on a pim network:
tor-11# show ip pim designated-router
NonPri: Number of neighbors missing DR Priority hello option
As you can see Elections == 2. This is because pimd performs
an election on (A) and (C) above. I see no need to modify
(A) to check if we have any knowledge of the interface before
this call.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Donald Sharp [Fri, 19 Jun 2015 00:01:34 +0000 (17:01 -0700)]
pimd: Fix first DR Election
The function pim_neighbor_new caused the dr election before
the addition of the neighbor to the pim_ifp->pim_neighbor_list,
in pim_neighbor_add, which is needed to properly elect the
correct DR.
Move the dr_election and hello trigger till after the addition
to the list.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Donald Sharp [Fri, 19 Jun 2015 01:14:20 +0000 (18:14 -0700)]
pimd: Add ability to set DR Priority for an interface
From RFC 4601, Section 4.3.1:
The DR_Priority Option allows a network administrator to give
preference to a particular router in the DR election process by
giving it a numerically larger DR Priority. The DR_Priority Option
SHOULD be included in every Hello message, even if no DR Priority is
explicitly configured on that interface. This is necessary because
priority-based DR election is only enabled when all neighbors on an
interface advertise that they are capable of using the DR_Priority
Option. The default priority is 1.
This modification allows the setting of the DR Priority on a per
interface basis.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
pimd: add support for configuring multicast static routes
Hi,
This patch adds the ability to configure multicast static routes
directly into pimd. Two source files are introduced to implement the new
feature in addition to changes to existing files.
Here is how it can be used the CLI:
interface <incoming interface>
ip mroute <outgoing interface> <group addr> #
for asm
or ip mroute <outgoing interface> <group addr> <source> # for ssm
Please let me know if you have any questions or concerns,
Regards,
Jafar
Acked-by: Donald Sharp <sharpd@cumulusnetworks.com>
Donald Sharp [Sat, 30 May 2015 22:57:54 +0000 (18:57 -0400)]
Removal of 'show ip mroute'
The 'show ip mroute' in zebra_vty.c collided with the
'show ip mroute' command in pim_cmd.c. The 'show ip rpf'
command is functionally equivalent to the zebra_vty.c
'show ip mroute'. Therefore remove the 'show ip mroute' command
in zebra_vty.c.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Donald Sharp [Sat, 13 Jun 2015 00:47:26 +0000 (17:47 -0700)]
pimd assert when no route to source from a new igmp join
When pim_upstream_new is called the code looks up the nexthop.
If there is no route to the source, the code silently ignored
the error returned. When the nexthop lookup fails don't create
the 'struct pim_stream *' to return.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Donald Sharp [Fri, 5 Jun 2015 19:15:44 +0000 (12:15 -0700)]
pim_mroute.h has a different version of code than linux/mroute.h provides
linux/mroutes.h and pim_mroute.h both have copies of the same structures.
This is causing failures in setsockopt(..., MRT_ADD_MFC,...) because
of data structure incompatibilities between the kernel and what
pim_mroute.h was providing. Modify the code to check for mroute.h
and include it if necessary. I did not modify the non linux/mroute.h
path because I do not have other systems to test on easily.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
David Lamparter [Wed, 4 Feb 2015 06:01:14 +0000 (07:01 +0100)]
pimd: merge pimd as of 2015-01-19
Welcome pimd to the Quagga daemon zoo!
This is a merge of commit 77ae369 ("pimd: Log ifindex found for an
interface when zebra lib reports a new connected address."), with
the intermediate "reconnect" changes removed (c9adf00...d274381). d274381 is replaced with b162ab7, which includes some changes. In
addition, 4 reconnect-related changes and 1 cosmetic one have been
bumped out.
The rebase command used to produce the branch that is merged here is:
git rebase --onto b162ab7c9adf0077ae369
Note that 3 patches had their author rewritten from
"Anonymous SR#108542 <>" (which is not a valid git author ID)
to: "Savannah SR#108542 <nbahr@atcorp.com>" (which is the e-mail address
listed in the associated Savannah ticket)
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
David Lamparter [Tue, 27 Jan 2015 19:24:15 +0000 (20:24 +0100)]
zebra: mark multicast commands experimental
depending on feedback from actually having these commands in a released
version, we may want to adjust them. Thus, mark them as experimental so
users are aware of this.
Cc: Everton Marques <everton.marques@gmail.com> Cc: Balaji G <balajig81@gmail.com> Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
David Lamparter [Thu, 22 Jan 2015 18:12:35 +0000 (19:12 +0100)]
zebra: add "show ip rpf" to get result of RPF lookup
Checking what route exactly a RPF lookup for a given source uses is
essential for an administrator to debug multicast routing issues. This
command provides exactly that, using the multicst RPF lookup function
and printing out its result to the CLI.
Cc: Everton Marques <everton.marques@gmail.com> Cc: Balaji G <balajig81@gmail.com> Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
David Lamparter [Tue, 6 Jan 2015 18:53:24 +0000 (19:53 +0100)]
zebra: make MRIB lookup behaviour switchable
depending on the usage scenario (and availability of multitopology IGP
protocols, which is currently zero in Quagga), different approaches of
Multicast RPF lookups are useful.
Reference behaviours from commercial vendors are urib-only/mrib-only
(Juniper, depending on inet.2 availability) and lowest-distance (Cisco).
As we are currently without MT IGP support, mrib-first seems the most
useful default for Quagga.
Cc: Everton Marques <everton.marques@gmail.com> Cc: Balaji G <balajig81@gmail.com> Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
David Lamparter [Thu, 22 Jan 2015 18:09:36 +0000 (19:09 +0100)]
zebra: return route_node from rib_match_ipv4_safi
The multicast code needs to know the route_node in addition to the rib
entry in order to perform distance or prefix-length comparisons. Add it
as optional "out" pointer parameter.
Cc: Everton Marques <everton.marques@gmail.com> Cc: Balaji G <balajig81@gmail.com> Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
David Lamparter [Mon, 12 Jan 2015 06:05:06 +0000 (07:05 +0100)]
zebra: dummy kernel "install" multicast routes
This is a followup to 9511633 ("zebra: MBGP routes should not be
installed in the kernel"), which was correct in disabling MRIB routes
being installed in the kernel, yet broke the MRIB since now routes were
never marked as active.
Hence, push down the check into the kernel install functions, so that
the routes are still marked active. At the same time, the FPM calls get
a check each since otherwise we'd bump the FPM interface on MRIB
updates.
Fixes: 9511633 ("zebra: MBGP routes should not be installed in the kernel") Cc: Everton Marques <everton.marques@gmail.com> Cc: Balaji G <balajig81@gmail.com> Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
David Lamparter [Thu, 22 Jan 2015 18:03:53 +0000 (19:03 +0100)]
zebra: fix optional distance on static mrib route
Unfortunately, the quagga CLI parser doesn't support [<1-255>]. Fix by
working around with an alias.
Replaces the following commits:
- zebra: mrib: [no] ip mroute - require distance.
- zebra: mrib: [no] ip mroute - make distance optional.
(Rewritten as alias)
Cc: Everton Marques <everton.marques@gmail.com> Cc: Balaji G <balajig81@gmail.com> Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
With the MRIB being independent from the Unicast RIB, there's currently
now way to add static routes to the MRIB. Address that by adding a
separate set of commands for MRIB static routes.
Combines these original patches:
- zebra: mrib: ip mroute command to add unicast route to MRIB for multicast RPF.
- zebra: mrib: no ip mroute: Fix removal of static multicast RPF route.
- zebra: mrib: remove unused static_add/delete_ipv4
- zebra: Cleanups to zebra_rib.
- pimd: Merge pim-only branch.
Cc: Everton Marques <everton.marques@gmail.com> Cc: Balaji G <balajig81@gmail.com> Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
This adds a new zapi call "ZEBRA_IPV4_NEXTHOP_LOOKUP_MRIB" performing a
Multicast RPF lookup for a given source. Details of the lookup
behaviour are left to the zebra side of things.
Note: this is non-reactive, as in, only delivers a snapshot of the state
at a particular point in time. There's no push notification of changes
happening to the RIB.
This combines the following 3 original patches:
- zebra: add zsend_ipv4_nexthop_lookup_mrib()
- zserv: Query mrib (SAFI_MULTICAST).
- zebra: Cleanups to zebra_rib.
Cc: Everton Marques <everton.marques@gmail.com> Cc: Balaji G <balajig81@gmail.com> Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
David Lamparter [Thu, 22 Jan 2015 18:02:13 +0000 (19:02 +0100)]
zebra: identify MRIB on debug messages
since the same code handles both URIB and MRIB, the debug messages can
get rather confusing if the RIB isn't identified. Mark the MRIB in
debug messages so we can distinguish that.
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
David Lamparter [Thu, 24 Apr 2014 18:22:53 +0000 (20:22 +0200)]
zebra: factor out rib debug logs
Introduces a logging function that takes a struct route_node * argument,
and prefixes log output with that node's prefix. While this removes
some duplication, it will also later be useful for srcdest route nodes.
Behaviour before and after the patch should be exactly identical.
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
vivek [Mon, 23 May 2016 16:46:14 +0000 (09:46 -0700)]
zebra: Ensure IPv6 RA configuration is displayed correctly
IPv6 RAs on an interface can be enabled either by the operator or internally
due to the configuration of a BGP unnumbered neighbor. Ensure that this is
displayed in the configuration correctly.
Signed-off-by: Vivek Venkatraman <vivek@cumulusnetworks.com> Reviewed-by: Donald Sharp <sharpd@cumulusnetworks.com>
Ticket: CM-11076
Reviewed By: CCR-4770
Testing Done: Manual; also verified by defect submitter.
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.
Donald Sharp [Sun, 15 May 2016 17:33:15 +0000 (13:33 -0400)]
lib: Fix some more compiler warnings
Three different changes:
a) in nexthop.c we have an actual bug, we've rearranged
the enumerated types and the list of enums has changed, we
were displaying the wrong nexthop information.
b) Remove some dead code from sockunion.h
c) '\0' evaluates to 0 which is NULL. vector_set takes
a pointer.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com> Reviewed-by: Daniel Walton <dwalton@cumulusnetworks.com>