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>
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>
