You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository was archived by the owner on Dec 10, 2024. It is now read-only.
if networks['vpnMode'] == 'spoke':
for peers in networks['merakiVpnPeers']:
if peers['networkId'] == vmx1_id or peers['networkId'] == vmx2_id:
vMX will only learn routes for Networks that have designated vMX as a Hub in Spoke.
In other words, AWS's Route table does not learn the routes of other Hubs.
Therefore, if you have a DC-DC Failover Topoglogy with a multi-sided configuration of DC and AWS, you will need to modify your scripts.
The text was updated successfully, but these errors were encountered:
I correct the information.
Upon investigation, this issue was not a limitation of the script.
In effect, the DC-DC Failover topology for Meraki vMX can only be configured with Hub & Spoke.
Therefore, it is affected by the Meraki MX Series specifications, not by script constraints.
This issue is complex and will be explained step by step.
First, in the DC-DC Failover topology, the Hubs (Primary & Secondary hubs) exchange the same routes, so loops occur as it as.
The Primary & Secondary Hubs only have a Static Route of 0.0.0.0 in Underlay, so the individual routes learned by Auto VPN are preferred.
Second, to stop the loop between Hubs, you need to ask support to disable route exchange between Hubs.
And if route exchange between Hubs is disabled, in effect Full Mesh or Partial Mesh configurations will not be possible.
It means that only Hub & Spoke configuration is possible.
I have contacted Meraki Technical Support in Japan to confirm the specifications for loop.
The specifications for loops are not described in the English documentation.
I asked them to describe it in the Japanese documentation.
In my environment, no loops occurred.
However, support responded that looping is the expected behavior.
It's just a guess.
I thought that the Local Networks setting was being treated as equivalent to Static Route to prevent eBGP Multihop flaps.
However, support says it has nothing to do with it.
For eBGP multi-hop, this option is configured per neighbor. This value can be adjusted to peer the concentrator with something multiple hops away in the data center or cloud. If multihop is used AND the eBGP peer is also advertising the IP route that the MX is using to connect to the eBGP peer, 10.101.0.0/24 in the above example. Then this route MUST be added to the list of 'Local Networks' in the 'VPN settings' section above the 'BGP settings' section of the 'Site-to-site VPN' page, as shown below:
There are conditions in lambda_function.py that defines the target of route learning.
https://github.com/aws-quickstart/quickstart-cisco-meraki-sd-wan-vmx/blob/main/functions/source/lambda_function.py
vMX will only learn routes for Networks that have designated vMX as a Hub in Spoke.
In other words, AWS's Route table does not learn the routes of other Hubs.
Therefore, if you have a DC-DC Failover Topoglogy with a multi-sided configuration of DC and AWS, you will need to modify your scripts.
The text was updated successfully, but these errors were encountered: