Re: [ovs-discuss] ovs_assert(classifier_is_empty(>cls)) failed when restart openvswitch service.

[Zhanghaibo (Euler)]

Hi Ben,

Thanks very much for your reply.

We checked patchs of bug fixes since 2.7.0 released, but did not find any patch 
that looks could fix the problem, so we did further investigation to this issue.

Here is our findings, would please kindly give your comments? Thank you.

1.  In flow learning procedure of “hanlder” thread, if old rule has already 
been existing, the rule will be deleted, and later in function 
add_flow_finish(),  remove_rule_rcu() function will be added to rcu cbset of 
“handler” thread, remove_rule_rcu() will remove the old rule from classifier of 
oftable. But even it has been added to rcu cbset, it will not be called before 
size of cbs[] reach max.

  /* To be called after version bump. */
  static void
  add_flow_finish(struct ofproto *ofproto, struct ofproto_flow_mod *ofm,
  const struct openflow_mod_requester *req)
  OVS_REQUIRES(ofproto_mutex)
  {
  struct rule *old_rule = rule_collection_n(>old_rules)
  ? rule_collection_rules(>old_rules)[0] : NULL;
  struct rule *new_rule = rule_collection_rules(>new_rules)[0];
  struct ovs_list dead_cookies = OVS_LIST_INITIALIZER(_cookies);

  replace_rule_finish(ofproto, ofm, req, old_rule, new_rule, 
_cookies);
  learned_cookies_flush(ofproto, _cookies);
  if (old_rule) {
  ovsrcu_postpone(remove_rule_rcu, old_rule);
  } else {
  ofmonitor_report(ofproto->connmgr, new_rule, NXFME_ADDED, 0,
   req ? req->ofconn : NULL,
   req ? req->request->xid : 0, NULL);

  /* Send Vacancy Events for OF1.4+. */
  send_table_status(ofproto, new_rule->table_id);
  }
  }


2.  In bridge destroy procedure of main thread, in function 
ofproto_destroy(), ofproto_destroy_defer__() will be added to cbset of “main” 
thread, it will not be called before size of cbs[] reach max.
  void
  ofproto_destroy(struct ofproto *p, bool del)
  OVS_EXCLUDED(ofproto_mutex)
  {
  struct ofport *ofport, *next_ofport;
  struct ofport_usage *usage;

  if (!p) {
  return;
  }

  if (p->meters) {
  meter_delete(p, 1, p->meter_features.max_meters);
  p->meter_features.max_meters = 0;
  free(p->meters);
  p->meters = NULL;
  }

  ofproto_flush__(p);
  HMAP_FOR_EACH_SAFE (ofport, next_ofport, hmap_node, >ports) {
  ofport_destroy(ofport, del);
  }

  HMAP_FOR_EACH_POP (usage, hmap_node, >ofport_usage) {
  free(usage);
  }

  #ifdef DPDK_EVS
  // must before p->ofproto_class->destruct(p, del);
  ofproto_free_sf_oftable(p);
  p->ofproto_class->destruct(p, del);
  #else
  p->ofproto_class->destruct(p);
  #endif

  /* We should not postpone this because it involves deleting a 
listening
   * socket which we may want to reopen soon. 'connmgr' may be used by 
other
   * threads only if they take the ofproto_mutex and read a non-NULL
   * 'ofproto->connmgr'. */
  ovs_mutex_lock(_mutex);
  connmgr_destroy(p->connmgr);
  p->connmgr = NULL;
  ovs_mutex_unlock(_mutex);

  /* Destroying rules is deferred, must have 'ofproto' around for them. 
*/
  ovsrcu_postpone(ofproto_destroy_defer__, p);
  }

