| View previous topic :: View next topic |
| Author |
Message |
WWWW
Tux's lil' helper
Joined: 30 Nov 2014
Posts: 143
|
 Posted: Thu Nov 19, 2015 12:24 am Post subject: two nics, separate inside the OS possible? |
 |
|
hello,
One nic is connected to an internal network which is set up with the standard networking, nothing fancyful. I think I want it to remain like that because a server, apache (default install), mysql, php, etc... is using it.
I am aware of having to routes to separate traffic from nics and so on. Now is too complicated to assign programs to their proper nic. I can't have apache talking to nic1, php to nic2 and mysql misconfigured listening to lo.
They are all tied together with something like this, (taken unimagingly straight out the man pages):
| Code: |
route add default gw aaa.bbb.ccc.ddd
|
Until here is all good.
What I am facing problems with is that I added a second nic because I want to connect a virtualized m$$$ to EN'SAY.
I sorta know how to hook up qemu to a nic but I realize it's not possible to avoid the route table.
At first I thought to be a piece of cake believing I could assing the second interface bare to qemu, thinking that qemu/m$$ could somehow bypass linux networking, the packets jumping from the second nic straight into m$$.
I think it doesn't work like this.
My idea is the following in case is possible.
nic1 with assigned a default route, for system traffic.
nic2 assign separate non-conflicting route to isolate the traffic for qemu.
Is this doable? Can a system have a default route for one nic AND a second nic with its own routing table?
I thought this could be easy like assigning a raw device to qemu -file device=/dev/sda.
For my solution I imagine qemu could do something like this -net device=enp2s0,format=bare_metal.
I am aware of passthrough, but I don't know if it requires the same IOMMU requisites or VGA passthrough. This mobo definately can't passthrough a VGA. Perhaps net device doesn't need IOMMU to passthrough.
Recapping, is it possible for a second nic2 to have its own routing table while nic1 has a default routing?
thanks.
p.s.: I am really after the fastest solution so I will listen to any other approach that I haven't mentioned. |
|
| Back to top |
|
 |
