On Sun, 2019-01-27 at 21:50 +0800, Ed Greshko wrote:
On 1/27/19 7:48 AM, Patrick O'Callaghan wrote:
> Same here. To eliminate some variables, I turned off my dnsmasq
> service, disabled it and rebooted. The problem is still there: for a
> few moments the guests are network-reachable, then they aren't. They
> may come back, they may not. Or one does and the other doesn't. It's
> completely unpredictable. If I could even figure out which component is
> causing the problem I could BZ it, but nothing stands out.
>
> I'll keep looking but I'm seriously considering a complete system
> reinstall, something I haven't done in about 5 years, in case some
> cruft from earlier iterations of Fedora is somehow lurking in the
> shadows.
Well, I can't say that I've ever seen "intermittent" problems like that
caused by SW. But
since the host and guest are on the same HW it seems to be the only thing that makes
sense.
The only thing that comes to mind is that communication on a LAN with IPv4 takes place
based on the MAC address and ARP request/response. If somehow guest obtained the same
MAC
address for their interfaces one may see odd behavior.
Apparently not. The link/ether field is different for all of them:
$ ip addr
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: enp3s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq state UP group
default qlen 1000
link/ether d4:3d:7e:f4:1b:08 brd ff:ff:ff:ff:ff:ff
inet 192.168.1.73/24 brd 192.168.1.255 scope global noprefixroute enp3s0
valid_lft forever preferred_lft forever
inet6 fe80::d63d:7eff:fef4:1b08/64 scope link noprefixroute
valid_lft forever preferred_lft forever
3: virbr0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group
default qlen 1000
link/ether 52:54:00:8b:88:60 brd ff:ff:ff:ff:ff:ff
inet 192.168.122.1/24 brd 192.168.122.255 scope global virbr0
valid_lft forever preferred_lft forever
4: virbr0-nic: <BROADCAST,MULTICAST> mtu 1500 qdisc fq master virbr0 state DOWN
group default qlen 1000
link/ether 52:54:00:8b:88:60 brd ff:ff:ff:ff:ff:ff
5: vnet0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq master virbr0 state
UNKNOWN group default qlen 1000
link/ether fe:54:00:b0:20:88 brd ff:ff:ff:ff:ff:ff
inet6 fe80::fc54:ff:feb0:2088/64 scope link
valid_lft forever preferred_lft forever
6: vnet1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq master virbr0 state
UNKNOWN group default qlen 1000
link/ether fe:54:00:1d:55:89 brd ff:ff:ff:ff:ff:ff
inet6 fe80::fc54:ff:fe1d:5589/64 scope link
valid_lft forever preferred_lft forever
Another thing: the gateway address (192.168.122.1) is pingable from
both sides, i.e. from the guest and the host, but packets are not being
forwarded. net.ipv4.ip_forward is 1 (on), so possibly the problem is at
a lower level with the actual bridge. Not sure how I can check that,
but note that ip6 packets do go back and forth so it seems unlikely.
The firewall rules are:
$ sudo firewall-cmd --info-zone=public
public (active)
target: default
icmp-block-inversion: no
interfaces: enp3s0 p3p1 virbr0 virbr0-nic
sources:
services: dhcp dhcpv6-client dns mdns mountd nfs rpc-bind rsyncd samba ssh
ports: 32410/udp 32413/tcp 32412/tcp 8200/tcp 1900/udp 32400/tcp 32469/tcp 32414/tcp
24800/tcp
protocols:
masquerade: no
forward-ports:
source-ports: 24800/tcp
icmp-blocks:
rich rules:
Thanks for your patience in looking at this Ed. Don't feel pressured to
keep responding :-)
poc