3.  As “handler” and “main” have cbs[] each, it is possible that, 
ofproto_destroy_defer__() is called earlier than remove_rule_rcu(), so 
classifier of oftable is not empty. Then it will cause assert failed in function

  /* Destroys 'table', including its classifier and eviction groups.
   *
   * The caller is responsible for freeing 'table' itself. */
  static void
  oftable_destroy(struct oftable *table)
  {
  ovs_assert(classifier_is_empty(>cls));

  ovs_mutex_lock(_mutex);
  oftable_configure_eviction(table, 0, NULL, 0);
  ovs_mutex_unlock(_mutex);

  hmap_destroy(>eviction_groups_by_id);
  heap_destroy(>eviction_groups_by_size);
  classifier_destroy(>cls);
  free(table->name);
  }

-Original Message-
From: Ben Pfaff [mailto:b...@ovn.org]
Sent: 2017年12月7日 6:25
To: Zhanghaibo (Euler) 
Cc: ovs-discuss@openvswitch.org; Yinpeijun ; liucheng (J) 
; caihe ; Huangjian (J) 
; Zhoujingbin 
Subject: Re: [ovs-discuss] ovs_assert(classifier_is_empty(>cls)) failed 
when restart openvswitch service.

On Wed, Dec 06, 2017 at 08:28:30PM +, Zhanghaibo (Euler) wrote:
> Hello all,
>
> I run into abort issue when restart openvswitch service, the coredump file 
> shows that ovs_assert() failed in function 

Re: [ovs-discuss] OVS 2.8.1 changes the rates of data packets!

[Ben Pfaff]

It seems like you're just jumping to conclusions here.  What have you
done to understand the situation?

On Fri, Dec 08, 2017 at 05:59:57PM -0800, Dawood Sajjadi wrote:
> when I remove the wireless interfaces from the bridge, there is no problem.
> However, as soon as adding the wireless interfaces to the bridge, the
> problem shows up. So, it seems OVS (at least) is a part of the problem.
> 
> On Fri, Dec 8, 2017 at 5:55 PM, Ben Pfaff  wrote:
> 
> > On December 8, 2017 5:53:44 PM PST, Dawood Sajjadi 
> > wrote:
> >>
> >> I created a bridge using OVS 2.8.1 in Ubuntu 14.04. The bridge contains 4
> >> physical ports including one ethernet and three wireless ports. The
> >> ethernet port is connected to a laptop that generated dummy traffic using
> >> Iperf. So, the ethernet port is used as the incoming port and the generated
> >> traffic leaves the bridge through the wireless (as the outgoing) ports. I
> >> used tcpdump to capture the traffic at the incoming and outgoing ports of
> >> the bridge and I noticed that the volume of the outgoing traffic (at the
> >> wireless ports) is by far lower than the amount of the incoming traffic
> >> (from the ethernet port). It seems the OVS bridge drops/limits the rate of
> >> outgoing packets. For instance, if the size of the captured traffic using
> >> tcpdump at eth0 is 15 MB, the total size of the captured traffic on
> >> wireless ports is 3 MB!
> >>
> >> I didn't make any change in the default configuration of the OVS. Also,
> >> to ensure that there is no predefined Queue/QoS policy at the bridge, I
> >> used "ovs-vsctl --all destroy qos && ovs-vsctl --all destroy queue"
> >> command. However, the problem persists! Has anyone encountered such an
> >> issue before? I really appreciate having your feedback. Thanks.
> >>
> >
> > OVS doesn't change data rates. You should try to figure out what's going
> > on without making that assumption.
> >
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] OVS 2.8.1 changes the rates of data packets!

[Dawood Sajjadi]

when I remove the wireless interfaces from the bridge, there is no problem.
However, as soon as adding the wireless interfaces to the bridge, the
problem shows up. So, it seems OVS (at least) is a part of the problem.

On Fri, Dec 8, 2017 at 5:55 PM, Ben Pfaff  wrote:

