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
