Cloud Managed Networks

The netdestination sounds odd. Does the entries in the list ever change when going from toggling DR mode on/off? I would probably get the ticket escalated to ERT.  I cant really think of times that I have ever used more then 5-6 items in a single net-dest config. Maybe there is a different approach you can take due to hierarchy of designs. You could try creating a general net-dest entry and apply it to roles at a global level. At a site level you could select the checkbox for a local override. There are alot of different alias you can use that have been very beneficial for layering items at a hierarchy. I have been successful with generalized template configs and then overwrite the alias at the site level. 

As to the certificate thing. The last I had checked was Jan/Feb and that functionality was not completed yet. I had to load the cert in classic central and then go into new central and perform the import option from classic (There is an action option for import).  At the time it didn't matter how the cert was packaged (pem / pfx / etc). ERT informed me at the time that it was not fully migrated yet. 

I am still waiting for the vpn orchestration and topology to be supported. 

I have been using 10.7 since it was released. I have had a couple hiccups with microbranch AP's upgrading to 10.8. You can try downgrading the gateway to 10.7.latest and see if you have issues with net-destination then. May have to see if you can enable debugging for the config syncing from central to see what is happening. 

The netdestination sounds odd. Does the entries in the list ever change when going from toggling DR mode on/off? I would probably get the ticket escalated to ERT.  I cant really think of times that I have ever used more then 5-6 items in a single net-dest config. Maybe there is a different approach you can take due to hierarchy of designs. You could try creating a general net-dest entry and apply it to roles at a global level. At a site level you could select the checkbox for a local override. There are alot of different alias you can use that have been very beneficial for layering items at a hierarchy. I have been successful with generalized template configs and then overwrite the alias at the site level. 

As to the certificate thing. The last I had checked was Jan/Feb and that functionality was not completed yet. I had to load the cert in classic central and then go into new central and perform the import option from classic (There is an action option for import).  At the time it didn't matter how the cert was packaged (pem / pfx / etc). ERT informed me at the time that it was not fully migrated yet. 

I am still waiting for the vpn orchestration and topology to be supported. 

I have been using 10.7 since it was released. I have had a couple hiccups with microbranch AP's upgrading to 10.8. You can try downgrading the gateway to 10.7.latest and see if you have issues with net-destination then. May have to see if you can enable debugging for the config syncing from central to see what is happening. 

We are working with support on this, but an observation was made yesterday.  When you create a new Netdestination in Central it requires you to select an IPv4 or IPv6 option.  The IPv4 option is selected by default.  You then add the networks or host to the list and save the changes.   After this you can no longer edit the IPv4 option.  In our case after saving both IPv4 and IPv6 are greyed out and it appears neither are selected.  And because we can't edit it there is nothing, I can do to fix it.

My team created a new test one and again it defaulted to IPv4 and after saving the changes the IPv4 still shows.  It is an exact copy, minus the name, of the other netdestination where the IPv4 did not stick.  So now I am left with is this the issue?  What caused this?  Will it happen again?  And how do I fix it?  It took days to get those in there and assign to access policies.

Actually this was a really good find. I had realized we were impacted as well. I could not find any times that this stripped the config form my campus APs. It most likely seemed as cosmetic. I can always open a ticket and work with an ERT resource to get an answer if needed. Maybe I created these entries back in Dec and something could have happened with a routine update. 

 I was able to correct this with an API call pretty easily. No need to rebuild anything. A PATCH update fixed this and corrected what was in the gui. You are welcome to PM if you need help or guidance with API calls to update. 

https://developer.arubanetworks.com/new-central-config/reference/updatenetgroupsnetgroupbyid

I am not going to show api call for PATCH but I looked in audit trial and you can see the update take place. I also showed the updated item in the GUI. 

We are working with support on this, but an observation was made yesterday.  When you create a new Netdestination in Central it requires you to select an IPv4 or IPv6 option.  The IPv4 option is selected by default.  You then add the networks or host to the list and save the changes.   After this you can no longer edit the IPv4 option.  In our case after saving both IPv4 and IPv6 are greyed out and it appears neither are selected.  And because we can't edit it there is nothing, I can do to fix it.

My team created a new test one and again it defaulted to IPv4 and after saving the changes the IPv4 still shows.  It is an exact copy, minus the name, of the other netdestination where the IPv4 did not stick.  So now I am left with is this the issue?  What caused this?  Will it happen again?  And how do I fix it?  It took days to get those in there and assign to access policies.

@justink Thank you for sharing this.  I am new to APIs but will see if we can figure it out and reach out if needed.   

Actually this was a really good find. I had realized we were impacted as well. I could not find any times that this stripped the config form my campus APs. It most likely seemed as cosmetic. I can always open a ticket and work with an ERT resource to get an answer if needed. Maybe I created these entries back in Dec and something could have happened with a routine update. 

 I was able to correct this with an API call pretty easily. No need to rebuild anything. A PATCH update fixed this and corrected what was in the gui. You are welcome to PM if you need help or guidance with API calls to update. 

https://developer.arubanetworks.com/new-central-config/reference/updatenetgroupsnetgroupbyid

I am not going to show api call for PATCH but I looked in audit trial and you can see the update take place. I also showed the updated item in the GUI. 

We are working with support on this, but an observation was made yesterday.  When you create a new Netdestination in Central it requires you to select an IPv4 or IPv6 option.  The IPv4 option is selected by default.  You then add the networks or host to the list and save the changes.   After this you can no longer edit the IPv4 option.  In our case after saving both IPv4 and IPv6 are greyed out and it appears neither are selected.  And because we can't edit it there is nothing, I can do to fix it.

My team created a new test one and again it defaulted to IPv4 and after saving the changes the IPv4 still shows.  It is an exact copy, minus the name, of the other netdestination where the IPv4 did not stick.  So now I am left with is this the issue?  What caused this?  Will it happen again?  And how do I fix it?  It took days to get those in there and assign to access policies.

Your welcome. I am not sure if that value being removed has any issues with the config syncing or not. I would check your gateways before updating it, and after. I had spot checked my campus AP's with the 4-5 net-dest that did not have ipv4 in them. The AP's I spot checked all seemed to have the proper net-dest for v4. 

I do not have any gateways in CNX yet. We only use VPN gateways and I am waiting for those features. In the documentation for the PATCH they have an option for v4_v6, although it clearly states that devices do not support this.  Its prettty easy to check config for gateways and AP's. All the net-dest are defined as v4 or v6 when created. It would only make sense to do the same in the mgmt suite. 

They make it pretty easy to do on the developer page for GET (fetching). A PATCH is to update some options on an existing entry. They do not include the bearer token on the PATCH, although its pretty easy to get this and use a linux machine with curl. Your other option is to use something like postman. The general API call is pretty easy to do once you generate a bearer token. 

It would be easier for me to push a defect on a specific update if I know the issue happened at a certain time. Since I had started our original configs back in nov. Its hard to say at what point did that get stripped out. Im happy to inquire if you are running into walls. I did not update all of mine and can use some as an example. 

@justink Thank you for sharing this.  I am new to APIs but will see if we can figure it out and reach out if needed.   

Actually this was a really good find. I had realized we were impacted as well. I could not find any times that this stripped the config form my campus APs. It most likely seemed as cosmetic. I can always open a ticket and work with an ERT resource to get an answer if needed. Maybe I created these entries back in Dec and something could have happened with a routine update. 

 I was able to correct this with an API call pretty easily. No need to rebuild anything. A PATCH update fixed this and corrected what was in the gui. You are welcome to PM if you need help or guidance with API calls to update. 

https://developer.arubanetworks.com/new-central-config/reference/updatenetgroupsnetgroupbyid

I am not going to show api call for PATCH but I looked in audit trial and you can see the update take place. I also showed the updated item in the GUI. 

We are working with support on this, but an observation was made yesterday.  When you create a new Netdestination in Central it requires you to select an IPv4 or IPv6 option.  The IPv4 option is selected by default.  You then add the networks or host to the list and save the changes.   After this you can no longer edit the IPv4 option.  In our case after saving both IPv4 and IPv6 are greyed out and it appears neither are selected.  And because we can't edit it there is nothing, I can do to fix it.

My team created a new test one and again it defaulted to IPv4 and after saving the changes the IPv4 still shows.  It is an exact copy, minus the name, of the other netdestination where the IPv4 did not stick.  So now I am left with is this the issue?  What caused this?  Will it happen again?  And how do I fix it?  It took days to get those in there and assign to access policies.

@justink - Thank you we ran the API and now they all have the IPv4 showing.   My team will do some more testing tomorrow to verify if the gateways are getting the netdestinations and I will come back and update this post.   Thank you for the help, I learned a lot about APIs today.

Your welcome. I am not sure if that value being removed has any issues with the config syncing or not. I would check your gateways before updating it, and after. I had spot checked my campus AP's with the 4-5 net-dest that did not have ipv4 in them. The AP's I spot checked all seemed to have the proper net-dest for v4. 

I do not have any gateways in CNX yet. We only use VPN gateways and I am waiting for those features. In the documentation for the PATCH they have an option for v4_v6, although it clearly states that devices do not support this.  Its prettty easy to check config for gateways and AP's. All the net-dest are defined as v4 or v6 when created. It would only make sense to do the same in the mgmt suite. 

They make it pretty easy to do on the developer page for GET (fetching). A PATCH is to update some options on an existing entry. They do not include the bearer token on the PATCH, although its pretty easy to get this and use a linux machine with curl. Your other option is to use something like postman. The general API call is pretty easy to do once you generate a bearer token. 

It would be easier for me to push a defect on a specific update if I know the issue happened at a certain time. Since I had started our original configs back in nov. Its hard to say at what point did that get stripped out. Im happy to inquire if you are running into walls. I did not update all of mine and can use some as an example. 

@justink Thank you for sharing this.  I am new to APIs but will see if we can figure it out and reach out if needed.   

