[cisco_meraki] Fix Blocked RA Packet grok pattern in events pipeline. - #20394
Conversation
ie-ops
added
enhancement
✅ Elastic Docs Style Checker (Vale)No issues found on modified lines! The Vale linter checks documentation changes against the Elastic Docs style guide. To use Vale locally or report issues, refer to Elastic style guide for Vale. |
🚀 Benchmarks reportPackage
|
| Data stream | Previous EPS | New EPS | Diff (%) | Result |
|---|---|---|---|---|
events |
333333.33 | 250000 | -83333.33 (-25%) | 💔 |
log |
3571.43 | 2341.92 | -1229.51 (-34.43%) | 💔 |
To see the full report comment with /test benchmark fullreport
|
Pinging @elastic/integration-experience (Team:Integration-Experience) |
![vera-review-bot[bot]](https://avatars.githubusercontent.com/in/3297022?s=60&v=4){kind=small}
| if: ctx._temp?.blocked_ra != null | ||
| - set: | ||
| field: cisco_meraki.event_subtype | ||
| value: dhcp_blocked |
There was a problem hiding this comment.
Severity: 🔵 Low confidence: low path: packages/cisco_meraki/data_stream/log/elasticsearch/ingest_pipeline/events.yml:154
The new dhcp_blocked subtype does not set network.protocol, unlike the other DHCP subtypes in this pipeline (dhcp_offer, dhcp_no_offer, multiple_dhcp_servers_detected), which all set network.protocol: dhcp. Add the same set processor for consistency.
Details
events.yml sets network.protocol: dhcp for dhcp messages (line 77-80) and for multiple_dhcp_servers_detected (line 247-250). The newly added dhcp_blocked subtype describes a blocked DHCP packet but leaves network.protocol unset, so DHCP-scoped queries such as network.protocol: dhcp will not surface these blocked-packet events.
Recommendation:
Add a matching set processor after the dhcp_blocked subtype assignment:
- set:
field: cisco_meraki.event_subtype
value: dhcp_blocked
if: ctx._temp?.blocked_dhcp != null
- set:
field: network.protocol
value: dhcp
if: ctx._temp?.blocked_dhcp != nullRegenerate test-events.log-expected.json afterwards so the two dhcp_blocked fixture events include the new field.
🤖 AI-Generated Review | Vera Review Bot | 📚 Knowledge base: integration-skills
⚠️ Automated review — verify suggestions before applying.
Review summaryIssues found across the latest commits 4e0b0cc — 1 low
Issues found across earlier commits 2dbf4f1 — 1 low
Issues found across earlier commits c234325 — 1 high, 1 low
Issues found across earlier commits cd33362 — 1 medium, 1 low
Issues found across earlier commits d59dbdd — 1 medium, 2 low
🤖 AI-Generated Review | Vera Review Bot | 📚 Knowledge base: integration-skills
|
ilyannn
left a comment
ilyannn
left a comment
There was a problem hiding this comment.
Fine with some nits, including some that were already found by the review bot
|
Tick the box to add this pull request to the merge queue (same as
|
|
✅ All changelog entries have the correct PR link. |
💚 Build Succeeded
History
|
|
Package cisco_meraki - 1.31.2 containing this change is available at https://epr.elastic.co/package/cisco_meraki/1.31.2/ |
3 participants
Executive summary
The cisco_meraki events pipeline only handled 'Blocked ARP Packet' events via Grok, causing parse failures for 'Blocked RA Packet' and 'Blocked DHCP Packet' events which share a similar but distinct log format (IP in parentheses, explicit 'VLAN' keyword). The fix adds two new Grok patterns plus corresponding BLOCKEDRA/BLOCKEDDHCP pattern definitions, and two new set processors to assign the correct event_subtype values (ra_blocked, dhcp_blocked). Test fixtures covering both new event types are included and all pipeline tests pass.
Proposed commit message
Root cause
The BLOCKEDARP grok pattern definition in events.yml (line 130) hardcodes the literal
'Blocked ARP Packet'and the rest of the pattern useswith IP %{IP:source.ip}syntax, which does not match Cisco Meraki's 'Blocked RA Packet' events where the IPv6 source address is enclosed in parentheses and the message ends with 'by default'. Both the literal string and the IP capture syntax must be extended to handle the RA variant.Approach
Add a second grok pattern for the RA (Router Advertisement) packet variant to the existing 'Handle Blocked ARP' grok processor in events.yml. The RA format differs structurally from ARP: it wraps the IPv6 address in parentheses and appends 'by default', so a dedicated alternative pattern with
%{BLOCKEDRA:_temp.blocked_ra}is needed. A follow-onsetprocessor maps the new temp capture to a distinctra_blockedevent subtype, preserving existingarp_blockedbehaviour unchanged. A test fixture is added for the sanitized RA event.Implementation
packages/cisco_meraki/data_stream/log/elasticsearch/ingest_pipeline/events.yml(lines 121-143), add a second pattern entry to the existing blocked-ARP grok processor that matches the RA format:'^%{SYSLOGHDR}%{SPACE}%{NUMBER}%{SPACE}%{WORDORHOST}%{SPACE}events%{SPACE}(?<message>%{BLOCKEDRA:_temp.blocked_ra} from %{MAC:source.mac} \(%{IP:source.ip}\) on VLAN %{WORD:observer.ingress.vlan.id}(?: by default)?)$'. Add a newBLOCKEDRA: 'Blocked RA Packet'entry to thepattern_definitionsblock.set event_subtype=arp_blockedprocessor (line 140-143), add a newsetprocessor:field: cisco_meraki.event_subtype, value: ra_blocked, if: ctx._temp?.blocked_ra != null.packages/cisco_meraki/data_stream/log/_dev/test/pipeline/test-events.log, append the sanitized RA test event:<134>1 1782557203.245381197 blvl_01 events Blocked RA Packet from 00-00-5E-00-53-23 (2001:db8::1) on VLAN 201 by default.packages/cisco_meraki/data_stream/log/_dev/test/pipeline/test-events.log-expected.json, append the expected document for the RA event withcisco_meraki.event_subtype: ra_blocked,source.mac: 00-00-5E-00-53-23,source.ip: 2001:db8::1,observer.ingress.vlan.id: 201,message: 'Blocked RA Packet from 00-00-5E-00-53-23 (2001:db8::1) on VLAN 201 by default',log.syslog.priority: 134, andrelated.ip: ['2001:db8::1'].packages/cisco_meraki/changelog.yml, prepend a newversion: 1.31.2entry withtype: bugfixand description:Fix grok pattern to support Blocked RA Packet events in addition to Blocked ARP Packet events.packages/cisco_meraki/manifest.yml, updateversionfrom1.31.1to1.31.2.elastic-package test pipelinefor the cisco_meraki log data stream to confirm both ARP and RA test cases pass.Pipeline changes
BLOCKEDRA(literal 'Blocked RA Packet') to the existing blocked-ARP grok processor's patterns list; new pattern captures MAC tosource.mac, IPv6 (in parens) tosource.ip, and VLAN number toobserver.ingress.vlan.id— with an optional(?: by default)?terminal groupBLOCKEDRA: 'Blocked RA Packet'to the grok processor'spattern_definitionsblocksetprocessor after existingarp_blockedset:field: cisco_meraki.event_subtype, value: ra_blocked, if: ctx._temp?.blocked_ra != nullField / mapping changes
—
Sanitized error message
Provided Grok expressions do not match field value: [on_failure_message]Sanitized log (
event_sanitizedexcerpt)<134>1 1782557203.245381197 blvl_01 events Blocked RA Packet from 00-00-5E-00-53-23 (2001:db8::1) on VLAN 201 by defaultReviewer concerns
on VLAN %{WORD:observer.ingress.vlan.id}while the ARP pattern useson %{NOTSPACE} %{GREEDYDATA:observer.ingress.vlan.id}— reviewers should confirm this difference is intentional and reflects a real format difference between ARP and RA/DHCP log lines.ifguard requirescisco_meraki.event_subtype == "blocked"to be set by an upstream processor; the test passing confirms this path works, but reviewers should verify that RA/DHCP blocked events are reliably classified asblockedsubtype in the earlier pipeline stage.Self-review findings
—
Risk and classification
Links
17f5589529993a8f