Established Member
Posts: 994
Registered: ‎07-23-2015
Kudos: 536
Solutions: 55

UNMS API Service IPs

I have brought up similar concerns in the past, but this topic here directed me to ask further questions in this forum:

 

https://community.ubnt.com/t5/UCRM/UCRM-API-Service-Device-Management-IP/m-p/2701827#M14292

 

Im very concerned about the ability to differentiate CPE/device management IPs (IPs on equipment the ISP always owns/manages), and Service IPs (IPs on equipment that relate to the customer’s delivered IP service — which may or may not be owned by ISP). Since it seems the suggestion is that development for service-device API features in UCRM is halted in favor of UNMS, I started digging into the UNMS API looking for parity between what I am leveraging today in UCRM and what UNMS supports. It seems there is a very large gap. In an environment where service IPs may be handed to customer-owned equipment (IE equipment not in UNMS), how does the UNMS API plan on tracking/keeping up with Service IPs? Today this is handled in UCRM in a way that allows the CSR to specify the Service IP with no requirement that the device receiving the Service IP be managed by UNMS. It seems that by switching over to a UNMS-managed API for Sevice IPs, it becomes MANDATORY that all devices receiving Service IPs also be managed by UNMS. This is further confirmed by @UBNT-Meiv pointing me to the UNMS API reference for “devices”. 

 

Can I get a confirmation if this is indeed the case?

Please don't forget to kudo helpful posts and mark accepted solutions accordingly!
jcm.me - Personal Site | Joyn.Tech - Consulting Site

Add Auto-Provisioning Support to UNMS
Add DAI/IP Source Guard to Edgeswitches
Ubiquiti Employee
Posts: 3,280
Registered: ‎09-08-2017
Kudos: 1244
Solutions: 245

Re: UNMS API Service IPs

@Joyn  Hello Joshua. 

At this moment UNMS doesn't have an IP management system. We are definitely going to implement one in the future though. Right now there is no API that would return a list of all IP addresses, their types etc...
Instead, UNMS works with different entities, namely Sites, Clients, Devices, Interfaces, and their IP addresses. 

From the monitoring perspective, it doesn't matter what type is the IP address. When any device is connected all IP addresses are acquired from its interfaces. 
With the introduction of features like QoS and Suspend it will become important to recognize Ip addresses in the internal ISP network and in customers' homes. To accommodate this need there will be section 'Network' available in UNMS version 0.14.0. where the user will need to specify the IP address range of the internal network.
After that whenever a suspend of any customer is about to take place, UNMS will find which devices belong to that customer, what are their interfaces, what IP addresses are on those interfaces and then it will block those addresses in the internal network IP range.

UBNT_Alternate_Logo.png
UNMS Support - If you want to report an issue please use this guide.

Check out our ever-evolving Help Center for answers to many common questions!

Established Member
Posts: 994
Registered: ‎07-23-2015
Kudos: 536
Solutions: 55

Re: UNMS API Service IPs


@UBNT-Radek wrote:

After that whenever a suspend of any customer is about to take place, UNMS will find which devices belong to that customer, what are their interfaces, what IP addresses are on those interfaces and then it will block those addresses in the internal network IP range.


What you explained above assumes that the service IP (the customer's IP their equipment utilizes) is on a piece of UNMS-managed equipment. In the case where the customer's data service is transparently bridged through a CPE, and the UNMS/CPE device only has a management IP for internal monitoring/management access, how is UNMS/UCRM made aware of the customer IP for suspension/authorization purposes? The Service IP would be on the customer's Linksys/Belkin/Cisco/whatever they want device and we want that flexibility/transparency by design. In the UNMS scenario that UBNT keeps touting, what correlates Service IPs to Service Devices (CPEs)? Think of the deployment similar to an ATT/Comcast DSL/cable modem in bridge mode. When ATT/Comcast puts their device in bridge mode, this allows the customer to receive a generic public data service through their modem (no NAT in the CPE or upstream managed ISP router).

 

We are doing this today in UCRM by populating "Service IPs" by hand. Today UCRM tracks service IPs and lets you grab/identify them with API calls. We can then take the service IP and service device MAC and programatically provision them in our DHCP server using option 82 in the CPE to tag the DHCP packets for authorization/identification purposes. I'd like to know how UNMS is supposed to retain this same level of functionality. To me it sounds like UBNT is making a very broad (and incorrect) assumption that all equipment receiving a Service IP is going to be within UNMS and attached to an interface on a Ubiquity device. Essentially this forces us as the ISP to make the customer use our CPE device if we want suspension to work properly (terrible).

Please don't forget to kudo helpful posts and mark accepted solutions accordingly!
jcm.me - Personal Site | Joyn.Tech - Consulting Site

Add Auto-Provisioning Support to UNMS
Add DAI/IP Source Guard to Edgeswitches
Ubiquiti Employee
Posts: 3,280
Registered: ‎09-08-2017
Kudos: 1244
Solutions: 245

Re: UNMS API Service IPs

@Joyn  Hello Josua. Thank you for a nice constructive discussion. I appreciate the effort you put into it and I will try to provide the same. So let's go through it point by point:
What you explained above assumes that the service IP (the customer's IP their equipment utilizes) is on a piece of UNMS-managed equipment.

I can partially agree here. The main point is that UNMS needs to know about the device. It doesn't have to be managed by UNMS. So if the device is not Ubiquiti, then it has to be present in UNMS as a 3rd party device with a correct IP address. This can be done either manually or through SNMP.
The Service IP would be on the customer's Linksys/Belkin/Cisco/whatever they want device and we want that flexibility/transparency by design.

I understand that flexibility is key here and UNMS can provide that by connecting the said device as a 3rd party one. The correct IP address of the device is critical for this to work properly. 

We are doing this today in UCRM by populating "Service IPs" by hand. Today UCRM tracks service IPs and lets you grab/identify them with API calls.

Those service IP will be transferred to 3rd party devices in UNMS. Those devices will be attached to a Client site which will be paired to a specific service(s) in UCRM.

I'd like to know how UNMS is supposed to retain this same level of functionality.

We will add API for easy download of a blocked IP and Service IP lists for any Client Site.

To me it sounds like UBNT is making a very broad (and incorrect) assumption that all equipment receiving a Service IP is going to be within UNMS and attached to an interface on a Ubiquity device.

It is true that in order to provide the advanced management services you need, UNMS will require to know about all devices within your network topology including 3rd party ones. So this is more of a requirement than assumption. Without having a complete topology map, UNMS will not be able to perform those functions. 

UBNT_Alternate_Logo.png
UNMS Support - If you want to report an issue please use this guide.

Check out our ever-evolving Help Center for answers to many common questions!

Established Member
Posts: 994
Registered: ‎07-23-2015
Kudos: 536
Solutions: 55

Re: UNMS API Service IPs

@UBNT-Radek allowing for 3rd party devices in UNMS is a good start. However, I do not care/want to monitor it or have it displayed i the frontend as a "down" device because it's not responding to ICMP or SNMP. In fact, with the device being customer-owed and managed I'd rather not be hitting their device with any kind of monitoring probes. Will this be possible?

 

For the 3rd party device IP, can this still be entered in UCRM by the CSR setting up the service? The CSR has no business in UNMS and shouldn't care about it. Plus, having to toggle between two UIs adds another pane of glass. CSRs are there to setup the account/billing and attatch device information to the acount. The reason I ask this is because I have been told in previous posts that the Service IP functionality was being removed from UCRM and handled "automatically" by UNMS. Obviously this can't work.

 

I also asked earlier if there was a way to differentiate Service IPs from Management IPs in UNMS. Clearly there has to be a way to do this, right? You wouldn't want to consider Management IPs for suspension purposes amongst other things. What's a "blocked IP"?

 

 

Thank you for taking the time to reply. I would love to receive any kind of early access to the new combined UNMS/UCRM to test it for functionality and have the opportunity to provide input to devs where there are gaps.

Please don't forget to kudo helpful posts and mark accepted solutions accordingly!
jcm.me - Personal Site | Joyn.Tech - Consulting Site

Add Auto-Provisioning Support to UNMS
Add DAI/IP Source Guard to Edgeswitches