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?
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.
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.
@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?
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!