model: CCR1036-8G-2S+
revision: r2
factory-firmware: 6.43.10
current-firmware: 6.45.3
upgrade-firmware: 6.45.3
Maybe i have searched bad, but didn't found exact what i need.

Situation - i need to announce a lot of prefixes to multiple bgp peers, and need to get more-specific route announcement
example:
I have directly-connected network 192.168.0.0/22 on interface (another prefixes, and in fact more then one, but it doesn't make any changes for question)
What i exactly need to announce to one peer /22 and to another 192.168.0.0/23 and 192.168.2.0/23. To have normal working prefixes and network synchronization (to have a chance to stop announce of /23 in soft reset case) i need to have in static routing table exact match for 192.168.0.0/23 192.168.2.0/23.
I've made for now it by route to interface:
ip route print detail
Flags: X - disabled, A - active, D - dynamic, C - connect, S - static, r - rip, b - bgp, o - ospf, m - mme,
B - blackhole, U - unreachable, P - prohibit
4 ADC dst-address=192.168.0.0/22 pref-src=192.168.0.1 gateway=sfp-sfpplus1 gateway-status=sfp-sfpplus1 reachable distance=0 scope=10
5 A S dst-address=192.168.0.0/23 gateway=sfp-sfpplus1 gateway-status=sfp-sfpplus1 reachable distance=1 scope=30 target-scope=10
7 A S dst-address=192.168.2.0/23 gateway=sfp-sfpplus1 gateway-status=sfp-sfpplus1 reachable distance=1 scope=30 target-scope=10
But have doubts about possible issues with routing such addresses like 192.168.1.255 or 192.168.2.0.
Doest it will be correct? Or there is another better way to make it? like was in cisco null0 254 route?
I've found an post where was made blackhole route with distance 254. but by tests and as i understand this way will only works fine with aggregation of prefixes.. not with more specific routes.

In current situation it seems to be working, but we already got a mysterious issue - about 90% forwarding packet drop from random sources. By researching incident with multiple firmware changes, and trying to upload save config - suspect that problem was with renaming interfaces. Made initial configuration one more time without renaming - and all was routed fine.

Ok, please explain how to create in right way more specific route route for eBGP announce? (About mysterious packet drops - it was before routes via interface.)

We are already running /22 on other hardware, but not owned by us, and now migrating router to own, it's mikrotik.
There are already customers there, each using his own ip, and yes 192.168.1.255, 192.168.2.0 - also routed and used. (In fact IPs are not 192.168.X.X, but for our case it doesn't matter). Now in test-mode mikrotik also connected to network, yes, via sfp-port interface.
/ip address
add address=192.168.0.1/22 interface=sfp-sfpplus1 network=192.168.0.0

I've setup BGP instance, have 2 peers now, and 1-2 more will be in nearest future. And i need to announce 1x /22 and 2x /23 prefixes for same network.
/routing bgp instance
set default disabled=yes
add as=XXXXX client-to-client-reflection=no name=XXXXX out-filter=OUTFILTER redistribute-connected=yes \
redistribute-static=yes router-id=XXX.XXX.XXX.XXX
/routing bgp network
add disabled=no network=192.168.0.0/22 synchronize=yes
add disabled=no network=192.169.0.0/23 synchronize=yes
add disabled=no network=192.168.2.0/23 synchronize=yes
.....
Synchronization enabled.

Regarding explanation in wiki if sync enabled - i need to get exact match route in routing table for this network.
Regarding tested, in fact without it - bgp won't work properly at all, routing bgp peer resend-all will not work (bgp proccess would not generate packets peer X.X.X.X rcvd UPDATE about 192.168.0.0/23 -- withdrawn)
So to have properly running bgp announce and soft reconfiguration with my peers i need to have in routing table exact prefix match for /23. And the question - how to do it in proper way?

I cannot do like your stuff recommends - have smaller networks, and aggregate them to bigger prefix by the help of blackhole route. I have inverse case - i have a lot of networks directly connected to router interface, and i need for properl bgp working to have more specific routes, example: network directly connected /22 - so i need to announce /22 and 2x /23 in bgp, network is /23 - 1x /23 and 2x /24.

So in conclusion - i do not have a target to split directly connected network, i need to create somehow fake routes /23 to get it normally working with BGP and soft reconfiguration with BGP peers.

Any suggestions how to make it right way?

Turn synchronization off and announce the prefixes you need. Unlike Cisco, MikroTik will announce whatever prefix length you specify in networks if synchronization is turned off. You don't need a static route for the BGP advertisement.

Thank you for reply.
But this option makes another problem. We had a pain with debug logs from both sides of bgp-connection to find it out. When synchronization off, mikrotik do not interact normally with bgp-neighbours. When i drop in filter prefix announce without sync, no packet generated to neighbour:
10.1.10.2 rcvd UPDATE about 192.168.0.0/23 -- withdrawn
And only one way to deal with it make hard-reset of bgp-session, what is crap, to flap each time session instead of using soft-update with "routing bgp peer resend-all".

Try using 'aggregate' instead of 'network' and check the include IGP option, that should fix the issue you're seeing.

For your nailed-up static routes intended for prefix origination, I'd say the best thing to do would be to add them as distance=254, type=blackhole

e.g.
/ip route
add dst=192.168.0.0/22 type=blackhole distance=254
add dst=192.168.0.0/23 type=blackhole distance=254
add dst=192.168.2.0/23 type=blackhole distance=254

This way, you don't need to specify a next interface, etc. The distance=254 part ensures that they will not override real routes if you do ever need to have an active /23 to a real next-hop destination in your network. The blackhole will simply be a catch-all. Having a blackhole "catch-all" route is good practice anyway, so that any packets on your network with destination IP addresses that are not actually allocated anywhere should get discarded properly. If you don't have this anywhere in your network, then these packets will end up in a ping-pong somewhere until TTL expires, wasting resources.

I would also say that you should use networks to originate all prefixes that you might want to advertise to any peer. This will create all of them in your BGP. Then use a set of filter rules for each peer to limit which prefixes you will allow out to that peer. For example, on the peer that you don't want the /23 prefixes, you could block prefix-length=23-32. On peers you want to send only the /23 prefixes, you would accept prefix-length=23, and discard otherwise.

In general, the most straightforward way to make a filter set is to specifically allow things that you definitely want, and then have a deny-all rule at the end. Specify the things you wish to allow starting with the most specific and then the more general things towards the end.

Thank you. Perfect, will try to play around distance blackhole routes.
About filter - thank you for recommendation, but over testing I have chosen to have a bit large out filter in bgp instance with exact matches of needed networks and prefixes, but to have a very flexible configuration by the help of adding own communities, and to build filters with my neighbour peers uplinks based on community matches. Deny-rule in the end without doubt- it is a only one right way practice to avoid surprises