krinn
Watchman
Joined: 02 May 2003
Posts: 7470
|
| Posted: Thu Nov 19, 2015 10:10 am Post subject: |
|
|
how about adding nic1 as gw to nic2?
route add -net 192.168.1.0 netmask 255.255.255.0 gw 192.168.0.4
this way nic2 (192.168.1 range) route is only toward nic1 (192.168.0.4 here) and never to default
It's what you want?: nic1 classic, nic2 no access to default while still can speak with nic1 |
|
| Back to top |
|
|
WWWW
Tux's lil' helper
Joined: 30 Nov 2014
Posts: 143
|
| Posted: Thu Nov 19, 2015 12:27 pm Post subject: |
|
|
| krinn wrote: | how about adding nic1 as gw to nic2?
route add -net 192.168.1.0 netmask 255.255.255.0 gw 192.168.0.4
this way nic2 (192.168.1 range) route is only toward nic1 (192.168.0.4 here) and never to default
It's what you want?: nic1 classic, nic2 no access to default while still can speak with nic1 |
Thank you for replaying.
No. The two nics are completely separated networks from the outside.
NIC1 classic, already set up and working.
NIC2 is the one that has the interwebz ethernet plugged into, yet not configured (due to the confusion explained in my post). NIC2 should by pass linux completely, if possible, as is to be connected to m$$$ under qemu.
In other words, m$$$ is sitting all alone there unable to talk to its mothership.
At this point I don't care communication between nic1 and nic2. I need m$$ connected as fast as possible, so whatever is simpler.
Reviewing qemu's networking amazingly doesn't have a simple option to grab a nic bare-metal and let the virtualized OS configure it.
While PCI passthrough would be the ideal solution, I think this mobo lacks a fully IOMMU compliable BIOS to do so.
It seems that what I want to do is not possible due to the nature of networking on Linux OS internal. No matter what option, excepet for pci passthrough, any traffic that touches a nic has to be managed by linux.
thanks. |
|
| Back to top |
|
|
krinn
Watchman
Joined: 02 May 2003
Posts: 7470
|
| Posted: Fri Nov 20, 2015 8:33 am Post subject: |
|
|
| WWWW wrote: | | It seems that what I want to do is not possible due to the nature of networking on Linux OS internal. |
This seems more a limit by qemu than linux.
It's virtualisation, not emulation ; you don't emulate any hardware... you reuse existing hw control by the host inside the guest.
I must tell i'm unsure what you are trying to achieve (yeah i know you told us what you wish do), but i can't really get what you are trying to do.
If you want hide any activity from the guest os network, you cannot, the card use your network.
If you want just separate them, you have nothing to do, if nic1 is 192.168.0 range, and you setup nic2 with a 192.168.1 range, both cannot speak with each other without a bridge.
So you just have to setup a route to the gw nic2 should use
route add --net 192.168.1.0 gw whatever_ip_windows_gw_use dev eth1
It's only when you have no route define that default route will be use. |
|
| Back to top |
|
|
nativemad
Developer
Joined: 30 Aug 2004
Posts: 918
Location: Switzerland
|
| Posted: Fri Nov 20, 2015 11:11 am Post subject: |
|
|
Hi,
you could simply make a bridge device without an ip bound to it on the hostside. The second nic and a tap-device for qemu would then be bridged and the VM only sees the net on nic2 while the host-OS can't reach ip's on the second lan....
To do that manually:
| Code: | tunctl -t tap0
brctl addbr br0
brctl addif br0 enp2s0
brctl addif br0 tap0
ifconfig enp2s0 up
ifconfig br0 up
ifconfig tap0 up
|
Here is the same for /etc/conf.d/net:
| Code: |
config_br0="null"
config_enp2s0="null"
config_tap0="null"
tuntap_tap0="tap"
bridge_br0="enp2s0 tap0"
rc_net_br0_need="net.enp2s0 net.tap0"
|
After that you can start the VM with these options (replace the X with your desired mac):
| Code: | | -net nic,macaddr=XX:XX:XX:XX:XX:XX,model=virtio,netdev=net0 -netdev tap,ifname=tap0,script=no,id=net0 |
HTH, cheers
_________________
Power to the people! |
|
| Back to top |
|
|
szatox
Advocate
Joined: 27 Aug 2013
Posts: 3136
|
| Posted: Fri Nov 20, 2015 7:24 pm Post subject: |
|
|
Actually if you want a connection between guest and host, all you have to do is assign an IP to the TAP interface bound by your VM.
If you want the guest to be able to reach the internet, you can either let it use "user mode" (the default that happens when you don't provide TAP) - your VM wil lbe behind NAT though.
Or, you can route that traffic from TAP to the internet with iptables.
When you have more VMs and you want to put them on a single network segment, bridges come in handy. You enslave TAP devices with a bridge and assign a single host's IP to the bridge.
Note: none of the above uses your NIC2
Expanding your network even further, you may want to put your VMs on the same network as other physical machines in your LAN. In this case you create a bridge, and give it IP just like with multiple VMs, and enslave NIC2 (without IP) as well as TAP devices.
Have your pick. Whatever you want, you just name it and you've got it. You can even enslave NIC1 with that bridge too and have you host act as a big switch rather than a router. Just bear in mind every setup has some drawbacks. The one with one big bridge for everything most likely is not something you want.
Note: none of those requires you to define routing table, if you make sure IP pools with equal masks don't overlap.
E.g. 10.0.1.0/24 for VMs, 10.0.2.0/24 for LAN don't overlap, and 0.0.0.0/0 (default) has lower priority and will be chosen every time none of the other pools match. |
|
| Back to top |
|
|
nativemad
Developer
Joined: 30 Aug 2004
Posts: 918
Location: Switzerland
|
| Posted: Fri Nov 20, 2015 8:21 pm Post subject: |
|
|
| szatox wrote: | You can even enslave NIC1 with that bridge too and have you host act as a big switch rather than a router. Just bear in mind every setup has some drawbacks. The one with one big bridge for everything most likely is not something you want.
|
Yeah, if all you want is the host to reach the other net you could assign an ip on the bridge or add another tap device in the bridge with an ip assigned. (I wouldn't use the VM's tap for that, as you can better place rules on it if it is seperated)
| szatox wrote: | Note: none of those requires you to define routing table, if you make sure IP pools with equal masks don't overlap.
E.g. 10.0.1.0/24 for VMs, 10.0.2.0/24 for LAN don't overlap, and 0.0.0.0/0 (default) has lower priority and will be chosen every time none of the other pools match. |
It gets tricky if you have two default routes (the VMs lan has a different gateway) and you want to answer services on the lower-priority default-route (on the host or a vm that sees all nets).... In that case you'll need iproute2 and some rules...
You can do quite weird setups if you want with VMs as firewalls in between the nets and so on! I really like it.
And all that networking stuff is done with tools already available outside of qemu... That's probably the reason why nobody wants to hook an entire nic to just one VM! 
I guess we're already way beyond what is asked for, but could also be interesting... If you like challenge and you could do the whole setup on one nic and/or have another one present, there is also bonding/teaming! 
_________________
Power to the people! |
|
| Back to top |
|
|
hceline
n00b
Joined: 30 Aug 2015
Posts: 36
|
| Posted: Fri Nov 20, 2015 11:52 pm Post subject: |
|
|
| I would suggest pci-passtrough if your cpu/chipset support it. |
|
| Back to top |
|
|
szatox
Advocate
Joined: 27 Aug 2013
Posts: 3136
|
| Posted: Sat Nov 21, 2015 2:21 pm Post subject: |
|
|
| Quote: | nic1 with assigned a default route, for system traffic.
nic2 assign separate non-conflicting route to isolate the traffic for qemu. |
Back to the topic, guys 
Leave NIC1 as the default. Create a bridge and enslave TAP and NIC2. Leave TAP, NIC2 and bridge without IP or assign IP to the bridge if you want to allow VM and host talk to each other.
Don't set any routing rules on host, this bridge will behave like a switch attaching your VM to whatever network your NIC2 is connected to. |
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
Networking & Security
