Anyone using vwires consisting of a single interface on one side and a link aggregate on the other?

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Announcements
Please sign in to see details of an important advisory in our Customer Advisories area.

Anyone using vwires consisting of a single interface on one side and a link aggregate on the other?

L2 Linker

We've discovered what we consider a handy feature: creating a vwire with a single interface on one side and a LAG on the other side. This lets you connect a network device with no redundant network connection capabilities to a LAG on a pair of switches for redundancy.

 

We are using this to connect a router and a remote access box to two switches to protect against switch failure.

 

The only concern I have is that I've had a couple of Palo Alto experts say this won't work. One went as far as to say this configuration can't be commited.

 

Anyone else doing this?

11 REPLIES 11

L6 Presenter

Nice, creative! I don't have any experience with this but tempted to try. 🙂

 

Cyber Elite
Cyber Elite

If this is actually working then it would by no means be supported by PA. It would be interesting to know what version of PANos your actually running, as this probably shouldn't have commited as vwire needs at least two interfaces to function correctly.

Out of curiosity what is the benefit of running vwire in this scenario; wouldn't it make more sense to run with a layer2/3 interface and avoid the vwire all together?

I have three interfaces in the vwire (I've started to refer to this setup as a "kinky three-way vwire"). One side of the vwire is a single interface. The other side is an AE made up of two interfaces.

 

The single interface goes in the "outside" security zone and is connected to a device with no LAG possibility. The AE goes in the "inside" zone and the corresponding ports are connected to a LAG on the core switches.

 

The benefit is that I can have something like a remote access box (with only one inside interface) have a path to both of my core switches to protect against a core switch failure. Yes, I realize the remote access box and the Palo are still single points of failure, but I have at least eliminated switch failure as a potential to take down remote access (in this case).

 

And I am a bit concerned about support - especially since two Palo experts have said this won't work. On the other hand, it DOES work, and there is nothing documented that says this isn't a viable config.

 

I  am running 7.1.4-h2

 

 

 

 

O.O That makes way more sense actually, I was under the impression that you had made a vwire with just a single Aggregated interface, which shouldn't work. It makes way more sense now. 

 

I wouldn't be to worried about support unless you actually have an interface issue, if they have to look at your interfaces for something then I would expect that they would just tell you that the way you have them configured is causing your issue. Also as a side note I wouldn't be to suprised if they simply said that was your issue whenever they noticed it while investigating a support ticket; as it would be an easy step to eliminate and it isn't a supported configuration they will probably have you fix it before they continue to troubleshoot anything else. 

My experience with PA support is that they will work with your regardless of your configuration unless there is a clear indication that the configuration in question is the root cause of the issue in the ticket.

 

But I do think you are right to want to get an official answer of this configuration is a good tested and supported configuration.  This can potentially save you time and trouble down the road.  The best way to do that would be to raise an official support case and ask that question explicitly.  Simply upload the config files and your testing results.

Steve Puluka BSEET - IP Architect - DQE Communications (Metro Ethernet/ISP)
ACE PanOS 6; ACE PanOS 7; ASE 3.0; PSE 7.0 Foundations & Associate in Platform; Cyber Security; Data Center

I tried opening a support case. They informed me that support is for fixing problems, and that this was a design issue, and they couldn't help. They directed me to my sales engineer who said that configuration couldn't be committed (wrong) and couldn't possibly work since VWIRE mode doesn't do any layer two switching (again wrong).

 

I sent him screen shots of the setup and in operation, but he never replied.

Wow, I'm sorry you are getting such a run around on what seems like a simple query.  I'm really surprised that support shut you down like that.  My experiences on tickets about best practices have all been very positive.

 

Personally, I would push back with support not sales.  The question at hand is will this configuration be a supported one should issues arise down the road.  Not even a design best practice one.  And I have had support confirm design best practices.

 

I would ask for escalation.  Or perhaps one of the Palo Alto community admins here can assist in this type of query. 

Steve Puluka BSEET - IP Architect - DQE Communications (Metro Ethernet/ISP)
ACE PanOS 6; ACE PanOS 7; ASE 3.0; PSE 7.0 Foundations & Associate in Platform; Cyber Security; Data Center

I'm not too worried about it. If I do call in for support and they don't like my setup, I can always temporarily change it to a standard VWIRE setup pretty easily.

@Ken_Cornetet  and others..

My name is Joe Delio, and I am one of the Palo Alto Network admins. 

 

The main issue in a config like this is that it is "Not Recommended". 

Can it be done? Yes, clearly as you have it working now. 

Now, with everything in life, just because you can, doesn't mean it "should" be done or that it will be supported.

Can you balance a car on 2 wheels and drive? Yes. But it doesn't mean that it is recommended or even designed to work that way.

 

Also, to answer your question about VWire.. 

In order for VWire to function, it needs to interfaces that it can use to forward the traffic from in and out. 

It is also refered to as a "Bridged" Interface Or even "Transparent" interface. VWire is designed to read and foreward or block traffic based upon your configuration. Heck, you can even get NAT with Vwire.. so yes, there can be "modification" of traffic, but unless NAT is configured, no L3 or L2 information is changed on the packets.

 

Now, onto the "issue".  What is the "issue"? 

Is something not working correctly while in this config?

 

Regards,

Joe Delio

LIVEcommunity team member
Stay Secure,
Joe
Don't forget to Like items if a post is helpful to you!

No issues. Seems to work just peachy.

 

I'd think Palo would tout this as a feature, not as "not recommended". This could be a selling point for Palo Alto. This lets a customer get even more benefit by putting a Palo Alto into their mix of network gear.

 

 

Thanks for the clear answer Joe.  This is what I would expect to have been able to get from a support ticket as noted above.

 

My question was exactly that, is this a supported/recommended configuration or would using it open up the possibility of odd behavior and unsupported issues.  Your answer would be yes.

 

Most places that I have worked would then not want to implement that type of solution.

 

It seems to me that asking support if a configuration like this is supported/recommended should be answered and not pushed off like this query was in  the ticket.  And this has not been my experience with asking about recommended/supported configs to support.  So I would have pushed back and said I want an answer.

Steve Puluka BSEET - IP Architect - DQE Communications (Metro Ethernet/ISP)
ACE PanOS 6; ACE PanOS 7; ASE 3.0; PSE 7.0 Foundations & Associate in Platform; Cyber Security; Data Center
  • 3576 Views
  • 11 replies
  • 0 Likes
Like what you see?

Show your appreciation!

Click Like if a post is helpful to you or if you just want to show your support.

Click Accept as Solution to acknowledge that the answer to your question has been provided.

The button appears next to the replies on topics you’ve started. The member who gave the solution and all future visitors to this topic will appreciate it!

These simple actions take just seconds of your time, but go a long way in showing appreciation for community members and the LIVEcommunity as a whole!

The LIVEcommunity thanks you for your participation!