Community discussions

MikroTik App
 
jupiadrian
just joined
Topic Author
Posts: 1
Joined: Thu Aug 11, 2022 12:29 pm
Location: Sweden

Increasing BGP cost in announced OSPF routes (ROS 7)

Thu Aug 11, 2022 5:37 pm

Hi!
I'm experimenting with a project where we need to connect our network to AWS using their service Direct Connect. We've been up and running with our configuration over a month, which works really good. I'm new to both BGP and OSPF, so I'm not that experienced yet.

The routing between AWS and the "on-premise" world are made by using BGP in a CCR1072 (sto-sk1-gw01) runing ROS 7. The received announced route from AWS is seen and it's possible to communicate between the router and AWS. In the same VLAN, several routers talks OSPF for the routing between each other which also receives the redistributed route from AWS.

In the upcoming future, I need to establish a backup connection to AWS from the same network. For that purpose, I have another CCR1072 (sto-sk1-gw02), which also has an established BGP connection. As both CCR1072 are talking OSPF, they both received each other's BGP route but its own announced route to AWS (the announced BGP route from AWS are identical).

As I will use VRRP between the CC1072, it's important that traffic to/from AWS is is coming from the virtual router being active by that moment. This also means that the redistributed BGP route in OSPF needs to be chosen based on which router that's online, in this case sto-sk1-gw01 (sto-sk1-gw02 as backup). I'm thinking about increasing the distance for the "backup" BGP route, which in my world would mean that the primary choice for all other routers would be to go to sto-sk1-gw01 first. When sto-sk1-gw01 dies and these routes are disappearing, they'll switch over to the higher, but active, BGP route on backup router sto-sk1-gw02.

Am I completely out of range, or could this be a solution? Thanks for any help!
You do not have the required permissions to view the files attached to this post.
 
eduplant
Member Candidate
Member Candidate
Posts: 139
Joined: Tue Dec 19, 2017 9:45 am

Re: Increasing BGP cost in announced OSPF routes (ROS 7)

Fri Aug 12, 2022 5:54 am

I think you're on the way there. It's possible to redistribute the DirectConnect BGP routes into OSPF as external type 2 and have your preferred path have the lower cost. A couple of observations:

1. Is this OSPF pathway between the routers a dedicated VLAN or is it shared with client devices? If it isn't, I recommend a dedicated VLAN.
2. The OSPF redistribution/cost situation will help you influence outbound, but you also will need to influence inbound. The DirectConnect documentation indicates that you can announce your prefixes to AWS with one of three communities (low, medium, and high priority) to change how their side localprefs the prefixes. By doing both, that will be enough to keep traffic using one tunnel unless that router/path fails.
3. Keeping this path in sync with VRRP is not possible without scripting. Even if one router is the active VRRP router most of the time, there are a number of reasons to switch over or switch back (maintenance, temporary disruption, etc.) This is where #1 comes in because it needs to be possible for traffic to route from any of the routers through to the one with the preferred DirectConnect link even if the path is suboptimal. Same for reverse traffic from AWS.
4. Are you intending to apply stateful firewall rules on either of the devices with the DirectConnect links? That's the main situation that you would have to care which of the links inbound and outbound traffic use. Otherwise occasional asymmetry isn't a big deal.

Since you mentioned you're new to routing protocols, I should mention the canonical advice about redistribution:
1. Don't redistribute BGP into an IGP (RIP/OSPF/EIGRP/IS-IS). This advice usually is about scalability and separation of concerns between internal and external reachability. In this specific case, you're limiting your BGP usage so narrowly to just covering what DirectConnect supports and it's going to be just a handful of prefixes on the AWS side, this isn't a big deal. I just want to flag for your future information that it's usually strictly inadvisable.
2. When redistributing between any two routing protocols, make sure you pick a direction to redistribute and stick with it. Don't redistribute protocol_1 into protocol_2 and then protocol_2 back into protocol_1. Lots of really exciting (read: bad) and subtly broken things can result if you don't filter carefully and fully understand the ramifications.

Happy routing!

Who is online

Users browsing this forum: No registered users and 13 guests