26.06.2019 20:17, Christian M wrote:
> Started ntpd in the two main 12-0-RELEASE vm's I've been testing with.
> drift files show -0.262 and -1.144 after about two hours.
This is very good, so it should not be timekeeping problem.
There were many fixes to FreeBSD12 after the release. Can you upda
Started ntpd in the two main 12-0-RELEASE vm's I've been testing with.
drift files show -0.262 and -1.144 after about two hours.
Den ons 26 juni 2019 kl 12:50 skrev Eugene Grosbein :
> 26.06.2019 17:44, Christian M wrote:
>
> > Sorry to say, but no. Nothing changed :(
> >
> > The iperf issue conc
Hi all,
first, for completeness:
> So (3rd line) the SYN/ACK arrives with correct IPv4 addresses then get’s
> forwarded with a source address of
>
> :200:0:50:e689:9765:7085 instead of 64:ff9b::9765:7085
That looks like random garbage due to an uninitialized struct in6_addr.
> Then we h
On 26.06.2019 14:23, Patrick M. Hausen wrote:
> Hi all,
>
>> Am 26.06.2019 um 12:28 schrieb Andrey V. Elsukov :
>>
>> On 26.06.2019 13:10, Patrick M. Hausen wrote:
>>> tcpdump will take some more time, currently we do not have /dev/bpf in
>>> these jails.
>>
>> So, nat64_direct_output didn't help
Hi all,
> Am 26.06.2019 um 12:28 schrieb Andrey V. Elsukov :
>
> On 26.06.2019 13:10, Patrick M. Hausen wrote:
>> tcpdump will take some more time, currently we do not have /dev/bpf in these
>> jails.
>
> So, nat64_direct_output didn't help?
> Does `ipfw nat64lsn NAT64 list states` shows correc
26.06.2019 17:44, Christian M wrote:
> Sorry to say, but no. Nothing changed :(
>
> The iperf issue concerns me a bit also:
Try starting ntpd inside VM guests, wait an hour then post contents of
/var/db/ntpd.drift
This is to verify quality of time source provided to VMs by hypervisor.
Sorry to say, but no. Nothing changed :(
The iperf issue concerns me a bit also:
root@:/usr/home/asdf # iperf3 -c 172.31.16.126
iperf3: error - unable to receive control message: Connection reset by peer
root@:/usr/home/asdf # iperf3 -c 172.31.16.126
Connecting to host 172.31.16.126, port 5201
ip
26.06.2019 17:26, Christian M wrote:
> I ran ifconfig xn0 -txcsum on both test VM's, and all incorrect checksum
> disappeared.
[skip]
Data looks good. Did it run better this time?
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mai
On 26.06.2019 13:10, Patrick M. Hausen wrote:
> tcpdump will take some more time, currently we do not have /dev/bpf in these
> jails.
So, nat64_direct_output didn't help?
Does `ipfw nat64lsn NAT64 list states` shows correct addresses?
--
WBR, Andrey V. Elsukov
signature.asc
Description: Open
I ran ifconfig xn0 -txcsum on both test VM's, and all incorrect checksum
disappeared.
netstat -sp ip for VM1 (172.31.16.125, running iperf3 -c always) and VM2
(172.31.16.126, running iperf3 -s always):
ip:
3664084 total packets received
0 bad header checksums
0 with size smaller than minimum
0 w
> Am 26.06.2019 um 11:47 schrieb Andrey V. Elsukov :
> Check the output of the following commands on both translators:
>
> # sysctl net.inet.ip.fw | grep nat64
> # ipfw nat64lsn all list
> # ipfw nat64lsn NAT64 stats
Working 11.2 system:
root@gate64:~ # sysctl net.inet.ip.fw | grep nat64
net.ine
On 26.06.2019 11:05, Patrick M. Hausen wrote:
> Hi all,
>
> we have a bit of a problem with some new servers that
> use NAT64 to access certain services that offer only
> legacy IP - like github.
>
> As far as I found the respective NAT64 gateways (in jails
> with VNET) are configured identically
Hi there,
On dt., juny 25 2019, ult...@ultimasbox.com wrote:
Hello Mel,
While it may be possible to have an IPv6 only environment, I
don't
think it is really viable. There are simply too many things that
don't run
on or have very limited support for IPv6 that it makes it very
hard
to drop
26.06.2019 15:11, Christian M wrote:
> Running tcpdump on the host while running iperf3 between the 12.0 VM's
> results in a lot of incorrect cksum like this.
>
> tcpdump -i vif54.0 -v -nn| grep -i incorrect
> 172.31.16.125.63013 > 172.31.16.126.5201: Flags [.], cksum 0x7f08
> (incorrect -> 0x030
Hi all,
we have a bit of a problem with some new servers that
use NAT64 to access certain services that offer only
legacy IP - like github.
As far as I found the respective NAT64 gateways (in jails
with VNET) are configured identically except for the
particular addresses, of course.
Yet, 11.2 wo
checksum offloading doe not seem to have any affect when done on the VM
VIF's. Both 12.0-RELEASE VIF's now have:
other-config (MRW): ethtool-rx: off; ethtool-tx: off; ethtool-sg: off;
ethtool-tso: off; ethtool-ufo: off; ethtool-gso: off
ethtool -k vif54.0
Features for vif54.0:
rx-checksumming: on
16 matches
Mail list logo
