[ovs-discuss] ping and flow
Hi i am trying to understand this better from 192.168.3.3 ping 192.168.3.4 -c *10* *10* packets transmitted, 10 received, 0% packet loss, time 9003ms ovs-dpctl dump-flows in_port(3),eth(src=52:b9:12:5f:87:b1,dst=ea:91:10:fc:7a:bf),eth_type(0x0800),ipv4(src=192.168.3.4,dst=192.168.3.3,proto=1,tos=0,ttl=64,frag=no),icmp(type=0,code=0), *packets:9*, bytes:882, used:0.860s, actions:3 in_port(5),eth(src=ea:91:10:fc:7a:bf,dst=52:b9:12:5f:87:b1),eth_type(0x0800),ipv4(src=192.168.3.3,dst=192.168.3.4,proto=1,tos=0,ttl=64,frag=no),icmp(type=8,code=0), *packets:9*, bytes:882, used:0.860s, actions:5 Why am i not able to see all *10* packets in the flow,flow is showing 9 and no packet got lost. I guess it has something to do with first packet for which there was no active flow. My understanding was that first packet will be send to user space which generates flow and send to kernel space and all the subsequent packet will flow through data path with out going through user space,but doesn't above shows that user space generates flow and also handles first packet...can some body please confirm this ___ discuss mailing list discuss@openvswitch.org http://openvswitch.org/mailman/listinfo/discuss
Re: [ovs-discuss] dropped over-mtu packet:
Thanks Jesse, yes,it is a driver issue,Since other servers don't have this driver issue they are not showing this in dmesg,but does that mean that ovs send packets with out considering MTU of interface. Thanks, kevin On Mon, Dec 2, 2013 at 11:54 PM, Jesse Gross wrote: > It's likely due to the driver coalescing segments but not properly > setting up the metadata, which happened with some versions of the > Broadcom driver. You can look at the LRO and GRO settings on the NIC > as a temporary workaround. > > On Mon, Dec 2, 2013 at 6:51 AM, kevin parker > wrote: > > Thanks for the reply Philip, > > You are right i have TSO > > (tcp-segmentation-offload: on) enabled on eth0 and eth1,but no other > servers > > are > > showing this in dmesg. > > > > Also With TSO on,why ovs is dropping frames rather than fragmenting it. > > > > Regards, > > Kevin > > > > Hi, > >> > >> > >> seems that you have TSO enabled? > >> you can check the offloading features of your NIC with ethtool. > >> > >> Best, > >> > >> Philip > >> > >> Am 02.12.13 15:09, schrieb kevin parker: > >> > >> Hi, > >> I am confused with this in dmesg > >> dmesg |grep "mtu" > >> [10674662.495400] openvswitch: xapi3: dropped over-mtu packet: 2853 > > 1500 > >> [10674662.495406] openvswitch: xapi3: dropped over-mtu packet: 2853 > > 1500 > >> [10674662.495411] openvswitch: xapi3: dropped over-mtu packet: 2853 > > 1500 > >> [10674662.495432] openvswitch: xapi3: dropped over-mtu packet: 4082 > > 1500 > >> [10674662.495435] openvswitch: xapi3: dropped over-mtu packet: 4082 > > 1500 > >> [10674662.495441] openvswitch: xapi3: dropped over-mtu packet: 4082 > > 1500 > >> [13413434.378976] openvswitch: xapi3: dropped over-mtu packet: 4082 > > 1500 > >> [13413434.378982] openvswitch: xapi3: dropped over-mtu packet: 4082 > > 1500 > >> [13413434.378989] openvswitch: xapi3: dropped over-mtu packet: 4082 > > 1500 > >> [13413434.379050] openvswitch: xapi3: dropped over-mtu packet: 2556 > > 1500 > >> [13413434.379054] openvswitch: xapi3: dropped over-mtu packet: 2556 > > 1500 > >> [13413434.379058] openvswitch: xapi3: dropped over-mtu packet: 2556 > > 1500 > >> > >> All interfaces are configured with MTU of 1500 (netstat -i )and on > >> physical switch also it is 1500. > >> > >> I dont understand why it is showing above in dmesg,can some one explain > me > >> why something is trying to send Frames above 1500 and getting blocked by > >> ovs,even if no interface has an MTU of 1500 < .Is there any way to find > out > >> what is trying to send frames larger than 1500. > >> > >> ovs-vsctl -V > >> ovs-vsctl (Open vSwitch) 1.4.2 > >> Compiled Nov 23 2012 12:41:37 > >> > >> ovs-dpctl show > >> system@xapi3: > >> lookups: hit:47665012972 missed:27317456871 lost:156544274 > >> flows: 829 > >> port 0: xapi3 (internal) > >> port 1: eth1 > >> port 2: eth0 > >> port 4: xapi4 (internal) > >> port 31: vif28.0 > >> port 32: vif29.0 > >> port 33: vif30.0 > >> > >> ovs-vsctl list-ports xapi3 > >> bond1 > >> > >> ovs-appctl bond/show bond1 > >> bond_mode: active-backup > >> bond-hash-basis: 0 > >> updelay: 31000 ms > >> downdelay: 200 ms > >> lacp_negotiated: false > >> > >> slave eth1: enabled > >> active slave > >> may_enable: true > >> > >> slave eth0: enabled > >> may_enable: true > >> > >> Regards, > >> Kevin > >> > >> > >> > >> ___ > >> discuss mailing list > >> discuss@openvswitch.org > >> http://openvswitch.org/mailman/listinfo/discuss > >> > >> > >> > >> -- > >> Philip Wette, M.Sc. E-Mail: we...@mail.upb.de > >> University of Paderborn Tel.: 05251 / 60-1716 > >> Department of Computer Science > >> Computer Networks Group http://wwwcs.upb.de/cs/ag-karl > >> Warburger Straße 100Room: O3.152 > >> 33098 Paderborn > >> > >> > >> ___ > >> discuss mailing list > >> discuss@openvswitch.org > >> http://openvswitch.org/mailman/listinfo/discuss > >> > >> > > > > > > ___ > > discuss mailing list > > discuss@openvswitch.org > > http://openvswitch.org/mailman/listinfo/discuss > > > ___ discuss mailing list discuss@openvswitch.org http://openvswitch.org/mailman/listinfo/discuss
Re: [ovs-discuss] GRE tunnel
Can any one please help me understand the invisible link that carries traffic from gre0 through birdge with NIC attached. On Thu, Dec 5, 2013 at 10:10 PM, kevin parker wrote: > Hi All, > I have a working GRE connected between one kvm host ovs 1.11 and > xenserver ovs 1.4.6 > > I have created an *isolated* bridge and connected virtual interface to > isolated bridge with private ip ,and then added *gre0* port by mentioning > remote public IP. > > Everything is fine, dont have any issues :) > > For understanding it better > > tried tcpdump on isolated bridge i am not able find anything other than > ARP request > > *tcpdump -i isolated -n not port 22 -v* >> tcpdump: listening on isolated, link-type EN10MB (Ethernet), capture size >> 65535 bytes >> 21:31:06.304223 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has >> 10.168.122.10 tell 10.168.122.200, length 28 > > > so used dump-flows on ovs 1.4.6 > ovs-dpctl dump-flows isolated|grep -v 'src=22' |grep -v 'dst=22' > in_port(3),eth(src=ae:0a:5e:8a:cc:2b,dst=52:54:00:bb:86:99),eth_type(0x0800),ipv4(src=10.168.122.200,dst=10.168.122.10,proto=1,tos=0,ttl=64,frag=no),icmp(type=8,code=0), > packets:0, bytes:0, used:never, actions:*1* > > in_port(1),eth(src=52:54:00:bb:86:99,dst=ae:0a:5e:8a:cc:2b),eth_type(0x0800),ipv4(src=10.168.122.10,dst=10.168.122.200,proto=1,tos=0,ttl=64,frag=no),icmp(type=0,code=0), > packets:0, bytes:0, used:never, actions:*3* > > From this if i understand correctly ovs is outputting to port 1 which is > *gre0* with remote ip .But i don't understand > 1.how packets go from *gre0* through bridge *kvmbr0* in which NIC is > bridged. > and > 2. tcpdump not showing any packets in isolated bridge. > > Can some one please help me understand this better or point to some > documentation > > Regards, > kevin > ___ discuss mailing list discuss@openvswitch.org http://openvswitch.org/mailman/listinfo/discuss
[ovs-discuss] GRE tunnel
Hi All, I have a working GRE connected between one kvm host ovs 1.11 and xenserver ovs 1.4.6 I have created an *isolated* bridge and connected virtual interface to isolated bridge with private ip ,and then added *gre0* port by mentioning remote public IP. Everything is fine, dont have any issues :) For understanding it better tried tcpdump on isolated bridge i am not able find anything other than ARP request *tcpdump -i isolated -n not port 22 -v* > tcpdump: listening on isolated, link-type EN10MB (Ethernet), capture size > 65535 bytes > 21:31:06.304223 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has > 10.168.122.10 tell 10.168.122.200, length 28 so used dump-flows on ovs 1.4.6 ovs-dpctl dump-flows isolated|grep -v 'src=22' |grep -v 'dst=22' in_port(3),eth(src=ae:0a:5e:8a:cc:2b,dst=52:54:00:bb:86:99),eth_type(0x0800),ipv4(src=10.168.122.200,dst=10.168.122.10,proto=1,tos=0,ttl=64,frag=no),icmp(type=8,code=0), packets:0, bytes:0, used:never, actions:*1* in_port(1),eth(src=52:54:00:bb:86:99,dst=ae:0a:5e:8a:cc:2b),eth_type(0x0800),ipv4(src=10.168.122.10,dst=10.168.122.200,proto=1,tos=0,ttl=64,frag=no),icmp(type=0,code=0), packets:0, bytes:0, used:never, actions:*3* >From this if i understand correctly ovs is outputting to port 1 which is *gre0* with remote ip .But i don't understand 1.how packets go from *gre0* through bridge *kvmbr0* in which NIC is bridged. and 2. tcpdump not showing any packets in isolated bridge. Can some one please help me understand this better or point to some documentation Regards, kevin ___ discuss mailing list discuss@openvswitch.org http://openvswitch.org/mailman/listinfo/discuss
Re: [ovs-discuss] dropped over-mtu packet:
Thanks for the reply Philip, You are right i have TSO (tcp-segmentation-offload: on) enabled on eth0 and eth1,but no other servers are showing this in dmesg. Also With TSO on,why ovs is dropping frames rather than fragmenting it. Regards, Kevin Hi, > > seems that you have TSO enabled? > you can check the offloading features of your NIC with ethtool. > > Best, > > Philip > > Am 02.12.13 15:09, schrieb kevin parker: > > Hi, > I am confused with this in dmesg > *dmesg |grep "mtu"* > [10674662.495400] openvswitch: xapi3: dropped over-mtu packet: 2853 > 1500 > [10674662.495406] openvswitch: xapi3: dropped over-mtu packet: 2853 > 1500 > [10674662.495411] openvswitch: xapi3: dropped over-mtu packet: 2853 > 1500 > [10674662.495432] openvswitch: xapi3: dropped over-mtu packet: 4082 > 1500 > [10674662.495435] openvswitch: xapi3: dropped over-mtu packet: 4082 > 1500 > [10674662.495441] openvswitch: xapi3: dropped over-mtu packet: 4082 > 1500 > [13413434.378976] openvswitch: xapi3: dropped over-mtu packet: 4082 > 1500 > [13413434.378982] openvswitch: xapi3: dropped over-mtu packet: 4082 > 1500 > [13413434.378989] openvswitch: xapi3: dropped over-mtu packet: 4082 > 1500 > [13413434.379050] openvswitch: xapi3: dropped over-mtu packet: 2556 > 1500 > [13413434.379054] openvswitch: xapi3: dropped over-mtu packet: 2556 > 1500 > [13413434.379058] openvswitch: xapi3: dropped over-mtu packet: 2556 > 1500 > > All interfaces are configured with MTU of 1500 (netstat -i )and on > physical switch also it is 1500. > > I dont understand why it is showing above in dmesg,can some one explain > me why something is trying to send Frames above 1500 and getting blocked by > ovs,even if no interface has an MTU of 1500 < .Is there any way to find out > what is trying to send frames larger than 1500. > > ovs-vsctl -V > ovs-vsctl (Open vSwitch) 1.4.2 > Compiled Nov 23 2012 12:41:37 > > *ovs-dpctl show * > system@xapi3: > lookups: hit:47665012972 missed:27317456871 lost:156544274 > flows: 829 > port 0: xapi3 (internal) > port 1: eth1 > port 2: eth0 > port 4: xapi4 (internal) > port 31: vif28.0 > port 32: vif29.0 > port 33: vif30.0 > > *ovs-vsctl list-ports xapi3* > bond1 > > *ovs-appctl bond/show bond1* > bond_mode: active-backup > bond-hash-basis: 0 > updelay: 31000 ms > downdelay: 200 ms > lacp_negotiated: false > > slave eth1: enabled > active slave > may_enable: true > > slave eth0: enabled > may_enable: true > > Regards, > Kevin > > > > ___ > discuss mailing > listdiscuss@openvswitch.orghttp://openvswitch.org/mailman/listinfo/discuss > > > > -- > Philip Wette, M.Sc. E-Mail: we...@mail.upb.de > University of Paderborn Tel.: 05251 / 60-1716 > Department of Computer Science > Computer Networks Group http://wwwcs.upb.de/cs/ag-karl > Warburger Straße 100Room: O3.152 > 33098 Paderborn > > > ___ > discuss mailing list > discuss@openvswitch.org > http://openvswitch.org/mailman/listinfo/discuss > > > ___ discuss mailing list discuss@openvswitch.org http://openvswitch.org/mailman/listinfo/discuss
[ovs-discuss] dropped over-mtu packet:
Hi, I am confused with this in dmesg *dmesg |grep "mtu"* [10674662.495400] openvswitch: xapi3: dropped over-mtu packet: 2853 > 1500 [10674662.495406] openvswitch: xapi3: dropped over-mtu packet: 2853 > 1500 [10674662.495411] openvswitch: xapi3: dropped over-mtu packet: 2853 > 1500 [10674662.495432] openvswitch: xapi3: dropped over-mtu packet: 4082 > 1500 [10674662.495435] openvswitch: xapi3: dropped over-mtu packet: 4082 > 1500 [10674662.495441] openvswitch: xapi3: dropped over-mtu packet: 4082 > 1500 [13413434.378976] openvswitch: xapi3: dropped over-mtu packet: 4082 > 1500 [13413434.378982] openvswitch: xapi3: dropped over-mtu packet: 4082 > 1500 [13413434.378989] openvswitch: xapi3: dropped over-mtu packet: 4082 > 1500 [13413434.379050] openvswitch: xapi3: dropped over-mtu packet: 2556 > 1500 [13413434.379054] openvswitch: xapi3: dropped over-mtu packet: 2556 > 1500 [13413434.379058] openvswitch: xapi3: dropped over-mtu packet: 2556 > 1500 All interfaces are configured with MTU of 1500 (netstat -i )and on physical switch also it is 1500. I dont understand why it is showing above in dmesg,can some one explain me why something is trying to send Frames above 1500 and getting blocked by ovs,even if no interface has an MTU of 1500 < .Is there any way to find out what is trying to send frames larger than 1500. ovs-vsctl -V ovs-vsctl (Open vSwitch) 1.4.2 Compiled Nov 23 2012 12:41:37 *ovs-dpctl show * system@xapi3: lookups: hit:47665012972 missed:27317456871 lost:156544274 flows: 829 port 0: xapi3 (internal) port 1: eth1 port 2: eth0 port 4: xapi4 (internal) port 31: vif28.0 port 32: vif29.0 port 33: vif30.0 *ovs-vsctl list-ports xapi3* bond1 *ovs-appctl bond/show bond1* bond_mode: active-backup bond-hash-basis: 0 updelay: 31000 ms downdelay: 200 ms lacp_negotiated: false slave eth1: enabled active slave may_enable: true slave eth0: enabled may_enable: true Regards, Kevin ___ discuss mailing list discuss@openvswitch.org http://openvswitch.org/mailman/listinfo/discuss
Re: [ovs-discuss] Analyzing crash log,after network freeze
Thanks Andy,Since i am using OVS 1.4.6,i will try to recreate by swapping ram again. I forgot to mention that after the crash system was showing "parity check 2 system dimm memory" Thanks for your help. Regards, Kev On Thu, Nov 7, 2013 at 11:09 PM, Andy Zhou wrote: > This is the sort of errors you may need to dig into a bit more at your > end. > > We should first try to find out if this caused by hardware issues. I > suppose If you can experiment by swapping RAM back. RAM issues should also > cause crashes that are not OVS related. > > If you can rule out RAM change being the cause, I'd suggest try version > OVS 1.4.6 -- There are a few datpath bug fixes on the 1.4 branch that may > be related. > > > Hope this helps, > > Andy > > > > > > On Wed, Nov 6, 2013 at 11:40 PM, kevin parker > wrote: > >> Thanks for the reply Andy, >> Can you help me identify reason for >> this behavior. >> I only know that Xenserver was down and hard reset was required to bring >> it back. >> Recently we changed RAM from 2 Gb x 4 (1333 Mhz) to 8Gb x 1 (1600 MHz). >> >> i have ovs 1.4.2 running on other servers with out any issues. >> >> Thanks, >> kevin >> >> >> >> On Thu, Nov 7, 2013 at 1:21 AM, Andy Zhou wrote: >> >>> It does look like OVS related. >>> >>> >>> On Wed, Nov 6, 2013 at 3:42 AM, kevin parker >>> wrote: >>> >>>> Hello All, >>>> >>>> One of our xen server server stopped responding after few >>>> network tests,can some one please help me verify whether it is related to >>>> ovs. >>>> In stack trace i can see ovs process id. >>>> >>>> *ovs-vsctl -V* >>>> ovs-vsctl (Open vSwitch) 1.4.6 >>>> Compiled Jun 14 2013 09:23:27 >>>> >>>> *From log:* >>>> >>>> <4>[322699.276939] /local/domain/15/device/vif/0: Connected >>>> <4>[322724.120768] vif15.0: draining TX queue >>>> <0>[333985.181875] NMI: IOCK error (debug interrupt?) >>>> <4>[333985.181881] Modules linked in: tun nfs nfs_acl auth_rpcgss >>>> tcp_diag inet_diag lockd sunrpc openvswitch_mod ipt_REJECT >>>> nf_conntrack_ipv4 nf_defrag_ipv4 xt_state nf_conntrack xt_tcpudp >>>> iptable_filter ip_tables x_tables binfmt_misc nls_utf8 isofs dm_mirror >>>> video output sbs sbshc fan battery ac parport_pc lp parport nvram usbhid >>>> container evdev thermal sg button processor thermal_sys hpilo e1000e >>>> serio_raw rtc_cmos rtc_core rtc_lib 8250_pnp 8250 serial_core tpm_tis tpm >>>> tpm_bios pcspkr dm_region_hash dm_log dm_mod ahci libata sd_mod scsi_mod >>>> ext3 jbd uhci_hcd ohci_hcd ehci_hcd usbcore fbcon font tileblit bitblit >>>> softcursor [last unloaded: microcode] >>>> <4>[333985.181917] >>>> <4>[333985.181919] Pid: 5334, comm: ovs-vswitchd Not tainted >>>> (2.6.32.43-0.4.1.xs1.8.0.835.170778xen #1) ProLiant DL120 G7 >>>> <4>[333985.181921] EIP: 0061:[] EFLAGS: 00010246 CPU: 0 >>>> <4>[333985.181926] EIP is at ovs_flow_tbl_lookup+0x5e/0x80 >>>> [openvswitch_mod] >>>> <4>[333985.181928] EAX: 0030 EBX: ec42e834 ECX: 0012 EDX: >>>> 4d8c04a6 >>>> <4>[333985.181929] ESI: ec42e85e EDI: eda21cf2 EBP: eda21cc4 ESP: >>>> eda21ca8 >>>> <4>[333985.181931] DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0069 >>>> <0>[333985.181932] Process ovs-vswitchd (pid: 5334, ti=eda2 >>>> task=ec782670 task.ti=eda2) >>>> <0>[333985.181936] Stack: >>>> <4>[333985.181937] ec42e82c 0030 eda21cd4 4d8c04a6 c100e9a0 >>>> edadcac0 edc1c2c0 eda21d5c >>>> <4>[333985.181940] <0> f0a143e2 eda21d4c edca8000 >>>> 0001 240a2600 >>>> <4>[333985.181943] <0> 846a00b0 5cd61cda 0008 003f0006 b06a7c73 >>>> 92687c73 50002d82 >>>> <0>[333985.181947] Call Trace: >>>> <4>[333985.181952] [] ? >>>> ovs_dp_process_received_packet+0xa2/0xf0 [openvswitch_mod] >>>> <4>[333985.181956] [] ? pollwake+0x0/0x70 >>>> <4>[333985.181960] [] ? ovs_vport_receive+0x75/0x90 >>>> [openvswitch_mod] >>>> <4>[333985.181964] [] ? netdev_frame_hook+0x4f/0x90 >>>> [openvswitch_mod] >>>> <4>
Re: [ovs-discuss] Analyzing crash log,after network freeze
Thanks for the reply Andy, Can you help me identify reason for this behavior. I only know that Xenserver was down and hard reset was required to bring it back. Recently we changed RAM from 2 Gb x 4 (1333 Mhz) to 8Gb x 1 (1600 MHz). i have ovs 1.4.2 running on other servers with out any issues. Thanks, kevin On Thu, Nov 7, 2013 at 1:21 AM, Andy Zhou wrote: > It does look like OVS related. > > > On Wed, Nov 6, 2013 at 3:42 AM, kevin parker wrote: > >> Hello All, >> >> One of our xen server server stopped responding after few >> network tests,can some one please help me verify whether it is related to >> ovs. >> In stack trace i can see ovs process id. >> >> *ovs-vsctl -V* >> ovs-vsctl (Open vSwitch) 1.4.6 >> Compiled Jun 14 2013 09:23:27 >> >> *From log:* >> >> <4>[322699.276939] /local/domain/15/device/vif/0: Connected >> <4>[322724.120768] vif15.0: draining TX queue >> <0>[333985.181875] NMI: IOCK error (debug interrupt?) >> <4>[333985.181881] Modules linked in: tun nfs nfs_acl auth_rpcgss >> tcp_diag inet_diag lockd sunrpc openvswitch_mod ipt_REJECT >> nf_conntrack_ipv4 nf_defrag_ipv4 xt_state nf_conntrack xt_tcpudp >> iptable_filter ip_tables x_tables binfmt_misc nls_utf8 isofs dm_mirror >> video output sbs sbshc fan battery ac parport_pc lp parport nvram usbhid >> container evdev thermal sg button processor thermal_sys hpilo e1000e >> serio_raw rtc_cmos rtc_core rtc_lib 8250_pnp 8250 serial_core tpm_tis tpm >> tpm_bios pcspkr dm_region_hash dm_log dm_mod ahci libata sd_mod scsi_mod >> ext3 jbd uhci_hcd ohci_hcd ehci_hcd usbcore fbcon font tileblit bitblit >> softcursor [last unloaded: microcode] >> <4>[333985.181917] >> <4>[333985.181919] Pid: 5334, comm: ovs-vswitchd Not tainted >> (2.6.32.43-0.4.1.xs1.8.0.835.170778xen #1) ProLiant DL120 G7 >> <4>[333985.181921] EIP: 0061:[] EFLAGS: 00010246 CPU: 0 >> <4>[333985.181926] EIP is at ovs_flow_tbl_lookup+0x5e/0x80 >> [openvswitch_mod] >> <4>[333985.181928] EAX: 0030 EBX: ec42e834 ECX: 0012 EDX: 4d8c04a6 >> <4>[333985.181929] ESI: ec42e85e EDI: eda21cf2 EBP: eda21cc4 ESP: eda21ca8 >> <4>[333985.181931] DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0069 >> <0>[333985.181932] Process ovs-vswitchd (pid: 5334, ti=eda2 >> task=ec782670 task.ti=eda2) >> <0>[333985.181936] Stack: >> <4>[333985.181937] ec42e82c 0030 eda21cd4 4d8c04a6 c100e9a0 edadcac0 >> edc1c2c0 eda21d5c >> <4>[333985.181940] <0> f0a143e2 eda21d4c edca8000 >> 0001 240a2600 >> <4>[333985.181943] <0> 846a00b0 5cd61cda 0008 003f0006 b06a7c73 >> 92687c73 50002d82 >> <0>[333985.181947] Call Trace: >> <4>[333985.181952] [] ? >> ovs_dp_process_received_packet+0xa2/0xf0 [openvswitch_mod] >> <4>[333985.181956] [] ? pollwake+0x0/0x70 >> <4>[333985.181960] [] ? ovs_vport_receive+0x75/0x90 >> [openvswitch_mod] >> <4>[333985.181964] [] ? netdev_frame_hook+0x4f/0x90 >> [openvswitch_mod] >> <4>[333985.181968] [] ? netif_receive_skb+0x1bb/0x6a0 >> <4>[333985.181971] [] ? __napi_gro_receive+0xda/0xf0 >> <4>[333985.181973] [] ? napi_skb_finish+0x38/0x40 >> <4>[333985.181975] [] ? napi_gro_receive+0x2d/0x40 >> <4>[333985.181980] [] ? e1000_receive_skb+0x68/0xf0 [e1000e] >> <4>[333985.181984] [] ? e1000_clean_rx_irq+0x21a/0x360 [e1000e] >> <4>[333985.181990] [] ? e1000e_poll+0x19d/0x2b0 [e1000e] >> <4>[333985.181992] [] ? net_rx_action+0x155/0x260 >> <4>[333985.181996] [] ? __do_softirq+0xc2/0x200 >> <4>[333985.181998] [] ? end_pirq+0x95/0x110 >> <4>[333985.182001] [] ? do_softirq+0x75/0x80 >> <4>[333985.182002] [] ? irq_exit+0x35/0x40 >> <4>[333985.182005] [] ? evtchn_do_upcall+0x2fc/0x4a9 >> <4>[333985.182007] [] ? hypervisor_callback+0x43/0x4b >> <0>[333985.182008] Code: 08 eb 37 8b 1b 85 db 74 31 8b 03 0f 18 00 90 8d >> 43 f8 8b 55 f0 89 45 e4 3b 50 10 75 e6 8b 45 e8 8d 73 0c 8b 7d ec fc 39 c0 >> 89 c1 a6 75 d4 8b 45 e4 83 c4 10 5b 5e 5f 5d c3 c7 45 e4 00 00 00 >> >> Regards, >> kevin >> >> ___ >> discuss mailing list >> discuss@openvswitch.org >> http://openvswitch.org/mailman/listinfo/discuss >> >> > ___ discuss mailing list discuss@openvswitch.org http://openvswitch.org/mailman/listinfo/discuss
[ovs-discuss] Analyzing crash log,after network freeze
Hello All, One of our xen server server stopped responding after few network tests,can some one please help me verify whether it is related to ovs. In stack trace i can see ovs process id. *ovs-vsctl -V* ovs-vsctl (Open vSwitch) 1.4.6 Compiled Jun 14 2013 09:23:27 *From log:* <4>[322699.276939] /local/domain/15/device/vif/0: Connected <4>[322724.120768] vif15.0: draining TX queue <0>[333985.181875] NMI: IOCK error (debug interrupt?) <4>[333985.181881] Modules linked in: tun nfs nfs_acl auth_rpcgss tcp_diag inet_diag lockd sunrpc openvswitch_mod ipt_REJECT nf_conntrack_ipv4 nf_defrag_ipv4 xt_state nf_conntrack xt_tcpudp iptable_filter ip_tables x_tables binfmt_misc nls_utf8 isofs dm_mirror video output sbs sbshc fan battery ac parport_pc lp parport nvram usbhid container evdev thermal sg button processor thermal_sys hpilo e1000e serio_raw rtc_cmos rtc_core rtc_lib 8250_pnp 8250 serial_core tpm_tis tpm tpm_bios pcspkr dm_region_hash dm_log dm_mod ahci libata sd_mod scsi_mod ext3 jbd uhci_hcd ohci_hcd ehci_hcd usbcore fbcon font tileblit bitblit softcursor [last unloaded: microcode] <4>[333985.181917] <4>[333985.181919] Pid: 5334, comm: ovs-vswitchd Not tainted (2.6.32.43-0.4.1.xs1.8.0.835.170778xen #1) ProLiant DL120 G7 <4>[333985.181921] EIP: 0061:[] EFLAGS: 00010246 CPU: 0 <4>[333985.181926] EIP is at ovs_flow_tbl_lookup+0x5e/0x80 [openvswitch_mod] <4>[333985.181928] EAX: 0030 EBX: ec42e834 ECX: 0012 EDX: 4d8c04a6 <4>[333985.181929] ESI: ec42e85e EDI: eda21cf2 EBP: eda21cc4 ESP: eda21ca8 <4>[333985.181931] DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0069 <0>[333985.181932] Process ovs-vswitchd (pid: 5334, ti=eda2 task=ec782670 task.ti=eda2) <0>[333985.181936] Stack: <4>[333985.181937] ec42e82c 0030 eda21cd4 4d8c04a6 c100e9a0 edadcac0 edc1c2c0 eda21d5c <4>[333985.181940] <0> f0a143e2 eda21d4c edca8000 0001 240a2600 <4>[333985.181943] <0> 846a00b0 5cd61cda 0008 003f0006 b06a7c73 92687c73 50002d82 <0>[333985.181947] Call Trace: <4>[333985.181952] [] ? ovs_dp_process_received_packet+0xa2/0xf0 [openvswitch_mod] <4>[333985.181956] [] ? pollwake+0x0/0x70 <4>[333985.181960] [] ? ovs_vport_receive+0x75/0x90 [openvswitch_mod] <4>[333985.181964] [] ? netdev_frame_hook+0x4f/0x90 [openvswitch_mod] <4>[333985.181968] [] ? netif_receive_skb+0x1bb/0x6a0 <4>[333985.181971] [] ? __napi_gro_receive+0xda/0xf0 <4>[333985.181973] [] ? napi_skb_finish+0x38/0x40 <4>[333985.181975] [] ? napi_gro_receive+0x2d/0x40 <4>[333985.181980] [] ? e1000_receive_skb+0x68/0xf0 [e1000e] <4>[333985.181984] [] ? e1000_clean_rx_irq+0x21a/0x360 [e1000e] <4>[333985.181990] [] ? e1000e_poll+0x19d/0x2b0 [e1000e] <4>[333985.181992] [] ? net_rx_action+0x155/0x260 <4>[333985.181996] [] ? __do_softirq+0xc2/0x200 <4>[333985.181998] [] ? end_pirq+0x95/0x110 <4>[333985.182001] [] ? do_softirq+0x75/0x80 <4>[333985.182002] [] ? irq_exit+0x35/0x40 <4>[333985.182005] [] ? evtchn_do_upcall+0x2fc/0x4a9 <4>[333985.182007] [] ? hypervisor_callback+0x43/0x4b <0>[333985.182008] Code: 08 eb 37 8b 1b 85 db 74 31 8b 03 0f 18 00 90 8d 43 f8 8b 55 f0 89 45 e4 3b 50 10 75 e6 8b 45 e8 8d 73 0c 8b 7d ec fc 39 c0 89 c1 a6 75 d4 8b 45 e4 83 c4 10 5b 5e 5f 5d c3 c7 45 e4 00 00 00 Regards, kevin ___ discuss mailing list discuss@openvswitch.org http://openvswitch.org/mailman/listinfo/discuss
Re: [ovs-discuss] iptables with ovs
Thanks anant, i went through their documentation it says they have connected vif to bridge and applied rules on that and then connected bridge to ovs,but i couldn't find a documentation to connect bridge to ovs. Can some one please help me with solving this. Thanks kevin On Thu, Oct 3, 2013 at 9:25 PM, ananthan wrote: > > I dont think "iptables -m physdev vif" can work with ovs,but in openstack > i think they made it to work by attaching virtual interface to Linux > bridge and then to ovs bridge,may be some one can explain it better. > > > > > > On Thu, Oct 3, 2013 at 2:45 PM, kevin parker wrote: > >> Hi, >>Is there any way that i can make iptables filtering to work with >> ovs. >> >> NAT is working but not able to filter traffic coming into the vm. >> >> Earlier with bridge i was able to filter using *-m physdev* ,but its not >> working with ovs. >> >> Is there any work around or changes that i can make for iptables to work >> with ovs. >> >> Currently i use ovs-ofctl to filter port and ip ,but need to use iptables >> to do the filtering part. >> >> Regards, >> kevin >> >> >> >> >> ___ >> discuss mailing list >> discuss@openvswitch.org >> http://openvswitch.org/mailman/listinfo/discuss >> >> > ___ discuss mailing list discuss@openvswitch.org http://openvswitch.org/mailman/listinfo/discuss
[ovs-discuss] iptables with ovs
Hi, Is there any way that i can make iptables filtering to work with ovs. NAT is working but not able to filter traffic coming into the vm. Earlier with bridge i was able to filter using *-m physdev* ,but its not working with ovs. Is there any work around or changes that i can make for iptables to work with ovs. Currently i use ovs-ofctl to filter port and ip ,but need to use iptables to do the filtering part. Regards, kevin ___ discuss mailing list discuss@openvswitch.org http://openvswitch.org/mailman/listinfo/discuss
[ovs-discuss] Installing 1.11 on Debian and existing datapath
Hi, I have compiled ovs 1.11 and was working fine. Now trying to install it through *.deb* packages which i generated as explained in INSTALL.DEBIAN. But i am not able to install datapath using m-a a-i openvswitch-datapath its showing this: *Bad luck, the kernel headers for the target kernel version could not be found and you did not specify other valid kernel headersto use. * * * *uname -r* 3.8.0-29-generic * * *ls -l /usr/src* linux -> linux-headers-3.8.0-29-generic linux-headers-3.8.0-29 linux-headers-3.8.0-29-generic openvswitch-1.11.0 openvswitch-datapath.tar.bz2 since my default kernel comes with ovs * * *cat /boot/config-3.8.0-29-generic |grep -i openvswitch* CONFIG_OPENVSWITCH=m *modprobe openvswitch* *modinfo openvswitch* filename: /lib/modules/3.8.0-29-generic/updates/dkms/openvswitch.ko version:*1.11.0* license:GPL description:Open vSwitch switching datapath srcversion: 6F60612DEDF2D2B5CEF0F76 depends: vermagic: 3.8.0-29-generic SMP mod_unload modversion Since the default module is 1.11.0,is it possible to make it work with generated .deb packages. When i tried to do that by enabling *modprobe openvswitch * * * and then *ovs-dpctl dump-flows br0 * shows ovs-dpctl: opening datapath (No such device) but* ovs-dpctl show* shows system@ovs-system: lookups: hit:448281 *missed*:97 lost:1 flows: 5 port 0: ovs-system (internal) port 1: br0 (internal) port 2: eth0 from missed and lost value does that mean that data path is working as only 97 times it has to come to user space for generating flows,if data path is working what could be the reason for No such device for dump-flows *ovs-dpctl -v dump-flows br0* * * 2013-09-29T14:37:45Z|1|netlink_socket|DBG|nl_sock_transact_multiple__ (Success): nl(len:40, type=16(control), flags=1[REQUEST], seq=1, pid=2488,genl(cmd=3,version=1) 2013-09-29T14:37:45Z|2|netlink_socket|DBG|nl_sock_recv__ (Success): nl(len:192, type=16(control), flags=0, seq=1, pid=2488,genl(cmd=1,version=2) 2013-09-29T14:37:45Z|3|netlink_socket|DBG|nl_sock_transact_multiple__ (Success): nl(len:36, type=16(control), flags=1[REQUEST], seq=1, pid=2488,genl(cmd=3,version=1) 2013-09-29T14:37:45Z|4|netlink_socket|DBG|nl_sock_recv__ (Success): nl(len:184, type=16(control), flags=0, seq=1, pid=2488,genl(cmd=1,version=2) 2013-09-29T14:37:45Z|5|netlink_socket|DBG|nl_sock_transact_multiple__ (Success): nl(len:36, type=16(control), flags=1[REQUEST], seq=1, pid=2488,genl(cmd=3,version=1) 2013-09-29T14:37:45Z|6|netlink_socket|DBG|nl_sock_recv__ (Success): nl(len:184, type=16(control), flags=0, seq=1, pid=2488,genl(cmd=1,version=2) 2013-09-29T14:37:45Z|7|netlink_socket|DBG|nl_sock_transact_multiple__ (Success): nl(len:36, type=16(control), flags=1[REQUEST], seq=1, pid=2488,genl(cmd=3,version=1) 2013-09-29T14:37:45Z|8|netlink_socket|DBG|nl_sock_recv__ (Success): nl(len:92, type=16(control), flags=0, seq=1, pid=2488,genl(cmd=1,version=2) 2013-09-29T14:37:45Z|9|netlink_socket|DBG|nl_sock_transact_multiple__ (Success): nl(len:36, type=16(control), flags=1[REQUEST], seq=1, pid=4294962918,genl(cmd=3,version=1) 2013-09-29T14:37:45Z|00010|netlink_socket|DBG|nl_sock_recv__ (Success): nl(len:184, type=16(control), flags=0, seq=1, pid=4294962918,genl(cmd=1,version=2) 2013-09-29T14:37:45Z|00011|netlink_socket|DBG|nl_sock_transact_multiple__ (Success): nl(len:32, type=25(ovs_datapath), flags=9[REQUEST][ECHO], seq=1, pid=2488,genl(cmd=3,version=1) 2013-09-29T14:37:45Z|00012|netlink_socket|DBG|nl_sock_recv__ (Success): nl(len:52, type=2(error), flags=0, seq=1, pid=2488 error(-19(No such device), in-reply-to(nl(len:32, type=25(ovs_datapath), flags=9[REQUEST][ECHO], seq=1, pid=2488)) 2013-09-29T14:37:45Z|00013|netlink_socket|DBG|received NAK error=0 (No such device) Thanks, kev ___ discuss mailing list discuss@openvswitch.org http://openvswitch.org/mailman/listinfo/discuss
[ovs-discuss] With and Without ovs-controller
Hi, I am new to OVS and trying to understand OVS working. *With out controller:* On my kvm host(ubuntu 12.04) i have ovs-vswitchd running with out any controller. version 1.6.9 In this case i guess ovs is not working as open flow based switch. as "ovs-ofctl dump-flows " is only showing default flow. but still able to see flows in "ovs-dpctl dump-flows " * * *1. *Are these flows same as flows created when connected to a controller?. *2. *Are these flows generated by user space process ovs-vswitchd? *3. *Isn't flow crucial for packet to flow through data path,if it is not always necessary to create flow (as per old mailing list) why it creates flow :-) *With ovs-controller* Added ovs to ovs-controller on different host and able to see flows generated on ovs-controller console,but as per man page of ovs-controller *"* *ovs-controller manages any number of remote switches over OpenFlow pro-* * tocol, causing them to function as L2 MAC-learning switches or hub"* * * *4* So from above man page, if with out any controller which mode does ovs work? * * *5.*Why ovs-vswitchd was consuming CPU even with separate controller and controller generating flows instead of ovs-vswitchd. Hope someone can answer these simple questions and help understand OVS better. Regards, kev ___ discuss mailing list discuss@openvswitch.org http://openvswitch.org/mailman/listinfo/discuss
[ovs-discuss] help in understanding drop rules which came with out setting any manual drop rule.
Hi All, How can drop rule come with out setting any drop rule manually. using OVS 1.4.1 *dpctl dump-flows* in_port(2),eth(src=00:26:0a:24:ae:00,dst=8e:fd:95:35:22:d1),eth_type(0x8100),vlan(vid=40,pcp=0),encap(eth_type(0x0800),ipv4(src=59.x.x.68,dst=11.x.x.41,proto=6,tos=0,ttl=59,frag=no),tcp(src=46583,dst=80)), packets:0, bytes:0, used:never, *actions:drop* in_port(2),eth(src=00:26:0a:24:ae:00,dst=8e:fd:95:35:22:d1),eth_type(0x8100),vlan(vid=40,pcp=0),encap(eth_type(0x0800),ipv4(src=11.x.x.214,dst=11.x.x.41,proto=6,tos=0,ttl=56,frag=no),tcp(src=33124,dst=443)), packets:0, bytes:0, used:never, *actions:drop* in_port(2),eth(src=00:26:0a:24:ae:00,dst=8e:fd:95:35:22:d1),eth_type(0x8100),vlan(vid=40,pcp=0),encap(eth_type(0x0800),ipv4(src=11.x.x.35,dst=11.x.x.41,proto=6,tos=0,ttl=56,frag=no),tcp(src=50363,dst=8080)), packets:1, bytes:66, used:0.128s, *actions:drop* No manuall drop rule has been set but on dpctl dump-flows there are some drop rules,for vm in port 2 with ip 11.x.x.41 On what basis ovs determines what to block. Expecting a reply, Regards, kev ___ discuss mailing list discuss@openvswitch.org http://openvswitch.org/mailman/listinfo/discuss
Re: [ovs-discuss] Even with ovs-controller vswitchd is still heavily used
i dont think ovs uses multiple controller at the same time,in my case both were used. i am looking for the reason as per man page in secure mode vswitchd will not be used when connection to controller fails,but it does not says that when the connection is working both controller will be used. Regards, keve On Fri, Jun 7, 2013 at 10:17 PM, Ben Pfaff wrote: > Why did you think that setting secure mode would not use ovs-vswitchd? > > On Fri, Jun 07, 2013 at 09:33:31PM +0530, kevin parker wrote: > > I thought setting secure mode would not use ovs-vswitchd, but in my case > > its using both ovs-controller and ovs-vswitchd > > Regards, > > Ananthakrishnan > > > > > > On Fri, Jun 7, 2013 at 8:22 PM, Ben Pfaff wrote: > > > > > Why do use think it would make a difference? > > > > > > On Fri, Jun 07, 2013 at 08:16:52PM +0530, kevin parker wrote: > > > > Can some one please clarify this,why ovs-vswitchd is used even in > secure > > > > mode > > > > > > > > > > > > On Thu, Jun 6, 2013 at 10:58 AM, kevin parker < > kevin.parker...@gmail.com > > > >wrote: > > > > > > > > > and with out controller and in standalone ovs-vswitchd is at ~80% > for > > > the > > > > > same traffic. > > > > > > > > > > using > > > > > *ovs-vsctl -V* > > > > > ovs-vsctl (Open vSwitch) 1.4.2 > > > > > Compiled Nov 23 2012 12:41:37 > > > > > > > > > > *ovs-controller -V* > > > > > ovs-controller (Open vSwitch) 1.4.0+build0 > > > > > Compiled Feb 18 2013 13:13:22 > > > > > OpenFlow versions 0x1:0x1 > > > > > > > > > > > > > > > On Thu, Jun 6, 2013 at 10:28 AM, kevin parker < > > > kevin.parker...@gmail.com>wrote: > > > > > > > > > >> Mostly HTTP, > > > > >> > > > > >> For confirming bench marked Apache with ab, ovs-vswitchd reached > 100% > > > and > > > > >> ovs-controller 14% > > > > >> > > > > >> ovs-dpctl show at the time of benchmark > > > > >> > > > > >> system@xenbr0: > > > > >> lookups: hit:55391 missed:966296 lost:0 > > > > >> flows: 0 > > > > >> port 0: xenbr0 (internal) > > > > >> port 3: vif2.1 > > > > >> port 4: vif1.1 > > > > >> > > > > >> Do i need to make any changes in ovs-controller. > > > > >> > > > > >> Thanks, > > > > >> Kevin. > > > > >> > > > > >> > > > > >> On Wed, Jun 5, 2013 at 9:56 PM, Ben Pfaff wrote: > > > > >> > > > > >>> On Wed, Jun 05, 2013 at 07:11:44PM +0530, kevin parker wrote: > > > > >>> > Hi, > > > > >>> > > > > > >>> > i have ovs-controller with default setting > (ovs-controller > > > -v > > > > >>> > ptcp:6633). > > > > >>> > > > > > >>> > > > > > >>> > on xenserver host with ovs > > > > >>> > > > > > >>> > *ovs-vsctl get-fail-mode xenbr0* > > > > >>> > *secure* > > > > >>> > > > > > >>> > I set it to secure mode to test that host should not use > vswitchd > > > for > > > > >>> flows > > > > >>> > and forward it to controller for generating flow .* > > > > >>> > * > > > > >>> > > > > > >>> > *ovs-vsctl get-controller xenbr0* > > > > >>> > *tcp:10.10.10.183:6633* > > > > >>> > * > > > > >>> > * > > > > >>> > * ovs-dpctl show > > > > >>> > * > > > > >>> > * > > > > >>> > hit:8560336 missed:1060122 lost:0 > > > > >>> > flows: 81 > > > > >>> > * > > > > >>> > > > > > >>> > where xenbr0 is an isolated bridge with no connection to host > > > > >>> interfaces. > > > > >>> > No other bridge is connected to this controller. > > > > >>> > When i ping vms on same host l can see ovs-vswitchd using 35% > > > CPU. > > > > >>> > > > > > >>> > and ovs-controller almost 11% CPU and some times non > responsive ssh > > > > >>> session > > > > >>> > on hosts. > > > > >>> > > > > >>> What kind of trafffic do you have in your network? > > > > >>> > > > > >> > > > > >> > > > > > > > > > ___ discuss mailing list discuss@openvswitch.org http://openvswitch.org/mailman/listinfo/discuss
Re: [ovs-discuss] Even with ovs-controller vswitchd is still heavily used
I thought setting secure mode would not use ovs-vswitchd, but in my case its using both ovs-controller and ovs-vswitchd Regards, Ananthakrishnan On Fri, Jun 7, 2013 at 8:22 PM, Ben Pfaff wrote: > Why do use think it would make a difference? > > On Fri, Jun 07, 2013 at 08:16:52PM +0530, kevin parker wrote: > > Can some one please clarify this,why ovs-vswitchd is used even in secure > > mode > > > > > > On Thu, Jun 6, 2013 at 10:58 AM, kevin parker >wrote: > > > > > and with out controller and in standalone ovs-vswitchd is at ~80% for > the > > > same traffic. > > > > > > using > > > *ovs-vsctl -V* > > > ovs-vsctl (Open vSwitch) 1.4.2 > > > Compiled Nov 23 2012 12:41:37 > > > > > > *ovs-controller -V* > > > ovs-controller (Open vSwitch) 1.4.0+build0 > > > Compiled Feb 18 2013 13:13:22 > > > OpenFlow versions 0x1:0x1 > > > > > > > > > On Thu, Jun 6, 2013 at 10:28 AM, kevin parker < > kevin.parker...@gmail.com>wrote: > > > > > >> Mostly HTTP, > > >> > > >> For confirming bench marked Apache with ab, ovs-vswitchd reached 100% > and > > >> ovs-controller 14% > > >> > > >> ovs-dpctl show at the time of benchmark > > >> > > >> system@xenbr0: > > >> lookups: hit:55391 missed:966296 lost:0 > > >> flows: 0 > > >> port 0: xenbr0 (internal) > > >> port 3: vif2.1 > > >> port 4: vif1.1 > > >> > > >> Do i need to make any changes in ovs-controller. > > >> > > >> Thanks, > > >> Kevin. > > >> > > >> > > >> On Wed, Jun 5, 2013 at 9:56 PM, Ben Pfaff wrote: > > >> > > >>> On Wed, Jun 05, 2013 at 07:11:44PM +0530, kevin parker wrote: > > >>> > Hi, > > >>> > > > >>> > i have ovs-controller with default setting (ovs-controller > -v > > >>> > ptcp:6633). > > >>> > > > >>> > > > >>> > on xenserver host with ovs > > >>> > > > >>> > *ovs-vsctl get-fail-mode xenbr0* > > >>> > *secure* > > >>> > > > >>> > I set it to secure mode to test that host should not use vswitchd > for > > >>> flows > > >>> > and forward it to controller for generating flow .* > > >>> > * > > >>> > > > >>> > *ovs-vsctl get-controller xenbr0* > > >>> > *tcp:10.10.10.183:6633* > > >>> > * > > >>> > * > > >>> > * ovs-dpctl show > > >>> > * > > >>> > * > > >>> > hit:8560336 missed:1060122 lost:0 > > >>> > flows: 81 > > >>> > * > > >>> > > > >>> > where xenbr0 is an isolated bridge with no connection to host > > >>> interfaces. > > >>> > No other bridge is connected to this controller. > > >>> > When i ping vms on same host l can see ovs-vswitchd using 35% > CPU. > > >>> > > > >>> > and ovs-controller almost 11% CPU and some times non responsive ssh > > >>> session > > >>> > on hosts. > > >>> > > >>> What kind of trafffic do you have in your network? > > >>> > > >> > > >> > > > > ___ discuss mailing list discuss@openvswitch.org http://openvswitch.org/mailman/listinfo/discuss
Re: [ovs-discuss] Even with ovs-controller vswitchd is still heavily used
Can some one please clarify this,why ovs-vswitchd is used even in secure mode On Thu, Jun 6, 2013 at 10:58 AM, kevin parker wrote: > and with out controller and in standalone ovs-vswitchd is at ~80% for the > same traffic. > > using > *ovs-vsctl -V* > ovs-vsctl (Open vSwitch) 1.4.2 > Compiled Nov 23 2012 12:41:37 > > *ovs-controller -V* > ovs-controller (Open vSwitch) 1.4.0+build0 > Compiled Feb 18 2013 13:13:22 > OpenFlow versions 0x1:0x1 > > > On Thu, Jun 6, 2013 at 10:28 AM, kevin parker > wrote: > >> Mostly HTTP, >> >> For confirming bench marked Apache with ab, ovs-vswitchd reached 100% and >> ovs-controller 14% >> >> ovs-dpctl show at the time of benchmark >> >> system@xenbr0: >> lookups: hit:55391 missed:966296 lost:0 >> flows: 0 >> port 0: xenbr0 (internal) >> port 3: vif2.1 >> port 4: vif1.1 >> >> Do i need to make any changes in ovs-controller. >> >> Thanks, >> Kevin. >> >> >> On Wed, Jun 5, 2013 at 9:56 PM, Ben Pfaff wrote: >> >>> On Wed, Jun 05, 2013 at 07:11:44PM +0530, kevin parker wrote: >>> > Hi, >>> > >>> > i have ovs-controller with default setting (ovs-controller -v >>> > ptcp:6633). >>> > >>> > >>> > on xenserver host with ovs >>> > >>> > *ovs-vsctl get-fail-mode xenbr0* >>> > *secure* >>> > >>> > I set it to secure mode to test that host should not use vswitchd for >>> flows >>> > and forward it to controller for generating flow .* >>> > * >>> > >>> > *ovs-vsctl get-controller xenbr0* >>> > *tcp:10.10.10.183:6633* >>> > * >>> > * >>> > * ovs-dpctl show >>> > * >>> > * >>> > hit:8560336 missed:1060122 lost:0 >>> > flows: 81 >>> > * >>> > >>> > where xenbr0 is an isolated bridge with no connection to host >>> interfaces. >>> > No other bridge is connected to this controller. >>> > When i ping vms on same host l can see ovs-vswitchd using 35% CPU. >>> > >>> > and ovs-controller almost 11% CPU and some times non responsive ssh >>> session >>> > on hosts. >>> >>> What kind of trafffic do you have in your network? >>> >> >> > ___ discuss mailing list discuss@openvswitch.org http://openvswitch.org/mailman/listinfo/discuss
Re: [ovs-discuss] Even with ovs-controller vswitchd is still heavily used
and with out controller and in standalone ovs-vswitchd is at ~80% for the same traffic. using *ovs-vsctl -V* ovs-vsctl (Open vSwitch) 1.4.2 Compiled Nov 23 2012 12:41:37 *ovs-controller -V* ovs-controller (Open vSwitch) 1.4.0+build0 Compiled Feb 18 2013 13:13:22 OpenFlow versions 0x1:0x1 On Thu, Jun 6, 2013 at 10:28 AM, kevin parker wrote: > Mostly HTTP, > > For confirming bench marked Apache with ab, ovs-vswitchd reached 100% and > ovs-controller 14% > > ovs-dpctl show at the time of benchmark > > system@xenbr0: > lookups: hit:55391 missed:966296 lost:0 > flows: 0 > port 0: xenbr0 (internal) > port 3: vif2.1 > port 4: vif1.1 > > Do i need to make any changes in ovs-controller. > > Thanks, > Kevin. > > > On Wed, Jun 5, 2013 at 9:56 PM, Ben Pfaff wrote: > >> On Wed, Jun 05, 2013 at 07:11:44PM +0530, kevin parker wrote: >> > Hi, >> > >> > i have ovs-controller with default setting (ovs-controller -v >> > ptcp:6633). >> > >> > >> > on xenserver host with ovs >> > >> > *ovs-vsctl get-fail-mode xenbr0* >> > *secure* >> > >> > I set it to secure mode to test that host should not use vswitchd for >> flows >> > and forward it to controller for generating flow .* >> > * >> > >> > *ovs-vsctl get-controller xenbr0* >> > *tcp:10.10.10.183:6633* >> > * >> > * >> > * ovs-dpctl show >> > * >> > * >> > hit:8560336 missed:1060122 lost:0 >> > flows: 81 >> > * >> > >> > where xenbr0 is an isolated bridge with no connection to host >> interfaces. >> > No other bridge is connected to this controller. >> > When i ping vms on same host l can see ovs-vswitchd using 35% CPU. >> > >> > and ovs-controller almost 11% CPU and some times non responsive ssh >> session >> > on hosts. >> >> What kind of trafffic do you have in your network? >> > > ___ discuss mailing list discuss@openvswitch.org http://openvswitch.org/mailman/listinfo/discuss
Re: [ovs-discuss] Even with ovs-controller vswitchd is still heavily used
Mostly HTTP, For confirming bench marked Apache with ab, ovs-vswitchd reached 100% and ovs-controller 14% ovs-dpctl show at the time of benchmark system@xenbr0: lookups: hit:55391 missed:966296 lost:0 flows: 0 port 0: xenbr0 (internal) port 3: vif2.1 port 4: vif1.1 Do i need to make any changes in ovs-controller. Thanks, Kevin. On Wed, Jun 5, 2013 at 9:56 PM, Ben Pfaff wrote: > On Wed, Jun 05, 2013 at 07:11:44PM +0530, kevin parker wrote: > > Hi, > > > > i have ovs-controller with default setting (ovs-controller -v > > ptcp:6633). > > > > > > on xenserver host with ovs > > > > *ovs-vsctl get-fail-mode xenbr0* > > *secure* > > > > I set it to secure mode to test that host should not use vswitchd for > flows > > and forward it to controller for generating flow .* > > * > > > > *ovs-vsctl get-controller xenbr0* > > *tcp:10.10.10.183:6633* > > * > > * > > * ovs-dpctl show > > * > > * > > hit:8560336 missed:1060122 lost:0 > > flows: 81 > > * > > > > where xenbr0 is an isolated bridge with no connection to host interfaces. > > No other bridge is connected to this controller. > > When i ping vms on same host l can see ovs-vswitchd using 35% CPU. > > > > and ovs-controller almost 11% CPU and some times non responsive ssh > session > > on hosts. > > What kind of trafffic do you have in your network? > ___ discuss mailing list discuss@openvswitch.org http://openvswitch.org/mailman/listinfo/discuss
[ovs-discuss] Even with ovs-controller vswitchd is still heavily used
Hi, i have ovs-controller with default setting (ovs-controller -v ptcp:6633). on xenserver host with ovs *ovs-vsctl get-fail-mode xenbr0* *secure* I set it to secure mode to test that host should not use vswitchd for flows and forward it to controller for generating flow .* * *ovs-vsctl get-controller xenbr0* *tcp:10.10.10.183:6633* * * * ovs-dpctl show * * hit:8560336 missed:1060122 lost:0 flows: 81 * where xenbr0 is an isolated bridge with no connection to host interfaces. No other bridge is connected to this controller. When i ping vms on same host l can see ovs-vswitchd using 35% CPU. and ovs-controller almost 11% CPU and some times non responsive ssh session on hosts. Is this normal, Regards, kevin ___ discuss mailing list discuss@openvswitch.org http://openvswitch.org/mailman/listinfo/discuss
Re: [ovs-discuss] HIgh CPU usage for ovs-vswitchd with flows
Hi Justin, Which version do u recommend,which is capable enough to use low cpu: I tested on kvm *host1* running *OVS 1.6.90* and created vm-1 and on another kvm *host2* created 2 vms (vm1 and vm2) then from vm2 and vm3 using hping3 i flooded vm1. initially flow was 500 later came down to <5 sudo ovs-dpctl show system@kvmbr0: lookups: hit:29144 missed:71485237 lost:8866 *flows: 3* port 0: xenbr0 (internal) port 1: eth1 but CPU usage of ovs-vswitchd was ~100% when i increased * flow-eviction-threshold to 2000 * * * CPU usage did not decrease but total RAM usage increased by 10% . On other vms running on *host1* there was more than 25% packet loss for ping request and broken pipe for ssh session. * * Regards, Kevin On Tue, May 28, 2013 at 10:46 PM, Jing Ai wrote: > > > Date: Mon, 27 May 2013 09:10:20 -0700 > > From: Justin Pettit > > Subject: Re: [ovs-discuss] HIgh CPU usage for ovs-vswitchd with flows > > 3069 and lost: 267425491 > > To: kevin parker > > Cc: discuss@openvswitch.org > > Message-ID: > > Content-Type: text/plain; charset=iso-8859-1 > > > > We've made a lot of improvements in flow set up rate since version 1.4, > so upgrading to a more current version (we're on 1.10 now) will likely > help. We're currently working on multithreading the OVS userspace and > adding support for wildcarded flows in the kernel, which should > substantially improve flow set up. > > > > --Justin > > > > Good to know there are ongoing efforts to improve flow setup. What are the > timelines for those features? Any patch sent out for review? Thanks! > > Best, > Jing > > > > > > On May 27, 2013, at 12:59 AM, kevin parker > wrote: > > > > > Hi, > > > > > > Running OVS 1.4 on xenserver 6.0.2 , but its taking very high cpu some > times ~100%. > > > > > > ovs-dpctl show > > > > > > system@xenbr5: > > > lookups: hit:2560723 missed:3742809 lost:0 > > > flows: 5 > > > port 0: xenbr5 (internal) > > > port 1: eth5 > > > system@xapi2: > > > lookups: hit:1660559495 missed:1241428 lost:0 > > > flows: 11 > > > port 0: xapi2 (internal) > > > port 1: eth7 > > > port 2: eth6 > > > system@xenbr4: > > > lookups: hit:2539909 missed:3729876 lost:0 > > > flows: 5 > > > port 0: xenbr4 (internal) > > > port 1: eth4 > > > system@xapi3: > > > lookups: hit:20443295213 missed:26596588140 lost:267425491 > > > flows: 3069 > > > port 0: xapi3 (internal) > > > port 1: eth1 > > > port 2: eth0 > > > port 4: xapi4 (internal) > > > port 15: vif12.0 > > > port 18: vif14.0 > > > system@xenbr2: > > > lookups: hit:1634980795 missed:166104910 lost:0 > > > flows: 127 > > > port 0: xenbr2 (internal) > > > port 1: eth2 > > > system@xenbr3: > > > lookups: hit:2450949145 missed:81360495 lost:0 > > > flows: 118 > > > port 0: xenbr3 (internal) > > > port 1: eth3 > > > port 2: xapi6 (internal) > > > port 6: vif12.1 > > > port 8: vif14.1 > > > > > > Network usage: > > > > > > dstat -n > > > > > > -net/total- > > > recv send > > > 6475k 5736k > > > 6575k 5646k > > > 6767k 6347k > > > > > > Can some one please tell me how this can be fixed. > > > > > > Regards, > > > Kevin > > ___ discuss mailing list discuss@openvswitch.org http://openvswitch.org/mailman/listinfo/discuss
Re: [ovs-discuss] HIgh CPU usage for ovs-vswitchd with flows 3069 and lost: 267425491
Thank you Justin, Could you please tell me how can i regenerate these many number of flows for testing so that i can configure threshold based on that,when i tried iperf with 1B and udp flow didn't increase and there were no packet loss.Is ovs-controller generate flow based on packet-type src and dst? Because in my case i am able to see only single flow for my udp traffic. Regards, kevin On Mon, May 27, 2013 at 10:17 PM, Justin Pettit wrote: > I'm guessing the traffic is bursty or ovs-vswitchd was busing doing other > work and the queues overflowed. > > --Justin > > > On May 27, 2013, at 9:34 AM, kevin parker > wrote: > > > Justin, > > Even at 85-90% CPU usage i am seeing increased lost > count,initially i faced high lost count when ovs-vswitchd was at 100%.So > what can be the reason for dropped packet even with 10% free cpu available. > > > > regards, > > kevin > > > > > > On Mon, May 27, 2013 at 9:40 PM, Justin Pettit > wrote: > > We've made a lot of improvements in flow set up rate since version 1.4, > so upgrading to a more current version (we're on 1.10 now) will likely > help. We're currently working on multithreading the OVS userspace and > adding support for wildcarded flows in the kernel, which should > substantially improve flow set up. > > > > --Justin > > > > > > On May 27, 2013, at 12:59 AM, kevin parker > wrote: > > > > > Hi, > > > > > > Running OVS 1.4 on xenserver 6.0.2 , but its taking very high cpu > some times ~100%. > > > > > > ovs-dpctl show > > > > > > system@xenbr5: > > > lookups: hit:2560723 missed:3742809 lost:0 > > > flows: 5 > > > port 0: xenbr5 (internal) > > > port 1: eth5 > > > system@xapi2: > > > lookups: hit:1660559495 missed:1241428 lost:0 > > > flows: 11 > > > port 0: xapi2 (internal) > > > port 1: eth7 > > > port 2: eth6 > > > system@xenbr4: > > > lookups: hit:2539909 missed:3729876 lost:0 > > > flows: 5 > > > port 0: xenbr4 (internal) > > > port 1: eth4 > > > system@xapi3: > > > lookups: hit:20443295213 missed:26596588140 lost:267425491 > > > flows: 3069 > > > port 0: xapi3 (internal) > > > port 1: eth1 > > > port 2: eth0 > > > port 4: xapi4 (internal) > > > port 15: vif12.0 > > > port 18: vif14.0 > > > system@xenbr2: > > > lookups: hit:1634980795 missed:166104910 lost:0 > > > flows: 127 > > > port 0: xenbr2 (internal) > > > port 1: eth2 > > > system@xenbr3: > > > lookups: hit:2450949145 missed:81360495 lost:0 > > > flows: 118 > > > port 0: xenbr3 (internal) > > > port 1: eth3 > > > port 2: xapi6 (internal) > > > port 6: vif12.1 > > > port 8: vif14.1 > > > > > > Network usage: > > > > > > dstat -n > > > > > > -net/total- > > > recv send > > > 6475k 5736k > > > 6575k 5646k > > > 6767k 6347k > > > > > > Can some one please tell me how this can be fixed. > > > > > > Regards, > > > Kevin > > > > > > > > > > > > > > > ___ > > > discuss mailing list > > > discuss@openvswitch.org > > > http://openvswitch.org/mailman/listinfo/discuss > > > > > > ___ discuss mailing list discuss@openvswitch.org http://openvswitch.org/mailman/listinfo/discuss
Re: [ovs-discuss] HIgh CPU usage for ovs-vswitchd with flows 3069 and lost: 267425491
Justin, Even at 85-90% CPU usage i am seeing increased lost count,initially i faced high lost count when ovs-vswitchd was at 100%.So what can be the reason for dropped packet even with 10% free cpu available. regards, kevin On Mon, May 27, 2013 at 9:40 PM, Justin Pettit wrote: > We've made a lot of improvements in flow set up rate since version 1.4, so > upgrading to a more current version (we're on 1.10 now) will likely help. > We're currently working on multithreading the OVS userspace and adding > support for wildcarded flows in the kernel, which should substantially > improve flow set up. > > --Justin > > > On May 27, 2013, at 12:59 AM, kevin parker > wrote: > > > Hi, > > > > Running OVS 1.4 on xenserver 6.0.2 , but its taking very high cpu > some times ~100%. > > > > ovs-dpctl show > > > > system@xenbr5: > > lookups: hit:2560723 missed:3742809 lost:0 > > flows: 5 > > port 0: xenbr5 (internal) > > port 1: eth5 > > system@xapi2: > > lookups: hit:1660559495 missed:1241428 lost:0 > > flows: 11 > > port 0: xapi2 (internal) > > port 1: eth7 > > port 2: eth6 > > system@xenbr4: > > lookups: hit:2539909 missed:3729876 lost:0 > > flows: 5 > > port 0: xenbr4 (internal) > > port 1: eth4 > > system@xapi3: > > lookups: hit:20443295213 missed:26596588140 lost:267425491 > > flows: 3069 > > port 0: xapi3 (internal) > > port 1: eth1 > > port 2: eth0 > > port 4: xapi4 (internal) > > port 15: vif12.0 > > port 18: vif14.0 > > system@xenbr2: > > lookups: hit:1634980795 missed:166104910 lost:0 > > flows: 127 > > port 0: xenbr2 (internal) > > port 1: eth2 > > system@xenbr3: > > lookups: hit:2450949145 missed:81360495 lost:0 > > flows: 118 > > port 0: xenbr3 (internal) > > port 1: eth3 > > port 2: xapi6 (internal) > > port 6: vif12.1 > > port 8: vif14.1 > > > > Network usage: > > > > dstat -n > > > > -net/total- > > recv send > > 6475k 5736k > > 6575k 5646k > > 6767k 6347k > > > > Can some one please tell me how this can be fixed. > > > > Regards, > > Kevin > > > > > > > > > > ___ > > discuss mailing list > > discuss@openvswitch.org > > http://openvswitch.org/mailman/listinfo/discuss > > ___ discuss mailing list discuss@openvswitch.org http://openvswitch.org/mailman/listinfo/discuss
[ovs-discuss] HIgh CPU usage for ovs-vswitchd with flows 3069 and lost: 267425491
Hi, Running OVS 1.4 on xenserver 6.0.2 , but its taking very high cpu some times ~100%. *ovs-dpctl show* * * system@xenbr5: lookups: hit:2560723 missed:3742809 lost:0 flows: 5 port 0: xenbr5 (internal) port 1: eth5 system@xapi2: lookups: hit:1660559495 missed:1241428 lost:0 flows: 11 port 0: xapi2 (internal) port 1: eth7 port 2: eth6 system@xenbr4: lookups: hit:2539909 missed:3729876 lost:0 flows: 5 port 0: xenbr4 (internal) port 1: eth4 system@xapi3: lookups: hit:20443295213 missed:26596588140 *lost:267425491* flows: 3069 port 0: xapi3 (internal) port 1: eth1 port 2: eth0 port 4: xapi4 (internal) port 15: vif12.0 port 18: vif14.0 system@xenbr2: lookups: hit:1634980795 missed:166104910 lost:0 flows: 127 port 0: xenbr2 (internal) port 1: eth2 system@xenbr3: lookups: hit:2450949145 missed:81360495 lost:0 flows: 118 port 0: xenbr3 (internal) port 1: eth3 port 2: xapi6 (internal) port 6: vif12.1 port 8: vif14.1 *Network usage:* * * *dstat -n* * * *-net/total-* * recv send* 6475k 5736k 6575k 5646k 6767k 6347k Can some one please tell me how this can be fixed. Regards, Kevin ___ discuss mailing list discuss@openvswitch.org http://openvswitch.org/mailman/listinfo/discuss
Re: [ovs-discuss] How can this work with out _dst ?
All incoming packets should be dropped as there is no rule for incoming
traffic.But packets are going in and out.
I tried tcpdump to troubleshoot:
*
*
*1.DROP all in_port 2*
in_port=2 priority=299 action=drop"tcpdump :As expected no
incoming/outgoing packets.
*
*
*2.Allowed incoming ARP *
in_port=2 priority=303 dl_type=0x0806 dl_dst=6a:3b:ad:97:c9:8a
nw_dst=5.x.x.125 idle_timeout=0 action=normal
tcpdump: As expected tcpdump shows ARP request from other vms.
*
*
*3.Allowed incoming IP packets *
in_port=2 priority=304 dl_type=0x0800 nw_dst=5.x.x.125
dl_dst=6a:3b:ad:97:c9:8a action=normal"
tcpdump:As expected shows icmp echo request .
Above 3 as expected:but when
*1.DROP all in_port 2*
in_port=2 priority=299 action=drop"
*2.Allowed Outgoing ARP*
"in_port=2 priority=301 dl_type=0x0800 nw_src=5.x.x.125
dl_src=6a:3b:ad:97:c9:8a action=normal"
*3.Allowed outgoing packets*
"in_port=2 priority=302 dl_type=0x0806 nw_src=5.x.x.125
dl_src=6a:3b:ad:97:c9:8a action=normal"
Both incoming and outgoing worked.
Regards,
kev
On Tue, May 21, 2013 at 11:30 AM, Ben Pfaff wrote:
> Same procedure, except that you have to instead figure out where you
> think it should be dropped and was not.
>
> On Tue, May 21, 2013 at 11:26:55AM +0530, kevin parker wrote:
> > Thank You Ben for the detailed description,but my issue is everything is
> > working :) .I hope it shouldn't work so that i can troubleshoot the
> issue.
> > The only thing i am not able to understand is how packets are reaching my
> > vm with out *nw_dst* and *dl_dst*.
> >
> >
> > On Mon, May 20, 2013 at 11:47 PM, Ben Pfaff wrote:
> >
> > > On Sat, May 18, 2013 at 02:47:50PM +0530, kevin parker wrote:
> > > > Can some one please say how this work?
> > > >
> > > >
> > >
> 1.priority=400,arp,in_port=2,dl_src=6a:3b:ad:97:c9:8a,nw_src=5.x.x.12,arp_sha=6a:3b:ad:97:c9:8a
> > > > actions=NORMAL
> > > >
> > > > 2.priority=399,ip,in_port=2,dl_src=6a:3b:ad:97:c9:8a,nw_src=5.x.x.12
> > > > actions=NORMAL
> > > >
> > > > 3.priority=398,in_port=2 actions=drop
> > > >
> > > > 4.priority=0 actions=NORMAL
> > > >
> > > > i have only enabled outgoing IP and ARP,but still i am able to
> connect
> > > > through dis.How can packet go in with out *nw_dst *and *dl_dst*.?
> > >
> > > It's hard for us to guess what you expect to work or not work.
> > >
> > > This procedure described in the FAQ might help you figure out what's
> > > going on or at least to clarify your question.
> > >
> > > Q: I have a sophisticated network setup involving Open vSwitch, VMs or
> > >multiple hosts, and other components. The behavior isn't what I
> > >expect. Help!
> > >
> > > A: To debug network behavior problems, trace the path of a packet,
> > >hop-by-hop, from its origin in one host to a remote host. If
> > >that's correct, then trace the path of the response packet back to
> > >the origin.
> > >
> > >Usually a simple ICMP echo request and reply ("ping") packet is
> > >good enough. Start by initiating an ongoing "ping" from the origin
> > >host to a remote host. If you are tracking down a connectivity
> > >problem, the "ping" will not display any successful output, but
> > >packets are still being sent. (In this case the packets being sent
> > >are likely ARP rather than ICMP.)
> > >
> > >Tools available for tracing include the following:
> > >
> > >- "tcpdump" and "wireshark" for observing hops across network
> > > devices, such as Open vSwitch internal devices and physical
> > > wires.
> > >
> > >- "ovs-appctl dpif/dump-flows " in Open vSwitch 1.10 and
> > > later or "ovs-dpctl dump-flows " in earlier versions.
> > > These tools allow one to observe the actions being taken on
> > > packets in ongoing flows.
> > >
> > > See ovs-vswitchd(8) for "ovs-appctl dpif/dump-flows"
> > > documentation, ovs-dpctl(8) for "ovs-dpctl dump-flows"
> > > documentation, and "Why are there so many different ways to
> > > dump flows?" above for some background.
> > >
> > >- "ovs-appctl ofproto/trace" to observe the logic behind how
> > > ovs-vswitchd treats packets.
Re: [ovs-discuss] How can this work with out _dst ?
Thank You Ben for the detailed description,but my issue is everything is
working :) .I hope it shouldn't work so that i can troubleshoot the issue.
The only thing i am not able to understand is how packets are reaching my
vm with out *nw_dst* and *dl_dst*.
On Mon, May 20, 2013 at 11:47 PM, Ben Pfaff wrote:
> On Sat, May 18, 2013 at 02:47:50PM +0530, kevin parker wrote:
> > Can some one please say how this work?
> >
> >
> 1.priority=400,arp,in_port=2,dl_src=6a:3b:ad:97:c9:8a,nw_src=5.x.x.12,arp_sha=6a:3b:ad:97:c9:8a
> > actions=NORMAL
> >
> > 2.priority=399,ip,in_port=2,dl_src=6a:3b:ad:97:c9:8a,nw_src=5.x.x.12
> > actions=NORMAL
> >
> > 3.priority=398,in_port=2 actions=drop
> >
> > 4.priority=0 actions=NORMAL
> >
> > i have only enabled outgoing IP and ARP,but still i am able to connect
> > through dis.How can packet go in with out *nw_dst *and *dl_dst*.?
>
> It's hard for us to guess what you expect to work or not work.
>
> This procedure described in the FAQ might help you figure out what's
> going on or at least to clarify your question.
>
> Q: I have a sophisticated network setup involving Open vSwitch, VMs or
>multiple hosts, and other components. The behavior isn't what I
>expect. Help!
>
> A: To debug network behavior problems, trace the path of a packet,
>hop-by-hop, from its origin in one host to a remote host. If
>that's correct, then trace the path of the response packet back to
>the origin.
>
>Usually a simple ICMP echo request and reply ("ping") packet is
>good enough. Start by initiating an ongoing "ping" from the origin
>host to a remote host. If you are tracking down a connectivity
>problem, the "ping" will not display any successful output, but
>packets are still being sent. (In this case the packets being sent
>are likely ARP rather than ICMP.)
>
>Tools available for tracing include the following:
>
>- "tcpdump" and "wireshark" for observing hops across network
> devices, such as Open vSwitch internal devices and physical
> wires.
>
>- "ovs-appctl dpif/dump-flows " in Open vSwitch 1.10 and
> later or "ovs-dpctl dump-flows " in earlier versions.
> These tools allow one to observe the actions being taken on
> packets in ongoing flows.
>
> See ovs-vswitchd(8) for "ovs-appctl dpif/dump-flows"
> documentation, ovs-dpctl(8) for "ovs-dpctl dump-flows"
> documentation, and "Why are there so many different ways to
> dump flows?" above for some background.
>
>- "ovs-appctl ofproto/trace" to observe the logic behind how
> ovs-vswitchd treats packets. See ovs-vswitchd(8) for
> documentation. You can out more details about a given flow
> that "ovs-dpctl dump-flows" displays, by cutting and pasting
> a flow from the output into an "ovs-appctl ofproto/trace"
> command.
>
>- SPAN, RSPAN, and ERSPAN features of physical switches, to
> observe what goes on at these physical hops.
>
>Starting at the origin of a given packet, observe the packet at
>each hop in turn. For example, in one plausible scenario, you
>might:
>
>1. "tcpdump" the "eth" interface through which an ARP egresses
> a VM, from inside the VM.
>
>2. "tcpdump" the "vif" or "tap" interface through which the ARP
> ingresses the host machine.
>
>3. Use "ovs-dpctl dump-flows" to spot the ARP flow and observe
> the host interface through which the ARP egresses the
> physical machine. You may need to use "ovs-dpctl show" to
> interpret the port numbers. If the output seems surprising,
> you can use "ovs-appctl ofproto/trace" to observe details of
> how ovs-vswitchd determined the actions in the "ovs-dpctl
> dump-flows" output.
>
>4. "tcpdump" the "eth" interface through which the ARP egresses
> the physical machine.
>
>5. "tcpdump" the "eth" interface through which the ARP
> ingresses the physical machine, at the remote host that
> receives the ARP.
>
>6. Use "ovs-dpctl dump-flows" to spot the ARP flow on the
> remote host that receives the ARP and observe the VM "vif"
> or "tap" interface to which the flow is directed. Again,
> "ovs-dpctl show" and "ovs-appctl ofproto/trace" might help.
>
>7. "tcpdump" the "vif" or "tap" interface to which the ARP is
> directed.
>
>8. "tcpdump" the "eth" interface through which the ARP
> ingresses a VM, from inside the VM.
>
>It is likely that during one of these steps you will figure out the
>problem. If not, then follow the ARP reply back to the origin, in
>reverse.
>
>
___
discuss mailing list
discuss@openvswitch.org
http://openvswitch.org/mailman/listinfo/discuss
[ovs-discuss] How can this work with out _dst ?
Hi, Can some one please say how this work? 1.priority=400,arp,in_port=2,dl_src=6a:3b:ad:97:c9:8a,nw_src=5.x.x.12,arp_sha=6a:3b:ad:97:c9:8a actions=NORMAL 2.priority=399,ip,in_port=2,dl_src=6a:3b:ad:97:c9:8a,nw_src=5.x.x.12 actions=NORMAL 3.priority=398,in_port=2 actions=drop 4.priority=0 actions=NORMAL i have only enabled outgoing IP and ARP,but still i am able to connect through dis.How can packet go in with out *nw_dst *and *dl_dst*.? Initially i was using with out *in_port *and it was working as expected ie * nw_dst*,*dl_dst*,*nw_src*,*dl_src* were required for connection to takes place.Whts the big difference,can some only clarify this. kev ___ discuss mailing list discuss@openvswitch.org http://openvswitch.org/mailman/listinfo/discuss
