topic Re: Custom Region in General Topics

Custom Region

jdprovine — Thu, 08 Feb 2018 19:53:05 GMT

Has anyone created a custon region and later found out that there was alrady a built in region for that country? How did you deal with it?

Re: Custom Region

reaper — Fri, 09 Feb 2018 12:09:04 GMT

HI @jdprovine

they can live side by side

Re: Custom Region

jdprovine — Fri, 09 Feb 2018 13:50:20 GMT

@reaper

So I can rename my custom one and cause not issues, cause right now they are named exactly the same. I cannot see both like you can. I want to avoid having the same issue I am having now when someone created a custome BR, created a rule with it, deleted the rule , and deleted the custom BR and that is what caused my autocommit to fail

Re: Custom Region

reaper — Fri, 09 Feb 2018 15:36:24 GMT

Interesting!

Yes, if they have a unique name that does not match (case sensitive) the built-in region, they can exist side by side
If you have previously created a custom one named exactly (case sensitive) the same, that would cause a conflict and will make commits fail

Re: Custom Region

jdprovine — Fri, 09 Feb 2018 15:44:07 GMT

@reaper

My plan is to give the custom region another name, reassign the rules that have it to the built in region, delete the custom region and the preform the CLI that will clean up the issue as preposed by TAC. FYI I was not the creator of the custom region, the downside of having more than one administrator LOL

Re: Custom Region

jdprovine — Mon, 12 Feb 2018 20:25:32 GMT

@reaper @BPry @Mick_Ball

I changed the name of my custom region from US to US-Custom and commited the change - under objects/region.

In the CLI it went from this, then i changed a couple of my rules to US (United States) and the rule broke any ideas what went wrong? Why would changing of a custom regions name create another ID?

ID Name
---------- --------------------
1024 vsys1+BR
1025 vsys1+US

To this

ID Name
---------- --------------------
1024 vsys1+BR
1025 vsys1+US
1026 vsys1+US-Custom

Type: 36 Last id: 1027 Mismatch cnt: 0

Re: Custom Region

BPry — Mon, 12 Feb 2018 20:51:47 GMT

@jdprovine,

If you go into configure mode and run 'Show Region' what actually shows up. Those would be your 'Custom' regions.

Re: Custom Region

jdprovine — Mon, 12 Feb 2018 20:56:11 GMT

@BPry

The name i changed it too -

old name US