> On December 8, 2017 5:53:44 PM PST, Dawood Sajjadi 
> wrote:
>>
>> I created a bridge using OVS 2.8.1 in Ubuntu 14.04. The bridge contains 4
>> physical ports including one ethernet and three wireless ports. The
>> ethernet port is connected to a laptop that generated dummy traffic using
>> Iperf. So, the ethernet port is used as the incoming port and the generated
>> traffic leaves the bridge through the wireless (as the outgoing) ports. I
>> used tcpdump to capture the traffic at the incoming and outgoing ports of
>> the bridge and I noticed that the volume of the outgoing traffic (at the
>> wireless ports) is by far lower than the amount of the incoming traffic
>> (from the ethernet port). It seems the OVS bridge drops/limits the rate of
>> outgoing packets. For instance, if the size of the captured traffic using
>> tcpdump at eth0 is 15 MB, the total size of the captured traffic on
>> wireless ports is 3 MB!
>>
>> I didn't make any change in the default configuration of the OVS. Also,
>> to ensure that there is no predefined Queue/QoS policy at the bridge, I
>> used "ovs-vsctl --all destroy qos && ovs-vsctl --all destroy queue"
>> command. However, the problem persists! Has anyone encountered such an
>> issue before? I really appreciate having your feedback. Thanks.
>>
>
> OVS doesn't change data rates. You should try to figure out what's going
> on without making that assumption.
>
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] OVS 2.8.1 changes the rates of data packets!

[Ben Pfaff]

On December 8, 2017 5:53:44 PM PST, Dawood Sajjadi  
wrote:
>I created a bridge using OVS 2.8.1 in Ubuntu 14.04. The bridge contains
>4
>physical ports including one ethernet and three wireless ports. The
>ethernet port is connected to a laptop that generated dummy traffic
>using
>Iperf. So, the ethernet port is used as the incoming port and the
>generated
>traffic leaves the bridge through the wireless (as the outgoing) ports.
>I
>used tcpdump to capture the traffic at the incoming and outgoing ports
>of
>the bridge and I noticed that the volume of the outgoing traffic (at
>the
>wireless ports) is by far lower than the amount of the incoming traffic
>(from the ethernet port). It seems the OVS bridge drops/limits the rate
>of
>outgoing packets. For instance, if the size of the captured traffic
>using
>tcpdump at eth0 is 15 MB, the total size of the captured traffic on
>wireless ports is 3 MB!
>
>I didn't make any change in the default configuration of the OVS. Also,
>to
>ensure that there is no predefined Queue/QoS policy at the bridge, I
>used
>"ovs-vsctl --all destroy qos && ovs-vsctl --all destroy queue" command.
>However, the problem persists! Has anyone encountered such an issue
>before?
>I really appreciate having your feedback. Thanks.

OVS doesn't change data rates. You should try to figure out what's going on 
without making that assumption. ___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

[ovs-discuss] OVS 2.8.1 changes the rates of data packets!

[Dawood Sajjadi]

I created a bridge using OVS 2.8.1 in Ubuntu 14.04. The bridge contains 4
physical ports including one ethernet and three wireless ports. The
ethernet port is connected to a laptop that generated dummy traffic using
Iperf. So, the ethernet port is used as the incoming port and the generated
traffic leaves the bridge through the wireless (as the outgoing) ports. I
used tcpdump to capture the traffic at the incoming and outgoing ports of
the bridge and I noticed that the volume of the outgoing traffic (at the
wireless ports) is by far lower than the amount of the incoming traffic
(from the ethernet port). It seems the OVS bridge drops/limits the rate of
outgoing packets. For instance, if the size of the captured traffic using
tcpdump at eth0 is 15 MB, the total size of the captured traffic on
wireless ports is 3 MB!

I didn't make any change in the default configuration of the OVS. Also, to
ensure that there is no predefined Queue/QoS policy at the bridge, I used
"ovs-vsctl --all destroy qos && ovs-vsctl --all destroy queue" command.
However, the problem persists! Has anyone encountered such an issue before?
I really appreciate having your feedback. Thanks.
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] Failed assertion in ovs-vswitchd when running OVN

