Chirag Shah [Wed, 22 Feb 2017 15:28:36 +0000 (07:28 -0800)]
pimd: Nexthop tracking support
Add pim Nexthop tracking feature 1st part where, specific RP or Source address (unicast address)
register with Zebra. Once nexthop update received from Zebra for a given address, scan RP or upstream
entries impacted by the change in nexthop.
Reviewed By: CCR-5761, Donald Sharp <sharpd@cumulusnetworks.com>
Testing Done: Tested with multiple RPs and multiple *,G entries at LHR.
Add new Nexthop or remove one of the link towards RP and verify RP and upstream nexthop update.
similar test done at RP with multiple S,G entries to reach source.
Signed-off-by: Chirag Shah <chirag@cumulusnetworks.com>
anuradhak [Thu, 9 Mar 2017 19:42:55 +0000 (11:42 -0800)]
pimd: display reg-state and join-state info in the pim_upstream output
Changed the state field in the "sh ip pim upstream" output to include
register and join state info as a comma separated value. Register info
is supressed if reg-state=NoInfo.
Sample output:
=============
root@fhr:/home/cumulus# net show pim upstream
Iif Source Group State Uptime JoinTimer
RSTimer KATimer RefCnt
swp1 33.1.1.1 239.1.1.2 J,RegP 00:00:18 --:--:--
00:00:44 00:03:24 2
root@fhr:/home/cumulus#
root@rp:/home/cumulus# net show pim upstream
Iif Source Group State Uptime JoinTimer
RSTimer KATimer RefCnt
lo * 239.1.1.2 J 00:02:08 00:00:52
--:--:-- --:--:-- 1
swp1 33.1.1.1 239.1.1.2 J 00:00:16 00:00:11
--:--:-- 00:03:26 1
root@rp:/home/cumulus#
anuradhak [Thu, 9 Mar 2017 18:47:50 +0000 (10:47 -0800)]
pimd: simplify pim upstream state transitions
This is another follow-up change to the reg-state and up-join-state
separation. The upstream join state machine can now respond to
JoinDesired macro changes independent of router role.
I have also dropped the PRUNE state from the upstream-join-state
enumeration. RFC4601 only defines JOINED and NOTJOINED states. And PRUNE
can really be replace by NOTJOINED.
Signed-off-by: Anuradha Karuppiah <anuradhak@cumulusnetworks.com> Reviewed-by: Donald Sharp <sharpd@cumulusnetworks.com>
Ticket: CM-14700
Testing Done: Register state machine in FHR only, combined FHR-RP and
FHR-RP-LHR/all-in-one setups. Also ran pim-smoke.
anuradhak [Thu, 9 Mar 2017 17:52:59 +0000 (09:52 -0800)]
pimd: add new/distinct enumeration for pim register state
With the separation of register-state and upstream-join-state we no
longer need an enumeration that covers both states. This commit includes
the following -
1. Defined new enumeration for reg state (this 1:1 with RFC4601).
2. Dropped JOIN_PENDING enum value from upstream join state. RFC4601
only define two values NOT_JOINED and JOINED for this state.
Signed-off-by: Anuradha Karuppiah <anuradhak@cumulusnetworks.com> Reviewed-by: Donald Sharp <sharpd@cumulusnetworks.com>
Ticket: CM-14700
Testing Done: Verified register setup manually and ran pim-smoke
anuradhak [Wed, 8 Mar 2017 17:29:40 +0000 (09:29 -0800)]
pimd: Separate the register and upstream join states on the FHR
On the FHR upstream-join-state is not particularly relevant as we
don't need to send upstream JPs for the SG. So that field was being
overloaded with the register-state. However some of the events that
triggered changes to the JoinDesired macro were accidentally overwriting
the state with join info (instead of treating it as register info)
confusing the register state machine.
To make the PIM RFC macros' implemention simple I have separated out
the register-state. And upstream->state now solely describes the
upstream-join-state independent of the role of the PIM router.
Signed-off-by: Anuradha Karuppiah <anuradhak@cumulusnetworks.com> Reviewed-by: Donald Sharp <sharpd@cumulusnetworks.com>
Ticket: CM-14700
Testing Done: verified pim-register state-machine with separate and
combined FHR/RP routers. Also ran pim-smoke.
Donald Sharp [Fri, 10 Mar 2017 00:37:23 +0000 (19:37 -0500)]
zebra: Fix specific prefix handling
Suppose we are handling the process_workq and either a new static
route is installed or a Routing Protocol installs a new route.
We will call evaluate_rnh with a specific prefix. We might
have a situation where we clear the NHC flag prematurely.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
The patch actually made the situation worse since the return value from
cmd_complete_command_real() was now inconsistently allocated from
different memory stat pools.
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
Donald Sharp [Tue, 7 Mar 2017 20:13:04 +0000 (15:13 -0500)]
zebra: Notify all nexthops that we've changed
Zebra when it was scanning the tree would unset NEXTHOPS_CHANGED
after the first notification. If the route we are notifying because
of covers multiple interesting nexthops then we would be unable
to know that we need to notify for that one as well because of
the flag removal.
Ticket: CM-15157 Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
David Lamparter [Wed, 8 Mar 2017 15:13:12 +0000 (16:13 +0100)]
*: fix some user-visible Quagga remnants
(Note: the allow_delete thing is called "zebra" on the commandline
because that's the clearest context there, while it is called "FRR" in
the CLI because that's considerably less confusing in a vtysh env.)
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
Timo Teräs [Tue, 14 Feb 2017 11:07:39 +0000 (13:07 +0200)]
distro/redhat: package nhrpd
Signed-off-by: Timo Teräs <timo.teras@iki.fi>
[DL: adapted for FRR, changed port number 2612->2610] Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
In file included from netlink_gre.c:15:0:
/usr/include/linux/ipv6.h:19:8: error: redefinition of 'struct in6_pktinfo'
struct in6_pktinfo {
^
In file included from netlink_gre.c:10:0:
/usr/include/netinet/in.h:536:8: note: originally defined here
struct in6_pktinfo
^
In file included from netlink_gre.c:15:0:
/usr/include/linux/ipv6.h:24:8: error: redefinition of 'struct ip6_mtuinfo'
struct ip6_mtuinfo {
^
In file included from netlink_gre.c:10:0:
/usr/include/netinet/in.h:543:8: note: originally defined here
struct ip6_mtuinfo
So instead of libc's netinet/in.h include kernel's linux/in.h
and the add sys/socket.h for struct sockaddr since it does not
seem to be defined in kernel headers.
Signed-off-by: Timo Teräs <timo.teras@iki.fi> Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
Timo Teräs [Thu, 19 Jan 2017 15:27:01 +0000 (17:27 +0200)]
nhrpd: implement next hop resolution protocol
This provides DMVPN support and integrates to strongSwan. Please read
README.nhrpd and README.kernel for more details.
[DL: cherry-picked from dafa05e65fe4b3b3ed5525443f554215ba14f42c]
[DL: merge partially resolved, this commit will not build.] Signed-off-by: Timo Teräs <timo.teras@iki.fi> Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
Donald Sharp [Mon, 6 Mar 2017 13:16:43 +0000 (08:16 -0500)]
bgpd, zebra: Add ifindex to NEXTHOP_TYPE_IPV4
When passing up NEXTHOP_TYPE_IPV4 pass up the ifindex as well
Zebra already stores this data by passing it up PIM will be
able to use NEXTHOP_TYPE_IPV4 without having to do a recursive
lookup.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com> Reviewed-by: Don Slice <dslice@cumulusnetworks.com> Reviewed-by: Chirag Shah <chirag@cumulusnetworks.com>
Renato Westphal [Fri, 3 Mar 2017 20:50:22 +0000 (17:50 -0300)]
ldpd: always check if the received labels are valid
We were doing some sanity checks only for labels of Label Mapping
messages. Now do the same checks for labels of Label Release and Label
Withdraw messages as well.
While here, plug a small memleak in the error path of recv_labelmessage().
Renato Westphal [Fri, 3 Mar 2017 20:50:22 +0000 (17:50 -0300)]
ldpd: send VPLS MAC withdrawals
RFC 4762 says that MAC address withdrawal messages can be used to
improve convergence time in VPLS networks. This patch makes ldpd send
MAC withdrawals whenever a non-pseudowire interface pertaining to a
VPLS goes down. The processing of received MAC withdrawals will be
implemented later.
Renato Westphal [Fri, 3 Mar 2017 20:50:22 +0000 (17:50 -0300)]
ldpd: fix parsing of optional tlvs in address messages
We were aborting the session upon receipt of MAC Address Withdrawal
messages. Now make the parser aware that optional TLVs are possible in
address messages.
Renato Westphal [Fri, 3 Mar 2017 20:50:22 +0000 (17:50 -0300)]
ldpd: implement RFC 5561 (LDP Capabilities)
This patch per-se doesn't introduce any useful functionality, but prepares
the ground for new enhancements to ldpd (i.e. implementation of new RFCs
that make use of LDP capabilities).
Renato Westphal [Fri, 3 Mar 2017 20:50:22 +0000 (17:50 -0300)]
ldpd: implement support for PWid group wildcards
This was missing from our original RFC 4447 VPLS implementation. Now
ldpd understands group wildcards as mandated by the RFC, but we still
don't send them ourselves. I can't see any case in which sending a group
wildcard would be useful, but nonetheless this patch provides a function
called lde_send_labelwithdraw_pwid_wcard() which is ready to be used in
the future anytime we feel like it might be useful.
Renato Westphal [Fri, 3 Mar 2017 20:50:22 +0000 (17:50 -0300)]
ldpd: fix processing of Label Withdraw messages
Whenever we receive a Label Withdraw message with an optional Label
TLV, we should check if this label matches the label previously
received from this neighbor for this FEC. If they don't match then we
shouldn't uninstall the previous label from the kernel. This fixes a
misinterpretation from the "Receive Label Withdraw" algorithm described
in the A.1.5 section of RFC 5036.
Also, simplify the check of pending withdraws in lde_check_release()
and lde_check_release_wcard().
Renato Westphal [Fri, 3 Mar 2017 20:50:22 +0000 (17:50 -0300)]
ldpd: the PW Status is an unknown TLV
Without this fix, any LDP speaker that doesn't implement RFC 4447 will
shut down the session upon receipt of a PWid Label Mapping (unless the
use of the PW-Status TLV is disabled via configuration).
Renato Westphal [Fri, 3 Mar 2017 20:50:22 +0000 (17:50 -0300)]
ldpd: send correct status code on error condition
The Unknown TLV status code is reserved for cases where we don't know
how to process a given TLV and its Unknown TLV bit is not set.
In the case of Address Messages, the Address List TLV is mandatory and
should appear before any optional TLV in the message. If that doesn't
happen the correct status notification to send is "Missing Message
Parameters" (non-fatal error).
Also, add a missing htons when creating an Address List TLV. Since the
value of TLV_TYPE_ADDRLIST is 0x0101 this missing htons wasn't noticed
earlier.
Renato Westphal [Fri, 3 Mar 2017 20:50:22 +0000 (17:50 -0300)]
ldpd: kill send_notification_nbr()
Be more clever and trigger the PDU SENT event inside send_notification()
when tcp->nbr is set. This way we can eliminate send_notification_nbr()
and always use send_notification() instead.