Age | Commit message (Collapse) | Author | Files | Lines |
|
Change-Id: I8a6f069af4acce97fd0ee262c217af645afd476d
Signed-off-by: Hongjun Ni <hongjun.ni@intel.com>
Signed-off-by: Dave Barach <dave@barachs.net>
|
|
This change adds support for IPv6 while refactoring most of the
original plugin code in the following ways.
- Adhere to vpp style guidelines.
- Split the netlink, node, and tap processing into separate
files named with a "tap_inject" prefix which more accurately
represents the functionality.
- Implement our own tap management and rx/tx. This is to reduce
the overhead of passing packets in and out of vnet tap
devices, in favor of directly reading/writing from the tap.
- Change how nodes work. Now we have neighbor, rx, and tx nodes.
The neighbor node sends ARP replies and ICMP6 neighbor
advertisements to the arp-input and icmp6-neighbor-solicitation
nodes, respectively, before also injecting the packet to the
host, making it possible for both vpp and the host network stack
to resolve the next hop. The tx node injects packets into the
host by writing to the tap. The rx node reads packets from the
tap and sends them on its associated data plane interface.
- Simplify the CLI. Instead of creating taps specifically for
a given interface we create a tap for all of the Ethernet
interfaces with the "enable tap-inject" CLI command. The
interfaces are named with a "vpp" prefix, i.e. "vpp0". Also
add a "disable tap-inject" option.
- Provide ability to enable at configuration time with the
tap-inject { enable } stanza.
Change-Id: I6b56da606e2da1d793ce6aca222fe4eb5a4e070d
Signed-off-by: Jeff Shaw <jeffrey.b.shaw@intel.com>
|
|
Register an IP protocol handler for UDP. When a UDP packet
arrives on a tapped interface configured for UDP, the packet
is injected on the input device's respective tap.
commit f560a490c already adds support for directing multicast
packets to the tap device.
Change-Id: I2a28a123d9bf1470f87986e66f34e76a99e63f48
Signed-off-by: Jeff Shaw <jeffrey.b.shaw@intel.com>
|
|
When an interface is tapped, the tap inherits the link state of the
underlying device.
Also, the hw vector was being resized in the time between getting
the interface and when the hw_address was referenced, leading to
a segmentation fault. Resolve the issue by saving the mac
address contents on the stack before passing to other functions.
Change-Id: I4b5b31e438159a83ddfea808882503775b1fcd1a
Signed-off-by: Jeff Shaw <jeffrey.b.shaw@intel.com>
|
|
This patch introduces a method to listen to link state events.
The method invokes callback functions to set the interface
flags.
Change-Id: I284bc5dd92a38c91f093d6709fb43b6b5ae57c56
Signed-off-by: Elza Mathew <elza.mathew@intel.com>
|
|
When requested, inject IGMP and OSPF packets with a multicast
address of 224.0.0.0/24 to the respective tap.
Change-Id: I2763e3df1929d12bd7b5a68bca51f83febc63b28
Signed-off-by: Jeff Shaw <jeffrey.b.shaw@intel.com>
|
|
Previously, if one interface were configured to inject a protocol,
then all interfaces would inject the protocol. In other words, if
iface 1 were configured for arp,icmp4 and iface 2 were configured
for arp,icmp4,tcp, then iface 1 would erroneously inject tcp.
This commit fixes the above behavior such that each packet is
compared with the protocols enabled for the interface before
injecting.
Change-Id: I20477a24019f3e0209b863aca25c1253ba45d7f4
Signed-off-by: Jeff Shaw <jeffrey.b.shaw@intel.com>
|
|
The build issue has been fixed in the netlink repo. Remove
the note from the README as it is no longer relevant.
Change-Id: I3d9fe59f443b926fb83dce16655d86d88ea06be4
Signed-off-by: Jeff Shaw <jeffrey.b.shaw@intel.com>
|
|
Enabled with 'tap inject arp,icmp4,tcp from ... as ...'
Change-Id: Ibc1670a8d4b9b3c4369ced9e42df85f496f4129c
Signed-off-by: Jeff Shaw <jeffrey.b.shaw@intel.com>
|
|
Handle arp, icmp4, and classified packets in a single node
function instead of three nearly identical ones.
Change-Id: Id3752bbf2b4f5b1f9d8f98315d330dcf2124c829
Signed-off-by: Jeff Shaw <jeffrey.b.shaw@intel.com>
|
|
Change-Id: Ief5544e58f002e8d33b72dd87295c29f93345d37
Signed-off-by: Jeff Shaw <jeffrey.b.shaw@intel.com>
|