Description:
Incorrect behavior during best path selection for the imported routes.
Imported routes are always treated as eBGP routes.
Change is intended for fixing the issues related to
bgp best path selection for leaked routes:
- FRR does ecmp for the imported routes,
even without any ecmp related config.
If the same prefix is imported from two different VRFs,
then we configure the route with ecmp even without
any ecmp related config.
- Locally imported routes are preferred over imported
eBGP routes.
If there is a local route and eBGP learned route
for the same prefix, if we import both the routes,
imported local route is selected as best path.
- Same route is imported from multiple tenant VRFs,
both imported routes point to the same VRF in nexthop.
- When the same route with same nexthop in two different VRFs
is imported from those two VRFs, route is not installed as ecmp,
even though we had ecmp config.
- During best path selection, while comparing the paths for imported routes,
we should correctly refer to the original route i.e. the ultimate path.
- When the same route is imported from multiple VRF,
use the correct VRF while installing in the FIB.
- When same route is imported from two different tenant VRFs,
while comparing bgp path info as part of bgp best path selection,
we should ideally also compare corresponding VRFs.
See-also: https://github.com/FRRouting/frr/files/7169555/FRR.and.Cisco.VRF-Lite.Behaviour.pdf
Co-authored-by: Santosh P K <sapk@vmware.com>
Co-authored-by: Kantesh Mundaragi <kmundaragi@vmware.com>
Signed-off-by: Iqra Siddiqui <imujeebsiddi@vmware.com>
draft-ietf-bess-srv6-services-07 defines new SID structure Sub-Sub-TLV.
This patch adds SID structure information to bgp_attr_srv6_l3vpn. This
patch also defines default SID stucture used by following patches.
Signed-off-by: Ryoga Saito <contact@proelbtn.com>
Current implementation of SRv6 SID allocation algorithm sets most least
2 bytes. But, according to RFC8986, function bits is located in the next
to locator. New allocation alogirithm respects this format.
Signed-off-by: Ryoga Saito <contact@proelbtn.com>
In eusure_vrf_tovpn_sid, there is a check to ensure not to select both
SID index and SID auto mode. But, this current check is wrong and not
meaningful.
Signed-off-by: proelbtn <contact@proelbtn.com>
Some BGP updates received by BGP invite local router to
install a route through itself. The system will not do it, and
the route should be considered as not valid at the earliest.
This case is detected on the zebra, and this detection prevents
from trying to install this route to the local system. However,
the nexthop tracking mechanism is called, and acts as if the route
was valid, which is not the case.
By detecting in BGP that use case, we avoid installing the invalid
routes.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
Coverity scan found this issue. The bgp_vrf variable in
ensure_vrf_tovpn_sid() has already been derefed in all paths
at this point in time. No need to check for it existing
at this point.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
This commit make bgpd to support VPN SID advertisement
as BGP Prefix-SID when route-leaking from BGP-vrf instance
to BGP-vpn instance.
Signed-off-by: Hiroki Shirokura <slank.dev@gmail.com>
This commit add cil to configure BGP SRv6-VPN sid allocation.
Almost mechanism are based on BGP MPLS-VPN.
User can allocate and export sid with using following config.
Then bgpd try to allocate new SID to redirect vpn to vrf using
SRv6 localsid End.DT4/DT6. Currently linux kernel will regect
End.DT4 route install due to no-implementation.
(at-least today's FRR's ci kernel.)
So now we only supports BGP SRv6-VPNv6.
router bgp 1
segment-routing srv6
locator loc1
!
address-family ipv6 vpn
exit-address-family
!
router bgp 1 vrf vrf10
address-family ipv6 unicast
sid vpn export 1 !!(option1)!!
sid vpn export auto !!(option2)!!
exit-address-family
!
Signed-off-by: Hiroki Shirokura <slank.dev@gmail.com>
Description:
Route leaking from default vrf to non-default vrf stops after frr restart.
If the interface comes up after route leaking is configured,
in the case of vpn router id update, we delete the ecommunity value
and never reconfigure the rtlist.
This results in skipping route leak to non-default vrfs (vpn to vrf).
Router-id change that is not explicitly configured
(a change from zebra, frr restart) should not replace a configured vpn RD/RT.
Added few helpful debugs as well.
Co-authored-by: Santosh P K <sapk@vmware.com>
Co-authored-by: Kantesh Mundaragi <kmundaragi@vmware.com>
Signed-off-by: Abhinay Ramesh <rabhinay@vmware.com>
Problem:
Stale routes are seen in the bgp table(ipv4 and ipv6)
RCA:
Scenario1:
Interface down and withdraw is in-progress.
Router bgp config leading to re-leaking.
Now, withdraw-in-progress routes,
are again leaked to bgp vrf instance(s) importing routes.
Whenever we see an interface down
and corresponding address delete,
while withdrawal of exported routes is in-progress,
routes are marked as being removed and put into work queue.
‘router bgp’ config is updated, which triggers
bgp_vpn_leak_export; which exports routes from configured bgp vrf to VPN.
So withdraw-in-progress routes,
are again leaked to bgp vrf instance(s) importing routes; leading to stale routes.
Scenario2:
- 'no import vrf non-default-vrf’ [in the default vrf]
- bgp update from the peer withdrawing prefix [non-default vrf]
- 'import vrf non-default-vrf’ [configured in the default vrf]
While withdrawal of exported routes is in-progress,
routes are marked as being removed and put into work queue,
In the meantime, if import vrf is configured,
which exports routes from configured bgp vrf to VPN.
So withdraw-in-progress new routes,
are again leaked to bgp vrf instance(s) importing routes; leading to stale routes.
Fix:
Whenever leaking routes (leak_update),
for already existing routes,
skip the routes with bgp_path_info
marked as being removed.
Also added the log message for the return.
Co-authored-by: Santosh P K <sapk@vmware.com>
Co-authored-by: Kantesh Mundaragi <kmundaragi@vmware.com>
Signed-off-by: Abhinay Ramesh <rabhinay@vmware.com>
Description:
Imported/leak-from routes do not get withdrawn/removed
even if the source VRF is deleted.
Deleting and re-adding a tenant vrf, does not refresh the RIB.
Whenever VRF is deleted (bgp_vrf_disable),
currently we are withdrawing leak-from-vrf and
leak-to-vrf routes from vpn table for the vrf,
which is deleted.
But we are currently not withdrawing routes from leak-to vrfs.
We should also withdraw leak-to routes
from leak-to vrfs (calling vpn_leak_to_vrf_withdraw).
Co-authored-by: Santosh P K <sapk@vmware.com>
Co-authored-by: Kantesh Mundaragi <kmundaragi@vmware.com>
Signed-off-by: Abhinay Ramesh <rabhinay@vmware.com>
New and improved submission for this commit -- updated to accommodate
changes from 4027d19b0.
Adds support for 'rd all' matching for EVPN and L3VPN show commands.
Introduces evpn_show_route_rd_all_macip().
Cleans up some show commands to use SHOW_DISPLAY string constants.
Signed-off-by: Trey Aspelund <taspelund@nvidia.com>
Adds support for 'rd all' matching for EVPN and L3VPN show commands.
Introduces evpn_show_route_rd_all_macip().
Cleanup some show commands to use SHOW_DISPLAY string constants.
Signed-off-by: Trey Aspelund <taspelund@nvidia.com>
If we are using a nexthop for a MPLS VPN route make sure the
nexthop is over a labeled path. This new check mirrors the one
in validate_paths (where routes are enabled when a nexthop
becomes reachable). The check is introduced to the code path
where routes are added and the nexthop is looked up.
Signed-off-by: Pat Ruddy <pat@voltanet.io>
The `struct ecommunity` structure is using an int for a size value.
Let's switch it over to a uint32_t for size values since a size
value for data can never be negative.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
If we are attempting to store the bgp name for route
leaking and we find a match do not leak the memory.
Please note this is probably not really going to happen
ever.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
The route_map_object_t was being used to track what protocol we were
being called against. But each protocol was only ever calling itself.
So we had a variable that was only ever being passed in from route_map_apply
that had to be carried against and everyone was testing if that variable
was for their own stack.
Clean up this route_map_object_t from the entire system. We should
speed some stuff up. Yes I know not a bunch but this will add up.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
gcc 10 complains about some of our format specs, fix them. Use
atomic size_t in thread stats, to work around platform
differences.
Signed-off-by: Mark Stapp <mjs@voltanet.io>
==916511== 18 bytes in 2 blocks are definitely lost in loss record 7 of 147
==916511== at 0x483877F: malloc (vg_replace_malloc.c:307)
==916511== by 0x4BE0F0A: strdup (strdup.c:42)
==916511== by 0x48D66CE: qstrdup (memory.c:122)
==916511== by 0x1E6E31: bgp_vpn_leak_export (bgp_mplsvpn.c:2690)
==916511== by 0x28E892: bgp_router_create (bgp_nb_config.c:124)
==916511== by 0x48E05AB: nb_callback_create (northbound.c:869)
==916511== by 0x48E0FA2: nb_callback_configuration (northbound.c:1183)
==916511== by 0x48E13D0: nb_transaction_process (northbound.c:1308)
==916511== by 0x48E0137: nb_candidate_commit_apply (northbound.c:741)
==916511== by 0x48E024B: nb_candidate_commit (northbound.c:773)
==916511== by 0x48E6B21: nb_cli_classic_commit (northbound_cli.c:64)
==916511== by 0x48E757E: nb_cli_apply_changes (northbound_cli.c:281)
Signed-off-by: Chirag Shah <chirag@nvidia.com>
NLRI parsing for mpls vpn was missing several length checks that could
easily result in garbage heap reads past the end of nlri->packet.
Convert the whole function to use stream APIs for automatic bounds
checking...
Signed-off-by: Quentin Young <qlyoung@nvidia.com>
rfc 5701 is supported. it is possible to configure in bgp vpn, a list of
route target with ipv6 external communities to import. it is to be noted
that this ipv6 external community has been developed only for matching a
bgp flowspec update with same ipv6 ext commmunity.
adding to this, draft-ietf-idr-flow-spec-v6-09 is implemented regarding
the redirect ipv6 option.
Practically, under bgp vpn, under ipv6 unicast, it is possible to
configure : [no] rt6 redirect import <IPV6>:<AS> values.
An incoming bgp update with fs ipv6 and that option matching a bgp vrf,
will be imported in that bgp vrf.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
Remove mid-string line breaks, cf. workflow doc:
.. [#tool_style_conflicts] For example, lines over 80 characters are allowed
for text strings to make it possible to search the code for them: please
see `Linux kernel style (breaking long lines and strings)
<https://www.kernel.org/doc/html/v4.10/process/coding-style.html#breaking-long-lines-and-strings>`_
and `Issue #1794 <https://github.com/FRRouting/frr/issues/1794>`_.
Scripted commit, idempotent to running:
```
python3 tools/stringmangle.py --unwrap `git ls-files | egrep '\.[ch]$'`
```
Signed-off-by: David Lamparter <equinox@diac24.net>
This is the bulk part extracted from "bgpd: Convert from `struct
bgp_node` to `struct bgp_dest`". It should not result in any functional
change.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
Problem reported where bgp sessions were being torn down for ibgp
peers with the reason being optional attribute error. Found that
when a route was leaked, the RTs were stripped but the actual
EXTCOMMUNUNITY attribute was not cleared so an empty ecommunity
attribute stayed in the bgp table and was sent in updates.
Ticket: CM-30000
Signed-off-by: Don Slice <dslice@cumulusnetworks.com>
This macro is undefined if vnc is disabled, and while it defaults to 0,
this is still wrong and causes issues with -Werror
Signed-off-by: Quentin Young <qlyoung@cumulusnetworks.com>
Add new function `bgp_node_get_prefix()` and modify
the bgp code base to use it.
This is prep work for the struct bgp_dest rework.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Problem seen that if "import vrf route-map RMAP" was entered
without any vrfs being imported, the configuration was displayed
as "route-map vpn import RMAP". Additionally, if "import vrf
route-map" was entered without specifying a route-map name,
the command was accepted and the word "route-map" would be
treated as a vrf name. This fix resolves both of those issues
and also allows deleting the "import vrf route-map" line without
providing the route-map name.
Ticket: CM-28821
Signed-off-by: Don Slice <dslice@cumulusnetworks.com>
Some were converted to bool, where true/false status is needed.
Converted to void only those, where the return status was only false or true.
Signed-off-by: Donatas Abraitis <donatas.abraitis@gmail.com>
During VRF-to-VRF route leaking, strip any extraneous route targets. This
ensures that source-VRF-specific route targets or route targets that are
internally assigned for the VRF-to-VRF route leaking don't get attached
to the route in the target VRF.
Signed-off-by: Vivek Venkatraman <vivek@cumulusnetworks.com>
Reviewed-by: Donald Sharp <sharpd@cumulusnetworks.com>
Reviewed-by: Don Slice <dslice@cumulusnetworks.com>
If the default BGP instance is importing routes from another instance and
the latter has a router-id update, the update handler needs to handle the
default instance in a special way.
Signed-off-by: Vivek Venkatraman <vivek@cumulusnetworks.com>
Reviewed-by: Chirag Shah <chirag@cumulusnetworks.com>
Reviewed-by: Don Slice <dslice@cumulusnetworks.com>
Ticket: CM-26007
Reviewed By: CCR-9108
Testing Done: Detailed verification in 3.x
uint8_t * cannot be cast to uint32_t * unless the
pointed-to address is aligned according to uint32_t's
alignment rules. And it usually is not.
Signed-off-by: Santosh P K <sapk@vmware.com>
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>
