Hello everyone,
I have a situation to resolve and I'm looking for practical advice.
I state that I have an AS number and a public /24 subnet to be announced.
We currently have two upstreams, each of which allows us to use two eBGP sessions.
I would like to create a redundant core structure however I am looking for an approach that is not too elaborate.
My idea is to use two different eBGP routers, one mikrotik and one FFR (Maybe both virtualized on separate HP VMs) however I don't know how to connect this access structure to my current OSPF network.
I had thought about using VVRP however I would need to have a single link to my OSPF network and this could be a vulnerable point.
Anyone have any ideas?
Thank you

I usually link the NSRC BGP BCP slides [1] since they're the most concise description I know of for good BGP practice.

The default answer I would go with is:

• Have the internet edge routers participate in OSPF with each other and with the rest of your network. This is how they reach your clients.
• Have the internet edge routers originate a default route into OSPF. This is how your clients reach the internet.
• Directly connect your internet edge routers and run iBGP between their loopback addresses. This a) gives them a consistent and complete view of the exits from your network and b) allows them to send traffic to each other when they receive client traffic that should leave via the other router.
• Run next-hop-self (on Mikrotik that's nexthop-choice=force-self) both for eBGP (the default) and iBGP (not the default). This way you don't have to redistribute your uplink prefixes into OSPF.
• Do not redistribute BGP routes into OSPF or OSPF routes into BGP. OSPF cannot take internet-sized tables without melting down.
• On most platforms, including ROSv7, BGP will only announce routes where there is a matching route in the table. Use a static route (can be null) on your internet edge routers as the eligibility for your announcements rather than information from OSPF. This way if you have OSPF issues, you will not withdraw/announce flap your upstream BGP peers.
• Because you have two upstream peers, take into account the NSRC recommendations for defensive routing policy. You will have to translate into Mikrotik syntax, though. Your upstream providers should also be writing defensive policy, but protect yourself in case they aren't. The worst situation is if you announce internet routes from one peer to the other and accidentally become a transit AS for your providers.

[1] https://nsrc.org/workshops/2023/nsrc-bk ... GP-BCP.pdf