Renato Westphal [Tue, 28 Mar 2017 00:39:27 +0000 (21:39 -0300)]
doc: minor tweaks in the build instructions
* ldpd is built by default in all platforms, it's not necessary to
provide --enable-ldpd anymore;
* Remove comment about ldpd not being tested on OpenBSD, it works very
well on this platform;
* Provide instructions to enable MPLS forwarding in OpenBSD.
Renato Westphal [Mon, 27 Mar 2017 23:14:09 +0000 (20:14 -0300)]
ldpd: replace all occurrences of '\n' with VTY_NEWLINE
The format of the terse output of several ldpd's show commands was copied
from the OpenBSD's ldpctl(8) control program. In the process of doing
that I forgot to replace the occurrences of '\n' with VTY_NEWLINE.
Renato Westphal [Sat, 18 Mar 2017 20:05:35 +0000 (17:05 -0300)]
ldpd: change the sorting algorithm of adjacencies
Now the "show mpls ldp discovery" command will display all LDP
adjancencies sorted by address family, neighbor ID and then type (link
or targeted).
Example:
vtysh# show mpls ldp discovery
AF ID Type Source Holdtime
ipv4 3.3.3.3 Link rt2-eth1 15
ipv4 3.3.3.3 Link rt2-eth2 15
ipv4 4.4.4.4 Link rt2-eth1 15
ipv6 1.1.1.1 Link rt2-eth0 15
ipv6 3.3.3.3 Link rt2-eth1 15
ipv6 3.3.3.3 Link rt2-eth2 15
ipv6 4.4.4.4 Link rt2-eth1 15
ßingen [Mon, 20 Mar 2017 14:34:49 +0000 (15:34 +0100)]
Implement generic label manager
Label Manager allows to share MPLS label space among different
daemons. Each daemon can request a chunk of consecutive labels and
release it if it doesn't need them anymore. Label Manager stores the
daemon protocol and instance to identify the owner client. It uses them
to perform garbage collection, releasing all label chunks from a client
when it gets disconnected or reconnected.
Additionally, every client can request that the chunk is never garbage
collected. In that case client has the responsibility to release
non-used labels.
Zebra can host the label manager itself (if no -l param is provided) or
connect to an external one using zserv/zclient (providing its address
with -l param).
Client code is in lib/zclient.c, but currently only LDP is using it.
TODO: Allow for custom ranges requests, i.e., specify the start label
besides the chunk.
TODO: Release labels from LDP.
Renato Westphal [Fri, 17 Mar 2017 18:41:04 +0000 (15:41 -0300)]
ldpd: remove pseudowire LSP check
In order to bring a pseudowire up, we must make sure that there's at
least one LSP available to its remote end (otherwise the labeled frames
from the CEs wouldn't reach their destination). We were doing this
check in ldpd, but doing so is very limiting because it doesn't consider
other types of LSPs that might be available (static LSPs, RSVP-TE, SR,
etc). Thus remove this check from the l2vpn_pw_ok() function. Later
on we'll implement a pseudowire manager in zebra which will solve this
problem in a much better way (including notifying ldpd about failures
to install a pseudowire in the kernel/hardware).
Donald Sharp [Thu, 16 Mar 2017 15:15:32 +0000 (11:15 -0400)]
pimd: Consider interface change a RPF_CHANGED event
Suppose you have a unnumbered ecmp connections between
two switches:
st1-l3# show ip pim neighbor
Interface Neighbor Uptime Holdtime DR Pri
swp52 6.0.0.10 00:00:01 00:00:29 1
swp53 6.0.0.10 00:00:06 00:00:26 1
And for a given (S,G) the RPF goes:
st1-l3# show ip nht
99.1.1.1
resolved via bgp
fe80::4e76:25ff:fee7:42d1, via swp52
fe80::4e76:25ff:fee7:42d5, via swp53
Client list: pim(fd 14)
Now suppose, 52 is the choosen RPF( since we can only pick one )
and the interface goes down. As such we will choose to use
swp53.
The problem was that the pim_rpf_update call is made
it will change the rpf interface to 53, but not tell
the calling function that the RPF_CHANGED because
it is only looking at the rpf_addr(the nexthop)
to see if it is changed and if we are in an unnumbered
dual ecmp to the same box it was not detecting and
notifying.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Donald Sharp [Fri, 10 Mar 2017 15:26:00 +0000 (10:26 -0500)]
pimd: Carefully Reconstruct FHR state when interface bounces
When an interface bounces and we receive a packet before
pim has a chance to fully bring the 'struct pim_usptream'
back up correctly, first check to see if we already have
an associated data structure before creating it again.
This removes a case where both the c_oil and up ref counts
were being incremented and never removed properly.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
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>
projects / mirror / frr.git / log