Hyper-V virtual network switch
So this might be a very basic and very stupid question but for the life of me I can not find an explanation on the web anywhere as to how this should work.
I have a very basic Hyper-V setup on my Windows 10 machine. I have two VM's one is a Mikrotik image and the other is lUbuntu. At this point I'm working on the most basic network configuration. I want the Mikrotik to behave as a router and firewall between the lUbuntu system and the outside.
I have two virtual network switches (VS) setup in Hyper-V. First the default switch (call it Outside) and second an internal switch (call it Inside) I created. The Mikrotik box has two VNIC's setup that are connected to the two switches. It acts as a DHCP-server on the VNIC which is connected to the Inside VNS.
If I look at my Host system (the Windows 10 I'm running the Hyper-V on) I see the expected two virtual switches as NIC's one vEthernet (Inside) and one vEthernet (Outside).
The issue I have is that the (Inside) NIC has a APIPA address. When I try to get it to renew the adress using ipconfig /renew the command times out. At the same time the Lubuntu system which has one VNIC which is connected to the (Inside) VS works just fine and gets an IP address from the appropriate pool right away.
So my first question is why does the Host system not behave the way I would expect with regards to a Hyper-V Virtual switch?
I assumed from what I read about Hyper-V virtual switches that the Host operating system should see it pretty much the same as a guest. Except it knows it's virtual I guess.
networking hyper-v
asked Dec 24 '18 at 21:02
DRFDRF
90110
migrated from serverfault.com Dec 24 '18 at 22:45
This question came from our site for system and network administrators.
|
show 7 more comments
So this might be a very basic and very stupid question but for the life of me I can not find an explanation on the web anywhere as to how this should work.
I have a very basic Hyper-V setup on my Windows 10 machine. I have two VM's one is a Mikrotik image and the other is lUbuntu. At this point I'm working on the most basic network configuration. I want the Mikrotik to behave as a router and firewall between the lUbuntu system and the outside.
I have two virtual network switches (VS) setup in Hyper-V. First the default switch (call it Outside) and second an internal switch (call it Inside) I created. The Mikrotik box has two VNIC's setup that are connected to the two switches. It acts as a DHCP-server on the VNIC which is connected to the Inside VNS.
If I look at my Host system (the Windows 10 I'm running the Hyper-V on) I see the expected two virtual switches as NIC's one vEthernet (Inside) and one vEthernet (Outside).
The issue I have is that the (Inside) NIC has a APIPA address. When I try to get it to renew the adress using ipconfig /renew the command times out. At the same time the Lubuntu system which has one VNIC which is connected to the (Inside) VS works just fine and gets an IP address from the appropriate pool right away.
So my first question is why does the Host system not behave the way I would expect with regards to a Hyper-V Virtual switch?
I assumed from what I read about Hyper-V virtual switches that the Host operating system should see it pretty much the same as a guest. Except it knows it's virtual I guess.
networking hyper-v
asked Dec 24 '18 at 21:02
DRFDRF
90110
migrated from serverfault.com Dec 24 '18 at 22:45
This question came from our site for system and network administrators.
You need something on the internal network providing IP addresses. Either static IPs on each client on this network, or a DHCP server.
– music2myear
Dec 24 '18 at 23:15
@music2myear As the question states I have a Mikrotik router which is setup as a DHCP-server on the VNIC that is bound to the internal VS.
– DRF
Dec 25 '18 at 7:58
Either it is not providing the correct service, or the other VMs aren't finding that service.
– music2myear
Dec 26 '18 at 2:21
@music2myear The VM's are finding the service just fine. The lUbuntu VM gets an IP address no problem. The issue is with the Host OS not the VM's.
– DRF
Dec 26 '18 at 9:46
One more question: If the purpose of the Internal switch is to allow communication between the VMs and to provide communication Lubuntu to the Mikrotik, why didn't you choose a Private switch? The Private switch allows communication only between the VMs on your host and so sounds like the correct switch for the job. An Internal switch generally acts as a bridge on your host, allowing VMs access to host resources, which is not what it sounds like you are trying to do with that particular switch.
– music2myear
Dec 26 '18 at 16:13
|
show 7 more comments
So this might be a very basic and very stupid question but for the life of me I can not find an explanation on the web anywhere as to how this should work.
I have a very basic Hyper-V setup on my Windows 10 machine. I have two VM's one is a Mikrotik image and the other is lUbuntu. At this point I'm working on the most basic network configuration. I want the Mikrotik to behave as a router and firewall between the lUbuntu system and the outside.
I have two virtual network switches (VS) setup in Hyper-V. First the default switch (call it Outside) and second an internal switch (call it Inside) I created. The Mikrotik box has two VNIC's setup that are connected to the two switches. It acts as a DHCP-server on the VNIC which is connected to the Inside VNS.
If I look at my Host system (the Windows 10 I'm running the Hyper-V on) I see the expected two virtual switches as NIC's one vEthernet (Inside) and one vEthernet (Outside).
The issue I have is that the (Inside) NIC has a APIPA address. When I try to get it to renew the adress using ipconfig /renew the command times out. At the same time the Lubuntu system which has one VNIC which is connected to the (Inside) VS works just fine and gets an IP address from the appropriate pool right away.
So my first question is why does the Host system not behave the way I would expect with regards to a Hyper-V Virtual switch?
I assumed from what I read about Hyper-V virtual switches that the Host operating system should see it pretty much the same as a guest. Except it knows it's virtual I guess.
networking hyper-v
asked Dec 24 '18 at 21:02
DRFDRF
90110
So this might be a very basic and very stupid question but for the life of me I can not find an explanation on the web anywhere as to how this should work.
I have a very basic Hyper-V setup on my Windows 10 machine. I have two VM's one is a Mikrotik image and the other is lUbuntu. At this point I'm working on the most basic network configuration. I want the Mikrotik to behave as a router and firewall between the lUbuntu system and the outside.
I have two virtual network switches (VS) setup in Hyper-V. First the default switch (call it Outside) and second an internal switch (call it Inside) I created. The Mikrotik box has two VNIC's setup that are connected to the two switches. It acts as a DHCP-server on the VNIC which is connected to the Inside VNS.
If I look at my Host system (the Windows 10 I'm running the Hyper-V on) I see the expected two virtual switches as NIC's one vEthernet (Inside) and one vEthernet (Outside).
The issue I have is that the (Inside) NIC has a APIPA address. When I try to get it to renew the adress using ipconfig /renew the command times out. At the same time the Lubuntu system which has one VNIC which is connected to the (Inside) VS works just fine and gets an IP address from the appropriate pool right away.
So my first question is why does the Host system not behave the way I would expect with regards to a Hyper-V Virtual switch?
I assumed from what I read about Hyper-V virtual switches that the Host operating system should see it pretty much the same as a guest. Except it knows it's virtual I guess.
networking hyper-v
networking hyper-v
asked Dec 24 '18 at 21:02
DRFDRF
90110
asked Dec 24 '18 at 21:02
DRFDRF
90110
asked Dec 24 '18 at 21:02
DRFDRF
90110
asked Dec 24 '18 at 21:02
DRFDRF
90110
asked Dec 24 '18 at 21:02
DRFDRF
90110
90110
migrated from serverfault.com Dec 24 '18 at 22:45
This question came from our site for system and network administrators.
migrated from serverfault.com Dec 24 '18 at 22:45
This question came from our site for system and network administrators.
You need something on the internal network providing IP addresses. Either static IPs on each client on this network, or a DHCP server.
– music2myear
Dec 24 '18 at 23:15
@music2myear As the question states I have a Mikrotik router which is setup as a DHCP-server on the VNIC that is bound to the internal VS.
– DRF
Dec 25 '18 at 7:58
Either it is not providing the correct service, or the other VMs aren't finding that service.
– music2myear
Dec 26 '18 at 2:21
@music2myear The VM's are finding the service just fine. The lUbuntu VM gets an IP address no problem. The issue is with the Host OS not the VM's.
– DRF
Dec 26 '18 at 9:46
One more question: If the purpose of the Internal switch is to allow communication between the VMs and to provide communication Lubuntu to the Mikrotik, why didn't you choose a Private switch? The Private switch allows communication only between the VMs on your host and so sounds like the correct switch for the job. An Internal switch generally acts as a bridge on your host, allowing VMs access to host resources, which is not what it sounds like you are trying to do with that particular switch.
– music2myear
Dec 26 '18 at 16:13
|
show 7 more comments
You need something on the internal network providing IP addresses. Either static IPs on each client on this network, or a DHCP server.
– music2myear
Dec 24 '18 at 23:15
@music2myear As the question states I have a Mikrotik router which is setup as a DHCP-server on the VNIC that is bound to the internal VS.
– DRF
Dec 25 '18 at 7:58
Either it is not providing the correct service, or the other VMs aren't finding that service.
– music2myear
Dec 26 '18 at 2:21
@music2myear The VM's are finding the service just fine. The lUbuntu VM gets an IP address no problem. The issue is with the Host OS not the VM's.
– DRF
Dec 26 '18 at 9:46
One more question: If the purpose of the Internal switch is to allow communication between the VMs and to provide communication Lubuntu to the Mikrotik, why didn't you choose a Private switch? The Private switch allows communication only between the VMs on your host and so sounds like the correct switch for the job. An Internal switch generally acts as a bridge on your host, allowing VMs access to host resources, which is not what it sounds like you are trying to do with that particular switch.
– music2myear
Dec 26 '18 at 16:13
You need something on the internal network providing IP addresses. Either static IPs on each client on this network, or a DHCP server.
– music2myear
Dec 24 '18 at 23:15
You need something on the internal network providing IP addresses. Either static IPs on each client on this network, or a DHCP server.
– music2myear
Dec 24 '18 at 23:15
@music2myear As the question states I have a Mikrotik router which is setup as a DHCP-server on the VNIC that is bound to the internal VS.
– DRF
Dec 25 '18 at 7:58
@music2myear As the question states I have a Mikrotik router which is setup as a DHCP-server on the VNIC that is bound to the internal VS.
– DRF
Dec 25 '18 at 7:58
Either it is not providing the correct service, or the other VMs aren't finding that service.
– music2myear
Dec 26 '18 at 2:21
Either it is not providing the correct service, or the other VMs aren't finding that service.
– music2myear
Dec 26 '18 at 2:21
@music2myear The VM's are finding the service just fine. The lUbuntu VM gets an IP address no problem. The issue is with the Host OS not the VM's.
– DRF
Dec 26 '18 at 9:46
@music2myear The VM's are finding the service just fine. The lUbuntu VM gets an IP address no problem. The issue is with the Host OS not the VM's.
– DRF
Dec 26 '18 at 9:46
One more question: If the purpose of the Internal switch is to allow communication between the VMs and to provide communication Lubuntu to the Mikrotik, why didn't you choose a Private switch? The Private switch allows communication only between the VMs on your host and so sounds like the correct switch for the job. An Internal switch generally acts as a bridge on your host, allowing VMs access to host resources, which is not what it sounds like you are trying to do with that particular switch.
– music2myear
Dec 26 '18 at 16:13
One more question: If the purpose of the Internal switch is to allow communication between the VMs and to provide communication Lubuntu to the Mikrotik, why didn't you choose a Private switch? The Private switch allows communication only between the VMs on your host and so sounds like the correct switch for the job. An Internal switch generally acts as a bridge on your host, allowing VMs access to host resources, which is not what it sounds like you are trying to do with that particular switch.
– music2myear
Dec 26 '18 at 16:13
|
show 7 more comments
1 Answer
1
active
oldest
votes
So you have . . .
The VM Mikrotik machine configured with two NIC's with one
connected to the "internal" Hyper-V switch (inside) that has the DHCP service running on it, and the other is connected to an "external" Hyper-V switch (outside), etc.The lUbuntu VM has one NIC and you connect that to the "internal" Hyper-V switch which has a DHCP server service listening on it from the Mikrotik machine to process requests accordingly.
Clarification Resources
1. Configuring VM Networking on a Hyper-V NAT Switch
Virtual machines that are connected to a NAT virtual switch are in an
isolated broadcast domain, a different one to the LAN. The NAT switch
does not have flat, 2-way routing to the LAN that the host is
connected to. The virtual switch is an internal virtual switch that
the host NATs to the LAN. This means that, by default, the virtual
machines can connect to the LAN, but the LAN cannot connect to the
virtual machines. And even if we do create NAT rules, the virtual
switch remains a separate broadcast domain from the LAN.
The virtual switch is somewhat isolated from the LAN, especially from broadcast-based services such as DHCP. You can deploy your own DHCP server(s) as virtual machines that are connected to the virtual switch. The scope of these servers is limited to the virtual switch, so there is no impact on the LAN, and network administrators should not have a problem with your DHCP servers being deployed on the NAT virtual switch.
Source
2. Internal Hyper-V switch configuration
Internal: Allows communication between virtual machines on the same Hyper-V server, and between the virtual machines and the
management host operating system.
Source
3. Visualization of all switch modes
Source
Potential Workarounds
The way I've handled this is to ensure the VMs connected to the internal switch have IP addresses assigned, and then from the host Hyper-V management server, I then can access those machines from the host OS that way via their IP addresses.
You could probably look over the Set up a NAT network, and be sure to have a full understanding of it and then Create a NAT virtual network and configure it accordingly to see if it'll do what you want using the "internal" Hyper-V switch functionality.
Since the VMs can talk with the Mikrotik machine, perhaps you can setup routing in it and then tell the VMs to use it's accessible internal Hyper-V switch IP address as the default gateway on all those devices, and just let it do the routing when things need accessed that's not connected to the internal Hyper-V switch.
Check your VLAN configuration and see Configure virtual local area networks for Hyper-V in the event something at this level is needed or causing trouble.
Configure and View VLAN Settings on Hyper-V Virtual Switch Ports
Check any OS level firewall rules for the blocking of the traffic coming from the internal Hyper-V switch to the host Hyper-V or any of the connected VMs.
answered Dec 27 '18 at 17:52
Pimp Juice ITPimp Juice IT
23.8k113972
Hmm I think the conclusion is incorrect though the information is certainly interesting. Notice that the picture you provide shows the Internal switch being connected to a specific (virtual)NIC in the Host OS. This seems important especially in the case where you are running the Hyper-V on a Windows-10 machine (I believe that's called client Hyper-V?) in which case the first part of that picture is actually wrong. Or rather misleading since the "Default switch" is none of those three. It behaves as explained in part 1.
– DRF
Dec 27 '18 at 18:17
That means that the "Default switch" actually performs NAT on things coming in from the outside. I don't (yet) know what that means for Host to Guest communication on this switch but it's (probably) not the same as the External switch where the Host OS will have an IP address in the same pool as the VM's and all of these will behave as if they are behind a switch which then is connected to the outside through the Physical Network card.
– DRF
Dec 27 '18 at 18:20
(Note I have actually already figured out where my issue was with the help of a friend. Specifically I messed up the VLAN's on the Host NIC. I put the Host OS into Vlan 2. Disabling "Vlan identification for management operating system" fixed my issue. And the VNIC in the Host OS now gets and IP address from the Mikrotik DHCP server without issues. So you're exactly right in your comment there was another level of blocking.
– DRF
Dec 27 '18 at 18:23
@DRF I re-read that statement and I also agree it was not correct so I purged that content from the answer. I also added some additional detail and resources that may be helpful with regard to the VLAN level stuff and the other levels of blocking such as OS level firewalls and such.
– Pimp Juice IT
Dec 27 '18 at 19:01
add a comment |
Your Answer
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "3"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fsuperuser.com%2fquestions%2f1387471%2fhyper-v-virtual-network-switch%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
So you have . . .
The VM Mikrotik machine configured with two NIC's with one
connected to the "internal" Hyper-V switch (inside) that has the DHCP service running on it, and the other is connected to an "external" Hyper-V switch (outside), etc.The lUbuntu VM has one NIC and you connect that to the "internal" Hyper-V switch which has a DHCP server service listening on it from the Mikrotik machine to process requests accordingly.
Clarification Resources
1. Configuring VM Networking on a Hyper-V NAT Switch
Virtual machines that are connected to a NAT virtual switch are in an
isolated broadcast domain, a different one to the LAN. The NAT switch
does not have flat, 2-way routing to the LAN that the host is
connected to. The virtual switch is an internal virtual switch that
the host NATs to the LAN. This means that, by default, the virtual
machines can connect to the LAN, but the LAN cannot connect to the
virtual machines. And even if we do create NAT rules, the virtual
switch remains a separate broadcast domain from the LAN.
The virtual switch is somewhat isolated from the LAN, especially from broadcast-based services such as DHCP. You can deploy your own DHCP server(s) as virtual machines that are connected to the virtual switch. The scope of these servers is limited to the virtual switch, so there is no impact on the LAN, and network administrators should not have a problem with your DHCP servers being deployed on the NAT virtual switch.
Source
2. Internal Hyper-V switch configuration
Internal: Allows communication between virtual machines on the same Hyper-V server, and between the virtual machines and the
management host operating system.
Source
3. Visualization of all switch modes
Source
Potential Workarounds
The way I've handled this is to ensure the VMs connected to the internal switch have IP addresses assigned, and then from the host Hyper-V management server, I then can access those machines from the host OS that way via their IP addresses.
You could probably look over the Set up a NAT network, and be sure to have a full understanding of it and then Create a NAT virtual network and configure it accordingly to see if it'll do what you want using the "internal" Hyper-V switch functionality.
Since the VMs can talk with the Mikrotik machine, perhaps you can setup routing in it and then tell the VMs to use it's accessible internal Hyper-V switch IP address as the default gateway on all those devices, and just let it do the routing when things need accessed that's not connected to the internal Hyper-V switch.
Check your VLAN configuration and see Configure virtual local area networks for Hyper-V in the event something at this level is needed or causing trouble.
Configure and View VLAN Settings on Hyper-V Virtual Switch Ports
Check any OS level firewall rules for the blocking of the traffic coming from the internal Hyper-V switch to the host Hyper-V or any of the connected VMs.
answered Dec 27 '18 at 17:52
Pimp Juice ITPimp Juice IT
23.8k113972
Hmm I think the conclusion is incorrect though the information is certainly interesting. Notice that the picture you provide shows the Internal switch being connected to a specific (virtual)NIC in the Host OS. This seems important especially in the case where you are running the Hyper-V on a Windows-10 machine (I believe that's called client Hyper-V?) in which case the first part of that picture is actually wrong. Or rather misleading since the "Default switch" is none of those three. It behaves as explained in part 1.
– DRF
Dec 27 '18 at 18:17
That means that the "Default switch" actually performs NAT on things coming in from the outside. I don't (yet) know what that means for Host to Guest communication on this switch but it's (probably) not the same as the External switch where the Host OS will have an IP address in the same pool as the VM's and all of these will behave as if they are behind a switch which then is connected to the outside through the Physical Network card.
– DRF
Dec 27 '18 at 18:20
(Note I have actually already figured out where my issue was with the help of a friend. Specifically I messed up the VLAN's on the Host NIC. I put the Host OS into Vlan 2. Disabling "Vlan identification for management operating system" fixed my issue. And the VNIC in the Host OS now gets and IP address from the Mikrotik DHCP server without issues. So you're exactly right in your comment there was another level of blocking.
– DRF
Dec 27 '18 at 18:23
@DRF I re-read that statement and I also agree it was not correct so I purged that content from the answer. I also added some additional detail and resources that may be helpful with regard to the VLAN level stuff and the other levels of blocking such as OS level firewalls and such.
– Pimp Juice IT
Dec 27 '18 at 19:01
add a comment |
So you have . . .
The VM Mikrotik machine configured with two NIC's with one
connected to the "internal" Hyper-V switch (inside) that has the DHCP service running on it, and the other is connected to an "external" Hyper-V switch (outside), etc.The lUbuntu VM has one NIC and you connect that to the "internal" Hyper-V switch which has a DHCP server service listening on it from the Mikrotik machine to process requests accordingly.
Clarification Resources
1. Configuring VM Networking on a Hyper-V NAT Switch
Virtual machines that are connected to a NAT virtual switch are in an
isolated broadcast domain, a different one to the LAN. The NAT switch
does not have flat, 2-way routing to the LAN that the host is
connected to. The virtual switch is an internal virtual switch that
the host NATs to the LAN. This means that, by default, the virtual
machines can connect to the LAN, but the LAN cannot connect to the
virtual machines. And even if we do create NAT rules, the virtual
switch remains a separate broadcast domain from the LAN.
The virtual switch is somewhat isolated from the LAN, especially from broadcast-based services such as DHCP. You can deploy your own DHCP server(s) as virtual machines that are connected to the virtual switch. The scope of these servers is limited to the virtual switch, so there is no impact on the LAN, and network administrators should not have a problem with your DHCP servers being deployed on the NAT virtual switch.
Source
2. Internal Hyper-V switch configuration
Internal: Allows communication between virtual machines on the same Hyper-V server, and between the virtual machines and the
management host operating system.
Source
3. Visualization of all switch modes
Source
Potential Workarounds
The way I've handled this is to ensure the VMs connected to the internal switch have IP addresses assigned, and then from the host Hyper-V management server, I then can access those machines from the host OS that way via their IP addresses.
You could probably look over the Set up a NAT network, and be sure to have a full understanding of it and then Create a NAT virtual network and configure it accordingly to see if it'll do what you want using the "internal" Hyper-V switch functionality.
Since the VMs can talk with the Mikrotik machine, perhaps you can setup routing in it and then tell the VMs to use it's accessible internal Hyper-V switch IP address as the default gateway on all those devices, and just let it do the routing when things need accessed that's not connected to the internal Hyper-V switch.
Check your VLAN configuration and see Configure virtual local area networks for Hyper-V in the event something at this level is needed or causing trouble.
Configure and View VLAN Settings on Hyper-V Virtual Switch Ports
Check any OS level firewall rules for the blocking of the traffic coming from the internal Hyper-V switch to the host Hyper-V or any of the connected VMs.
answered Dec 27 '18 at 17:52
Pimp Juice ITPimp Juice IT
23.8k113972
Hmm I think the conclusion is incorrect though the information is certainly interesting. Notice that the picture you provide shows the Internal switch being connected to a specific (virtual)NIC in the Host OS. This seems important especially in the case where you are running the Hyper-V on a Windows-10 machine (I believe that's called client Hyper-V?) in which case the first part of that picture is actually wrong. Or rather misleading since the "Default switch" is none of those three. It behaves as explained in part 1.
– DRF
Dec 27 '18 at 18:17
That means that the "Default switch" actually performs NAT on things coming in from the outside. I don't (yet) know what that means for Host to Guest communication on this switch but it's (probably) not the same as the External switch where the Host OS will have an IP address in the same pool as the VM's and all of these will behave as if they are behind a switch which then is connected to the outside through the Physical Network card.
– DRF
Dec 27 '18 at 18:20
(Note I have actually already figured out where my issue was with the help of a friend. Specifically I messed up the VLAN's on the Host NIC. I put the Host OS into Vlan 2. Disabling "Vlan identification for management operating system" fixed my issue. And the VNIC in the Host OS now gets and IP address from the Mikrotik DHCP server without issues. So you're exactly right in your comment there was another level of blocking.
– DRF
Dec 27 '18 at 18:23
@DRF I re-read that statement and I also agree it was not correct so I purged that content from the answer. I also added some additional detail and resources that may be helpful with regard to the VLAN level stuff and the other levels of blocking such as OS level firewalls and such.
– Pimp Juice IT
Dec 27 '18 at 19:01
add a comment |
So you have . . .
The VM Mikrotik machine configured with two NIC's with one
connected to the "internal" Hyper-V switch (inside) that has the DHCP service running on it, and the other is connected to an "external" Hyper-V switch (outside), etc.The lUbuntu VM has one NIC and you connect that to the "internal" Hyper-V switch which has a DHCP server service listening on it from the Mikrotik machine to process requests accordingly.
Clarification Resources
1. Configuring VM Networking on a Hyper-V NAT Switch
Virtual machines that are connected to a NAT virtual switch are in an
isolated broadcast domain, a different one to the LAN. The NAT switch
does not have flat, 2-way routing to the LAN that the host is
connected to. The virtual switch is an internal virtual switch that
the host NATs to the LAN. This means that, by default, the virtual
machines can connect to the LAN, but the LAN cannot connect to the
virtual machines. And even if we do create NAT rules, the virtual
switch remains a separate broadcast domain from the LAN.
The virtual switch is somewhat isolated from the LAN, especially from broadcast-based services such as DHCP. You can deploy your own DHCP server(s) as virtual machines that are connected to the virtual switch. The scope of these servers is limited to the virtual switch, so there is no impact on the LAN, and network administrators should not have a problem with your DHCP servers being deployed on the NAT virtual switch.
Source
2. Internal Hyper-V switch configuration
Internal: Allows communication between virtual machines on the same Hyper-V server, and between the virtual machines and the
management host operating system.
Source
3. Visualization of all switch modes
Source
Potential Workarounds
The way I've handled this is to ensure the VMs connected to the internal switch have IP addresses assigned, and then from the host Hyper-V management server, I then can access those machines from the host OS that way via their IP addresses.
You could probably look over the Set up a NAT network, and be sure to have a full understanding of it and then Create a NAT virtual network and configure it accordingly to see if it'll do what you want using the "internal" Hyper-V switch functionality.
Since the VMs can talk with the Mikrotik machine, perhaps you can setup routing in it and then tell the VMs to use it's accessible internal Hyper-V switch IP address as the default gateway on all those devices, and just let it do the routing when things need accessed that's not connected to the internal Hyper-V switch.
Check your VLAN configuration and see Configure virtual local area networks for Hyper-V in the event something at this level is needed or causing trouble.
Configure and View VLAN Settings on Hyper-V Virtual Switch Ports
Check any OS level firewall rules for the blocking of the traffic coming from the internal Hyper-V switch to the host Hyper-V or any of the connected VMs.
answered Dec 27 '18 at 17:52
Pimp Juice ITPimp Juice IT
23.8k113972
So you have . . .
The VM Mikrotik machine configured with two NIC's with one
connected to the "internal" Hyper-V switch (inside) that has the DHCP service running on it, and the other is connected to an "external" Hyper-V switch (outside), etc.The lUbuntu VM has one NIC and you connect that to the "internal" Hyper-V switch which has a DHCP server service listening on it from the Mikrotik machine to process requests accordingly.
Clarification Resources
1. Configuring VM Networking on a Hyper-V NAT Switch
Virtual machines that are connected to a NAT virtual switch are in an
isolated broadcast domain, a different one to the LAN. The NAT switch
does not have flat, 2-way routing to the LAN that the host is
connected to. The virtual switch is an internal virtual switch that
the host NATs to the LAN. This means that, by default, the virtual
machines can connect to the LAN, but the LAN cannot connect to the
virtual machines. And even if we do create NAT rules, the virtual
switch remains a separate broadcast domain from the LAN.
The virtual switch is somewhat isolated from the LAN, especially from broadcast-based services such as DHCP. You can deploy your own DHCP server(s) as virtual machines that are connected to the virtual switch. The scope of these servers is limited to the virtual switch, so there is no impact on the LAN, and network administrators should not have a problem with your DHCP servers being deployed on the NAT virtual switch.
Source
2. Internal Hyper-V switch configuration
Internal: Allows communication between virtual machines on the same Hyper-V server, and between the virtual machines and the
management host operating system.
Source
3. Visualization of all switch modes
Source
Potential Workarounds
The way I've handled this is to ensure the VMs connected to the internal switch have IP addresses assigned, and then from the host Hyper-V management server, I then can access those machines from the host OS that way via their IP addresses.
You could probably look over the Set up a NAT network, and be sure to have a full understanding of it and then Create a NAT virtual network and configure it accordingly to see if it'll do what you want using the "internal" Hyper-V switch functionality.
Since the VMs can talk with the Mikrotik machine, perhaps you can setup routing in it and then tell the VMs to use it's accessible internal Hyper-V switch IP address as the default gateway on all those devices, and just let it do the routing when things need accessed that's not connected to the internal Hyper-V switch.
Check your VLAN configuration and see Configure virtual local area networks for Hyper-V in the event something at this level is needed or causing trouble.
Configure and View VLAN Settings on Hyper-V Virtual Switch Ports
Check any OS level firewall rules for the blocking of the traffic coming from the internal Hyper-V switch to the host Hyper-V or any of the connected VMs.
answered Dec 27 '18 at 17:52
Pimp Juice ITPimp Juice IT
23.8k113972
edited Dec 27 '18 at 19:00
answered Dec 27 '18 at 17:52
Pimp Juice ITPimp Juice IT
23.8k113972
answered Dec 27 '18 at 17:52
Pimp Juice ITPimp Juice IT
23.8k113972
answered Dec 27 '18 at 17:52
Pimp Juice ITPimp Juice IT
23.8k113972
23.8k113972
Hmm I think the conclusion is incorrect though the information is certainly interesting. Notice that the picture you provide shows the Internal switch being connected to a specific (virtual)NIC in the Host OS. This seems important especially in the case where you are running the Hyper-V on a Windows-10 machine (I believe that's called client Hyper-V?) in which case the first part of that picture is actually wrong. Or rather misleading since the "Default switch" is none of those three. It behaves as explained in part 1.
– DRF
Dec 27 '18 at 18:17
That means that the "Default switch" actually performs NAT on things coming in from the outside. I don't (yet) know what that means for Host to Guest communication on this switch but it's (probably) not the same as the External switch where the Host OS will have an IP address in the same pool as the VM's and all of these will behave as if they are behind a switch which then is connected to the outside through the Physical Network card.
– DRF
Dec 27 '18 at 18:20
(Note I have actually already figured out where my issue was with the help of a friend. Specifically I messed up the VLAN's on the Host NIC. I put the Host OS into Vlan 2. Disabling "Vlan identification for management operating system" fixed my issue. And the VNIC in the Host OS now gets and IP address from the Mikrotik DHCP server without issues. So you're exactly right in your comment there was another level of blocking.
– DRF
Dec 27 '18 at 18:23
@DRF I re-read that statement and I also agree it was not correct so I purged that content from the answer. I also added some additional detail and resources that may be helpful with regard to the VLAN level stuff and the other levels of blocking such as OS level firewalls and such.
– Pimp Juice IT
Dec 27 '18 at 19:01
add a comment |
Hmm I think the conclusion is incorrect though the information is certainly interesting. Notice that the picture you provide shows the Internal switch being connected to a specific (virtual)NIC in the Host OS. This seems important especially in the case where you are running the Hyper-V on a Windows-10 machine (I believe that's called client Hyper-V?) in which case the first part of that picture is actually wrong. Or rather misleading since the "Default switch" is none of those three. It behaves as explained in part 1.
– DRF
Dec 27 '18 at 18:17
That means that the "Default switch" actually performs NAT on things coming in from the outside. I don't (yet) know what that means for Host to Guest communication on this switch but it's (probably) not the same as the External switch where the Host OS will have an IP address in the same pool as the VM's and all of these will behave as if they are behind a switch which then is connected to the outside through the Physical Network card.
– DRF
Dec 27 '18 at 18:20
(Note I have actually already figured out where my issue was with the help of a friend. Specifically I messed up the VLAN's on the Host NIC. I put the Host OS into Vlan 2. Disabling "Vlan identification for management operating system" fixed my issue. And the VNIC in the Host OS now gets and IP address from the Mikrotik DHCP server without issues. So you're exactly right in your comment there was another level of blocking.
– DRF
Dec 27 '18 at 18:23
@DRF I re-read that statement and I also agree it was not correct so I purged that content from the answer. I also added some additional detail and resources that may be helpful with regard to the VLAN level stuff and the other levels of blocking such as OS level firewalls and such.
– Pimp Juice IT
Dec 27 '18 at 19:01
Hmm I think the conclusion is incorrect though the information is certainly interesting. Notice that the picture you provide shows the Internal switch being connected to a specific (virtual)NIC in the Host OS. This seems important especially in the case where you are running the Hyper-V on a Windows-10 machine (I believe that's called client Hyper-V?) in which case the first part of that picture is actually wrong. Or rather misleading since the "Default switch" is none of those three. It behaves as explained in part 1.
– DRF
Dec 27 '18 at 18:17
Hmm I think the conclusion is incorrect though the information is certainly interesting. Notice that the picture you provide shows the Internal switch being connected to a specific (virtual)NIC in the Host OS. This seems important especially in the case where you are running the Hyper-V on a Windows-10 machine (I believe that's called client Hyper-V?) in which case the first part of that picture is actually wrong. Or rather misleading since the "Default switch" is none of those three. It behaves as explained in part 1.
– DRF
Dec 27 '18 at 18:17
That means that the "Default switch" actually performs NAT on things coming in from the outside. I don't (yet) know what that means for Host to Guest communication on this switch but it's (probably) not the same as the External switch where the Host OS will have an IP address in the same pool as the VM's and all of these will behave as if they are behind a switch which then is connected to the outside through the Physical Network card.
– DRF
Dec 27 '18 at 18:20
That means that the "Default switch" actually performs NAT on things coming in from the outside. I don't (yet) know what that means for Host to Guest communication on this switch but it's (probably) not the same as the External switch where the Host OS will have an IP address in the same pool as the VM's and all of these will behave as if they are behind a switch which then is connected to the outside through the Physical Network card.
– DRF
Dec 27 '18 at 18:20
(Note I have actually already figured out where my issue was with the help of a friend. Specifically I messed up the VLAN's on the Host NIC. I put the Host OS into Vlan 2. Disabling "Vlan identification for management operating system" fixed my issue. And the VNIC in the Host OS now gets and IP address from the Mikrotik DHCP server without issues. So you're exactly right in your comment there was another level of blocking.
– DRF
Dec 27 '18 at 18:23
(Note I have actually already figured out where my issue was with the help of a friend. Specifically I messed up the VLAN's on the Host NIC. I put the Host OS into Vlan 2. Disabling "Vlan identification for management operating system" fixed my issue. And the VNIC in the Host OS now gets and IP address from the Mikrotik DHCP server without issues. So you're exactly right in your comment there was another level of blocking.
– DRF
Dec 27 '18 at 18:23
@DRF I re-read that statement and I also agree it was not correct so I purged that content from the answer. I also added some additional detail and resources that may be helpful with regard to the VLAN level stuff and the other levels of blocking such as OS level firewalls and such.
– Pimp Juice IT
Dec 27 '18 at 19:01
@DRF I re-read that statement and I also agree it was not correct so I purged that content from the answer. I also added some additional detail and resources that may be helpful with regard to the VLAN level stuff and the other levels of blocking such as OS level firewalls and such.
– Pimp Juice IT
Dec 27 '18 at 19:01
add a comment |
Thanks for contributing an answer to Super User!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fsuperuser.com%2fquestions%2f1387471%2fhyper-v-virtual-network-switch%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
You need something on the internal network providing IP addresses. Either static IPs on each client on this network, or a DHCP server.
– music2myear
Dec 24 '18 at 23:15
@music2myear As the question states I have a Mikrotik router which is setup as a DHCP-server on the VNIC that is bound to the internal VS.
– DRF
Dec 25 '18 at 7:58
Either it is not providing the correct service, or the other VMs aren't finding that service.
– music2myear
Dec 26 '18 at 2:21
@music2myear The VM's are finding the service just fine. The lUbuntu VM gets an IP address no problem. The issue is with the Host OS not the VM's.
– DRF
Dec 26 '18 at 9:46
One more question: If the purpose of the Internal switch is to allow communication between the VMs and to provide communication Lubuntu to the Mikrotik, why didn't you choose a Private switch? The Private switch allows communication only between the VMs on your host and so sounds like the correct switch for the job. An Internal switch generally acts as a bridge on your host, allowing VMs access to host resources, which is not what it sounds like you are trying to do with that particular switch.
– music2myear
Dec 26 '18 at 16:13