[
https://bro-tracker.atlassian.net/browse/BIT-700?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15535#comment-15535
]
grigorescu commented on BIT-700:
--------------------------------
I've actually been looking at PacketSorter recently, and I think it would be
useful for at least CMU and another EDU. The way CMU taps the network is to
aggregate SPANs from different routers, and to ensure no duplicate traffic is
received, the upflow is received from one router, while the downflow is
received from another. This can obviously lead to problems when the packets
arrive out of order (which seems to happen). An option I've been considering is
to use our Arista switch as the master timesource that all routers synchronize
to, and then use the PacketSorter to sort the packets based on timestamp. I
think as we see more people tapping their networks internally, we'll see more
of this distributed tapping that will need to be sorted.
Does that seem like a reasonable use case? Is there a different, cleaner, way
to achieve that?
> PacketSorter
> ------------
>
> Key: BIT-700
> URL: https://bro-tracker.atlassian.net/browse/BIT-700
> Project: Bro Issue Tracker
> Issue Type: Problem
> Components: Bro
> Reporter: gregor
> Assignee: Robin Sommer
> Labels: BroV6,, IPv6
> Fix For: 2.3
>
>
> (from an e-mail I sent a while ago)
> Might relevant for IPv6 so setting milestone to 2.1
> Hi,
> I was wondering about Bro's packet sorter. From a quick glance it
> appears that it's only enabled if packet_sort_window is set to a non
> zero value. When enabled it will sort packets
> a) based on timestamps and
> b) for TCP packets based on SEQ/ACK numbers (I presume to ensure that
> ACKs are delivered after the data packet)
> Note, this is independent from Bro's ability to process multiple trace
> files (or multiple interfaces) in order. So I was wondering about the
> use cases for PacketSorter, especially (a)
> If the packet sorter is enabled Bro's behavior will slightly change: It
> won't pass ARP packets to the ARP analyzer, and it won't create a weird
> if it's not an IP packet.
> I was just wondering whether anybody has recently used the packet
> sorter. If not I'm wondering whether we should test this code path to
> see whether it works correctly esp wrt IPv6.
> Or, actually, whether the packet sorter is worth keeping or whether we
> should remove the code.
> And another question would be if the TCP sorting would better be handled
> by the TCP analyzer?
> Opinions?
--
This message was sent by Atlassian JIRA
(v6.2-OD-09-036#6252)
_______________________________________________
bro-dev mailing list
[email protected]
http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev
