- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
ospf/eigrp assymetric routing
hi,
I'm attaching a picture that explains it all.
in a nutshell I have 2 hubs and I connect spokes to both hubs.
HUb1 is first and Hub2 is second in the spoke hubs list.
I need a way without doing any manual entry in the cisco core network for the network to know that to reach spoke the network should prefer to route through hub1. please see attached picture.
many spokes but I've selected the middle one as example.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
The MX only advertises the networks it knows, in this case the preference configuration must be done on your Core, or you can try to change the cost of OSPF on the MX.
- Router ID: The OSPF Router ID that the MX will use to identify itself to neighbors.
- Area ID: The OSPF Area ID that the MX will use when sending route advertisements.
- Cost: (Defaults to 1) The route cost attached to all OSPF routes advertised from the MX.
- Hello timer: (Defaults to 10) How frequently the MX will send OSPF Hello packets in seconds. This should be the same across all devices in your OSPF topology.
- Dead timer: (Defaults to 40) How long the MX will wait (in seconds) to see Hello packets from a particular OSPF neighbor before considering that neighbor inactive.
https://documentation.meraki.com/MX/Site-to-site_VPN/Using_OSPF_to_Advertise_Remote_VPN_Subnets
Please, if this post was useful, leave your kudos and mark it as solved.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
it won't work on the hub, if I change the cost of the ospf on the hub itself then that hub is either better always or lesser priority always. yet I have some spokes that prefer that given hub.
seems to me only way as you say is directly on the core. but then again I have to know every subnet I want to give priority to on one side vs the other... too much manual entries.
was hoping for maybe some other option :).
thanks.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
The only option is to configure your SW L3.
Please, if this post was useful, leave your kudos and mark it as solved.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
You would be better off using a BGP peering between your Cisco devices and both Hubs and then redistribute those routes into your IGP.
With the implementation of BGP on Meraki SD-WAN you can actually select a primary hub and then a lower priority secondary hub which will use AS-prepending to make that route less desirable. You can even have split where some sites use the left hub and other sites use the right hub. Your hubs need to be in concentrator mode though.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Doesn't BGP only work on One-Armed Concentrator?
Please, if this post was useful, leave your kudos and mark it as solved.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
my other solution is to take my HUB1 which is actually a cluster of 2 test MX105 (active/passive) and split that into HUB1 and HUB3. I make HUB3 ospf lower priority advertisements as you show in the screenshot on top. then 1 spoke will connect to either HUB1 and HUB3 or HUB2 and HUB3. this way my routing issue is fixed since the backup to all spokes is HUB3 and it sends ospf with lower priority than hub1 and hub2.
I'll still wait and consult with meraki and cisco to see what other options I have but for now this will work.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
yes but I have some spokes primary with hub1 and some spokes primary with hub2.
if I make 1 hub more desirable with bgp in the meraki hub directly then I end up with asynchronous issue again.
so let's say I say hub2 is less desirable with bgp and one of the spokes prefers hub2 due to geography and closer hub to the spoke. now the core prefers hub1. so if from core I ping spoke it will go through hub1 and come back to me through hub2 because spoke prefers hub2.
