Hi!
Is it possible to remove those attributes to routes advertised to ebgp peers via filter?

We have some downstream AS which get routes from us. These attributes are being injected in BGP routes propagated via our internal bird route reflectors. In our own routers this information is useful. So we can investigate routes by where they originally entered our network. But this information should not be propagated further to external ASN.

Cheers
Dennis

this is becoming important, today we found a problem with an eBGP peer with a Huawei or Cisco router at the other end, the debug process shows that they're receiving the cluster-list & originatorid as part of the BGP attributes, which by default makes them discard the routes.

example (from my lab):
Apr 8 2024 21:26:24.280.2 HUAWEI RM/6/RMDEBUG:
BGP.Public : Error identified while receiving UPDATE message from the peer 172.16.x.1 and ignored
Reason: (ORIGINATORID Attribute received from EBGP).

Apr 8 2024 21:26:24.280.3 HUAWEI RM/6/RMDEBUG:
BGP.Public : Error identified while receiving UPDATE message from the peer 172.16.x.1 and ignored
Reason: (CLUSTERLIST Attribute received from EBGP).

Apr 8 2024 21:26:24.280.4 HUAWEI RM/6/RMDEBUG:
BGP: routes in update message need to be processed as withdrawn message due to reason mentioned above.

Apr 8 2024 21:26:24.280.5 HUAWEI RM/6/RMDEBUG:
BGP.Public: Recv UPDATE from 172.16.x.1 with following destinations :

Update message length : 91
MP_reach : AFI/SAFI 1/1
Origin : IGP
AS Path : XXXX YYYY
Next Hop : 172.16.x.1
Community : <aaaa:bbbb>
BGP.Public: Recv UPDATE(Withdraw) MSG from 172.16.x.1 with following destinations :

2.19.162.0/24,

<HUAWEI>

If you peer (using eBGP) with Juniper or any other Mikrotik, it works like charm, haven't tested with other platforms.

This is the log from another Mikrotik (running v6):

05:36:56 route,bgp,debug,packet UPDATE Message
05:36:56 route,bgp,debug,packet RemoteAddress=10.x.x.2
05:36:56 route,bgp,debug,packet MessageLength=91
05:36:56 route,bgp,debug,packet
05:36:56 route,bgp,debug,packet PathAttributes
05:36:56 route,bgp,debug,packet bgp-origin=IGP
05:36:56 route,bgp,debug,packet bgp-as-path=XXXX,YYYY
05:36:56 route,bgp,debug,packet bgp-as-path-len=2
05:36:56 route,bgp,debug,packet bgp-aggregator-as=3427860480
05:36:56 route,bgp,debug,packet bgp-aggregator-address=2.162.19.2
05:36:56 route,bgp,debug,packet bgp-communities={aaaa:bbbb}
05:36:56 route,bgp,debug,packet bgp-originator-id=151355236
05:36:56 route,bgp,debug,packet bgp-cluster-list={ 235372388, 33554432 }
05:36:56 route,bgp,debug,packet
05:36:56 route,bgp,debug,packet NLRI=2.19.162.0/24

The main router sending this updates is a CCR2216 running 7.13.5.

Thank you sri2007,

this is exactly also our problem. We have two customers using Cisco gear and the logs of their devices are flooded with messages about BGP advertisements having those attributes.

For Mikrotik-Devs: RFC4456 (introducing route reflection and mentioned attributes, https://datatracker.ietf.org/doc/html/rfc4456) says in paragraph 8:

When a route is reflected, it is possible through misconfiguration to
form route re-distribution loops. The route reflection method
defines the following attributes to detect and avoid routing
information loops:

ORIGINATOR_ID

ORIGINATOR_ID is a new optional, non-transitive BGP attribute of Type
code 9. This attribute is 4 bytes long and it will be created by an
RR in reflecting a route. This attribute will carry the BGP
Identifier of the originator of the route in the local AS. A BGP
speaker SHOULD NOT create an ORIGINATOR_ID attribute if one already
exists. A router that recognizes the ORIGINATOR_ID attribute SHOULD
ignore a route received with its BGP Identifier as the ORIGINATOR_ID.

CLUSTER_LIST

CLUSTER_LIST is a new, optional, non-transitive BGP attribute of Type
code 10. It is a sequence of CLUSTER_ID values representing the
reflection path that the route has passed.

When an RR reflects a route, it MUST prepend the local CLUSTER_ID to
the CLUSTER_LIST. If the CLUSTER_LIST is empty, it MUST create a new
one. Using this attribute an RR can identify if the routing
information has looped back to the same cluster due to
misconfiguration. If the local CLUSTER_ID is found in the
CLUSTER_LIST, the advertisement received SHOULD be ignored.

Non-transitive means: These attributes are not allowed to be propagated outside of own ASN. So if bgp peer is configured as ebgp* these attribute have to be removed from advertisements.

We have also seen this problem with eBGP to Cisco router, Mikrotik 7.13.5 to Cisco IOS (XE).

In the Cisco we get

%BGP-6-MSGDUMP_LIMIT: unsupported or mal-formatted message received from …..:
FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF 005C 0200 0000 4340 0101 0250 0200 0E02
0300 009A E000 009A E000 009A E040 0304 0AFA 1295 4006 00D0 0800 049A E000 01D0
1000 0800 029A E000 0000 2A80 0904 C318 BF0D 900A 0004 C318 BF0A 080A

%BGP-6-MALFORMEDATTR: Malformed attribute in (BGP(0) Prefixes: 10.0.0.0/8 ) received from …..,

We did a workaround in Cisco router running IOS XE that solves the problem. Discarding these attributes in the incoming eBGP routing updates work by adding the following in neighbor configuration.

neighbor ….. path-attribute discard range 9 10 in

Older Cisco IOS does not support path-attribute discard neighbor configuration, so can't be solved with this workaround.

Do you know of any updates from Mikrotik to solve this problem?

Please report this behaviour to the Mikrotik support.
https://mikrotik.com/support

the same issue with bgp but in my case i think problem with as-path attribute in confederation