Addressing the question of what uRPF has to do with this: it’s possible—unlikely, but possible—that Meta hasn’t been able to find the issue because while it looks like a faulty interface within a bundle (and it probably is), it could also be that an internal route has uRPF accidentally enabled and is receiving asymmetric traffic, causing it to drop packets on that path. It’s a possibility, but only Meta would know for sure. I included it in the title to give them a lead; it can really only be one of two things: uRPF on an interface participating in an ECMP, or an interface dropping packets at the hardware level within a bundle
Sorry, I’m new to this forum. I thought I’d be able to attach images, but you can find them all on the website linked to the post. Apologies for the late response; it’s been a rough few days. Meta took this thread quite hostilely and even tried contacting my clients. It doesn't feel good to get on an organization's bad side, but I didn't see any other alternative
Hey man. I agree, this issue has been going on for nearly six months, and they’ve been closing my tickets—it’s honestly a joke at this point. Back in 2023, the exact same thing happened, and I had to resort to social engineering just to get them to find the problem; they fixed it a day later. I’m not proud of doing that, but I have to emphasize it because Meta has built performance dashboards designed to delude themselves.
Packet loss is happening all the time, though it might be more noticeable during peak hours since a faulty interface will show a higher error rate under heavy load. You can replicate it using looking glasses; maybe you didn't see it five days ago but you do now. Since it’s an ECMP issue, it depends heavily on which source and destination servers you’re testing. It’s just a matter of iterating.
I’m glad you were able to replicate it on ping.pe; Meta, however, still has no clue