* ebtables, MAC masquerading, and ARP and ND rewriting
@ 2014-06-04 15:15 Alex Bligh
2014-06-10 14:25 ` Paul Robert Marino
0 siblings, 1 reply; 3+ messages in thread
From: Alex Bligh @ 2014-06-04 15:15 UTC (permalink / raw
To: netfilter; +Cc: Alex Bligh
I am trying to use Linux to perform in a bridge configuration using
ebtables. The particular bridge I am plugging Linux into appears to
have some design flaws (for anyone interested, it's the bridge inside
VMware with NIC teaming), and the vendor appears to be uninterested
in fixing it.
The configuration looks like this:
| .......... ...................... aa:bb:cc:dd:ee:01
| NIC-A : VMware : : Linux bridge :------------ Dev1
+----------: bridge : : :
| : : : 11:22:33:44:55:66 : aa:bb:cc:dd:ee:02
| : :------: eth0 :------------ Dev2
| NIC-B : : : :
+----------: : : : aa:bb:cc:dd:ee:03
| : : : :------------ Dev3
| :........: :....................:
LAN
NIC-A and NIC-B are in active/passive mode, however, passive does not
mean 'does not transmit packets'.
What happens is a broadcast packet leaves device Dev1 with source address
aa:bb:cc:dd:ee:01, is passed through the linux bridge and transmitted
through device eth0 to the VMware bridge. It is then transmitted
out of NIC-A onto the LAN. What then happens is that the switch(es)
on the LAN transmits the packet through NIC-B back to the VMware
bridge.
The VMware bridge appears to have an 'interesting' bridge algorithm,
in that it is not a learning bridge that it appears to examine the
source address of the packet, and determine that as it is not the MAC of
the VM device (11:22:33:44:55:66), it transmits it to eth0. This
causes the linux bridge to learn (incorrectly) that aa:bb:cc:dd:ee:01
can be reached through eth0.
Essentially VMware has not been designed with there being more
than one MAC address used to the right of the bridge.
One route here would be to drop all packets coming in from eth0
that have the MAC addresses of Dev1 to Dev3. But that is hard
as I'd need to know in advance what Dev1 to Dev3's MAC addresses
are and indeed these can change real time.
A better route (I think) be to do what VMware wants, and only use
one MAC source address to the right of the bridge. This would require
MAC masquerading. I know how to do this with ebtables, but I don't
know how to handle the issue of ARP (IPv4) and ND (IPv6) packets.
The ebtables examples page suggests this is handled by the BROUTE
table DROP-ing, and hence routing the packets. That won't work
for me as I'm not using the IP stack under Linux and indeed there
may be IP address conflicts between the management of the Linux
box and the VLANs which are bridged. What I think I need to do is
rewrite the outgoing arp replies and ND replies going through eth0
so that all MAC addresses are set to that of eth0 (i.e. 11:22:33:44:55:66
on the above). I don't think I can use arptables to do this as
this requires the packets are routed. And that doesn't help with ND.
Any ideas?
--
Alex Bligh
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: ebtables, MAC masquerading, and ARP and ND rewriting
2014-06-04 15:15 ebtables, MAC masquerading, and ARP and ND rewriting Alex Bligh
@ 2014-06-10 14:25 ` Paul Robert Marino
2014-06-13 6:33 ` Alex Bligh
0 siblings, 1 reply; 3+ messages in thread
From: Paul Robert Marino @ 2014-06-10 14:25 UTC (permalink / raw
To: Alex Bligh; +Cc: netfilter
have you tried bonding or teaming instead, then you would have one
virtual device and you wouldn't have to worry about learning mac
addresses. then you can use a bridge to link the VMware Ethernet
interface to the bonded or teamed nics
the scenario you described is not what the bridging driver was designed for.
On Wed, Jun 4, 2014 at 11:15 AM, Alex Bligh <alex@alex.org.uk> wrote:
> I am trying to use Linux to perform in a bridge configuration using
> ebtables. The particular bridge I am plugging Linux into appears to
> have some design flaws (for anyone interested, it's the bridge inside
> VMware with NIC teaming), and the vendor appears to be uninterested
> in fixing it.
>
> The configuration looks like this:
>
> | .......... ...................... aa:bb:cc:dd:ee:01
> | NIC-A : VMware : : Linux bridge :------------ Dev1
> +----------: bridge : : :
> | : : : 11:22:33:44:55:66 : aa:bb:cc:dd:ee:02
> | : :------: eth0 :------------ Dev2
> | NIC-B : : : :
> +----------: : : : aa:bb:cc:dd:ee:03
> | : : : :------------ Dev3
> | :........: :....................:
> LAN
>
> NIC-A and NIC-B are in active/passive mode, however, passive does not
> mean 'does not transmit packets'.
>
> What happens is a broadcast packet leaves device Dev1 with source address
> aa:bb:cc:dd:ee:01, is passed through the linux bridge and transmitted
> through device eth0 to the VMware bridge. It is then transmitted
> out of NIC-A onto the LAN. What then happens is that the switch(es)
> on the LAN transmits the packet through NIC-B back to the VMware
> bridge.
>
> The VMware bridge appears to have an 'interesting' bridge algorithm,
> in that it is not a learning bridge that it appears to examine the
> source address of the packet, and determine that as it is not the MAC of
> the VM device (11:22:33:44:55:66), it transmits it to eth0. This
> causes the linux bridge to learn (incorrectly) that aa:bb:cc:dd:ee:01
> can be reached through eth0.
>
> Essentially VMware has not been designed with there being more
> than one MAC address used to the right of the bridge.
>
> One route here would be to drop all packets coming in from eth0
> that have the MAC addresses of Dev1 to Dev3. But that is hard
> as I'd need to know in advance what Dev1 to Dev3's MAC addresses
> are and indeed these can change real time.
>
> A better route (I think) be to do what VMware wants, and only use
> one MAC source address to the right of the bridge. This would require
> MAC masquerading. I know how to do this with ebtables, but I don't
> know how to handle the issue of ARP (IPv4) and ND (IPv6) packets.
>
> The ebtables examples page suggests this is handled by the BROUTE
> table DROP-ing, and hence routing the packets. That won't work
> for me as I'm not using the IP stack under Linux and indeed there
> may be IP address conflicts between the management of the Linux
> box and the VLANs which are bridged. What I think I need to do is
> rewrite the outgoing arp replies and ND replies going through eth0
> so that all MAC addresses are set to that of eth0 (i.e. 11:22:33:44:55:66
> on the above). I don't think I can use arptables to do this as
> this requires the packets are routed. And that doesn't help with ND.
>
> Any ideas?
>
> --
> Alex Bligh
>
>
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe netfilter" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: ebtables, MAC masquerading, and ARP and ND rewriting
2014-06-10 14:25 ` Paul Robert Marino
@ 2014-06-13 6:33 ` Alex Bligh
0 siblings, 0 replies; 3+ messages in thread
From: Alex Bligh @ 2014-06-13 6:33 UTC (permalink / raw
To: Paul Robert Marino; +Cc: Alex Bligh, Mail List - Netfilter
[-- Attachment #1: Type: text/plain, Size: 4750 bytes --]
Paul,
On 10 Jun 2014, at 15:25, Paul Robert Marino <prmarino1@gmail.com> wrote:
> have you tried bonding or teaming instead, then you would have one
> virtual device and you wouldn't have to worry about learning mac
> addresses. then you can use a bridge to link the VMware Ethernet
> interface to the bonded or teamed nics
>
> the scenario you described is not what the bridging driver was designed for.
The customer is using teaming & bonding which is what creates the
VMware bridge. I need the bridge in Linux because, well, it’s
running eatables, has multiple devices on (not just 3), does
VLAN stuff etc.; actually I simplified and there are many bridges.
Everything works fine until the customer uses NIC teaming on the
LHS.
IE I’m not putting in bridging to solve this. I’m putting in
bridging because I need bridging, then the broken VMware bridge
that its teaming features inserts is breaking the bridge
in the VM.
Alex
>
> On Wed, Jun 4, 2014 at 11:15 AM, Alex Bligh <alex@alex.org.uk> wrote:
>> I am trying to use Linux to perform in a bridge configuration using
>> ebtables. The particular bridge I am plugging Linux into appears to
>> have some design flaws (for anyone interested, it's the bridge inside
>> VMware with NIC teaming), and the vendor appears to be uninterested
>> in fixing it.
>>
>> The configuration looks like this:
>>
>> | .......... ...................... aa:bb:cc:dd:ee:01
>> | NIC-A : VMware : : Linux bridge :------------ Dev1
>> +----------: bridge : : :
>> | : : : 11:22:33:44:55:66 : aa:bb:cc:dd:ee:02
>> | : :------: eth0 :------------ Dev2
>> | NIC-B : : : :
>> +----------: : : : aa:bb:cc:dd:ee:03
>> | : : : :------------ Dev3
>> | :........: :....................:
>> LAN
>>
>> NIC-A and NIC-B are in active/passive mode, however, passive does not
>> mean 'does not transmit packets'.
>>
>> What happens is a broadcast packet leaves device Dev1 with source address
>> aa:bb:cc:dd:ee:01, is passed through the linux bridge and transmitted
>> through device eth0 to the VMware bridge. It is then transmitted
>> out of NIC-A onto the LAN. What then happens is that the switch(es)
>> on the LAN transmits the packet through NIC-B back to the VMware
>> bridge.
>>
>> The VMware bridge appears to have an 'interesting' bridge algorithm,
>> in that it is not a learning bridge that it appears to examine the
>> source address of the packet, and determine that as it is not the MAC of
>> the VM device (11:22:33:44:55:66), it transmits it to eth0. This
>> causes the linux bridge to learn (incorrectly) that aa:bb:cc:dd:ee:01
>> can be reached through eth0.
>>
>> Essentially VMware has not been designed with there being more
>> than one MAC address used to the right of the bridge.
>>
>> One route here would be to drop all packets coming in from eth0
>> that have the MAC addresses of Dev1 to Dev3. But that is hard
>> as I'd need to know in advance what Dev1 to Dev3's MAC addresses
>> are and indeed these can change real time.
>>
>> A better route (I think) be to do what VMware wants, and only use
>> one MAC source address to the right of the bridge. This would require
>> MAC masquerading. I know how to do this with ebtables, but I don't
>> know how to handle the issue of ARP (IPv4) and ND (IPv6) packets.
>>
>> The ebtables examples page suggests this is handled by the BROUTE
>> table DROP-ing, and hence routing the packets. That won't work
>> for me as I'm not using the IP stack under Linux and indeed there
>> may be IP address conflicts between the management of the Linux
>> box and the VLANs which are bridged. What I think I need to do is
>> rewrite the outgoing arp replies and ND replies going through eth0
>> so that all MAC addresses are set to that of eth0 (i.e. 11:22:33:44:55:66
>> on the above). I don't think I can use arptables to do this as
>> this requires the packets are routed. And that doesn't help with ND.
>>
>> Any ideas?
>>
>> --
>> Alex Bligh
>>
>>
>>
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe netfilter" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
> --
> To unsubscribe from this list: send the line "unsubscribe netfilter" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
>
--
Alex Bligh
[-- Attachment #2: Message signed with OpenPGP using GPGMail --]
[-- Type: application/pgp-signature, Size: 842 bytes --]
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2014-06-13 6:33 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2014-06-04 15:15 ebtables, MAC masquerading, and ARP and ND rewriting Alex Bligh
2014-06-10 14:25 ` Paul Robert Marino
2014-06-13 6:33 ` Alex Bligh
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.