(sidenote.. don’t spend too much time on this 
) Actually… I don’t like this at all…
The official KNX Specification (v2.1) defines KNXnet/IP Service Type Identifiers for KNXnet/IP protocol version 1.0 (Core) in the range of 0200 to 020F hex.
So this identifier (0x20b) belongs to the KNXnet/IP Core action.
But… the KNX Standard (volume 3 (System Specifications), part 8 (KNXnet/IP), chapter 1) has only 10 Service names used until now (up to 0x20a)… 020B until 020F are unused.
So… it seems to me that GIRA has implemented another Service Type Identifier (outside the KNX standard) for their X1 product (0x20b)…
They have done it before also with Service Type Identifier 0x538 to me…
Boris is treating this here: https://github.com/calimero-project/calimero-core/blob/master/src/tuwien/auto/calimero/knxnetip/KNXnetIPRouting.java
// newer Gira servers have a "reliable communication" option, which uses the
// following unsupported service type; not part of the knx spec
private static final int GiraUnsupportedSvcType = 0x538;
Simple version: The calimero library which is used by the KNX Binding has all the KNX Standard service types implemented. The GIRA X1 is broadcasting some UDP datagrams with an unknown (by calimero) service type identifier. In theory, this warning can be ignored since it shouldn’t block the regular (standard) communications.
You could try to disable “Reliable Communications” in your GIRA X1 using ETS to see if this message disappears.
From my experience, they use these “extended” service types to establish communications between their Gateways and their other solutions (software, etc)
…The good news from all of this is: openHAB2 is receiving multicast messages from the GIRA X1 gateway on your network. If we fix the configs, it will work