A buggy if check causes the code to attempt setting the IPv6 default
route through an IPv4 gateway causing PAPI to produce the following
TypeError: object of type 'IPv4Address' has no len()
VPP 20.05 changed the API definition of acl_add_replace() and its
macip equivalent.. Fix to support it.
Some tidyups in the way things are constructed.
These date from when ipaddress required unicode input. That's no
longer true, and these obscure the type information from the
original calls. Sub in the orginals.
These now use ip_interface types to set, list and delete IP addresses.
Calling code has been very lightly touched to make this work, as
we plan on propagating the type change outward from vpp.py.
The remote locator's IP address is not programmed correctly in VPP
which implies that the l3 underlay network is effectively broken and
no communication is possible across compute nodes.
Refactoring included: push the construction of VPP-specific data
structures into vpp.py and make the call parameters more neutral.
We're still using PAPI's return, but we assign a type to it which
makes it explicit what we're getting and what callers can do with it.
'get_macip_acl_dumo' is a redundant and cumbersome name; _dump is
more PAPI parlance, so I went with get_macip_acls.
Removed the proxy function, it only makes things less clear.
Server.py has a lot of functions in, not all of which have signatures,
so we can't go full-on with type checking, but we can at least make it
check the bodies of all its functions.
Note the spot where bvi_if_idx can be None ('not found') - the checks
would rule out 0 (valid ifidx) and in some cases aren't made (go do
things with None that are unacceptable). All patched up.
It's hard to typecheck in its current form, but it also uses 'file'
(conventionally a module) as a variable name. Slight rework without
functional change, should be possible to eyeball the result and agree
nothing significant has changed here.
loopback_idx == 0 is a valid possiblility, so a test should have read
loopback_idx is not None (i.e. there is no loopback interface).
However, the mocking in the test repo thinks that that 'None' return
value should actually be 'False', which means that correcting the check
in the code breaks the test.
Typing strengthening in vpp.py
- all functions have py3-style type signatures
(highlighting inconsistencies in typing)
- Some types added to emphasise where the data has a
type (e.g. int -> *_idx_t for a lot of the object indices since
they are not convertible with ints or each other; some less
strict types where we should be looking at NamedTuple types;
address types; etc.)
- callers altered where necessary (most are not strictly checked enough
to notice, since types are only checked in functions with signatures)
Since this file is called by others but does not call out,
this is a fine place to get type-strength started in the VPP code.
When the gpe listener receives a gpe port delete event from etcd, it
deletes the remote mapping entry for the port as well the lisp l2
arp entry. Before deleting the l2 arp entry, it checks for the
existence of the entry in VPP. This check fails because the IP address
returned by PAPI is the Python IPv4Address object whereas the gpe
listener expects the binary address.
As part of a port binding the agent also checks and creates the gpe
remote-mappings for all the ports for which such a mapping does not
exist. But an incorrect regex match leads to failure in creation of
the remote-mappings. This patch fixes it.
Instead of the local VM's mac, the vhostuser interface's mac is
programmed as lisp local eid in VPP. This causes VPP to drop outgoing
packets effectively ensuring that no communication can happen between
VMs across compute nodes.
When agent is restarted, it re-creates its in-memory remote eid
mappings by querying VPP which results in the mac field containing
the new PAPI MACAddress object instead of string. This causes the
Instead of the VM's mac, the vhostuser interface's mac is programmed
as the remote VM's l2 arp entry in VPP. This effectively ensures that
no communication can happen between VMs running on separate compute
Before trying to add a new lisp local eid in VPP, ML2 agent
checks against the in-memory map of local eids. But when the agent
is restarted, it builds the map of local eids by querying VPP. This
results in the in-memory map to contain MACAddress object from PAPI
instead of a string. This causes the check to fail and the attempt
to create the local eid fails causing the agent to crash.
During deletion of a gpe port, the cleanup of the l2 arp entry fails.
This happens because PAPI returns the mac address as the new
MACAddress object whereas ML2 agent assumes it to be a string.
First noticed with ICMPv6, there's an 'implicit' ACL that
matches later parts fragments of fragmented packets which reflects
the first (permit *or* deny) ACL added for a specific traffic type.
The match is conducted on what's in the fragmented packet - source
and destination address, protocol - but cannot match things like ports
because fragmentation is at the IP level where ports don't exist.
What we're seeing is that the first rule for some types of traffic is
a deny, and it dictates fragmentation filtering. We change this to
ensure that there's a permit first so that all fragments are unfiltered.
We want one additional thread in Neutron for the return worker,
and we really only need one additional thread per formward worker.
When we have multiple threads (with AFTER_INIT) this seems to be
upsetting the process of port binding, particularly on router and
DHCP ports, because of the multiple almost simultaneous binding
messages that trigger in the herd of threads.
ML2 agent uses synchronous mode API calls and it does not solicit
any async notifications/events from VPP. Making the following
1. Set async_thread=False so that PAPI does not spawn the
background thread for async msg handling.
2. Remove the asynchronous event handling code.
3. Remove the threading.Lock which was required for the
asynchronous event handling thread.