-
-
Notifications
You must be signed in to change notification settings - Fork 206
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
Source and destination IPs getting set to 0.0.0.0 #283
Comments
Thanks for the report. It looks like the sflow code does not unwrap properly the MPLS label stack. I will work on that. |
Fixed. Please use latest master or release 1.6.23. |
Thank you so much!
———
Lisa Ensman
Indiana University, Bloomington
GlobalNOC - SysEng
Network Data Collection & Analysis (NDCA)
… On May 7, 2021, at 11:21 AM, Peter Haag ***@***.***> wrote:
Fixed. Please use latest master or release 1.6.23.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub <#283 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AEJOH6M54IREMOHOQD637JLTMQAQ3ANCNFSM42AGU7HA>.
|
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
I have run into an issue where sfcapd or nfdump is setting the src and dst IPs of flows to 0.0.0.0.
Looking at a sample of flows in detail with tcpdump and wireshark, I see that most flows do have valid IPs. (A few do not and that is presumably a problem for Arista; let's not consider those.) When I look at the same flows in the corresponding nfcapd file using nfdump, I see that many of the flows are listed as 0.0.0.0->0.0.0.0. Ports and protocols are also 0, the number of bytes is not.
This issue may have something to do with MPLS label switching over a certain vlan. In a particular 5-minute nfcapd file that I am looking at, considering only flows using that vlan, nfdump says 99% are 0.0.0.0->0.0.0.0. Of flows not on that vlan, only 3 have 0.0.0.0.
Months ago, there was a maintenance to "reconfigure the router to prefer LDP LSP-based next-hop resolution for all IPv4 BGP-learned routes. This converted the backbone from hop-by-hop routing to an LSP mesh for IPv4 transit traffic." We later noticed that the number of flows reported by nfdump and our logstash pipeline dropped starting at that time (presumably because flows we now see with 0.0.0.0's weren't listed at all by the previous version of nfdump in use).
Is this a known problem?
We are using a build of nfdump made from master, cloned 3/4/21 (in order to get another recent fix), sflow version 5, and an Arista Networks DCS-7208 SRAM-48C6-F router.
I can send you a pcap file, if requested.
Thanks!
The text was updated successfully, but these errors were encountered: