Thanks for the ack!
The FAQ entries I had in mind are about IP addresses and why you
shouldn't put them on physical ports, not about where you should put
your dummy connections (I don't think dummies are mentioned at all in
the FAQ, since they're a dev testing only feature).
Here are the ones I was thinking of:
### Q: I created a bridge and added my Ethernet port to it, using commands
like these:
ovs-vsctl add-br br0
ovs-vsctl add-port br0 eth0
and as soon as I ran the "add-port" command I lost all connectivity
through eth0. Help!
A: A physical Ethernet device that is part of an Open vSwitch bridge
should not have an IP address. If one does, then that IP address
will not be fully functional.
You can restore functionality by moving the IP address to an Open
vSwitch "internal" device, such as the network device named after
the bridge itself. For example, assuming that eth0's IP address is
192.168.128.5, you could run the commands below to fix up the
situation:
ifconfig eth0 0.0.0.0
ifconfig br0 192.168.128.5
(If your only connection to the machine running OVS is through the
IP address in question, then you would want to run all of these
commands on a single command line, or put them into a script.) If
there were any additional routes assigned to eth0, then you would
also want to use commands to adjust these routes to go through br0.
If you use DHCP to obtain an IP address, then you should kill the
DHCP client that was listening on the physical Ethernet interface
(e.g. eth0) and start one listening on the internal interface
(e.g. br0). You might still need to manually clear the IP address
from the physical interface (e.g. with "ifconfig eth0 0.0.0.0").
There is no compelling reason why Open vSwitch must work this way.
However, this is the way that the Linux kernel bridge module has
always worked, so it's a model that those accustomed to Linux
bridging are already used to. Also, the model that most people
expect is not implementable without kernel changes on all the
versions of Linux that Open vSwitch supports.
By the way, this issue is not specific to physical Ethernet
devices. It applies to all network devices except Open vSwitch
"internal" devices.
### Q: I created a tap device tap0, configured an IP address on it, and
added it to a bridge, like this:
tunctl -t tap0
ifconfig tap0 192.168.0.123
ovs-vsctl add-br br0
ovs-vsctl add-port br0 tap0
I expected that I could then use this IP address to contact other
hosts on the network, but it doesn't work. Why not?
A: The short answer is that this is a misuse of a "tap" device. Use
an "internal" device implemented by Open vSwitch, which works
differently and is designed for this use. To solve this problem
with an internal device, instead run:
ovs-vsctl add-br br0
ovs-vsctl add-port br0 int0 -- set Interface int0 type=internal
ifconfig int0 192.168.0.123
Even more simply, you can take advantage of the internal port that
every bridge has under the name of the bridge:
ovs-vsctl add-br br0
ifconfig br0 192.168.0.123
In more detail, a "tap" device is an interface between the Linux
(or *BSD) network stack and a user program that opens it as a
socket. When the "tap" device transmits a packet, it appears in
the socket opened by the userspace program. Conversely, when the
userspace program writes to the "tap" socket, the kernel TCP/IP
stack processes the packet as if it had been received by the "tap"
device.
Consider the configuration above. Given this configuration, if you
"ping" an IP address in the 192.168.0.x subnet, the Linux kernel
routing stack will transmit an ARP on the tap0 device. Open
vSwitch userspace treats "tap" devices just like any other network
device; that is, it doesn't open them as "tap" sockets. That means
that the ARP packet will simply get dropped.
You might wonder why the Open vSwitch kernel module doesn't
intercept the ARP packet and bridge it. After all, Open vSwitch
intercepts packets on other devices. The answer is that Open
vSwitch only intercepts *received* packets, but this is a packet
being transmitted. The same thing happens for all other types of
network devices, except for Open vSwitch "internal" ports. If you,
for example, add a physical Ethernet port to an OVS bridge,
configure an IP address on a physical Ethernet port, and then issue
a "ping" to an address in that subnet, the same thing happens: an
ARP gets transmitted on the physical Ethernet port and Open vSwitch
never sees it. (You should not do that, as documented at the
beginning of this section.)
It can make sense to add a "tap" device to an Open vSwitch bridge,
if some userspace program (other than Open vSwitch) has opened the
tap socket. This is the case, for example, if the "tap" device was
created by KVM (or QEMU) to simulate a virtual NIC. In such a
case, when OVS bridges a packet to the "tap" device, the kernel
forwards that packet to KVM in userspace, which passes it along to
the VM, and in the other direction, when the VM sends a packet, KVM
writes it to the "tap" socket, which causes OVS to receive it and
bridge it to the other OVS ports. Please note that in such a case
no IP address is configured on the "tap" device (there is normally
an IP address configured in the virtual NIC inside the VM, but this
is not visible to the host Linux kernel or to Open vSwitch).
There is one special case in which Open vSwitch does directly read
and write "tap" sockets. This is an implementation detail of the
Open vSwitch userspace switch, which implements its "internal"
ports as Linux (or *BSD) "tap" sockets. In such a userspace
switch, OVS receives packets sent on the "tap" device used to
implement an "internal" port by reading the associated "tap"
socket, and bridges them to the rest of the switch. In the other
direction, OVS transmits packets bridged to the "internal" port by
writing them to the "tap" socket, causing them to be processed by
the kernel TCP/IP stack as if they had been received on the "tap"
device. Users should not need to be concerned with this
implementation detail.
Open vSwitch has a network device type called "tap". This is
intended only for implementing "internal" ports in the OVS
userspace switch and should not be used otherwise. In particular,
users should not configure KVM "tap" devices as type "tap" (use
type "system", the default, instead).
On Mon, Jun 15, 2015 at 09:44:50AM -0700, Alex Wang wrote:
> Thx for your explanation, makes sense!
>
> Could you point me to the FAQ explaining this? Did not find it by
> searching key words:
> remote, conn
>
> Acked-by: Alex Wang <al...@nicira.com>
>
> On Mon, Jun 15, 2015 at 8:49 AM, Ben Pfaff <b...@nicira.com> wrote:
>
> > I think that it would be unusual to have a single interface with both an
> > IP address assigned and a connection to a remote switch. This is
> > because an IP address is normally on an internal port (most commonly the
> > port named the same as the bridge), whereas connections to remote
> > switches (which are analogous to physical ports) shouldn't have IP
> > addresses (as the FAQ points out). So while I don't think this change
> > would hurt, I don't think it's necessary and might be confusing.
> >
> > On Sun, Jun 14, 2015 at 11:25:27PM -0700, Alex Wang wrote:
> > > Want to ask, do we need to call 'dummy_packet_conn_send(&dev->conn,
> > buffer,
> > > size);' in the
> > > arp request case? Could this cause problem when there is a loop?
> > >
> > > Thanks,
> > > Alex Wang,
> > >
> > > On Sun, Jun 14, 2015 at 12:18 PM, Ben Pfaff <b...@nicira.com> wrote:
> > >
> > > > This is the only missing piece to make native tunneling work with dummy
> > > > devices for testing purposes.
> > > >
> > > > Signed-off-by: Ben Pfaff <b...@nicira.com>
> > > > ---
> > > > lib/netdev-dummy.c | 17 +++++++++++++++++
> > > > 1 file changed, 17 insertions(+)
> > > >
> > > > diff --git a/lib/netdev-dummy.c b/lib/netdev-dummy.c
> > > > index 4d1ef8a..ff65689 100644
> > > > --- a/lib/netdev-dummy.c
> > > > +++ b/lib/netdev-dummy.c
> > > > @@ -932,6 +932,23 @@ netdev_dummy_send(struct netdev *netdev, int qid
> > > > OVS_UNUSED,
> > > >
> > > > dummy_packet_conn_send(&dev->conn, buffer, size);
> > > >
> > > > + /* Reply to ARP requests for 'dev''s assigned IP address. */
> > > > + if (dev->address.s_addr) {
> > > > + struct dp_packet packet;
> > > > + struct flow flow;
> > > > +
> > > > + dp_packet_use_const(&packet, buffer, size);
> > > > + flow_extract(&packet, &flow);
> > > > + if (flow.dl_type == htons(ETH_TYPE_ARP)
> > > > + && flow.nw_proto == ARP_OP_REQUEST
> > > > + && flow.nw_dst == dev->address.s_addr) {
> > > > + struct dp_packet *reply = dp_packet_new(0);
> > > > + compose_arp(reply, ARP_OP_REPLY, dev->hwaddr,
> > flow.dl_src,
> > > > + false, flow.nw_dst, flow.nw_src);
> > > > + netdev_dummy_queue_packet(dev, reply);
> > > > + }
> > > > + }
> > > > +
> > > > if (dev->tx_pcap) {
> > > > struct dp_packet packet;
> > > >
> > > > --
> > > > 2.1.3
> > > >
> > > > _______________________________________________
> > > > dev mailing list
> > > > dev@openvswitch.org
> > > > http://openvswitch.org/mailman/listinfo/dev
> > > >
> >
_______________________________________________
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
