> 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
