VSNext inter-vs communication

[melcu]

Hi Expert,

I have a setup with 3 gateways running R82 ElasticXL in VSNext.

vs0 - management, bla bla

vs1 - servers

vs2 - "other servers" + wifi + users + whatever

Requirements:

VS2 "wifi" should comunicate with vs1's servers

vs1 servers need to communicate with vs2 'other servers'.

What I am not understanding in VSNext is:

 - if you create one Virtual Switch but do not assign an external (physical) interface can you use it by "connec to Vritual Swtich" inside each VS and just put a  /30 in between ?  Then  static routes   from vs1 to x.x.x.x/24 from vs2  via interconnect

from vs2 return static routes /24 via vs1 interconnect.

Will this work ?

[Bob_Zimmerman]

That's exactly how it would work, yes.

[Global] DallasticXL-s01-01:0> add vsnext virtual-[ESC][ESC]
add vsnext virtual-gateway interfaces VALUE id VALUE one-time-password VALUE instances VALUE instances6 VALUE wait-for-task VALUE
add vsnext virtual-link virtual-gateway VALUE virtual-switch VALUE wrp-id VALUE
add vsnext virtual-switch name VALUE id VALUE wait-for-task VALUE

When building a new switch VS, you just need to specify a name and an ID (which can be "auto" to let the system assign a VSID).

Once the switch exists, you add warp links by specifying the non-switch VSID, the switch VSID, and the warp ID (which can also be "auto"). Remember to add this to the gateway's topology in the management and to push policy for antispoofing to work correctly.

From there, it's like any other transit interface. I know older VSX wouldn't let you use /31 blocks, and I'm not sure if VSNext resolved that limitation. A /30 should be fine, just wasteful. You can either add static routes or use dynamic routing (e.g, with a route-map to redistribute connected routes so as you add new interfaces on either VS, the other will just pick up the routes).

I'm not sure if switch VSs run any form of STP, so be careful with your topology.

[Wolfgang]

@Bob_Zimmerman  and @melcu I believe you need to assign a physical or VLAN interface for such a connection. Iˋm not really sure maybe something changed with VSnext but with VSX you need this interface. With VSX and ClusterXL you can have a configuration Running one VS1 on clusternodeA and Running VS2 on clusternodeB. If you want connectivity between both VSs you need an external switch and assigned interfaces and too the virtual switch. All packets are flow through the external switch.

I believe with ElasticXL there is too a need with such a configuration.Maybee @emmap or @Lari_Luoma can comment this.

[melcu]

Thanks but what will be the reason to call it "virtual" if you need to route between external :))
I will spin up 2 gateways in EXL and try to do a /30 between VS 1 and VS2 and ping between.

If you're asking me is a stupid to use an external interface 😞 It's not like when you have VSLS were  VS1 sits in Netherlands and VS2 is in Japan.

[Bob_Zimmerman]

That definitely wasn't a requirement on classic VSX.

I was once involved in a datacenter connection project with constantly changing requirements. We ordered new firewalls based on the "final requirements", but the project team changed them again before the boxes were even delivered. Now they wanted something with a given address in one DC to be able to talk to something with the same address in the other DC, so we needed two NAT points. Complex political situation resulted in us being told we had to deliver without any additional purchases. The final deployment was VS0 handling traffic on one side, a switch for VS1, then VS2 handling traffic for the other side. This is possible using any firewall license (switch VSs don't consume a license slot, and every license comes with VS0 plus one VS). You just need to use vsx_util vsls to tweak VSLS distribution to stick all the VSs on one member, otherwise a lot of traffic can end up on the sync link.

VSNext has an advantage here, though: there's no more Standby state. All the VSs are active on all the members.

[this_guy_again]

Wolfgang is correct, per sk183336.

You need a physical switch to bridge the virtual switches inside each physical host.

[melcu]

So what you are telling me is that if I have 2  and I need  VS1 to communicate with VS2 basically I need to connect  ethX from each SGM to an external layer2 swtich  and then route.

What is the difference in connecting ethx  from  SGM1 to ethx to SGM2  and connecting  both ethX  to an external swtich. 
Who wrote the code for this **bleep** ?

Fortigate has inter-vdom communication and guess what it can do 80Gbps (ask me how I know). It's accelerated by the ASIC. 

Junper has lsys/tsys within its belly.

Check Point .. let's buy some SFPs, let's consume some ports because we need VS1 to communicate with VS2.

So stupid design. Really. SO stupid!

[this_guy_again]

Hmm, you might get away with a back-to-back connection, yeah. As long as the virtual switches are connected... Best to be tested.

[emmap]

It doesn't have to be a whole new interface, a sub-interface/VLAN on an existing trunk will work. I believe the reason for this requirement is for Distribution. The packet might be distributed to SGM 1_1 for VS1 but then SGM 1_2 for VS2. We don't want to load up the Sync interface with all the inter-VS traffic here so we do the pivotting over the VSwitch's 'network' interface. If you only have one SGM per site then you don't need this, as long as your cluster is in HA mode not VSLS mode.