[Ben Pfaff]

Thanks for testing!  I applied this to master.

I don't think it needs backporting, because branch-2.8 doesn't have this
assertion.

On Thu, Dec 07, 2017 at 06:59:40PM -0800, Kevin Lin wrote:
> The patch worked for me! (network works, and no more warnings in ovs-vswitchd)
> 
> > On Dec 7, 2017, at 3:54 PM, Ben Pfaff  wrote:
> > 
> > On Thu, Dec 07, 2017 at 02:44:36PM -0800, Kevin Lin wrote:
> >> Hi Ben,
> >> 
> >> I’ve included the traces for an ARP request, and a ping. ovs-vswitchd also 
> >> logs errors for the return traffic, but I didn’t include that as it seems 
> >> redundant.
> >> 
> >> root@ip-172-31-2-45:/# ovs-appctl ofproto/trace kelda-int 
> >> 'arp,in_port=1,vlan_tci=0x,dl_src=02:00:0a:c5
> >> :34:1e,dl_dst=ff:ff:ff:ff:ff:ff,arp_spa=10.197.52.30,arp_tpa=10.203.4.66,arp_op=1,arp_sha=02:00:0a:c5:34:1e
> >> ,arp_tha=ff:ff:ff:ff:ff:ff'
> >> Flow: 
> >> arp,in_port=1,vlan_tci=0x,dl_src=02:00:0a:c5:34:1e,dl_dst=ff:ff:ff:ff:ff:ff,arp_spa=10.197.52.30,arp_tpa=10.203.4.66,arp_op=1,arp_sha=02:00:0a:c5:34:1e,arp_tha=ff:ff:ff:ff:ff:ff
> >> 
> >> bridge("kelda-int")
> >> ---
> >> 0. in_port=1,dl_src=02:00:0a:c5:34:1e, priority 32768
> >>load:0x2->NXM_NX_REG0[]
> >>resubmit(,1)
> >> 1. arp,dl_dst=ff:ff:ff:ff:ff:ff, priority 1000
> >>LOCAL
> >>output:NXM_NX_REG0[]
> >> -> output port is 2
> >> Cannot truncate output to patch port 
> > 
> > Thanks for the details.
> > 
> > Would you mind testing this patch?
> >https://patchwork.ozlabs.org/patch/845908/ 
> > 
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] SSH over GRE tunnel, MTU 1500 devices in VMs on same physical host

[Orabuntu-LXC]

So just to update this in case it helps anyone.  The reason MTU 1500 was
working in this setup is because the traffic wasn't going over the GRE
tunnel which as Sherlock Holmes might have said "once you have eliminated
the impossible, whatever remains must be the truth" which is to say it's
impossible for packets of MTU 1500 to traverse a GRE tunnel,
unencapsulated, no? so then it followed that the traffic wasn't using the
tunnel.  So I just took away the tunnel entirely and found that all the LXC
containers on all the VM's on this host indeed could talk to each other
ssh, etc. just fine at MTU 1500 with no GRE tunnel needed.

This setup is VirtualBox VM's which are on the same OpenvSwitch network as
the LXC containers, with everything on the same physical host.  It was
quite simple to prove to myself simply by taking away the GRE tunnel and
observing that containers in different VM's on the same phyiscal host could
still talk with each other just fine.  I'm not a networking person
originally I've just added on iptables, switches, routers as needed to
support my Orabuntu-LXC work, so I must confess I still don't quite
understand why the containers on the VM's on same physical host can talk at
MTU 1500 without a GRE tunnel while the LXC containers in VM's or physical
hosts on different physical hosts required a GRE tunnel and of course MTU
1420, but I'm looking into it.  I'm sure it'll be a d'oh! revelation!

On Fri, Dec 1, 2017 at 1:44 PM, Gregory Rose  wrote:

