Administrative distance does not prefer static bovpn route over an external bgp?
During a migration project in phases, I need to activate 1 branch office vpn per week. Each bovpn will create a static route (192.168.2.x for office2 192.168.3.x for office 3...). However, these vpn routes are overruled by dynamic routes coming in from an existing bgp solution (which we have to migrate).
First I forget thinking about administrative distance and just thought about metric.
They have metric 1 in their dynamic routings that are sent to watchguard. Changing those to metric 10 to give the bovpn static routes with metric 1 a chance is impossible says the bgp provider. How can I tell the watchguard to ignore or overrule certain dynamic routes coming in from bgp, to give preference to static routes that came with BOVPN's, for the same networks?
Well then someone on another community told me about administrative distance having priority over metric. That’s very good info but weird because I read that the administrative distance of external bgp is 20 while the administrative distance of static route is 1. So it should have preferred the static over the bgp yet it shows the bgp in the routing table and the static route is nowhere to be found in the routing table when it overlaps that bgp route.
Answers
Hi @Joris85
I'd suggest taking a look at the list of supported BGP commands here:
(BGP Commands)
https://www.watchguard.com/help/docs/help-center/en-US/Content/en-US/Fireware/dynamicrouting/bgp_commands_c.html
If you're still running into an issue, I'd suggest opening a support case using the support center link at the top right of this page.
-James Carson
WatchGuard Customer Support