Setting network adapter metric priority in Windows 7 [closed] - windows

Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 9 years ago.
Improve this question
I'm having an issue on Windows 7 - if I have my Ethernet cable plugged in, Windows will default to using my WiFi network adapter. I would prefer that Windows default to my Ethernet connection. In order to resolve this, I have to manually disconnect the WiFi adapter in Control Panel's "Networking and Sharing Center", and then it will recognize my Ethernet connection.
Another weird thing is when I look at Control Panel\Network and Internet\Network Connections, my "TAP-Win32 Adapter OAS" is always disconnected. My Ethernet adapter is only noticed when I have it plugged in; and only then it shows up as a new adapter called "Realtek PCIe GBE Family Controller".
Note: Sorry I can't show screen captures because I'm one reputation point away from being able to show images.
I followed the steps in the articles How to Change the Priority of Wired/Wireless Network Cards in Windows and An explanation of the Automatic Metric feature for Internet Protocol routes
Here are my current metrics (network adapter priority):
C:\Users\Michael> netstat -rn
===========================================================================
Interface List
10...1c c1 de 98 1b 88 ......Realtek PCIe GBE Family Controller
16...00 ff fa d7 9e 94 ......TAP-Win32 Adapter OAS
13...00 26 82 c8 41 a7 ......Broadcom 43224AG 802.11a/b/g/draft-n Wi-Fi Adapter
12...70 f3 95 79 4f ec ......Bluetooth Device (Personal Area Network)
24...00 50 56 c0 00 08 ......VMware Virtual Ethernet Adapter for VMnet8
1...........................Software Loopback Interface 1
18...00 00 00 00 00 00 00 e0 Microsoft ISATAP Adapter
21...00 00 00 00 00 00 00 e0 Microsoft ISATAP Adapter #2
22...00 00 00 00 00 00 00 e0 Microsoft ISATAP Adapter #3
14...00 00 00 00 00 00 00 e0 Teredo Tunneling Pseudo-Interface
17...00 00 00 00 00 00 00 e0 Microsoft ISATAP Adapter #4
20...00 00 00 00 00 00 00 e0 Microsoft ISATAP Adapter #5
===========================================================================
IPv4 Route Table
===========================================================================
Active Routes:
Network Destination Netmask Gateway Interface Metric
0.0.0.0 0.0.0.0 192.168.1.1 192.168.1.103 28
0.0.0.0 0.0.0.0 192.168.1.1 192.168.1.101 24
127.0.0.0 255.0.0.0 On-link 127.0.0.1 306
127.0.0.1 255.255.255.255 On-link 127.0.0.1 306
127.255.255.255 255.255.255.255 On-link 127.0.0.1 306
192.168.1.0 255.255.255.0 On-link 192.168.1.103 270
192.168.1.0 255.255.255.0 On-link 192.168.1.101 268
192.168.1.101 255.255.255.255 On-link 192.168.1.101 268
192.168.1.103 255.255.255.255 On-link 192.168.1.103 270
192.168.1.255 255.255.255.255 On-link 192.168.1.103 270
192.168.1.255 255.255.255.255 On-link 192.168.1.101 268
192.168.116.0 255.255.255.0 On-link 192.168.116.1 276
192.168.116.1 255.255.255.255 On-link 192.168.116.1 276
192.168.116.255 255.255.255.255 On-link 192.168.116.1 276
224.0.0.0 240.0.0.0 On-link 127.0.0.1 306
224.0.0.0 240.0.0.0 On-link 192.168.1.101 268
224.0.0.0 240.0.0.0 On-link 192.168.116.1 276
224.0.0.0 240.0.0.0 On-link 192.168.1.103 270
255.255.255.255 255.255.255.255 On-link 127.0.0.1 306
255.255.255.255 255.255.255.255 On-link 192.168.1.101 268
255.255.255.255 255.255.255.255 On-link 192.168.116.1 276
255.255.255.255 255.255.255.255 On-link 192.168.1.103 270
===========================================================================
Although the "Realtek PCIe GBE Family Controller" has the higher priority metric, Windows still uses the WiFi connection by default. So to be explicit, I followed the instructions from the article; I unchecked the "automatic metric" assignment, and set it manually; only for the following adapters (on TCP/IPv4):
10: TAP-Win32 Adapter OAS
12: Realtek PCIe GBE Family Controller
14: Broadcom 43224AG 802.11a/b/g/draft-n Wi-Fi Adapter
16: Bluetooth Device (Personal Area Network)
I then rebooted, and unfortunately, these settings were not picked up. Running the "netstat -rn" displays the same interface list priority as shown above, and again Windows used the WiFi adapter by default.
If anyone has run into the same issues and resolved them, please let me know. The fact that Windows 7 does not prioritize an Ethernet connection over a WiFi connection baffles me, and its annoying to have to finagle around with it every time I boot up.
If you also understand the behavior for the two adapters "Realtek PCIe GBE Family Controller" and "TAP-Win32 Adapter OAS", that would be helpful as well.

