there are some cases where the bgp deletion will not be complete, while
the vrf identifier of the bgp instance is not completely identified. The
vrf search based on the bgp name is the better protection, since the bgp
vrf instance is created, even if the vrf identifier is not yet known.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
On interface down do not delete the eigrp interface data
structure. Ensure that the address that we have setup the
eigrp data structure ontop of is what we are deleting.
Additionally add a test to show that this is no-longer
crashing eigrp. Future commits will further modify
this test to actually ensure that the eigrp topo is
updated correctly and the rib has the correct data.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
The ref count for the eigrp topology table was incorrect in a couple
of spots. Let's clean it up.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
The prefix data structure was being freed yet still needed in the
future and it's a fundamental part of the eigrp_interface data
structure let's keep it there instead of having it be deleted
and then not.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
When we schedule a packet for future handling, list the packet
type so that we can see what we are getting with debugs.
Also note which client and how many packets we received from that
client.
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>
Collapse the old static free function into the actual public
function that was using it (and the only user of it.)
Signed-off-by: Mark Stapp <mjs@voltanet.io>
When you are using the install/remove routes command, the
output goes to a log file. This command allows for ease
of dump of timing information from the vty or vtysh.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
We have a bit of a mess with globals in the sharp daemon.
Let's start formalizing it a bit. Future commits will
take advantage of this, as that we need to have the ability
to start dumping stats about commands we have issued.
These changes will be useful for debugging and understanding
what is going on.
Signed-off-by: Donald sharp <sharpd@cumulusnetworks.com>
Allow the sharp daemon to specify whether or not a watched
nexthop should be connected or not.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
In Asymmetric and symetric routing scenario in EVPN
where each VTEP pair having different set of addresses
for the SVIs.
This knob allows reachability (ping connectivity) of
SVI IPs and resolve ARP resoultion VTEPs across racks.
This knob should not be used when same SVI IPs configured
on VTEPs across racks or when advertise default gateway
is configured.
Ticket:CM-23782
Testing Done:
Bring up EVPN symmetric routing topology with different
SVI IPs on different VTEPs. Enable advertise svi ip
at each VTEP, remote VTEPs installs arp entry for
SVI IPs via EVPN type-2 route exchange.
Signed-off-by: Chirag Shah <chirag@cumulusnetworks.com>
This change is used to send configue changes for
advertise svi address as macip (type-2) route.
Ticket:CM-23782
Signed-off-by: Chirag Shah <chirag@cumulusnetworks.com>
Currently our systemd dependencies look something like this (example
from vanilla Debian 9):
$ systemctl list-dependencies frr
frr.service
● ├─system.slice
● └─sysinit.target
...
$ systemctl list-dependencies --reverse frr
frr.service
● └─network-online.target
● └─apt-daily.service
Note that sysinit.target does not depend on any network* service or
target.
In other words, unless there is a service that requires
network-online.service, even if FRR is enabled it will not be started.
Therefore network-online.target is the wrong unit to have in WantedBy=,
as it is not always started.
This patch updates our service file so that it is properly started by
the system when enabled, delayed until networking is up, and if possible
delayed until after NetworkManager, systemd-networkd or any other
networking configuration manager has finished performing its tasks -
i.e. after network-online.target.
After these changes our new dependency graph looks like this:
$ systemctl list-dependencies frr
frr.service
● ├─system.slice
● │ └─networking.service
● ├─network.target
● └─sysinit.target
...
$ systemctl list-dependencies --reverse frr
frr.service
● └─multi-user.target
● └─graphical.target
This way, FRR will be started by multi-user.target (just like most
applications), but delayed until after networking has been configured.
In the same stroke, this should also fix issues on systems that do not
provide "networking.service" (such as CentOS 7).
Signed-off-by: Quentin Young <qlyoung@cumulusnetworks.com>
Signed-off-by: David Lamparter <equinox@diac24.net>
