Intel X540 T2 verliert Connection

V

vt9000

Member
Guten Morgen,

Das Release von FreeBSD 14 habe ich zum Anlass genommen meine Labs Umgebung auf FreeBSD zu ziehen. Dabei handelte es sich bisher um einen auf kvm basierende virtuelle Umgebung, die an einem Mangel Switch sowie 2 OpenBSD Kisten hängt.

Die Installation hing zuerst an einer Stelle, das Setzen von:
$ set hint.uart.1.disabled="1"
Zum Vergrößern anklicken....
Am leader prompt und anschließend in der /boot/device.hints schuf hier Abhilfe.

Die Onboard 2.5 Gbe NIC wird nicht erkannt, die X540 T2 hab ich in ein failover lagg0 Device gepackt.

Eine Test VM läuft nach Konfiguration via vm-bhyve im vlan 203.

Soweit so gut. Bei einem System Boot lassen sich alle vergebenen Adressen sowie das Gateway erfolgreich pinken, nach etwa 20 bis 30 Minuten geht die Connectivity allerdings verloren.

Lediglich ein ping der lokalen Interfaces, also lagg0 sowie lagg203 sind noch möglich. Die VM sowie das Gateway sind trotz entsprechender Routen nicht zu erreichen.

Bei dem Switch handelt es sich um einen Cisco SG350 1Gbe Switch der demnächst ausgewechselt wird.

Es gibt wohl einen Port des Intel Drivers auf freshports den ich mangels Zeit noch nicht testen konnte.

Hatte hier jemand mit einer ähnlichen Kombination bereits Erfahrungen diesbezüglich sammeln können, bzw. wie kann ich hier beim Debugging vorgehen?

Unter Manjaro Linux gab es keine Probleme weswegen ich den Treiber bzw. die Netzwerkkarte hier in Verdacht habe.

Viele Grüße
 
vt9000 schrieb:
...n, nach etwa 20 bis 30 Minuten geht die Connectivity allerdings verloren.

Lediglich ein ping der lokalen Interfaces, also lagg0 sowie lagg203 sind noch möglich. Die VM sowie das Gateway sind trotz entsprechender Routen nicht zu erreichen.
Zum Vergrößern anklicken....
Wie sind die Ausgaben von:
Code: 
cat /etc/rc.conf | grep -i defaultrouter
arping -c 3 -i <Interface> <IP-Adresse-gateway/Router>
arp -a
?
EDIT:

Evtl. auch mit einem permanenten arp-cache-Eintrag für das gateway/Router testen:
Code: 
arp -S <IP-Adresse-gateway> <MAC-Adresse-gateway> pub
und evtl. auch (temporär) mit einem root-cronjob der alle 30 Sekunden einen arping (arp-request) auf die IP-Adresse vom gateway macht:
Code: 
@30    root    -q -n arping -q -c 2 -W 1 -w 5 -i <Interface> <IP-Adresse-gateway/Router>
(evtl. den absoluten Pfad für arping benutzen).
 
morromett schrieb:
Wie sind die Ausgaben von:
Code: 
cat /etc/rc.conf | grep -i defaultrouter
arping -c 3 -i <Interface> <IP-Adresse-gateway/Router>
arp -a
?
Zum Vergrößern anklicken....
arp -a zeigt incomplete, im tcpdump sieht man lediglich who-has requests, allerdings keine Antwort.

Die rc.conf und die Ausgabe von arping kann ich abends nach liefern.

Edit: Vielen Dank für die schnelle Antwort.
 
Evtl. wäre es hilfreich wenn du ein paar mehr infos postest, z.B. die komplette ausgabe von ifconfig, die config vom switch auf den entsprechenden interfaces und die genaue netzwerk config zumindest vom bhyve-host-betriebsystem sowie des gasts-betriebsystems.
 
vt9000 schrieb:
nach etwa 20 bis 30 Minuten geht die Connectivity allerdings verloren.
Zum Vergrößern anklicken....
Ich hatte Probleme mit einer X550-T2. Dort musste ich den Medientyp explizit angeben, sonst hat das Interface überhaupt keinen carrier bekommen. Vielleicht hilft dir das auch:

Code: 
ifconfig_ix1="inet aa.xx.yy.zz/nn media 1000baseTX up"
                                  ^^^^^^^^^^^^^^^^^^
 
Ist die Karte umgebaut worden oder anders gefragt: ist sie jetzt einem anderen airflow als vorher ausgesetzt?
Mir ist eine Intel unregelmäßig sogar vom Bus geflogen, ohne dass was geändert wurde. Bei genauem Hinsehen fiel dann auf, dass das Kühlpad furztrocken wegbröselte.
Also einmal ne Runde durchputzen, frische Paste drauf. Läuft jetzt über zwei Monate wieder perfekt!

Die Karten werden heiß, aus der Ära (2012) sowieso und da sie passiv gekühlt sind, machts das nicht besser. Kann jetzt natürlich sein, dass die config-Umstellung + lagg ein Grad wärmer triggert und dann nach 20-30 Minuten tempbedingt aussteigt.
 
Die auto negotiation könnte mir da tatsächlich in die Suppe spucken wozu ich auch etwas im englischen FreeBSD Forum gefunden hab. Werd mir im Zuge dessen mal den Kühler ansehen. Hab die Karte im Januar gekauft, aber wer weiß wo und wie lange die davor rum gelegen ist. Der Steckplatz hat sich ebenfalls geändert, da ne alte Geforce 1060 wieder in den Rechner gewandert ist.

Die Entscheidung für die X540 T2 lag an der Tatsache daß diese eine der wenigen Karten war, die passiv gekühlt sind.
 
vt9000 schrieb:
Die Entscheidung für die X540 T2 lag an der Tatsache daß diese eine der wenigen Karten war, die passiv gekühlt sind.
Zum Vergrößern anklicken....
Das ist nicht so wie mit passiv gekühlten GPUs und da geht das auch nur, weil der Kühler meist doppelt so groß wie die Karte selbst ist. Es sind Serverkarten, die erwarten hohen airflow der in Servern naturgemäß herrscht bzw. herrschen sollte. Ich weiß jetzt nicht, ob und wie man den Sensor abrufen könnte, sofern sie einen haben. Aber es kann nicht schaden, mal direkt einen Lüfter draufpusten zu lassen und gucken, wie sich das verhält.

vt9000 schrieb:
Hab die Karte im Januar gekauft, aber wer weiß wo und wie lange die davor rum gelegen ist.
Zum Vergrößern anklicken....
Spielt eigentlich keine Rolle, ob das Pad jetzt 7 oder 11 Jahre ausgetrocknet ist. :)
 
Wie versprochen die Auszuege aus der Konfiguration:

ix0: flags=1008943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST,LOWER_UP> metric 0 mtu 1500
options=4e53fbb<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,JUMBO_MTU,VLAN_HWCSUM,TSO4,TSO6,LRO,WOL_UCAST,WOL_MCAST,WOL_MAGIC,VLAN_HWFILTER,VLAN_HWTSO,RXCSUM_IPV6,TXCSUM_IPV6,HWSTATS,MEXTPG>
ether a0:36:9f:40:55:90
media: Ethernet autoselect (1000baseT <full-duplex>)
status: active
nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL>
ix1: flags=1008943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST,LOWER_UP> metric 0 mtu 1500
options=4e53fbb<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,JUMBO_MTU,VLAN_HWCSUM,TSO4,TSO6,LRO,WOL_UCAST,WOL_MCAST,WOL_MAGIC,VLAN_HWFILTER,VLAN_HWTSO,RXCSUM_IPV6,TXCSUM_IPV6,HWSTATS,MEXTPG>
ether a0:36:9f:40:55:90
hwaddr a0:36:9f:40:55:92
media: Ethernet autoselect (1000baseT <full-duplex>)
status: active
nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL>
lo0: flags=1008049<UP,LOOPBACK,RUNNING,MULTICAST,LOWER_UP> metric 0 mtu 16384
options=680003<RXCSUM,TXCSUM,LINKSTATE,RXCSUM_IPV6,TXCSUM_IPV6>
inet 127.0.0.1 netmask 0xff000000
inet6 ::1 prefixlen 128
inet6 fe80::1%lo0 prefixlen 64 scopeid 0x3
groups: lo
nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL>
lagg0: flags=1008943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST,LOWER_UP> metric 0 mtu 1500
options=4e53fbb<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,JUMBO_MTU,VLAN_HWCSUM,TSO4,TSO6,LRO,WOL_UCAST,WOL_MCAST,WOL_MAGIC,VLAN_HWFILTER,VLAN_HWTSO,RXCSUM_IPV6,TXCSUM_IPV6,HWSTATS,MEXTPG>
ether a0:36:9f:40:55:90
hwaddr 00:00:00:00:00:00
inet 10.66.1.100 netmask 0xffffff00 broadcast 10.66.1.255
laggproto failover lagghash l2,l3,l4
laggport: ix0 flags=5<MASTER,ACTIVE>
laggport: ix1 flags=0<>
groups: lagg
media: Ethernet autoselect
status: active
nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL>
vm-public: flags=1008843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST,LOWER_UP> metric 0 mtu 1500
options=0
ether ee:bc:53:3c:72:5b
id 00:00:00:00:00:00 priority 32768 hellotime 2 fwddelay 15
maxage 20 holdcnt 6 proto rstp maxaddr 2000 timeout 1200
root id 00:00:00:00:00:00 priority 32768 ifcost 0 port 0
member: lagg0.203 flags=143<LEARNING,DISCOVER,AUTOEDGE,AUTOPTP>
ifmaxaddr 0 port 6 priority 128 path cost 55
groups: bridge vm-switch viid-4c918@
nd6 options=9<PERFORMNUD,IFDISABLED>
lagg0.203: flags=1008943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST,LOWER_UP> metric 0 mtu 1500
description: vm-vlan/public/lagg0.203
options=4600303<RXCSUM,TXCSUM,TSO4,TSO6,RXCSUM_IPV6,TXCSUM_IPV6,MEXTPG>
ether a0:36:9f:40:55:90
groups: vlan vm-vlan viid-4272e@
vlan: 203 vlanproto: 802.1q vlanpcp: 0 parent interface: lagg0
media: Ethernet autoselect
status: active
nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL>
Zum Vergrößern anklicken....
/etc/rc.conf
hostname="pardona"

ifconfig_ix0="up"
ifconfig_ix1="up"
cloned_interfaces="lagg0"
ifconfig_lagg0="laggproto failover laggport ix0 laggport ix1"
ipv4_addrs_lagg0="10.66.1.100/24"

defaultrouter="10.66.1.1"

gateway_enable="YES"

sshd_enable="YES"
moused_nondefault_enable="NO"
# Set dumpdev to "AUTO" to enable crash dumps, "NO" to disable
dumpdev="AUTO"
zfs_enable="YES"

kld_list="nvidia-modeset"

dbus_enable="YES"
gdm_enable="YES"

vm_enable="YES"
vm_dir="zfs:zroot/bhyve"

pf_enable="YES"
Zum Vergrößern anklicken....
arp -a
# arp -a
foo.bar.net (10.66.1.1) at 00:0d:b9:42:61:79 on lagg0 permanent [ethernet]
pardona.bar.net (10.66.1.100) at a0:36:9f:40:55:90 on lagg0 permanent [ethernet]
Zum Vergrößern anklicken....
arping output
# arping -c 3 -i lagg0 10.66.1.1
ARPING 10.66.1.1
60 bytes from 00:0d:b9:42:61:79 (10.66.1.1): index=0 time=155.873 usec
60 bytes from 00:0d:b9:42:61:79 (10.66.1.1): index=1 time=149.309 usec
60 bytes from 00:0d:b9:42:61:79 (10.66.1.1): index=2 time=212.339 usec

--- 10.66.1.1 statistics ---
3 packets transmitted, 3 packets received, 0% unanswered (0 extra)
rtt min/avg/max/std-dev = 0.149/0.173/0.212/0.028 ms
Zum Vergrößern anklicken....

media 1000baseTX up habe ich jetzt in der rc.conf ergaenzt und das Netzwerk neu gestartet. VM config kommt in einem separatem Post.
 
Zuletzt bearbeitet:
Wie versprochen die Configs der VM:

cat /zroot/bhyve/mydebian/mydebian.conf
loader="grub"
cpu=2
memory=6192M
network0_type="virtio-net"
network0_switch="public"
grub_run_partition="1"
grub_run_dir="/boot/grub"
disk0_name="disk0"
disk0_dev="sparse-zvol"
disk0_type="virtio-blk"
uuid="a36b9d60-5b56-4492-9a90-2bff4b8ea14d"
network0_mac="58:9c:fc:03:fb:02"
Zum Vergrößern anklicken....
vm switch list

# vm switch list public --help
NAME TYPE IFACE ADDRESS PRIVATE MTU VLAN PORTS
public standard vm-public - no - 203 lagg0
Zum Vergrößern anklicken....
Die VM ist statisch auf die 10.101.1.10 konfiguriert und nutzt als Gateway die 10.101.1.1 (Tagged vlan iface auf dem Router) analog zur 10.66.1.1
# vm console mydebian
Connected

mydebian login: root
Password:
Linux mydebian 6.1.0-13-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.1.55-1 (2023-09-29) x86_64

The programs included with the Debian GNU/Linux system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.

Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.
Last login: Sun Nov 26 12:23:57 EST 2023 on ttyS0
root@mydebian:~# ifconfig
-bash: ifconfig: command not found
root@mydebian:~# 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 noprefixroute
valid_lft forever preferred_lft forever
2: enp0s5: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
link/ether 58:9c:fc:03:fb:02 brd ff:ff:ff:ff:ff:ff
inet 10.101.1.10/24 brd 10.101.1.255 scope global enp0s5
valid_lft forever preferred_lft forever
inet6 fe80::5a9c:fcff:fe03:fb02/64 scope link
valid_lft forever preferred_lft forever
root@mydebian:~# ip r
default via 10.101.1.1 dev enp0s5 onlink
10.101.1.0/24 dev enp0s5 proto kernel scope link src 10.101.1.10
Zum Vergrößern anklicken....
Mittlerweile hat die Virtuelle Maschine keine Connectivitaet mehr. Keine Ahnung ob das mit dem Neustart der des Netzwerks zu tun hat. Das lagg0 Interface scheint jedenfalls momentan keine Probleme zu bereiten.

Ich werde auf jeden Fall einen Blick darauf werfen, einen cronjob wie vorgeschlagen hab ich in die crontab gepackt.
 
vt9000 schrieb:
Mittlerweile hat die Virtuelle Maschine keine Connectivitaet mehr. ..... Das lagg0 Interface scheint jedenfalls momentan keine Probleme zu bereiten.
Ich werde auf jeden Fall einen Blick darauf werfen, einen cronjob wie vorgeschlagen hab ich in die crontab gepackt.
Zum Vergrößern anklicken....
Sieht man mit tcpdump, am lagg0-Interface, arp-Anfragen und -Antworten (d. h. in bei de Richtungen):
Code: 
tcpdump -c 30 -vvveni lagg0 arp
?
 
Moin,
Heute morgen habe ich den intel_ix_kmod installiert. In dmesg waren ix0, lagg0 sowie lo0 up down Einträge zu finden.

Die up down Meldungen sind erst einmal verschwunden.

Werde dann Abends wieder einen Blick auf die Kiste werfen.

Zur besseren Kühlung kommt dann noch ein Dritter 140 Silent Wings 3 ins Dark Base Pro 900 Gehäuse. Kühlpaste gibt's für die Karte dann am Wochenende.
 
Du könntest mal bei diesem Treiber auf ein sysctl bez. der Temperatur suchen, vielleicht gibts da was.

sysctl -a | grep temp pi mal Daumen.
 
Guten Morgen,

der intel_ix_kmod Treiber werkelt jetzt seit gestern und die Probleme scheinen verschwunden. Nach einem Tag sehen die ix spezifischen sysctl's gut aus. Leider gibt es im ix Treiber keine temp sysctls. Es gibt sysctls 'dev.ix.<n>.mac_stats' die auch error counter beinhalten, diese sind allerdings alle leer.
# sysctl -a | grep -E 'dev\.ix.*(drop|disc)'
dev.ix.1.mac_stats.short_discards: 0
dev.ix.1.queue7.rx_discarded: 0
dev.ix.1.queue7.br_drops: 0
dev.ix.1.queue6.rx_discarded: 0
dev.ix.1.queue6.br_drops: 0
dev.ix.1.queue5.rx_discarded: 0
dev.ix.1.queue5.br_drops: 0
dev.ix.1.queue4.rx_discarded: 0
dev.ix.1.queue4.br_drops: 0
dev.ix.1.queue3.rx_discarded: 0
dev.ix.1.queue3.br_drops: 0
dev.ix.1.queue2.rx_discarded: 0
dev.ix.1.queue2.br_drops: 0
dev.ix.1.queue1.rx_discarded: 0
dev.ix.1.queue1.br_drops: 0
dev.ix.1.queue0.rx_discarded: 0
dev.ix.1.queue0.br_drops: 0
dev.ix.1.dropped: 0
dev.ix.0.mac_stats.short_discards: 0
dev.ix.0.queue7.rx_discarded: 0
dev.ix.0.queue7.br_drops: 0
dev.ix.0.queue6.rx_discarded: 0
dev.ix.0.queue6.br_drops: 0
dev.ix.0.queue5.rx_discarded: 0
dev.ix.0.queue5.br_drops: 0
dev.ix.0.queue4.rx_discarded: 0
dev.ix.0.queue4.br_drops: 0
dev.ix.0.queue3.rx_discarded: 0
dev.ix.0.queue3.br_drops: 0
dev.ix.0.queue2.rx_discarded: 0
dev.ix.0.queue2.br_drops: 0
dev.ix.0.queue1.rx_discarded: 0
dev.ix.0.queue1.br_drops: 0
dev.ix.0.queue0.rx_discarded: 0
dev.ix.0.queue0.br_drops: 0
dev.ix.0.dropped: 0
Zum Vergrößern anklicken....
Der Output des tcpdump Kommandos bezueglich arp requests / replies zeigt ebenfalls keine Auffaelligkeiten.
# tcpdump -c 30 -vvveni lagg0 arp
tcpdump: listening on lagg0, link-type EN10MB (Ethernet), snapshot length 262144 bytes
05:07:33.043460 a0:36:9f:40:55:90 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 58: Ethernet (len 6), IPv4 (len 4), Request who-has 10.66.1.1 tell 10.66.1.100, length 44
05:07:33.043626 00:0d:b9:42:61:79 > a0:36:9f:40:55:90, ethertype ARP (0x0806), length 60: Ethernet (len 6), IPv4 (len 4), Reply 10.66.1.1 is-at 00:0d:b9:42:61:79, length 46
05:07:34.106253 a0:36:9f:40:55:90 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 58: Ethernet (len 6), IPv4 (len 4), Request who-has 10.66.1.1 tell 10.66.1.100, length 44
05:07:34.106418 00:0d:b9:42:61:79 > a0:36:9f:40:55:90, ethertype ARP (0x0806), length 60: Ethernet (len 6), IPv4 (len 4), Reply 10.66.1.1 is-at 00:0d:b9:42:61:79, length 46
05:08:05.013165 a0:36:9f:40:55:90 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 58: Ethernet (len 6), IPv4 (len 4), Request who-has 10.66.1.1 tell 10.66.1.100, length 44
05:08:05.013298 00:0d:b9:42:61:79 > a0:36:9f:40:55:90, ethertype ARP (0x0806), length 60: Ethernet (len 6), IPv4 (len 4), Reply 10.66.1.1 is-at 00:0d:b9:42:61:79, length 46
05:08:06.014847 a0:36:9f:40:55:90 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 58: Ethernet (len 6), IPv4 (len 4), Request who-has 10.66.1.1 tell 10.66.1.100, length 44
05:08:06.014979 00:0d:b9:42:61:79 > a0:36:9f:40:55:90, ethertype ARP (0x0806), length 60: Ethernet (len 6), IPv4 (len 4), Reply 10.66.1.1 is-at 00:0d:b9:42:61:79, length 46
05:08:37.003468 a0:36:9f:40:55:90 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 58: Ethernet (len 6), IPv4 (len 4), Request who-has 10.66.1.1 tell 10.66.1.100, length 44
05:08:37.003605 00:0d:b9:42:61:79 > a0:36:9f:40:55:90, ethertype ARP (0x0806), length 60: Ethernet (len 6), IPv4 (len 4), Reply 10.66.1.1 is-at 00:0d:b9:42:61:79, length 46
05:08:38.004749 a0:36:9f:40:55:90 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 58: Ethernet (len 6), IPv4 (len 4), Request who-has 10.66.1.1 tell 10.66.1.100, length 44
05:08:38.004885 00:0d:b9:42:61:79 > a0:36:9f:40:55:90, ethertype ARP (0x0806), length 60: Ethernet (len 6), IPv4 (len 4), Reply 10.66.1.1 is-at 00:0d:b9:42:61:79, length 46
05:09:09.028770 a0:36:9f:40:55:90 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 58: Ethernet (len 6), IPv4 (len 4), Request who-has 10.66.1.1 tell 10.66.1.100, length 44
05:09:09.028933 00:0d:b9:42:61:79 > a0:36:9f:40:55:90, ethertype ARP (0x0806), length 60: Ethernet (len 6), IPv4 (len 4), Reply 10.66.1.1 is-at 00:0d:b9:42:61:79, length 46
05:09:10.050741 a0:36:9f:40:55:90 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 58: Ethernet (len 6), IPv4 (len 4), Request who-has 10.66.1.1 tell 10.66.1.100, length 44
05:09:10.050899 00:0d:b9:42:61:79 > a0:36:9f:40:55:90, ethertype ARP (0x0806), length 60: Ethernet (len 6), IPv4 (len 4), Reply 10.66.1.1 is-at 00:0d:b9:42:61:79, length 46
Zum Vergrößern anklicken....
Die virtuelle Maschine ist erreichbar und kommt ans Gateway
# vm console mydebian
Connected

mydebian login: root
Password:
Linux mydebian 6.1.0-13-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.1.55-1 (2023-09-29) x86_64

The programs included with the Debian GNU/Linux system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.

Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.
Last login: Wed Nov 29 23:12:27 EST 2023 on ttyS0
root@mydebian:~# ping -c3 10.66.1.1
PING 10.66.1.1 (10.66.1.1) 56(84) bytes of data.
64 bytes from 10.66.1.1: icmp_seq=1 ttl=255 time=0.303 ms
64 bytes from 10.66.1.1: icmp_seq=2 ttl=255 time=0.338 ms
64 bytes from 10.66.1.1: icmp_seq=3 ttl=255 time=0.318 ms

--- 10.66.1.1 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2084ms
rtt min/avg/max/mdev = 0.303/0.319/0.338/0.014 ms
root@mydebian:~# ping -c3 10.101.1.1
PING 10.101.1.1 (10.101.1.1) 56(84) bytes of data.
64 bytes from 10.101.1.1: icmp_seq=1 ttl=255 time=0.307 ms
64 bytes from 10.101.1.1: icmp_seq=2 ttl=255 time=0.317 ms
64 bytes from 10.101.1.1: icmp_seq=3 ttl=255 time=0.339 ms

--- 10.101.1.1 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2096ms
rtt min/avg/max/mdev = 0.307/0.321/0.339/0.013 ms
root@mydebian:~# ip addr show enp0s5
2: enp0s5: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
link/ether 58:9c:fc:03:fb:02 brd ff:ff:ff:ff:ff:ff
inet 10.101.1.10/24 brd 10.101.1.255 scope global enp0s5
valid_lft forever preferred_lft forever
inet6 fe80::5a9c:fcff:fe03:fb02/64 scope link
valid_lft forever preferred_lft forever
root@mydebian:~# ip r
default via 10.101.1.1 dev enp0s5 onlink
10.101.1.0/24 dev enp0s5 proto kernel scope link src 10.101.1.10
Zum Vergrößern anklicken....
Um auf der sicheren Seite zu sein hab ich die Kiste rebootet. Bisher sehe jetzt keine Probleme mehr, mal sehen wie es dann Abends aussieht.

Alles in Allem gefaellt mir die Kombi FreeBSD bhyve in Verbindung mit vm-bhyve sehr gut und bhyve ist gefuehlt auch richtig schnell.
 
Im letzten Codeblock sind die Ausgaben aus der Debian VM zu finden.

Die IP ist die 10.101.1.10, das Gateway 10.101.1.1.

Scheint alles soweit zu laufen, am Abend kann ich wieder nen Blick drauf werfen ob es noch Probleme mit dem Gateway von lagg0 gab.
 
Das Gateway ist im Endeffekt eine OpenBSD apu2c4 Kiste die ein Interface em1 mit der IP 10.66.1.1 und ein Interface vlan203 mit der IP 10.101.1.1 hat.

Dazwischen ist ein cisco SG350 mit tagged vlans im switchport Mode trunk mit nem native vlan 10.66.1.0/24 sowie mehreren allowed vlans konfiguriert.
 
vt9000 schrieb:
Im letzten Codeblock sind die Ausgaben aus der Debian VM zu finden.

Die IP ist die 10.101.1.10, das Gateway 10.101.1.1.
Zum Vergrößern anklicken....
Ja, aber dort zeigst Du auch einen erfolgreichen Ping auf die 10.66.1.1 aus einem anderen Subnetz:
Code: 
root@mydebian:~# ping -c3 10.66.1.1
PING 10.66.1.1 (10.66.1.1) 56(84) bytes of data.
64 bytes from 10.66.1.1: icmp_seq=1 ttl=255 time=0.303 ms
64 bytes from 10.66.1.1: icmp_seq=2 ttl=255 time=0.338 ms
64 bytes from 10.66.1.1: icmp_seq=3 ttl=255 time=0.318 ms

--- 10.66.1.1 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2084ms
rtt min/avg/max/mdev = 0.303/0.319/0.338/0.014 ms
... und das Routing dort hin, meinte ich.
 
Das Routing in das Subnet ist momentan erlaubt. Ich bin nicht ganz sicher auf was du hinaus willst, da kann ich hoechstens spekulieren.

Mir ist klar, dass damit der Hypervisor aus der mydebian VM netzwerktechnisch direkt erreichbar ist. Da es sich hier allerdings lediglich um eine labs Umgebung handelt sehe ich hier kein Thema. Im Zuge des Umzugs des Hypervisors kann ich diesen Weg im Anschluss via pf auf dem Router zunageln.

PS: Der intel_ix_kmod Treiber werkelt ohne weitere Probleme. Sogar ein suspend wurde nach kurzer Downtime, resultierend in 2 mails des arpping cronjobs, ueberlebt.
 
Kleines Update,

die intel x540 T2 Karte hatte wohl tatsächlich ein Hitzeproblem. Habe diese jetzt mit einer

ix0@pci0:11:0:0: class=0x020000 rev=0x01 hdr=0x00 vendor=0x8086 device=0x10fb subvendor=0x8086 subdevice=0x000c
vendor = 'Intel Corporation'
device = '82599ES 10-Gigabit SFI/SFP+ Network Connection'
class = network
subclass = ethernet
ix1@pci0:11:0:1: class=0x020000 rev=0x01 hdr=0x00 vendor=0x8086 device=0x10fb subvendor=0x8086 subdevice=0x000c
vendor = 'Intel Corporation'
device = '82599ES 10-Gigabit SFI/SFP+ Network Connection'
class = network
subclass = ethernet
Zum Vergrößern anklicken....
ersetzt. Die Verbindungen sind jetzt stabil, ein Download einer FreeBSD dvd1 iso läuft jetzt komplett durch. Damit konnte ich die Netzwerkkarte zuverlässig abschießen.

Vielen Dank für die hilfreichen Tipps. Nun steht einer Verwendung von FreeBSD bhyve für mein Homelab nichts mehr im Wege.

EDIT: STRG+Return beendet nicht die Eingabe im CodeBlock sondern schließt die Eingabe ab.

VG
 
Der Kühler sieht ja auch recht winzig aus. Kannst du bei der neuen und konntest du bei der alten im Betrieb ohne Schmerzen dranfassen?
 
Die neue Karte wird lediglich lauwarm, die alte Karte habe ich im laufenden Betrieb nicht angefasst, hat aber ein Label dass die Kühlrippen wohl heiß werden. Hab es dann nicht ausprobiert einfach aus Gründen "Told you so!".

Das Gehäuse habe ich jetzt umgebaut dass auf der gesamten Höhe, auch oberhalb der Grafikkarte von vorne Luft durchs Gehäuse geblasen werden. Für den Ryzen 9 7590x ist eine nzxt Wasserkühlung verbaut deren Lüfter oben im Gehäuse Luft nach draußen pustet.

Der Umbau der Gehäusekühlung hat auf jeden Fall keine Abhilfe geschafft, Temperaturwerte waren leider keine ersichtlich, das Verhalten bei erhöhten Netzwerktraffic für mich aber logische Konsequenz.
 
Kurzer Nachtrag: Habe gerade vm bhyve angetestet für den Usecase den ich habe: Erstellung von virtuellen Maschinen am liebsten mit cloud-init. Was soll ich sagen: Works like a charm.

Als Anleitung zur Initialisierung von bhyve kam das Readme des vm bhyve github repos zum Einsatz: https://github.com/churchers/vm-bhyve

Eventuell noch Teile von hier: https://gist.github.com/ianthetechie/4e1e0b4cb48981629e5ad0e2cdd4e5ec

Vor allem der letmeout Part aus der vm console.

Zum Austesten von cloud-init diese beiden Seiten:
www.sisyphus.de

Create VMs in minutes with cloud config for vm-bhyve

There is an unexpected quick, easy and satisfying way to create new virtual machines for the bhyve supervisor in FreeBSD with the vm-bhyve utility and special cloud images supplied by many distributors.
www.sisyphus.de www.sisyphus.de

FreeBSD BHyve Setup Note

bhyve is FreeBSD's hypervisor. The native setup guide is at here. However, there exists a higher level wrapper called vm-bhyve available. I'm using that. I'm following the installation guide in README
kflu.github.io kflu.github.io

Wobei letztere eine bessere Beschreibung enthält um eine Automatisierung wie Ansible drauf fallen zu lassen.

Für die zu startenden VM's kann man in der rc.conf eventuell ein File /etc/vms.conf sourcen da man dann lediglich die VM Einträge in diesem File pflegen muss und nicht die gesamte rc.conf.
 
vt9000 schrieb:
Kurzer Nachtrag: Habe gerade vm bhyve angetestet für den Usecase den ich habe: Erstellung von virtuellen Maschinen am liebsten mit cloud-init. Was soll ich sagen: Works like a charm.
Zum Vergrößern anklicken....

Danke für den aufschlussreichen Beitrag. :cool:

Ich finde es persönlich auch auf der anderen Seite (mit FreeBSD als Gast) sehr schön, dass cloud-init unter FreeBSD große Fortschritte macht. Das ist (bzw. hoffentlich bald war) einer der großen Showstopper für den Einsatz von FreeBSD als Bestandteil zeitgenössischer IT-Infrastruktur.
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Zurück
Oben