# This IPv6 address cannot be used in IPv4 context

**URL:** <https://community.graylog.org/t/this-ipv6-address-cannot-be-used-in-ipv4-context/136>\
**Category:** Graylog Central (peer support)\
**Created:** [February 19, 2017, 5:25pm UTC](https://community.graylog.org/t/this-ipv6-address-cannot-be-used-in-ipv4-context/136 "2017-02-19T17:25:54Z")\
**Posts on this page:** 5\
**Page:** 1

<div class="post-metadata">

**Author:** ![dustintennill](https://sea2.discourse-cdn.com/flex016/user_avatar/community.graylog.org/dustintennill/32/1956_2.png) [@dustintennill](https://community.graylog.org/u/dustintennill)\
**Post date:** [February 19, 2017, 5:25pm UTC](https://community.graylog.org/t/this-ipv6-address-cannot-be-used-in-ipv4-context/136/1 "2017-02-19T17:25:54Z")

</div>

Hello,

We have been slowly working through debugging the various error messages seen in our graylog server.log file so we can see when there are real issues.

This particular message is a current concern:

```auto
2017-02-19T12:10:51.869-05:00 WARN [ProcessBufferProcessor] Unable to process message <5dc778dc-f6c6-11e6-9b33-0025b5ff0071>: org.graylog.plugins.pipelineprocessor.ast.exceptions.FunctionEvaluationException: java.lang.IllegalArgumentException: This IPv6 address cannot be used in IPv4 context

```

It occurs around 2500 times each day.  
What is the BEST way to troubleshoot error messages related to “unable to process message”? Has anyone written up a basic procedure that one could follow?

In older versions of Graylog I vaguely remember an interface where I could see the message that could not be processed, making it simple to find and fix the problem. If that’s here now I might be missing it.

I like this new discussion forum.

Dustin Tennill

---

<div class="post-metadata">

**Author:** ![jochen](https://sea2.discourse-cdn.com/flex016/user_avatar/community.graylog.org/jochen/32/8_2.png) [@jochen](https://community.graylog.org/u/jochen)\
**Post date:** [February 20, 2017, 4:08pm UTC](https://community.graylog.org/t/this-ipv6-address-cannot-be-used-in-ipv4-context/136/2 "2017-02-20T16:08:02Z")

</div>

Hi Dustin,

these messages are most likely produced by some invalid call to the [`cidr_match()`](http://docs.graylog.org/en/2.2/pages/pipelines/functions.html#cidr-match) function.

You should check the usage of that function and make sure to only pass valid parameters.

Cheers,  
Jochen

---

<div class="post-metadata">

**Author:** ![lennart](https://sea2.discourse-cdn.com/flex016/user_avatar/community.graylog.org/lennart/32/63_2.png) [@lennart](https://community.graylog.org/u/lennart)\
**Post date:** [February 20, 2017, 6:01pm UTC](https://community.graylog.org/t/this-ipv6-address-cannot-be-used-in-ipv4-context/136/3 "2017-02-20T18:01:55Z")

</div>

@jochen This looks like the message is being discarded. Can you confirm? If so, we should change the behavior of `cidr_match()` and make the function throw a warning but handle it gracefully, i.e. not lose the whole message.

---

<div class="post-metadata">

**Author:** ![dustintennill](https://sea2.discourse-cdn.com/flex016/user_avatar/community.graylog.org/dustintennill/32/1956_2.png) [@dustintennill](https://community.graylog.org/u/dustintennill)\
**Post date:** [February 20, 2017, 9:32pm UTC](https://community.graylog.org/t/this-ipv6-address-cannot-be-used-in-ipv4-context/136/4 "2017-02-20T21:32:08Z")

</div>

Thanks !!!

Sounds like a pipeline is the next place to check.

---

<div class="post-metadata">

**Author:** ![dustintennill](https://sea2.discourse-cdn.com/flex016/user_avatar/community.graylog.org/dustintennill/32/1956_2.png) [@dustintennill](https://community.graylog.org/u/dustintennill)\
**Post date:** [February 25, 2017, 4:52pm UTC](https://community.graylog.org/t/this-ipv6-address-cannot-be-used-in-ipv4-context/136/5 "2017-02-25T16:52:30Z")

</div>

Here is a reduced bit of pipeline we currently have deployed.

```auto
rule "from datacenter subnet"
when
    cidr_match("192.168.1.0/24", to_ip($message.gl2_remote_ip)) OR cidr_match("192.168.2.0/24", to_ip($message.gl2_remote_ip)) 
then
    set_field(field: "LocationTag", value: "datacenter");
end

```

I am trying to confirm with log data, but I am assuming that an ipv6 address isn’t safely handled by “to\_ip”. Will post back once I know for sure.