[
https://issues.apache.org/jira/browse/METRON-854?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15982885#comment-15982885
]
ASF GitHub Bot commented on METRON-854:
---------------------------------------
Github user nickwallen commented on the issue:
https://github.com/apache/incubator-metron/pull/531
@basvdl I should have first said, thanks for all your hard work!
You probably have already thought through many of these options, so please
educate me on their pros/cons. I am going to lay out all of the possibilities
that I can think of just so that we don't leave any stone unturned.
(1) Alter the Source of Telemetry - This is the option that you chose.
This has the downside that we now have a forked, external dependency that we
are relying on you to maintain going forward. That's a lot of work for you!
(2) Use an Alternative Source of Telemetry - Is there an alternative to
`DHCPDump` out there that we could use instead? I think this would be the
simplest approach assuming one exists.
(3) Reunite lines at the parser - Each line would come in as a separate
Kafka message. We cannot rely on ordering of those messages, so we would need
some kind of unique identifier contained within each message to then reunite
them all into a single DHCPDump record. This would be very different from our
current architecture and is not currently supported.
(4) Transport Mechanism - How do you envision getting the DHCPDump records
into Kafka? aka the transport mechanism? No matter what, we need some kind of
transport mechanism. You could potentially create a solution that takes the
separate record lines, stitches them into a single line, then pushes them to
Kafka as a complete DHCPDump record.
> Create DHCPDump Parser
> ----------------------
>
> Key: METRON-854
> URL: https://issues.apache.org/jira/browse/METRON-854
> Project: Metron
> Issue Type: New Feature
> Reporter: Bas van de Lustgraaf
> Priority: Minor
> Labels: parser
>
> Create a DHCPDump parser. This information can be used during enrichment to
> link ip-addresses to hostnames.
> {noformat}
> TIME: 2017-01-16 16:54:21.655|INTERFACE: eth2|OP:1 BOOTPREQUEST|CIADDR:
> 172.20.75.77|YIADDR: 0.0.0.0|SIADDR: 0.0.0.0|GIADDR: 172.20.75.8|CHADDR:
> fc:f8:ae:e8:ef:db:00:00:00:00:00:00:00:00:00:00|OPTION: 53 1 DHCP message
> type: 8 |DHCPINFORM|OPTION: 61 7 Client-identifier:
> 01:fc:f8:ae:e8:ef:db|OPTION: 12 5 Host name: Q1244|OPTION: 60 8 Vendor
> class identifier: MSFT 5.0|OPTION: 55 13 Parameter Request List: 1
> (Subnet mask)|| 15 (Domainname)|| 3 (Routers)|| 6 (DNS server)|| 44
> (NetBIOS name server)|| 46 (NetBIOS node type)|| 47 (NetBIOS scope)|| 31
> (Perform router discovery)|| 33 (Static route)||121 (Classless Static
> Route)||249 (MSFT - Classless route)|| 43 (Vendor specific info)||252 (MSFT -
> WinSock Proxy Auto Detect)|||IP: 10.10.10.177 > 172.20.1.11 |
> b8:ca:3a:67:95:8a > 0:50:56:84:68:43
> TIME: 2017-01-16 17:13:14.548|INTERFACE: eth2|OP:1 BOOTPREQUEST|CIADDR:
> 172.20.75.77|YIADDR: 0.0.0.0|SIADDR: 0.0.0.0|GIADDR: 172.20.75.8|CHADDR:
> fc:f8:ae:e8:ef:db:00:00:00:00:00:00:00:00:00:00|OPTION: 53 1 DHCP message
> type: 8 |DHCPINFORM|OPTION: 61 7 Client-identifier:
> 01:fc:f8:ae:e8:ef:db|OPTION: 12 5 Host name: Q1244|OPTION: 60 8 Vendor
> class identifier: MSFT 5.0|OPTION: 55 13 Parameter Request List: 1
> (Subnet mask)|| 15 (Domainname)|| 3 (Routers)|| 6 (DNS server)|| 44
> (NetBIOS name server)|| 46 (NetBIOS node type)|| 47 (NetBIOS scope)|| 31
> (Perform router discovery)|| 33 (Static route)||121 (Classless Static
> Route)||249 (MSFT - Classless route)|| 43 (Vendor specific info)||252 (MSFT -
> WinSock Proxy Auto Detect)|||IP: 10.10.10.177 > 172.20.1.10 |
> b8:ca:3a:67:95:8a > 0:50:56:b9:28:ac
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
