without knowing the subnet masks you are using here it's hard to say where your issue is.
generally if the application server cannot connect to the agent directly you need to stand up a SOCKS proxy that straddles a network that the appserver can connect to and a network that can connect to your targets.
i would start looking here:
The Agents are not reporting back into the App Server the proxy has direct access to the agent but when you try and add from the console it simply states agent is not responding, I thought this was a connection instigated from the Appserver to the agent.
Any logs I can review to try and understand where it is failing?
Some of the tests I'd try are:
- Telnet from Appserver to Proxy on proxy port
- Telnet from Proxy to RSCD agent on RSCD agent port
If both of these are successful then you know connectivity is correct.
Check Proxy and Repeater Routing rules in BSA under Infrastructure Management.
If all this appears correct I'd snoop the traffic on all 3 parts involved appserver,proxy and RSCD agent to ensure traffic is going where you expect.
How are the network routing rules setup ? how do you tell bladelogic what targets are behind a proxy ?
THis is the part that is confusing me, If I add a server on the same subnet of the Proxy work fine, if I try and ad a server from a different IP range which means routing through on of the three nics I get Agent not responding?
I am able to resolve the name of the server from the proxy via DNS, I can ping the server and I can telnet over port 4750 to the device in question, but it will not register within Bladelogic.
I have not setup any specific rules on the proxy as it all looks ok which is the weird part?
when you say you can ping and telnet to 4750 on the server - to what nic/subnet and from where ?
when i say network routing rules i mean in the infrastructure manager interface in bsa - how does bsa know these servers are behind which proxy ?
The proxies are working and reporting correctly, as I have added servers on the same NIC subnet, as the proxies, and they work through to the Console, it when I try and add a server from the 3rd nic it never connects?
On further testing I am not able to get a response on 4750 from the Customer device which is off Nic3, so it looks like the BL is not listening on the 3rd Nic but is on the 1st, any ideas how to tell BL to use all 3 nics?
if you run a 'netstat -an | grep 4750" on the system w/ the agent, where do you see port 4750 listening ?
can you run a 'netstat -nr' on the system w/ the agent and paste that in, and tell which ip represents the 3rd nic?
I have run some tests and wanted to show the results:
I have two Systems Running Linux these are:
Linux Proxy which is as follows:
tcp 0 0 0.0.0.0:4750 0.0.0.0:* LISTEN
tcp 0 0 172.23.129.76:4750 184.108.40.206:56903 ESTABLISHED
Linux Repeater which is as follows:
tcp 0 0 0.0.0.0:4750 0.0.0.0:* LISTEN
tcp 0 0 172.23.244.203:4750 172.23.236.40:60626 ESTABLISHED
So the 172.23.129.x is the NIC1 which is routed back to our core infrastructure
And the 172.23.244.x is NIC3 which is routed to the Customer devices.
This is from the Linux Repeater:
And this is from the Linux Proxy:
I can get an agent that resides on the same subnet 172.23.129.x to work in Bladelogic, and this can communicate to the repeater over 4750.
But if I try on the server on the 172.23.226.x address space it never connects to 4750.
Is this everything you wanted?
i wanted the netstat output from the actual target server, not the repeater or proxy.
So on the windows target system you seem to have a single nic w/ the ip of 172.23.226.209 / 255.255.255.224. are there any other nics on this system ?
the socks proxy system would seem to go through the gateway of 172.23.244.129 to get to the 172.23.226.192/27 subnet - is that correct? can you confirm that w/ a traceroute?
can you then run a traceroute from the windows target to 172.23.244.203 (the ip of the socks proxy) ?
I can confirm that the target server only has a single nic, and the SOCKS proxy is routing through the 172.23.244.129 interface directly onto the target server
And a tracert from the target device routes via 172.23.226.193 then onto the Proxy.