Mitesh Kanjariya <mitesh@marvel-07.cumulusnetworks.com>: Author Summary

Builds triggered by Mitesh Kanjariya <mitesh@marvel-07.cumulusnetworks.com>

Builds triggered by an author are those builds which contains changes committed by the author.
97
55 (57%)
42 (43%)

Breakages and fixes

Broken means the build has failed but the previous build was successful.
Fixed means that the build was successful but the previous build has failed.
50 (52% of all builds triggered)
8 (8% of all builds triggered)
-42
Build Completed Code commits Tests
FRR › TOPOPR › #234 1 year ago
zebra: vni [prefix-routes-only] should also be provided for the 'no' cmd
We have a command to enable symmetric routing only for type-5 routes.
This command is provided under vrf <> option in zebra as follows:
vrf <VRF>
  vni <VNI> [prefix-routes-only]
We need the corresponding no version of the command as well as follows:
vrf <VRF>
  no vni <VNI> [prefix-routes-only]

Signed-off-by: Mitesh Kanjariya <mitesh@cumulusnetworks.com>
bgpd: apply advertise ipv4 unicast route-map while advertising type-5 routes
A newly added ipv4/ipv6 route in BGP RIB might be advertised as type-5 EVPN route.
The user might have configured a route-map for advertising type-5 routes.
We need to apply this route-map while advertising ipv4/ipv6 routes as type-5.

Signed-off-by: Mitesh Kanjariya <mitesh@cumulusnetworks.com>
zebra: remote RMAC for EVPN ipv6 hosts should be programmed against the ipv4 nexthop
For ipv6 host, the next hop is conevrted to ipv6 mapped address.
However, the remote rmac should still be programmed with the ipv4 address.
This is how the entries will look in the kernel for ipv6 hosts routing.

vrf routing table:
ipv6 -> ipv6_mapped remote vtep on l3vni SVI

neigh table:
ipv6_mapped remote vtep -> remote RMAC

bridge fdb:
remote rmac -> ipv4 vtep tunnel

Signed-off-by: Mitesh Kanjariya <mitesh@cumulusnetworks.com>
bgpd: no advertise ipv6 unicast comand should unset the af_flags
no advertise ipv6 unicast command should unset the corresponding
af_flag in bgp_vrf rather than the vrf_flags.

Signed-off-by: Mitesh Kanjariya <mitesh@cumulusnetworks.com>
bgpd: write route-map to config for advertise type5 commands
We enable/disable type-5 routes by following commands:
advertise ipv4 unicast [route-map <route-map>]
advertise ipv6 commands [route-map <route-map>]
the route-map part was writtem to conf file.

Signed-off-by: Mitesh Kanjariya <mitesh@cumulusnetworks.com>
bgpd/zebra: use stream_putl/getl to send VNIs
Signed-off-by: Mitesh Kanjariya <mitesh@cumulusnetworks.com>
bgpd: enable neighbor-nexthop-self for l2vpn evpn address family
In the FRR implementation of EVPN,
eBGP leaf-spine peering for EVPN is fully supported by allowing
the next hop to be propagated and not rewritten at each hop.
There are other changes also related to route import to facilitate this.
However, propagating the next hop is not correct in some cases.
Specifically, if the DC is comprised of multiple PODs
with distinct intra-POD and inter-POD VxLAN tunnels,
EVPN routes received from an adjacent POD by a border/exit leaf
must be propagated into the local POD with the next hop rewritten (to self).

Signed-off-by: Mitesh Kanjariya <mitesh@cumulusnetworks.com>
bgpd: modify route install/withdraw logic for evpn type-5 routes in vrf
We install type-5 routes as ipv4/ipv6 unicast routes in the vrf table.
along with these routes, we also install the RMAC
and the nexthop Neigh entries.
There might be scenarios were the bestpath has changed and
we are now pointing to a new nexthop with a different RMAC.
As per BGP logic, we just send an update for the route and the nexthop
is replaced. However, this causes problem because the RMAC and neigh entry
corresponding to the previous nexthop are still lingering in the system.
We need to clear those entries for proper functoning.

