Re: gretap tunnel redirecting 2 different networks on destination host to nics

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