Hello, On 29.06.23 11:58, Matthias Petermann wrote:
While I do not want to praise the evening before the day....you deserve some feedback. Both the synthetic test with ssh/dd and my real payload with ssh/dump have been running for easily 6 hours without interruption this morning. I took the advice and first made static entries in the ARP table for each other for the two partners directly involved (Dom0 and the DomU concerned). I will continue to monitor this but it looks much better now than the days before.In case this proves as a reproduceable solution, my next question would be how this could be persisted (apart from hard-coding the arp -d -a / -s calls into rc.local etc.). The former proposal you sent me (net.inet.icmp.bmcastecho=1 and ping -nc10) did not create ARP-adresses with no expiration time on my NetBSD 10.0_BETA system. You mentioned this might be a feature of -HEAD - not sure about 10...I also wanted to mention - and I don't know how this contributes - that mDNSd is enabled on all involved hosts. I had originally planned this so that the hosts can also find each other via the .local suffix if the local domain .lan cannot be resolved - for example if the DNS server is down.Kind regards Matthias
With the assignment of permanent ARP entries, everything worked stably for the whole day yesterday. It seems to be due to the ARP entries. I've done some work on how to make this persistent at least as a workaround and found /etc/ethers in combination with /usr/sbin/arp -f /etc/ethers to be suitable.
Anyway, while applying this change and do further testing, something weird came to my attention. Is this expected?:
Please see the MAC adress configured in the DomU config file (on Dom0): ``` ame="srv-net" type="pv" kernel="/netbsd-XEN3_DOMU.gz" memory=512 vcpus=2 vif = ['mac=00:16:3E:00:00:01,bridge=bridge0,ip=192.168.2.51' ] disk = [ 'file:/data/vhd/srv-net_root.img,0x01,rw','file:/data/vhd/srv-net_data1.img,0x02,rw','file:/data/vhd/srv-net_data2.img,0x03,rw','file:/data/vhd/srv-net_data3.img,0x04,rw', ] ```In the DomU this configured MAC adress matches the MAC of the virtual network interface:
``` srv-net$ ifconfig xennet0 xennet0: flags=0x8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500 capabilities=0x3fc00<TCP4CSUM_Rx,TCP4CSUM_Tx,UDP4CSUM_Rx,UDP4CSUM_Tx> capabilities=0x3fc00<TCP6CSUM_Rx,TCP6CSUM_Tx,UDP6CSUM_Rx,UDP6CSUM_Tx> enabled=0 ec_capabilities=0x5<VLAN_MTU,JUMBO_MTU> ec_enabled=0 address: 00:16:3e:00:00:01 inet6 fe80::216:3eff:fe00:1%xennet0/64 flags 0 scopeid 0x1 inet 192.168.2.51/24 broadcast 192.168.2.255 flags 0 ```In opposite to this, on the Dom0 the related xen backend network interface has a slightly different MAC:
```xvif1i0: flags=0x8943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST> mtu 1500
capabilities=0x3fc00<TCP4CSUM_Rx,TCP4CSUM_Tx,UDP4CSUM_Rx,UDP4CSUM_Tx> capabilities=0x3fc00<TCP6CSUM_Rx,TCP6CSUM_Tx,UDP6CSUM_Rx,UDP6CSUM_Tx> enabled=0 ec_capabilities=0x5<VLAN_MTU,JUMBO_MTU> ec_enabled=0x1<VLAN_MTU> address: 00:16:3e:01:00:01 inet6 fe80::216:3eff:fe01:1%xvif1i0/64 flags 0 scopeid 0x4 ``` It differs in the 4th octet and I am wondering, if this is intended? Kind regards Matthias
Attachment:
smime.p7s
Description: S/MIME Cryptographic Signature