>
> On 11/29/2017 12:12 PM, Orabuntu-LXC wrote:
>
> Hi,
>
> I have what is probably a dumb question so it should be an easy one for
> gurus.
>
> I built two VM's on VirtualBox using my Orabuntu-LXC software.  The VM
> VNIC's are ports on OvS sw1 on each VM.  The VM's are on the same physical
> host.  I have LXC containers on the sw1 switch also.  What has surprised me
> with this setup is that I can ssh between containers that are on different
> VMs and all the network devices, the VNIC's and the OvS switches, and the
> physical interface on the host, are all set to MTU 1500.  Not anywhere in
> this setup is MTU 1420 used.  My understanding was, and what I have found
> in all previous cases, was that I had to use MTU 1420 for ssh over a GRE
> tunnel to allow for encapsulation, so my question is I am wondering how can
> ssh be working over this GRE tunnel when all the MTU of all devices is set
> to 1500?
>
>
> ssh will use smaller packets  for most terminal oriented applications.
> Perhaps you're not exchanging traffic with larger packet sizes.
>
> Try iperf or something like that which will use maximum size MTUs
>
> - Greg
>
>
> TIA
>
> --
> Gilbert Standen
> Creator Orabuntu-LXC
> 914-261-4594 <(914)%20261-4594>
> gilb...@orabuntu-lxc.com
>
>
>
> ___
> discuss mailing 
> listdiscuss@openvswitch.orghttps://mail.openvswitch.org/mailman/listinfo/ovs-discuss
>
>
>


-- 
Gilbert Standen
Creator Orabuntu-LXC
914-261-4594
gilb...@orabuntu-lxc.com
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] ipsec_gre not working in OpenWRT

[Ansis Atteka]

I am trying to enable ipsec_gre tunnelling between two openwrt.

[ANSIS}:Is the iptables rule that sets skb_mark to 1 for incoming ESP packets 
in effect?  Are you using ufw or firewall-cmd or some other iptables pipeline 
where following invocation "debian/openvswitch-ipsec.init:iptables -D INPUT 
-t mangle $1 -j MARK --set-mark 1/1 || return 0" does not work for your case?

___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

[ovs-discuss] ipsec_gre not working in OpenWRT

[José Miguel Guzmán]

Hi Guys

I am trying to enable ipsec_gre tunnelling between two openwrt.
I created a physical and internal bridge, based on
http://docs.openvswitch.org/en/latest/howto/userspace-tunneling/ (although
I am using kernel space tunnelling)

# Creates Internal Bridge
ovs-vsctl --may-exist add-br br-int \
  -- set Bridge br-int datapath_type=$DATAPATH \
-- br-set-external-id br-int bridge-id br-int \
  -- set bridge br-int fail-mode=standalone

ovs-vsctl add-port br-int gre0  -- set interface gre0 type=$PROTOCOL
options:remote_ip=$THERE options:psk=test123
ifconfig br-int $TUN_HERE mtu 1400 up

# Creates physical Bridge
ovs-vsctl --may-exist add-br br-phy \
  -- set Bridge br-phy datapath_type=$DATAPATH \
  -- br-set-external-id br-phy bridge-id br-phy \
  -- set bridge br-phy fail-mode=standalone \
   other_config:hwaddr=$BRIDGEID

ovs-vsctl --timeout 10 add-port br-phy $DEV
ifconfig $DEV 0.0.0.0 mtu 2000
ifconfig br-phy $HERE mtu 2000 up

Everything works fine when $PROTOCOL is gre.
I can see decapsulated packages coming from the gre_sys interface, and
being received by br-int
I can actually ping between br-int (1.1.1.1 <=> 1.1.1.2)

But if PROTOCOL is ipsec_gre, it doesnt work
ovs-monitor-ipsec is running, and configuring security associations between
the two hosts.
I can see ESP traffic through br-phy
I can see packets being received in the gre_sys interface (meaning SA is
ok), but receiving switch is failing to reply ARP

*root@cpe5:~/TEST# tcpdump -i gre_sys -n -nn*
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on gre_sys, link-type EN10MB (Ethernet), capture size 262144 bytes
09:32:24.807643 ARP, Request who-has 1.1.1.2 tell 1.1.1.1, length 28
09:32:25.807685 ARP, Request who-has 1.1.1.2 tell 1.1.1.1, length 28

The only difference I see when compare gre with ipsec_gree, is that there
is some missing flows for tunneling when in ipsec_gre mode

In gre mode, I see

*root@cpe5:~# ovs-appctl dpctl/dump-flows*
# There flows are installed in both cases
recirc_id(0),in_port(4),eth(src=d8:58:d7:00:2e:c9,dst=d8:58:d7:00:2e:c6),eth_type(0x0800),ipv4(frag=no),
packets:8, bytes:1032, used:0.430s, actions:3
recirc_id(0),in_port(4),eth(src=d8:58:d7:00:2e:c9,dst=d8:58:d7:00:2e:c6),eth_type(0x0806),
packets:1, bytes:60, used:2.420s, actions:3
recirc_id(0),in_port(3),eth(src=d8:58:d7:00:2e:c6,dst=d8:58:d7:00:2e:c9),eth_type(0x0800),ipv4(frag=no),
packets:8, bytes:1032, used:0.430s, actions:4
recirc_id(0),in_port(3),eth(src=d8:58:d7:00:2e:c6,dst=d8:58:d7:00:2e:c9),eth_type(0x0806),
packets:0, bytes:0, used:never, actions:4

# There flows get installed only in GRE mode. They are missing when
IPSEC_GRE is in use
recirc_id(0),in_port(1),eth(src=1a:6b:2d:47:f3:43,dst=5a:a4:e4:d9:25:43),eth_type(0x0806),
packets:0, bytes:0, used:never,
actions:set(tunnel(dst=192.168.222.204,ttl=64,flags(df))),2
recirc_id(0),in_port(1),eth(src=1a:6b:2d:47:f3:43,dst=5a:a4:e4:d9:25:43),eth_type(0x0800),ipv4(tos=0/0x3,frag=no),
packets:7, bytes:686, used:0.430s,
actions:set(tunnel(dst=192.168.222.204,ttl=64,flags(df))),2
recirc_id(0),tunnel(src=192.168.222.204,dst=192.168.222.205,ttl=64,flags(-df-csum)),in_port(2),skb_mark(0),eth(src=5a:a4:e4:d9:25:43,dst=1a:6b:2d:47:f3:43),eth_type(0x0806),
packets:0, bytes:0, used:never, actions:1
recirc_id(0),tunnel(src=192.168.222.204,dst=192.168.222.205,ttl=64,flags(-df-csum)),in_port(2),skb_mark(0),eth(src=5a:a4:e4:d9:25:43,dst=1a:6b:2d:47:f3:43),eth_type(0x0800),ipv4(frag=no),
packets:7, bytes:686, used:0.430s, actions:1

In vswitch.log I see messages warning received packet on unassociated
datapath port 2

*2017-12-08T11:30:00.598Z|00093|dpif(handler6)|DBG|system@ovs-system: miss
upcall:*
recirc_id(0),dp_hash(0),skb_priority(0),tunnel(src=192.168.222.204,dst=192.168.222.205,ttl=64,flags(0)),in_port(2),skb_mark(0),ct_state(0),ct_mark(0),eth(src=ee:9f:69:e6:40:4f,dst=33:33:00:00:00:16),eth_type(0x86dd),ipv6(src=fe80::ec9f:69ff:fee6:404f,dst=ff02::16,label=0,proto=58,tclass=0,hlimit=1,frag=no),
icmpv6(type=143,code=0)
icmp6,vlan_tci=0x,dl_src=ee:9f:69:e6:40:4f,dl_dst=33:33:00:00:00:16,ipv6_src=fe80::ec9f:69ff:fee6:404f,ipv6_dst=ff02::16,ipv6_label=0x0,nw_tos=0,nw_ecn=0,nw_ttl=1,icmp_type=143,icmp_code=0,nd_target=::,nd_sll=00:00:00:00:00:00,nd_tll=00:00:00:00:00:00
icmp6_csum:94ca