Actually this was a really good find. I had realized we were impacted as well. I could not find any times that this stripped the config form my campus APs. It most likely seemed as cosmetic. I can always open a ticket and work with an ERT resource to get an answer if needed. Maybe I created these entries back in Dec and something could have happened with a routine update. 

 I was able to correct this with an API call pretty easily. No need to rebuild anything. A PATCH update fixed this and corrected what was in the gui. You are welcome to PM if you need help or guidance with API calls to update. 

https://developer.arubanetworks.com/new-central-config/reference/updatenetgroupsnetgroupbyid

I am not going to show api call for PATCH but I looked in audit trial and you can see the update take place. I also showed the updated item in the GUI. 

We are working with support on this, but an observation was made yesterday.  When you create a new Netdestination in Central it requires you to select an IPv4 or IPv6 option.  The IPv4 option is selected by default.  You then add the networks or host to the list and save the changes.   After this you can no longer edit the IPv4 option.  In our case after saving both IPv4 and IPv6 are greyed out and it appears neither are selected.  And because we can't edit it there is nothing, I can do to fix it.

My team created a new test one and again it defaulted to IPv4 and after saving the changes the IPv4 still shows.  It is an exact copy, minus the name, of the other netdestination where the IPv4 did not stick.  So now I am left with is this the issue?  What caused this?  Will it happen again?  And how do I fix it?  It took days to get those in there and assign to access policies.

That was a quick turn around. Glad to hear things worked out with correcting the invalid config. It would be interesting to find out if that fixes your sync issues. Just keep in mind that API's dont typically do error checking the same as it would in the GUI or CLI of a device. There is potential to overwrite configs or push something that is not supported. Just error on the side of caution when performing a PATCH / POST. 

I actually had to do some searching to find which API was intended for the alias (net-dest). In the web its under alias, but its not part of the alias api output. I checked a valid example and then looked for examples that didn't meet that criteria at a top level. I didn't share everything as it was not necessary and just wanted to show you that it could be done and fixed pretty quick without hours of recreating. 

The hierarchy in CNX can also make it a bit more difficult for the api aspect. The shared vs local and hierarchy can take some time to get used to with config changes. 

@justink - Thank you we ran the API and now they all have the IPv4 showing.   My team will do some more testing tomorrow to verify if the gateways are getting the netdestinations and I will come back and update this post.   Thank you for the help, I learned a lot about APIs today.

Your welcome. I am not sure if that value being removed has any issues with the config syncing or not. I would check your gateways before updating it, and after. I had spot checked my campus AP's with the 4-5 net-dest that did not have ipv4 in them. The AP's I spot checked all seemed to have the proper net-dest for v4. 

I do not have any gateways in CNX yet. We only use VPN gateways and I am waiting for those features. In the documentation for the PATCH they have an option for v4_v6, although it clearly states that devices do not support this.  Its prettty easy to check config for gateways and AP's. All the net-dest are defined as v4 or v6 when created. It would only make sense to do the same in the mgmt suite. 

They make it pretty easy to do on the developer page for GET (fetching). A PATCH is to update some options on an existing entry. They do not include the bearer token on the PATCH, although its pretty easy to get this and use a linux machine with curl. Your other option is to use something like postman. The general API call is pretty easy to do once you generate a bearer token. 

It would be easier for me to push a defect on a specific update if I know the issue happened at a certain time. Since I had started our original configs back in nov. Its hard to say at what point did that get stripped out. Im happy to inquire if you are running into walls. I did not update all of mine and can use some as an example. 

@justink Thank you for sharing this.  I am new to APIs but will see if we can figure it out and reach out if needed.   

Actually this was a really good find. I had realized we were impacted as well. I could not find any times that this stripped the config form my campus APs. It most likely seemed as cosmetic. I can always open a ticket and work with an ERT resource to get an answer if needed. Maybe I created these entries back in Dec and something could have happened with a routine update. 

 I was able to correct this with an API call pretty easily. No need to rebuild anything. A PATCH update fixed this and corrected what was in the gui. You are welcome to PM if you need help or guidance with API calls to update. 

https://developer.arubanetworks.com/new-central-config/reference/updatenetgroupsnetgroupbyid

I am not going to show api call for PATCH but I looked in audit trial and you can see the update take place. I also showed the updated item in the GUI. 

We are working with support on this, but an observation was made yesterday.  When you create a new Netdestination in Central it requires you to select an IPv4 or IPv6 option.  The IPv4 option is selected by default.  You then add the networks or host to the list and save the changes.   After this you can no longer edit the IPv4 option.  In our case after saving both IPv4 and IPv6 are greyed out and it appears neither are selected.  And because we can't edit it there is nothing, I can do to fix it.

My team created a new test one and again it defaulted to IPv4 and after saving the changes the IPv4 still shows.  It is an exact copy, minus the name, of the other netdestination where the IPv4 did not stick.  So now I am left with is this the issue?  What caused this?  Will it happen again?  And how do I fix it?  It took days to get those in there and assign to access policies.