Signed-off-by: Mitesh Kanjariya <mitesh@cumulusnetworks.com>
195 of 776 failed
FRR › FRR › #1082 1 year ago
bgpd: modify route install/withdraw logic for evpn type-5 routes in vrf
We install type-5 routes as ipv4/ipv6 unicast routes in the vrf table.
along with these routes, we also install the RMAC
and the nexthop Neigh entries.
There might be scenarios were the bestpath has changed and
we are now pointing to a new nexthop with a different RMAC.
As per BGP logic, we just send an update for the route and the nexthop
is replaced. However, this causes problem because the RMAC and neigh entry
corresponding to the previous nexthop are still lingering in the system.
We need to clear those entries for proper functoning.

Signed-off-by: Mitesh Kanjariya <mitesh@cumulusnetworks.com>
zebra: remote RMAC for EVPN ipv6 hosts should be programmed against the ipv4 nexthop
For ipv6 host, the next hop is conevrted to ipv6 mapped address.
However, the remote rmac should still be programmed with the ipv4 address.
This is how the entries will look in the kernel for ipv6 hosts routing.

vrf routing table:
ipv6 -> ipv6_mapped remote vtep on l3vni SVI

neigh table:
ipv6_mapped remote vtep -> remote RMAC

bridge fdb:
remote rmac -> ipv4 vtep tunnel

Signed-off-by: Mitesh Kanjariya <mitesh@cumulusnetworks.com>
zebra: vni [prefix-routes-only] should also be provided for the 'no' cmd
We have a command to enable symmetric routing only for type-5 routes.
This command is provided under vrf <> option in zebra as follows:
vrf <VRF>
  vni <VNI> [prefix-routes-only]
We need the corresponding no version of the command as well as follows:
vrf <VRF>
  no vni <VNI> [prefix-routes-only]

Signed-off-by: Mitesh Kanjariya <mitesh@cumulusnetworks.com>
bgpd/zebra: use stream_putl/getl to send VNIs
Signed-off-by: Mitesh Kanjariya <mitesh@cumulusnetworks.com>
bgpd: enable neighbor-nexthop-self for l2vpn evpn address family
In the FRR implementation of EVPN,
eBGP leaf-spine peering for EVPN is fully supported by allowing
the next hop to be propagated and not rewritten at each hop.
There are other changes also related to route import to facilitate this.
However, propagating the next hop is not correct in some cases.
Specifically, if the DC is comprised of multiple PODs
with distinct intra-POD and inter-POD VxLAN tunnels,
EVPN routes received from an adjacent POD by a border/exit leaf
must be propagated into the local POD with the next hop rewritten (to self).

Signed-off-by: Mitesh Kanjariya <mitesh@cumulusnetworks.com>
bgpd: no advertise ipv6 unicast comand should unset the af_flags
no advertise ipv6 unicast command should unset the corresponding
af_flag in bgp_vrf rather than the vrf_flags.

Signed-off-by: Mitesh Kanjariya <mitesh@cumulusnetworks.com>
bgpd: write route-map to config for advertise type5 commands
We enable/disable type-5 routes by following commands:
advertise ipv4 unicast [route-map <route-map>]
advertise ipv6 commands [route-map <route-map>]
the route-map part was writtem to conf file.

Signed-off-by: Mitesh Kanjariya <mitesh@cumulusnetworks.com>
bgpd: apply advertise ipv4 unicast route-map while advertising type-5 routes
A newly added ipv4/ipv6 route in BGP RIB might be advertised as type-5 EVPN route.
The user might have configured a route-map for advertising type-5 routes.
We need to apply this route-map while advertising ipv4/ipv6 routes as type-5.