Windows has two different settings in which priority is established. There is the metric value which you have already set in the adapter settings, and then there is the connection priority in the network connections settings.
To change the priority of the connections:
Open your Adapter Settings (Control Panel\Network and Internet\Network Connections)
Click Alt to pull up the menu bar
Select Advanced -> Advanced Settings
Change the order of the connections so that the connection you want to have priority is top on the list

I had the same problem on Windows 7 64-bit Pro. I adjusted network adapters binding using Control panel but nothing changed. Also metrics where showing that Win should use Ethernet adapter as primary, but it didn't.
Then a tried to uninstall Ethernet adapter driver and then install it again (without restart) and then I checked metrics for sure.
After this, Windows started prioritize Ethernet adapter.

Related

Why does multicast sockets work as intended on system with two network interfaces?

I am working on the SW of a test equipment. This system includes a PC (running Windows 10) and multiple Raspberry Pi units (and a bunch of equipment not relevant for this question). The PC has two physical network adapters:
NIC1 (identified by 192.168.0.122 in routing table below)
NIC2 (identified by 192.168.130.25 in routing table below)
NIC1 is connected to a switch connecting all network nodes inside the rack containing the test equipment. Thus, it is an internal network not connected to the outside world. There is a multicast based protocol in use to communicate between the PC and the various Raspberry Pi units.
NIC2 is the public interface to the test equipment. Its purpose is to enable automation of the test equipment. There is a TCP server running on the PC waiting for connections on NIC2 using a domain specific protocol. NIC2 is connected to a laboratory subnet, physically separated from the internal network on NIC1.
The test equipment works fine. But recently I realized I had forgotten to bind the sockets for the multicast based protocol to NIC1 on the PC. For some reason the system have worked fine anyway - even though I have shut it down and restarted it many, many times. It is not a coincidence, it is definitely a deterministic behaviour.
This is how the routing table looks like on the PC:
===========================================================================
Active Routes:
Network Destination Netmask Gateway Interface Metric
0.0.0.0 0.0.0.0 192.168.0.1 192.168.0.122 25
0.0.0.0 0.0.0.0 192.168.130.254 192.168.130.25 25
127.0.0.0 255.0.0.0 On-link 127.0.0.1 331
127.0.0.1 255.255.255.255 On-link 127.0.0.1 331
127.255.255.255 255.255.255.255 On-link 127.0.0.1 331
192.168.0.0 255.255.255.0 On-link 192.168.0.122 281
192.168.0.122 255.255.255.255 On-link 192.168.0.122 281
192.168.0.255 255.255.255.255 On-link 192.168.0.122 281
192.168.130.0 255.255.255.0 On-link 192.168.130.25 281
192.168.130.25 255.255.255.255 On-link 192.168.130.25 281
192.168.130.255 255.255.255.255 On-link 192.168.130.25 281
224.0.0.0 240.0.0.0 On-link 127.0.0.1 331
224.0.0.0 240.0.0.0 On-link 192.168.0.122 281
224.0.0.0 240.0.0.0 On-link 192.168.130.25 281
255.255.255.255 255.255.255.255 On-link 127.0.0.1 331
255.255.255.255 255.255.255.255 On-link 192.168.0.122 281
255.255.255.255 255.255.255.255 On-link 192.168.130.25 281
===========================================================================
For example: there is one socket on the PC joining the multicast group 239.255.4.0:90. According to the routing table both NICs have the same network destinations and netmasks for multicast routes (as expected), but also the same metric. A lower metric value for NIC1 would have explained the behaviour. With equal metrics I would have expected a more random behaviour.
My main question is: How come the multicast sockets always select the NIC1 adapter on the PC?
(Just for the protocol: I have now bound the multicast sockets on the PC to NIC1. There is no difference, the system still works fine. I feel a bit more confident, though. But since this is the first time I am working with multiple network adapters I am still a bit worried that I have misunderstood something.)

