Hello,
We are trying a week to announce a block / 24 within our mikrotik without success. We were only able to announce block / 22 and / 23. We reviewed all the filters and we could not. Can someone help me?
Config in attach.
Routing-Filters.txt (2.56 KB)
Did you check with your upstream? Perhaps he is blocking your announces if they are higher than /23
Enviado desde mi SAMSUNG-SM-G920A mediante Tapatalk
He’s says: No have block there. 
Is this the chain you’re using?
add action=accept chain=Britis_out comment="ANUNCIO DE BLOCOS-BRITIS" prefix=192.140.36.0/22 prefix-length=22-24
add action=accept chain=Britis_out prefix=192.140.36.0/23 prefix-length=23
add action=accept chain=Britis_out disabled=yes prefix=192.140.37.0/24 prefix-length=24
add action=accept chain=Britis_out prefix=192.140.38.0/23 prefix-length=23
add action=accept chain=Britis_out disabled=yes prefix=192.140.39.0/24 prefix-length=24
add action=discard chain=Britis_out
So the prefix is 192.140.36.0/22 right? assuming these are in the right order, by the very first rule you should be propagating anything 22-24.
Not using any summary rules?
Tried resetting the peer?
Recently I’ve had an issue where prefixes weren’t getting processed by the receiving router (was a MK too), only fixed after deleting the peering and making a new one in the receiving end, you could try this too on your side.
I reconfigured Peer, but in all looking glass when I advertise my prefix with / 24 only receive 192.140.3x.0 without mask
lg.rj.ptt.br> show ip bgp regexp 266202
BGP table version is 0, local router ID is 45.6.52.200
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale, R Removed
Origin codes: i - IGP, e - EGP, ? - incomplete
Network Next Hop Metric LocPrf Weight Path
- 192.140.39.0 45.6.52.75 0 28250 266202 i
-
45.6.52.75 0 28250 266202 i -
45.6.52.75 0 0 28250 266202 i
*> 45.6.52.75 0 0 28250 266202 i
Do all four /24 from that block exist in your local route table as /24?
BGP won’t advertise a prefix unless it has an exact match present in the routing table.
That is certainly the behavior of some routing platforms like Cisco, but MikroTik can advertise a prefix without it existing in the routing table.
to the OP. Verify the route is being announced by issuing the following command:
routing bgp advertisements print peer=peer_name
But it must surely exist in the BGP table in order for it to be advertised, and if it’s in the BGP table, isn’t it going to be in the routing table (maybe as a static or IGP route, but still)?
The point being a route filter will not automatically de-aggregate a range, it must be explicitly configured somewhere.
Actually on MikroTik it doesn’t need to be in the routing table at all to be originated (not that this is a good practice though), all you need to do is create the proper network statements and setting “synchronize=no” as IPANetEngineer said:
/routing bgp network add network=10.10.0.0/22 synchronize=no
/routing bgp network add network=10.10.0.0/24 synchronize=no
/routing bgp network add network=10.10.1.0/24 synchronize=no
/routing bgp network add network=10.10.2.0/24 synchronize=no
/routing bgp network add network=10.10.3.0/24 synchronize=no
This would originate 10.10.0.0/22 and its division in /24 even if there’s no route for these in the routing table.
If you set it as “syncronize=yes” then it’d behave as every other platform out there (to be originated the route must exist first in the routing table)
No, but it still needs to be originated somewhere. If it hasn’t been explicitly configured, BGP won’t advertise them.
I’m just trying to find out from the OP how those /24 blocks are being generated, as all he’s posted so far are his filters.
The network statement can originate a prefix in BGP even if it doesn’t exist in the routing table. There are times when I’ve found this to be incredibly helpful as I need to create an aggregate route without any prefixes in that range existing in the routing table.