Re: [ovs-discuss] ovsdb-server listen ptcp: and ovs-* utils
On Fri, Oct 04, 2013 at 09:45:16AM +0400, Vasiliy Tolstov wrote: > I want to debug own ovsdb client and needed that ovsdb-server listens > for tcp connection on some port. How can i specify to listen ptcp and > punix in same time? Use multiple --remote options. ___ discuss mailing list discuss@openvswitch.org http://openvswitch.org/mailman/listinfo/discuss
[ovs-discuss] ovsdb-server listen ptcp: and ovs-* utils
Hello! I want to debug own ovsdb client and needed that ovsdb-server listens for tcp connection on some port. How can i specify to listen ptcp and punix in same time? -- Vasiliy Tolstov, e-mail: v.tols...@selfip.ru jabber: v...@selfip.ru ___ discuss mailing list discuss@openvswitch.org http://openvswitch.org/mailman/listinfo/discuss
Re: [ovs-discuss] Trunk & Vlan tag with ovsbr0,eth0 and vnet0
Hi Ben, I have gone through OVS FAQ , but not able to understand Scenario 3 from FAQ. So could you please help me in same ? Thanks & Regards Ashish On Fri, Oct 4, 2013 at 10:16 AM, Ben Pfaff wrote: > The results you explain in all of your scenarios are what I would expect > to happen. Did you read the introduction to VLANs in the OVS FAQ? > > Q: What's a VLAN? > > A: At the simplest level, a VLAN (short for "virtual LAN") is a way to >partition a single switch into multiple switches. Suppose, for >example, that you have two groups of machines, group A and group B. >You want the machines in group A to be able to talk to each other, >and you want the machine in group B to be able to talk to each >other, but you don't want the machines in group A to be able to >talk to the machines in group B. You can do this with two >switches, by plugging the machines in group A into one switch and >the machines in group B into the other switch. > >If you only have one switch, then you can use VLANs to do the same >thing, by configuring the ports for machines in group A as VLAN >"access ports" for one VLAN and the ports for group B as "access >ports" for a different VLAN. The switch will only forward packets >between ports that are assigned to the same VLAN, so this >effectively subdivides your single switch into two independent >switches, one for each group of machines. > >So far we haven't said anything about VLAN headers. With access >ports, like we've described so far, no VLAN header is present in >the Ethernet frame. This means that the machines (or switches) >connected to access ports need not be aware that VLANs are >involved, just like in the case where we use two different physical >switches. > >Now suppose that you have a whole bunch of switches in your >network, instead of just one, and that some machines in group A are >connected directly to both switches 1 and 2. To allow these >machines to talk to each other, you could add an access port for >group A's VLAN to switch 1 and another to switch 2, and then >connect an Ethernet cable between those ports. That works fine, >but it doesn't scale well as the number of switches and the number >of VLANs increases, because you use up a lot of valuable switch >ports just connecting together your VLANs. > >This is where VLAN headers come in. Instead of using one cable and >two ports per VLAN to connect a pair of switches, we configure a >port on each switch as a VLAN "trunk port". Packets sent and >received on a trunk port carry a VLAN header that says what VLAN >the packet belongs to, so that only two ports total are required to >connect the switches, regardless of the number of VLANs in use. >Normally, only switches (either physical or virtual) are connected >to a trunk port, not individual hosts, because individual hosts >don't expect to see a VLAN header in the traffic that they receive. > >None of the above discussion says anything about particular VLAN >numbers. This is because VLAN numbers are completely arbitrary. >One must only ensure that a given VLAN is numbered consistently >throughout a network and that different VLANs are given different >numbers. (That said, VLAN 0 is usually synonymous with a packet >that has no VLAN header, and VLAN 4095 is reserved.) > > On Fri, Oct 04, 2013 at 10:12:08AM +0530, ashish yadav wrote: > > Hi, > > > > Could anyone please look into these fundamental queries of OVS & Vlan > and > > reply ? > > > > > > Thanks & Regards > >Ashish > > > > > > On Thu, Oct 3, 2013 at 9:42 PM, ashish yadav >wrote: > > > > > Hi, > > > > > > I was doing some exercise, came across few scenario. > > > I need help to understand these cases. > > > > > > *Environment: * > > > a. One Host and one VM in it > > > b. OVS running: > > > [root@sholay ashish]# ovs-vsctl show > > > 2b113c03-81e5-4c90-ba6c-b2eb2381432a > > > Bridge "ovsbr0" > > > Port "ovsbr0" > > > Interface "ovsbr0" > > > type: internal > > > Port "vnet0" > > > Interface "vnet0" > > > Port "eth0" > > > Interface "eth0" > > > ovs_version: "1.4.6" > > > > > > VM is up and I am able to ping: > > > a. External World from VM & Host. > > > b. Ping between HOST & VM fine. > > > > > > *Scenario 1:* > > > vnet0 is vlan tag: > > >[root@sholay ashish]# ovs-vsctl show > > > 2b113c03-81e5-4c90-ba6c-b2eb2381432a > > > Bridge "ovsbr0" > > > Port "ovsbr0" > > > tag: 0 > > > Interface "ovsbr0" > > > type: internal > > > Port "vnet0" > > > tag: 5 > > > Interface "vnet0" > > > Port "eth0" > > > tag: 0 > > > Interface "eth0" > > > ovs_version: "1.4.6" > > > > > > a. From VM, not
Re: [ovs-discuss] Trunk & Vlan tag with ovsbr0,eth0 and vnet0
The results you explain in all of your scenarios are what I would expect to happen. Did you read the introduction to VLANs in the OVS FAQ? Q: What's a VLAN? A: At the simplest level, a VLAN (short for "virtual LAN") is a way to partition a single switch into multiple switches. Suppose, for example, that you have two groups of machines, group A and group B. You want the machines in group A to be able to talk to each other, and you want the machine in group B to be able to talk to each other, but you don't want the machines in group A to be able to talk to the machines in group B. You can do this with two switches, by plugging the machines in group A into one switch and the machines in group B into the other switch. If you only have one switch, then you can use VLANs to do the same thing, by configuring the ports for machines in group A as VLAN "access ports" for one VLAN and the ports for group B as "access ports" for a different VLAN. The switch will only forward packets between ports that are assigned to the same VLAN, so this effectively subdivides your single switch into two independent switches, one for each group of machines. So far we haven't said anything about VLAN headers. With access ports, like we've described so far, no VLAN header is present in the Ethernet frame. This means that the machines (or switches) connected to access ports need not be aware that VLANs are involved, just like in the case where we use two different physical switches. Now suppose that you have a whole bunch of switches in your network, instead of just one, and that some machines in group A are connected directly to both switches 1 and 2. To allow these machines to talk to each other, you could add an access port for group A's VLAN to switch 1 and another to switch 2, and then connect an Ethernet cable between those ports. That works fine, but it doesn't scale well as the number of switches and the number of VLANs increases, because you use up a lot of valuable switch ports just connecting together your VLANs. This is where VLAN headers come in. Instead of using one cable and two ports per VLAN to connect a pair of switches, we configure a port on each switch as a VLAN "trunk port". Packets sent and received on a trunk port carry a VLAN header that says what VLAN the packet belongs to, so that only two ports total are required to connect the switches, regardless of the number of VLANs in use. Normally, only switches (either physical or virtual) are connected to a trunk port, not individual hosts, because individual hosts don't expect to see a VLAN header in the traffic that they receive. None of the above discussion says anything about particular VLAN numbers. This is because VLAN numbers are completely arbitrary. One must only ensure that a given VLAN is numbered consistently throughout a network and that different VLANs are given different numbers. (That said, VLAN 0 is usually synonymous with a packet that has no VLAN header, and VLAN 4095 is reserved.) On Fri, Oct 04, 2013 at 10:12:08AM +0530, ashish yadav wrote: > Hi, > > Could anyone please look into these fundamental queries of OVS & Vlan and > reply ? > > > Thanks & Regards >Ashish > > > On Thu, Oct 3, 2013 at 9:42 PM, ashish yadav wrote: > > > Hi, > > > > I was doing some exercise, came across few scenario. > > I need help to understand these cases. > > > > *Environment: * > > a. One Host and one VM in it > > b. OVS running: > > [root@sholay ashish]# ovs-vsctl show > > 2b113c03-81e5-4c90-ba6c-b2eb2381432a > > Bridge "ovsbr0" > > Port "ovsbr0" > > Interface "ovsbr0" > > type: internal > > Port "vnet0" > > Interface "vnet0" > > Port "eth0" > > Interface "eth0" > > ovs_version: "1.4.6" > > > > VM is up and I am able to ping: > > a. External World from VM & Host. > > b. Ping between HOST & VM fine. > > > > *Scenario 1:* > > vnet0 is vlan tag: > >[root@sholay ashish]# ovs-vsctl show > > 2b113c03-81e5-4c90-ba6c-b2eb2381432a > > Bridge "ovsbr0" > > Port "ovsbr0" > > tag: 0 > > Interface "ovsbr0" > > type: internal > > Port "vnet0" > > tag: 5 > > Interface "vnet0" > > Port "eth0" > > tag: 0 > > Interface "eth0" > > ovs_version: "1.4.6" > > > > a. From VM, not able to ping Host machine & External world. > > b. From Host, able to ping External world. > > > > This is desired behaviour. No problem here. > > > > > > *Scenario 2:* > >ovsbr0 & vent0 are Vlan Tag: > >[root@sholay ashish]# ovs-vsctl show > > 2b113c03-81e5-4c90-ba6c-b2eb2381432a > > Bridge "ovsbr0" > > Port "ovsbr0" > > tag: 5 > > Interfac
Re: [ovs-discuss] Trunk & Vlan tag with ovsbr0,eth0 and vnet0
Hi, Could anyone please look into these fundamental queries of OVS & Vlan and reply ? Thanks & Regards Ashish On Thu, Oct 3, 2013 at 9:42 PM, ashish yadav wrote: > Hi, > > I was doing some exercise, came across few scenario. > I need help to understand these cases. > > *Environment: * > a. One Host and one VM in it > b. OVS running: > [root@sholay ashish]# ovs-vsctl show > 2b113c03-81e5-4c90-ba6c-b2eb2381432a > Bridge "ovsbr0" > Port "ovsbr0" > Interface "ovsbr0" > type: internal > Port "vnet0" > Interface "vnet0" > Port "eth0" > Interface "eth0" > ovs_version: "1.4.6" > > VM is up and I am able to ping: > a. External World from VM & Host. > b. Ping between HOST & VM fine. > > *Scenario 1:* > vnet0 is vlan tag: >[root@sholay ashish]# ovs-vsctl show > 2b113c03-81e5-4c90-ba6c-b2eb2381432a > Bridge "ovsbr0" > Port "ovsbr0" > tag: 0 > Interface "ovsbr0" > type: internal > Port "vnet0" > tag: 5 > Interface "vnet0" > Port "eth0" > tag: 0 > Interface "eth0" > ovs_version: "1.4.6" > > a. From VM, not able to ping Host machine & External world. > b. From Host, able to ping External world. > > This is desired behaviour. No problem here. > > > *Scenario 2:* >ovsbr0 & vent0 are Vlan Tag: >[root@sholay ashish]# ovs-vsctl show > 2b113c03-81e5-4c90-ba6c-b2eb2381432a > Bridge "ovsbr0" > Port "ovsbr0" > tag: 5 > Interface "ovsbr0" > type: internal > Port "vnet0" > tag: 5 > Interface "vnet0" > Port "eth0" > tag: 0 > Interface "eth0" > ovs_version: "1.4.6" > > a. VM is able to Ping host, but Fail to ping External world. > * Why it is so ?* > b. Host Machine Fail to ping External world. > *Why its is so ?* > > > *Scenario 3:* > eth0 & vent0 are Vlan Tag: > [root@sholay ashish]# ovs-vsctl show > 2b113c03-81e5-4c90-ba6c-b2eb2381432a > Bridge "ovsbr0" > Port "ovsbr0" > tag: 0 > Interface "ovsbr0" > type: internal > Port "vnet0" > tag: 5 > Interface "vnet0" > Port "eth0" > tag: 5 > Interface "eth0" > ovs_version: "1.4.6" > > a. VM able to ping external world, but fail to ping host ip. > * Why it is so ?* > b. Host Machine not able to ping external world. > *Why VM can excess external world, but host not ?* > > > Thanks & Regards > Ashish > > ___ discuss mailing list discuss@openvswitch.org http://openvswitch.org/mailman/listinfo/discuss
Re: [ovs-discuss] ovsdb protocol version
2013/10/4 Ben Pfaff : > I don't understand why you think it's a strange choice to use the string > value "unlimited", for an unlimited value, or an integer, when an > integer limit is wanted. On the contrary, to me it seems transparently > easy to understand. Yes, name is very transparently to understand. I have a question only from encoding/decoding side of json. And in many software for unlimited used number -1 to say that it is not null.. -- Vasiliy Tolstov, e-mail: v.tols...@selfip.ru jabber: v...@selfip.ru ___ discuss mailing list discuss@openvswitch.org http://openvswitch.org/mailman/listinfo/discuss
Re: [ovs-discuss] ovsdb protocol version
On Fri, Oct 04, 2013 at 08:10:12AM +0400, Vasiliy Tolstov wrote: > 2013/10/4 Ben Pfaff : > > The format is flexible and I didn't have a reason not to use it. > > Yes, but why not use single type for example string in this case and > not use OR ? I don't understand why you think it's a strange choice to use the string value "unlimited", for an unlimited value, or an integer, when an integer limit is wanted. On the contrary, to me it seems transparently easy to understand. ___ discuss mailing list discuss@openvswitch.org http://openvswitch.org/mailman/listinfo/discuss
Re: [ovs-discuss] ovsdb protocol version
2013/10/4 Ben Pfaff : > The format is flexible and I didn't have a reason not to use it. Yes, but why not use single type for example string in this case and not use OR ? -- Vasiliy Tolstov, e-mail: v.tols...@selfip.ru jabber: v...@selfip.ru ___ discuss mailing list discuss@openvswitch.org http://openvswitch.org/mailman/listinfo/discuss
Re: [ovs-discuss] ovsdb protocol version
On Fri, Oct 04, 2013 at 08:01:45AM +0400, Vasiliy Tolstov wrote: > I have a question about : > https://tools.ietf.org/html/draft-pfaff-ovsdb-proto-04, Why Max > integer or string? Why no use -1 for max for example? > In case of integer or sting this creates problems with automatic > encoding/decoding this json type =( The format is flexible and I didn't have a reason not to use it. > > The type of a database column. Either an or a JSON > object that describes the type of a database column, with the > following members: > > > "key": required > "value":optional > "min":optional > "max": or "unlimited"optional > > If "min" or "max" is not specified, each defaults to 1. If "max" > is specified as "unlimited", then there is no specified maximum > number of elements, although the implementation will enforce some > limit. After considering defaults, "min" must be exactly 0 or > exactly 1, "max" must be at least 1, and "max" must be greater > than or equal to "min". ___ discuss mailing list discuss@openvswitch.org http://openvswitch.org/mailman/listinfo/discuss
Re: [ovs-discuss] ovsdb protocol version
2013/10/4 Ben Pfaff : > All the versions of the draft describe the current vswitch, but the > newer versions are slightly better worded. Thanks, Ben! I have a question about : https://tools.ietf.org/html/draft-pfaff-ovsdb-proto-04, Why Max integer or string? Why no use -1 for max for example? In case of integer or sting this creates problems with automatic encoding/decoding this json type =( The type of a database column. Either an or a JSON object that describes the type of a database column, with the following members: "key": required "value":optional "min":optional "max": or "unlimited"optional If "min" or "max" is not specified, each defaults to 1. If "max" is specified as "unlimited", then there is no specified maximum number of elements, although the implementation will enforce some limit. After considering defaults, "min" must be exactly 0 or exactly 1, "max" must be at least 1, and "max" must be greater than or equal to "min". -- Vasiliy Tolstov, e-mail: v.tols...@selfip.ru jabber: v...@selfip.ru ___ discuss mailing list discuss@openvswitch.org http://openvswitch.org/mailman/listinfo/discuss
Re: [ovs-discuss] ovsdb protocol version
On Fri, Oct 04, 2013 at 07:45:48AM +0400, Vasiliy Tolstov wrote: > I'm try to implement in controller ovsdb protocol to control ovs. > I see that in ietf site two protocols version 02 and 04. > What version use current vSwitch 2.0 ? All the versions of the draft describe the current vswitch, but the newer versions are slightly better worded. ___ discuss mailing list discuss@openvswitch.org http://openvswitch.org/mailman/listinfo/discuss
[ovs-discuss] ovsdb protocol version
Hi All. I'm try to implement in controller ovsdb protocol to control ovs. I see that in ietf site two protocols version 02 and 04. What version use current vSwitch 2.0 ? -- Vasiliy Tolstov, e-mail: v.tols...@selfip.ru jabber: v...@selfip.ru ___ discuss mailing list discuss@openvswitch.org http://openvswitch.org/mailman/listinfo/discuss
Re: [ovs-discuss] Kernel oops running Open vSwitch on 3.3 Kernel (ARM)
Both of these functions are pretty innocuous, don't work with shared data, and shouldn't be architecture-specific. Furthermore, given that the problem remains essentially the same but moves around between versions indicates to me that the issue isn't with the code itself. It sounds to me that there is a larger issue with corruption - either by something else in memory, running off the end of the stack, etc. That is obviously difficult to track down but it might explain why the problem appears to be specific to your environment (I've never heard a report of this before). On Thu, Oct 3, 2013 at 1:38 AM, Michele Bozier wrote: > Jesse, > > Many thanks for your suggestions. > For the openvswitch.ko module built from the Open vSwitch git repository, the > line of code causing the kernel oops appears to be the following in method > ovs_flow_to_nlattrs(): > if (nla_put_u32(skb, OVS_KEY_ATTR_PRIORITY, output->phy.priority)) > goto nla_put_failure; > This is totally repeatable - happens every time. > > For the openvswitch.ko module built from the kernel 3.3 sources, the problem > is different, but again totally repeatable. > The Kernel oops is as follows: > > Unable to handle kernel NULL pointer dereference at virtual address > pgd = de3e8000 > [] *pgd=9e3c7831, *pte=, *ppte= > Internal error: Oops: 817 [#1] PREEMPT > Modules linked in: > CPU: 0Not tainted (3.3.0 #1) > PC is at ovs_flow_tbl_alloc+0x4e/0x94 > LR is at ovs_flow_tbl_alloc+0x4b/0x94 > pc : []lr : []psr: 8033 > sp : de277c50 ip : 6c6c6c6c fp : > r10: 0004 r9 : de33bf10 r8 : de32f280 > r7 : r6 : de342000 r5 : 0400 r4 : 0002 > r3 : de342000 r2 : r1 : 0002 r0 : > Flags: Nzcv IRQs on FIQs on Mode SVC_32 ISA Thumb Segment user > Control: 50c5387d Table: 9e3e8019 DAC: 0015 > Process ovs-vswitchd (pid: 454, stack limit = 0xde2762e8) > Stack: (0xde277c50 to 0xde278000) > … > [] (ovs_flow_tbl_alloc+0x4e/0x94) from [] > (ovs_dp_cmd_new+0x51/0x130) > [] (ovs_dp_cmd_new+0x51/0x130) from [] > (genl_rcv_msg+0x15f/0x17c) > [] (genl_rcv_msg+0x15f/0x17c) from [] > (netlink_rcv_skb+0x65/0x70) > [] (netlink_rcv_skb+0x65/0x70) from [] > (genl_rcv+0x17/0x20) > [] (genl_rcv+0x17/0x20) from [] > (netlink_unicast+0x117/0x150) > [] (netlink_unicast+0x117/0x150) from [] > (netlink_sendmsg+0x185/0x1cc) > [] (netlink_sendmsg+0x185/0x1cc) from [] > (sock_sendmsg+0x5f/0x74) > > In this case, the line of code causing the problem in ovs_flow_tbl_alloc() is > table->buckets = alloc_buckets(new_size); > > When I tried to put a printk to dump the new_size property in this second > scenario then the problem moved again. > What else can I try? > Regards > Michele Bozier > > > -Original Message- > From: Jesse Gross [mailto:je...@nicira.com] > Sent: 01 October 2013 20:35 > To: Michele Bozier > Cc: discuss@openvswitch.org > Subject: Re: [ovs-discuss] Kernel oops running Open vSwitch on 3.3 Kernel > (ARM) > > On Tue, Oct 1, 2013 at 2:25 AM, Michele Bozier wrote: >> I am having trouble running Open vSwitch on the ARM platform after >> cross-compiling on an i686 platform. I am using the latest code from >> master from the Open vSwitch git repository - commit Sept 26th >> (6a8a8528acb05d6d0a520e09ad1ec67e62b99e5e) and the Arago Kernel 3.3. >> >> >> >> The problem I am seeing when running on the target and trying to >> create a switch is as follows: >> >> >> >> insmod ./openvswitch.ko >> >> The module seems to install fine -on the console I get >> >> openvswitch: Open vSwitch switching datapath 2.0.90, built Sep 30 2013 >> 11:33:05 >> >> >> >> ./ovsdb-tool create /usr/local/etc/openvswitch/conf.db >> ./vswitch.ovsschema ./ovsdb-server --remote=ptcp:6634 >> --remote=db:Open_vSwitch,Open_vSwitch,manager_options >> --pidfile=/home/opf/server.pid --detach ./ovs-vsctl >> --db=tcp:127.0.0.1:6634 --no-wait init ./ovs-vswitchd >> tcp:127.0.0.1:6634 --pidfile=/home/opf/switch.pid >> --log-file=/home/opf/switch.log --detach >> >> >> >> On the console I see the following: >> >> 1970-01-01T00:01:15Z|1|vlog|INFO|opened log file >> /home/opf/switch.log >> >> 1970-01-01T00:01:15Z|2|reconnect|INFO|tcp:127.0.0.1:6634: connecting... >> >> 1970-01-01T00:01:15Z|3|reconnect|INFO|tcp:127.0.0.1:6634: >> connected >> >> >> >> I then enter the command to create a switch ./ovs-vsctl >> --db=tcp:127.0.0.1:6634 add-br opfbr >> >> >> >> I get the following output to the console >> >> device: 'ovs-system': device_add >> >> device ovs-system entered promiscuous mode >> >> device: 'opfbr0': device_add >> >> device opfbr0 entered promiscuous mode >> >> >> >> Followed shortly afterwards by a kernel oops. >> >> >> >> [root@synergy opf]# Unable to handle kernel paging request at virtual >> address 8d10051d pgd = dd84 [8d10051d] *pgd= Internal error: >> Oops: 5 [#1] PREEMPT Modules linked in: openvswitch(O) >> >> CPU: 0Tainted: G
Re: [ovs-discuss] Flow miss/Packet order question
On Thu, Oct 3, 2013 at 6:26 AM, Dmitry Fleytman wrote: > On Oct 3, 2013, at 04:20 AM, Jesse Gross wrote: >> On Wed, Oct 2, 2013 at 4:49 AM, Dmitry Fleytman wrote: >>> >>> On Apr 30, 2012, at 20:15 PM, Ben Pfaff wrote: >>> I think that your explanation stems from a misunderstanding. Yes, if an OpenFlow controller uses a reactive model, then it cannot avoid the problem. However, I think that Joji is raising a different issue, one that is an implementation detail within Open vSwitch and that controllers have no power to avoid. Let me explain in detail. When a packet arrives for which there is no kernel flow, the kernel sends it to userspace. Userspace sends the packet and sets up a kernel flow. In the meantime, more packets might have arrived and been queued to userspace. Userspace will send these packets, but any packets that arrive after the kernel flow is set up will be forwarded directly by the kernel before those queued to userspace go out. >>> >>> >>> This is exactly the problem we face while going for KVM paravirtualized >>> network driver for Windows (NetKVM) certification. >>> There are a few automated tests that send bursts of packets and wait for >>> the same packets and the same order on the other side. >>> >>> We have a POC patches (pretty dirty) that solve the problem (below). The >>> idea is simple - when datapath makes upcall it queues packets in kernel >>> until user mode completes processing and downloads a new flow. It looks >>> like overkill to queue packets per datapath, queueing per vport will be >>> enough, but it was easier to implement this way and it proves the concept >>> as well. Still, it is obvious there is performance and scaling impact so >>> another ideas are highly welcome. >>> >>> What do you think? Should we go for this solution and prepare clean patches >>> for submission? >> >> I think in order to fully solve the problem you actually need to queue >> per flow, rather than per port or per datapath. Otherwise, you end up >> serializing to one flow setup at a time, which is probably a bigger >> problem in practice than the one this is trying to solve. >> > > The problem is we are talking about moments when there is no flow for > specific packet and user mode is working on it's creation. How can we > serialise per flow in this case? You would have to track pending flows in some form, either through the flow table or a new data structure and release packets when a real flow is installed. I hope that there is a simpler way of solving this problem because it would add quite a bit of complexity (not just managing all of these queues but also enforcing limits like a socket buffer). However, this is no way that serializing at a per datapath or per port level is going to perform well enough to make that a viable solution. ___ discuss mailing list discuss@openvswitch.org http://openvswitch.org/mailman/listinfo/discuss
[ovs-discuss] Hello OpenVSwitch friends
Good morning/afternoon/evening All, Have successfully compiled/installed OpenVSwitch 1.11.0 on a CentOS 6.4 server with KVM installed and now scratching ones head. I have removed the standard Linux bridge from the ethernet interface and rebound the IP to the default NIC and rebooted. Where do I go from here now ? Any howto's for integration with CentOS 6.4 and KVM would be appreciated please. This is a stock KVM install: qemu-kvm-0.12.1.2-2.355.0.1.el6.centos.7.x86_64 qemu-kvm-tools-0.12.1.2-2.355.0.1.el6.centos.7.x86_64 so even unsure how to tell if the necessary OVS code is included ? All help appreciated :) Thank you. ___ discuss mailing list discuss@openvswitch.org http://openvswitch.org/mailman/listinfo/discuss
Re: [ovs-discuss] How to read L2 MAC tables
On Oct 2, 2013, at 7:11 PM, Morgan Yang wrote: > Thanks. Is it possible to dump the flows into the ovsdb so if I have a backup > ovs instance,, it can just load the flow information? Or, is it expected to > have redundant openflow controllers to do that? OVSDB and OpenFlow are two different protocols. Regardless, though, the learning table from the "normal" action is not remotely accessible. If you are doing learning in your controllers, though, then they'd be able to share that information with each other. In general, MAC learning is pretty fast and transparent, so I'm not sure why you'd need to pre-populate it. Since you appear to be in wireless, maybe you are expecting devices to move and want up-to-date locations? I suppose you could build something with the learn action and flow notifications, but it wouldn't be trivial. Or you could just build a local agent that monitors the FDB. The best solution is obviously going to depend on the problem you're trying to solve. --Justin ___ discuss mailing list discuss@openvswitch.org http://openvswitch.org/mailman/listinfo/discuss
Re: [ovs-discuss] OVS not forwarding
Hi all.. The output of dmesg is as follows dmesg | grep ovs [0.00] Linux version 3.5.7.17 (root@vvdnovs) (gcc version 4.6.3 (Ubuntu/Linaro 4.6.3-1ubuntu5) ) #3 SMP Thu Sep 5 09:35:11 IST 2013 () [ 351.553616] device ovs-system entered promiscuous mode root@vvdnovs:~# root@vvdnovs:~# root@vvdnovs:~# dmesg | grep openvswitch [ 13.345922] openvswitch: Open vSwitch switching datapath The bridge is still not forwarding packets after enabling IPFIX.I am using Kernel version 3.5.7.17. Can you recommend me some specific kernel version which supports IPFIX. Thanks ... Sonia On Wed, Oct 2, 2013 at 10:16 PM, Ben Pfaff wrote: > abhishek jain sent an almost identical question > yesterday: > http://openvswitch.org/pipermail/discuss/2013-October/011407.html > I responded: > http://openvswitch.org/pipermail/discuss/2013-October/011422.html > > > On Tue, Oct 1, 2013 at 12:00 AM, sonia verma wrote: > >> Hi all.. >> >> >> I am trying IPFIX with OVS version 1.11. and not able to forward packets >> after enabling IPFIX on OVS.Following are the logs after enabling IPFIX on >> OVS.. >> >> >> 2013-10-01T05:37:25Z|00259|dpif|WARN|Dropped 37 log messages in last 148 >> seconds (most recently, 147 seconds ago) due to excessive rate >> > 2013-10-01T05:37:25Z|00260|dpif|WARN|system@ovs-system: failed to >> put[modify][zero] (Numerical result out of range) >> in_port(2),eth(src=e0:db:55:a0:e1:13,dst=00:27:13:b7:2f:74),eth_type(0x0800),ipv4(src= >> 192.168.1.200/0.0.0.0,dst=192.168.1.54/0.0.0.0,proto=1/0,tos=0/0,ttl=128/0,frag=no/0xff),icmp(type=8/0,code=0/0), >> packets:0, bytes:0, used:never, >> actions:sample(sample=100.0%,actions(userspace(pid=4294962366,ipfix))),4 >> > 2013-10-01T05:37:25Z|00261|dpif|WARN|system@ovs-system: failed to >> put[modify][zero] (Numerical result out of range) >> in_port(4),eth(src=00:27:13:b7:2f:74,dst=e0:db:55:a0:e1:13),eth_type(0x0800),ipv4(src= >> 192.168.1.54/0.0.0.0,dst=192.168.1.200/0.0.0.0,proto=1/0,tos=0/0,ttl=64/0,frag=no/0xff),icmp(type=0/0,code=0/0), >> packets:0, bytes:0, used:never, >> actions:sample(sample=100.0%,actions(userspace(pid=4294962363,ipfix))),2 >> >> >> WHAT DOES IT MEAN >> >> Thanks.. >> Sonia >> >> ___ >> discuss mailing list >> discuss@openvswitch.org >> http://openvswitch.org/mailman/listinfo/discuss >> >> > > > -- > "I don't normally do acked-by's. I think it's my way of avoiding > getting blamed when it all blows up." Andrew Morton > ___ discuss mailing list discuss@openvswitch.org http://openvswitch.org/mailman/listinfo/discuss
[ovs-discuss] Trunk & Vlan tag with ovsbr0,eth0 and vnet0
Hi, I was doing some exercise, came across few scenario. I need help to understand these cases. *Environment: * a. One Host and one VM in it b. OVS running: [root@sholay ashish]# ovs-vsctl show 2b113c03-81e5-4c90-ba6c-b2eb2381432a Bridge "ovsbr0" Port "ovsbr0" Interface "ovsbr0" type: internal Port "vnet0" Interface "vnet0" Port "eth0" Interface "eth0" ovs_version: "1.4.6" VM is up and I am able to ping: a. External World from VM & Host. b. Ping between HOST & VM fine. *Scenario 1:* vnet0 is vlan tag: [root@sholay ashish]# ovs-vsctl show 2b113c03-81e5-4c90-ba6c-b2eb2381432a Bridge "ovsbr0" Port "ovsbr0" tag: 0 Interface "ovsbr0" type: internal Port "vnet0" tag: 5 Interface "vnet0" Port "eth0" tag: 0 Interface "eth0" ovs_version: "1.4.6" a. From VM, not able to ping Host machine & External world. b. From Host, able to ping External world. This is desired behaviour. No problem here. *Scenario 2:* ovsbr0 & vent0 are Vlan Tag: [root@sholay ashish]# ovs-vsctl show 2b113c03-81e5-4c90-ba6c-b2eb2381432a Bridge "ovsbr0" Port "ovsbr0" tag: 5 Interface "ovsbr0" type: internal Port "vnet0" tag: 5 Interface "vnet0" Port "eth0" tag: 0 Interface "eth0" ovs_version: "1.4.6" a. VM is able to Ping host, but Fail to ping External world. * Why it is so ?* b. Host Machine Fail to ping External world. *Why its is so ?* *Scenario 3:* eth0 & vent0 are Vlan Tag: [root@sholay ashish]# ovs-vsctl show 2b113c03-81e5-4c90-ba6c-b2eb2381432a Bridge "ovsbr0" Port "ovsbr0" tag: 0 Interface "ovsbr0" type: internal Port "vnet0" tag: 5 Interface "vnet0" Port "eth0" tag: 5 Interface "eth0" ovs_version: "1.4.6" a. VM able to ping external world, but fail to ping host ip. * Why it is so ?* b. Host Machine not able to ping external world. *Why VM can excess external world, but host not ?* Thanks & Regards Ashish ___ discuss mailing list discuss@openvswitch.org http://openvswitch.org/mailman/listinfo/discuss
Re: [ovs-discuss] iptables with ovs
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
Re: [ovs-discuss] OVS not forwarding
On Thu, Oct 03, 2013 at 07:24:33AM -0700, Gurucharan Shetty wrote: > On Wed, Oct 2, 2013 at 11:45 PM, sonia verma wrote: > > Hi all.. > > > > The output of dmesg is as follows > > > > dmesg | grep ovs > > [0.00] Linux version 3.5.7.17 (root@vvdnovs) (gcc version 4.6.3 > > (Ubuntu/Linaro 4.6.3-1ubuntu5) ) #3 SMP Thu Sep 5 09:35:11 IST 2013 () > > [ 351.553616] device ovs-system entered promiscuous mode > > root@vvdnovs:~# > > root@vvdnovs:~# > > root@vvdnovs:~# dmesg | grep openvswitch > > [ 13.345922] openvswitch: Open vSwitch switching datapath > You are most likely using the kernel module from upstream Linux kernel > and not the one that is provided with version 1.11 from the git tree > in openvswitch.org > You should probably try the one from here. It looks like kernels 3.10 and later have this feature too. ___ discuss mailing list discuss@openvswitch.org http://openvswitch.org/mailman/listinfo/discuss
Re: [ovs-discuss] OVS not forwarding
On Wed, Oct 2, 2013 at 11:45 PM, sonia verma wrote: > Hi all.. > > The output of dmesg is as follows > > dmesg | grep ovs > [0.00] Linux version 3.5.7.17 (root@vvdnovs) (gcc version 4.6.3 > (Ubuntu/Linaro 4.6.3-1ubuntu5) ) #3 SMP Thu Sep 5 09:35:11 IST 2013 () > [ 351.553616] device ovs-system entered promiscuous mode > root@vvdnovs:~# > root@vvdnovs:~# > root@vvdnovs:~# dmesg | grep openvswitch > [ 13.345922] openvswitch: Open vSwitch switching datapath You are most likely using the kernel module from upstream Linux kernel and not the one that is provided with version 1.11 from the git tree in openvswitch.org You should probably try the one from here. > > The bridge is still not forwarding packets after enabling IPFIX.I am using > Kernel version 3.5.7.17. > > Can you recommend me some specific kernel version which supports IPFIX. > > Thanks ... > Sonia > > > > > On Wed, Oct 2, 2013 at 10:16 PM, Ben Pfaff wrote: >> >> abhishek jain sent an almost identical question >> yesterday: >> http://openvswitch.org/pipermail/discuss/2013-October/011407.html >> I responded: >> http://openvswitch.org/pipermail/discuss/2013-October/011422.html >> >> >> On Tue, Oct 1, 2013 at 12:00 AM, sonia verma >> wrote: >>> >>> Hi all.. >>> >>> >>> I am trying IPFIX with OVS version 1.11. and not able to forward packets >>> after enabling IPFIX on OVS.Following are the logs after enabling IPFIX on >>> OVS.. >>> >>> >>> 2013-10-01T05:37:25Z|00259|dpif|WARN|Dropped 37 log messages in last 148 >>> seconds (most recently, 147 seconds ago) due to excessive rate >>> > 2013-10-01T05:37:25Z|00260|dpif|WARN|system@ovs-system: failed to >>> > put[modify][zero] (Numerical result out of range) >>> > in_port(2),eth(src=e0:db:55:a0:e1:13,dst=00:27:13:b7:2f:74),eth_type(0x0800),ipv4(src=192.168.1.200/0.0.0.0,dst=192.168.1.54/0.0.0.0,proto=1/0,tos=0/0,ttl=128/0,frag=no/0xff),icmp(type=8/0,code=0/0), >>> > packets:0, bytes:0, used:never, >>> > actions:sample(sample=100.0%,actions(userspace(pid=4294962366,ipfix))),4 >>> > 2013-10-01T05:37:25Z|00261|dpif|WARN|system@ovs-system: failed to >>> > put[modify][zero] (Numerical result out of range) >>> > in_port(4),eth(src=00:27:13:b7:2f:74,dst=e0:db:55:a0:e1:13),eth_type(0x0800),ipv4(src=192.168.1.54/0.0.0.0,dst=192.168.1.200/0.0.0.0,proto=1/0,tos=0/0,ttl=64/0,frag=no/0xff),icmp(type=0/0,code=0/0), >>> > packets:0, bytes:0, used:never, >>> > actions:sample(sample=100.0%,actions(userspace(pid=4294962363,ipfix))),2 >>> >>> >>> WHAT DOES IT MEAN >>> >>> Thanks.. >>> Sonia >>> >>> ___ >>> discuss mailing list >>> discuss@openvswitch.org >>> http://openvswitch.org/mailman/listinfo/discuss >>> >> >> >> >> -- >> "I don't normally do acked-by's. I think it's my way of avoiding >> getting blamed when it all blows up." Andrew Morton > > ___ discuss mailing list discuss@openvswitch.org http://openvswitch.org/mailman/listinfo/discuss
Re: [ovs-discuss] Flow miss/Packet order question
On Oct 3, 2013, at 04:20 AM, Jesse Gross wrote: > On Wed, Oct 2, 2013 at 4:49 AM, Dmitry Fleytman wrote: >> >> On Apr 30, 2012, at 20:15 PM, Ben Pfaff wrote: >> >>> I think that your explanation stems from a misunderstanding. Yes, if >>> an OpenFlow controller uses a reactive model, then it cannot avoid the >>> problem. However, I think that Joji is raising a different issue, one >>> that is an implementation detail within Open vSwitch and that >>> controllers have no power to avoid. >>> >>> Let me explain in detail. When a packet arrives for which there is no >>> kernel flow, the kernel sends it to userspace. Userspace sends the >>> packet and sets up a kernel flow. In the meantime, more packets might >>> have arrived and been queued to userspace. Userspace will send these >>> packets, but any packets that arrive after the kernel flow is set up >>> will be forwarded directly by the kernel before those queued to >>> userspace go out. >>> >> >> >> This is exactly the problem we face while going for KVM paravirtualized >> network driver for Windows (NetKVM) certification. >> There are a few automated tests that send bursts of packets and wait for the >> same packets and the same order on the other side. >> >> We have a POC patches (pretty dirty) that solve the problem (below). The >> idea is simple - when datapath makes upcall it queues packets in kernel >> until user mode completes processing and downloads a new flow. It looks like >> overkill to queue packets per datapath, queueing per vport will be enough, >> but it was easier to implement this way and it proves the concept as well. >> Still, it is obvious there is performance and scaling impact so another >> ideas are highly welcome. >> >> What do you think? Should we go for this solution and prepare clean patches >> for submission? > > I think in order to fully solve the problem you actually need to queue > per flow, rather than per port or per datapath. Otherwise, you end up > serializing to one flow setup at a time, which is probably a bigger > problem in practice than the one this is trying to solve. > The problem is we are talking about moments when there is no flow for specific packet and user mode is working on it's creation. How can we serialise per flow in this case? > It's not entirely clear to me that the general solution is really > worth the extra complexity for situations beyond the WHQL test so > there might be a bandaid for that particular problem. Do you know > exactly what it is doing? The issue is there are a few tests that verify packet ordering and they all do different things, but generally speaking this is some "test" unidirectional traffic i.e. a bunch of packets being sent without waiting for responses, exactly the problematic case. Unfortunately strict packets order is a must for MS certification. ___ discuss mailing list discuss@openvswitch.org http://openvswitch.org/mailman/listinfo/discuss
Re: [ovs-discuss] Open vswitch and an existing vlan
See, I knew this would be the group to ask. I missed that native-tagged/native-untagged was even an option. I set my eth1 port to native-tagged and voilà! We have a running switch. This thing is pretty awesome. Thanks! On Wed, Oct 2, 2013 at 7:12 PM, Ben Pfaff wrote: > On Wed, Oct 02, 2013 at 04:11:10PM -0400, Maxwell Bottiger wrote: > > I'm working off the the tutorial in the open vswitch VLANS cookbook. > I've > > followed the directions as best I could, but I still don't have things > > quite working correctly. To start with, here is my configuration: > > > > d70e42a8-1b7e-433d-a2c2-921e3c720e8e > > Bridge "bridge0" > > Port "tap1" > > tag: 2 > > Interface "tap1" > > Port "eth1" > > tag: 666 > > trunks: [2, 6] > > Interface "eth1" > > Port "tap0" > > tag: 6 > > Interface "tap0" > > Port "bridge0" > > Interface "bridge0" > > type: internal > > ovs_version: "1.4.3" > > > > > > I have eth1 of my workstation connected to the trunked port on one of my > > switches. The trunk VLAN is 666 on this setup. I have two tap > interfaces > > defined, one should be on VLAN 6, the other on VLAN 2. The desired > outcome > > is to have a virtual machine on tap0 connect straight through to VLAN6, > and > > a vm on tap1 connect directly through to the other resources on VLAN2. > I'm > > not sure if having a trunk with an odd PVID is throwing me off, or if > > there's something more I need to set. I looked at eth1 with wireshark, > and > > I can see traffic from all the other VLANs, so I'm pretty sure that > > connection is solid. I saw in other emails in the archive that people > > often wanted to see the ovs-ofctl output, so I'll include that too. > > Did you actually configure eth1 as native-tagged or native-untagged? > "ovs-vsctl show" doesn't display that, so I can't tell. > ___ 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
Re: [ovs-discuss] Kernel oops running Open vSwitch on 3.3 Kernel (ARM)
Jesse, Many thanks for your suggestions. For the openvswitch.ko module built from the Open vSwitch git repository, the line of code causing the kernel oops appears to be the following in method ovs_flow_to_nlattrs(): if (nla_put_u32(skb, OVS_KEY_ATTR_PRIORITY, output->phy.priority)) goto nla_put_failure; This is totally repeatable - happens every time. For the openvswitch.ko module built from the kernel 3.3 sources, the problem is different, but again totally repeatable. The Kernel oops is as follows: Unable to handle kernel NULL pointer dereference at virtual address pgd = de3e8000 [] *pgd=9e3c7831, *pte=, *ppte= Internal error: Oops: 817 [#1] PREEMPT Modules linked in: CPU: 0Not tainted (3.3.0 #1) PC is at ovs_flow_tbl_alloc+0x4e/0x94 LR is at ovs_flow_tbl_alloc+0x4b/0x94 pc : []lr : []psr: 8033 sp : de277c50 ip : 6c6c6c6c fp : r10: 0004 r9 : de33bf10 r8 : de32f280 r7 : r6 : de342000 r5 : 0400 r4 : 0002 r3 : de342000 r2 : r1 : 0002 r0 : Flags: Nzcv IRQs on FIQs on Mode SVC_32 ISA Thumb Segment user Control: 50c5387d Table: 9e3e8019 DAC: 0015 Process ovs-vswitchd (pid: 454, stack limit = 0xde2762e8) Stack: (0xde277c50 to 0xde278000) … [] (ovs_flow_tbl_alloc+0x4e/0x94) from [] (ovs_dp_cmd_new+0x51/0x130) [] (ovs_dp_cmd_new+0x51/0x130) from [] (genl_rcv_msg+0x15f/0x17c) [] (genl_rcv_msg+0x15f/0x17c) from [] (netlink_rcv_skb+0x65/0x70) [] (netlink_rcv_skb+0x65/0x70) from [] (genl_rcv+0x17/0x20) [] (genl_rcv+0x17/0x20) from [] (netlink_unicast+0x117/0x150) [] (netlink_unicast+0x117/0x150) from [] (netlink_sendmsg+0x185/0x1cc) [] (netlink_sendmsg+0x185/0x1cc) from [] (sock_sendmsg+0x5f/0x74) In this case, the line of code causing the problem in ovs_flow_tbl_alloc() is table->buckets = alloc_buckets(new_size); When I tried to put a printk to dump the new_size property in this second scenario then the problem moved again. What else can I try? Regards Michele Bozier -Original Message- From: Jesse Gross [mailto:je...@nicira.com] Sent: 01 October 2013 20:35 To: Michele Bozier Cc: discuss@openvswitch.org Subject: Re: [ovs-discuss] Kernel oops running Open vSwitch on 3.3 Kernel (ARM) On Tue, Oct 1, 2013 at 2:25 AM, Michele Bozier wrote: > I am having trouble running Open vSwitch on the ARM platform after > cross-compiling on an i686 platform. I am using the latest code from > master from the Open vSwitch git repository - commit Sept 26th > (6a8a8528acb05d6d0a520e09ad1ec67e62b99e5e) and the Arago Kernel 3.3. > > > > The problem I am seeing when running on the target and trying to > create a switch is as follows: > > > > insmod ./openvswitch.ko > > The module seems to install fine -on the console I get > > openvswitch: Open vSwitch switching datapath 2.0.90, built Sep 30 2013 > 11:33:05 > > > > ./ovsdb-tool create /usr/local/etc/openvswitch/conf.db > ./vswitch.ovsschema ./ovsdb-server --remote=ptcp:6634 > --remote=db:Open_vSwitch,Open_vSwitch,manager_options > --pidfile=/home/opf/server.pid --detach ./ovs-vsctl > --db=tcp:127.0.0.1:6634 --no-wait init ./ovs-vswitchd > tcp:127.0.0.1:6634 --pidfile=/home/opf/switch.pid > --log-file=/home/opf/switch.log --detach > > > > On the console I see the following: > > 1970-01-01T00:01:15Z|1|vlog|INFO|opened log file > /home/opf/switch.log > > 1970-01-01T00:01:15Z|2|reconnect|INFO|tcp:127.0.0.1:6634: connecting... > > 1970-01-01T00:01:15Z|3|reconnect|INFO|tcp:127.0.0.1:6634: > connected > > > > I then enter the command to create a switch ./ovs-vsctl > --db=tcp:127.0.0.1:6634 add-br opfbr > > > > I get the following output to the console > > device: 'ovs-system': device_add > > device ovs-system entered promiscuous mode > > device: 'opfbr0': device_add > > device opfbr0 entered promiscuous mode > > > > Followed shortly afterwards by a kernel oops. > > > > [root@synergy opf]# Unable to handle kernel paging request at virtual > address 8d10051d pgd = dd84 [8d10051d] *pgd= Internal error: > Oops: 5 [#1] PREEMPT Modules linked in: openvswitch(O) > > CPU: 0Tainted: G O (3.3.0 #7) > > PC is at ovs_flow_to_nlattrs+0x5/0x430 [openvswitch] LR is at > ovs_flow_cmd_fill_info+0x114/0x208 [openvswitch] > > pc : []lr : []psr: 8033 > > sp : de273c30 ip : 0058 fp : 0018 > > r10: de36e540 r9 : 0001fffb r8 : dd8b8000 > > r7 : 0013 r6 : 01cd r5 : dd8b8088 r4 : 0070 > > r3 : r2 : de36e540 r1 : 8d100505 r0 : 0002001b > > Flags: Nzcv IRQs on FIQs on Mode SVC_32 ISA Thumb Segment user > > Control: 50c5387d Table: 9d840019 DAC: 0015 Process ovs-vswitchd (pid: > 461, stack limit = 0xde2722e8) > > Stack: (0xde273c30 to 0xde274000) > > ... > > [] (ovs_flow_to_nlattrs+0x5/0x430 [openvswitch]) from > [] > (ovs_flow_cmd_fill_info+0x114/0x208 [openvswitch]) [] > (ovs_flow_cmd_fill_info+0x114/0x208 [openvswitch]) from [] > (o