Kubernetes service on windows node not reachable

I'm currently working on a mixed Linux/Windows Kubernetes cluster.
It's currently 4 nodes, running as VMs in a VMWare cluster on a single physical server:
3 Linux nodes running on debian stretch and configured using kubeadm
1 Windows Server 2019 (1809) node configured based on Microsoft's documentation.
I'm using flannel in host-gw mode for the networking as suggested by Microsoft.
IPs are properly assigned to both pods and services in their respective ranges (10.244.0.0/16 for pods and 10.96.0.0/12 for services).
The whole thing is running with Kubernetes 1.13. upgraded from 1.12.3 and the flannel binaries freshly downloaded today as well from Microsoft/SDN.
The Windows Powershell command to start the services:
.\start.ps1 -ManagementIP 10.71.145.37 -ClusterCIDR 10.244.0.0/16 -ServiceCIDR 10.96.0.0/12 -KubeDnsServiceIP 10.96.0.10
What's working?
Linux pod -> Linux pod: yes
Linux pod -> Windows pod: yes
Windows pod -> Linux pod: yes
Windows pod -> Windows pod: yes
Linux pod -> Linux service: yes
Linux pod -> Windows service: no
Windows pod -> Linux service: no
Windows pod -> Windows service: no
Linux host -> Linux pod: yes
Linux host -> Windows pod: yes
Windows host -> Linux pod: yes
Windows host -> Windows pod: yes
Linux host -> Linux service: yes
Linux host -> Windows service: no
Windows host -> Linux service: no
Windows host -> Windows service: no
Long story short: Direct connections to pods work across Windows and Linux, service connections only work for Linux services (services backed by Linux pods) and only from Linux pods or hosts.
DNS resolution is also working, although I cannot resolve service.namespace on Windows pods, just hostname or FQDN work, nothing in between.
Routing tables from the Linux nodes:
# host linux-node-1: 10.71.144.71
root#linux-node-1:~# route
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
default 10.71.144.1 0.0.0.0 UG 0 0 0 ens32
10.71.144.0 0.0.0.0 255.255.252.0 U 0 0 0 ens32
10.244.0.0 0.0.0.0 255.255.255.0 U 0 0 0 cni0
10.244.1.0 linux-node-2 255.255.255.0 UG 0 0 0 ens32
10.244.2.0 linux-node-3 255.255.255.0 UG 0 0 0 ens32
10.244.5.0 windows-node-1 255.255.255.0 UG 0 0 0 ens32
172.17.0.0 0.0.0.0 255.255.0.0 U 0 0 0 docker0
# host linux-node-2: 10.71.147.15
root#linux-node-2:~# route
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
default 10.71.144.1 0.0.0.0 UG 0 0 0 ens32
10.71.144.0 0.0.0.0 255.255.252.0 U 0 0 0 ens32
10.244.0.0 linux-node-1 255.255.255.0 UG 0 0 0 ens32
10.244.1.0 0.0.0.0 255.255.255.0 U 0 0 0 cni0
10.244.2.0 linux-node-3 255.255.255.0 UG 0 0 0 ens32
10.244.5.0 windows-node-1 255.255.255.0 UG 0 0 0 ens32
172.17.0.0 0.0.0.0 255.255.0.0 U 0 0 0 docker0
# host linux-node-3: 10.71.144.123
root#linux-node-3:~# route
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
default 10.71.144.1 0.0.0.0 UG 0 0 0 ens32
10.71.144.0 0.0.0.0 255.255.252.0 U 0 0 0 ens32
10.244.0.0 linux-node-1 255.255.255.0 UG 0 0 0 ens32
10.244.1.0 linux-node-2 255.255.255.0 UG 0 0 0 ens32
10.244.2.0 0.0.0.0 255.255.255.0 U 0 0 0 cni0
10.244.5.0 windows-node-1 255.255.255.0 UG 0 0 0 ens32
172.17.0.0 0.0.0.0 255.255.0.0 U 0 0 0 docker0
Routing table from the Windows node:
PS C:\k> route print
===========================================================================
Interface List
9...00 50 56 89 69 ce ......Hyper-V Virtual Ethernet Adapter #2
21...00 15 5d 8d 98 26 ......Hyper-V Virtual Ethernet Adapter #3
1...........................Software Loopback Interface 1
12...00 15 5d 84 c0 c9 ......Hyper-V Virtual Ethernet Adapter
===========================================================================
IPv4 Route Table
===========================================================================
Active Routes:
Network Destination Netmask Gateway Interface Metric
0.0.0.0 0.0.0.0 10.71.144.1 10.71.145.37 25
0.0.0.0 0.0.0.0 10.244.5.1 10.244.5.2 281
10.71.144.0 255.255.252.0 On-link 10.71.145.37 281
10.71.145.37 255.255.255.255 On-link 10.71.145.37 281
10.71.145.37 255.255.255.255 10.71.144.1 10.71.145.37 125
10.71.147.255 255.255.255.255 On-link 10.71.145.37 281
10.244.0.0 255.255.255.0 10.71.144.71 10.71.145.37 281
10.244.1.0 255.255.255.0 10.71.147.15 10.71.145.37 281
10.244.2.0 255.255.255.0 10.71.144.123 10.71.145.37 281
10.244.5.0 255.255.255.0 On-link 10.244.5.2 281
10.244.5.2 255.255.255.255 On-link 10.244.5.2 281
10.244.5.255 255.255.255.255 On-link 10.244.5.2 281
127.0.0.0 255.0.0.0 On-link 127.0.0.1 331
127.0.0.1 255.255.255.255 On-link 127.0.0.1 331
127.255.255.255 255.255.255.255 On-link 127.0.0.1 331
172.27.80.0 255.255.240.0 On-link 172.27.80.1 5256
172.27.80.1 255.255.255.255 On-link 172.27.80.1 5256
172.27.95.255 255.255.255.255 On-link 172.27.80.1 5256
224.0.0.0 240.0.0.0 On-link 127.0.0.1 331
224.0.0.0 240.0.0.0 On-link 172.27.80.1 5256
224.0.0.0 240.0.0.0 On-link 10.71.145.37 281
224.0.0.0 240.0.0.0 On-link 10.244.5.2 281
255.255.255.255 255.255.255.255 On-link 127.0.0.1 331
255.255.255.255 255.255.255.255 On-link 172.27.80.1 5256
255.255.255.255 255.255.255.255 On-link 10.71.145.37 281
255.255.255.255 255.255.255.255 On-link 10.244.5.2 281
===========================================================================
Persistent Routes:
Network Address Netmask Gateway Address Metric
0.0.0.0 0.0.0.0 10.244.5.1 Default
10.244.0.0 255.255.255.0 10.71.144.71 Default
10.244.1.0 255.255.255.0 10.71.147.15 Default
10.244.2.0 255.255.255.0 10.71.144.123 Default
0.0.0.0 0.0.0.0 10.244.5.2 Default
10.71.145.37 255.255.255.255 10.71.144.1 100
===========================================================================
Traceroute from the Windows pod to kube-dns:
C:\>tracert -4 -d -h 10 10.96.0.10
Tracing route to 10.96.0.10 over a maximum of 10 hops
2
1 * * * Request timed out.
2 * * * Request timed out.
3 * * * Request timed out.
4 * * * Request timed out.
5 * * * Request timed out.
6 * * * Request timed out.
7 * * * Request timed out.
8 * * * Request timed out.
9 * * * Request timed out.
10 * * * Request timed out.
Trace complete.
Traceroute from a Linux pod to kube-dns:
root#deb:/# traceroute -4 -n 10.96.0.10
traceroute to 10.96.0.10 (10.96.0.10), 30 hops max, 60 byte packets
1 10.244.2.1 0.396 ms 0.336 ms 0.314 ms
2 10.71.144.1 7.044 ms 9.939 ms 10.062 ms
3 10.71.144.2 1.727 ms 1.917 ms 10.71.144.3 1.233 ms
4 10.68.132.166 6.985 ms 10.68.132.162 7.934 ms 8.404 ms
5 10.103.4.246 203.807 ms 203.405 ms 203.777 ms
6 10.103.4.245 209.431 ms 209.348 ms 209.772 ms
7 10.96.108.86 496.457 ms 502.957 ms 494.978 ms
8 10.96.0.10 211.666 ms * *
Hop 1 is pod network address, hops 2 and 3 are the standard gateway (VRRP) of the Linux host, hop 7 is a switch in the physical network, hop 8 is the kube-dns service, the rest the hops (4-6) are probably Cisco routers in the physical network.
The fact that DNS queries are working and I can ping 10.96.0.1 (kubernetes services) and 10.96.0.10 (kube-dns) from the host lets me believe the routing is working, but I can't ping any other service address nor can I e.g. curl my ingress controller from the windows host.
Disabling the Windows firewall did not make a difference either.
I'm out of ideas on what else I can check here and googling around barely brings anything applicable.
Regarding Windows services failing:
Can you post CollectLogs.ps1 output (https://raw.githubusercontent.com/Microsoft/SDN/master/Kubernetes/windows/debug/collectlogs.ps1) and your CNI config file?
Can the Windows pods reach the external internet (e.g. curl -useb http://google.com?)
Also, there is a video recently presented at KubeCon that goes into detail on how to troubleshoot Kubernetes networking problems on Windows that you may find helpful: https://www.youtube.com/watch?v=tTZFoiLObX4&feature=youtu.be
Regarding resolution of service.namespace, unfortunately that is a difference in behavior today by design of the DNS resolver on Windows, whereby any name searches containing dots are treated authoritatively. This is also why the default CNI config file doesn't have the needed DNS suffices specified in the SearchList that isn't working today. This behavior won't change earlier than Windows Server, version 1903 release.

UDP packet sent to a multicast destination is sent via the loopback interface

I'm running Windows 10.
I had recently diagnosed an issue with my computer where any packet sent to a multicast destination is sent through the loopback interface rather than the 'default' one (see my adventures here).
Example code:
import socket
s = socket.socket(socket.AF_INET, socket.SOCK_DGRAM)
s.sendto(b"herpyderp", ('224.0.0.251', 5353))
The packet is seen on the loopback interface only (used Microsoft Message Analyzer to sniff).
I tried inspecting the routing table via route print, and got the following output:
IPv4 Route Table
===========================================================================
Active Routes:
Network Destination Netmask Gateway Interface Metric
0.0.0.0 0.0.0.0 10.0.10.138 10.0.10.30 35
10.0.10.0 255.255.255.0 On-link 10.0.10.30 291
10.0.10.30 255.255.255.255 On-link 10.0.10.30 291
10.0.10.255 255.255.255.255 On-link 10.0.10.30 291
127.0.0.0 255.0.0.0 On-link 127.0.0.1 331
127.0.0.1 255.255.255.255 On-link 127.0.0.1 331
127.255.255.255 255.255.255.255 On-link 127.0.0.1 331
224.0.0.0 240.0.0.0 On-link 127.0.0.1 331
224.0.0.0 240.0.0.0 On-link 10.0.10.30 291
255.255.255.255 255.255.255.255 On-link 127.0.0.1 331
255.255.255.255 255.255.255.255 On-link 10.0.10.30 291
===========================================================================
You'll note the metric indicates the packet should be sent through my 'default' interface.
I then tried inspecting the interface metric via the PowerShell Get-NetIPInterface cmdlet (as implied here), and got the following output:
ifIndex InterfaceAlias AddressFamily NlMtu(Bytes) InterfaceMetric Dhcp ConnectionState PolicyStore
------- -------------- ------------- ------------ --------------- ---- --------------- -----------
2 Ethernet 3 IPv6 1500 35 Enabled Connected ActiveStore
7 Ethernet IPv6 1500 5 Enabled Disconnected ActiveStore
1 Loopback Pseudo-Interface 1 IPv6 4294967295 75 Disabled Connected ActiveStore
3 isatap.home IPv6 1280 75 Disabled Disconnected ActiveStore
17 Teredo Tunneling Pseudo-Inte... IPv6 1280 75 Enabled Connected ActiveStore
2 Ethernet 3 IPv4 1500 35 Enabled Connected ActiveStore
7 Ethernet IPv4 1500 5 Enabled Disconnected ActiveStore
1 Loopback Pseudo-Interface 1 IPv4 4294967295 75 Disabled Connected ActiveStore
You'll note the InterfaceMetric field also seems to indicate my packet should be sent through the 'default' interface rather than through the loopback interface.
Forcing the socket to send the packet through a different interface via s.setsockopt(socket.IP_MULTICAST_IF, ...) works, but I shouldn't need to do that.
You'll note that there are two Ethernet interfaces corresponding to two network cards on my motherboard. When I connected the cable to Ethernet instead of Ethernet 3, the code above started behaving as I expected and the packet was sent through that interface rather than through the loopback interface.
What is going on?
On my Win10 PC there is a rule in the firewall: UDP port 5353 (mDNS) is allowed to be used by svchost.exe only. This basically means only some Windows services can use mDNS. You may want to check your own firewall and modify that rule - if you have it.
I'm using C++ rather than python, but this helped:
flag = 0;
setsockopt(this->socket, IPPROTO_IP, IP_MULTICAST_LOOP, (char*) & flag,sizeof(flag))
Disableing IP_MULTICAST_LOOP helped!

Creating a virtual switch for Hyper-v stops host from receiving udp multicast

Basically my issue is that I am unable to receive multicast udp packets (streaming video) once I have created an external virtual switch via the Hyper-V manager which is required to provide the guest OS full networking.
If I use VLC and play an RTSP url on my host without a virtual switch then it plays without any issues, once I add the virtual switch I am no longer able to play the multicast RTSP url.
Back Story
I have created a couple docker services to run in an Ubuntu 16.04 VM environment on my Windows 10 Pro host via Hyper-v. My docker service needs to be able to receive multicast udp packets which I have successfully done using VirtualBox... but I want to use Hyper-v. Once I solve why my host isn't able to receive multicast then I'll move along and test to make sure my container is able to as well.
Info
When executing this show joins command while attempting to stream the multicast RTSP url then the 239.168.1.75 address on the virtual switch increases its reference count properly, then after VLC is closed, the reference count goes back down, so it looks like it's joining/leaving the group correctly.
netsh interface ip show joins
Interface 1: Loopback Pseudo-Interface 1
Scope References Last Address
---------- ---------- ---- ---------------------------------
0 0 Yes 224.0.0.251
0 4 Yes 239.255.255.250
Interface 28: vEthernet (New Virtual Switch)
Scope References Last Address
---------- ---------- ---- ---------------------------------
0 0 Yes 224.0.0.1
0 3 Yes 224.0.0.251
0 1 Yes 224.0.0.252
0 0 Yes 239.168.1.75
0 4 Yes 239.255.255.250
Interface 15: Local Area Connection* 5
Scope References Last Address
---------- ---------- ---- ---------------------------------
0 0 Yes 224.0.0.1
route print
===========================================================================
Interface List
15...00 ff 10 60 55 c4 ......Juniper Network Connect Virtual Adapter
28...9c eb e8 35 1a 1e ......Hyper-V Virtual Ethernet Adapter
1...........................Software Loopback Interface 1
===========================================================================
IPv4 Route Table
===========================================================================
Active Routes:
Network Destination Netmask Gateway Interface Metric
0.0.0.0 0.0.0.0 192.168.1.1 192.168.1.138 25
127.0.0.0 255.0.0.0 On-link 127.0.0.1 331
127.0.0.1 255.255.255.255 On-link 127.0.0.1 331
127.255.255.255 255.255.255.255 On-link 127.0.0.1 331
192.168.1.0 255.255.255.0 On-link 192.168.1.138 281
192.168.1.138 255.255.255.255 On-link 192.168.1.138 281
192.168.1.255 255.255.255.255 On-link 192.168.1.138 281
224.0.0.0 240.0.0.0 On-link 127.0.0.1 331
224.0.0.0 240.0.0.0 On-link 192.168.1.138 281
255.255.255.255 255.255.255.255 On-link 127.0.0.1 331
255.255.255.255 255.255.255.255 On-link 192.168.1.138 281
===========================================================================
Persistent Routes:
None
Igmpquery (https://code.google.com/archive/p/igmpquery)
When using this tool I am able to query the network and get responses when the virtual switch is removed, but once it's added again, it fails.
With Virtual Switch
IGMP query generator V1.4
Project web site: http://code.google.com/p/igmpquery/
Requires WinPcap
\Device\NPF_{807EAC56-4C04-424D-9DDE-4411FB900E3C}
Description: Juniper Network Connect Virtual Adapter
Address Family Name: AF_INET
Address: 0.0.0.0
Netmask: 255.0.0.0
Broadcast Address: 0.0.0.0
IGMPv2 general query 0.0.0.0 -> 224.0.0.1
listening for responses ...
\Device\NPF_{27895664-EDF7-44E0-9753-E549EDCAD6E7}
Description: Realtek USB NIC
No Virtual Switch
IGMP query generator V1.4
Project web site: http://code.google.com/p/igmpquery/
Requires WinPcap
\Device\NPF_{807EAC56-4C04-424D-9DDE-4411FB900E3C}
Description: Juniper Network Connect Virtual Adapter
Address Family Name: AF_INET
Address: 0.0.0.0
Netmask: 255.0.0.0
Broadcast Address: 0.0.0.0
IGMPv2 general query 0.0.0.0 -> 224.0.0.1
listening for responses ...
\Device\NPF_{27895664-EDF7-44E0-9753-E549EDCAD6E7}
Description: Realtek USB NIC
Address Family Name: AF_INET
Address: 192.168.1.138
Netmask: 255.255.255.0
Broadcast Address: 0.0.0.0
IGMPv2 general query 192.168.1.138 -> 224.0.0.1
listening for responses ...
15:44:06.551 192.168.1.85 -> 224.0.0.252 IGMP Rpt 224.0.0.252
15:44:06.593 192.168.1.71 -> 224.0.0.251 IGMP Rpt 224.0.0.251
15:44:06.624 192.168.1.79 -> 224.0.0.252 IGMP Rpt 224.0.0.252
15:44:06.828 192.168.1.89 ->239.255.255.250 IGMP Rpt 239.255.255.250
I'm not 100% sure what the magic bullet was although it's now working.
Remove the virtual switch
Reset network settings
netsh winsock reset
netsh int ip reset
ipconfig /release
ipconfig /renew
ipconfig /flushdns
netsh advfirewall set allprofiles state off
Reboot
Add virtual switch
Reboot
Now when running the igmp tool I was getting responses from my own PC from within the virtual switch but no other devices on my main network
Uninstalled VirtualBox
Seemingly no help
Get frustrated, go to sleep
Once I woke up the next day and ran the igmp tool I started receiving replies from devices on my main network outside the virtual switch
Tested streaming multicast and everything worked great

Add route from single ip to localhost. OSX Mavericks

on my MacbookPro 15'' Retina, with OSX 10.9.4, I want to be able to:
route all single ip traffic to localhost.
My Goal is this:
I type http://192.168.1.54/test.html in the browser and I get what I normally get from
http://localhost/test.html
This is what I tried (en4 is the one I get internet connection from):
______$ sudo route add 192.168.1.54 localhost -ifp en4
checking the list
______$ sudo route add 192.168.1.54 localhost -ifp en4
add host 192.168.1.54: gateway localhost
______$ netstat -rn
Routing tables
Internet:
Destination Gateway Flags Refs Use Netif Expire
default 192.168.1.1 UGSc 42 4 en4
127 127.0.0.1 UCS 0 3 lo0
127.0.0.1 127.0.0.1 UH 50 15380 lo0
...
192.168.1.54 127.0.0.1 UGHS 0 0 en4
...
But the ping of 192.168.1.54 isn't working
I tried also the loopback interface with
______$ sudo route add 192.168.1.54 localhost -ifp lo0
getting the same result: nothing.
I'm kind of a newbie in this stuff, so any help will be great
Fire up your Terminal and type the following:
sudo ifconfig lo0 alias 192.168.66.66
After entering your password, that will redirect requests for 192.168.66.66 to the localhost/loopback adapter.
And if you need to remove this redirect, try
sudo ifconfig lo0 -alias 192.168.66.66
Source: http://www.vincecutting.co.uk/web-development/redirect-ip-address-back-to-localhost-on-mac-osx/
You'll need to create a mac virtual interface pointing to 192.168.1.54. Otherwise there is no one to reach at 192.168.1.54 and hence why your ping is failing.
In linux it's pretty straight forward to create additional virtual interfaces.
On my mac osx machine I was able to go into Systems Preferences --> Network
then hit the + sign to add an additional interfaces.
I picked Ethernet as my interface type and assigned the address of 192.168.1.54, 255.255.255.0 subnet mask and 192.168.1.1 as the default router.
Now both my primary 192.168.1.10 and my virtual 192.168.1.54 interfaces are up and pingable.
en0: flags=8863<UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST> mtu 1500
options=10b<RXCSUM,TXCSUM,VLAN_HWTAGGING,AV>
ether 0c:4d:e9:9a:1c:a3
inet6 fe80::e4d:e9ff:e936:1ca3%en0 prefixlen 64 scopeid 0x4
inet 192.168.1.10 netmask 0xffffff00 broadcast 192.168.1.255
inet 192.168.1.54 netmask 0xffffff00 broadcast 192.168.1.255
nd6 options=1<PERFORMNUD>
media: autoselect (100baseTX <full-duplex>)
status: active
My-Book-Pro:~ root# ping 192.168.1.10
PING 192.168.1.10 (192.168.1.10): 56 data bytes
64 bytes from 192.168.1.10: icmp_seq=0 ttl=64 time=0.095 ms
64 bytes from 192.168.1.10: icmp_seq=1 ttl=64 time=0.101 ms
My-MacBook-Pro:~ root# ping 192.168.1.54
PING 192.168.1.54 (192.168.1.54): 56 data bytes
64 bytes from 192.168.1.54: icmp_seq=0 ttl=64 time=0.085 ms
64 bytes from 192.168.1.54: icmp_seq=1 ttl=64 time=0.091 ms

Resources