We are designing a setup with PA 3060. On that we plan to have 2 vsys, lets call them V1 and V2.
I have an aggregated interface, lets call it ae22.
I want to create 2 subinterfaces:
ae22.1 ----- will be assigned to V1
ae22.2 ----- will be assigned to V2
Question: Can ae22.1 and ae22.2 have the same vlan number lets say vlan 100 ?
Thanks and Regards,
This is not possible, you can not use the same vlan tag on the same aggregated interface for layer3 sub-interfaces. I also tried using a L2 aggregated interface with 2 vlan interfaces but no success >> " No two logical aggregate interfaces can have same tag value."
I guess you already figured this out the hard way.
So as far as I know now it is not possible to have 2 or more vsys to have a IP in the same network/vlan when this is going via one and the same aggregated interface.
Can I ask why you need the same vlan tag to span the Vsys ? under any condition I would think this would be strange configuration but I have seen stranger requirements, As far as I am aware the configuration as you want it will not work as the firewall will need to use the tag to direct the traffic at the right VSYS.
If we had a better understanding of what you need to achieve it may be easier to assist with a solution.
In my case it is just a simple migration of 3 Cisco ASA virtual contexts to Palo Alto in 1:1 fashion. Since Cisco ASA has no problem with having subinterfaces with same dot1q tag on different contexts it was supposed we proceed with a migration in similar fashion to Palo Alto vSys. Right now it looks like it has such kind of limitation though, which is not a problem on Cisco.
Please see attached picture of our current design. We want to have only single port-channel between PA box and switches. All logical subinterfaces should be hanging off of it.
So the question is - how can we work around this problem and if adding another physical interface for each context is the only solution?
So, let me see if I understand this, you have the three contexts at the bottom of the diagram and you are wanting to share the gateway that is on vlan 99 across the three VSYS ?
If this is the case then I would look at the shared gateway implementation as this would fit your use case perfectly
Hope this helps, if not let me know if I can be of anymore assistance.
AFAIK it won't fit my requirements.
We need to have L3 interface on each of 3 new vSYS on PA box, which is sharing same IP subnet and (ideally) VLAN ID. This is required as we have multiple networks routed through each firewall context and those L3 interfaces are acting like next-hop-address.
So in my picture above 10.10.10.254 is the common gateway for all 3 contexts, but it is not located on FW, it is just a router which has interface within same VLAN/Subnet.
I see, I would like to go away and Lab this up, I am sure there will be a way to make this an easy migration, just for confirmation sake the Vlan that needs to shared across the VSYS in this example is 99 yes ? and then the three contexts are the nexthop gateway for your subnets ?
That's exactly correct. So in our design simplified from a router point of view on top of the pic we have for example:
1. Network A, next-hop is 10.10.10.1/24;
2. Network B, next-hop is 10.10.10.2/24;
3. Network C, next-hop is 10.10.10.3/24
So in fact 10.10.10.0/24 is a transit network between router and firewall contexts.
I see so following workaround: perform migration Cisco-->PA as they currently are, but add PHYSICAL interface to each of vSYS and tag it to VLAN99 from switch side (assuming it will be configured L3 untagged on FW side) or have a subinterface off from it. This way I would be able to overcome a restriction PA has - 'to not have subinterface with the same dot1q VLAN tag on same physical interface'.
Would be grateful if you can share other option which does not require to occupy physical interface for subinterface workload just because it is not allowed by PA.
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!