I can reproduce, thanks.
When any traffic is sent on a bridge with both ipfix per-bridge sampling and a
controller setup, vswitchd core dumps.
I'll fix this.
--
Romain Lenglet
On Sep 3, 2013, at 2:05 PM, Glenn McGuire <gle...@a-bb.net> wrote:
> > My understanding from your message is that removing a primary controller
> > makes IPFIX stop working.
>
> Quite the opposite is true - removing the primary controller makes IPFIX
> *begin* working.
> If I configure the (OpenFlow) controller first, I get no IPFIX packets at
> all, even though I do have a pair of flows.
> But as soon as I issue the del-controller command, I begin to get IPFIX
> packets.
> Obviously, a new default flow is installed after the controller is removed.
>
>
> root@crashandburn:~#
> root@crashandburn:~# ovs-vsctl list bridge
> _uuid : f3d600a5-5e48-4dc4-b078-1deeba943cd9
> controller : [ac6e4a6f-09b9-47c4-9379-51c89601fb32]
> datapath_id : "000000e04ceba42a"
> datapath_type : ""
> external_ids : {}
> fail_mode : []
> flood_vlans : []
> flow_tables : {}
> ipfix : []
> mirrors : []
> name : "br1"
> netflow : []
> other_config : {}
> ports : [7b9b7093-79ae-4cf8-a805-1d8712ebb2aa,
> bcff69bb-6b5b-48f6-a84e-46b095a91ad7, f9e1a64c-48ec-41fc-a329-b6b7b008dd31]
> protocols : ["OpenFlow10", "OpenFlow12", "OpenFlow13"]
> sflow : []
> status : {}
> stp_enable : false
> root@crashandburn:~# ovs-vsctl list port
> _uuid : f9e1a64c-48ec-41fc-a329-b6b7b008dd31
> bond_downdelay : 0
> bond_fake_iface : false
> bond_mode : []
> bond_updelay : 0
> external_ids : {}
> fake_bridge : false
> interfaces : [9be629c0-b22b-49da-a064-f692bf95bfdd]
> lacp : []
> mac : []
> name : "eth0"
> other_config : {}
> qos : d6cf8ef8-8b9e-4aeb-ad43-cbe7050f43d7
> statistics : {}
> status : {}
> tag : []
> trunks : []
> vlan_mode : []
>
> _uuid : 7b9b7093-79ae-4cf8-a805-1d8712ebb2aa
> bond_downdelay : 0
> bond_fake_iface : false
> bond_mode : []
> bond_updelay : 0
> external_ids : {}
> fake_bridge : false
> interfaces : [6371e7be-e7b2-45c7-a9c7-925d92fa5bd8]
> lacp : []
> mac : []
> name : "br1"
> other_config : {}
> qos : []
> statistics : {}
> status : {}
> tag : []
> trunks : []
> vlan_mode : []
>
> _uuid : bcff69bb-6b5b-48f6-a84e-46b095a91ad7
> bond_downdelay : 0
> bond_fake_iface : false
> bond_mode : []
> bond_updelay : 0
> external_ids : {}
> fake_bridge : false
> interfaces : [90008db1-baad-441c-8f49-df4b0b8635d0]
> lacp : []
> mac : []
> name : "eth2"
> other_config : {}
> qos : ce75d9bf-e3df-4554-b1b0-deaa3befe5b2
> statistics : {}
> status : {}
> tag : []
> trunks : []
> vlan_mode : []
> root@crashandburn:~#
> root@crashandburn:~# ovs-vsctl list flow-table
> root@crashandburn:~#
> root@crashandburn:~# ovs-vsctl list controller
> _uuid : ac6e4a6f-09b9-47c4-9379-51c89601fb32
> connection_mode : []
> controller_burst_limit: []
> controller_rate_limit: []
> enable_async_messages: []
> external_ids : {}
> inactivity_probe : []
> is_connected : true
> local_gateway : []
> local_ip : []
> local_netmask : []
> max_backoff : []
> other_config : {}
> role : other
> status : {sec_since_connect="167", state=ACTIVE}
> target : "tcp:172.20.2.112:6633"
> root@crashandburn:~#
> root@crashandburn:~#
> root@crashandburn:~# ovs-vsctl list ipfix
> root@crashandburn:~#
> root@crashandburn:~# ovs-ofctl dump-flows br1
> NXST_FLOW reply (xid=0x4):
> cookie=0x0, duration=198.649s, table=0, n_packets=198, n_bytes=19404,
> hard_timeout=36000, idle_age=0, in_port=1,dl_dst=00:e0:4c:eb:a4:2a
> actions=set_queue:1,LOCAL
> cookie=0x0, duration=198.644s, table=0, n_packets=198, n_bytes=19404,
> hard_timeout=36000, idle_age=0, in_port=LOCAL,dl_dst=00:23:ae:05:e1:3b
> actions=set_queue:1,output:1
> root@crashandburn:~#
> root@crashandburn:~#
> root@crashandburn:~#
> root@crashandburn:~# ovs-vsctl --id=@i create IPFIX
> targets=\"172.20.2.112:4739\" obs_domain_id=123 obs_point_id=456 sampling=1
> -- set Bridge br1 ipfix=@i
> 405abe40-6ce6-4daf-acb3-0387b366d4f8
> root@crashandburn:~#
> root@crashandburn:~#
> root@crashandburn:~# ovs-vsctl list bridge
> _uuid : f3d600a5-5e48-4dc4-b078-1deeba943cd9
> controller : [ac6e4a6f-09b9-47c4-9379-51c89601fb32]
> datapath_id : "000000e04ceba42a"
> datapath_type : ""
> external_ids : {}
> fail_mode : []
> flood_vlans : []
> flow_tables : {}
> ipfix : 405abe40-6ce6-4daf-acb3-0387b366d4f8
> mirrors : []
> name : "br1"
> netflow : []
> other_config : {}
> ports : [7b9b7093-79ae-4cf8-a805-1d8712ebb2aa,
> bcff69bb-6b5b-48f6-a84e-46b095a91ad7, f9e1a64c-48ec-41fc-a329-b6b7b008dd31]
> protocols : ["OpenFlow10", "OpenFlow12", "OpenFlow13"]
> sflow : []
> status : {}
> stp_enable : false
> root@crashandburn:~#
> root@crashandburn:~# ovs-vsctl list ipfix
> _uuid : 405abe40-6ce6-4daf-acb3-0387b366d4f8
> cache_active_timeout: []
> cache_max_flows : []
> external_ids : {}
> obs_domain_id : 123
> obs_point_id : 456
> sampling : 1
> targets : ["172.20.2.112:4739"]
> root@crashandburn:~#
> root@crashandburn:~# ovs-ofctl dump-flows br1
> NXST_FLOW reply (xid=0x4):
> cookie=0x0, duration=588.769s, table=0, n_packets=594, n_bytes=58068,
> hard_timeout=36000, idle_age=0, in_port=1,dl_dst=00:e0:4c:eb:a4:2a
> actions=set_queue:1,LOCAL
> cookie=0x0, duration=588.764s, table=0, n_packets=588, n_bytes=57624,
> hard_timeout=36000, idle_age=0, in_port=LOCAL,dl_dst=00:23:ae:05:e1:3b
> actions=set_queue:1,output:1
> root@crashandburn:~#
> root@crashandburn:~# ovs-vsctl list flow-table
> root@crashandburn:~# ovs-vsctl list flow_table
> root@crashandburn:~#
>
>
>
>
> On Tue, Sep 3, 2013 at 3:36 PM, Romain Lenglet <rleng...@vmware.com> wrote:
> Hi Glenn,
>
> This could be a bug.
> Please send more information:
> - Please send the contents of your "IPFIX" and "Bridge" tables, by running
> "ovs-vsctl list ipfix" and "ovs-vsctl list bridge". Especially, I'm curious
> about the "ipfix", "controller", and "fail_mode" columns.
> - Do you have flows in your OpenFlow tables and in the datapath? "ovs-dpctl
> dump-flows"
> - What condition triggers the problem?
>
> My understanding from your message is that removing a primary controller
> makes IPFIX stop working.
> From the OVS documentation: "If there are primary controllers, removing all
> of them clears the flow table."
> If there are no flows, it would be logical that nothing gets sampled by
> IPFIX, especially if the bridge is in "secure" fail mode.
>
> I'll know more with the information above.
> Thanks,
> --
> Romain Lenglet
>
> From: "Glenn McGuire" <gle...@a-bb.net>
> To: discuss@openvswitch.org
> Sent: Tuesday, September 3, 2013 11:43:22 AM
> Subject: [ovs-discuss] IPFIX stops sending
>
>
> I've been trying to work with the IPFIX support in recent versions of
> Openvswitch, and have run across the following behavior:
>
> When I configure an OpenFlow controller, the IPFIX messages stop being sent.
>
> On my most recent install (Ubuntu 12.x / 3.5.0-23 and ovs 2.0.0 presumably
> compiled with the system default compiler - gcc 4.6.3)
> IPFIX messages continue as soon as I delete the controller configuration
> (with ovs-vsctl del-controller)
> This includes sending a new set of templates, which makes sense since there
> is a timeout check in the send routine.
> (My previous install was on a CentOS host in usermode and had some stability
> issues that hid this behavior behind lockups and the occasional crash)
>
> My first suspect from glancing through the code is that it's hanging on a
> mutex, but a cursory inspection of the code shows consistent mutex use.
>
>
> Has anyone seen this?
> Do other folks use IPFIX with a controller?
>
> _______________________________________________
> discuss mailing list
> discuss@openvswitch.org
> http://openvswitch.org/mailman/listinfo/discuss
>
>
_______________________________________________
discuss mailing list
discuss@openvswitch.org
http://openvswitch.org/mailman/listinfo/discuss
