X86-64 19.07.4 Hyper-V issues

ssdnvv · November 2, 2020, 10:38pm

Hello there,

I am at my wit's end concerning the following issue:

Working environment:

Hypervisor: Hyper-V/Windows 10 Pro x64
Virtual Switch #1: Intel 82599 --> 10GBE-switch1 (192.168.1.3) <-- AP (192.168.1.2 lan, 192.168.2.2 iot, 192.168.5.2 guest); 1GBE-switch1 (192.168.1.5); 10GBE-switch2 (192.168.1.4)
Virtual Switch #2: Intel I211 <-- modem
guest1: OpenWrt 19.07.4 x86-64 (192.168.1.1 lan, 192.168.2.1 iot, 192.168.5.1 gast), DHCP+DNS-server for gast
- virtual NIC#1: Virtual Switch#1, tagged VLAN-ID 1
- virtual NIC#2: Virtual Switch#2
- virtual NIC#3: Virtual Switch#1, tagged VLAN-ID 2
- virtual NIC#4: Virtual Switch#1, tagged VLAN-ID 5
guest2: Ubuntu/pihole (192.168.1.12 lan, 192.168.2.12 gast), DHCP+DNS-server for lan+iot
- virtual NIC#1: Virtual Switch#1, tagged VLAN-ID 1
- virtual NIC#2: Virtual Switch#1, tagged VLAN-ID 2
Interfaces in OpenWrt:
- eth0 (lan)
- eth1 (wan)
- eth2 (iot)
- eth3 (guest)

In order to get rid of the 10GBE-switch1 and reduce my power consumption, I installed a Intel I340-T4 which I already had installed beforehand and working (but took it away because of some testing reasons). The card is recognized on hypervisor-level and I can blink the lights of every ethernet-port.

Virtual Switch #2#1: Intel I340-T4
Virtual Switch #2#2: Intel I340-T4#2

So I created for guest1 the additional interfaces

virtual NIC#5: Virtual Switch#2#1, tagged VLAN-ID 1
virtual NIC#6: Virtual Switch#2#1, tagged VLAN-ID 2
virtual NIC#7: Virtual Switch#2#1, tagged VLAN-ID 5
virtual NIC#8: Virtual Switch#2#2, tagged VLAN-ID 1
virtual NIC#9: Virtual Switch#2#2, tagged VLAN-ID 2
virtual NIC#10: Virtual Switch#2#2, tagged VLAN-ID 5

, added the following in /etc/init.d/network

eth4 (lan)
eth5 (iot)
eth6 (guest)
eth7 (lan)
eth8 (iot)
eth9 (guest)

and (after restarting network/the hypervisor) finally connected the cabling of 10GBE-switch2/1GBE-switch1/AP directly to 82599/I340-T4/I340-T4#2. The physical adapters' lights light up, cables are recognized on hypervisor-level and the connection on the 82599 works just like before. But the connections on the I340-T4/I340-T4#2 do not work.
Looking into OpenWrt

root@Router:~# ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq master br-lan state UP group default qlen 1000
    link/ether 00:01:00:00:00:00 brd ff:ff:ff:ff:ff:ff
3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc cake state UP group default qlen 1000
    link/ether 00:01:00:00:00:01 brd ff:ff:ff:ff:ff:ff
    inet 192.168.7.2/24 brd 192.168.7.255 scope global eth1
       valid_lft forever preferred_lft forever
    inet6 <IPv6-adress> scope link
       valid_lft forever preferred_lft forever
4: eth2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq master br-iot state UP group default qlen 1000
    link/ether 00:01:00:00:00:02 brd ff:ff:ff:ff:ff:ff
5: eth3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq master br-gast state UP group default qlen 1000
    link/ether 00:01:00:00:00:03 brd ff:ff:ff:ff:ff:ff
6: eth4: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq master br-lan state UP group default qlen 1000
    link/ether 00:01:00:00:00:04 brd ff:ff:ff:ff:ff:ff
7: eth5: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc mq master br-iot state DOWN group default qlen 1000
    link/ether 00:01:00:00:00:05 brd ff:ff:ff:ff:ff:ff
8: eth6: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc mq master br-gast state DOWN group default qlen 1000
    link/ether 00:01:00:00:00:06 brd ff:ff:ff:ff:ff:ff
9: eth7: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc mq master br-lan state DOWN group default qlen 1000
    link/ether 00:01:00:00:00:07 brd ff:ff:ff:ff:ff:ff
10: eth8: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc mq master br-iot state DOWN group default qlen 1000
    link/ether 00:01:00:00:00:08 brd ff:ff:ff:ff:ff:ff
11: eth9: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc mq master br-gast state DOWN group default qlen 1000
    link/ether 00:01:00:00:00:09 brd ff:ff:ff:ff:ff:ff
12: ifb0: <BROADCAST,NOARP> mtu 1500 qdisc noop state DOWN group default qlen 32
    link/ether 86:4c:51:c8:5b:e2 brd ff:ff:ff:ff:ff:ff
13: ifb1: <BROADCAST,NOARP> mtu 1500 qdisc noop state DOWN group default qlen 32
    link/ether 5a:3a:ce:ec:8f:70 brd ff:ff:ff:ff:ff:ff
31: br-gast: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether 00:01:00:00:00:03 brd ff:ff:ff:ff:ff:ff
    inet 192.168.5.1/24 brd 192.168.5.255 scope global br-gast
       valid_lft forever preferred_lft forever
32: br-iot: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether 00:01:00:00:00:02 brd ff:ff:ff:ff:ff:ff
    inet 192.168.2.1/24 brd 192.168.2.255 scope global br-iot
       valid_lft forever preferred_lft forever
33: br-lan: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether 00:01:00:00:00:00 brd ff:ff:ff:ff:ff:ff
    inet 192.168.1.1/24 brd 192.168.1.255 scope global br-lan
       valid_lft forever preferred_lft forever
34: wg0: <POINTOPOINT,NOARP> mtu 1420 qdisc noop state DOWN group default qlen 1000
    link/none
37: ifb4eth1: <BROADCAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc cake state UNKNOWN group default qlen 32
    link/ether de:3a:5a:50:28:c4 brd ff:ff:ff:ff:ff:ff

the interfaces are obviously recognized, and luci shows for each interface traffic for RX/TX. But neither AP nor 1GBE-switch1 can be reached.
Hopefully someone can help and give a hint where/what to search for...

Best,
ssdnvv

ssdnvv · November 4, 2020, 6:14pm

Can someone help?

lleachii · November 4, 2020, 6:20pm

So you're saying the original interfaces you configured work; but the new ones do not?

ssdnvv · November 4, 2020, 6:43pm

Correct, yes.
A Windows-PC shows unknown network, when directly connected.

lleachii · November 7, 2020, 3:02am

What does Wireshark show?

ssdnvv · November 18, 2020, 3:47pm

I reset the hypervisor's network settings for the two NICs (I340T4 & I340T4#2) and now I can reach AP and 1GBE-switch1 from Hypervisor (ping/webinterfaces). A client connected to 1GBE-switch can play media-files provided by the hypervisor's DLNA-server. So the NIC itself works.
Still I cannot reach AP/1GBE-switch from guest1/OpenWrt or any other client connected to guest1/OpenWrt.

To reduce complexity I reduced the additional connected virtual NICs to virtual NIC#5 (I340T4)/eth4 (lan).
When listening on the connection guest1/OpenWrt <--> 1GBE-switch, Wireshark only shows me one single package which origines from 1GBE-switch reoccuring periodically, no packages coming from guest1.

Within guest1/OpenWrt syslog/kernel log shows for the drivers

Wed Nov 18 17:01:00 2020 kern.info kernel: [   10.157198] e1000: Intel(R) PRO/1000 Network Driver - version 7.3.21-k8-NAPI
Wed Nov 18 17:01:00 2020 kern.info kernel: [   10.213562] e1000: Copyright (c) 1999-2006 Intel Corporation.
Wed Nov 18 17:01:00 2020 kern.info kernel: [   10.270621] igb: Intel(R) Gigabit Ethernet Network Driver - version 5.4.0-k
Wed Nov 18 17:01:00 2020 kern.info kernel: [   10.324955] igb: Copyright (c) 2007-2014 Intel Corporation.
Wed Nov 18 17:01:00 2020 kern.info kernel: [   10.938707] e1000e: Copyright(c) 1999 - 2015 Intel Corporation.
Wed Nov 18 17:01:00 2020 kern.info kernel: [   10.991955] ip_tables: (C) 2000-2006 Netfilter Core Team

and for the interface eth4

[   13.441212] br-lan: port 2(eth4) entered blocking state
[   13.488324] br-lan: port 2(eth4) entered disabled state
[   13.535272] device eth4 entered promiscuous mode
Wed Nov 18 16:42:32 2020 daemon.notice netifd: Network device 'eth4' link is up
[   13.811313] br-lan: port 2(eth4) entered blocking state
[   13.857435] br-lan: port 2(eth4) entered forwarding state

Luci shows there are packages sent from eth4 link
grafik
even though those packages never leave the physical adapter (otherwise they would be shown in Wireshark, right?).

Any ideas?

lleachii · November 18, 2020, 7:54pm

You should be seeing packets if you connected them to a real interface in the host
I assume you're running Wireshark on the host

ssdnvv · November 18, 2020, 8:27pm

Yes, that's what I was thinking, too. I recreated it several times by now with the very same result and really think there's something wrong with that :-/

Correct, yes.

ssdnvv · February 14, 2021, 9:53pm

I finally had the time to dig deeper into this issue.
The cards refused to work (the links show up as "activated" within my Hypervisor as well as on the client - but no traffic happens at all)... until I shut down my server (because of frustration) and after several hours started up again - et voila: One port was working. I just only tested this one port as eth1/WAN-connection and it worked out perfectly. But when I started to test the other ports (several hours later), they refused to work.
As this is pretty strange/weird I took a closer look at my Adapter, which I bought ->here:
I maybe bought a fake according to ->this thread, the card may just have died silently. Or, which might make sense with cheap transistors etc - the ports might not come up, if the card is warm/hot. I will try one last test where I cool down the complete physical machine totally, attach the cables and power it up again. Either it works (which might or might not fail after some time - but the end points are always on so this could work if the ports are not totally dead) or it does not. If no, I will order a retail Intel I350-T4v2 (sold by a known German IT company for four times the price of my China-bought one) and will see what happens after I replaced the card...