On 04/03/2018 08:02 AM, Marc Roos wrote:
How can I get the 10.11.12.x traffic received on tun1 at host B to eth2, and traffic 172.16.1.x to eth1?
Based on your last paragraph and macvtap comment it sounds like you are wanting to extend the physically separate 172.16.1.0/24 and 10.11.12.0/24 networks from server B to VMs on server A. Is that correct?
When I put the tun1 interface of server B in a bridge with eth1 I am able to ping several 172.16.1.x ip's from server A. And communication on this network seems to be ok.
Okay.
When I add eth2 to the bridge, the whole network goes down. (Because of a 'loop'?)
Did you remove eth1 from the bridge before starting your test?Are eth1 and eth2 physically connected to the same network? Thus forming a loop when eth1 and eth2 are bridged together?
Is (Rappid) Spanning Tree Protocol enabled anywhere? - I'm guessing not since things apparently go down because of a loop.
I thought of creating a 2nd gretab tunnel and use each tunnel for a network, but I think there is probably a better solution.
I'm guessing the 2nd gretap tunnel between the same endpoints (IPs on server A & B) won't work as desired.
How will servers A & B differentiate the gretap tunnels? - My understanding is that GRE(TAP) uses the source & destination IP addresses for the tunnel endpoints to differentiate. Seeing as how these would be the same....
I agree that there are other solutions that are likely better. VLANs and VXLAN immediately come to mind.
Please confirm if server A and server B have a layer 2 connection (that will support 802.1Q VLANs) between them.
I also don’t think iptables should be necessary, because I don’t want to do any natting (However I have default policy DROP on INPUT, OUTPUT, FORWARD)
IPTables (and EBTables) are used for more than just NATing. You can also use it to steer traffic based on source IP.
Why do you have the IPTables policies set to DROP?
I have a server A that sends 172.16.1.x and 10.11.12.x traffic via a gretab tunnel 192.168.1.x to server B. (Putting vms with a macvtap on tun1 on host A)
I don't think that's going to work as desired.Consider for a moment, if you will, using a single macvtap for the VMs that need to access mulitple network segments if the VMs were living on server B. Either all of the VMs accessing 172.16.1.0/24 would work and all of the VMs accessing 10.11.12.0/24 would fail -or- all of the VMs accessing 172.16.1.0/24 would fail and all of the VMs accessing 10.11.12.0/24 would work. Having a singular macvtap and putting multiple VMs on it that need to access separate physical networks is veyr likely not going to work. (Or I have the wrong understanding of macvtap.)
+-------------+ +------------+
172.16.1.x | B | | A |
-------|eth1 | 192.168.1.x GRETAP | |
| tun1|-----------------------------|tun1 |
10.11.12.x | | | |
-------|eth2 | | |
+-------------+ +------------+
It would be possible to use a single gretap tunnel, bridged with eth1 & eth2, /and/ EBTables to prevent the loop between eth1 & eth2 while still allowing each of them to communicate with tun1.
/If/ servers A & B share a layer 2 network that will pass 802.1Q VLAN tagged frames, I'd think seriously about using multiple VLANs. One VLAN for 172.16.1.0/24 (eth1) and another for 10.11.12.0/24 (eth2). Then have two macvtap adapters on server A, one connected to each VLAN interface. - You would need to bridge eth1 to one VLAN interface and eth2 to the other VLAN interface on server B.
If servers A & B /don't/ share a layer 2 network, I would consider VXLAN. VXLANs will work very similarly to VLANS. Instead of using VLAN interfaces, you would use VXLAN Tunnel Endpoint (a.k.a. VTEP) interfaces. You would still need to bridge eth1 to vtep1 and eth2 to vtep2 on server B.
Both the VLAN and VXLAN solution would very likely require mulitple macvtap configurations on server A, as each would be a logical extension of the 172.16.1.0/24 (eth1) and 10.11.12.0/24 (eth2) networks. (See previous comments.) - In short, you need to separate the network traffic somewhere (server A or B) and somehow (EBTables or multiple macvtap interfaces).
-- Grant. . . . unix || die
Attachment:
smime.p7s
Description: S/MIME Cryptographic Signature
