Re: [ovs-discuss] ovs-vswitchd and arp traffic
On 30 May 2012 21:42, Ben Pfaff wrote:
> On Wed, May 30, 2012 at 09:38:05PM +0100, Haris Rotsos wrote:
> > 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
>
fair point. I am using a custom start command so that if something goes
wrong I will still have access to the vm if I simply restart it and reset
all networking.
>
> Why do you go to this trouble of starting ovsdb-server and
> ovs-vswitchd yourself? The Debian packaging should do this for you.
> And then you would not need to say "--db=unix:/var/run/ovsdb-server"
> as you do, below.
>
> > 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.
>
> It seems likely that you are getting caught by in-band control. I
> recommend setting up your controller in "out-of-band" mode.
>
yeap that worked.
Just for the records, in order to set this you need first to run
$ sudo ovs-vsctl list controller
_uuid : 89578a45-9d03-47f2-9cc2-b3e5fea71896
connection_mode : out-of-band
controller_burst_limit: []
controller_rate_limit: []
external_ids: {}
inactivity_probe: []
is_connected: true
local_gateway : []
local_ip: []
local_netmask : []
max_backoff : []
role: other
status : {last_error="Connection refused",
sec_since_connect="394", sec_since_disconnect="417", state=ACTIVE}
target : "tcp:127.0.0.1:6633"
then use the uuid of the controller and run
$ sudo ovs-vsctl set controller 89578a45-9d03-47f2-9cc2-b3e5fea71896
connection_mode="out-of-band"
thanks forthe quick reply.
--
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: cr...@cl.cam.ac.uk
___
discuss mailing list
discuss@openvswitch.org
http://openvswitch.org/mailman/listinfo/discuss
[ovs-discuss] ovs-vswitchd and arp traffic
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: cr...@cl.cam.ac.uk ___ discuss mailing list discuss@openvswitch.org http://openvswitch.org/mailman/listinfo/discuss
Re: [ovs-discuss] Fwd: lldp support?
On 9 July 2011 17:13, Ben Pfaff wrote: > On Sat, Jul 09, 2011 at 09:13:48AM +0100, Haris Rotsos wrote: > > Currently I am trying to use ovs with the topology module of nox in order > to > > use the lldp protocol to discover devices connected to the switch. I was > > wondering if this is supported in the code of openvswitch . Is it > possible > > to enable such a protocol in openvswitch code and force it send updates? > I > > guess that using openlldp daemon could solve my problem, but I was > wondering > > if this is supported by the code of the switch too. > > OVS doesn't have built-in LLDP support. > I tried lldpd and seems to work sufficiently in paraller with openvswitch. I think that this solves my problem. > > The second problem I noticed is that the nox packet send to the switch is > > not recognized by the switch. on every packet out message I see on the > log > > of the ovs-vswitchd > > > > Jul 09 09:07:39|01304|dpif|WARN|system@br0: execute 1 failed (Invalid > > argument) on packet 00:04:23:b1:57:24 > 01:23:20:00:00:01, ethertype > Unknown > > (0x88cc), length 34: > > 0x: 0207 0400 0423 b157 2404 0302 0001 0602 > .#.W$... > > 0x0010: 0078 > > That's a strange message. What version of OVS are you using? > I am using the git master branch of the code. -- 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: cr...@cl.cam.ac.uk ___ discuss mailing list discuss@openvswitch.org http://openvswitch.org/mailman/listinfo/discuss
[ovs-discuss] Fwd: lldp support?
Hello all, Currently I am trying to use ovs with the topology module of nox in order to use the lldp protocol to discover devices connected to the switch. I was wondering if this is supported in the code of openvswitch . Is it possible to enable such a protocol in openvswitch code and force it send updates? I guess that using openlldp daemon could solve my problem, but I was wondering if this is supported by the code of the switch too. The second problem I noticed is that the nox packet send to the switch is not recognized by the switch. on every packet out message I see on the log of the ovs-vswitchd Jul 09 09:07:39|01304|dpif|WARN|system@br0: execute 1 failed (Invalid argument) on packet 00:04:23:b1:57:24 > 01:23:20:00:00:01, ethertype Unknown (0x88cc), length 34: 0x: 0207 0400 0423 b157 2404 0302 0001 0602 .#.W$... 0x0010: 0078 Any ideas how i could solve this? -- 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: cr...@cl.cam.ac.uk ___ discuss mailing list discuss@openvswitch.org http://openvswitch.org/mailman/listinfo/discuss
[ovs-discuss] Fwd: matching filed on stats_request
Hi everyone,
I have a minor problem trying to implement a stats polling mechanism from an
openflow controller. I am trying to get flow_stats and aggregate flow stats
from an openvswitch instance. As an example fo the behaviour, I have
installed the following flows in the flow table:
cookie=0x0, duration=272.966s, table_id=0, n_packets=190836,
n_bytes=28625400,
idle_timeout=1200,priority=65535,udp,in_port=1,vlan_tci=0x/0x,dl_src=00:04:23:b4:74:95,dl_dst=00:1e:68:9a:c5:75,nw_src=10.1.1.1,nw_dst=192.168.2.2,nw_tos=0,tp_src=8080,tp_dst=8080
actions=output:2
cookie=0x0, duration=272.966s, table_id=0, n_packets=190831,
n_bytes=28624650,
idle_timeout=1200,priority=65535,udp,in_port=1,vlan_tci=0x/0x,dl_src=00:04:23:b4:74:95,dl_dst=00:1e:68:9a:c5:75,nw_src=10.1.1.1,nw_dst=192.168.2.4,nw_tos=0,tp_src=8080,tp_dst=8080
actions=output:2
cookie=0x0, duration=272.966s, table_id=0, n_packets=190046,
n_bytes=28506900,
idle_timeout=1200,priority=65535,udp,in_port=1,vlan_tci=0x/0x,dl_src=00:04:23:b4:74:95,dl_dst=00:1e:68:9a:c5:75,nw_src=10.1.1.1,nw_dst=192.168.2.1,nw_tos=0,tp_src=8080,tp_dst=8080
actions=output:2
cookie=0x0, duration=272.966s, table_id=0, n_packets=190872,
n_bytes=28630800,
idle_timeout=1200,priority=65535,udp,in_port=1,vlan_tci=0x/0x,dl_src=00:04:23:b4:74:95,dl_dst=00:1e:68:9a:c5:75,nw_src=10.1.1.1,nw_dst=192.168.2.5,nw_tos=0,tp_src=8080,tp_dst=8080
actions=output:2
cookie=0x0, duration=272.966s, table_id=0, n_packets=190085,
n_bytes=28512750,
idle_timeout=1200,priority=65535,udp,in_port=1,vlan_tci=0x/0x,dl_src=00:04:23:b4:74:95,dl_dst=00:1e:68:9a:c5:75,nw_src=10.1.1.1,nw_dst=192.168.2.6,nw_tos=0,tp_src=8080,tp_dst=8080
actions=output:2
cookie=0x0, duration=272.966s, table_id=0, n_packets=190512,
n_bytes=28576800,
idle_timeout=1200,priority=65535,udp,in_port=1,vlan_tci=0x/0x,dl_src=00:04:23:b4:74:95,dl_dst=00:1e:68:9a:c5:75,nw_src=10.1.1.1,nw_dst=192.168.2.7,nw_tos=0,tp_src=8080,tp_dst=8080
actions=output:2
cookie=0x0, duration=272.966s, table_id=0, n_packets=189674,
n_bytes=28451100,
idle_timeout=1200,priority=65535,udp,in_port=1,vlan_tci=0x/0x,dl_src=00:04:23:b4:74:95,dl_dst=00:1e:68:9a:c5:75,nw_src=10.1.1.1,nw_dst=192.168.2.3,nw_tos=0,tp_src=8080,tp_dst=8080
actions=output:2
cookie=0x0, duration=272.966s, table_id=0, n_packets=190550,
n_bytes=28582500,
idle_timeout=1200,priority=65535,udp,in_port=1,vlan_tci=0x/0x,dl_src=00:04:23:b4:74:95,dl_dst=00:1e:68:9a:c5:75,nw_src=10.1.1.1,nw_dst=192.168.2.8,nw_tos=0,tp_src=8080,tp_dst=8080
actions=output:2
the flows as it can be seen differ only on the destination address and have
sequential dest ip addresses.
I am sending an ofp_flow_stats_request with the following format:
Frame 1 (122 bytes on wire, 122 bytes captured)
Ethernet II, Src: Intel_b4:74:94 (00:04:23:b4:74:94), Dst: Intel_b2:b6:cc
(00:04:23:b2:b6:cc)
Internet Protocol, Src: 10.1.0.1 (10.1.0.1), Dst: 10.1.0.2 (10.1.0.2)
Transmission Control Protocol, Src Port: 6633 (6633), Dst Port: 42201
(42201), Seq: 1, Ack: 1, Len: 56
OpenFlow Protocol
Header
Version: 0x01
Type: Stats Request (CSM) (16)
Length: 56
Transaction ID: 0
Stats Request
Type: Individual flow statistics (0x0001)
Flags: 0x
Flow Stats Request
Match
Match Types
...1 = Input port:
Wildcard (1)
..1. = VLAN ID:
Wildcard (1)
.1.. = Ethernet Src
Addr: Wildcard (1)
1... = Ethernet Dst
Addr: Wildcard (1)
...1 = Ethernet
Type: Wildcard (1)
..1. = IP Protocol:
Wildcard (1)
.1.. = TCP/UDP Src
Port: Wildcard (1)
1... = TCP/UDP Dst
Port: Wildcard (1)
..10 = IP Src Addr
Mask: /0 (32)
0111 11.. = IP Dst Addr
Mask: /1 (31)
...1 = VLAN
priority: Wildcard (1)
..1. = IPv4 DSCP:
Wildcard (1)
IP Src Addr: 0.0.0.0 (0.0.0.0)
IP Dst Addr: 192.168.2.0 (192.168.2.0)
Table ID: All Tables
Out Port: None (not associated with a physical port)
but I receive the following reply:
Frame 2 (846 bytes on wire, 846 bytes captured)
Ethernet II, Src: Intel_b2:b6:cc (00:04:23:b2:b6:cc), Dst: Intel_b4:74:94
(00:04:23:b4:74:94)
Internet Protocol, Src: 10.1.0.2 (10.1.0.2), Dst: 10.1.0.1 (10.1.0.1)
Transmission Control Protocol, Src Port: 42201 (42201), Dst Port: 6633
(6633), Seq: 1, Ack: 57,
Re: [ovs-discuss] Fwd: question regarding openflow flow table
Dear Ben, thanks a lot for your quick answer. Following your answer, the insertion of exact match rules in the classifier table doesn't have an impact on the switching performance and is the default behaviour expected from openvswitch? The linear search mode for the classifier table, was only a personal impression. On 16 December 2010 16:05, Ben Pfaff wrote: > On Thu, Dec 16, 2010 at 8:00 AM, Haris Rotsos wrote: >> I noticed using ovs-ofctl that openvswitch has 2 tables : hash with >> wildcard 0x00 and classifier with wildcard 0x3f. My >> understanding is that the first table is used for exact matches flows, >> while the second is used for wilcarded flows. When I insert the >> wildcard flows in the switch, I notice that they are placed in the >> classifier table. Doesn't this has a performance penalty? The has hash >> table uses a hash function with seek time constant, while the >> classifier uses a linear lookup with linear seek time depending on the >> number of flows in the table. > > If you're using Open vSwitch, then you are wrong that the classifier > uses linear lookup. It does not. > > If you have large numbers of wildcarded flows, recent versions of Open > vSwitch (from the Git repository) will have better performance than > older ones, because the classifier's performance has been improved. > They also report only a single table, but this is really not relevant > to performance. > -- 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: cr...@cl.cam.ac.uk ___ discuss mailing list discuss@openvswitch.org http://openvswitch.org/mailman/listinfo/discuss_openvswitch.org
[ovs-discuss] Fwd: question regarding openflow flow table
Hello everybody, I am currently using openvswitch as an openflow switch and nox as the controller, within which which I am writting a test module in python. The module inserts a few exact match flows in the openflow switch. I noticed using ovs-ofctl that openvswitch has 2 tables : hash with wildcard 0x00 and classifier with wildcard 0x3f. My understanding is that the first table is used for exact matches flows, while the second is used for wilcarded flows. When I insert the wildcard flows in the switch, I notice that they are placed in the classifier table. Doesn't this has a performance penalty? The has hash table uses a hash function with seek time constant, while the classifier uses a linear lookup with linear seek time depending on the number of flows in the table. -- 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: cr...@cl.cam.ac.uk ___ discuss mailing list discuss@openvswitch.org http://openvswitch.org/mailman/listinfo/discuss_openvswitch.org
Re: [ovs-discuss] openvswitch as openflow switch
You are right. After I insert a rule the host at eth1 is able to contact the computer hosting the switch. thank you very much for your help. On 24 November 2010 20:24, Ben Pfaff wrote: > If there is a controller but no flows, then no traffic will go through > the switch. You need to set up some flows for traffic to pass. > > On Wed, Nov 24, 2010 at 08:15:57PM +, Haris Rotsos wrote: >> no currently eth0 and eth1 have no ip. >> >> At the current point I am not interested to do switching between the 2 >> interfaces. I am only interested to reach the computer hosting the >> switch. In order to do that, do I need to setup a flow ? >> >> On 24 November 2010 20:10, Ben Pfaff wrote: >> > On Wed, Nov 24, 2010 at 07:26:50PM +, Haris Rotsos wrote: >> >> I have a question related to openvswitch and it's functionality as an >> >> openflow switch. I am currently setting up the switch as follows: >> >> >> >> insmod openvswitch/datapath/linux-2.6/openvswitch_mod.ko >> >> insmod openvswitch/datapath/linux-2.6/brcompat_mod.ko >> >> >> >> #Start ovsdb server. The configuration is the default created through >> >> ovsdb-create >> >> sudo ovsdb-server openvswitch/ovsdb.conf >> >> >> >> #initialize db and create bridge >> >> sudo ovs-vsctl init >> >> sudo ovs-vsctl add-br br0 >> >> ifconfig br0 10.1.1.1 netmask 255.255.255.0 >> >> sudo ovs-vsctl add-port br0 eth0 >> >> sudo ovs-vsctl add-port br0 eth1 >> >> sudo ovs-vsctl set-controller br0 tcp:127.0.0.1:6633 #I am using nox >> >> as a controller >> >> >> >> I also have a device attached on eth1 which has ip 10.1.1.2/24. As >> >> long as the switch doesn't have an openflow controller setted up, I am >> >> able to connect to the computer hosting the switch (e.g. pinging and >> >> sshing 10.1.1.1 works). After I setup the controller ip, the host >> >> becomes unreachable. The problem in the beginning was that the switch >> >> didn't reply to arp request, but even if I manually insert the mac >> >> address of br0, the host remained unreachable. Is there a way in a >> >> setup like the one mentioned to be able to push packets up the network >> >> stack to the system hosting the switch? >> > >> > Do you have an IP address configured (e.g. with ifconfig) on eth0 or >> > eth1? You should not. >> > >> > It sounds like the controller isn't setting up flows. Have you tried >> > using ovs-controller, to eliminate that possibility? >> > >> > Since the controller is local, then it would be better to use a Unix >> > domain socket (unix:) to connect to it. >> > >> >> >> >> -- >> 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: cr...@cl.cam.ac.uk > -- 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: cr...@cl.cam.ac.uk ___ discuss mailing list discuss@openvswitch.org http://openvswitch.org/mailman/listinfo/discuss_openvswitch.org
[ovs-discuss] openvswitch as openflow switch
Hello everybody, I have a question related to openvswitch and it's functionality as an openflow switch. I am currently setting up the switch as follows: insmod openvswitch/datapath/linux-2.6/openvswitch_mod.ko insmod openvswitch/datapath/linux-2.6/brcompat_mod.ko #Start ovsdb server. The configuration is the default created through ovsdb-create sudo ovsdb-server openvswitch/ovsdb.conf #initialize db and create bridge sudo ovs-vsctl init sudo ovs-vsctl add-br br0 ifconfig br0 10.1.1.1 netmask 255.255.255.0 sudo ovs-vsctl add-port br0 eth0 sudo ovs-vsctl add-port br0 eth1 sudo ovs-vsctl set-controller br0 tcp:127.0.0.1:6633 #I am using nox as a controller I also have a device attached on eth1 which has ip 10.1.1.2/24. As long as the switch doesn't have an openflow controller setted up, I am able to connect to the computer hosting the switch (e.g. pinging and sshing 10.1.1.1 works). After I setup the controller ip, the host becomes unreachable. The problem in the beginning was that the switch didn't reply to arp request, but even if I manually insert the mac address of br0, the host remained unreachable. Is there a way in a setup like the one mentioned to be able to push packets up the network stack to the system hosting the switch? -- 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: cr...@cl.cam.ac.uk ___ discuss mailing list discuss@openvswitch.org http://openvswitch.org/mailman/listinfo/discuss_openvswitch.org
[ovs-discuss] openflow packet_out and openvswitch
I am currently using nox and openvswitch in order to write a simple dhcp plugin for nox. I am trying to generate dhcp packets on the controller and push them out throught the openvswitch to the network. the packet I send is (using -V option on tshark): Frame 1 (372 bytes on wire, 372 bytes captured) Frame Number: 1 Frame Length: 372 bytes Capture Length: 372 bytes [Frame is marked: False] [Protocols in frame: eth:ip:tcp:of:eth:ip:udp:bootp] Ethernet II, Src: 00:00:00_00:00:00 (00:00:00:00:00:00), Dst: 00:00:00_00:00:00 (00:00:00:00:00:00) Destination: 00:00:00_00:00:00 (00:00:00:00:00:00) Address: 00:00:00_00:00:00 (00:00:00:00:00:00) ...0 = IG bit: Individual address (unicast) ..0. = LG bit: Globally unique address (factory default) Source: 00:00:00_00:00:00 (00:00:00:00:00:00) Address: 00:00:00_00:00:00 (00:00:00:00:00:00) ...0 = IG bit: Individual address (unicast) ..0. = LG bit: Globally unique address (factory default) Type: IP (0x0800) Internet Protocol, Src: 127.0.0.1 (127.0.0.1), Dst: 127.0.0.1 (127.0.0.1) Version: 4 Header length: 20 bytes Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00) 00.. = Differentiated Services Codepoint: Default (0x00) ..0. = ECN-Capable Transport (ECT): 0 ...0 = ECN-CE: 0 Total Length: 358 Identification: 0x4c06 (19462) Flags: 0x02 (Don't Fragment) 0.. = Reserved bit: Not Set .1. = Don't fragment: Set ..0 = More fragments: Not Set Fragment offset: 0 Time to live: 64 Protocol: TCP (0x06) Header checksum: 0xef89 [correct] [Good: True] [Bad : False] Source: 127.0.0.1 (127.0.0.1) Destination: 127.0.0.1 (127.0.0.1) Transmission Control Protocol, Src Port: 6633 (6633), Dst Port: 35686 (35686), Seq: 1, Ack: 1, Len: 306 Source port: 6633 (6633) Destination port: 35686 (35686) [Stream index: 0] Sequence number: 1 (relative sequence number) [Next sequence number: 307 (relative sequence number)] Acknowledgement number: 1 (relative ack number) Header length: 32 bytes Flags: 0x18 (PSH, ACK) 0... = Congestion Window Reduced (CWR): Not set .0.. = ECN-Echo: Not set ..0. = Urgent: Not set ...1 = Acknowledgement: Set 1... = Push: Set .0.. = Reset: Not set ..0. = Syn: Not set ...0 = Fin: Not set Window size: 1540 Checksum: 0xff5a [validation disabled] [Good Checksum: False] [Bad Checksum: False] Options: (12 bytes) NOP NOP Timestamps: TSval 9608020, TSecr 9608020 [SEQ/ACK analysis] [Number of bytes in flight: 306] [PDU Size: 306] OpenFlow Protocol Header Version: 0x01 Type: Packet Out (CSM) (13) Length: 306 Transaction ID: 0 Packet Out Buffer ID: None Frame Recv Port: 1 Size of action array in bytes: 8 Output Action(s) Action Type: Output to switch port (0) Len: 8 Output port: 1 Max Bytes to Send: 0 # of Actions: 1 Frame Data: 080027D6A219080027EE1D9F08004500010C8011... Ethernet II, Src: CadmusCo_ee:1d:9f (08:00:27:ee:1d:9f), Dst: CadmusCo_d6:a2:19 (08:00:27:d6:a2:19) Destination: CadmusCo_d6:a2:19 (08:00:27:d6:a2:19) Address: CadmusCo_d6:a2:19 (08:00:27:d6:a2:19) ...0 = IG bit: Individual address (unicast) ..0. = LG bit: Globally unique address (factory default) Source: CadmusCo_ee:1d:9f (08:00:27:ee:1d:9f) Address: CadmusCo_ee:1d:9f (08:00:27:ee:1d:9f) ...0 = IG bit: Individual address (unicast) ..0. = LG bit: Globally unique address (factory default) Type: IP (0x0800) Internet Protocol, Src: 10.2.0.1 (10.2.0.1), Dst: 255.255.255.255 (255.255.255.255) Version: 4 Header length: 20 bytes Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00) 00.. = Differentiated Services Codepoint: Default (0x00) ..0. = ECN-Capable Transport (ECT): 0 ...0 = ECN-CE: 0 Total Length: 268 Identification: 0x (0) Flags: 0x00 0.. = Reserved bit: Not Set .0. = Don't fragment: Not Set ..0 = More fragments: Not Set Fragment offset: 0 Time to live: 128 Protocol: UDP (0x11) Header checksum: 0x2fdf [correct]
