- Access exclusive content
- Connect with peers
- Share your expertise
- Find support resources
11-25-2013 07:01 AM
Hi all,
Having a paloalto with multiple VR and subnet overlapping ( having multiple interfaces / Sub witth same subnet).
EX:
Int1 - IP: 10.1.1.1/24 - VR1
Int2 - IP: 10.1.1.1/24 - VR2
.....
It works but does anybody knoes how:
For management services, specify one VR or another. You can choose per IP but not per VR / Interface ?
For making a ping in cli, specify as argument which is the source VR ? Because you can specify source IP but not VR.
Thx for your help.
Rgds
V.
12-03-2013 11:10 AM
I can somewhat understand why it doesnt work for different vrouters within the same vsys, but why doesnt it work for different vsys?
Isnt the point of using a vsys to be able to segment the hardware into partitions where each partition doesnt care about the others?
That is a common usecase is if you have several customers where each will manage their own VSYS. In this case it would suck big time if customer2 cannot use 10.0.0.1/30 because customer1 (on a different vsys) has already assigned this to one of their interfaces...
12-02-2013 12:20 PM
How did you configure the interfaces ?
both sub ? because with layer3 ,2 different interfaces with 2 different VR's commit gives error.
12-02-2013 04:25 PM
Nice catch Vince, it looks like you cannot tie the ping to a source interface. It "looks" like you should when you consider the ping options:
ping
+ bypass-routing Bypass routing table, use specified interface
But the bypass-routing allows only 'yes' or 'no' as it's arguments, not a source interface. Bug? Feature? I don't know, but it would be useful if you could. :smileyplain:
12-02-2013 07:15 PM
Looks like this has been overseen by PA and you should contact your SE to get this fixed (most likely through a feature request).
The CLI docs for ping says:
> bypass-routing — Sends the ping request directly to the host on a direct attached network, bypassing usual routing table
> count — Specifies the number of ping requests to be sent (1-2,000,000,000)
> do-not-fragment — Prevents packet fragmentation by use of the do-not-fragment bit in the packet’s IP header
> inet6 — Specifies that the ping packets will use IP version 6
> interval — Specifies how often the ping packets are sent (0 to 2000000000 seconds)
> no-resolve — Provides IP address only without resolving to hostnames
> pattern — Specifies a custom string to include in the ping request (you can specify up to 12 padding bytes to fill out the packet that is sent as an aid in diagnosing data-dependent problems)
> size — Specifies the size of the ping packets (0-65468 bytes)
> source — Specifies the source IP address for the ping command
> tos — Specifies the type of service (TOS) treatment for the packets by way of the TOS bit for the IP header in the ping packet (1-255)
> ttl — Specifies the time-to-live (TTL) value for the ping packet (IPv6 hop-limit value) (0-255 hops)
> verbose — Requests complete details of the ping request.
* host — Specifies the host name or IP address of the remote host
12-03-2013 11:10 AM
I can somewhat understand why it doesnt work for different vrouters within the same vsys, but why doesnt it work for different vsys?
Isnt the point of using a vsys to be able to segment the hardware into partitions where each partition doesnt care about the others?
That is a common usecase is if you have several customers where each will manage their own VSYS. In this case it would suck big time if customer2 cannot use 10.0.0.1/30 because customer1 (on a different vsys) has already assigned this to one of their interfaces...
12-04-2013 01:40 AM
Thx all for your answer. I am working on validation archie. I bypass this limitation by fixing different IP for each Pa's interfaces. But of course it's not really usefull.
Mean using different VR doesn't mean fully independant routing table .... 😞
V.
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!