Signed-off-by: Mitesh Kanjariya <mitesh@cumulusnetworks.com>
3829 passed
FRR › TOPOPR › #227 1 year ago
bgpd: resolve flag definition confict for af_flags under bgp vrf
afi/safi flags defined under bgp vrf needs to be unique across afi/safi.

Signed-off-by: Mitesh Kanjariya <mitesh@cumulusnetworks.com>
664 passed
FRR › TOPOPR › #226 1 year ago
bgpd: resolve flag definition confict for af_flags under bgp vrf
afi/safi flags defined under bgp vrf needs to be unique across afi/safi.

Signed-off-by: Mitesh Kanjariya <mitesh@cumulusnetworks.com>
5 of 776 failed
FRR › TOPOPR › #225 1 year ago
bgpd: resolve flag definition confict for af_flags under bgp vrf
afi/safi flags defined under bgp vrf needs to be unique across afi/safi.

Signed-off-by: Mitesh Kanjariya <mitesh@cumulusnetworks.com>
5 of 776 failed
FRR › TOPOPR › #224 1 year ago
bgpd: resolve flag definition confict for af_flags under bgp vrf
afi/safi flags defined under bgp vrf needs to be unique across afi/safi.

Signed-off-by: Mitesh Kanjariya <mitesh@cumulusnetworks.com>
5 of 776 failed
FRR › TOPOPR › #223 1 year ago
bgpd: resolve flag definition confict for af_flags under bgp vrf
afi/safi flags defined under bgp vrf needs to be unique across afi/safi.

Signed-off-by: Mitesh Kanjariya <mitesh@cumulusnetworks.com>
661 passed
FRR › TOPOPR › #222 1 year ago
bgpd: resolve flag definition confict for af_flags under bgp vrf
afi/safi flags defined under bgp vrf needs to be unique across afi/safi.

Signed-off-by: Mitesh Kanjariya <mitesh@cumulusnetworks.com>
664 passed
FRR › TOPOPR › #221 1 year ago
bgpd: resolve flag definition confict for af_flags under bgp vrf
afi/safi flags defined under bgp vrf needs to be unique across afi/safi.

Signed-off-by: Mitesh Kanjariya <mitesh@cumulusnetworks.com>
664 passed
You have insufficient permissions to see all of the builds.
Build Completed Code commits Tests
FRR › TOPOPR › #234 1 year ago
zebra: vni [prefix-routes-only] should also be provided for the 'no' cmd
We have a command to enable symmetric routing only for type-5 routes.
This command is provided under vrf <> option in zebra as follows:
vrf <VRF>
  vni <VNI> [prefix-routes-only]
We need the corresponding no version of the command as well as follows:
vrf <VRF>
  no vni <VNI> [prefix-routes-only]

Signed-off-by: Mitesh Kanjariya <mitesh@cumulusnetworks.com>
bgpd: apply advertise ipv4 unicast route-map while advertising type-5 routes
A newly added ipv4/ipv6 route in BGP RIB might be advertised as type-5 EVPN route.
The user might have configured a route-map for advertising type-5 routes.
We need to apply this route-map while advertising ipv4/ipv6 routes as type-5.

Signed-off-by: Mitesh Kanjariya <mitesh@cumulusnetworks.com>
zebra: remote RMAC for EVPN ipv6 hosts should be programmed against the ipv4 nexthop
For ipv6 host, the next hop is conevrted to ipv6 mapped address.
However, the remote rmac should still be programmed with the ipv4 address.
This is how the entries will look in the kernel for ipv6 hosts routing.

vrf routing table:
ipv6 -> ipv6_mapped remote vtep on l3vni SVI

neigh table:
ipv6_mapped remote vtep -> remote RMAC

bridge fdb:
remote rmac -> ipv4 vtep tunnel

Signed-off-by: Mitesh Kanjariya <mitesh@cumulusnetworks.com>
bgpd: no advertise ipv6 unicast comand should unset the af_flags
no advertise ipv6 unicast command should unset the corresponding
af_flag in bgp_vrf rather than the vrf_flags.

Signed-off-by: Mitesh Kanjariya <mitesh@cumulusnetworks.com>
bgpd: write route-map to config for advertise type5 commands
We enable/disable type-5 routes by following commands:
advertise ipv4 unicast [route-map <route-map>]
advertise ipv6 commands [route-map <route-map>]
the route-map part was writtem to conf file.

Signed-off-by: Mitesh Kanjariya <mitesh@cumulusnetworks.com>
bgpd/zebra: use stream_putl/getl to send VNIs
Signed-off-by: Mitesh Kanjariya <mitesh@cumulusnetworks.com>
bgpd: enable neighbor-nexthop-self for l2vpn evpn address family
In the FRR implementation of EVPN,
eBGP leaf-spine peering for EVPN is fully supported by allowing
the next hop to be propagated and not rewritten at each hop.
There are other changes also related to route import to facilitate this.
However, propagating the next hop is not correct in some cases.
Specifically, if the DC is comprised of multiple PODs
with distinct intra-POD and inter-POD VxLAN tunnels,
EVPN routes received from an adjacent POD by a border/exit leaf
must be propagated into the local POD with the next hop rewritten (to self).

Signed-off-by: Mitesh Kanjariya <mitesh@cumulusnetworks.com>
bgpd: modify route install/withdraw logic for evpn type-5 routes in vrf
We install type-5 routes as ipv4/ipv6 unicast routes in the vrf table.
along with these routes, we also install the RMAC
and the nexthop Neigh entries.
There might be scenarios were the bestpath has changed and
we are now pointing to a new nexthop with a different RMAC.
As per BGP logic, we just send an update for the route and the nexthop
is replaced. However, this causes problem because the RMAC and neigh entry
corresponding to the previous nexthop are still lingering in the system.
We need to clear those entries for proper functoning.

Signed-off-by: Mitesh Kanjariya <mitesh@cumulusnetworks.com>
195 of 776 failed
FRR › TOPOPR › #226 1 year ago
bgpd: resolve flag definition confict for af_flags under bgp vrf
afi/safi flags defined under bgp vrf needs to be unique across afi/safi.

Signed-off-by: Mitesh Kanjariya <mitesh@cumulusnetworks.com>
5 of 776 failed
FRR › TOPOPR › #225 1 year ago
bgpd: resolve flag definition confict for af_flags under bgp vrf
afi/safi flags defined under bgp vrf needs to be unique across afi/safi.

Signed-off-by: Mitesh Kanjariya <mitesh@cumulusnetworks.com>
5 of 776 failed
FRR › TOPOPR › #224 1 year ago
bgpd: resolve flag definition confict for af_flags under bgp vrf
afi/safi flags defined under bgp vrf needs to be unique across afi/safi.

Signed-off-by: Mitesh Kanjariya <mitesh@cumulusnetworks.com>
5 of 776 failed
FRR › TOPOPR › #194 1 year ago
bgpd: move route-target for a vrf under address-family evpn command
Signed-off-by: Mitesh Kanjariya <mitesh@cumulusnetworks.com>
bgpd: write vrf rd to config
When a non-default vrf rd is configured under l2vpn evpn in a vrf,
we need to update the config file.

Signed-off-by: Mitesh Kanjariya <mitesh@cumulusnetworks.com>
bgpd: keep a backpointer to vrf instance in struct bgpevpn
We will keep a backpointer to bgp vrf instance in bgpevpn.
struct bgpevpn denotes a l2vni and bgp_vrf corresponds to l3vni.
A back pointer to the vrf will provide efficient
access to vrf when needed.

