Prefixes flapp over routeserver unable to find corrosponding peers

Hi
i am facing peers over a routeserver available prefixes flap between 3000 - 11000 prefixes.
it looks that some peers have wrong max prefix config peering with the routeserver.

how can i find out what peering partners have flapping config?

i tried many things but i only can see how many prefixes are recieved via routeserver but not what prefixes…

anyone some idea how i can solve it?
br

Mark

/routing/route print

Is the place to start if you’re looking for prefixes from a specific ASN. You can filter the output with various options and operators.

yes i did but my problem is that it can not show what peerings und routes are learned via a root server

if i do /routing/route/print where afi=ipv6 and gateway=2001:7f8:30:0:2:1:0:9002
it prints routes learned from this peer.

but i am not able to find out if i do the print command to the root server ip

/routing/route/print where afi=ipv6 and gateway=2001:7f8:30:0:2:1:0:1121
empty respose …

my problem is that the rootserver enables peers and shows count of prefixes over the routeserver in total but i am not able to figure out what ecact prefixes/routes i have learnd from it.

what i did is using the route print peer per peer and monitor but this is quit time intensive with about 200 peers…

Normally route servers are designed to be out of path so I wouldn’t expect to see routes learned with a gateway of the route server. Route servers mimic the behavior of iBGP and don’t modify the next hop between eBGP peers.

So it makes sense that command wouldn’t return any routes that match. Is this an IX?

Yes it’s a ix just Google ipv6 Adresse from the command.
My issue is that some peers are not handling their config propper to the root server.
I monitored the usual suspects manual and I can see that the might have a wrong config limiting their export to a lower prefix amount and the routes learned are flapping between 3,5k to 11k routes all 5-7 minutes.
My goal was to figure out who to make a direct peering session to avoid that route flapping.
I was already in contact with the noc of the peering point - the know that problem but the members didn’t solved the issues after the got contacted by them.