new name US- Custom (this show when I go into configure mode and run show region

Re: Custom Region

BPry — Mon, 12 Feb 2018 20:57:45 GMT

@jdprovine,

Then you should be perfectly fine and the new 'US' is simply the default entry getting put back into the configuration.

Re: Custom Region

jdprovine — Mon, 12 Feb 2018 21:10:34 GMT

@BPry

So I should be able to add the built in use and it should work right? Isn't this say that there are now two custom regions with two different ID's?

1025 vsys1+US
1026 vsys1+US-Custom

According to this output when I changed the name of an existing custom region it created another ID for it in the ID manager

Re: Custom Region

BPry — Mon, 12 Feb 2018 21:06:51 GMT

@jdprovine,

I guess I'm lost on what command you are running to even get that? If the 'show region' command only shows the US-Custom entry then the US is not a custom region.

Re: Custom Region

jdprovine — Mon, 12 Feb 2018 21:13:29 GMT

@BPry

This was the command that TAC had been run to get the following results of what is in the ID manager

debug device-server dump idmgr type vsys-region all

ID Name
---------- --------------------
1024 vsys1+BR
1025 vsys1+US
1026 vsys1+US-Custom

Type: 36 Last id: 1027 Mismatch cnt: 0

According to this output when I changed the name of an existing custom region it created another ID for it in the ID manager

Re: Custom Region

BPry — Mon, 12 Feb 2018 21:24:28 GMT

@jdprovine,

Okay that makes more sense. It has to do with the way idmgr functions until you restart the device. Since 'US' effectively adds itself back in when you changed the entry idmgr doesn't see it the same as it would if you restart the device all-together. Once the device is restarted and the autocommit process goes through again you'll see vsys1+US drop off from idmgr.

Re: Custom Region

jdprovine — Mon, 12 Feb 2018 21:34:01 GMT

@BPry

These were the steps that TAC told me to use

Part I
1. Update the custom region US to US-Custom
2. See if the US-Custom and US are now options that show up in the list
3. Change the security policies from US-Custom to US
4. Delete custom region
5. debug device-server reset id-manager type vsys-region
6. configure/commit force

I did this

1. Update the custom region US to US-Custom -commit
2. See if the US-Custom and US are now options that show up in the list
3. Change the security policies from US-Custom to US

Re: Custom Region

reaper — Mon, 12 Feb 2018 21:41:36 GMT

I think I retraced your steps

so i had a custom object, which was named 'BE' and then renamed to 'BE-custom'

what happens is that the 'built in' region keeps existing, but it's no longer a custom object because you renamed that:

reaper@PA-220> debug device-server dump idmgr type vsys-region all 

ID         Name
---------- --------------------
1024       vsys1+home
1025       vsys1+BE
1026       vsys1+be

Type: 36 Last id: 1027 Mismatch cnt: 0

reaper@PA-220> debug device-server dump idmgr type vsys-region all

ID         Name
---------- --------------------
1024       vsys1+home
1025       vsys1+BE
1026       vsys1+be
1027       vsys1+BE-custom

if you then use the original region in policy, your commit fails, bcause it's actually no longer a valid object (you renamed it)

Details
vsys1
Error: Failed to find address 'BE'
Error: Unknown address 'BE'
Error: Failed to parse security policy
(Module: device)
Commit failed

so you shouldn't make a region object named identically as an existing region and then afterwards (after your first commit) renaming it, unless you first reboot or reset the id-manager:

reaper@PA-220> debug device-server reset id-manager type all

All ID manager is unset! Please commit the config again.

reaper@PA-220> configure 
Entering configuration mode
[edit]                                                                                                                                                                                                
reaper@PA-220# commit force



Commit job 35103 is in progress. Use Ctrl+C to return to command prompt
................................55%.....70%...98%............100%
Configuration committed successfully

[edit]                                                                                                                                                                                                
reaper@PA-220# exit
Exiting configuration mode
reaper@PA-220> debug device-server dump idmgr type vsys-region all

ID         Name
---------- --------------------
1024       vsys1+home
1025       vsys1+BE-custom
1026       vsys1+be

Type: 36 Last id: 1027 Mismatch cnt: 0

so if you need to change a region object as above, make sure to reset the id-manager before attempting to re-use the original region name

Re: Custom Region

BPry — Mon, 12 Feb 2018 21:42:43 GMT

@jdprovine,

That sounds exactly like what they should have recommended. In this case 'commit force' is actually needed after resetting the idmgr like this. Once you've followed those steps you'll see the idmgr return to normal and 'US' will leave your listed regions.

Re: Custom Region

BPry — Mon, 12 Feb 2018 21:50:38 GMT

@reaper,

I actually retraced this on a PA-220 in a remote office as well to make sure that I wasn't forgetting anything. It was a nice exercise with this again.

If you actually rename everything to BE-Custom for example and commit it'll commit fine as long as you remove all references to BE. Once the commit has finished you can then go back to put in the default BE group and everything continues to function as it should. However, the ID-Manager will maintain the BE listing until you fully restart the device or reset the id-manager.

Re: Custom Region

reaper — Mon, 12 Feb 2018 22:01:17 GMT

@BPry

i skipped that step as @jdprovine mentioned explicitly using the 'original' name without having first added a new custom object, (so my objects only contained the BE-custom, but my security policy had a 'BE' in it. because ID manager still has the original entry, the GUI allows you to add the original object) which leads to the failed commit

Re: Custom Region

jdprovine — Mon, 12 Feb 2018 23:23:39 GMT

@reaper @BPry

Even worse than making the autocommit fail during upgrade, neither US or US-Custom work in the security rule, it blocked traffic, I had to remove those region and replace it with any

Re: Custom Region

jdprovine — Mon, 12 Feb 2018 23:26:00 GMT

@reaper @BPry

And again all I did up update the existing custom region name from US to US-Custom, commited them and then started putting US back on my rules and it broke my rule had to change to any instead of US or US-Custom