Signed-off-by: Mitesh Kanjariya <mitesh@cumulusnetworks.com>
bgpd: Attach PMSI to only type-3 routes and rmac to only type-2 routes
The PMSI attribute is only applicable to EVPN type-3 route.
Rmac is applicable to type-2 and type-5 routes.
We should attach these attributes appropiately based on route-type.

Signed-off-by: Mitesh Kanjariya <mitesh@cumulusnetworks.com>
bgpd: add show bgp vrf all l2vpn evpn summary as an option
Ticket: CM-19738
Review: CCR-7194
Testing: Manual

Signed-off-by: Mitesh Kanjariya <mitesh@cumulusnetworks.com>
35 of 618 failed
FRR › TOPOPR › #193 1 year ago
bgpd: write vrf rd to config
When a non-default vrf rd is configured under l2vpn evpn in a vrf,
we need to update the config file.

Signed-off-by: Mitesh Kanjariya <mitesh@cumulusnetworks.com>
bgpd: keep a backpointer to vrf instance in struct bgpevpn
We will keep a backpointer to bgp vrf instance in bgpevpn.
struct bgpevpn denotes a l2vni and bgp_vrf corresponds to l3vni.
A back pointer to the vrf will provide efficient
access to vrf when needed.

Signed-off-by: Mitesh Kanjariya <mitesh@cumulusnetworks.com>
bgpd: add show bgp vrf all l2vpn evpn summary as an option
Ticket: CM-19738
Review: CCR-7194
Testing: Manual

Signed-off-by: Mitesh Kanjariya <mitesh@cumulusnetworks.com>
bgpd: Attach PMSI to only type-3 routes and rmac to only type-2 routes
The PMSI attribute is only applicable to EVPN type-3 route.
Rmac is applicable to type-2 and type-5 routes.
We should attach these attributes appropiately based on route-type.

Signed-off-by: Mitesh Kanjariya <mitesh@cumulusnetworks.com>
bgpd: move route-target for a vrf under address-family evpn command
Signed-off-by: Mitesh Kanjariya <mitesh@cumulusnetworks.com>
7 of 618 failed
FRR › TOPOPR › #191 1 year ago
bgpd: add show bgp vrf all l2vpn evpn summary as an option
Ticket: CM-19738
Review: CCR-7194
Testing: Manual

Signed-off-by: Mitesh Kanjariya <mitesh@cumulusnetworks.com>
bgpd: Attach PMSI to only type-3 routes and rmac to only type-2 routes
The PMSI attribute is only applicable to EVPN type-3 route.
Rmac is applicable to type-2 and type-5 routes.
We should attach these attributes appropiately based on route-type.

Signed-off-by: Mitesh Kanjariya <mitesh@cumulusnetworks.com>
bgpd: move route-target for a vrf under address-family evpn command
Signed-off-by: Mitesh Kanjariya <mitesh@cumulusnetworks.com>
bgpd: write vrf rd to config
When a non-default vrf rd is configured under l2vpn evpn in a vrf,
we need to update the config file.

Signed-off-by: Mitesh Kanjariya <mitesh@cumulusnetworks.com>
bgpd: keep a backpointer to vrf instance in struct bgpevpn
We will keep a backpointer to bgp vrf instance in bgpevpn.
struct bgpevpn denotes a l2vni and bgp_vrf corresponds to l3vni.
A back pointer to the vrf will provide efficient
access to vrf when needed.

Signed-off-by: Mitesh Kanjariya <mitesh@cumulusnetworks.com>
40 of 618 failed
FRR › TOPOPR › #190 1 year ago
bgpd: move route-target for a vrf under address-family evpn command
Signed-off-by: Mitesh Kanjariya <mitesh@cumulusnetworks.com>
bgpd: keep a backpointer to vrf instance in struct bgpevpn
We will keep a backpointer to bgp vrf instance in bgpevpn.
struct bgpevpn denotes a l2vni and bgp_vrf corresponds to l3vni.
A back pointer to the vrf will provide efficient
access to vrf when needed.

