[RFE] bgp-statistics

[vikram.choudhary]

[Existing problem]
Current BGP dynamic routing proposal [1]_ doesn't have support for getting BGP peer state and statistical information. Such information could be critical for debugging.

[Proposal]
- Existing BGP dynamic routing framework will be extended for supporting BGP peer state and statistical information.
- Additional display CLI's will be added.

[Benefits]
- Debugging will be strengthened.

[What is the enhancement?]
- Add debugging framework.
- Add interface for retrieving and displaying BGP peer statistics and states.

[Related information]
[1] Dynamic Advertising Routes for Public Ranges
    https://specs.openstack.org/openstack/neutron-specs/specs/mitaka/bgp-dynamic-routing.html

[Akihiro Motoki (amotoki)]

The feature which this RFE depends on is not yet implemented.
It is valid as a feature request, but the requested feature can be implemented during the current proposed implementation.

[Akihiro Motoki (amotoki)]

We need to revisit this after BGP-DR blueprint completes.

[Armando Migliaccio (armando-migliaccio)]

Thanks for the update. I think it's fair to say that until [1] is feature complete (blueprints implemented - i.e. basic code, tests, docs), bugs [2-7] are blocked. My suggestion would be to go and yell/help the assignee/approver of [1] and make sure that the work can complete successfully asap so that we can start focusing on 2-7 knowing on what grounds we can continue building.

[1] https://blueprints.launchpad.net/neutron/+spec/bgp-dynamic-routing
[2] https://bugs.launchpad.net/neutron/+bug/1509431
[3] https://bugs.launchpad.net/neutron/+bug/1509436
[4] https://bugs.launchpad.net/neutron/+bug/1527993
[5] https://bugs.launchpad.net/neutron/+bug/1528000
[6] https://bugs.launchpad.net/neutron/+bug/1528002
[7] https://bugs.launchpad.net/neutron/+bug/1528003

[vikram.choudhary (vikschw)]

Let's wait for driver's team confirmation..

[Ryan Tidwell (ryan-tidwell)]

Being able to query the state of a peering session via the API could be handy. The only way to verify it is to either tail the dr_agent log file or got to each peer and make sure it has a session opened with the dr_agent.

[Armando Migliaccio (armando-migliaccio)]

Assumed that by the end of Newton (or sooner if possible) the BGP repo is up and running and rock solid based on the efforts put into Mitaka, I see no reason why these requests should not be vetted and addressed by the BGP team directly. So please make a recommendation.

[vikram.choudhary (vikschw)]

I agree with armax and feel like it can be addressed by the new repo.

[vikram.choudhary (vikschw)]

IMO, a spec might be better for designing CLI, display format and functionality.

[OpenStack Infra (hudson-openstack)]

Change abandoned by Armando Migliaccio (<email address hidden>) on branch: master
Review: https://review.openstack.org/334397
Reason: This review is > 4 weeks without comment, and failed Jenkins the last time it was checked. We are abandoning this for now. Feel free to reactivate the review by pressing the restore button and leaving a 'recheck' comment to get fresh test results.

[Tim Way (tim.way)]

A variant of this affects me, I do not see a method to currently determine the IP address of the BGPSpeaker. This is required when configuring the upstream peer. It is IP address on the correct segment of the Neutron Agent where the BGP process is running. In my case I had to attach to the container directly and inspect the interfaces and IP addresses manually.

This isn't friendly for automation or even basic usability. Ideally the IP would be able to be discovered in the API (OpenStack CLI).

[Rodolfo Alonso (rodolfo-alonso-hernandez)]

Bug closed due to lack of activity, please feel free to reopen if needed.