Thanks Ben for your quick response, it's very helpful.
By looking at the flows dumped from dpctl, I have one more question.
With the 'normal' action showed in ovs-ofctl, ovs-dpctl has below output:
If the interface 'port 8: tap6fb4e8fd-4b' in 'br-int' received gratuitous
ARP, it will send out to all the 'gre-x' ports in 'br-tun', and op
pop_vlan, how does this logistic designed(packets flood from ports in
br-int to br-tun gre ports)? How does ovs implement the MAC learning switch
when 'normal' action is set, does the ofproto-dpif module actually collect
all of these actions and executed by dpif finally as the MAC learning
switch? I thought it is the flow-based switch by going through the source
code a bit, thank you.
# ovs-vsctl show
Bridge br-tun
fail_mode: secure
Port "gre-0a05055a"
Interface "gre-0a05055a"
type: gre
options: {df_default="true", in_key=flow,
local_ip="10.5.5.85", out_key=flow, remote_ip="10.5.5.90"}
Port "gre-0a050556"
Interface "gre-0a050556"
type: gre
options: {df_default="true", in_key=flow,
local_ip="10.5.5.85", out_key=flow, remote_ip="10.5.5.86"}
Port patch-int
Interface patch-int
type: patch
options: {peer=patch-tun}
Port br-tun
Interface br-tun
type: internal
Port "gre-0a050559"
Interface "gre-0a050559"
type: gre
options: {df_default="true", in_key=flow,
local_ip="10.5.5.85", out_key=flow, remote_ip="10.5.5.89"}
Bridge br-int
fail_mode: secure
Port br-int
Interface br-int
type: internal
Port patch-tun
Interface patch-tun
type: patch
options: {peer=patch-int}
Port int-br-data
Interface int-br-data
type: patch
options: {peer=phy-br-data}
Port "tapf9952c91-f9"
tag: 1
Interface "tapf9952c91-f9"
Port "tap6fb4e8fd-4b"
tag: 2
Interface "tap6fb4e8fd-4b"
# ovs-dpctl show
system@ovs-system:
lookups: hit:2990504 missed:14495 lost:5
flows: 8
masks: hit:13953149 total:5 hit/pkt:4.64
port 0: ovs-system (internal)
port 1: br-ex (internal)
port 2: eth1
port 3: br-int (internal)
port 4: gre_sys (gre)
port 5: br-tun (internal)
port 6: br-data (internal)
port 7: tapf9952c91-f9
port 8: tap6fb4e8fd-4b
port 9: tapbfb63b1b-53
# ovs-ofctl dump-flows
in_port(8),eth(src=fa:16:3e:0e:99:89,dst=ff:ff:ff:ff:ff:ff),eth_type(0x0806),arp(sip=192.168.21.1,tip=192.168.21.1,op=1/0xff),
packets:21, bytes:882, used:4.884s,
actions:push_vlan(vid=2,pcp=0),3,set(tunnel(tun_id=0x5,src=10.5.5.85,dst=10.5.5.90,ttl=64,flags(df,key))),pop_vlan,4,set(tunnel(tun_id=0x5,src=10.5.5.85,dst=10.5.5.89,ttl=64,flags(df,key))),4,set(tunnel(tun_id=0x5,src=10.5.5.85,dst=10.5.5.86,ttl=64,flags(df,key))),4
Best Regards.
Hui.
On Wed, Feb 24, 2016 at 1:48 AM, Ben Pfaff <b...@ovn.org> wrote:
> On Tue, Feb 23, 2016 at 03:25:24PM +0800, Hui Xiang wrote:
> > Could anyone help to point out what does below output represents? Is
> there
> > any document help to refer?
>
> Generally ovs-dpctl output consists of implementation details; we don't
> document most of it.
>
> > My environment is based on OpenStack neutron.
> >
> > 1) Does the 'actions=NORMAL' in ovs-ofctl dump-flows makes ovs-dpctl
> > dump-flows output looks like a learning switch?
>
> Yes.
>
> > 2) 'arp(sip=192.168.21.1,tip=192.168.21.1)' means source_ip equals to
> > '192.168.21.1', dst_ip equals to '192.168.21.1' as well, does it make
> sense
> > for ARP request?
>
> This is a "gratuitous ARP". You can do a web search for that term, for
> more information.
>
_______________________________________________
discuss mailing list
discuss@openvswitch.org
http://openvswitch.org/mailman/listinfo/discuss
