- Access exclusive content
- Connect with peers
- Share your expertise
- Find support resources
Enhanced Security Measures in Place: To ensure a safer experience, we’ve implemented additional, temporary security measures for all users.
03-03-2014 11:15 PM
I set ip address 192.168.1.254/24 in the ethernet1 which belong default router in the vsvy1.
I try to set the same ip address in the ethernet2 which belong another VR in the vsvy2.
When I commit, it will display duplicate address.
I just do some lab about vistual system for my client.
But I want to sure may I set the same ip in different interface between two virtual system?
03-03-2014 11:55 PM
Hello Kylelee,
I don't think we can configure the exact same IP address on 2 different interfaces, even though they are part of 2 different VSYS. It will throw you below mentioned error:
Error: duplicate address for interface ethernet1/xx and ethernet1/yy
Error: interface configuration error
(Module: device)
Commit failed
03-03-2014 11:55 PM
Hello Kylelee,
I don't think we can configure the exact same IP address on 2 different interfaces, even though they are part of 2 different VSYS. It will throw you below mentioned error:
Error: duplicate address for interface ethernet1/xx and ethernet1/yy
Error: interface configuration error
(Module: device)
Commit failed
03-04-2014 08:21 PM
Thanks for your support.
But it's strange, I originally thought that different virtual system shouble be independent system.
03-04-2014 09:07 PM
Hello Kylelee,
Could you please give me some time, i will try to get in touch with product-management team and provide you a valid explanation.
Thanks
03-05-2014 08:43 AM
Hi all,
It's a known limitation for Vsys. You can't have same IP on different interface (member of diff Vsys).
V.
03-05-2014 01:32 PM
As per my understanding you can not have the same ip address on two different interfaces. That is the limitation of the system.
However,
Overlapping IP address space requires separate VR/vsys
Ethernet interface can not have same ip interface even in different vsys.
Hope this help.
Numan
03-05-2014 02:21 PM
This answer is crazy.
Virtual routers exist because we want separation in routing between the devices. Why cripple this ability by preventing a basic function like ip address assignment in different virtual routers.
I hope this is on the near term roadmap to fix. I would classify is buggy behavior.
02-17-2015 10:17 AM
HI, does anyone know if there is a change regarding this?
07-20-2017 11:23 AM
Just confirmed today. This behavior still exists. IP@ space can overlap between multiple VR's but no two interfaces can have the same IP@... Does not require multiple VSYS, though.
07-20-2017 11:37 AM
In addition: the behaviour still exists in 8.0.2
03-24-2021 08:03 AM
in addition vol2: same behaviour in 9.0, 9.1 and 10.0
11-01-2021 06:32 AM
Still seeing same issue. No fix.
11-01-2021 07:30 AM
Hello,
I think if you want PA to fix it, you should give a valid reason. Separate VRs do allow interfaces in the same subnet, which you cannot do on a single VR. For my separate vsys customers, we never assign the same IP address because the vsys are not on an isolated network. We use different IP addresses to route to different firewalls (vsys).
I assume you have a valid design proposed for using the same IP address. I just can't think of any examples now.
Thanks,
Tom
04-21-2022 12:44 PM
For us, we have multiple segmented systems that we setup using the same script for IP addressing, but then leverage NAT going into the main network. This way we don't utilize more addresses and the scripts are easier. With this limitation I have to allocate unique addresses for each backend environment with no useful impact to the main network since those addresses aren't visible/published to the main network.
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!