RaidAndFade

This request's code has changed since approval. Re-Judging contents... Your pull request seems good, but must be checked by a human maintainer for the following reason(s): 1. Modifications to contributors.md...

Your pull request seems good, but must be checked by a human maintainer for the following reason(s): 1. An error occured while marking your code. The error should be addressed...

Yes, my case is arista VXLAN on Sflow, ideally with vni and any other data in the sample. Im not well versed on sflow format so unsure what the potential...

Sorry for the delay. Is it possible for you to provide me with a secure contact so I can send this data? Otherwise I would have to send obscured hexdumps....

Looking deeper on both sides. Unfortunately it looks like arista only sends sflows for received vxlan packets indeed. Outbound vxlan's only indicator is that it has a different gateway next_hop...

Sent, turns out i was wrong with the gateway being the destination vtep. it's actually the gateway *within* the vni, means no clear way to tie that to a vxlan....

I dont think i have a way to separate encapped and regular flows, I would probably end up sending everything to the decap listener. Ideally there's three additional fields alongside...

ingress and egress both happen on every device, it would have to separate on a per device level and i dont know of any way to do that.

Additionally, knowing the VNI/VTEPs is critical to being able to use this data meaningfully. Without the VNI i may as well just strip the vxlan headers on the way in...

I understand, I wouldn't want this to be reimplemented due to specific platform limitations later on either. That's why I was thinking we could ignore any flow data and go...