The route_map_event_hook callback was passing the `route_map_event_t`
to each individual interested party. No-one is ever using this data
so let's cut to the chase a bit and remove the pass through of data.
This is considered ok in that the routemap.c code came this way
originally and after 15+ years no-one is using this functionality.
Nor do I see any `easy` way to do anything useful with this data.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
become stale entries.
Topology:
--------
Source
|
FHR
|
RP ------ LHR --- Recv1
|
Recv2
Root case :
-----------
When RP acts as a LHR i.e RP has a local receiver and registed for
the same group where LHR connected receiver also registered for the
same multicast group.When RP receives a (s,g) join form LHR , it
increments upstream ref count to two to track the Local membership
as well.But at the time of KAT expiry in RP , upstream reference
is not being removed Which is added to track local membership which
is causing to make these entries as stale in RP and FHR.
Fix : Made the change such that it removes the upstream reference
if it is added to track the local memberships.
Signed-off-by: Rajesh Girada <rgirada@vmware.com>
vrf_id parameter is added to the api of bfd_client_sendmsg().
this permits being registered to bfd from a separate vrf.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
This macro:
- Marks ZAPI callbacks for readability
- Standardizes argument names
- Makes it simple to add ZAPI arguments in the future
- Ensures proper types
- Looks better
- Shortens function declarations
Signed-off-by: Quentin Young <qlyoung@cumulusnetworks.com>
There exists a possiblity that we have upstream data but
at this point in time the rpf failed because there is no
path. As such the rpf interface will be NULL and we
should not necessarily trust it. Prevent a crash
Ticket: CM-24857
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
So when we remove a ifchannel from the system we should check to
see if we still care about the S,G having it in the OIL still
due to inheritance rules. The deletion does not necessarily
mean it should not be in the OIL for the S,G.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
the json code has not been updated since a variety of new flags have
been added to the code base. Add those flags in so we can tell
what is going on sometimes.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Add the ability to select on a S or G for a `show ip mroute`
command.
show ip mroute 225.1.1.111
show ip mroute 4.5.6.7 225.1.1.111
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Always when creating a new S,G state look at all possible ifchannels
to decide what the mroute should be.
The bug that this is fixing is this:
Suppose two incoming `*,G` joins on swp1, and swp2.
Now suppose that one of those ifchannel `*,G` sends a `*,G S,G RPT Prune`.
We were creating the S,G upstream state as we should but we were
only looking at the S,G ifchannel to decide the S,G mroute we would
be creating. As such what we need to do is to look over the associated
*,G ifchannels and allow us to associate correct oil needed.
Ticket: CM-24732
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
1. vxlan instance cleanup needs to be done before the upstream entries are
force-flushed.
2. also vxlan callbacks need to be ignored post instance-cleanup.
Signed-off-by: Anuradha Karuppiah <anuradhak@cumulusnetworks.com>
This was resulting in static analyzer warnings for subsequent usage
of the same pointer -
pimd/pim_vxlan.c:962:36: warning: Access to field 'info' results in a
dereference of a null pointer (loaded from variable 'ifp')
pim_ifp = (struct pim_interface *)ifp->info;
^~~~~~~~~
1 warning generated.
Signed-off-by: Anuradha Karuppiah <anuradhak@cumulusnetworks.com>
The MLAG component on the switch is expected to provide some
properties (such as peerlink-rif) to bootstrap the anycast-VTEP
functionality. The final interface for this is being defined as
a part of the pim-mlag functionality.
This commit provides a hidden command to test the anycast-VTEP
functionality independent of the MLAG component.
Signed-off-by: Anuradha Karuppiah <anuradhak@cumulusnetworks.com>
Sample output:
root@TORS1:~# vtysh -c "show ip pim vxlan-groups"
Codes: I -> installed
Source Group Input Output Flags
27.0.0.7 239.1.1.101 lo I
* 239.1.1.100 - ipmr-lo I
* 239.1.1.101 - ipmr-lo I
27.0.0.7 239.1.1.100 lo I
root@TORS1:~#
root@TORS1:~# vtysh -c "show ip pim vxlan-work"
Codes: I -> installed
Source Group Input Flags
27.0.0.7 239.1.1.100 lo I
PS: note the worklist dump is a hidden command
Signed-off-by: Anuradha Karuppiah <anuradhak@cumulusnetworks.com>
The unique physical IP is used as the SIP in the ip header to ensure
that pim-register-stop makes it back to the right MLAG switch.
Signed-off-by: Anuradha Karuppiah <anuradhak@cumulusnetworks.com>
1. peerlink-rif as OIF in origination mroutes -
Hosts are multi-homed to the anycast-VTEP pair and can send BUM traffic to
either switch. But the RP would have only joined one MLAG switch for
pulling down the MDT. To make that work we add the peerlink/ISL as
an OIF to origination mroutes (TORC11<=>TORC12 is an anycast VTEP pair) -
root@TORC11:~# ip mr |grep "(36.0.0.9, 239.1.1.100)"
(36.0.0.9, 239.1.1.100) Iif: peerlink-3.4094 Oifs: peerlink-3.4094 uplink-1
root@TORC11:~#
root@TORC12:~# ip mr |grep "(36.0.0.9, 239.1.1.100)"
(36.0.0.9, 239.1.1.100) Iif: peerlink-3.4094 Oifs: peerlink-3.4094
root@TORC12:~#
2. VTEP-PIP as register source -
TORC11 and TORC12 share the same anycast VTEP IP (36.0.0.9 in the above
example). And that is the source registered by both VTEPs for all the BUM
mcast-groups. However to allow the pim register start machine to close
the SIP in the register-pkt's IP header must be set to an unique IP address.
This is the VTEP PIP.
Signed-off-by: Anuradha Karuppiah <anuradhak@cumulusnetworks.com>
1. special handling of term device in orig mroutes -
The multicast-vxlan termination device ipmr-lo is added to the (*, G)
mroute -
(0.0.0.0, 239.1.1.100) Iif: uplink-1 Oifs: uplink-1 ipmr-lo
This means that it will be inherited into all the SG entries including the
origination mroute. However we cannot terminate the traffic we originate
so some special handling is needed to exclude the termination device
in the origination entries -
27.0.0.7, 239.1.1.100) Iif: lo Oifs: uplink-1
2. special handling of term device on the MLAG pair -
Both MLAG switches pull down BUM-MDT traffic but only one (the DF) can
terminate the traffic. The non-DF must not exclude the termination device
from the MFC to prevent dups to the overlay.
DF -
root@TORC11:~# ip mr |grep "(0.0.0.0, 239.1.1.100)"
(0.0.0.0, 239.1.1.100) Iif: uplink-1 Oifs: uplink-1 ipmr-lo State: resolved
root@TORC11:~#
non-DF -
root@TORC12:~# ip mr |grep "(0.0.0.0, 239.1.1.100)"
(0.0.0.0, 239.1.1.100) Iif: uplink-1 Oifs: uplink-1 State: resolved
root@TORC12:~#
Signed-off-by: Anuradha Karuppiah <anuradhak@cumulusnetworks.com>
An interface needs to be designated as "termination device" and added to
the termination mroute's OIL. This is used by kernel and ASIC backends
to vxlan-decaps matching flows.
The default termination device is expected to have the prefix (start
sub-string) "ipmr-lo". This can be made configurable if needed -
root@TORS1:~# ip -d link show ipmr-lo
28: ipmr-lo: <BROADCAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN mode DEFAULT group default
link/ether 12:5a:ae:74:51:a2 brd ff:ff:ff:ff:ff:ff promiscuity 0
dummy addrgenmode eui64
root@TORS1:~# ip mr
This commit includes the changes to enable pim implicitly on the device
and set it up as the vxlan-term device per-pim-instance.
Signed-off-by: Anuradha Karuppiah <anuradhak@cumulusnetworks.com>
For vxlan origination mroutes the IIF is pinned to
a. lo for single VTEPs
b. peerlink-rif for anycast VTEPs
This commit includes the changes to react to pim-vifi add/del for these
devices.
Signed-off-by: Anuradha Karuppiah <anuradhak@cumulusnetworks.com>
To terminate a multicast VxLAN tunnel entry we setup a mroute with
ipmr-lo in the OIL -
(0.0.0.0, 239.1.1.100) Iif: uplink-1 Oifs: uplink-1 ipmr-lo
This is done by the vxlan component that add ipmr-lo as a local
member to termination SG entries. In addition termination entries
are also subject to MLAG DF election on the anycast VxLAN-AA setup.
Signed-off-by: Anuradha Karuppiah <anuradhak@cumulusnetworks.com>
Two flags have been introduced per-upstream entry -
1. XXX_MLAG_VXLAN - This indicates that MLAG DF (designated-forwarded)
election is needed on the entry. In the case of pim-evpn this flag is set
for termination (*, G) entries and will be inherited by the (S, G) entries
that are created as a result of SPT switchover on the G.
2. XXX_MLAG_NON_DF - This is set on entries that have lost the
DF election. Such entries are primarily used for blackholing traffic on
one of the MLAG switches. On a hardware accelerated switch this blackholing
happens in the ASIC preventing (non-needed) traffic hitting the CPU.
Signed-off-by: Anuradha Karuppiah <anuradhak@cumulusnetworks.com>
For multicast vxlan tunnels we register the local VTEP-IP independent
of the prescence of BUM traffic i.e. we prime the pump. This
is acheived via NULL registers.
VxLAN orig entries with upstream in a PIM_REG_JOIN state are linked to
a work list for periodic NULL register transmission. Once the SPT setup
is complete the upstream-entry moves to a PIM_REG_PRUNE state and is
remved from the VxLAN work list.
Signed-off-by: Anuradha Karuppiah <anuradhak@cumulusnetworks.com>
In a PIM MLAG setup (say L11<->L12 is the anycast VTEP pair) the RP
can choose to join either MLAG switch as the anycast VTEP-IP is
present on both. Let's say the RP joins L11.
Hosts are dual connected to L11<->L12 and can send traffic to either
switch. Let's say a host sends broadcast traffic to L12; now L12
must encapsulate and send the traffic toward L11. To do that the
origination-mroute on L12 must include the ISL in its OIL -
(36.0.0.9, 239.1.1.100) Iif: peerlink-3.4094 Oifs: peerlink-3.4094
L11 has a similar mroute -
(36.0.0.9, 239.1.1.100) Iif: peerlink-3.4094 Oifs: peerlink-3.4094 uplink-1
This mroute is used to rx traffic on peerlink-3.4094 and send it out of
uplink-1. Note that this mroute also includes the peerlink-rif in its
OIL. Explicit removal of IIF from OIL is done by the kernel (and other
dataplanes) to prevent traffic looping.
Signed-off-by: Anuradha Karuppiah <anuradhak@cumulusnetworks.com>
For every (local-vtep-ip, bum-mcast-grp) registered by evpn an origination
mroute is setup by pimd. The purpose of this mroute is to forward vxlan
encapsulated BUM -
Sample mroute (single VTEP):
(27.0.0.7, 239.1.1.100) Iif: lo Oifs: uplink-1
Sample mroute (anycast VTEP):
(36.0.0.9, 239.1.1.100) Iif: peerlink-3.4094\
Oifs: peerlink-3.4094 uplink-1
This commit is part-1 of orignation mroute setup and includes setup
of upstream entries with vxlan properties.
Signed-off-by: Anuradha Karuppiah <anuradhak@cumulusnetworks.com>
pim-vxlan work is maintained in a lists and processing staggered. One
such work is the generation of periodic null registers for the local
VTEP-IP.
This info is instance agnostic and maintained in a global cache.
Signed-off-by: Anuradha Karuppiah <anuradhak@cumulusnetworks.com>
This information will come in from a MLAG component. Hidden commands
will also be provided for testing the interface independent of the
separate MLAG component.
PS: It is possible that this cache will be merged with the base
pim-mlag datastructures once they are available.
Signed-off-by: Anuradha Karuppiah <anuradhak@cumulusnetworks.com>
pim vxlan component will create upstream entries and OIFs for
multicast VxLAN tunnel origination and termination in single-VTEP
and anycast-VTEP (MLAG) setups.
Signed-off-by: Anuradha Karuppiah <anuradhak@cumulusnetworks.com>
pim_vxlan will use this for registering the local-VTEP-IP wth the RP
independent of the presence of BUM traffic.
Signed-off-by: Anuradha Karuppiah <anuradhak@cumulusnetworks.com>
ipmr-lo is a dummy netdev with no additional addressing requirements -
root@TORS1:~# ip -d link show ipmr-lo
28: ipmr-lo: <BROADCAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN mode DEFAULT group default
link/ether 12:5a:ae:74:51:a2 brd ff:ff:ff:ff:ff:ff promiscuity 0
dummy addrgenmode eui64
root@TORS1:~#
This device is used by pim-vxlan to signify multicast-vxlan-tunnel
termination.
Signed-off-by: Anuradha Karuppiah <anuradhak@cumulusnetworks.com>
In an anycast VTEP setup the peerlink-rif (ISL) is added as a OIF to the
tunnel origination mroute. A new OIF protocol, VxLAN, has been added to
allow that functionalty.
Signed-off-by: Anuradha Karuppiah <anuradhak@cumulusnetworks.com>
Two devices have special significance to multicast VxLAN tunnels -
1. tunnel origination device -
This device is used as the source device to vxlan-encapsulate BUM traffic.
In the case of the default-vrf this is lo. And in the case of non-default
VRF this is vrf-net-device. This patchset is limited to default-VRF
underlay so all subsequent references of origination-dev are to lo. But it
is possible in the future to extend support to non-default VRFs.
Sample origination mroute on single-VTEP:
(27.0.0.7, 239.1.1.100) Iif: lo Oifs: uplink-1
In the case of MLAG we need to mroute traffic form the MLAG-peer so
we force the IIF to the ISL.
Sample origination mroute on MLAG-VTEP:
(36.0.0.9, 239.1.1.100) Iif: peerlink-3.4094 Oifs: peerlink-3.4094 uplink-1
2. tunnel termination device -
This device is used in the OIL to indicate that packets matching the flow
must be vxlan terminated and overlay packets subsequently forward to the
tenants. A special device has been created for this purpose called ipmr-lo.
This is a simple dummy interface from the kernel perspective which has
special siginficance only to pimd which implicitly enabled pim on the
device and adds it to the termination mroutes.
Sample termination mroute:
(0.0.0.0, 239.1.1.100) Iif: uplink-1 Oifs: uplink-1 ipmr-lo
PS: currently we default the termination device name to "ipmr-lo" but in
the future it is possible to provide a config command to set the
termination device.
Signed-off-by: Anuradha Karuppiah <anuradhak@cumulusnetworks.com>
PIM VxLAN handling will create two types of upstream entries and
maintain app-specific properties against the entry.
This commit provides the header definitions for that.
Signed-off-by: Anuradha Karuppiah <anuradhak@cumulusnetworks.com>
In a VxLAN-AA setup both the anycast VTEPS can send VxLAN encapsulated
traffic. This is despite the fact that the it is not-DR on the IIF
associated with the originating mroute.
Signed-off-by: Anuradha Karuppiah <anuradhak@cumulusnetworks.com>
In a MLAG setup both of the VTEPs can rx and reg-encapsulate BUM traffic
toward the RP. To prevent these duplicates we need a mechanism to disable
register encaps on specific mroutes.
Signed-off-by: Anuradha Karuppiah <anuradhak@cumulusnetworks.com>
This is specifically needed to allow pim-evpn mroutes in the MLAG setup -
(36.0.0.11, 239.1.1.100) Iif: peerlink.4094 Oifs: uplink-1, peerlink.4094
I could have gone the other way and disabled PIM_ENFORCE_LOOPFREE_MFC but
that opens the door too wide. Relaxing the checks for mlag-specific mroutes
seemed like the safer choice.
This commit provides the infrastructure to relax checks on a per-mroute
basis.
Signed-off-by: Anuradha Karuppiah <anuradhak@cumulusnetworks.com>
In the case of vxlan origination entries IIF is set to -
1. lo for single VTEPs
2. MLAG-ISL for VTEPs multihomed via MLAG.
This commit creates the necessary infrastructure by -
1. allowing the IIF to be set statically (without RPF lookup)
2. and by preventing next-hop-tracking registration
PS: Note that I have skipped additional checks in pim_upstream_del
intentionally i.e. an attempt will be made to remove nexthop-tracking
for the upstream entry (with STATIC_IIF) which will fail because of the
up-entry not being in the nh's hash table. Ideally we should maintain
a nh pointer in the up-entry to prevent this unnecessary processing.
In the abscence of that I wanted to avoid spraying STATIC_IIF checks
all over.
Signed-off-by: Anuradha Karuppiah <anuradhak@cumulusnetworks.com>
In the case of pim vxlan we create and keep upstream entries alive
in the abscence of traffic. So we need a mechanism to purge entries
abruptly on vxlan SG delete without having to wait for the entry
to age out.
These are again just the infrastructure changes needed for it.
Signed-off-by: Anuradha Karuppiah <anuradhak@cumulusnetworks.com>
For vxlan BUM MDTs we prime the pump and register the local-VTEP-ip
as source even before the first BUM packet is rxed. This commit provides
the infrastructure changes needed for that.
Signed-off-by: Anuradha Karuppiah <anuradhak@cumulusnetworks.com>
zebra sends (S, G) and (*, G) entries for BUM mcast groups to pimd. This
commit includes the changes to handle the notifications and trigger the
creation of (S, G) base cache in pimd.
Signed-off-by: Anuradha Karuppiah <anuradhak@cumulusnetworks.com>
These entries will be used over the subsequent commits for
1. vxlan-tunnel-termination handling - setup MDT to rx VxLAN encapsulated
BUM traffic.
2. vxlan-tunnel-origination handling - register local-vtep-ip as a
multicast source.
Signed-off-by: Anuradha Karuppiah <anuradhak@cumulusnetworks.com>
Add a bit of code to allow us to look at specified S,G for
the upstream available to us.
If one item is listed we assume Group, if both we assume Source
then Group.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Add a bit of code to allow us to look at specified S,G for
the upstreams available to us.
If one item is listed we assume Group, if both we assume Source then
Group.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Replace cli 'debug static' with 'debug pim static', to make
the 'debug static' node available for staticd (eventually).
Signed-off-by: Mark Stapp <mjs@voltanet.io>
The decision for Update_SPTbit(S,G, iif) includes a test
for JoinDesired(S,G) in section 4.2.2. When we were deciding
to update the spt bit we were not taking this into account.
This commit fixes this issue.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
When we receive a S,G join and the ifchannel is in S,G RPT Prune state,
pim should transition the ifchannel state to JOIN and transition the
pim_upstream state for the S,G stream.
Ticket: CM-24513
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
pim was sending a triggered response on every S,G RPT prune information
read. Suppose we had this in a *,G message:
*,G
S1, G RPT Prune
S2, G RPT Prune
We would send two triggered *,G messages upstream. This leads to over
processing and quickly changing state if S1 or S2 were in different
states.
Modify the code to send just one Triggered *,G upstream after looking
at all S,G state for a *,G.
Ticket: CM-24531
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
On the LHR after we decide that traffic is flowing and
we set the SPT bit for the S,G *and* the incoming IIF
of the S,G is different than the incoming IIF of the *,G
we should immediately send the *,G S,G RPT Prune as
a triggered response instead of waiting for the next
cycle.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Track whether or not we have received an answer from
our query to do nexthop tracking. This allows us to
go straight to doing a synchronous query for our
RPF.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Start the separation of tracking a Destination from the act
of looking it up. The cojoining of these two concepts led
to a bunch of code that had to think about both problems leading
to weird situations and code paths. Simplify the code by making
pim_ecmp_nexthop_search a static function and we only ever
call pim_ecmp_nexthop_lookup when we need to do a RPF().
pim_ecmp_nexthop_lookup will now attempt to find a stored pnc
and if it finds one it will report on the answer from it.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
When creating new RP information from a `ip pim rp A.B.C.D/M A.B.C.D`
we should determine if we are the RP even if we can or cannot
determine if we have a path to the RP via RPF.
This is because we should determine if we are the RP based upon a
connected ip address match not whether or not we have a path to
the RPF. We would normally think this is not important but
RPF is inherently asynchronous and we can have a state where
we have registered for nht but have not received the actual
path back yet from zebra.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
The current reverse logic led to this code construct
if (!pim_nexthop_lookup(...)) {
//Do something successfull
}
This is backwards and will cause logic errors when people
use this code. Fix to use true/false for success/failure.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
When a new pim neighbor comes up, we need to go through and
mark nexthops that we have received from zebra for reachability
tracking so we can refigure stuff. If we pass in the new neighbor
we can limit the search to those nexthops out the interface that
the new neighbor has come up.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
The pim_resolve_upstream_nh function call is no longer being used
let's remove it from the code base.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Issue: (*,G) mroute uptime is not updated in mroute table,
after deleting and adding the RP
Root cause: When RP gets deleted or becomes not reachable, then
we un-install the entry from the kernel, but still maintains the
entry in the stack. When RP gets re-configured or becomes reachable,
"show ip mroute" shows the uptime, when the channel_oil gets created.
Fix: Introduce a new time mroute_creation in the channel_oil, gets
updated when mroute gets installed in the kernel.
Signed-off-by: Sarita Patra <saritap@vmware.com>
When we delete an interface, we need to set the interface
ifindex to an internal value so that we don't end up in
a state where the re-addition of the same ifindex, due to
a rename operation, causes an infinite loop.
Fixes:#4007
Fix-Suggested-by: Saravanan K
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
When we are displaying S,G string data we already auto
display the string as (S,G) no need to have ((S,G)).
Cleanup some that were found during log look through.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
The pim_rp_check_is_my_ip_address function was checking to see
if we were the actual RP as well as the pim_register code
was doing the same thing. Remove the reduncancy a bit and
just make this function check for that we are the actual receiver
of this data.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
The code as written will scan the entirety of all pim upstreams
on a rpf change, this is not necessary because we know that when
we get a nexthop change we already scan the upstreams reliant
on that and do this work. There is no need to do this again a
short time later.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
The interface column in pim was limited to 8 or 9 columns
all over the place in pim, fix the code up to allow interface
length to be up to 16 columns.
Ticket: CM-23083
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
When we are shutting down, delay the zlookup free to as
late as possible since we may need it still
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Suppose we have 2 routers A and B. Both Router A and B have
the same priority of 1000. Router A is the elected DR.
Now suppose B lowers his priority to 1. He still looses the
DR election and we are not sending a hello with the new priority.
Immediately after this A's priority is also lowered to 1, it
looses the election and sends the hello. B receives this hello
and elects A as the DR( since it has the better ip address)
At this point A believes B is the DR, and B believes A is the
DR until such time that the normal hello from B is sent to A,
which if timed correctly can be a significant amount of time).
This code just causes a hello to be sent if the priority is
changed. Now both sides will be able to converge quickly
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
When RP gets deleted, find all the (*, G) upstream whose group belongs to
the deleted RP, release the upstream from pnc->upstream_hash in the function
pim_delete_tracked_nexthop().
Signed-off-by: Sarita Patra <saritap@vmware.com>
When a RP gets deleted, find all the (*, G) upstream whose
group belongs to the deleted RP.
case 1: if the group belongs to any other rp, then call
pim_upstream_update() to update the upstream addr and rpf
information.
case 2: If no RP found for the group, then clear the pim
upstream address and rpf information.
Signed-off-by: Sarita Patra <saritap@vmware.com>
When a new RP is configured, find all the (*, G) upstream whose
group belongs to the new RP and then update the upstream structure
with the below fields.
1. De-register for the old RP.
2. Set the upstream address as new RP
3. Register for the new RP.
4. Update the upstream rpf information and kernel multicast forwarding
cache(MFC), if the new RP is reachable.
Signed-off-by: Sarita Patra <saritap@vmware.com>
When route to RP gets modified, FRR receives a notification from
zebra, and call the function pim_resolve_upstream_nh() to compute the
nexthop and update upstream->rpf structure.
Issue: In case when RP becomes not reachable, FRR only uninstall
the mroute from the kernal, but not update the upstream->rpf structure.
Fix: When FRR receives a notification from zebra saying RP becomes
not reachable, then update the following fields.
1. update channel_oil incoming interface as MAXVIFS
2. Un-install the mroute from the kernel.
3. Switch upstream state from JOINED to NOTJOINED.
4. Clear the nexthop information of the upstream.
Signed-off-by: Sarita Patra <saritap@vmware.com>
When route to RP gets modified, FRR receives a notification from
zebra, and call the function pim_update_rp_nh() to compute the
new nexthop and will update the source_nexthop information of
rp_info. This is not working for the case when RP becomes not
reachable.
Fix: When FRR receives a notification from zebra saying RP becomes
not reachable, then delete the source_nexthop informatio of rp_info.
Signed-off-by: Sarita Patra <saritap@vmware.com>
In this commit, we are creating a dummy upstream & dummy channel_oil
for (*, G) when RP is not configured or not reachable.
Dummy upstream: <upstream_addr = INADDR_ANY, rpf = Unknown>
Dummy channel oil: <iif = MAXVIFS>
Signed-off-by: Sarita Patra <saritap@vmware.com>
When FRR receives IGMP/PIM (*, G) join and RP is not configured or not
reachable, then we are creating a dummy upstream with incoming interface
as NULL and upstream address as INADDR_ANY.
Added upstream address and incoming interface validation where it is necessary,
before doing any operation on the upstream.
Signed-off-by: Sarita Patra <saritap@vmware.com>
When FRR receives IGMP/PIM (*, G) join and RP is not configured or
not reachable, then we are creating a dummy upstream with incoming
interface as NULL.
Added some null checks for the incoming interface, while displaying
the pim upstream information in the cli command "show ip pim upstream".
Signed-off-by: Sarita Patra <saritap@vmware.com>
Added comments which explains the new values for existing fields
and new fields in the upstream and channel_oil data structure.
Following are the summary of the behaviour change in PIM code.
Scenario 1 : RP doesn’t exist/RP not reachable
Event: Join received
Current behaviour:
No upstream gets created
Changed behaviour:
Upstream data structure created with below info
upstream_addr: INADDR_ANY
channel_oil iif: MAXVIF
channel_oil is_valid: FALSE (flag introduced to indicate if this entry is valid to get installed in hardware)
RPF details: Not valid
Join state: NOT_JOINED
Kernal installed: FALSE
Scenario 2: Dummy upstream exists
Event: RP configured
Current Behaviour:
upstream address updated for the dummy upstream created.
Changed Behaviour:
upstream_addr: RP address
channel_oil iif: MAXVIF
channel_oil is_valid: FALSE
RPF details: only RP address updated
Join state: NOT_JOINED
Kernel installed: FALSE
Scenario 3: Dummy upstream exists
Event: RP becomes reachable
Current Behaviour:
Update channel oil, rpf details in the upstream and install in hardware
Changed Behaviour:
upstream_addr: RP Adress
channel_oil iif: MAXVIF
channel_oil is_valid: FALSE
RPF details: RPF details updated via NHT callback
Join state: JOINED
Kernel installed: TRUE
Scenario 4: MRoute exists
Event: RP gets deleted
Current behaviour:
Nothing got updated in him upstream and channel oil,
join timer still runs. Mroute still exists in kernel.
Changed behaviour:
upstream_addr: INADDR_ANY
channel_oil iif: MAXVIF
channel_oil is_valid: FALSE
RPF details: Not valid
Join state: NOT_JOINED (also sent prune towards deleted RPF nbr)
Kernel installed: FALSE
Scenario 5: MRoute Exists
Event: RP unreachable
Current behaviour:
Nothing got updated in him upstream and channel oil,
join timer still runs. Mroute sdeleted from kernel.
Changed behaviour:
upstream_addr: RP address
channel_oil iif: MAXVIF
channel_oil is_valid: FALSE
RPF details: only RP address updated
Join state: NOT_JOINED (also sent prune towards deleted RPF nbr)
Kernel installed: FALSE
Scenario 6: Mroute exists
Event: Better RP configured with precise group range & reachable.
Current behaviour:
No effect on existing route.
Changed behaviour:
Upstream address: Better RP
RPF interface: towards the better RP
Join state: JOINED (Send a prune towards the old RP and send a join
towards the better RP)
Scenario 7: Mroute exists
Event: RP deleted and another RP with broad group range fits this group & reachable
Current behaviour:
No effect on current behaviour
Changed behaviour:
Upstream address: next available RP
RPF interface: towards the next available RP
Join state: JOINED (Send a prune towards the old RP and send a join
towards the better RP)
Signed-off-by: Sarita Patra <saritap@vmware.com>
Add a test command to pim that allows you to reset the keepalive timer
for an upstream to it's max value. This is to allow purposeful testing
of cleanup code in pim, by forcing the keeaplive timer to expire later.
robot# show ip pim upstream
Iif Source Group State Uptime JoinTimer RSTimer KATimer RefCnt
enp3s0 192.168.201.136 225.1.0.0 NotJ,RegP 00:00:10 00:00:52 00:00:25 00:02:54 1
robot# show ip pim upstream
Iif Source Group State Uptime JoinTimer RSTimer KATimer RefCnt
enp3s0 192.168.201.136 225.1.0.0 NotJ,RegP 00:00:11 00:00:51 00:00:24 00:02:53 1
robot# test pim keep 192.168.201.136 225.1.0.0
Setting (192.168.201.136,225.1.0.0) to current keep alive time: 210
robot# show ip pim upstream
Iif Source Group State Uptime JoinTimer RSTimer KATimer RefCnt
enp3s0 192.168.201.136 225.1.0.0 NotJ,RegP 00:00:27 00:00:35 00:00:08 00:03:27 1
robot#
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Issue: Configure "ip pim rp x.x.x.x 225.0.0.0/4".
Show running config shows "ip pim rp x.x.x.x 224.0.0.0/4"
This is mis-leading.
Root-cause: Internally 225.0.0.0/4 is getting converted to
224.0.0.0/4 group mask, since the prefix length is 4.
Fix: Restrict the user to configure inconsistent group address
mask by throughing a cli error "Inconsistent address and mask".
Signed-off-by: Sarita Patra <saritap@vmware.com>
Issue: Shut the RP interface in the router RP. LHR will get to know
RP becomes not-reachable, so it send a prune towards the RP. On
receiving the prune, RP clear the (*, G) entry, but (S, G) should
not get removed if present.
Now no-shut the RP interface in the router RP. LHR will send a (*, G)
join towards the RP. On receiving join FRR create the (*, G) entry.
Along with this, it also add the interface(join received) in the OIL
of (S, G) and also refresh the (S, G) timer.
Fix: Dont refresh the timer for S, G or (*, G), if the flag for the
channel OIL is PIM_OIF_FLAG_PROTO_ANY.
Signed-off-by: Sarita Patra <saritap@vmware.com>
Add a command to track if an interface should be in active-active
mode or not. This command is hidden at this time because it
is not finished fully.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
- some target_CFLAGS that needed to include AM_CFLAGS didn't do so
- libyang/sysrepo/sqlite3/confd CFLAGS + LIBS weren't used at all
- consistently use $(FOO_CFLAGS) instead of @FOO_CFLAGS@
- 2 dependencies were missing for clippy
Signed-off-by: David Lamparter <equinox@diac24.net>
If you have an interface being added to a static mroute
and that interface has been configured w/ pim but does
not have a valid ip address yet, we do not create a
VIF for that device yet. As such when we attempt
to assign the vif array in the pim static data structure
we attempt to write into -1 of that array.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
The pimg data structure is only used in one spot to send the default
vrf id to zebra upon startup. Add the default vrf id to the struct pim_router
data structure and remove the pimg pointer.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Create a `struct pim_router` and move the thread master into it.
Future commits will further move global varaibles into the pim_router
structure.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Just add the ability to notice the capabilities on startup,
but don't do anything with it yet.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
When we receive a igmp report and attempt to initiate
a pim ifchannel for it and that fails to work then
let's back out the work done setting stuff up to this
point.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
When we fail to add a local membership add some additional debugs
so that we can have a bit more information on when something goes
bad.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
It's been a year since we added the new optional parameters
to instantiation. Let's switch over to the new name.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
When sending a sockoption for MRT_INIT, *bsd requires that
the data passed in must be 1. While linux does not, the
code was sending in a positive value that was causing issues
on *bsd of protocol not supported.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
When trying to run PIM on *bsd, the kernel expects to only
allow the pim kernel socket to work if we elevate priviledges.
So do so.
This commit gets us further in the startup of PIM on *bsd
but is not sufficient to get it fully started yet.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Introduce frr-interface.yang, which defines a model for managing FRR
interfaces.
Update the 'frr_yang_module_info' array of all daemons that will
implement this module.
Add automatically generated stub callbacks in if.c. These callbacks will
be implemented in the following commit.
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
FRR_DAEMON_INFO should now contain an array of 'frr_yang_module_info'
structures describing the YANG modules implemented by the daemon.
This array will be used by frr_init() function to load all YANG modules
and initialize the northbound callbacks during the daemon initialization.
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
Resolves issue with exit-vrf being placed at the end of zebra's portion
of a vrf block, but before other daemons' portions of the same config
block.
Signed-off-by: Quentin Young <qlyoung@cumulusnetworks.com>
The ->hash_cmp and linked list ->cmp functions were sometimes
being used interchangeably and this really is not a good
thing. So let's modify the hash_cmp function pointer to return
a boolean and convert everything to use the new syntax.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
This commit fixes two issues during pim shutdown.
1) The rp_info structure was being freed before the
outgoing notifications that depended on it's information
was sent out as part of shutdown.
2) The pim->upstream_list shutdown involved iterating
over the list via ALL_LIST_ELEMENTS. This typically
is enough but pim will auto delete child nodes as well
as itself when it goes away and they depend on it. As such
the node and nnode could possibly already have been freed.
So change the way we look at all the data in the upstream_list
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Suppose we have a bridge with a host and two routers attached
to it.
r1 r2
| |
--------
|
host
host is sending traffic.
r1 and r2 are pim neighbors and r2 is the DR.
Both r1 and r2 will receive data from the stream up the pim
kernel socket. r1 will notice that it is not the DR and
stop processing in pim. This code adds a bit more code to blackhole
the route when r1 detects it is not the DR in this scenario.
This is being done because the kernel is both keeping state and
sending data to the pim process to continue processing this.
Additionally if we happen to be running this on a asic, then
blackholing the route in the asic can save a significant amount
of cpu time handling this situation.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
When we decide we are not the right pim process to add upstream state
for the igmp state received, notice this in a debug to make life
easier to debug.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
The tracking of who have drpriority on an interface
in pim was not displayed anywhere. Add to the show
command for future reference.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
In pim_if_new use bool instead of an int to pass
true/false values for what we should create the
pim interface type for.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
The startup of a non-integrated config was not properly
allowing for startup to create the vif when we have
not learned about the interface we are trying to configure
at this point in time. Actually notice when we are
trying to create a pimreg device or not to properly
notice when to attempt to create the vif or not.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Allow at timer wheel creation time the ability to specify a
name for what we want the 'show thread cpu' to show up as.
Modify pim to note this.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
A new command "ip pim" is created to configure pim sm on an
interface, which replaces the existing commands "ip pim sm"
and "ip pim ssm" and make "ip pim sm" and "ip pim ssm" as
hidden commands. The command "ip multicast-routing" is removed
since it is already enabled on FRR by default.
Signed-off-by: Sarita Patra saritap@vmware.com
config.h (or, transitively, zebra.h) must be the first include file
listed for autoconf things like _GNU_SOURCE and _POSIX_C_SOURCE to work
correctly.
Signed-off-by: David Lamparter <equinox@diac24.net>
Since we're now building through one large Makefile, we can easily put
things with their daemons and crossreference nicely.
Signed-off-by: David Lamparter <equinox@diac24.net>
Problem reported that some bgp and ospf json commands did not return
any json output at all if the bgp/ospf instance did not exist.
Additionally, some bgp and ospf json commands did not return any json
output if the instance existed but no neighbors were defined. This
fix makes these commands more consistent in returning empty braces for
json output and issue a message if not using json output. Additionally,
made the flag "use_json" a bool to make it consistent since previously,
it had been defined as an int, char, u_char, and bool at various places.
Ticket: CM-21040
Signed-off-by: Don Slice <dslice@cumulusnetworks.com>
The Vrf aliases can be known with a specific hook. That hook will then,
from zebra propagate the information to the relevant zapi clients.
The registration hook function is the same for all daemons.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
End user was seeing this debug but we are not giving
the user enough information to debug this on his own.
Add a tiny bit of extra information that could point
the user to solving the problem for themselves.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
When pimd is getting terminated, pim_upstream_del() gets called as
part of cleaning process. pim_upstream_del() deletes the route and
assigns NULL to the up->channel_oil. It also deletes each if_channel
by calling the function pim_ifchannel_delete().
pim_ifchannel_delete() internally calls the caller function pim_upstream_del(),
if it is the last ifchannel for that upstream. So pim_upstream_del
is getting called twice, which will access the up->channel_oil which
was already set to NULL before. This results in crash.
Fix:
pim_ifchannel_delete() should call pim_upstream_del (caller function)
only if the up->ref_count > 0. Added an assert(up->ref_count > 0) in
the function pim_upstream_del().
Signed-off-by: Sarita Patra <saritap@vmware.com>
e.g.
pimd/pim_oil.c: In function ‘pim_channel_oil_dump’:
pimd/pim_oil.c:51:19: error: ‘%d’ directive writing between 1 and 11 bytes into a region of size 10 [-Werror=format-overflow=]
Build on gcc-8.2.0 is warning-free after this patch.
Signed-off-by: David Lamparter <equinox@diac24.net>
While terminating pim instance, the memory allocated for pim nexthop
should be released before deallocating the memory of pim nexthop cache(pnc).
This resolves the memory leak detected in pnc->nexthop creation.
Signed-off-by: Sarita Patra <saritap@vmware.com>
* Use the correct license header
* Stop headers from including themselves
* Use uniform relative include conventions
* Ensure that sources include what they use
* Turn off clang-format around struct array blocks
Signed-off-by: Quentin Young <qlyoung@cumulusnetworks.com>
The definition of the interface commands in vtysh.c were outdated.
Currently, all daemons that call if_cmd_init() will have the "no interface
IFNAME" command and the "[no] description" commands as well, so there's
no need to define exceptions for these commands anymore.
To fix this, make extract.pl parse the if.c file so that vtysh can get the
interface commands from there automatically. Only the "interface IFNAME
[vrf NAME]" must be kept in vtysh.c because it changes the vty node and
thus needs special treatment.
Finally, make pimd and pbrd display interface descriptions on "sh run"
when they are configured.
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
There is no need to check for failure of a ALLOC call
as that any failure to do so will result in a assert
happening. So we can safely remove all of this code.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Don't show BFD commands with timers since it might confuse users
("show running-config" won't display timers in client daemons anymore),
but keep accepting this command from previous configurations.
Signed-off-by: Rafael Zalamena <rzalamena@opensourcerouting.org>
When BFD timers are configured, don't show it anymore in the daemon
side. This will help us migrate the timers command from daemons to
`bfdd`.
Signed-off-by: Rafael Zalamena <rzalamena@opensourcerouting.org>
pimd/pim_nht.c: In function ‘pim_ecmp_nexthop_search’:
pimd/pim_nht.c:523:17: error: ‘nbr’ may be used uninitialized in this function [-Werror=maybe-uninitialized]
nexthop->nbr = nbr;
(on gcc 5.4.0; this is the only warning with that version.)
Signed-off-by: David Lamparter <equinox@diac24.net>
When calling route_map_finish, every place that we do we must
first set the deletion event to NULL, or we will create an infinite
loop, if we are using the delayed route-map application code.
As such we might as well just make the route_map_finish code
do this work, as that there is really no viable alternative here
and route_map_finish should only be called on shutdown.
This fixes an infinite loop in zebra on shutdown when there
are route-maps.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
On shutdown and cleaning up pim_upstream ensure that the
upstream_sg_wheel still exists to remove item from.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
When shutting down, do not free oil information after
interface information since we use the data there to
do so.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
frr_fini and pim_free both call zprivs_terminate. There is
no need for pim_free to call this function.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
If `ip igmp query-max-response-time` is set move it to
display first as that this command has order dependencies
on `ip igmp query-interval`.
Ticket: CM-21598
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
When there is a return at the end of a function, there
is no need for another one immediately after it.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
The pim_socket_join_source function only ever calls
pim_igmp_join_source and pim_socket_join_source is only
called from 1 place. Skip the level of indirection.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Abstract the RPF change for upstream handling code so
that we do not have two copies of the code.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
After we have decided what has changed as part of a update
we need to send the j/p messages to our peers.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Packet sending in PIM is a two step process.
1) Gather data size of next G to be packed into a packet.
2) Write data
After 1 we need to ensure that the next G to pack will actually
fit in a packet. If it does not send what we've currently written
and start a new packet to send.
Because this was a 2 step process it is important to be consistent
in what you think you have packed -vs- what you think you should.
PIM has a bug where we were considering S,G RPT Prunes for a *,G
even when the *,G was being pruned. This lead to a situation where
we were figuring a write size of more data then what we actually wrote
into a packet. This would leave a 8 byte whole of 0's in the packet
due to the way we moved pointers around.
Fix the code so that we do not attempt to consider S,G rpt prunes
for a *,G prune when figuring out how much we should write in step 1.
Ticket: CM-21644
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
When we receive a IGMP report on an interface, do not create upstream
state for that request, unless we are the DR for the incoming interface.
This will prevent a interface on a LAN segment from causing traffic
to flow to itself.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
In places where we do a pim_ecmp_nexthop_search, also
use pim_ecmp_nexthop_lookup instead of the single path
case of pim_nexthop_lookup.
This is in preparation of more serious surgery to fix
the weird api of pim_find_or_track_nexthop.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Both pim_ecmp_nexthop_lookup and pim_ecmp_fib_lookup_if_vif_index
pass the address in 2 times. Make function calls consistent
and just pass in the src once.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
The pim_ecmp_fib_looikup_if_vif_index does practically
the same work as pim_ecmp_nexthop_lookup, refactor to
use that function so that we do not have more code
that must parse the results from zclient_lookup_nexthop.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
When doing nexthop lookups do not permanently allocate
memory in zebra and pim to track the nexthop specified
on the cli.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
When we are looking up a RPF with a ecmp path, there
are situations where we are failing to find a path change
because we were not considering the actual number of neighbors
we have available to us at the start of the loop.
Example:
Suppose 2 way ecmp with a neighbor on each path. We have
multiple upstreams that are strewn across both paths.
If we loose a pim neighbor on one of the paths we would
initiate a rescan of the upstreams. If the neighbor
we lost happened to be the last ecmp path we rescanned
we would not successfully find a new path and leave
the upstream stranded.
This code change looks at the number of available neighbors
that we have -vs- the number of paths we have and chooses
the smaller of the two for figuring out what to do.
There probably exist other failure scenarios as well that
I am missing here and quite frankly the current code muddies
the water between a RPF lookup failure -vs- a RPF lookup succeeded
and there are no paths. Further work is needed here imo.
Additionally this idea of a pim_ecmp_nexthop_lookup and
pim_ecmp_nexthop_search is bogus. They are the same function and
should be merged at some point in time.
Ticket: CM-21599
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
There is no reason that a IGMP src should need a upstream
pim neighbor when doing a RPF lookup.
Ticket: CM-21599
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Unless someone intentionally changes MCAST_ALL_ROUTERS ("224.0.0.2") with a
wrong IP, this should never fail, so the fix is using "(void)" at the left
of the function call, as an explicit way of indicating we discard the
return value on purpose.
Signed-off-by: F. Aragon <paco@voltanet.io>
Additional fix over d94023d85c (PR #2546)
Removed all pointer arithmetic used for the checks, while keeping same
coverage. I hope this removes the Coverity warning (If this don't fix it, I'll
make Coverity work with a fork and try there as many times as necessary)
Signed-off-by: F. Aragon <paco@voltanet.io>
Additional fix over 18e994a043 (PR #2457)
Previous correction was not enough for fixing the Coverity warning. Now we
ensure we don't overflow the buffer.
Signed-off-by: F. Aragon <paco@voltanet.io>
route_map_mark_updated has a `int del_later` variable
that is passed in but never used. Just remove it.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Fix a couple of problems in my 1st fix for PIM nexthops reachable via a
connected route:
Use NEXTHOP_TYPE_IPV4_IFINDEX instead of NEXTHOP_TYPE_IPV4 since we add an
IPv4 address to an already known ifindex.
Assign nexthop_tab[num_ifindex].protocol_distance and .route_metric before
incrementing num_ifindex.
Revert the default: to individual switch case statement conversion in
zclient_read_nexthop() as requested by donaldsharp in #2347
Signed-off-by: Martin Buck <mb-tmp-tvguho.pbz@gromit.dyndns.org>
These commands were being accepted in all vrf's and
affecting all vrf's behavior globally, since they were
global variables.
Modify the code to make these two commands work
on a per-vrf basis.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
