CI Relationships - Infrastructure - Server to Switch , Router and Firewall

[Santosh Kumar8]

Hello Everyone, 

I am setting up discovery and started running discovery schedules for some subsets. Discovery results are good however i am not very satisfy with Ci relationships. Between applications (DB instances, Web Services) to Server relationship is great but I was also looking forward for Server to network relationships which i dont see very encouraging when i run some discovery scheduled. However these relationships are something every technical team ask for when do change on network devices. 

Have anyone got this right? Is there any best practice to follow while setting up discovery to get all infrastructure Ci relationship in place. Please do share

Also if someone cat comment why we dont have a pattern for Firewall in NY release ? is there any specific reason. We can build a pattern or also use Probe and Sensor but wanted to understand is there any specific reason wehy OOTB pattern is not added for Firewall?

[Ashutosh Munot1]

Hi,

I have this relationship properly established right from IP routers, IP Switches to Servers, VM instance, ESX host and Applications. We initially faced challenges where we were not able to discover all IP switch and Router details like forwarding tale, Spanning table due to credentials issue. 

Thanks,
Ashutosh

[Santosh Kumar8]

Thanks for reply Ashutosh. I see its getting added however for many devices its missing. Any particular reason ..i have firewall port open, snmp community string configured at our end, mid server hosts added in ACLs at devices..what could be missing. If relationship established only at time of CI reation or it will happen as and when details on switching and other details gets added  

[DuaneNMore]

One of the things we found with server to network is that sometimes there is overlap in non-routable addresses which the server has and that which has been configured into the router switch. For example, we have servers which have as an interface lo0 with ip "127.0.0.1"

Then there are routers which have Exit Interface Routing rules (dscy_route_interface) for destination address 127.0.0.0/8. 

So now what happens is when DeviceL3Mapping script include gets called (and I forget which sensor does this), 

 it will take 127.0.0.1 find it in the range of the 120 routers which have an Exit Interface Destination of 127.0.0.0/8 and then build an IP Connection::IP Connection relationship. One potential hack would be to add !dest_ip_network.startsWith("127.0.0.") down around line 110 in the noted script include