| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| ... | |
| |
|
|
|
|
|
|
|
|
|
| |
In my opinion, this makes better sense for the stack, because it's not
a packet or a collection of bytes, it's an array of struct mf_subvalue.
(I left it as an ofpbuf for accumulating stack entries during
translation, because the automatic reallocation and especially the stub
support there is helpful.)
Signed-off-by: Ben Pfaff <blp@ovn.org>
Acked-by: Jarno Rajahalme <jarno@ovn.org>
|
| |
|
|
|
|
|
|
|
|
| |
All of the callers of hash_words() and hash_words64() actually find it
easier to pass in the number of bytes instead of the number of 32-bit
or 64-bit words. These new functions allow the callers to be a little
simpler.
Signed-off-by: Ben Pfaff <blp@ovn.org>
Acked-by: Jarno Rajahalme <jarno@ovn.org>
|
| |
|
|
|
|
|
| |
An upcoming commit will add another kind of asynchronous message that
should be handled in the same way as packet-ins.
Signed-off-by: Ben Pfaff <blp@ovn.org>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Packet-in messages have been a bit of a mess. First, their abstraction
in the form of struct ofputil_packet_in has some fields that are used
in a clear way for incoming and outgoing packet-ins, and others
(packet_len, total_len, buffer_id) have have confusing meanings or
usage pattern depending on their direction.
Second, it's very confusing how a packet-in has both a reason (OFPR_*)
and a miss type (OFPROTO_PACKET_IN_*) and how those add up to the
actual reason that is used "on the wire" for each OpenFlow version (and
even whether the packet-in is sent at all!).
Finally, there's all kind of low-level detail randomly scattered between
connmgr, ofproto-dpif-xlate, and ofp-util.
This commit attempts to clear up some of the confusion. It simplifies
the struct ofputil_packet_in abstraction by removing the members that
didn't have a clear and consistent meaning between incoming and outgoing
packet-ins. It gets rid of OFPROTO_PACKET_IN_*, instead adding a couple
of nonstandard OFPR_* reasons that add up to what OFPROTO_PACKET_IN_*
was meant to say (in what I hope is a clearer way). And it consolidates
the tricky parts into ofp-util, where I hope it will be easier to
understand all in one place.
Signed-off-by: Ben Pfaff <blp@ovn.org>
Acked-by: Jarno Rajahalme <jarno@ovn.org>
|
| |
|
|
|
|
|
| |
An upcoming commit will use this library from ofp-util instead of ofproto.
Signed-off-by: Ben Pfaff <blp@ovn.org>
Acked-by: Jarno Rajahalme <jarno@ovn.org>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
I don't have any real evidence that these special cases make a difference
in real-world cases. The messages for the commits that add them are not
clear about the reasons for them. I seem to recall that they were only
tested with the dummy controller inside OVS, which isn't very good evidence
for real controllers. Finally, they cut across layers in nasty ways and
make it hard to better abstract packet-ins and packet buffering.
If these solve real problems then we can reconsider after some reports
come in.
Signed-off-by: Ben Pfaff <blp@ovn.org>
Acked-by: Jarno Rajahalme <jarno@ovn.org>
|
| |
|
|
|
|
|
|
|
|
| |
This isn't used yet but it will be in future commits.
This also looks forward to supporting Open vSwitch extensions to OAM_*,
which will be coming up soon.
Signed-off-by: Ben Pfaff <blp@ovn.org>
Acked-by: Jarno Rajahalme <jarno@ovn.org>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
The OF1.0 through OF1.3 "set async config" set the whole configuration,
OF1.4+ only update parts of it piecemeal, but the decoding function always
set the whole configuration. This commit fixes the problem by changing the
interface to require the caller to provide an initial state. (It would
be possible to simply make it mutate existing state in-place, but that
interface seems a little more error-prone.)
Found by inspection.
Signed-off-by: Ben Pfaff <blp@ovn.org>
Acked-by: Jarno Rajahalme <jarno@ovn.org>
|
| |
|
|
|
|
|
| |
This seems a little better than a pair of bare arrays.
Signed-off-by: Ben Pfaff <blp@ovn.org>
Acked-by: Jarno Rajahalme <jarno@ovn.org>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
OpenFlow 1.0 through 1.3 have a message OFPT_QUEUE_GET_CONFIG_REQUEST and
its corresponding reply, for fetching a description of the queues
configured on a given port. OpenFlow 1.4 changes this message to a
multipart message OFPMP_QUEUE_DESC, which Open vSwitch has not until now
implemented. This commit adds an implemntation of that message. Because
the message is a replacement for the former one, this commit implements it
using the same ofp-util functions as the former message, so that the client
code doesn't have to distinguish a difference between versions.
The ovs-ofctl command queue-get-config was previously undocumented (due
only to an oversight). This commit corrects that and documents the new
feature available with OpenFlow 1.4.
Signed-off-by: Ben Pfaff <blp@ovn.org>
Acked-by: Jarno Rajahalme <jarno@ovn.org>
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
This call to ofpbuf_trim() comes from a time when the packets passed to
pinsched came directly from a dpif. For some time now that's no longer
true--now they are messages generated by ofputil_encode_packet_in(), which
generally are well sized and do not benefit from trimming.
This is not a bug fix--the code is equally correct either way, it's only
the rationale for trimming that's obsolete.
Signed-off-by: Ben Pfaff <blp@ovn.org>
Acked-by: Jarno Rajahalme <jarno@ovn.org>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In handle_group_mod() cases where adding a group failed, nothing freed the
list of buckets, causing a leak. The same was true in every case of
modifying a group. This commit fixes the problem by changing add_group()
to never steal or free the buckets (modify_group() already acted this way)
and then making handle_group_mod() always free the buckets when it's done.
This approach might at first raise objections, because it makes add_group()
copy the buckets instead of just take the existing ones. But it actually
fixes a worse problem too: when OF1.4+ REQUESTFORWARD is enabled, the
group_mod is reused for the request forwarding. Until now, for a group_mod
that adds a new group and that has some buckets, the previous stealing of
buckets in add_group() meant that the group_mod's buckets were no longer
valid; in practice, the list of buckets became linked in a way that
iteration never terminated, which caused memory to be exhausted while
composing the requestforward message. By making add_group() no longer
modify the group_mod, we also fix this problem.
The requestforward test in the testsuite did not find the latter problem
because it only added a group without any buckets. This commit also
updates the testsuite to include a bucket in its group_mod, which would
have found the problem.
Found by pain and suffering.
Signed-off-by: Ben Pfaff <blp@ovn.org>
Acked-by: Jarno Rajahalme <jarno@ovn.org>
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
There is no need to set the mask on the outer header IP TTL [1]. The only requirement
is that the TTL will be non-zero. Clear the mask in tnl_wc_init().
[1] OVS VXLAN decap rule has full match on TTL for the outer headers?
http://www.spinics.net/lists/netdev/msg351961.html
Cc: Jesse Gross <jesse@kernel.org>
Cc: Joe Stringer <joe@ovn.org>
Signed-off-by: Haggai Eran <haggaie@mellanox.com>
Signed-off-by: Jesse Gross <jesse@kernel.org>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The print statement from Python 2 is a function in Python 3. Enable
print function support for Python 2 and convert print statements to
function calls.
Enable the H233 flake8 warning. If the hacking plugin is installed,
this will generate warnings for print statement usage not compatible
with Python 3.
H233 Python 3.x incompatible use of print operator
Signed-off-by: Russell Bryant <russell@ovn.org>
Acked-by: Ben Pfaff <blp@ovn.org>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Python 3 dropped exception handlers of the deprecated form:
except Exception, e:
You must use the newer syntax of:
except Exception as e:
This patch also enables a flake8 warning for this.
H231 Python 3.x incompatible 'except x,y:' construct
Signed-off-by: Russell Bryant <russell@ovn.org>
Acked-by: Ben Pfaff <blp@ovn.org>
|
| |
|
|
|
|
|
|
| |
Add a series of comments to make it more clear what's happening for
individual ukeys being handled during revalidator dump/sweep cycle.
Signed-off-by: Joe Stringer <joe@ovn.org>
Acked-by: Jarno Rajahalme <jarno@ovn.org>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Broadly, there are two cases that are handled during revalidator_sweep__:
- Ukeys which had their corresponding datapath flows deleted during the
most recent dump phase need to be deleted.
- If a flow for a ukey still exists in the datapath, the flow may need
to be removed or updated. This depends on a variety of factors such as
whether the datapath is being flushed, whether individual flows were
recently dumped, and whether those flows are valid for the current
revalidation generation.
Previously, the logic was written such that the first of these cases
would be handled under the "UKEY_KEEP" case to ensure that
revalidator_sweep__() will not attempt to delete flows that already
exist. In this case, ukey->flow_exists would be false, which would
trigger ukey cleanup.
While correct, this is misleading and difficult to follow. Since commit
83b03fe05e7a ("ofproto-dpif-upcall: Avoid double-delete of ukeys."),
this logic is no longer required to prevent double-deletion of such
flows, so we can now make this codepath more straightforward.
Signed-off-by: Joe Stringer <joe@ovn.org>
Co-authored-by: Jarno Rajahalme <jarno@ovn.org>
Acked-by: Jarno Rajahalme <jarno@ovn.org>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
If revalidation returns the result UKEY_DELETE, then both the ukey and
its corresponding flow should be deleted. However, if revalidation
returns UKEY_MODIFY, the ukey itself should be modified in-place and
should not be deleted.
Fix this by only applying the ukey deletion to ukeys whose datapath
operations delete a flow.
This may fix statistics accounting issues in rare cases involving
OpenFlow rule modification where actions are updated but flows remain
the same.
Found by inspection.
Signed-off-by: Joe Stringer <joe@ovn.org>
Acked-by: Jarno Rajahalme <jarno@ovn.org>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The OFPT_SET_CONFIG and OFPT_GET_CONFIG_REPLY messages, which have the
same format, have a 'flags' field in which OpenFlow defines some bits,
which change somewhat from one version to another, and does not define
others. Until now, Open vSwitch has not abstracted these messages at all
and has ignored the bits that OpenFlow leaves undefined. This commit
abstracts the messages in the same way as other OpenFlow messages and
validates in OFPT_SET_CONFIG messages that the undefined bits are set to
zero.
OpenFlow 1.1 and 1.2, but not OpenFlow 1.0, define a flag named
OFPC_INVALID_TTL_TO_CONTROLLER. Open vSwitch has until now also
implemented this as an extension to OpenFlow 1.0, and this commit retains
that extension.
Reported-by: Manpreet Singh <er.manpreet25@gmail.com>
Signed-off-by: Ben Pfaff <blp@ovn.org>
Acked-by: Andy Zhou <azhou@ovn.org>
|
| |
|
|
|
|
|
|
|
| |
I was not previously aware that this feature was missing.
Reported-by: Minoru TAKAHASHI <takahashi.minoru7@gmail.com>
Reported-at: http://openvswitch.org/pipermail/discuss/2015-October/019229.html
Signed-off-by: Ben Pfaff <blp@ovn.org>
Acked-by: Andy Zhou <azhou@ovn.org>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
revalidate_sweep__() has two cases where it calls ukey_delete() to
remove a ukey from the umap via cmap_remove(). The first case is a direct
call to ukey_delete(), when !flow_exists. The second case is an indirect
call via push_ukey_ops(), when result != UKEY_KEEP. If both of these
conditions are simultaneously true, however, the code would call
ukey_delete() twice, causing an assertion failure in the second call. This
commit fixes the problem by eliminating one of the calls.
The version tested by Ben Warren differs from this version, see:
http://openvswitch.org/pipermail/dev/2016-January/064117.html
Reported-by: Keith Holleman <keith.holleman@gmail.com>
Reported-at: http://openvswitch.org/pipermail/discuss/2015-December/019772.html
CC: Joe Stringer <joe@ovn.org>
VMware-BZ: #1579057
Signed-off-by: Ben Pfaff <blp@ovn.org>
Tested-by: Ben Warren <ben@skyportsystems.com>
|
| |
|
|
|
|
|
|
|
|
|
| |
recirc_state_clone() copies the stack and actions and nothing ever freed
them.
CC: Jarno Rajahalme <jarno@ovn.org>
CC: Andy Zhou <azhou@ovn.org>
Reported-by: William Tu <u9012063@gmail.com>
Reported-at: http://openvswitch.org/pipermail/dev/2016-January/064040.html
Signed-off-by: Ben Pfaff <blp@ovn.org>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch resolves the following warnings from flake8:
E111 indentation is not a multiple of four
E112 expected an indented block
E113 unexpected indentation
It's critical to have correct indentation in Python code, so it seemed
worth enabling these warnings.
Signed-off-by: Russell Bryant <russell@ovn.org>
Acked-by: Ben Pfaff <blp@ovn.org>
|
| |
|
|
|
|
|
|
|
|
| |
Resolve pep8 errors E302 and E303:
E302 expected 2 blank lines, found 1
E303 too many blank lines (3)
Signed-off-by: Russell Bryant <russell@ovn.org>
Acked-by: Ben Pfaff <blp@ovn.org>
|
| |
|
|
|
|
|
|
|
|
|
|
| |
If flake8 is installed, run it at build time. Similar to most Makefile
targets, run it once and then only run again if the files change.
flake8 is set to ignore all error and warning types that currently occur.
Future patches will remove items from the ignore list as they are
resolved.
Signed-off-by: Russell Bryant <russell@ovn.org>
Acked-by: Ben Pfaff <blp@ovn.org>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Until now, composing a fixed-length action with ofpact_put_<NAME>() failed
to append any padding required after the action. This commit changes that
so that these calls now add padding. This meant that the function
ofpact_pad(), which was until now required in various unintuitive places,
is no longer required, and removes it.
Variable-length actions still require calling ofpact_update_len() after
composition. I don't see a way to avoid that.
Signed-off-by: Ben Pfaff <blp@ovn.org>
Acked-by: Russell Bryant <russell@ovn.org>
|
| |
|
|
|
|
|
|
|
|
|
|
| |
A few bugs have been fixed lately that were related to struct
ofputil_flow_mod not being fully initialized in a few places. This commit
changes several pieces of code from using individual assignments to fields
in struct ofputil_flow_mod, to using whole initializers or assignments to
a whole struct. This should help prevent similar problems in the future.
CC: Ilya Maximets <i.maximets@samsung.com>
Signed-off-by: Ben Pfaff <blp@ovn.org>
Acked-by: Russell Bryant <russell@ovn.org>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
replace_rule_finish() makes decision using uninitialized
for intrenal flow fm->delete_reason.
Reported by valgrind for test cases 886, 942 and 943.
Conditional jump or move depends on uninitialised value(s)
at rule_insert (ofproto-dpif.c:4134)
by replace_rule_finish (ofproto.c:4831)
by add_flow_finish (ofproto.c:4661)
by modify_flows_finish (ofproto.c:4994)
by ofproto_flow_mod_finish (ofproto.c:6821)
by handle_flow_mod__ (ofproto.c:5323)
by ofproto_dpif_add_internal_flow (ofproto-dpif.c:5680)
by add_internal_miss_flow (ofproto-dpif.c:1385)
by add_internal_flows (ofproto-dpif.c:1412)
by construct (ofproto-dpif.c:1367)
by ofproto_create (ofproto.c:577)
by bridge_reconfigure (bridge.c:633)
by bridge_run (bridge.c:2975)
by main (ovs-vswitchd.c:120)
Uninitialised value was created by a stack allocation
at ofproto_dpif_add_internal_flow (ofproto-dpif.c:5658)
Signed-off-by: Ilya Maximets <i.maximets@samsung.com>
Signed-off-by: Ben Pfaff <blp@ovn.org>
|
| |
|
|
|
|
|
|
|
|
| |
When a group is deleted, all flows which include a Group action with the ID
of the deleted group should be removed. Until now, only flows in table 0
were removed. This fixes the problem.
Signed-off-by: Zoltán Balogh <zoltan.balogh@ericsson.com>
[blp@ovn.org added a test]
Signed-off-by: Ben Pfaff <blp@ovn.org>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch renames the command name related with geneve-map to a more
generic name as following:
add-geneve-map -> add-tlv-map
del-geneve-map -> del-tlv-map
dump-geneve-map -> dump-tlv-map
It also renames the Geneve_table to tlv_table.
By doing this renaming, the NSH variable context header (the same TLV
format as Geneve) or other protocol can reuse the field tun_metadata<N>
in the future.
Signed-off-by: Mengke Liu <mengke.liu@intel.com>
Signed-off-by: Ricky Li <ricky.li@intel.com>
Signed-off-by: Jesse Gross <jesse@kernel.org>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In the ODP context an empty mask netlink attribute usually means that
the flow should be an exact match.
odp_flow_key_to_mask{,_udpif}() instead return a struct flow_wildcards
with matches only on recirc_id and vlan_tci.
A more appropriate behavior is to handle a missing (zero length) netlink
mask specially (like we do in userspace and Linux datapath) and create
an exact match flow_wildcards from the original flow.
This fixes a bug in revalidate_ukey(): every flow created with
megaflows disabled would be revalidated away, because the mask would
seem too generic. (Another possible fix would be to handle the special
case of a missing mask in revalidate_ukey(), but this seems a more
generic solution).
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
If there's no actual packet (e.g. during revalidation),
execute_controller_action() exits right away, without calling
xlate_commit_actions().
xlate_commit_actions() might have an influence on slow_path reason
(which is included in the generated ODP actions), meaning that the
revalidation will not generate the same actions than the original
translation.
Fix the problem by making execute_controller_action() call
xlate_commit_actions() even without a packet.
|
| |
|
|
|
|
|
|
|
| |
Fixes hang of 'ovs-appctl ofproto/tnl-push-pop' when an invalid
argument passed.
Signed-off-by: Ilya Maximets <i.maximets@samsung.com>
Acked-by: Thadeu Lima de Souza Cascardo <cascardo@redhat.com>
Signed-off-by: Ben Pfaff <blp@ovn.org>
|
| |
|
|
|
|
|
|
|
|
| |
The NAT validation is similar (and based on) the existing conntrack
validation: when a dpif backer is created, we try to install a flow with
the ct_state NAT bits set. If the flow setup fails we assume that the
backer doesn't support NAT and we reject OpenFlow flows with a NAT
action or a match on the ct_state NAT bits.
Signed-off-by: Daniele Di Proietto <diproiettod@vmware.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
seq values are 64-bit, and storing them to a 32-bit variable causes
the stored value never to match actual seq value after the seq value
gets big enough.
This is a likely cause of OVS main thread using 100% CPU in a system
using bonds after some runtime.
VMware-BZ: #1564993
Reported-by: Hiram Bayless <hbayless@vmware.com>
Signed-off-by: Jarno Rajahalme <jarno@ovn.org>
Acked-by: Joe Stringer <joe@ovn.org>
Acked-by: Ben Pfaff <blp@ovn.org>
|
| |
|
|
|
|
|
|
|
| |
When doing push/pop and building tunnel header, do IPv6 route lookups and send
Neighbor Solicitations if needed.
Signed-off-by: Thadeu Lima de Souza Cascardo <cascardo@redhat.com>
Cc: Flavio Leitner <fbl@sysclose.org>
Signed-off-by: Ben Pfaff <blp@ovn.org>
|
| |
|
|
|
|
|
| |
This includes VXLAN, GRE and Geneve.
Signed-off-by: Thadeu Lima de Souza Cascardo <cascardo@redhat.com>
Signed-off-by: Ben Pfaff <blp@ovn.org>
|
| |
|
|
|
|
|
| |
This allows code to be written more naturally in some cases.
Signed-off-by: Ben Pfaff <blp@ovn.org>
Acked-by: Thadeu Lima de Souza Cascardo <cascardo@redhat.com>
|
| |
|
|
|
|
|
|
|
| |
Disallow installing rules that execute ct() if conntrack is unsupported
in the datapath.
Reported-by: Ravindra Kenchappa <ravindra.kenchappa@hpe.com>
Signed-off-by: Joe Stringer <joestringer@nicira.com>
Acked-by: Jarno Rajahalme <jarno@ovn.org>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The patch is to skip BFD packets in ipfix.
Bidirectional Forwarding Detection (BFD) packets are for monitoring
the tunnel link status and consumed by ovs itself, no need to sample
them.
Refer to IETF RFC 5881, BFD control packets are the UDP packets with
destination port 3784 and BFD echo packets are the UDP packets with dst
destination port 3785.
Ipfix will skip both BFD control packets and BFD echo packets.
Signed-off-by: Wenyu Zhang <wenyuz@vmware.com>
[blp@ovn.org added check for IP]
Signed-off-by: Ben Pfaff <blp@ovn.org>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Typically the datapath will support all available features, so check
that first before attempting to retrieve various values out of a
minimask as the latter doesn't need to be checked if all fields are
supported.
ct_state is an exception, because support for the bits in this field is
not binary; only some bits are defined so far, so they must still be
checked against the current known supported bits.
Suggested-by: Jarno Rajahalme <jrajahalme@nicira.com>
Signed-off-by: Joe Stringer <joestringer@nicira.com>
Acked-by: Jarno Rajahalme <jarno@ovn.org>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When inserting rules that match on connection tracking fields, datapath
support must be checked before allowing or denying the rule insertion.
Previously we only disallowed flows that had non-zero values for the
ct_* field, but allowed non-zero masks. This meant that, eg:
ct_state=-trk,...
Would be allowed, while
ct_state=+trk,...
Would be disallowed, due to lack of datapath support.
Fix this by performing the check on masks instead of the flows.
Reported-by: Ravindra Kenchappa <ravindra.kenchappa@hpe.com>
Signed-off-by: Joe Stringer <joestringer@nicira.com>
Acked-by: Jarno Rajahalme <jarno@ovn.org>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
If only half of a ct_label is present in a miniflow/minimask (eg, only
matching on one specific bit), then rule_check() would allow the flow
even if ct_label was unsupported, because it required both 64-bit fields
that comprise the ct_label to be present in the miniflow before
performing the check.
Fix this by populating the stack copy of the label directly from the
miniflow fields if available (or zero each 64-bit word if unavailable).
Suggested-by: Jarno Rajahalme <jrajahalme@nicira.com>
Signed-off-by: Joe Stringer <joestringer@nicira.com>
Acked-by: Jarno Rajahalme <jarno@ovn.org>
|
| |
|
|
|
|
|
|
|
|
| |
This patch adds support for Openflow1.4 error codes for set-async-config.
In this patch, a new error type, OFPET_ASYNC_CONFIG_FAILED is introduced
that enables the switch to properly inform the controller when controller
tries to set invalid mask or unsupported configuration.
Signed-off-by: Ambika Arora <ambika.arora@tcs.com>
Signed-off-by: Ben Pfaff <blp@ovn.org>
|
| |
|
|
|
|
|
| |
Use IPv4-mapped address and replace tnl_arp_lookup with tnl_neigh_lookup.
Signed-off-by: Thadeu Lima de Souza Cascardo <cascardo@redhat.com>
Signed-off-by: Ben Pfaff <blp@ovn.org>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Note that because there's been no prerequisite on the outer protocol,
we cannot add it now. Instead, treat the ipv4 and ipv6 dst fields in the way
that either both are null, or at most one of them is non-null.
[cascardo: abstract testing either dst with flow_tnl_dst_is_set]
cascardo: using IPv4-mapped address is an exercise for the future, since this
would require special handling of MFF_TUN_SRC and MFF_TUN_DST and OpenFlow
messages.
Signed-off-by: Jiri Benc <jbenc@redhat.com>
Signed-off-by: Thadeu Lima de Souza Cascardo <cascardo@redhat.com>
Co-authored-by: Thadeu Lima de Souza Cascardo <cascardo@redhat.com>
Signed-off-by: Ben Pfaff <blp@ovn.org>
|
| |
|
|
|
|
|
|
|
|
|
| |
Since we don't distinguish between IPv4 and IPv6 lookups, consolidate ARP
and ND cache into neighbor cache. Other references to ARP related to the
ARP cache but that are not really about ARP have been renamed as well.
tnl_arp_lookup is kept for lookups using IPv4 instead of IPv4-mapped
addresses, but that is going to be removed in a later patch.
Signed-off-by: Thadeu Lima de Souza Cascardo <cascardo@redhat.com>
Signed-off-by: Ben Pfaff <blp@ovn.org>
|
| |
|
|
|
|
|
|
|
| |
orig_tunnel_ip_dst is replaced by orig_tunnel_ipv6_dst and represents IPv4
addresses as IPv4-mapped IPv6 addresses. Since this is only used in
ofproto-dpif-xlate, this change is well contained.
Signed-off-by: Thadeu Lima de Souza Cascardo <cascardo@redhat.com>
Signed-off-by: Ben Pfaff <blp@ovn.org>
|
| |
|
|
|
|
|
|
|
| |
Allow configuration of IPv6 tunnel endpoints.
Signed-off-by: Jiri Benc <jbenc@redhat.com>
Co-authored-by: Thadeu Lima de Souza Cascardo <cascardo@redhat.com>
Signed-off-by: Thadeu Lima de Souza Cascardo <cascardo@redhat.com>
Signed-off-by: Ben Pfaff <blp@ovn.org>
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
This patch adds support for vacancy events in table-desc.
ovs-ofctl -O OpenFlow14 dump-tables-desc <switch>
-This command is enhanced to display the Vacancy Event configuration
of the tables on a <switch>, which is set using the mod-table command.
Signed-off-by: Saloni Jain <saloni.jain@tcs.com>
Co-authored-by: Hiteshi Kalra <hiteshi.kalra@tcs.com>
Signed-off-by: Hiteshi Kalra <hiteshi.kalra@tcs.com>
Signed-off-by: Ben Pfaff <blp@ovn.org>
|
