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.
Signed-off-by: NaveenThanikachalam nthanikachal@vmware.com
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.
Signed-off-by: NaveenThanikachalam nthanikachal@vmware.com
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.
Signed-off-by: NaveenThanikachalam nthanikachal@vmware.com
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.
Signed-off-by: NaveenThanikachalam nthanikachal@vmware.com
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.
Instead, use nexthop->vrf_id to fetch the L3VNI.
Signed-off-by: Ameya Dharkar <adharkar@vmware.com>
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>
"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.
Signed-off-by: Dinesh G Dutt <ddps4u@gmail.com>
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>
The `show ip nht vrf EVA ...` command was not allowing you to only
specify the vrf anymore. Fix this:
robot# show ip nht vrf EVA
<cr>
A.B.C.D IPv4 Address
X:X::X:X IPv6 Address
robot# show ip nht vrf EVA 4.5.6.7
robot# show ip nht vrf EVA
robot#
Ticket: CM-25831
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Modify the cli to allow us to specify the [vrf NAME]
and also get rid of the usages of VRF_DEFAULT that we can.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Push out the pass in of struct eigrp to all functions
in eigrp_topology.c so we do not lookup the eigrp pointer.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Add the ability to parse `router eigrp AS [vrf NAME]` and
modify eigrp_lookup to actually handle a vrf_id for us.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
For those places where we can immediately transform the usage
of VRF_DEFAULT to eigrp->vrf_id do so.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
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.
Signed-off-by: Mark Stapp <mjs@voltanet.io>
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.
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
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>