*2017-12-08T11:30:00.598Z|00094|tunnel(handler6)|WARN|receive tunnel port
not found 
*(icmp6,tun_src=192.168.222.204,tun_dst=192.168.222.205,tun_ipv6_src=::,tun_ipv6_dst=::,tun_gbp_id=0,tun_gbp_flags=0,tun_tos=0,tun_ttl=64,tun_flags=0,in_port=2,vlan_tci=0x,dl_src=ee:9f:69:e6:40:4f,dl_dst=33:33:00:00:00:16,

ipv6_src=fe80::ec9f:69ff:fee6:404f,ipv6_dst=ff02::16,ipv6_label=0x0,nw_tos=0,nw_ecn=0,nw_ttl=1,icmp_type=143,icmp_code=0,nd_target=::,nd_sll=00:00:00:00:00:00,nd_tll=00:00:00:00:00:00)

*2017-12-08T11:30:00.598Z|00095|netlink_socket(handler6)|DBG|nl_sock_transact_multiple__
(No error information): nl(len:212, type=23(ovs_flow),

Re: [ovs-discuss] OvS on ARM

[José Miguel Guzmán]

OK
I found the reason

In case it is useful for somebody else, it is because the kmod-openvswich
package is not including the vport-gre.ko, vport-lisp.ko, vport-*.ko
modules.
When those kernel modules are loaded, tunneling works!

JM

El lun., 13 nov. 2017 a las 2:16, José Miguel Guzmán (<
jmguz...@whitestack.com>) escribió:

> Hi Joo
>
> When you compiled for wrt, did you try tunneling in kernel module?
>
> I'm compiled OVS 2.5.0 that is the default version for Chaos Calmer, but I
> haven't been able to add tunnel ports to any kernel based switch. It says
> "Address family not supported by protocol" that some posts suggest is
> related to imcompability between kernel and user space (the should not be
> the case). I have gre and vxlan supported in kernel modules.
>
> I was able to create tunnel ports in userspace (datapath_type=netdev), but
> it's performance is low.
>
> Could you (or somebody else reading) suggest me any troubleshooting
> strategy? I'm running out of ideas
>
> Thanks a lot
> JM
>
>
>
>
> El 13 abr. 2017 12:21, "Joo Yong-Seok"  escribió:
>
> Yes, I tried and built it successfully. Also basic L2 functions are
> working ok.
>
> Used Linux kernel 3.14 + openvswitch 2.3.9 and openwrt chaos calmer.
>
> As an experiment, I also tried openvswitch 2.6.1 and basic things are
> working ok.
>
> No performance test data though.
>
> Best regards,
>
> On Apr 13, 2017 7:09 AM, "Michael Williams"  wrote:
>
>> Have any of you done any cross compilation of OvS for use on ARM based
>> systems? I was thinking of using the OpenWRT SDK to cross compile OvS on
>> Ubuntu for use on a wireless router that supports OpenWRT.
>>
>> ___
>> discuss mailing list
>> disc...@openvswitch.org
>> https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
>>
>>
> ___
> discuss mailing list
> disc...@openvswitch.org
> https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
>
>
> --

*José Miguel Guzmán*Senior Network Consultant
Latin America & Caribbean
  +1 (650) 248-2490 <+16502482490>
  +56 (9) 9064-2780 <+56990642780>
  jmguz...@whitestack.com
  jmguzmanc
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss