Test of ISPs in Dual WAN Hub - Single WAN Spokes setup

thomasthomsen
Head in the Cloud

Test of ISPs in Dual WAN Hub - Single WAN Spokes setup

Hi all

 

In order to test two different ISPs in a Dual WAN HUB setup is it possible to get some or just one of the spokes to connect to only WAN2 of the Dual WAN HUB setup ?

I could create a rule on the HUB telling it that all traffic to a spokes network should go out WAN2.

But the other way around, from the spoke to the HUB, what do you do about that traffic ?

There does not seem to be a "nice" option.

So Im guessing if the spoke starts traffic, it will just send all that over the primary tunnel thats on WAN1 on the HUB.

 

This would be really nice, also in a kind of load balance scenario, if you do not have enough bandwith to a DC on just one WAN connection. (But thats not my scenario).

 

But still, do anyone know of a nice way of doing it, or if it even possible ?

 

Thanks

Thomas

8 Replies 8
rhbirkelund
Kind of a big deal

On the Spoke site, can't you create a flowpreference and point a source/destination subnet to prefer WAN2?

LinkedIn ::: https://blog.rhbirkelund.dk/

Like what you see? - Give a Kudo ## Did it answer your question? - Mark it as a Solution 🙂

All code examples are provided as is. Responsibility for Code execution lies solely your own.

Hm.. Correction, that is for Internet bound traffic.

 

Shooting from the hip here.. What about a VPN traffic preference? If you create a performance class that would "break WAN1", and create a VPN traffic preference for source/destination to use WAN2?

 

LinkedIn ::: https://blog.rhbirkelund.dk/

Like what you see? - Give a Kudo ## Did it answer your question? - Mark it as a Solution 🙂

All code examples are provided as is. Responsibility for Code execution lies solely your own.
ww
Kind of a big deal
Kind of a big deal

Spoke has only a single wan

Spoke Wan1 setup tunnels to wan1 and wan2 of the hub. You cant force to which tunnel that traffic is going from the spoke

thomasthomsen
Head in the Cloud

Yeah that is kinda what I was starting to conclude.

I can do it from traffic with source from the DC (with VPN traffic preference).

But not the other way around.

*sigh* ....

I wish .. I guess.... 

rhbirkelund
Kind of a big deal

Ah, misunderstood that. Sorry for the confusion. 🙂

LinkedIn ::: https://blog.rhbirkelund.dk/

Like what you see? - Give a Kudo ## Did it answer your question? - Mark it as a Solution 🙂

All code examples are provided as is. Responsibility for Code execution lies solely your own.

As always. No worries. 🙂

thomasthomsen
Head in the Cloud

I just realised that this "issue" might actually be kind of a big limitation. (sorry for now getting into "rant territory" 🙂 )

 

If the single WAN Spoke has two tunnels to the dual WAN HUB what does it do in these two tunnels ?

Loadbalance ? - Failover ?

 

If it's just failover between the two tunnels from the single WAN spokes perspective (and I think it is in this case), you really can't use this setup to potentially get better performance in the DC/HUB end (or spoke end for that matter)

The Spoke will never know if WAN1 on the HUB end is congested. It will only be traffic from the HUB end that will know. Im guessing here that probes will only be send and evaluated pr. WAN connection, not pr. tunnel.

So all traffic started on the Spoke end might end up "bad", while traffic started from the DC/HUB end is ok.

This is what Im thinking.... but I might be wrong (someone please say Im wrong 🙂 )

 

The proper setup, I guess, would be to have a an option to select pr. tunnel preference in SD-Wan Policies.

Someday ... Someday ... I guess.....

Or , come to think of it, it would be really "cool" if the DUAL WAN end looked at incoming traffic, and from its probes, it knew that the WAN connection that the traffic was received on was bad, and then "instructed" the Single WAN end to switch to the other tunnel so it would receive all additional traffic on the other WAN.

Does it work this way ? Dont know....

Get notified when there are additional replies to this discussion.
Welcome to the Meraki Community!
To start contributing, simply sign in with your Cisco account. If you don't yet have a Cisco account, you can sign up.
Labels