Dual active VPN uplinks - DC traffic policy

[Adoos]

If your mX65 has dual active VPN uplinks how do you control which interface the traffic comes over from the DC? 

You can dictate the outbound traffic for the MX65 but it seems you have no control over the traffic back or originating from the DC. 

Does Meraki have a secret SDWAN way of sending traffic to the MX65 WAN interfaces?

[PhilipDAth]

The return traffic comes back via the same WAN port that the traffic was initiated from.

[Adoos]

Yes we understand traffic from MX65 outbound should come back through the same WAN interface. This is in a dual DC concentrator scenario and specifically talking about traffic coming from the DC concentrator to the MX65. 

What tells the concentrator to send traffic to WAN1 or WAN2? We notice some traffic coming over the WAN2 interface and some coming WAN1.The concentrator only has one interface active. 

[PhilipDAth]

Mmm, good question.  I don't know about traffic initated from the DC.

I'm going to guess it will use the WAN port that is configured as the preferred port for VPN traffic (on the spoke), or if none is defined, the preferred uplink.

[Adoos]

I guess we have no way to know which tunnel the traffic is even using. 

[PhilipDAth]

I'm thinking you would need to do a packet capture on the spoke.  You could also try doing a real time monitor of the WAN circuits and then initiate a lot of traffic.

[GreenMan]

For sessions initiated from the one-armed Hub, initially the Concentrator MX chooses one of it's two available tunnels to the relevant spoke fairly arbitrarily  (it's actually round-robin).   The Spoke MX then chooses the tunnel for the reply packets relating to this session, based on its own configured performance and policy SD-WAN rules.   Once the Hub MX sees the tunnel preferred by the Spoke, it will flip subsequent traffic, for that session, to match the Spoke's preferred tunnel.

[Adoos]

Oh ok, now we know how it works. Is this documented anywhere?

[PhilipDAth]

I don't recall seeing this documented anywhere.  Perhapos another job for @CameronMoody .

[Adoos]

Have you come across any Cisco SIP voice issues in this architecture? @GreenMan 

[GreenMan]

I haven't, but I'm not sure what customers of mine, if any, have this use-case. Can anyone here add anything further? Are you seeing specific issues Adoos, or are you in planning phase?

[Adoos]

Bit late on a response here but this has come up again, interested to see if anyone else has come up with this or can replicate. 

Scenario:

Active-Active Auto VPN enabled 

WAN 1: - MPLS | 4/4Mb/s

WAN 2: - NBN | 100/40Mb/s

We push SIP and Citrix over MPLS and everything else over NBN (including windows file share) with regular internet traffic breaking out at the branch directly. 

Issues: 

1. When active-active is enabled and spoke branch attempts to download a file from one of our shared drives in the DC they are experiencing incredibly poor download performance, basically if a PDF is 40MB you can be sure it will take either 5 minutes or will timeout.

Troubleshooting Steps:

• Initial thoughts were AMP as this has bitten us plenty of times so disabled that and still no good. 
• Maybe it's SMB? Poked around here and nothing obvious found as LAN speeds to the file share are excellent. 
• Maybe QOS? Checked that and everything is within spec. 
• To be sure it wasn't SMB or our server related in general we shared a file path on a PC to the remote site user with a 40MB pdf and when testing we experienced acceptable speeds/download time. 
  • That confused us so we kept digging and didn't get anywhere. 😃
• Ready to pass the ball to the systems team we disabled active-active auto VPN as this has bitten us previously for the same issue and conducted our tests again...suddenly download speeds are beautiful. 

Conclusion

Assuming our config is fine which i'm confident it is, something is seriously not right with the active-active feature. 

Raised a ticket with Meraki support and confirmed traffic is traversing WAN1 and WAN2 regardless of the policy in place. Meraki are going to dig a bit deeper and report back what is going on here. 

I thought the DC should respect what SDWAN policies are set and send file share traffic back via the NBN tunnel.

High number of TCP retrans and packets out of order when the feature is enabled with almost none when disabled. 

Versions:

MX67: 14.40 (branch)

MX250: 14.39 (dc)

[GreenMan]

Basically I think you need to follow this one through with the case on our Support team...