Configuration Replication
Hi everyone,
SunMC Version: 3.5 (latest patch level) - both on server and the agent.
I have a bunch of clustered servers, each with 2 public interfaces (using IPMP). The problem seems to be
that when updating the configuration, the agent for some reason keeps responding on "the other" interface
than it is specified in the object definition in SunMC, and it obviously gets denied. Is there a way to
circumvent this (short of voodoo-magic with routes, which I'm not even sure it works) in SunMC? Is there a
way of specifying a bunch of addresses/names for a client that are considered legal to receive answers
from and, at the end of the day, aliases of the same hardware platform?
I'd be forever in debt if anyone could give me a hand with this.
Thanks
Bogdan.
[835 byte] By [
In0rog] at [2008-2-4]
Hi everyone,
Don't you just hate it when it happens? 5 minutes after you post a question - you find the answer! Grrr!
Anyways, looks to me that one certain way to make sure the communication happens through the same
interface is to add a static route on the server where the agent runs, just like in the example below:
route -v add -host <IP for the SunMC swerver> <default gateway> -ifp bge0
That fixes it all - and it works like a charm.
Cheers,
Bogdan.
Actually, I take that back, it was just a fluke. It just happened that the agent selected the correct interface to go through and it all went fine.
It seems that no matter what route I put in, it still choses to go through whatever interface it pleases.
I have also tried to bind the agent to a specific interface (/var/opt/SUNWsymon/cfg/domain-config.x ) but that doesn't seem to have the expected efect - the daemons are still binding to *all* interfaces available on the system.
Any indeeas?
Bogdan
> It seems that no matter what route I put in, it still> choses to go through whatever interface it pleases.As a long time SunMC fan, I'd love to see setup ask which interface to bind to. And offer a command to change it.
> > It seems that no matter what route I put in, it
> still
> > choses to go through whatever interface it pleases.
>
> As a long time SunMC fan, I'd love to see setup ask
> which interface to bind to. And offer a command to
> change it.
Yes, you'd think someone would've thought of it before. Obviously not.
After a bit of tinkering with the agent, it seems that it runs a Bunch-O-Scripts(TM) that call binaries from
/opt/SUNWsymon/base/bin/sparc-sun-solaris2.9/ directory. Those binaries in turn bind to whatever
interface comes in handy. If push come to shove, I'll be even contemplating writing my own es-mcp-get
program that'll do The-Right-Thing(TM) from the beginning.
I have put a call with Sun about this bug, but so far they're "investigating" it.
cheers,
Ino!~
No Solution, but a workaround.
Problem are IP/MP at the Server Networkdevices.
Use the
/opt/SUNWsymon/sbin/esmultiip -l
comand to display all Server Networkdevices, SunMC-Server can use to reach the Clients.
Use nslookup from the clients to show all reachable
devices at the Server.
Then use
/opt/SUNWsymon/sbin/esmultiip -d
on the Server to deleet all devices from the SunMC-Server application, which the Clients can not Identify.
Then you will have no longer IP/MP, but the SunMC
Administration will work propper.
SUN solution will come end of 2005, SunMC 3.6.
(hopfully)
Hi all,
The Agent uses the hostname/IP in the agent->agentServer part of the domain-config.x file to decide what IP to use for security purposes. Change the agentServer entry to the IP you want it to use and rerun setup (or base-usm-seed.sh). Make sure the icon you created in the Console for that system uses the same IP
You shouldn't have to alter any routes. Regardless of the interfaces an Agent binds to it only honors SNMPv2usec security with packets sent to the agentServer IP.
Sounds like in your case you want to use the Virtual IP on both sides and just let Solaris "do the right thing" if either of the physical interfaces goes down.
If you want to lock down the SunMC Server to only listen to Agents coming from a single interface, run esmultiip
Regards,
Mike.Kirk@HalcyonInc.com
