A new command is available under SAFI_MPLS_VPN:
With this command, the BGP vpnvx prefixes received are
not kept, if there are no VRF interested in importing
those vpn entries.
A soft refresh is performed if there is a change of
configuration: retain cmd, vrf import settings, or
route-map change.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
The bgp_nexthop must be the source bgp structure. It cannot be the
destination bgp one.
Use bgp_orig source bgp struct by default.
Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
The "struct bgp" variable names in the mplsvpn bgp code do not
explicitly say whether they refer to a source or destination BGP
instance. Some variable declarations are commented out with "from" and
"to" but this does not avoid confusion within the functions. The names
of "struct bgp" variables are reused in different functions but their
names sometimes refer to a source instance and sometimes to a
destination instance.
Rename the "struct bgp" variable names to from_bgp and to_bgp.
Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
Prior to this fix, the magic number (16) was used regardless of what value
the user specified for func-bits. With this fix, user-specified values are
handled appropriately.
Signed-off-by: Nobuhiro MIKI <nmiki@yahoo-corp.jp>
Until now, it has been hard-coded that the position at which the label
is inserted is from the 64th bits. Therefore, when the Locator prefix
was not /64, incorrect SIDs were generated. Also, SIDs are generated
in duplicate on Lines 604 & 613 in bgpd/bgp_mplsvpn.c.
In this patch, the position where the label is inserted is calculated
based on the sum of block_bits_length and node_bits_length (i.e., the
user-specified Locator prefix length). In addition, SID generation is
performed at one location in alloc_new_sid.
Signed-off-by: Nobuhiro MIKI <nmiki@yahoo-corp.jp>
Since additional information such as block_bits_length is needed to
generate SIDs properly, the type of elements in srv6_locator_chunks
list is extended from "struct prefix_ipv6 *" to
"struct srv6_locator_chunk *". Even in terms of variable name,
"struct srv6_locator_chunk *" is appropriate.
Signed-off-by: Nobuhiro MIKI <nmiki@yahoo-corp.jp>
This patch adds transpostion_offset and transposition_len to bgp_sid_info,
and transposes SID only at bgp_zebra_announce.
Signed-off-by: Ryoga Saito <ryoga.saito@linecorp.com>
This patch changes the format of the Prefix-SID advertised by
bgpd. In current implementation, transposed SIDs were
advertised, which caused two problems:
1. bgpd that receives SRv6 L3VPN routes whose SID is
transposed couldn't put bgp_attr_srv6_l3vpn whose those
routes together. This leads extra memory consumption.
2. Some implementation will reject a route with transposed SID.
This will affect interoperability.
For those reasons, in this patch, instead of advertising
transposed SID, we change it to advertise the locator of SID.
Signed-off-by: Ryoga Saito <ryoga.saito@linecorp.com>
For the later patches, this patch changes the behavior of alloc_new sid
so that bgpd record not only SID for VRF, but also Locator of SID.
Signed-off-by: Ryoga Saito <ryoga.saito@linecorp.com>
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>
