Public bug reported:
Seems like collateral from
https://bugs.launchpad.net/neutron/+bug/1850779
I think this fix causes problems. We have multiple nodes that are
DVR_SNAT mode. Snat namespace is scheduled to 1 of them.
When l3-agent is restarted on the othre nodes, now, initialize() is
invoked
Public bug reported:
We took this bug fix: https://bugs.launchpad.net/neutron/+bug/1732067
and then also backported ourselves
https://bugs.launchpad.net/neutron/+bug/1866445
The latter is for iptables based firewall.
We have VLAN based networks, and seeing ingress packets destined to
local MACs
Public bug reported:
We are hitting this kernel issue due to a DHCP agent CHECKSUM rule that
is probably obsolete/not needed:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1840619
Upgrading the kernel is one workaround, but more disruptive, especially
since still using CentOS7, and kernel
Public bug reported:
Using Rocky, with OVS. Live migrated a VM on regular VLAN based provider
network. Network connectivity was stopped, no GARP packets observed on
tcpdump. Things started working after VM initiated traffic, causing MAC
to be relearned.
Looking at the code, send_ip_addr_adv_notif
Public bug reported:
Suppose we have DHCP servers per network 2. And we have a # of DHCP
agents > 2.
During a time of network instability, RabbitMQ issues, or even a DHCP
host temporarily going down the DHCP port will get rescheduled.
Except it looks like it's not so much as getting rescheduled,
Public bug reported:
Running Rocky, in a DVR environment
We are seeing repeated errors like this in neutron-server logs. Not sure
at this point what the effect is, or harmless. This is in a build test
environment where a lot of automated VMs get spawned and deleted then
associated/disassociated w
Public bug reported:
Since upgrading to Rocky, we have seen this issue pop up in several
environments, small and large. First we see various AMQP/Rabbit related
errors - missed heartbeats from neutron-server to rabbitmq, then
repeated errors such as Socket Closed, Broken Pipe, etc...
This continu
Public bug reported:
We have 2 DHCP servers per network. After network outages, and when
hosts come back online, the number of ACTIVE DHCP servers grow. This
happened again after more outages, with some networks having up to 9-10+
DHCP ports, many in ACTIVE state, despite neutron-server's neutron.
Public bug reported:
This bug builds on issue seen in
https://bugs.launchpad.net/neutron/+bug/1838697
In that issue, if you create a tenant network, some VMs, and attach it
to 2 DVR routers, only the DVR MAC rules exist for the first router.
With this issue, simply removing the subnet or deletin
Public bug reported:
This is seen on stable/pike, have not checked latest or stein.
1. Create a basic tenant network and create a DVR router, attach them.
Spin up some VMs:
[r...@pf9-kvm-neutron.platform9.net arjun(admin)]# openstack port list
--network 8cd0e19e-9041-4a62-9cc9-6bfb5b10f955 --lo
Public bug reported:
I have a tenant network attached to a router and external network, and
some VMs with Floating IPs deployed. I updated the network MTU from 1500
to 1300 (just as a test, but try any other MTU), and restarted nova
compute, ovs agent, l3-agent.
All interfaces (qvo/qvb/qbr, qr, d
client ID should only be enforce, and leases released, if it's actually set
on the port. In that case it means someone knows what they are doing, and we
want to check for a mismatch.
If its None, I suspect in 99.% of cases the operator does not know
or care about client ID field.
Public bug reported:
Seeing this on pike, but code looks same in master so issue still likely
exists.
We have a shared external network connected to router in TenantA. Now
create a network, either shared in tenantA or owned by tenantB, and
attach to tenantA's router (an admin user will have to do
Public bug reported:
We see this sporadically, sometimes it works, sometimes it doesn't. We
delete VMs, then create new ones. The new fixed IP can't get an IP via
DHCP, because the leases file still points to MAC of some old, deleted
VMs. The host file is correctly updated.
For example we see in
Public bug reported:
Seems like collateral from
https://bugs.launchpad.net/neutron/+bug/1751396
In DVR, the distributed gateway port's IP and MAC are shared in the
qrouter across all hosts.
The dvr_process_flow on the physical bridge (which replaces the shared
router_distributed MAC address with
Public bug reported:
Since upgrading to Centos 7.5, floating IP functionality has been
completely busted. Packets arrive inbound to qrouter from fip namespace
via RFP, but are not DNAT'd or routed, as we see nothing going out qr-
interface. For outbound packets leaving the VM, they are fine, but t
Public bug reported:
In OVS agent, there is a race condition between l2pop's add_fdb_entries
notification and provision_local_vlan when we create a vlanmanager
mapping. This results in either unicast, flooding, or both entries not
being populated on the host. Without the flooding entries, connecti
17 matches
Mail list logo
