Does goBGP support batch collection of full routing tables of specified AFI and SFAFI types through gRPC API (acquire in batches and multiple times)?

[wangchong2023]

Our requirement is to regularly obtain the full set of BGP routes of specified AFI and SAFI types in memory in a lightweight manner. The operations of collecting BGP routes using BMP and MRT methods are relatively cumbersome and heavy-duty.
If we collect BGP routes through the BMP protocol, we need to run additional BMP client protocols and parse the BMP protocol, and there are few open source software of this type.
If we use the MRT protocol to collect BGP routes, we also need to additionally run the MRT client and MRT file parsing program.

[wangchong2023]

BGP route on RR-Client(Router-ID:192.168.131.87, ASN:1000)

BGP-RR（Router-ID:192.168.131.87, ASN:1000）-------RR-Client(Router-ID:192.168.111.105, ASN:100)

When I call the GetTable function through the gRPC interface to obtain BGP routes on RR-Client (192.168.111.105), goBGP returns "doesn't have local rib". Is the gRPC parameter configuration incorrect?

Thanks very much.
@fujita

[fujita]

You need to use ListPath API to get paths.
Btw, I think that bmp is better than gRPC API for your purpose.

[wangchong2023]

th API to get paths.
Btw, I think that bmp is better than gRPC API for your purpose.

@fujita Thanks.
In fact, I also hope to use BMP to collect BGP routing and various BGP protocol statistics. The main difficulty is: if you use the BMP protocol to collect, you need a BMP server to parse BMP messages. It is relatively complicated to implement a program to parse BMP messages by yourself (not a simple object array, need to parse BGP protocol format packet); and currently the main In BMP server-side open source software, most of the fields in these BMP are exported through Kafka or files, etc., which will result in the introduction of too many third-party components or reduce the real-time nature of processing (files are basically similar to the MRT format) .
Is there a better way?

Route mirror of BMP:

[fujita]

I think that you could implement your own BMP server implementation by using OSS BMP implementations like https://github.com/sbezverk/gobmp

[wangchong2023]

I think that you could implement your own BMP server implementation by using OSS BMP implementations like https://github.com/sbezverk/gobmp

@fujita
We plan to use goBGP as the BGP RR client to collect BGP routers from ISP routers (assuming that the ISP router can only run BGP and cannot enable BMP).

If we run the BMP protocol on goBGP to export BGP routes, we need to deploy a program similar to goBMP to receive the routes from goBGP mirrored through the BMP protocol, and then obtain them through the communication protocol established with goBMP (such as Kafka) to the required BGP route. The additional deployment of goBMP and the establishment of a communication protocol with goBMP are too complex for practical applications.

If goBGP can directly export tiled routing update messages while exporting MRT format files, instead of the original BGP routing format (as you known, the routing format of the BGP protocol is too complex and constantly evolving, even if we implement BMP Server by ourselves), this will be very useful for real-time collection of BGP routing. help. Is there currently such a mechanism or can it be implemented?

We want to reuse goBGP's BGP route collection, parsing, and export capabilities, instead of implementing a program for parsing BGP protocol routes, which will increase additional protocol processing costs and error risks.

[fujita]

We plan to use goBGP as the BGP RR client to collect BGP routers from ISP routers

How you store collected data?

[wangchong2023]

We plan to use goBGP as the BGP RR client to collect BGP routers from ISP routers

How you store collected data?

@fujita
Stored in memory in a structured form and written to the database periodically. Take IPv4/IPv6 unicast routing as an example:

bgp_route.csv

[fujita]

WatchEvent API might work for you:
https://github.com/osrg/gobgp/blob/master/api/gobgp.proto#L39C13-L39C13

[wangchong2023]

WatchEvent API might work for you: https://github.com/osrg/gobgp/blob/master/api/gobgp.proto#L39C13-L39C13

@fujita Thanks very much.
Does the gRPC API(WatchEvent) support monitoring of BGP status? In addition, does goBGP have instructions for using this gRPC API?

[fujita]

Please check out the CLI code to use the WatchEvent API:
https://github.com/osrg/gobgp/blob/master/cmd/gobgp/monitor.go

[wangchong2023]

Thanks.
@fujita
When I call gRPC's WatchEvent interface, the API seems to return a BGP neighbor list instead of a BGP route. Is the parameter passed incorrectly or used incorrectly?
There are two BGP routes on 192.168.131.87.

[fujita]

used incorrectly. Please read the source of the CLI.

[wangchong2023]

@fujita
Thank you very much, we will try to call again. Are there any plans to write gRPC documentation? If there is such a document, which directory should it be placed in? We would like to contribute a little based on our usage experience. goBGP's gRPC is very powerful, and it will be even more powerful if it has good documentation and adaptation.

[fujita]

https://github.com/pseudomuto/protoc-gen-doc
writing the documentation in proto files is the common way?

[wangchong2023]

https://github.com/pseudomuto/protoc-gen-doc writing the documentation in proto files is the common way?
--->
@fujita
I used this tool, which provides a simple and easy API documentation method. Currently, our documentation lacks some overall introduction, such as API parameters, input and output function descriptions, constraints, etc., so using the API may require a certain process of exploration and experimentation. Adding this information will help goBGP be integrated more easily and clarify the features and capabilities it supports.
Do you have any suggestions on how to add these help documentation instructions?

[fujita]

You meant that protoc-gen-doc can't provide what you expect? I'm not sure what you meant.
If you add doc into proto files, then we can add a GitHub action to generate docs.