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,
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
Hi! Is there any solution for this? I’m having issues with aggregator attribute but in UBNT platforms
Hi,
We’re also having this issue on a CCR 2116 running 7.14.3, the below is being propagated over an eBGP neighborship despite both the originator-id and cluster-list path attributes being optional and non transitive.
/routing bgp advertisements print where dst=x.x.x.x/22
0 peer=bgp-cust-ipv4-1 dst=x.x.x.x/22 afi=ip nexthop=x.x.x.x
origin=0 as-path=sequence xxxxx xxxxx xxxxxx
communities=xxxxx,xxxxx,xxxxxx,xxxx
originator-id=x.x.x.x cluster-list=x.x.x.x <------------
Any assistance on this would be much appreciated 
Kind regards,
Jimmy
Has anybody already tried 7.16 released today in lab? It says:
*) bgp - fixed cluster-list and originator-id;
May be it is finally fixed. Won’t have time to check today. But maybe during the week.
We’re going to give the firmware upgrade a go this weekend! If anyone else tries this in the meantime please let me know how it goes.
Kind regards,
Jimmy
So we’ve applied the 7.16 firmware this morning and we believe the issue is now resolved unless we’re completely missing something! We’ve checked a couple of prefixes which were previously being sent with the cluster-list and originator-id path attributes and they’re no longer present.
We’ve also checked the full routing table for the originator-id and path-attributes and they’re not present on any of the routes being sent to the ebgp peer:
/routing bgp advertisements print where originator-id=x.x.x.x
/routing bgp advertisements print where cluster-list=x.x.x.x
Thanks MikroTik!
Kind regards,
Jimmy
We also recently updated all of our BGP routers (6x CCR2216) to 7.16. Looks like problems with cluster list are gone now.
We also checked with wireshark inspection. BGP updates to our eBGP peers are without cluster-list attributes. But those towards our route reflectors are with. So everything is working fine.
We even noticed a slight drop in overall CPU usage on our routers with many peers (facing AMS-IX and DE-CIX).
Great work!