[netsa-tools-discuss] Multi-protocol support in fixbuf using same listener

[John Jetmore]

Thanks for your response Emily. At this time we're not going to pursue
this so we can hit our own deadlines.  I appreciate your suggestions
as we may pick this up again in the future.

--John

On Mon, Apr 13, 2015 at 3:46 PM, Emily Sarneso <ecoff at sei.cmu.edu> wrote:
> Hello John,
>
> Thank you for your interest in our tools.
>
> Unfortunately, you are correct that it is not currently possible to receive the different flow protocols on the same receiving port.  You are actually the first person to request this functionality.  I don’t have any plans to add this in the near future, but I don’t think it would be too difficult to add.  Since you have already been brave enough to venture into the code, I’ll explain one way to do it if you’re interested in making some code changes.
>
> The easiest way to do it (off the top of my head) would be to create a new translator (similar to how sFlow or NetFlow v9 works).  Your translator would set up translatorStates for both sFlow and v9.  The header function would examine each packet to determine the protocol and set the translatorState appropriately.  The copostRead function of the new translator could call out to the copostRead (post process) function for each of the protocols:
>
> IPFIX -> fbCollectorPostProcNull (do nothing)
> V9 -> fbCollectorPostProcV9
> sFlow-> fbCollectorPostProcSFlow
>
> Likewise, the timeout function will have to timeout the appropriate session and state depending on the protocol.
>
> You need to make sure that the source IP/observation domains of the various flow exporters do not overlap.  If it is possible that this could happen, use the fbCollectorManageUDPStreamByPort() to manage the UDP sessions by source port as well.  You want each flow exporter to have their own UDP session to avoid any template confusion on the IPFIX side in fixbuf.
>
> This will require a bit of effort, but fortunately you can reuse a lot of the existing code.
>
> Hope that helps.  Please let me know if you have any questions.
>
> Good luck,
>
> Emily
>
> ----------
> Emily Sarneso
> CMU/SEI/CERT
> ecoff at cert.org
>
>
>
>
> On Apr 9, 2015, at 11:41 AM, John Jetmore <jj33 at pobox.com> wrote:
>
>> Hello, I'm trying to build a flow collector using libfixbuf.  I have
>> the basis for what I want and it works very well, thank you for the
>> work put into this library.
>>
>> One of the requirements I had for this project was to receive
>> different flow protocols (sflow, v9, ipfix) on the same receiving
>> port. We had thought this would be very easy since the docs didn't
>> seem to say that the translators were mutually exclusive.  oops.
>>
>> I've spent the past few days trying to creatively come up with
>> solutions to allow this behavior and haven't gotten very far.  I
>> finally proved to myself that there's a single collector per listener
>> (I was lead astray by the peer information in the struct being swapped
>> out), at which point I decided it probably wasn't possible right now.
>>
>> My questions to this list:
>> - Have I missed something obvious?  Is there a way to allow libfixbuf
>> to automatically translate flows using a single listener?
>> - Is there any plan for this?  To me it seems like it could be done.
>> The peer information in the fbCollector_st is already being swapped
>> out when the peer changes, could the pointer to the translationState
>> also be changed?
>>
>> Thanks again for the great library, and thanks in advance for any help.
>