On 30.11.2016 06:18, Ben Pfaff wrote:
On Tue, Nov 29, 2016 at 07:22:32PM +0500, Valentine Sinitsyn wrote:
On 29.11.2016 05:21, Ben Pfaff wrote:
On Fri, Oct 14, 2016 at 04:35:46PM +0500, Valentine Sinitsyn wrote:
This is a quick attempt to implement sample action at logical port
level.The goal is to export IPFIX flows for logical ports, yet it is
easy to extend this approach to logical switches as well.
Nothing is done to provision OVS instances with required
Flow_Sample_Collector_Set and IPFIX entries at this point.
This is pretty cool! The integration among OVS and OVN and IPFIX is
graceful.
The part that worries me is the CMS integration. Have you actually
built that integration already (for which CMS)? I have two concerns.
First, I'd prefer to see at least one CMS (probably OpenStack) support
this at or around the time that it goes into OVN. Second, I have some
skepticism around the idea that the CMS should configure the
Flow_Sample_Collector_Set, etc., because OVN doesn't currently require
the CMS to have any connectivity to OVSDB on each of the hypervisors and
this would require the CMS to add that support.
I agree that this particular bit is somewhat hacky. We plan to follow this
route for an in-house CMS we build, but I doubt OpenStack community would
pickup the idea. What alternatives do you see here? Having collector config
at south db level doesn't seem clear either. Think I want to configure
collector at 127.0.0.1:5900 - which localhost does this entry refer to?
Is this a common way to configure IPFIX? I had been under the
impression that generally there's one or a few collectors in a network,
to which each switch forwards packets. If it's common to use a
per-hypervisor collector, then that might actually makes thing easier,
since that would be easy for ovn-controller to configure into OVS on
each hypervisor.
Running collectors local to hypervisors is what we do here. I can't say
if it's a common scenario, but given that IPFIX is most often UDP which
can be lost, it usually makes sense to keep collectors and exporters as
close as possible.
Otherwise, I'm inclined to at least learn what the requirements would be
for common deployments of IPFIX. Even if we don't implement it them (or
all of them), it's important to me to know what we're leaving out so
that what we add now is built in a way that it's gracefully extensible
later.
For example: if a packet should be sent to a collector, should the
collector be chosen based on the packet's logical network, or based on
the packet's physical network (the hypervisor it's ingressing or
egressing), or on some combination of those?
I also find myself wondering whether logical port level is the right
level at which to choose whether to sample packets. Will OVN users want
finer-grained control over sampling and, if so, would it make more sense
to add an ACL-like table for that purpose at the northbound level?
You mean using an lflow match to control when the "sample" action will
trigger, rather than hard-wiring these actions to logical ports via
"ipfix_options"? This sounds reasonable and not to hard to implement,
given that we already have these tables in the southbound db.
If the sample() integration looks good, CMS assumptions aside, is there a
chance to merge it as a stand-alone action? That's true no publicly
available CMS would use it for a while, but when they decide to, the code
would already be there. And the code is not dead, as we'll be using it as
well.
It's better than no users at all.
Do you have any thoughts about supporting other monitoring technology
that OVS supports (e.g. sFlow) using similar techniques?
I haven't targeted any of them specifically, but it doesn't seem to be a
daunting task. One only need some way to associate sample() instance and a
sFlow receiver the same way collector_set_id does for IPFIX.
I'd suggest to generalize Flow_Sample_Collector_Set somehow, but we agreed
configuring things through this table in OVN scenario is suboptimal. Any
thoughts?
Did we have an earlier discussion? I've spent a few minutes searching
my email archive and I don't see one. If there was one, can you point
it out?
No, no prior discussion, sorry for being unclear.
I was referring to your concerns regarding CMS integration in the
beginning of this thread.
Thanks,
Valentine
_______________________________________________
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
