- touching the LSDB to explicitly remove a MaxAge LSA is always wrong
and results in desynchronization of the entire routing domain
- the LSDB code correctly handles replacing a MaxAge LSA with a newly
issued one
- removing the old LSA resets the sequence numbers, which may cause
other routers to reject the new LSA as old
- the function was horribly misnamed
Signed-off-by: David Lamparter <equinox@diac24.net>
David Lamparter [Mon, 29 Jul 2019 10:27:25 +0000 (12:27 +0200)]
ospfd: kill totally misnamed "timers"
Neither ospf_external_lsa_originate_timer() nor
ospf_default_originate_timer() are actually timers. They're only
executed on router-ID changes to refresh a particular LSA type.
Signed-off-by: David Lamparter <equinox@diac24.net>
Chirag Shah [Wed, 31 Jul 2019 01:58:44 +0000 (18:58 -0700)]
zebra: fix evpn dad clear cmd mac parsing
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>
Donald Sharp [Wed, 31 Jul 2019 16:29:32 +0000 (12:29 -0400)]
tests: Do not use peerUptime as a measure of if a clear worked
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>
Donald Sharp [Wed, 31 Jul 2019 15:07:58 +0000 (11:07 -0400)]
zebra: Fix display of `show ip import-check A.B.C.D`
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>
Donald Sharp [Wed, 31 Jul 2019 14:47:46 +0000 (10:47 -0400)]
sharpd: Update 'sharp watch import` to allow prefix
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>
Don Slice [Thu, 25 Jul 2019 15:35:06 +0000 (11:35 -0400)]
bgpd: stop removing and replacing private asn if it matches the peer
Problems reported that if multiple peers have "remove-private-AS
replace-AS" with each other and all are using private asns, the as-path
gets hosed and continues to grow when a prefix is removed. This fix
disallows removing and replacing the private asn if it matches the
peer's ASN so that normal as-path loop prevention will operate correctly.
Ticket: CM-25489 Signed-off-by: Don Slice <dslice@cumulusnetworks.com>
Donald Sharp [Mon, 29 Jul 2019 15:36:03 +0000 (11:36 -0400)]
zebra: Remove repeated enqueueing of system routes for rethinking
The code as written before this code change point would enqueue
every system route type to be refigured when we have an
interface event. I believe this was to originally handle bugs
in the way nexthop tracking was handled, mainly that if you keep
asking the question you'll eventually get the right answer.
Modify the code to not do this, we have fixed nexthop tracking
to not be so brain dead and to know when it needs to refigure
a route that it is tracking.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Donald Sharp [Mon, 29 Jul 2019 15:10:25 +0000 (11:10 -0400)]
zebra: Fix route replace v4 semantics with new system route
When a new system route comes in and we have a pre-existing
non-system route we are not deleting the current system
route from the linux kernel.
Modify the code such that when a route replace is sent
to the kernel with a new route as a system route and
the old route as a non-system route do a delete of
the old route so it is no longer in the kernel.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Rafael Zalamena [Fri, 26 Jul 2019 20:32:48 +0000 (17:32 -0300)]
topotest: fix bgp-path-attributes-topology
The first RIB check wants to assert that we don't have the r7's routes
in r1, so right after that code the routers r2 and r3 are configured
then `verify_rib` is called again to check for those routes.
This test never passed, but it didn't cause failures because of the
`try`/`except`.
Signed-off-by: Rafael Zalamena <rzalamena@opensourcerouting.org>
Don Slice [Mon, 1 Jul 2019 17:17:46 +0000 (17:17 +0000)]
zebra: skip queued entries when resolving nexthop
Problem reported where certain routes were not being passed on to
clients if they were operated on while still queued for kernel
installation. Changed it to defer working on entries that were
queued to dplane so we could operate on them after getting an
answer back from kernel installatino.
Ticket: CM-25480 Signed-off-by: Don Slice <dslice@cumulusnetworks.com>
Don Slice [Wed, 24 Jul 2019 15:52:03 +0000 (15:52 +0000)]
bgpd: solve invalid error message when clearing interface peer
Problem reported that if "clear bgp swp1" is issued, an error
message is received saying the name or address is malformed. This
was because of a change in bgp_vty.c that removed the storing
and passing of the interface name for this command. Commit that
caused the problem was ac5dec7e88ce2f8cd2943bb61437046718fb34c2.
Ticket: CM-25737 Signed-off-by: Don Slice <dslice@cumulusnetworks.com>
bgpd: Convert to network byte order before passing value to `community_del_val`
community_val_get() returns ntohl(val) which is used in more places like
community_include(), community_add_val(), but community_del_val() is missing
back conversion htonl().
Rafael Zalamena [Wed, 17 Jul 2019 13:09:25 +0000 (10:09 -0300)]
frr-reload.py: fix reload with different settings
Add `allow-external-route-update` and `domainname` to the one line
context list, otherwise reload will fail when those commands show up in
the running configuration.
Signed-off-by: Rafael Zalamena <rzalamena@opensourcerouting.org>
Don Slice [Wed, 17 Jul 2019 17:19:08 +0000 (13:19 -0400)]
bgpd: encode implicit next-hop-self in some vrf route leaking scenarios
Problem reported that when vrf route-leaking between an unnumbered
peer in one vrf to a numbered peer in another vrf, the nexthop
attribute was missing from the update, causing the session to fail.
determined that we needed to expand the mechanism for verifying if
the route has been learned in the other vrf without an ipv4 nexthop.
Ticket: CM-25610 Signed-off-by: Don Slice <dslice@cumulusnetworks.com>
Rafael Zalamena [Wed, 17 Jul 2019 21:39:03 +0000 (18:39 -0300)]
topotest: improve reliability of `verify_rib`
Attempt to run the function multiple times to make sure we got the
result we expected. This is a middle ground between big sleeps and short
test intervals.
Signed-off-by: Rafael Zalamena <rzalamena@opensourcerouting.org>
bgpd: Route-map VNI in-filter filters out all the routes for EVPN
Issue1: When a vni in-filter eg:"neighbor X.X.X.X route-map RM-VNI-FILTER in"
is configured under evpn address-family, all the received routes are dropped
regardless of whether the route has a matching vni or not.
(Where RM-VNI-FILTER contains "match evpn vni 100")
Issue2: Routes with 2 labels are not filtered correctly
Issue3: This filter should not get applied for MPLS routes. For MPLS routes,
we need route-map to handle a 3rd state besides match/nomatch called: noop.
Fix1: The handler bgp_update() that services the received route ignored the
route's label while deciding whether to filter it or not.
As part of the fix, the handler now uses the label info to make the
decision about whether to filter the route or not.
Fix2: route_match_vni() now tries to match both the labels within the route
Fix3: route_match_vni() should return noop when it encounters an mpls based
route. For this, route_map library should handle this 3rd state: RMAP_NOOP.
Related fix : Extract tunnel type
This fix relies on PR 4314 #4314 to extract the tunnel type from bgp extended
communities. The information about the route's tunnel type (vxlan or mpls)
is needed to apply "match evpn vni xx" rule. This rule is applicable to
vxlan routes, and should exit safely for mpls based evpn routes.
lib: Introducing a 3rd state for route-map match cmd: RMAP_NOOP
Introducing a 3rd state for route_map_apply library function: RMAP_NOOP
Traditionally route map MATCH rule apis were designed to return
a binary response, consisting of either RMAP_MATCH or RMAP_NOMATCH.
(Route-map SET rule apis return RMAP_OKAY or RMAP_ERROR).
Depending on this response, the following statemachine decided the
course of action:
State1:
If match cmd returns RMAP_MATCH then, keep existing behaviour.
If routemap type is PERMIT, execute set cmds or call cmds if applicable,
otherwise PERMIT!
Else If routemap type is DENY, we DENYMATCH right away
State2:
If match cmd returns RMAP_NOMATCH, continue on to next route-map. If there
are no other rules or if all the rules return RMAP_NOMATCH, return DENYMATCH
We require a 3rd state because of the following situation:
The issue - what if, the rule api needs to abort or ignore a rule?:
"match evpn vni xx" route-map filter can be applied to incoming routes
regardless of whether the tunnel type is vxlan or mpls.
This rule should be N/A for mpls based evpn route, but applicable to only
vxlan based evpn route.
Also, this rule should be applicable for routes with VNI label only, and
not for routes without labels. For example, type 3 and type 4 EVPN routes
do not have labels, so, this match cmd should let them through.
Today, the filter produces either a match or nomatch response regardless of
whether it is mpls/vxlan, resulting in either permitting or denying the
route.. So an mpls evpn route may get filtered out incorrectly.
Eg: "route-map RM1 permit 10 ; match evpn vni 20" or
"route-map RM2 deny 20 ; match vni 20"
With the introduction of the 3rd state, we can abort this rule check safely.
How? The rules api can now return RMAP_NOOP to indicate
that it encountered an invalid check, and needs to abort just that rule,
but continue with other rules.
As a result we have a 3rd state:
State3:
If match cmd returned RMAP_NOOP
Then, proceed to other route-map, otherwise if there are no more
rules or if all the rules return RMAP_NOOP, then, return RMAP_PERMITMATCH.
Donald Sharp [Tue, 9 Jul 2019 00:00:43 +0000 (00:00 +0000)]
pimd: Always create upstream reference when adding channel oil
Modify the code to create an upstream reference whenever the code
creates an channel_oil via the pim_mroute.c code. This code also
starts a keep alive timer to clean up the reference if we do
nothing with it after the normal time.
I've left alone the source->channel_oil creation because these
are kept and tracked independently already.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Donald Sharp [Wed, 17 Jul 2019 00:41:01 +0000 (20:41 -0400)]
pbrd: Do not install nexthop group until we have nexthops
The creation of a nexthop group results in a callback with
just the nexthop group name. At this point in time we
do not have any nexthop information so there is nothing to
install.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Donald Sharp [Tue, 16 Jul 2019 12:27:31 +0000 (08:27 -0400)]
staticd: Track state of where we are and limit installs/updates to min
Track the state of the route and how we have installed it or not.
This commit limits the number of installs/updates/deletes to a
minimum number instead of repeated sends to zebra.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Donald Sharp [Tue, 16 Jul 2019 11:31:18 +0000 (07:31 -0400)]
staticd: Setup nexthop tracking instead of installing route
Route installs should be handled by the setup of nexthop tracking
instead of installing the route and then installing the nexthop
tracking again ( and reinstalling the route )
This change makes routes be installed one time.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
projects / matthieu / frr.git / log