Signed-off-by: Mitesh Kanjariya <mitesh@cumulusnetworks.com>
bgpd: write vrf rd to config
When a non-default vrf rd is configured under l2vpn evpn in a vrf,
we need to update the config file.

Signed-off-by: Mitesh Kanjariya <mitesh@cumulusnetworks.com>
bgpd: Attach PMSI to only type-3 routes and rmac to only type-2 routes
The PMSI attribute is only applicable to EVPN type-3 route.
Rmac is applicable to type-2 and type-5 routes.
We should attach these attributes appropiately based on route-type.

Signed-off-by: Mitesh Kanjariya <mitesh@cumulusnetworks.com>
bgpd: add show bgp vrf all l2vpn evpn summary as an option
Ticket: CM-19738
Review: CCR-7194
Testing: Manual

Signed-off-by: Mitesh Kanjariya <mitesh@cumulusnetworks.com>
7 of 564 failed
FRR › TOPOPR › #189 1 year ago
bgpd: write vrf rd to config
When a non-default vrf rd is configured under l2vpn evpn in a vrf,
we need to update the config file.

Signed-off-by: Mitesh Kanjariya <mitesh@cumulusnetworks.com>
bgpd: keep a backpointer to vrf instance in struct bgpevpn
We will keep a backpointer to bgp vrf instance in bgpevpn.
struct bgpevpn denotes a l2vni and bgp_vrf corresponds to l3vni.
A back pointer to the vrf will provide efficient
access to vrf when needed.

Signed-off-by: Mitesh Kanjariya <mitesh@cumulusnetworks.com>
bgpd: add show bgp vrf all l2vpn evpn summary as an option
Ticket: CM-19738
Review: CCR-7194
Testing: Manual

Signed-off-by: Mitesh Kanjariya <mitesh@cumulusnetworks.com>
bgpd: Attach PMSI to only type-3 routes and rmac to only type-2 routes
The PMSI attribute is only applicable to EVPN type-3 route.
Rmac is applicable to type-2 and type-5 routes.
We should attach these attributes appropiately based on route-type.

Signed-off-by: Mitesh Kanjariya <mitesh@cumulusnetworks.com>
bgpd: move route-target for a vrf under address-family evpn command
Signed-off-by: Mitesh Kanjariya <mitesh@cumulusnetworks.com>
12 of 618 failed
FRR › TOPOPR › #188 1 year ago
bgpd: keep a backpointer to vrf instance in struct bgpevpn
We will keep a backpointer to bgp vrf instance in bgpevpn.
struct bgpevpn denotes a l2vni and bgp_vrf corresponds to l3vni.
A back pointer to the vrf will provide efficient
access to vrf when needed.

Signed-off-by: Mitesh Kanjariya <mitesh@cumulusnetworks.com>
bgpd: add show bgp vrf all l2vpn evpn summary as an option
Ticket: CM-19738
Review: CCR-7194
Testing: Manual

Signed-off-by: Mitesh Kanjariya <mitesh@cumulusnetworks.com>
bgpd: Attach PMSI to only type-3 routes and rmac to only type-2 routes
The PMSI attribute is only applicable to EVPN type-3 route.
Rmac is applicable to type-2 and type-5 routes.
We should attach these attributes appropiately based on route-type.

Signed-off-by: Mitesh Kanjariya <mitesh@cumulusnetworks.com>
bgpd: write vrf rd to config
When a non-default vrf rd is configured under l2vpn evpn in a vrf,
we need to update the config file.

