Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Faulty data request #218

Open
tobpip opened this issue Jun 9, 2021 · 3 comments
Open

Faulty data request #218

tobpip opened this issue Jun 9, 2021 · 3 comments

Comments

@tobpip
Copy link

tobpip commented Jun 9, 2021

Hi,

i have a problem with pybgpstrem (v2.0.2).


  1. Problem
    When i use it to collect data than i get a error message. An excerpt is visible here.
    image
    I have this problem when i try to download data after the time step 1590019200 (unix).

  1. Problem
    When i use the "Any" filter after the time step 1584489600 (unix) i get BGP message with the prefix 0.0.0.0/0
    Before this time step i don't get such messages.

I did the test with different prefixes. But there was no difference in the reaction of the programme.

@vkotronis
Copy link

We are encountering the same problem on the monitors of the ARTEMIS open-source on-premise tool: https://github.com/FORTH-ICS-INSPIRE/artemis/tree/master

We are using the latest version of the libbgpstream container (2.2.0) https://github.com/slowr/artemis-base-images/blob/master/monitor/Dockerfile#L1

Our implementation (in Python) is packed here: https://github.com/FORTH-ICS-INSPIRE/artemis/blob/master/monitor-services/bgpstreamlivetap/core/bgpstreamlive.py#L369

Like @tobpip reported, we recently started getting this error that overflows the logs:

bgpstreamlivetap_1   | WARN: INVALID_MSG: Invalid prefix in MP_(UN)REACH_NLRI (parsebgp_bgp_update_mp_reach.c:110)

Is there a way to address this? Can it be suppressed in case it stems from an upstream collector? We do not see this by directly using the kafka RV stream, however all clients that use the classic Python-based client are affected (no errors, but warning overflows).

Thanks in advance for looking into this!

@racompton
Copy link

Same here. Commenting so I'm notified when this is resolved.

@alistairking
Copy link
Member

I suspect this might be corrupted data generated by RV collectors running a version of FRR that mis-handled ADD-PATH attributes.

Can you narrow the problem down to specific collectors/time ranges?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants