Hello Manuel, On 23.06.23 16:17, Manuel Bouyer wrote:
I'm not sure it's Xen-specific, there have been changes in the network stack between -9 and -10 affecting the way ARP and duplicate addresses are managed.
Thanks for your attention. I remember you are one of the Xen Gurus RVP recommended me to call :-) At the moment I am also far from sure this is a Xen issue, but try to follow each suspicion I get aware of. Do you have more details on the network stack changes (maybe a link to change log or files I should take a look at?).
``` name="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' ]the ip= part is not used by NetBSD. A fixed mac address shouldn't make a difference, it's the xl tool which generates one if needed and the domU doesn't know if it's fixed or auto-generated.
Thanks for the clarification... so then its a one time setup thing only.Btw, the ip= I forgot to mention - I agree this is not part of the official NetBSD configuration :-) Actually I use it as a way to assign IP-Adresses for my DomUs from the Dom0 config. It's part of the custom image builder[1] created to standardize my setups. Xen in NetBSD 10 feels (and measures...) so much more performant - I hope there is some way to address this network issue. For the weekend I plan do reproduce the exact same setup on a higher quality hardware to find out if there is potentially some hardware related factor existing. At the moment I run it on a low cost NUC7CJYB with Celeron J4025 CPU and Realtek NIC. I go some reports especially the NIC could qualify for the source of the trouble (although I still don't understand if this is relevant for the bridge between Dom0 and the DomUs.).
Kind regards Matthias[1] https://forge.petermann-it.de/mpeterma/vmtools/src/commit/95d55f184b9fd1d74c931abfc7d44c58f00c0c32/lib/install.sh#L81
Attachment:
smime.p7s
Description: S/MIME Cryptographic Signature