[ovs-discuss] ovs-vswitchd and arp traffic

Haris Rotsos cr409 at cam.ac.uk
Wed May 30 20:38:05 UTC 2012


Hi all,

I am writting to this list, because I notice a strange behaviour with the
ovs-vswitch distributed with the ubuntu/debian distribution.

My confusion/problem(?) lies on the way the ovs-vswitchd handles
arptraffic. I initialize my switch as follows:

ovsdb-server /etc/openvswitch/conf.db  --remote=punix:/var/run/ovsdb-server
--detach --monitor
ovs-vswitchd  unix:/var/run/ovsdb-server --detach --monitor

ovs-vsctl --db=unix:/var/run/ovsdb-server init
ovs-vsctl --db=unix:/var/run/ovsdb-server add-br br0
ovs-vsctl --db=unix:/var/run/ovsdb-server add-port br0 eth1
ovs-vsctl --db=unix:/var/run/ovsdb-server set-controller br0 tcp:
127.0.0.1:6633
ovs-vsctl --db=unix:/var/run/ovsdb-server set-fail-mode br0 standalone

what i trying to do is to capture arp requests/response on the controller
on the interface eth0.

I am doing the following simple experiment:

$ sudo ovs-ofctl add-flow br0 arp,action=controller
$ sudo ovs-ofctl dump-flows br0 arp
NXST_FLOW reply (xid=0x4):
 cookie=0x0, duration=12.471s, table=0, n_packets=0, n_bytes=0, arp
actions=CONTROLLER:65535

$ arp -n
Address                  HWtype  HWaddress           Flags Mask
 Iface
10.242.70.1              ether   fe:ff:ff:ff:ff:ff   C
br0
$ arp -d 10.242.70.1
$ ping 10.242.70.1 -c 1
PING 10.242.70.1 (10.242.70.1) 56(84) bytes of data.

ovs-dpctl reports the aro flow is inserted in the kernel module

$ ovs-dpctl dump-flows br0
in_port(0),eth(src=72:5a:47:50:57:43,dst=ff:ff:ff:ff:ff:ff),eth_type(0x0806)
,arp(sip=10.242.71.5,tip=10.242.70.1,op=1,sha=72:5a:47:50:57:43,tha=00:00:00:00:00:00),
packets:0, bytes:0, used:never, actions:1
in_port(0),eth(src=72:5a:47:50:57:43,dst=fe:ff:ff:ff:ff:ff),eth_type(0x0800),ipv4(src=X.X.X.X,dst=X.X.X.X,proto=17,tos=0,ttl=64,frag=no),udp(src=53,dst=56375),
packets:397, bytes:40830, used:0.448s, actions:1
in_port(1),eth(src=fe:ff:ff:ff:ff:ff,dst=72:5a:47:50:57:43),eth_type(0x0800),ipv4(src=X.X.X.X,dst=X.X.X.X,proto=17,tos=0,ttl=49,frag=no),udp(src=56375,dst=53),
packets:417, bytes:42380, used:0.448s, actions:0
in_port(1),eth(src=fe:ff:ff:ff:ff:ff,dst=72:5a:47:50:57:43),eth_type(0x0806)
,arp(sip=10.242.70.1,tip=10.242.71.5,op=2,sha=fe:ff:ff:ff:ff:ff,tha=72:5a:47:50:57:43),
packets:0, bytes:0, used:never, actions:0
in_port(0),eth(src=72:5a:47:50:57:43,dst=fe:ff:ff:ff:ff:ff),eth_type(0x0800),ipv4(src=X.X.X.X,dst=X.X.X.X,proto=6,tos=0,ttl=64,frag=no),tcp(src=22,dst=36224),
packets:47, bytes:6734, used:0.000s, actions:1
in_port(1),eth(src=fe:ff:ff:ff:ff:ff,dst=72:5a:47:50:57:43),eth_type(0x0800),ipv4(src=X.X.X.X,dst=X.X.X.X,proto=6,tos=0,ttl=50,frag=no),tcp(src=36224,dst=22),
packets:86, bytes:7572, used:0.000s, actions:0

the packet is processed and pushed from the outgoing interface

$ sudo tcpdump -i eth0 -n arp
tcpdump: WARNING: eth0: no IPv4 address assigned
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes
20:21:10.716614 ARP, Request who-has 10.242.70.1 tell 10.242.71.5, length 28
20:21:10.722116 ARP, Reply 10.242.70.1 is-at fe:ff:ff:ff:ff:ff, length 28

no packet thought is received by the user-space process  of openvswitch

$ sudo ovs-ofctl dump-flows br0 arp
NXST_FLOW reply (xid=0x4):
 cookie=0x0, duration=278.503s, table=0, n_packets=0, n_bytes=0, arp
actions=CONTROLLER:65535

the arp packet is never reported on the control channel as a packet_in
message. Is there some intermediate rules in the ovs-vswitchd? why is ovs-
openflowd is deprecated? how can i disable the switch from handling
automatically the arp traffic?

thanks in advance for any pointers.

-- 
Charalampos Rotsos
PhD student
The University of Cambridge
Computer Laboratory
William Gates Building
JJ Thomson Avenue
Cambridge
CB3 0FD

Phone: +44-(0) 1223 767032
Email: cr409 at cl.cam.ac.uk

 <cr409 at cl.cam.ac.uk>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://openvswitch.org/pipermail/ovs-discuss/attachments/20120530/58b55788/attachment.html>


More information about the discuss mailing list