A buggy if check causes the code to attempt setting the IPv6 default
route through an IPv4 gateway causing PAPI to produce the following
error:
TypeError: object of type 'IPv4Address' has no len()
Change-Id: Ia455cb983f26f171994e45d30ac0575300fdbdb3
Closes-Bug: #1899772
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.
Change-Id: Ib6c58c46f87b705bd03c38407ad9e6b948687e8b
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.
Change-Id: I105661c532b3f9c9919c74d6f1effa156cb2f397
Remove dead function. Make mac_t and mac_str_t strong types that
require casting to and from; propagate type checking outwards.
Change-Id: If5c82665bdea849d437677b79a08bc967b9f35dd
dump_acl_info and dump_tag_info use x.next() - should be x.__next__()
or more idiomatically next(x)
Change-Id: Ic99b318900bd9cba6d4c7fcd24357151590542f2
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.
Change-Id: Ia19ac1b1e478e310737be462ba5733ebc26b16bf
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.
Change-Id: Id12c6b1ce226dd65a7fe88e0d4044c44149db3c1
Closes-Bug: #1892765
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.
Change-Id: Ib9d9a888d734ef7f8fbe23475c04ac75029014cd
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.
Change-Id: Ib90d3e3e141379ec1729dc8218e0be687b95069e
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.
Change-Id: I6dda9115f6777a2ad0876bb42370c2bb6830a640
Looks like when we created network_interface.py this call was not
properly converted from a get(), and so the network is not correctly
found.
Change-Id: If27cacbb921c6b3a1dc1241e8a19b71c4974327b
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.
Change-Id: I05310b0547248b364778409e518fc25db792ccf7
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.
Change-Id: I8a266de84e260506e3c4c5340472c0c26e2d0542
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.
Change-Id: I3935daf12c5b96fad56c46c970580582ad47f8a4
Closes-Bug: #1893766
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.
Change-Id: I0c9e0deb98072789873bea20726dfa0cc80c7b6a
Closes-Bug: #1893201
The create_vhost_user_if API assigns a random mac to the newly created
vhostuser interface so no need to supply a mac param anymore.
Change-Id: Ie0a8cae4e6870cf6dd5d33314b993942025fa155
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.
Change-Id: I786888793bb474802b0294f5b3fd73c2507ad147
Closes-Bug: #1892766
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
failure.
Change-Id: I303cdf3e51a2fc38c5cddfb03643ba6493503846
CLoses-Bug: #1892862
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
nodes.
Change-Id: Ib703ae543421b4555c9ecc6b0d52ef34bd45b6f3
Closes-Bug: #1892762
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.
Change-Id: Ib342260407100f6aa3e53a531f2130be9d4a9d83
Closes-Bug: #1892749
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.
Change-Id: I46a132fe5aa4b6505bbb3479a9ced2b38df3a46b
Closes-Bug: #1892700
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.
Change-Id: I097401d2ef91632390fab43f3e7194124af1b1a4
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.
Change-Id: I68dbd02b8a235b128779357d4bf3df26b5bf604a
ML2 agent uses synchronous mode API calls and it does not solicit
any async notifications/events from VPP. Making the following
cleanups:
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.
Change-Id: I21ace1bc4982a8e557893d3d2d5e785906d74e1d
Naveen Joy