vdhingra [Tue, 13 Aug 2019 05:56:38 +0000 (22:56 -0700)]
zebra : blackhole_type was not set correctly in recursive routes
If there is a recursive route resolved over blackhole route, then
the resolved blackhole_type is not getting set correctly.
This fix updates the bh_type correctly for resursive routes.
bgpd: Optimizing route-map's processing of dependencies.
Say for eg., 256 prefix-list entries are pasted to VTYSH.
This results in BGP processing the events for several minutes.
BGPD starts a timer for 5 seconds when the first dependency configuraion
is received. On timer expiry, BGP process dependent route-maps.
After this processing, BGPD reads the configurations received in the
next 5 seconds and then re-processes the route-maps from the beginning.
This cyclic re-processing consumes time and CPU cycles.
Instead of starting a timer when the first configuration is received,
everytime a configuration is received, the existing timer is reset.
This would mean that all the configurations are read first before the timer
expires. This eliminates the cyclic re-processing.
A race condition causes the failure.
The function "make_info()" sets the path info's peer to
bgp instance's "peer_self" which is created when BGP is first
configured and deleted only when BGP is brought down completely.
A race condition causes the bgp instances's "peer_self" to be
removed before the routes are being pulled off from the aggregate
address.
If the bgp instance's "peer_self" is NULL or, if BGP is being deleted,
the aggregate route must not be reinstalled.
bgpd: Standard large-communities CLI does not return error when it's configured with reg-ex.
The CLI to configure the standard format large-communities attribute
accepts regular expressions as well.
For ex., the below configuration is accepted.
"bgp large-community-list standard TEST permit 1:1 100:*"
The code to parse the large-communities does identify the configuration
as invalid however, error returned isn't processed.
The code has to be modified to handle the error.
Ameya Dharkar [Fri, 9 Aug 2019 22:21:27 +0000 (15:21 -0700)]
Zebra: Incorrect L3VNI for FPM rtmsg for EVPN RT-5 prefix
We used the vrf_id in the rtm_table field of the netlink rtmsg to fetch L3VNI.
But, now we program table_id to rtm_table field instead of vrf_id.
Thus, L3VNI fetched using rtm_table is incorrect.
Chirag Shah [Thu, 8 Aug 2019 17:43:49 +0000 (10:43 -0700)]
zebra: fix advertise svi ip as macip route
PR #3745 added EVPN feature to advertise individual
SVI-IPs as MAC-IP routes.
Fix a condition in zebra to send MAC and IP pair
to bgpd when the feature is enabled.
Testing Done:
Originator VTEP:
TORC11:~# ip -br addr show VxU-1002
VxU-1002 UP 45.0.2.2/24 2001:fee1:0:2::2/64
show bgp l2vpn evpn vni 1004
VNI: 1004 (known to the kernel)
Type: L2
Tenant-Vrf: default
RD: 27.0.0.11:3
Advertise-svi-macip : Yes
Import Route Target:
10:1004
Export Route Target:
10:1004
Remote vtep evpn route output for 45.0.4.2:
BGP routing table entry for 27.0.0.11:3:[2]:[0]:[48]:[00:02:00:00:00:2f]:[32]:[45.0.4.2]
Paths: (2 available, best #1)
Advertised to non peer-group peers:
MSP1(uplink-1) MSP2(uplink-2)
Route [2]:[0]:[48]:[00:02:00:00:00:2f]:[32]:[45.0.4.2] VNI 1004
64435 65546
36.0.0.11 from MSP1(uplink-1) (27.0.0.9)
Origin IGP, valid, external, bestpath-from-AS 64435, best (First path received)
Extended Community: RT:10:1004 ET:8
Last update: Thu Aug 8 18:09:13 2019
Signed-off-by: Chirag Shah <chirag@cumulusnetworks.com>
Dinesh Dutt [Thu, 8 Aug 2019 02:58:18 +0000 (02:58 +0000)]
bgpd: Display received and advertised EVPN routes from neighbors
"show bgp l2vpn evpn neighbors <neighbor> [advertised-routes|routes]' did
not work due to various bugs. First, the command only accepted IPv4
addresses as valid neighbor ID, thereby rejecting unnumbered BGP and IPv6
neighbor address. Second, the SAFI was hardcoded to MPLS_VPN even though
we were passing the safi. Third, "all" made no sense in the command context
and to make the command uniform across all address families, I removed the
"all" keyword from the command.
Donald Sharp [Thu, 8 Aug 2019 01:45:02 +0000 (21:45 -0400)]
staticd: Fix blackhole routes being installed
When we are ready to install a route, we were treating
blackhole routes as something that should be nexthop tracked
which does not work as well as one would expect.
Additionally add some test code to show that this actually
fixes this issue.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
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.
Renato Westphal [Tue, 6 Aug 2019 18:53:42 +0000 (15:53 -0300)]
doc: suggest the installation of the libcap development library
All FRR Linux packages are built using libcap-dev (or libcap-devel)
installed in the system. Update the build instructions to suggest
FRR developers to do the same. The main motivation for this is that
the seteuid() system call is too expensive and overall less secure
compared to using the Linux capabilities framework.
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>
projects / matthieu / frr.git / log