Hello, I converted a WAN VPN running over OSPF that was working well in the below scenario, however I moved from a dedicated VPS running vyos to connect to my core network, also running vyos. This required seperating the two OSPF area 0 with a BGP network.
Location A has 3 uplinks to the internet, all 3 use VPN tunnels to the Core
- UpLink 1 has a neighbor weight of 100
- Uplink 2 has a neighbor weight of 5
- Uplink 3 has a neighbor weight of 10
- Crosslink to B has a neighbor weight of 1000
Location B has 1 uplink to A and 1 backup uplink to the Core, also over a VPN
- Crosslink to A has a neighbor weight of 1000
- Uplink backup has a neighbor weight of 1
The issue is that site A has unreliable power, and site B uses it for it’s internet connection. If A goes down, B sucessfully fails over to the backu uplink.
However, with this configuration, while only one link is selected rather than ECMP, when site A comes online, it’s route is pointed up through B’s backup location.
bouncing the backup uplink on B, fixes this issue and internet goes over site A’s available link as expected even when the backup uplink’s neighbors connect. However it’s consistent that the undesirable route is selected.
What do I need to do to prevent B from being the destination and prevent async routing out A and back around through it’s uplink
Route A / Router B , do they have a IBGP neighbor ? if it was configured , you should use as-prepend over Router B , it should help from point of view where ISP prefer announce from Router A instead of Router B.
I figured out how to set the extcommunity bandwidth value and local preference for each link using a route-map, while leaving the crosslink between site A and B default.
A 1 bandwidth and local pref 100/100
A 2 bw and lp 5/5
A 3 bw and lp 50/50
B 1 bw and lp 1/1
This allows Site A to select the right uplink based on which is available, and B will use the cross connect for internet unless site A is offline, then it uses it’s backup
perfect! local preference helps with the outgoing traffic, although , it doesn’t solved the problem with ingress traffic ,based on upstream router verify as-path , at this point should be used as-prepend.
Also note that as-prepend is just a hint for the sender (AS) which path you prefer to receive at. They can very well ignore recursive as-prepends.
I did set the local pref on the core for each link, and I’m still seeing the backup link in the core stick as the return path for site B’s subnet, while B’s route is using the preferred path to the core.
Am I misunderstanding something that local pref 1 is less preferred than local pref 5, or is it reversed where lower is more preferred?
edit, I see that the default pref is 100, so I left the backup link at 1 and rebased the local prefs for the links as higher than 100. This is now working as expected in both directions.
I’d like to bump this again because I’m still getting stuck with the backup link taking over when site A reconnects to Site B. I have to shutdown the tunnel interface on site B so the interconnect to site A becomes the path. Then turning the tunnel back on
Site A current:
All have default weight
- Wan 1 local pref 200/bw 100
- Wan 2 local pref 150/bw 50
- Wan 3 local pref 101/bw 50
- Interconnect weight 60000, default BW and localpref
Site B
interconnect weight 60000, default BW and local pref
*Backup default weight, lp 1, bw 1
I need site B to connect to the core’s advertized routes and site A’s subnet over the interconnect as soon as the neighbor is available, but switch back to the backup link as soon as site A isn’t available over the interconnect. Without setting the weight 60000, I was seeing site B use the backup to connect to site A
This was actually working perfectly over OSPF, but with a new network infrastructure I need to isolate each site’s OSPF area 0
Are you doing iBGP peering between A and B, or are you peering with the ISP directly?
Can you post any configs, and your “show ip bgp” from both ends (before and after link flap preferably)
Do you have a diagram that you can share, even if it’s just basic?
Do you have to flap the link, or does “reset ip bgp all” fix it as well?
Thanks, its all ibgp over vpn tunnels, but i learned from a coworker that if i use route prepending it will make the shorter path between site B and the core appear longer. My attempt to set bandwidths and local prefs are only useful for local path selection, but do “obviously” nothing when selecting the path between AS in the whole network
1 Like
BGP is a different animal from that of OSPF.
You might review the BGP patch selection process, such as BGP Attributes and Path Selection
Certain attributes are only locally significant, some may stay within an AS, and some can be sent out to neighboring AS.
This might help you decide how you wish to affect routing policy with BGP.