I am not sure I read your rules correctly , the layout might be different in the actual ruleset , but as far as I can tell the FIRST rule that would match your traffic would be this one : ebtables -A FORWARD -i tap1 -j tap1_IC *ebtalbes -N tap1_IC ebtables -P tap1_IC DROP ebtables -A tap1_IC --among-src ! 52:54:0:1:6c:c1=10.200.10.101 -j DROP ebtables -A tap1_IC --among-dst 52:54:0:1:6c:c2=10.200.10.102 -j ACCEPT ebtables -A tap1_IC -d Broadcast -j ACCEPT *ebtalbes -A tap1_IC -d Multicast -j ACCEPT So reading the rules , after hitting the last rules here you go to ACCEPT and no further ruleset is used , Aka it will NEVER process the rules for outgoing to tap3 "ebtables -A FORWARD -o tap3 -j tap1_OC" as you already allowed it prior ! On a second note , there are several places your rules are using wrong word " ebtalbes" instead of "ebtables" ( not sure if that is only in this mail , or if that is also in the actual ruleset ) Best regards André Paulsberg-Csibi Senior Network Engineer Fault Handling IBM Services AS andre.paulsberg-csibi@xxxxxxxx M +47 9070 5988 -----Original Message----- From: netfilter-owner@xxxxxxxxxxxxxxx [mailto:netfilter-owner@xxxxxxxxxxxxxxx] On Behalf Of xiegaofeng@xxxxxxxxxxxxx Sent: 9. mai 2017 10:47 To: netfilter@xxxxxxxxxxxxxxx Subject: Multicast does not work on ebtables Hi, My host has three virtual machines: VM1 VM2, and VM3. Their interfaces in the physical host respectively are tap1, tap2, and tap3; and their IPs are 10.200.10.101(52:54:0:1:6c:c1), 10.200.10.102(52:54:0:1:6c:c2), 10.200.10.103(52:54:0:1:6c:c3). tap1, tap2 and tap3 are bound on a same linux bridge. I hope that tap1 and tap2 can communicate with each other, not tap3. The ebtables rules are as follow. # For tap1 ebtalbes -N tap1_IC ebtables -P tap1_IC DROP ebtables -A tap1_IC --among-src ! 52:54:0:1:6c:c1=10.200.10.101 -j DROP ebtables -A tap1_IC --among-dst 52:54:0:1:6c:c2=10.200.10.102 -j ACCEPT ebtables -A tap1_IC -d Broadcast -j ACCEPT ebtalbes -A tap1_IC -d Multicast -j ACCEPT ebtalbes -N tap1_MI ebtables -P tap1_MI DROP ebtables -A tap1_MI --among-dst 52:54:0:1:6c:c1=10.200.10.101 -j RETURN ebtables -A tap1_MI -d Broadcast -j RETURN ebtalbes -A tap1_MI -d Multicast -j RETURN ebtables -N tap1_OC ebtables -P tap1_OC DROP ebtables -A tap1_OC -j tap1_MI ebtables -A tap1_OC --among-src 52:54:0:1:6c:c2=10.200.10.102 -j ACCEPT ebtables -A FORWARD -i tap1 -j tap1_IC ebtables -A FORWARD -o tap1 -j tap1_OC # For tap2 ebtalbes -N tap2_IC ebtables -P tap2_IC DROP ebtables -A tap2_IC --among-src ! 52:54:0:1:6c:c2=10.200.10.102 -j DROP ebtables -A tap2_IC --among-dst 52:54:0:1:6c:c1=10.200.10.101 -j ACCEPT ebtables -A tap2_IC -d Broadcast -j ACCEPT ebtalbes -A tap2_IC -d Multicast -j ACCEPT ebtalbes -N tap2_MI ebtables -P tap2_MI DROP ebtables -A tap2_MI --among-dst 52:54:0:1:6c:c2=10.200.10.102 -j RETURN ebtables -A tap2_MI -d Broadcast -j RETURN ebtalbes -A tap2_MI -d Multicast -j RETURN ebtables -N tap2_OC ebtables -P tap2_OC DROP ebtables -A tap2_OC -j tap2_MI ebtables -p tap2_OC --among-src 52:54:0:1:6c:c1=10.200.10.101 -j ACCEPT ebtables -A FORWARD -i tap2 -j tap1_IC ebtables -A FORWARD -o tap2 -j tap1_OC # For tap3 ebtalbes -N tap3_IC ebtables -P tap3_IC DROP ebtables -A tap3_IC --among-src ! 52:54:0:1:6c:c3=10.200.10.103 -j DROP ebtables -A tap3_IC -d Broadcast -j ACCEPT ebtalbes -A tap3_IC -d Multicast -j ACCEPT ebtalbes -N tap3_MI ebtables -P tap3_MI DROP ebtables -A tap3_MI --among-dst 52:54:0:1:6c:c3=10.200.10.103 -j RETURN ebtables -A tap3_MI -d Broadcast -j RETURN ebtalbes -A tap3_MI -d Multicast -j RETURN ebtables -N tap3_OC ebtables -P tap3_OC DROP ebtables -A tap3_OC -j tap3_MI ebtables -A FORWARD -i tap3 -j tap1_IC ebtables -A FORWARD -o tap3 -j tap1_OC For TCP, UDP or BROADCAST, it works as expected. But for Multicast, it's not. When VM1 sends a Multicast packet, VM2 can receive it and it's OK, but VM3 will also receive it. It's not right, because the chain tap3_OC does not have the matched rule and will DROP it by default. I do not known why VM3 can receive this Multicast packet. I'm not sure whether it is a bug. Thanks, Aaron -- To unsubscribe from this list: send the line "unsubscribe netfilter" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at https://emea01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fvger.kernel.org%2Fmajordomo-info.html&data=02%7C01%7C%7Ce0d3df1e6a0a4726767208d496b8e6dd%7C40cc2915e2834a2794716bdd7ca4c6e1%7C1%7C0%7C636299168271803731&sdata=0YbTKK49pozyz0luRPB2Ae%2FnMFDWJFszQEdXx39Mfuw%3D&reserved=0 -- To unsubscribe from this list: send the line "unsubscribe netfilter" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
