Mark Stapp [Tue, 6 Aug 2019 18:59:01 +0000 (14:59 -0400)]
docs: Add notes about limited MPLS-TE support
Add notes to several docs about the limits to FRR's current
MPLS-TE support, which is limited to some routing protocol
LSA/TLV support. It wasn't very clear that FRR does not offer
a complete TE/RSVP-TE solution at this time.
Also removed some stale info about configure script options.
David Lamparter [Tue, 6 Aug 2019 14:54:52 +0000 (16:54 +0200)]
*: fix ctype (isalpha & co.) casts
The correct cast for these is (unsigned char), because "char" could be
signed and thus have some negative value. isalpha & co. expect an int
arg that is positive, i.e. 0-255. So we need to cast to (unsigned char)
when calling any of these.
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
Quentin Young [Thu, 1 Aug 2019 17:38:46 +0000 (17:38 +0000)]
vrrpd: try to bind interfaces on if_down notifications
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>
Quentin Young [Thu, 1 Aug 2019 17:37:05 +0000 (17:37 +0000)]
zebra: send interface updates when down
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>
Don Slice [Wed, 31 Jul 2019 16:38:49 +0000 (12:38 -0400)]
bgpd: resolve memleak on show bgp vrf all ipv6 unicast summary json
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>
This fix is wrong too. The zclient->redist & ->mi_redist arrays are
accessed past their size for any external route that is not 0.0.0.0/0.
Also, it is incorrect to check default_information for DEFAULT_ROUTE
since that's "originate always".
Signed-off-by: David Lamparter <equinox@diac24.net>
- 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>
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>
Chirag Shah [Fri, 26 Jul 2019 21:57:59 +0000 (14:57 -0700)]
zebra: del auto mac when vni is down
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>
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>
projects / mirror / frr.git / log