Dinesh Dutt [Mon, 12 Aug 2019 13:20:18 +0000 (13:20 +0000)]
bgpd: Display the imported route information for EVPN routes
For IPv4/v6 unicast routes that have been imported from EVPN Prefix
routes, display the information about where the route has been imported
from allowing for easy tracing of how a FIB/RIB entry got populated.
Signed-off-by: Dinesh G Dutt <5016467+ddutt@users.noreply.github.com>
vdhingra [Wed, 14 Aug 2019 07:18:43 +0000 (00:18 -0700)]
zebra : zebra redistributing IPV4 link local Addresses inconsistently.
Create an interface with IP4 link local address 169.254.0.131/25.
In BGP enable the redistribute connected. Now Zebra will not send
the route corresponding to IPV4 link local address. Now made this
interface down and up. Zebra sends the route to BGP.
Zebra should not send this route to BGP.
This Fix would make the behaviour consistent and would not send the
routes corresponding to IPV4 Link local addresses.
Dinesh G Dutt [Tue, 13 Aug 2019 16:29:40 +0000 (16:29 +0000)]
zebra: Ensure master's ifname is known, even if slave comes up first
In if_netlink.c, when an interface structure, ifp, is first created,
its possible for the master to come up after the slave interface does.
This means, the slave interface has no way to display the master's ifname
in show outputs. To fix this, we need to allow creation by ifindex instead
of by ifname so that this issue is handled.
Signed-off-by: Dinesh G Dutt<5016467+ddutt@users.noreply.github.com>
Dinesh G Dutt [Tue, 13 Aug 2019 16:28:16 +0000 (16:28 +0000)]
zebra: Display master interface names, not ifindices
When displaying the master interface's information in "show interface",
the display is currently the ifindex of the master interface. Make it
display the name as well as that is more useful than the name.
Signed-off-by: Dinesh G Dutt<5016467+ddutt@users.noreply.github.com>
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.
bgpd: Large-communities CLI accepts configurations sans attributes.
BGP large-communities configuration CLI is successful even if
the command is configured without any attributes.
For ex., the below commands are successful.
1) "bgp large-community-list standard TEST permit"
2) "bgp large-community-list standard TEST deny"
The CLI definitions that allow these erroneous configurations need to be removed.
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>
projects / mirror_frr.git / log