Re: IP Devices and CMDB 2.1 Classes
That is exactly what I wanted to know, Peter! Thanks, that is great. Of course probably they won't want to do this, but then again, it won't be for lack of telling them the right thing to do! Cheers, Louise --- On Fri, 3/20/09, P Romain ARSlist wrote: From: P Romain ARSlist Subject: Re: IP Devices and CMDB 2.1 Classes To: arslist@ARSLIST.ORG Date: Friday, March 20, 2009, 2:32 PM ** BMC FD/TD Discovery creates an IP Endpoint class for the IP and a LAN Endpoint CI for the MAC address and relates these together (dependency where the MAC is the parent if I remember right). It relates these two CIs to the computer system using the hosted access point class. If you want to pull the best practice card then I’d go with the above. From: Action Request System discussion list(ARSList) [mailto: arslist@ARSLIST.ORG ] On Behalf Of Louise Van Hine Sent: 20 March 2009 17:49 To: arslist@ARSLIST.ORG Subject: Re: IP Devices and CMDB 2.1 Classes ** So when the IP addresses are put into the LanEndpoint, I make a relationship to the ComputerSystem records? None of this is discovery stuff, it's all going to be imported data for now. Thanks everyone for your input! I'll see what the customer wants to do. This is only a proof of concept system in any case, so we can try different things to see what works. --- On Fri, 3/20/09, Guillaume Rheault wrote: From: Guillaume Rheault Subject: Re: IP Devices and CMDB 2.1 Classes To: arslist@ARSLIST.ORG Date: Friday, March 20, 2009, 11:14 AM ** You can also use the LAN EndPoint class. I actually prefer the LAN Endpoint class instead of the IP EndPoint class for this situation, since the LAN EndPoint has the MAC Address; you can use the Group Address field for the subnet mask; another useful field is the Alias Addresses, in which you can store multiple virtual IPs. -Guillaume -Original Message- From: Action Request System discussion list(ARSList) on behalf of Lyle Taylor Sent: Thu 03/19/09 6:40 PM To: arslist@ARSLIST.ORG Subject: Re: IP Devices and CMDB 2.1 Classes I believe the IP Endpoint class is intended to document things like IP addresses. Adding an attribute for IP address is probably not a good solution, unless you know that the device will only have one (or some maximum number of) IP address(es). As noted in someone else's reply, there is a field for domain name on the computer system class already. Lyle From: Action Request System discussion list(ARSList) [mailto:arsl...@arslist.org] On Behalf Of Louise Van Hine Sent: Thursday, March 19, 2009 4:27 PM To: arslist@ARSLIST.ORG Subject: IP Devices and CMDB 2.1 Classes ** I wanted to know from those who have done some mapping of network hardware and devices, how you map various and sundry IP-addressed network devices in the CMDB? My task right now is to try to use what we have without adding any classes or attributes, (at least for now), and it looks like most everything can be shoved into the ComputerSystem class, since that is where the mapping document says to put bridges, firewalls, routers and the like, but I am interested to know how CMDB administrators have handled attributes like domain name and primary and secondary IP address when there is no business need to describe or to discover connectivity collections, endpoints, lans, etc. Do you just add attributes, or what? __Platinum Sponsor: RMI Solutions ARSlist: "Where the Answers Are" html___ NOTICE: This email message is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message. ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Platinum Sponsor: RMI Solutions ARSlist: "Where the Answers Are" __Platinum Sponsor: RMI Solutions ARSlist: "Where the Answers Are" html___ __Platinum Sponsor: RMI Solutions ARSlist: "Where the Answers Are" html_Platinum Sponsor: RMI Solutions ARSlist: "Where the Answers Are" html___ ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Platinum Sponsor: RMI Solutions ARSlist: "Where the Answers Are"
Re: IP Devices and CMDB 2.1 Classes
That's right, you got to create a relationship -Guillaume -Original Message- From: Action Request System discussion list(ARSList) on behalf of Louise Van Hine Sent: Fri 03/20/09 1:49 PM To: arslist@ARSLIST.ORG Subject: Re: IP Devices and CMDB 2.1 Classes So when the IP addresses are put into the LanEndpoint, I make a relationship to the ComputerSystem records? None of this is discovery stuff, it's all going to be imported data for now. Thanks everyone for your input! I'll see what the customer wants to do. This is only a proof of concept system in any case, so we can try different things to see what works. --- On Fri, 3/20/09, Guillaume Rheault wrote: From: Guillaume Rheault Subject: Re: IP Devices and CMDB 2.1 Classes To: arslist@ARSLIST.ORG Date: Friday, March 20, 2009, 11:14 AM ** You can also use the LAN EndPoint class. I actually prefer the LAN Endpoint class instead of the IP EndPoint class for this situation, since the LAN EndPoint has the MAC Address; you can use the Group Address field for the subnet mask; another useful field is the Alias Addresses, in which you can store multiple virtual IPs. -Guillaume -Original Message- From: Action Request System discussion list(ARSList) on behalf of Lyle Taylor Sent: Thu 03/19/09 6:40 PM To: arslist@ARSLIST.ORG Subject: Re: IP Devices and CMDB 2.1 Classes I believe the IP Endpoint class is intended to document things like IP addresses. Adding an attribute for IP address is probably not a good solution, unless you know that the device will only have one (or some maximum number of) IP address(es). As noted in someone else's reply, there is a field for domain name on the computer system class already. Lyle From: Action Request System discussion list(ARSList) [mailto:arsl...@arslist.org] On Behalf Of Louise Van Hine Sent: Thursday, March 19, 2009 4:27 PM To: arslist@ARSLIST.ORG Subject: IP Devices and CMDB 2.1 Classes ** I wanted to know from those who have done some mapping of network hardware and devices, how you map various and sundry IP-addressed network devices in the CMDB? My task right now is to try to use what we have without adding any classes or attributes, (at least for now), and it looks like most everything can be shoved into the ComputerSystem class, since that is where the mapping document says to put bridges, firewalls, routers and the like, but I am interested to know how CMDB administrators have handled attributes like domain name and primary and secondary IP address when there is no business need to describe or to discover connectivity collections, endpoints, lans, etc. Do you just add attributes, or what? __Platinum Sponsor: RMI Solutions ARSlist: "Where the Answers Are" html___ NOTICE: This email message is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message. ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Platinum Sponsor: RMI Solutions ARSlist: "Where the Answers Are" __Platinum Sponsor: RMI Solutions ARSlist: "Where the Answers Are" html___ ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Platinum Sponsor: RMI Solutions ARSlist: "Where the Answers Are" ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Platinum Sponsor: RMI Solutions ARSlist: "Where the Answers Are"
Re: IP Devices and CMDB 2.1 Classes
BMC FD/TD Discovery creates an IP Endpoint class for the IP and a LAN Endpoint CI for the MAC address and relates these together (dependency where the MAC is the parent if I remember right). It relates these two CIs to the computer system using the hosted access point class. If you want to pull the best practice card then I'd go with the above. _ From: Action Request System discussion list(ARSList) [mailto:arsl...@arslist.org] On Behalf Of Louise Van Hine Sent: 20 March 2009 17:49 To: arslist@ARSLIST.ORG Subject: Re: IP Devices and CMDB 2.1 Classes ** So when the IP addresses are put into the LanEndpoint, I make a relationship to the ComputerSystem records? None of this is discovery stuff, it's all going to be imported data for now. Thanks everyone for your input! I'll see what the customer wants to do. This is only a proof of concept system in any case, so we can try different things to see what works. --- On Fri, 3/20/09, Guillaume Rheault wrote: From: Guillaume Rheault Subject: Re: IP Devices and CMDB 2.1 Classes To: arslist@ARSLIST.ORG Date: Friday, March 20, 2009, 11:14 AM ** You can also use the LAN EndPoint class. I actually prefer the LAN Endpoint class instead of the IP EndPoint class for this situation, since the LAN EndPoint has the MAC Address; you can use the Group Address field for the subnet mask; another useful field is the Alias Addresses, in which you can store multiple virtual IPs. -Guillaume -Original Message- From: Action Request System discussion list(ARSList) on behalf of Lyle Taylor Sent: Thu 03/19/09 6:40 PM To: arslist@ARSLIST.ORG Subject: Re: IP Devices and CMDB 2.1 Classes I believe the IP Endpoint class is intended to document things like IP addresses. Adding an attribute for IP address is probably not a good solution, unless you know that the device will only have one (or some maximum number of) IP address(es). As noted in someone else's reply, there is a field for domain name on the computer system class already. Lyle From: Action Request System discussion list(ARSList) [mailto:arsl...@arslist.org] On Behalf Of Louise Van Hine Sent: Thursday, March 19, 2009 4:27 PM To: arslist@ARSLIST.ORG Subject: IP Devices and CMDB 2.1 Classes ** I wanted to know from those who have done some mapping of network hardware and devices, how you map various and sundry IP-addressed network devices in the CMDB? My task right now is to try to use what we have without adding any classes or attributes, (at least for now), and it looks like most everything can be shoved into the ComputerSystem class, since that is where the mapping document says to put bridges, firewalls, routers and the like, but I am interested to know how CMDB administrators have handled attributes like domain name and primary and secondary IP address when there is no business need to describe or to discover connectivity collections, endpoints, lans, etc. Do you just add attributes, or what? __Platinum Sponsor: RMI Solutions ARSlist: "Where the Answers Are" html___ NOTICE: This email message is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message. ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Platinum Sponsor: RMI Solutions ARSlist: "Where the Answers Are" __Platinum Sponsor: RMI Solutions ARSlist: "Where the Answers Are" html___ __Platinum Sponsor: RMI Solutions ARSlist: "Where the Answers Are" html___ ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Platinum Sponsor: RMI Solutions ARSlist: "Where the Answers Are"
Re: IP Devices and CMDB 2.1 Classes
So when the IP addresses are put into the LanEndpoint, I make a relationship to the ComputerSystem records? None of this is discovery stuff, it's all going to be imported data for now. Thanks everyone for your input! I'll see what the customer wants to do. This is only a proof of concept system in any case, so we can try different things to see what works. --- On Fri, 3/20/09, Guillaume Rheault wrote: From: Guillaume Rheault Subject: Re: IP Devices and CMDB 2.1 Classes To: arslist@ARSLIST.ORG Date: Friday, March 20, 2009, 11:14 AM ** You can also use the LAN EndPoint class. I actually prefer the LAN Endpoint class instead of the IP EndPoint class for this situation, since the LAN EndPoint has the MAC Address; you can use the Group Address field for the subnet mask; another useful field is the Alias Addresses, in which you can store multiple virtual IPs. -Guillaume -Original Message- From: Action Request System discussion list(ARSList) on behalf of Lyle Taylor Sent: Thu 03/19/09 6:40 PM To: arslist@ARSLIST.ORG Subject: Re: IP Devices and CMDB 2.1 Classes I believe the IP Endpoint class is intended to document things like IP addresses. Adding an attribute for IP address is probably not a good solution, unless you know that the device will only have one (or some maximum number of) IP address(es). As noted in someone else's reply, there is a field for domain name on the computer system class already. Lyle From: Action Request System discussion list(ARSList) [mailto:arsl...@arslist.org] On Behalf Of Louise Van Hine Sent: Thursday, March 19, 2009 4:27 PM To: arslist@ARSLIST.ORG Subject: IP Devices and CMDB 2.1 Classes ** I wanted to know from those who have done some mapping of network hardware and devices, how you map various and sundry IP-addressed network devices in the CMDB? My task right now is to try to use what we have without adding any classes or attributes, (at least for now), and it looks like most everything can be shoved into the ComputerSystem class, since that is where the mapping document says to put bridges, firewalls, routers and the like, but I am interested to know how CMDB administrators have handled attributes like domain name and primary and secondary IP address when there is no business need to describe or to discover connectivity collections, endpoints, lans, etc. Do you just add attributes, or what? __Platinum Sponsor: RMI Solutions ARSlist: "Where the Answers Are" html___ NOTICE: This email message is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message. ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Platinum Sponsor: RMI Solutions ARSlist: "Where the Answers Are" __Platinum Sponsor: RMI Solutions ARSlist: "Where the Answers Are" html___ ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Platinum Sponsor: RMI Solutions ARSlist: "Where the Answers Are"
Re: IP Devices and CMDB 2.1 Classes
You can also use the LAN EndPoint class. I actually prefer the LAN Endpoint class instead of the IP EndPoint class for this situation, since the LAN EndPoint has the MAC Address; you can use the Group Address field for the subnet mask; another useful field is the Alias Addresses, in which you can store multiple virtual IPs. -Guillaume -Original Message- From: Action Request System discussion list(ARSList) on behalf of Lyle Taylor Sent: Thu 03/19/09 6:40 PM To: arslist@ARSLIST.ORG Subject: Re: IP Devices and CMDB 2.1 Classes I believe the IP Endpoint class is intended to document things like IP addresses. Adding an attribute for IP address is probably not a good solution, unless you know that the device will only have one (or some maximum number of) IP address(es). As noted in someone else's reply, there is a field for domain name on the computer system class already. Lyle From: Action Request System discussion list(ARSList) [mailto:arsl...@arslist.org] On Behalf Of Louise Van Hine Sent: Thursday, March 19, 2009 4:27 PM To: arslist@ARSLIST.ORG Subject: IP Devices and CMDB 2.1 Classes ** I wanted to know from those who have done some mapping of network hardware and devices, how you map various and sundry IP-addressed network devices in the CMDB? My task right now is to try to use what we have without adding any classes or attributes, (at least for now), and it looks like most everything can be shoved into the ComputerSystem class, since that is where the mapping document says to put bridges, firewalls, routers and the like, but I am interested to know how CMDB administrators have handled attributes like domain name and primary and secondary IP address when there is no business need to describe or to discover connectivity collections, endpoints, lans, etc. Do you just add attributes, or what? __Platinum Sponsor: RMI Solutions ARSlist: "Where the Answers Are" html___ NOTICE: This email message is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message. ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Platinum Sponsor: RMI Solutions ARSlist: "Where the Answers Are" ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Platinum Sponsor: RMI Solutions ARSlist: "Where the Answers Are"
Re: IP Devices and CMDB 2.1 Classes
I believe the IP Endpoint class is intended to document things like IP addresses. Adding an attribute for IP address is probably not a good solution, unless you know that the device will only have one (or some maximum number of) IP address(es). As noted in someone else's reply, there is a field for domain name on the computer system class already. Lyle From: Action Request System discussion list(ARSList) [mailto:arsl...@arslist.org] On Behalf Of Louise Van Hine Sent: Thursday, March 19, 2009 4:27 PM To: arslist@ARSLIST.ORG Subject: IP Devices and CMDB 2.1 Classes ** I wanted to know from those who have done some mapping of network hardware and devices, how you map various and sundry IP-addressed network devices in the CMDB? My task right now is to try to use what we have without adding any classes or attributes, (at least for now), and it looks like most everything can be shoved into the ComputerSystem class, since that is where the mapping document says to put bridges, firewalls, routers and the like, but I am interested to know how CMDB administrators have handled attributes like domain name and primary and secondary IP address when there is no business need to describe or to discover connectivity collections, endpoints, lans, etc. Do you just add attributes, or what? __Platinum Sponsor: RMI Solutions ARSlist: "Where the Answers Are" html___ NOTICE: This email message is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message. ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Platinum Sponsor: RMI Solutions ARSlist: "Where the Answers Are"
Re: IP Devices and CMDB 2.1 Classes
Hi Louise, At one customer I added an IP attribute to computer system because they also weren't interested in doing anything with this data except store it. At other customers we've used the IP Endpoint class primarily because that's where BMC Discovery puts this data. Different IPs were differentiated by Tier 3. So, IMHO either option is OK. Domain name is an attribute on computer system. Cheers Peter _ From: Action Request System discussion list(ARSList) [mailto:arsl...@arslist.org] On Behalf Of Louise Van Hine Sent: 19 March 2009 17:04 To: arslist@ARSLIST.ORG Subject: IP Devices and CMDB 2.1 Classes ** I wanted to know from those who have done some mapping of network hardware and devices, how you map various and sundry IP-addressed network devices in the CMDB? My task right now is to try to use what we have without adding any classes or attributes, (at least for now), and it looks like most everything can be shoved into the ComputerSystem class, since that is where the mapping document says to put bridges, firewalls, routers and the like, but I am interested to know how CMDB administrators have handled attributes like domain name and primary and secondary IP address when there is no business need to describe or to discover connectivity collections, endpoints, lans, etc. Do you just add attributes, or what? __Platinum Sponsor: RMI Solutions ARSlist: "Where the Answers Are" html___ ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Platinum Sponsor: RMI Solutions ARSlist: "Where the Answers Are"
