Ensure that the route-entry QUEUED flag is cleared in the async
notification path, as it is in the normal results processing
code path.
Signed-off-by: Mark Stapp <mjs@voltanet.io>
Normally we only opportunistically try to bind interfaces to VRRP
instances upon getting if_add and if_up notifications; now that Zebra
sends if_down notifications when interfaces change while they are down,
we should try to bind when we get those as well.
This solves a bug where VRRP would not bind and activate virtual routers
to valid interfaces because their MACs were changed to VRRP macs while
the interface was down.
Signed-off-by: Quentin Young <qlyoung@cumulusnetworks.com>
When interfaces change while they are up, Zebra sends if_up
notifications with the updated interface info. Change Zebra to send
if_down notifications with interface info when the interface changes
while it is down.
VRRP, at the least, needs these to know about MAC changes while an
interface is down.
Signed-off-by: Quentin Young <qlyoung@cumulusnetworks.com>
Coverity report caught this log mutex being unlocked twice.
Removing the extra one before the goto statement.
Signed-off-by: Stephen Worley <sworley@cumulusnetworks.com>
Problem reported with memory leak when the command "show bgp vrf all
ipv6 unicast summary json" is issued. Found that the problem only
occurs if the configuration does not actually include the ipv6
address-family but does contain ipv4 unicast peers. If we didn't
match a peer in the address-family being displayed, we would create
the json object but never free it. This fix actually stops creating
the json object in this section of code and lets the create happen
in the area where the match occurs.
Ticket: CM-25616
Signed-off-by: Don Slice <dslice@cumulusnetworks.com>
When we are sending a redistribute_update, pass the old_re in
so that if we still have it around we can update the calling protocol.
Test:
router ospf
redistribute sharp
!
sharp install route 4.5.6.7 nexthop 192.168.201.1 1
Now add a `ip route 4.5.6.7/32 192.168.201.1`.
This causes zebra to replace the sharp route with the static route.
No update is sent to ospf and debug:
2019/08/01 19:02:38.271998 ZEBRA: 0:4.5.6.7/32: Redist update re 0x12fdbda0 (static), old 0x0 (None)
With fix:
2019/08/01 19:15:09.644499 ZEBRA: 0:4.5.6.7/32: Redist update re 0x1ba5bce0 (static), old 0x1beea4e0 (sharp)
2019/08/01 19:15:09.645462 OSPF: ospf_zebra_read_route: from client sharp: vrf_id 0, p 4.5.6.7/32
Ticket: CM-25847
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Delete an auto MAC with no neighbor associated,
when its VNI is down.
In Following sequence stale MAC entry retained in
FRR (zebra).
- Local MAC-IP pair
- MAC is deleted in bridge fdb table
- VNI is down, triggers IP (neigh) entries removed
from FRR DB.
- MAC retained as AUTO MAC with neigh list count 0.
- When VNI is UP again, stale MAC entry retained in FRR
DB.
When the MAC-IP pair moves behind remote VTEP, local VTEP
fails to add remote entry as its MAC is in auto state.
Ticket:CM-25504
Reviewed By:
Testing Done:
Validated the sequence with fix and auto MAC is deleted
when VNI is down.
When VNI comes up, the remote MAC-IP is added to FRR (Zebra)
and kernel.
Signed-off-by: Chirag Shah <chirag@cumulusnetworks.com>
Add info info in local mac del debug,
the local sequence and assoicated neigh count.
remote_mac_ip_add modify debug to display
flags value to cover local, remote and auto flags
for the MAC.
Signed-off-by: Chirag Shah <chirag@cumulusnetworks.com>
Add a warning to the user documentation about v6 ecmp route
deletion and what version of the linux kernel that you should
be using.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
The changes came as part of PR #4730, checks
only variable mac, which is never null. Even
for ip version of cli hits "mac" case statement
and failing the clear cli.
Testing Done:
Before Fix:
VTEP-03# show evpn arp-cache vni 1002 duplicate
VNI 1002 #ARP (IPv4 and IPv6, local and remote) 1
IP Type State MAC Remote VTEP
Seq #'s
11.11.11.11 remote active aa:22:aa:aa:aa:aa 27.0.0.16
7/8
VTEP-03# clear evpn dup-addr vni 1002 ip 11.11.11.11
% Requested MAC does not exist in VNI 1002
Post fix:
VTEP-03# clear evpn dup-addr vni 1002 ip 11.11.11.11
VTEP-03#
VTEP-03# show evpn mac vni all duplicat
VNI 1002 #MACs (local and remote) 1
MAC Type Intf/Remote VTEP VLAN Seq #'s
aa:aa:aa:aa:aa:aa remote 27.0.0.16 7/8
Post fix:
VTEP-03# clear evpn dup-addr vni 1002 mac aa:aa:aa:aa:aa:aa
VTEP-03#
VTEP-03# clear evpn dup-addr vni 1002 ip 11.11.11.11
VTEP-03#
Signed-off-by: Chirag Shah <chirag@cumulusnetworks.com>
The peerUptime data received from a `show bgp ipv4 uni summ json`
gives you the time in seconds since the peer has come up.
The clear_bgp_and_verify function is checking the peerUptime
for before and after and if they are the same then the test
was declaring a clear failure.
The problem with this is of course that the tests can run fast
enough that the peerUptime is the same for before and after the clear.
Modify the test case to use peerUptimeEstablishedEpoch.
This value is the seconds since the epoch since the establishment
of the peer. This will allow us to know that a clear happened.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Add some asserts where `list_del()` is called to verify they object
was found when it was deleted.
Signed-off-by: Stephen Worley <sworley@cumulusnetworks.com>
The new list api did not implement the `*_del` endpoint as
it was described in the docs here:
http://docs.frrouting.org/projects/dev-guide/en/latest/lists.html#c.Z_del
This patch implements the endpoints to return the object deleted if
found, otherwise NULL for all but the atomic lists.
The atomic list `*_del` code is marked as TODO and will remain undefined
for now.
Signed-off-by: Stephen Worley <sworley@cumulusnetworks.com>
The 'show ip import-check A.B.C.D` code was generating
a /32 prefix for comparison. Except import-check was
being used by bgp to track networks. So they could
have received a /24( or anything the `network A.B.C.D/M`
statement specifies ).
Consequently when we do a `show ip import-check A.B.C.D`
we would never find the network but a `show ip import-check |
grep A.B.C.D` would find it.
Fix the exact comparison to a match.
For the `show ip nht A.B.C.D` case we are comparing
a /32 to a /32 so prefix_match will work still.
While a `show ip import-check A.B.C.D` will now show
the expected behavior as well.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Instead of defaulting the import-check to a /32
allow the tester to specify any prefix that they want
when doing an import-check.
Test:
donna.cumulusnetworks.com# sharp watch import
A.B.C.D/M The v4 prefix for import check to watch
X:X::X:X/M The v6 prefix to signal for watching
donna.cumulusnetworks.com# sharp watch import 4.5.6.0/24
donna.cumulusnetworks.com# show ip import-check
4.5.6.0
resolved via kernel
via 10.50.11.1, enp0s3
Client list: sharp(fd 21)
donna.cumulusnetworks.com# sharp watch import 4:5:6::0/64
donna.cumulusnetworks.com# show ipv6 import-check
4:5:6::
resolved via kernel
fe80::cad7:19ff:fe0a:fdfd, via enp0s3
fe80::ce37:abff:fe4f:a601, via enp0s3
Client list: sharp(fd 21)
donna.cumulusnetworks.com# sharp watch nexthop
A.B.C.D The v4 address to signal for watching
X:X::X:X The v6 nexthop to signal for watching
donna.cumulusnetworks.com# sharp watch nexthop 4.5.6.7
donna.cumulusnetworks.com# sharp watch nexthop 4:5::6:7
donna.cumulusnetworks.com# show ip nht
4.5.6.7
unresolved
Client list: sharp(fd 21)
donna.cumulusnetworks.com# show ipv6 nht
4:5::6:7
unresolved
Client list: sharp(fd 21)
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
The documentation says "match aspath" to match an AS path in a
route-map while the directive is "match as-path".
Signed-off-by: Vincent Bernat <vincent@bernat.ch>
The v2 and v3 ospf documentation was suggesting
that the user should use a deprecated command.
Fixes: #4734
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
