I guess to could have the rules inbound on ebtables. Just remember that multicast and broadcast also needs to get through. I like it outbound as this is where I actually have the issue and I know packets in this direction will have to been sourced from me.
Thank you for the kind words.
I will say that, after troubleshooting this, Im not sure you can fault Heztner here (though I might have hinted at that earlier). Actually, it works as designed. The problem is that the Proxmox config Im running (and properly you as well) turns your normal network...
Okay. I will try to explain .. :)
A switch works under a couple of main rules:
Whenever a packet comes in:
Rule1: Record the source mac and the interface it came from in a table
Rule2: Lookup the destination mac in the table created in rule 1:
Rule2A: If the destination mac is found in...
So, I did indeed get some packets during the night and they were successfully dropped by the filter above in ebtables. I could verify this as I ran tcpdump at the same time and didnt record a single packet going out (to wrong mac addresses that is).
Last question I have: How do I incorporate...
So I looked a lot at all these filters and was really unsure what they did (and more worried how they actually would behave) so I took a little different approach in order to troubleshoot.
ebtables does layer2 rules, so I started with just seeing if I could log every time the server was sending...
To my knowledge rp_filter is IP reverse path check (layer3 checking). Since this is switch-to-switch we are looking for some sort of layer2 (aka MAC) filtering.
I totally agree that this looks more and more like a flooding problem. And since we have a software switch (aka bridge) when entering into our Proxmox servers, it (to me) looks like some solution to not have our software switch flood unknown unicast (received from the Heztner network) everywhere.
Gents,
Got the same problem as you. The dreaded "Unauth MAC" from Hetzner. I'm running two IPs/MACs on my proxmox and I actually managed to catch to offending packets yesterday by running:
tcpdump -Q out -n -w /tmp/ether2.pcap -e not ether host 00:50:56:15:14:E5 and not ether host...
This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
By continuing to use this site, you are consenting to our use of cookies.