Signed-off-by: Mitesh Kanjariya <mitesh@cumulusnetworks.com>
bgpd: move route-target for a vrf under address-family evpn command
Signed-off-by: Mitesh Kanjariya <mitesh@cumulusnetworks.com>
2 of 582 failed
Build Completed Code commits Tests
FRR › FRR › #1082 1 year ago
bgpd: modify route install/withdraw logic for evpn type-5 routes in vrf
We install type-5 routes as ipv4/ipv6 unicast routes in the vrf table.
along with these routes, we also install the RMAC
and the nexthop Neigh entries.
There might be scenarios were the bestpath has changed and
we are now pointing to a new nexthop with a different RMAC.
As per BGP logic, we just send an update for the route and the nexthop
is replaced. However, this causes problem because the RMAC and neigh entry
corresponding to the previous nexthop are still lingering in the system.
We need to clear those entries for proper functoning.

Signed-off-by: Mitesh Kanjariya <mitesh@cumulusnetworks.com>
zebra: remote RMAC for EVPN ipv6 hosts should be programmed against the ipv4 nexthop
For ipv6 host, the next hop is conevrted to ipv6 mapped address.
However, the remote rmac should still be programmed with the ipv4 address.
This is how the entries will look in the kernel for ipv6 hosts routing.

vrf routing table:
ipv6 -> ipv6_mapped remote vtep on l3vni SVI

neigh table:
ipv6_mapped remote vtep -> remote RMAC

bridge fdb:
remote rmac -> ipv4 vtep tunnel

Signed-off-by: Mitesh Kanjariya <mitesh@cumulusnetworks.com>
zebra: vni [prefix-routes-only] should also be provided for the 'no' cmd
We have a command to enable symmetric routing only for type-5 routes.
This command is provided under vrf <> option in zebra as follows:
vrf <VRF>
  vni <VNI> [prefix-routes-only]
We need the corresponding no version of the command as well as follows:
vrf <VRF>
  no vni <VNI> [prefix-routes-only]

Signed-off-by: Mitesh Kanjariya <mitesh@cumulusnetworks.com>
bgpd/zebra: use stream_putl/getl to send VNIs
Signed-off-by: Mitesh Kanjariya <mitesh@cumulusnetworks.com>
bgpd: enable neighbor-nexthop-self for l2vpn evpn address family
In the FRR implementation of EVPN,
eBGP leaf-spine peering for EVPN is fully supported by allowing
the next hop to be propagated and not rewritten at each hop.
There are other changes also related to route import to facilitate this.
However, propagating the next hop is not correct in some cases.
Specifically, if the DC is comprised of multiple PODs
with distinct intra-POD and inter-POD VxLAN tunnels,
EVPN routes received from an adjacent POD by a border/exit leaf
must be propagated into the local POD with the next hop rewritten (to self).

Signed-off-by: Mitesh Kanjariya <mitesh@cumulusnetworks.com>
bgpd: no advertise ipv6 unicast comand should unset the af_flags
no advertise ipv6 unicast command should unset the corresponding
af_flag in bgp_vrf rather than the vrf_flags.

Signed-off-by: Mitesh Kanjariya <mitesh@cumulusnetworks.com>
bgpd: write route-map to config for advertise type5 commands
We enable/disable type-5 routes by following commands:
advertise ipv4 unicast [route-map <route-map>]
advertise ipv6 commands [route-map <route-map>]
the route-map part was writtem to conf file.

Signed-off-by: Mitesh Kanjariya <mitesh@cumulusnetworks.com>
bgpd: apply advertise ipv4 unicast route-map while advertising type-5 routes
A newly added ipv4/ipv6 route in BGP RIB might be advertised as type-5 EVPN route.
The user might have configured a route-map for advertising type-5 routes.
We need to apply this route-map while advertising ipv4/ipv6 routes as type-5.

Signed-off-by: Mitesh Kanjariya <mitesh@cumulusnetworks.com>
3829 passed
FRR › FRR › #548 2 years ago
bgpd: Intialize all the variables used in argv_find.
Ticket: CM-17706
Review: CCR-6639
Testing: Manual (test failing in min test for ARM)

Signed-off-by: Mitesh Kanjariya <mitesh@cumulusnetworks.com>
3517 passed
You have insufficient permissions to see all of the builds.