Highlighted
Established Member
Posts: 1,021
Registered: ‎07-23-2015
Kudos: 550
Solutions: 56

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,430
Registered: ‎09-08-2017
Kudos: 1314
Solutions: 257

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: 1,021
Registered: ‎07-23-2015
Kudos: 550
Solutions: 56

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,430
Registered: ‎09-08-2017
Kudos: 1314
Solutions: 257

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: 1,021
Registered: ‎07-23-2015
Kudos: 550
Solutions: 56

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
Ubiquiti Employee
Posts: 3,430
Registered: ‎09-08-2017
Kudos: 1314
Solutions: 257

Re: UNMS API Service IPs

@Joyn  Hello Joshua. Thank you for a great reply. I feel we are having a really useful and productive discussion here. Let me please again pick specific points and give info related to them.

"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?

Yes, you can disable monitoring for those devices and they will always retain their Active status, it will not send alerts when offline etc... It will be there just to complete your topology view.

 

For the 3rd party device IP, can this still be entered in UCRM by the CSR setting up the service?

Just to be clear about the terminology. I am assuming CSR means 'customer' and I will be answering your points according to that. 

 

The CSR has no business in UNMS and shouldn't care about it.

Yes, we agree with that. Here is the chain of service as we see it:
Client/Customer(CRM) -> Client site (NMS) -> Device (NMS) -> Interface (NMS) -> IP (NMS). 
I am using CRM as Customer-relationship management and NMS as Network management system.

Plus, having to toggle between two UIs adds another pane of glass.
Right now we are working hard to integrate UCRM and UNMS into one seamless application. Very soon there will be a 'Network' section in UNMS which will show data about customers and allow you to quickly transfer to the CRM section for more personal info. In the same spirit, there will be some network management info in the CRM section, for example, NetFlow data for a specific customer despite that CRM module do not directly know which device/IP that customer owns. 

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.

Maybe we just did not understand each other at this point. Let me please describe the situation and hopefully, that would clear things. I will be using some terminology described in this article. In the CRM section of the future integrated UNMS, there will be a database with no client IP addresses. This is done because network issues are going to be completely handled by the Network part of UNMS. This Network module will be able to return a client IP for a specific CRM service. UNMS is able to track the connection between that service and the Network Client site. Then follow the connection to a device, its interface, and its IP address. There will be a range of clients' IPs so that UNMS knows the IP belongs to the internal network even when the IP changes.

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?

UNMS knows IP addresses of all interfaces in the network and it doesn't need to distinguish between service/management IP addresses for the new implementation of QoS and Suspend on EdgeRouter. Even when a device is, for example, suspended it can still communicate with UNMS and therefore it is still manageable. This is possible because the communication always comes from the device to the UNMS IP address which is always automatically allowed on the gateway.

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.

You are most welcome. I will make sure you have a chance to test the integrated version early. 

 

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: 1,021
Registered: ‎07-23-2015
Kudos: 550
Solutions: 56

Re: UNMS API Service IPs

[ Edited ]

@UBNT-Radek

“CSR” stands for customer service representative. These are non-technical receptionists, front counter people, billing folks. They simply set up accounts in UCRM and attach CPE equipment to them.

You mentioned enabling QoS on the Edgerouter. We have no intentions of doing this and quite frankly migrated away from this provisioning mentality because it put too much strain and config clutter in to our core routers. It makes more sense for us to handle QoS at the edge distributed in each customer’s bridge mode CPE station rather than piled centrally into one device.

This being said with the CPE station needing to have QoS enabled is why it’s important to track management IPs, Service IPs, and track customer CPE equipment mapped to accounts. It’s also needed for DHCP Option 82 correlation/authorization on to the network.

Your chain of service seems to be inherently flawed to work with a network where the “Device (NMS)” is a bridge mode CPE. See below:

Client/Customer(CRM) -> Client site (NMS) -> Device (NMS) -> Interface (NMS) -> IP (NMS)

I’m assuming that “IP (NMS)” is analogous to “Service IP” in UCRM today. How do you correlate a public “IP (NMS)” to a CPE and the CPE’s interface if the CPE is in bridge mode and only has a management IP?

 

When the CPE is bridged, how do you discover/track it to a particular service to enforce the proper QoS?

 

When the CPE is bridged, how do you track/correlate Service IPs (for suspension) to customers’ services?

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