ISP/Telco provider setup in CMDB?

[Ted N1]

Hi,

I'm setting up an ISP/Telco provider in their CMDB. We want to represent all involved equipment from Customer Service (Sold Product/Service Offering) to the ISPs core network in the CMDB.

Equipment involved:

- Access Points (cmdb_ci_wap_network)

- LAN Switches (cmdb_ci_ip_switch)

- WAN Switches (cmdb_ci_ip_switch)

- Switch Ports (dscy_switchport?)

- Routers (cmdb_ci_ip_router)

- Router Interfaces (dscy_router_interface?)

- Patch cables

- Fibre cables

Then there's of course variants of switches and routers for the WAN that I can represent in the same tables.

My questions relates to:

1. The tables prefixed dscy i presume come from Discovery? Why not the same naming convention as other tables?

2. Patch cables, how do you represent these in your CMDB? Relationships between ports? Custom CI Class?

3. Fiber cables, how do you represent these in your CMDB? Assets? Custom CI Class?

Best regards

Ted

[CasperJT]

Hi Ted,

I definitely do not have the answers to all your questions.

1. It looks like this is simply because the table is intended for discovery. There are other port tables, that you can consider using instead or verify with ServiceNow, whether there are any downsides to using other tools than ServiceNow to populate it. The Application Service table is also called '_discovered'. I guess it is just ServiceNow's way of telling us to make sure to automate these classes.
https://community.servicenow.com/community?id=community_question&sys_id=7aecd27adb28c050feb1a851ca96...

For 2 and 3, maybe the plugin CMDB Telecom Category (com.snc.cmdb.telecom.category) holds some of the classes you are missing, otherwise, the CMDB is intended to be extended with new classes (hence it is excluded from the table extension restrictions in the license setup).

Hope this helps.

//Casper

[Alec Hanson]

1. I believe the '_discovered' on the Application Services, was more as it was an existing class that was 're-purposed' to cover a wider scope, I guess so that there was backward compatibity it was decided not rename the table name which might be what has happeed on the 'dscy_' tables.

2. I guess with the Cables question you might need to way up what the business outcome is of tracking it as a CI versus as a relationship. i.e. Is the cable itself going to be treated as a CI, tracked controlled, changed and put up that scrutiny, or is just the connection that is of concern?

That I believe will determine if you need a relationship or class. As for whether they are Assets depends on whether the org treats them as such - i.e. have a cost associated that they need to monitor and control.

[Ted N1]

OK.

My intent with the cabling is that it's important to keep record of exactly which ports the cables connect to each other since port configuration is unique by customer delivery. Hence I'm leaning towards adding a table for patch cables and fiber cables used to connect customer end-points to distribution/core network equipment.

Fiber cables I'm seeing from the same perspective as switches and routers, they consist of a number of 'ports' (part of cable or even wave-length/color used). As such it's interesting to understand how much of the fiber is being used when it's part of a distribution/core network.

BR Ted

[Alec Hanson]

OK does sound like you are going down to detail that would need new Classes