two bgp vrf instance has vrf route leak configured,
when a source vrf x is deleted, its leaked routes are cleaned
up from the destination and vpn table.
With this change when a source bgp instance is reconfigured,
export its routes back to destination vrfs where it is configured
as leak.
Ticket:CM-20534 CM-24484
Reviewed By:
Testing Done:
configure vrf leak between two vrf intances,
delete and readd source vrf and checked its routes
exported to vpn table and leaked vrfs table.
Signed-off-by: Chirag Shah <chirag@cumulusnetworks.com>
A VRF leak is configured between two vrfs,
bgp VRF X and VRF Y.
When a bgp VRF X is removed, unimport bgp VRF X routes
from VPN and VRF Y.
If VRF X is also importing from bgp VRF Y, remove X from
export list of Y and do required route cleanup.
Ticket:CM-20534 CM-24484
Reviewed By:
Testing Done:
Before deleteing vrf1002:
nl1# show ip route vrf vrf1003 9.9.2.4/32
Routing entry for 9.9.2.4/32
Known via "bgp", distance 200, metric 0, vrf vrf1003, best
Last update 00:04:51 ago
* 200.2.8.2, via swp1.2(vrf vrf1002)
* 200.2.9.2, via swp2.2(vrf vrf1002)
* 200.2.10.2, via swp3.2(vrf vrf1002)
Instance vrf1003:
This VRF is importing IPv4 Unicast routes from the following VRFs:
vrf1002
Import RT(s): 6.0.2.9:2
This VRF is exporting IPv4 Unicast routes to the following VRFs:
vrf1002
RD: 6.0.3.9:3
Export RT: 6.0.3.9:3
After deleting vrf1002:
nl1(config)# no router bgp 64902 vrf vrf1002
nl1# show ip route vrf vrf1003 9.9.2.4/32
Routing entry for 9.9.2.4/32
Known via "bgp", distance 20, metric 0, vrf vrf1003, best
Last update 00:00:32 ago
* 200.3.8.2, via swp1.3
* 200.3.9.2, via swp2.3
* 200.3.10.2, via swp3.3
Instance vrf1003:
This VRF is importing IPv4 Unicast routes from the following VRFs:
vrf1002
Import RT(s):
This VRF is not exporting IPv4 Unicast routes to any other VRF
nl1# show bgp ipv4 vpn
No BGP prefixes displayed, 0 exist
Readd vrf1002:
points back to source vrf
nl1# show ip route vrf vrf1003 9.9.2.4/32
Routing entry for 9.9.2.4/32
Known via "bgp", distance 200, metric 0, vrf vrf1003, best
Last update 00:00:21 ago
* 200.2.8.2, via swp1.2(vrf vrf1002)
* 200.2.9.2, via swp2.2(vrf vrf1002)
* 200.2.10.2, via swp3.2(vrf vrf1002)
Signed-off-by: Chirag Shah <chirag@cumulusnetworks.com>
A router-id change that isn't explicitly configured (a change
from zebra, for example) should not replace a configured vpn
RD/RT.
Signed-off-by: Mark Stapp <mjs@voltanet.io>
The label value is set to MPLS_LABEL_NONE at the start
of the function and we never modify it, testing it for
BGP_PREVENT_VRF_2_VRF_LEAK equality will never be true
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
VRF route leak auto RD and RT uses router-id,
when a router-id changes for a bgp instance, change
associated vpn RD and RT values. Withdraw
old RD/RT routes from vpn and with new
RD/RT values advertise new routes to vpn.
One of the sceanrio is restarting frr:
A router-id change may not have reflected
for bgp vrf instance X, while import vrf X
under bgp vrf instance Y.
Once router-id changes for bgp VRF X,
change RD and RTs from export VRF and
imported VRFs. Readvertise routes with new
values to VPN.
Ticket:CM-24149
Reviewed By:CCR-8394
Testing Done:
Validated via configured multiple bgp VRF instances
and enable route leaks among them, restart frr
and all instance received correct RD and RT values.
Checked 'show bgp vrf all ipv4 unicast route-leak'
and vpn table 'show bgp ipv4 vpn all' output.
Signed-off-by: Chirag Shah <chirag@cumulusnetworks.com>
Refine check that looks for VPN routes imported into a VRF because
a VRF can have other imported routes too like IPv4 and IPv6 unicast
routes sourced from EVPN type-2 and type-5 routes.
Signed-off-by: Vivek Venkatraman <vivek@cumulusnetworks.com>
Reviewed-by: Anuradha Karuppiah <anuradhak@cumulusnetworks.com>
Reviewed-by: Donald Sharp <sharpd@cumulusnetworks.com>
The check on which routes are exportable is a superset, so remove the
route sub-type checks. Also, this change is needed to handle EVPN-imported
leaked routes correctly.
Signed-off-by: Vivek Venkatraman <vivek@cumulusnetworks.com>
IPv4 or IPv6 unicast routes which are imported from EVPN routes
(type-2 or type-5) and installed in a BGP instance and then leaked
do not need any nexthop tracking, as any tracking should happen in
the source instance.
Signed-off-by: Vivek Venkatraman <vivek@cumulusnetworks.com>
Reviewed-by: Anuradha Karuppiah <anuradhak@cumulusnetworks.com>
Reviewed-by: Donald Sharp <sharpd@cumulusnetworks.com>
A non-imported route or a non-VPN imported route is a candidate to be
exported into the VPN routing table for leaking to other BGP instances
or advertisement into BGP/MPLS VPN. The former is a local or learnt
IPv4 or IPv6 route. The latter is an IPv4 or IPv6 route that is based
on a received EVPN type-2 or type-5 route.
Implement a function to specify if a route can be exported into VPN
and use in the appropriate places.
Signed-off-by: Vivek Venkatraman <vivek@cumulusnetworks.com>
Reviewed-by: Anuradha Karuppiah <anuradhak@cumulusnetworks.com>
Reviewed-by: Donald Sharp <sharpd@cumulusnetworks.com>
BGP IPv6 routes should never contain the NEXT_HOP attribute
(MP_REACH_NLRI should be used instead).
This reverts commit 75cd35c697.
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
For VRF route leak, enable route map filter based
on "source-vrf" check.
Implemented match filter rule for "source-vrf" which
compares leaked routes original vrf_id (where it leaked from)
during importing into target VRF.
Ticket:CM-23776
Reviewed By:
Testing Done:
Configure vrf route leak from vrf1 to vrf2,
configure import vrf under vrf2 along with route-map
with source-vrf filter.
Add and remove source-vrf filter and checked routes
were added and removed to vrf2 table via vpn (default) table.
Signed-off-by: Chirag Shah <chirag@cumulusnetworks.com>
When using an `import vrf` mechanism we are marking
the vrf label as BGP_PREVENT_VRF_2_VRF_LEAK, and then sending
this down to zebra. Since zebra knows nothing about this special
value, convert it to a value that it does know MPLS_LABEL_NONE.
This bug was introduced by: 13b7e7f007
And shows up with this error message in the zebra log:
2019/01/09 08:25:16 ZEBRA: Extended Error: Label >= configured maximum in platform_labels
2019/01/09 08:25:16 ZEBRA: [EC 4043309093] netlink-cmd (NS 0) error: Invalid argument, type=RTM_NEWROUTE(24), seq=8, pid=3321825991
2019/01/09 08:25:16 ZEBRA: [EC 4043309103] LSP Install Failure: 4294967294
And zebra kept the label as:
donna.cumulusnetworks.com# show mpls table
Inbound Outbound
Label Type Nexthop Label
-------- ------- --------------- --------
-2 BGP GREEN
-2 BGP BLUE
After this fix, neither the labels are stored in zebra nor do we see
the log error message.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Fully revert the rest of the e23b9ef6d2 commit as that it was breaking
route leaking between vrf's.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
previous change was to fix rnh module in Zebra for leaked routes
this reverts that fix, so probably reintroduces the problem.
Signed-off-by: Lou Berger <lberger@labn.net>
The bgp_info data is stored as a void pointer in `struct bgp_node`.
Abstract retrieval of this data and setting of this data
into functions so that in the future we can move around
what is stored in bgp_node.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Problems were reported with the name of the default vrf and the
default bgp instance being different, creating confusion. This
fix changes both to "default" for consistency.
Ticket: CM-21791
Signed-off-by: Don Slice <dslice@cumulusnetworks.com>
Reviewed-by: CCR-7658
Testing: manual testing and automated tests before pushing
Do a straight conversion of `struct bgp_info` to `struct bgp_path_info`.
This commit will setup the rename of variables as well.
This is being done because `struct bgp_info` is not descriptive
of what this data actually is. It is path information for routes
that we keep to build the actual routes nexthops plus some extra
information.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Problem reported that some bgp and ospf json commands did not return
any json output at all if the bgp/ospf instance did not exist.
Additionally, some bgp and ospf json commands did not return any json
output if the instance existed but no neighbors were defined. This
fix makes these commands more consistent in returning empty braces for
json output and issue a message if not using json output. Additionally,
made the flag "use_json" a bool to make it consistent since previously,
it had been defined as an int, char, u_char, and bool at various places.
Ticket: CM-21040
Signed-off-by: Don Slice <dslice@cumulusnetworks.com>
Problem reported that when systemctl restart networking or switchd
performed, not all imported prefixes were successfully restored.
Ticket: CM-21684
Signed-off-by: Don Slice <dslice@cumulusnetworks.com>
The warning given by PVS-Studio is related to per-element overflow (there is
no real overflow, because of how elements are mapped in the union). This
same warning is typically reported by Coverity, too.
Signed-off-by: F. Aragon <paco@voltanet.io>
Issue 2473
VRF-VPN route-leaking configuration commands assumed existence of
default bgp instance. If a non-default vrf configuration occurred
before the default vrf configuration, it would result in a (NULL)
dereference to the non-existent default vrf.
This change 1) detects non-existence of default vrf and skips corresponding
RIB updating that normally occurs during configuration changes of the
route-leaking parameters; and 2) when the default bgp instance is defined,
runs the deferred RIB updating.
In vpn_leak_to_vrf_update_all(), replace early return if bgp_vpn is NULL
with assert, as the former would lead to subtly wrong RIB contents. The
underlying issue that led to commit 73aed5841a
should be fixed by the above changes.
Signed-off-by: G. Paul Ziemba <paulz@labn.net>
Issue 2381: interface based routes not marked "up" when they originate
in zebra, redistributed to bgp vrf, then imported to vpn and then
imported by another vrf.
Routes that are redistributed into BGP from zebra should not get
nexthop tracking (the assumption is that the originating protocol
is responsible to export or withdraw the route according to its own
notion of nexthop status).
The vpn-vrf route-leaking code checks the source route sub_type to
decide whether to use nexthop tracking on the resulting leaked route.
A route that is redistributed from zebra into bgp will have
sub_type==BGP_ROUTE_REDISTRIBUTE. If it is leaked to the vpn RIB,
the resulting vpn RIB route will have sub_type==BGP_ROUTE_IMPORTED.
If THAT vpn route is leaked to another vrf, the original code will
examine only the leak-source route sub_type and, since it is
not BGP_ROUTE_REDISTRIBUTE, will wrongly try to use nexthop tracking
on the new route in the final vrf.
This change modifies the leak function to track back up the
parent links to the ultimate parent of the leak source route
and look at that route's sub_type instead.
Signed-off-by: G. Paul Ziemba <paulz@labn.net>
There exists cases where we will attempt to hard delete
the bgp instance( say a `no router bgp` is issued )
when we have vrf route leaking. If we do have this
lock the bgp instance of the originator and do not
let it be deleted out from under us until we are
finished processing.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
There exists code paths where the rn was being used after free.
This eliminates these code paths.
Fixes: CM-21019
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
The bgp_info_extra_get call gets the extra pointer, which
is also needed for the setlabels() call, so move the call
to above the setlabels.
Also remove an unnecessary test of a pointer since we
have already dereferenced it by the time we are testing
for it's existence.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Imported routes in a VRF routing table have a reference to their parent
route entry which resides in the EVPN or IPVPN routing table. Ensure that
this reference uses appropriate locking so that the parent entry doesn't
get freed prematurely.
Signed-off-by: Vivek Venkatraman <vivek@cumulusnetworks.com>
Reviewed-by: Donald Sharp <sharpd@cumulusnetworks.com>
(cherry picked from commit 13cb6b22ba9d558b1b4a1e8752f63f13242462a7)
Conflicts:
bgpd/bgp_mplsvpn.c
Ticket: CM-20471
Testing Done:
a) Ran vrf_route_leak tests without fix and hit crash, ran twice with fix
and did not see the crash.
b) Ran evpn-smoke and ensured there were no new failures.
The vrf 2 vrf route leaking auto-derives RD and RT and
installs the routes into the appropriate vpn table.
These routes when a operator configured ipv[4|6] vpn
neighbors were showing up off box. The RD and RT
values choosen are localy significant but globaly
useless and may cause confusion.
Put a special bit of code in to notice that we
should not be advertising these routes off box.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
This commit reverts part of ceb800e0edb9f8979cebb1e6be9497d787bee39c
as it was found to be causing issues in upstream CI.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Note that when we are importing vrf EVA into vrf DONNA
we must keep track of all the vrfs EVA is being
exported into and we must also keep track of all the vrf's
that DONNA is receiving data from as well.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Connected routes redistributed into BGP as well as IPv4 routes with IPv6
link-local next hops (RFC 5549) need information about the associated
interface in BGP if they are candidates to be leaked into another VRF. In
the absence of route leaking, this was not necessary. Introduce the
appropriate mechanism and ensure this is used during route install (in
the target VRF).
Ticket: CM-20343, CM-20382
Testing done:
1. Manually verified failed scenarios and some additional ones - logs
in the tickets.
2. Ran bgp-min and evpn-min - results are good.
3. Ran vrf smoke - has some failures, but none which look new
Signed-off-by: Vivek Venkatraman <vivek@cumulusnetworks.com>
Ensure that when a route redistributed into a VRF is subsequently
deleted, it is properly removed from the VPN table (if exported)
so that it can be removed from other VRFs and withdrawn from
L3VPN peers.
Ticket: CM-20345
Signed-off-by: Vivek Venkatraman <vivek@cumulusnetworks.com>
The VRF routes exported to the global VPN table must not be
imported routes. It is not necessary to check if they originate
in the global VPN instance as that doesn't hold good for VRF-to-
VRF route-leaking. Merely checking that they are not imported
should handle both L3VPN and VRF-to-VRF route-leaking use cases.
Ticket: CM-20283
Signed-off-by: Vivek Venkatraman <vivek@cumulusnetworks.com>
Implement fixes for route leaking between VRFs through BGP, especially for
the scenario where routes are leaked from a VRF X to multiple other VRFs.
This include making sure that import and export happen via the global VPN
table, setting RD correctly and proper handling for multiple import/export.
Ticket: CM-20256
Signed-off-by: Vivek Venkatraman <vivek@cumulusnetworks.com>
Reviewed-by: Donald Sharp <sharpd@cumulusnetworks.com>
When routes are injected into the VPN table and then leaked into candidate
VRFs, the source should be the default instance. Also, the loop check when
withdrawing routes from a VRF should be that the route's origin isn't that
VRF; this handles VRF route leaking also and is consistent with checks in
other places.
Signed-off-by: Vivek Venkatraman <vivek@cumulusnetworks.com>
(cherry picked from commit 0149d2848c59bfb3277592caf0a5d5e07a2de872)
Ticket: CM-20256
add the `import vrf XXXX` command
router bgp 4 vrf DONNA
<config>
!
router bgp 4 vrf EVA
<config>
address-family ipv4 uni
import vrf DONNA
!
!
This command will allow for vrf EVA to specify that it would like
to receive the routes from vrf DONNA into it's table.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
bgp route extra->bgp_orig for routes leaked vpn->vrf should be set
to original extra->bgp_orig if it is set, not vpn's bgp instance.
The initial leak is OK because it goes through a loopback path
in the vrf->vpn leaking code, but it is possible later re-leaks (e.g.,
if the destination vrf's leak configuration is changed) could
set the wrong extra->bgp_orig and break the route's nexthop.
Signed-off-by: G. Paul Ziemba <paulz@labn.net>
given a configuration such as this:
router bgp 7777 vrf A
address-family ipv4 unicast
route-map vpn import FOO
import vpn
or this:
router bgp 7777 vrf A
address-family ipv4 unicast
rd vpn export 1:3
rt vpn export 1:100
route-map vpn export FOO
export vpn
Previous code allowed leaking if the named FOO route-map was not defined.
Since the configuration is logically incomplete, if a route-map is named
for "vpn export" or "vpn import" but is not defined, leaking should not
occur until the route-map is defined.
This changeset implements the correct behavior.
Signed-off-by: G. Paul Ziemba <paulz@labn.net>
vpn-vrf leak code was not triggering a BGP update or an announce to zebra
if a route's labels changed. This changeset corrects that problem.
Signed-off-by: G. Paul Ziemba <paulz@labn.net>
Add support for CLI "auto" keyword in vrf->vpn export label:
router bgp NNN vrf FOO
address-family ipv4 unicast
label vpn export auto
exit-address-family
Signed-off-by: G. Paul Ziemba <paulz@labn.net>
In general, routes leaked from the vpn rib to a vrf include any
labels that might have been attached to the vpn route. VRF routes
that have labels attached require a label-switched path and therefore
require nexthops with labels in order to be marked valid by the
nexthop-tracking logic.
However, some routes in the vpn RIB originated in vrfs local to this
router. Even though they may have labels, we must omit the labels
when leaking to a vrf because traffic using those resulting routes
will be carried by this router via IP routing and not label switching.
The nexthops of these routes do not need to indicate a label-switched
path, and thus the routes should be marked valid even when their nexthops
do not have labels.
This changeset omits labels from vpn->vrf leaked routes when the ultimate
source of the vpn route was a local vrf.
Signed-off-by: G. Paul Ziemba <paulz@labn.net>
Routes that have labels must be sent via a nexthop that also has labels.
This change notes whether any path in a nexthop update from zebra contains
labels. If so, then the nexthop is valid for routes that have labels.
If a nexthop update has no labeled paths, then any labeled routes
referencing the nexthop are marked not valid.
Add a route flag BGP_INFO_ANNC_NH_SELF that means "advertise myself
as nexthop when announcing" so that we can track our notion of the
nexthop without revealing it to peers.
Signed-off-by: G. Paul Ziemba <paulz@labn.net>
The following types are nonstandard:
- u_char
- u_short
- u_int
- u_long
- u_int8_t
- u_int16_t
- u_int32_t
Replace them with the C99 standard types:
- uint8_t
- unsigned short
- unsigned int
- unsigned long
- uint8_t
- uint16_t
- uint32_t
Signed-off-by: Quentin Young <qlyoung@cumulusnetworks.com>
This commit is relying on bgp vpn-policy. It is needed to configure
several bgp vrf instances, and in each of the bgp instance, configure
the following command under address-family ipv4 unicast node:
[no] rt redirect import RTLIST
Then, a function is provided, that will parse the BGP instances.
The incoming ecommunity will be compared with the configured rt redirect
import ecommunity list, and return the VRF first instance of the matching
route target.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
- vpn_leak_to_vpn_active(): check instance type
- vpn_leak_prechange(): qualify with test for active
- vpn_leak_postchange(): remove duplicated call to
vpn_leak_from_vrf_update_all()
- bgp_vty.c: Avoid null-pointer dereference for command "no rt vpn import"
Signed-off-by: G. Paul Ziemba <paulz@labn.net>
PR #1739 added code to leak routes between (default VRF) VPN safi and unicast RIBs in any VRF. That set of changes included temporary CLI including vpn-policy blocks to specify RD/RT/label/&c. After considerable discussion, we arrived at a consensus CLI shown below.
The code of this PR implements the vpn-specific parts of this syntax:
router bgp <as> [vrf <FOO>]
address-family <afi> unicast
rd (vpn|evpn) export (AS:NN | IP:nn)
label (vpn|evpn) export (0..1048575)
rt (vpn|evpn) (import|export|both) RTLIST...
nexthop vpn (import|export) (A.B.C.D | X:X::X:X)
route-map (vpn|evpn|vrf NAME) (import|export) MAP
[no] import|export [vpn|evpn|evpn8]
[no] import|export vrf NAME
User documentation of the vpn-specific parts of the above syntax is in PR #1937
Signed-off-by: G. Paul Ziemba <paulz@labn.net>
In bgp_update_receive the first thing we do is establish
that the peer->status is Established. We then do a bunch
of work and call bgp_nlri_parse where we break out for
each address family. Each AFI is then checking for
being peer->status is Established again. There is no
point in checking this again.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
- add "debug bgp vpn label" CLI
- improved debug messages for "debug bgp bestpath"
- send vrf label to zebra after zebra informs bgpd of vrf_id
- withdraw vrf_label from zebra if zebra informs bgpd that vrf_id is disabled
Signed-off-by: G. Paul Ziemba <paulz@labn.net>
When doing symmetric routing,
EVPN type-2 (MACIP) routes need to be advertised with two labels (VNIs)
the first being the L2 VNI (identifying the VLAN) and
the second being the L3 VNI (identifying the VRF).
The receive processing needs to handle one or two labels too.
Ticket: CM-18489
Review: CCR-6949
Testing: manual and bgp/evpn/mpls smoke
Signed-off-by: Vivek Venkatraman <vivek@cumulusnetworks.com>
Signed-off-by: Daniel Walton <dwalton@cumulusnetworks.com>
VARIABLE tokens must be all uppercase, this allows us to support WORD
tokens that begin with an uppercase letter. The "Null0" keyword is an
example of where this is needed.
The only VARIABLE we had that wasn't already all uppercase was
ASN:nn_or_IP-address:nn
This reverts commit c14777c6bf.
clang 5 is not widely available enough for people to indent with. This
is particularly problematic when rebasing/adjusting branches.
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
BGP Route Distinguisher (RD) handling is common for different flavors
of BGP VPNs such as BGP/MPLS IP VPNs (RFC 4364) and BGP EVPNs (RFC 7432).
Separate out the RD handling functions into its own files.
Note: No functional change introduced with this commit.
Signed-off-by: Vivek Venkatraman <vivek@cumulusnetworks.com>
Reviewed-by: Donald Sharp <sharpd@cumulusnetworks.com>
