Limits of VWIRE?

[mikand]

One can find in the datasheets various limits regarding VSYS (where some models wants an additional license) but what about VWIRE?

Are there any limits regarding number of VWIREs one can use for each model (I assume the VM-models doesnt support VWIRE at all)?

Also, are there any drawbacks of putting various VWIREs into the same zone (or is this even possible)?

Im thinking of an example such as:

R1 / R2: outer devices

PA1 / PA2: PA-devices running 1:1 VWIREs

SW1 / SW2: inner devices

and then that R1/R2 will form etherchannels with SW1/SW2 where PA1/PA2 uses VWIRE to be fully transparent.

In a full-mesh version that would mean that PA1 would need something like:

int1: R1_11

int2: SW1_11

int3: R1_12

int4: SW2_12

int5: R2_21

int6: SW1_21

int7: R2_22

int8: SW2_22

That is the aggregating group 11 (formed between R1 and SW1) would have one cable through PA1 and one through PA2 and so on.

The above ends up with 4 x VWIREs.

What Im thinking of here is if there would be any problems of setting up the zones such as:

zone_outer: int1, int3, int5, int7

zone_inner: int2, int4, int6, int8

Edit: Also what is your experience of a setup such as the one above?

[NGS_SOC]

I've a project as you described above, using a couple of PA-3020 in A/A with 2 vwire for each device (4 ports used  each). I configured a single trust zone for even ports and another untrust for odd ports. In my case etherchannel lacp between switch and switch does the dirty job, and is important to specify the round-robin algorithm with load-banlance ip-src-dst to fix traffic on a vwire.  I used different vlan in the same switch, for example coming out traffic from a vlan, inspect in PA, and than putting again into another vlan, same switch. I's also possibile using a different configuration with etherchannel ly3 (no switchport). Used switch : Cisco Catalyst 3750 nand 3560X

In my experience I saw no limits in vwire except the number of ports; total vwire numbers  = floor[(total ports - ha ports) /2]

The only drowback, except natural loss of routing and vpn, is avoiding inspected vlan traffic flowing agin into same vwire etherchannel, this could happen in multiple vlan tagged are present and switch does intervlan routing.

[mikand]

Thanks for the headsup regarding the loadsharing algorithm to make sure its L2 or L3 and not L4 (that is loadsharing where srcport and/or dstport is involved would be bad).

Another workaround to add for this might be to use:

set deviceconfig setting session tcp-reject-non-syn no

What about session-syncing?

In your case you used A/A but wouldnt it be sufficient to use two (or more) standalone PA-boxes aswell?

Configuration-wise this could be handled by a Panorama which pushes the same config (security policies etc) to both devices. Or is it possible to setup a HA-sync between two PA-boxes and only sync the config between them (like two standalone boxes but they share the same security policies)?

Regarding the failover situation, when a link in the etherchannel breaks, Im thinking if im missing something with this assumption?

*) Etherchannel is formed between R1 and SW1 where one link goes through PA1 and the other through PA2 (PA's running with VWIRE).

*) Thanks to loadsharing algorithm set to L3-mode (srcip+dstip), or perhaps even better dstip going R1->SW1 and srcip going SW1->R1 (this would handle any appid's based on heuristics like skype or whatever), traffic for a specific server/client-combo connected to SW will always travel the same path (and by that the packets will be in order aswell etc).

*) Now there is a linkfailure and the traffic start to pass through the other PA-device instead.

If "set deviceconfig setting session tcp-reject-non-syn no" is set this shouldnt be any problem. However if AppID is being used this could force an ongoing session to become blocked on the other PA (the one which the ongoing session is now being sent through) after a few packets (which of course would be bad) depending on which AppIDs are being used of course?

If this is true then A/A seems to be the only option to make this work - or how is it supposed to work in the design described in the following docs (or am I missing something here)?

http://www.paloaltonetworks.com/literature/solution-briefs/tech-partners/arista.pdf

http://www.aristanetworks.com/media/system/pdf/palo_alto_networks_arista.pdf

[NGS_SOC]

set deviceconfig setting session tcp-reject-non-syn no

I alway use this command in vwire mode, for me PAN should implement it as default

In your case you used A/A but wouldnt it be sufficient to use two (or more) standalone PA-boxes aswell?

Using two different separate boxes managed by Panorama could be a solution as well, but in the specific project vwire is only a part of the entire solution. I dedicated also ports for ly3 configuration and HA have to be configured. A/P was not the best choice so I decided to set A/A. Session sync is not an issue due to load-balance algorithm and the way how HA is porformed. In case of failure of one device (or cable) sessions are already duplicated from active-primary to active-secondary (and reverse) via HA2 and HA3 links, The issue is on log sparse on two different boxes but using panorama as global collector even this is not a major problem. Also HA license are less expensive than 2 separate ones.

The docs you linked are about core switches similar to Cisco Nexus family, low latency hig performaces, but the configuration with multiple PAs in vwire absorbing etherchnnel single links,  is usable anyhow. Some months ago I found an interesting document,maybe a partner one I have to check, talking about PAN in datacenter, as soon as I found I'll post here.

[tommyluke]

NGS why do you prefer having a VWIRE deployment not track state? I ask because we typically deploy L3 and I'm getting ready to deploy a complex (IMO) VWIRE pair of 3050s.

thx,

Tommy Adams