Good News!! Maybe I should put an ER. James.
On Thu, May 26, 2011 at 4:52 PM, Pfleger, Jim <[email protected]> wrote: > Last summer we put in an ER for a similar problem with SBGW integrations. We > found that when an SBGW sends an alarm for address 10.10.10.1 from your > example, both the device with that management address and the device with > that interface address will get the SBGW alarm. We asked for an option to > restrict the SBGW search to the device addresses and not interface or other > child addresses. The ER was accepted last September, but not yet scheduled. > > > On 5/26/11 7:39 AM, "James Garthek" <[email protected]> wrote: > >> Hi, >> >> I have same problem and CA told me the same thing. >> >> I agree to CA that if Spectrum receives a trap, it should associate it >> with all devices that have that IP. But if that IP is in the IP >> Redundancy Excluded List, Spectrum shouldn't associate the trap with >> that device. >> >> In your case, IP 1.1.1.1 is an "illegal" address and your cluster >> shouldn't send traps with that address. But you can be using >> 10.10.10.1 and 10.10.10.2 as local point-to-point addresses between >> two routers and at the same time, you can have a local server with IP >> 10.10.10.1. When your server sends a trap with his own "legal" IP, >> Spectrum will associate the alarm with all both routers and server. I >> think this can be a very common situation. >> >> Regards. >> James. >> >> >> >> On Wed, May 25, 2011 at 9:51 PM, Olliver, Roderick >> <[email protected]> wrote: >>> Hi all, >>> >>> We have a bunch of devices that are set up with what should be an illegal >>> IP(1.1.1.1/1.1.1.2/etc) for communication within a cluster. Somehow while >>> it was being configured it seems one of these devices sent a trap with the >>> source address of 1.1.1.1 and the event/alarm was asserted to each of these >>> devices in Spectrum. >>> >>> No doubt the device shouldn't have sent it, but it sent a bunch of people >>> chasing a ghost on a lot of devices. Confirmed with CA that it is the >>> expected behaviour in Spectrum for a trap received from a duplicate IP >>> address. >>> >>> Wondering if anyone has thought of a workaround to this? >>> >>> Thanks, >>> ...rod >>> Roderick Olliver | Technical Systems Analyst | Distributed Network >>> Configuration Management | RBC Royal Bank >>> _______________________________________________________________________ >>> >>> This e-mail may be privileged and/or confidential, and the sender does not >>> waive >>> any related rights and obligations. Any distribution, use or copying of this >>> e-mail or the information >>> it contains by other than an intended recipient is unauthorized. >>> If you received this e-mail in error, please advise me (by return e-mail or >>> otherwise) immediately. >>> >>> Ce courriel peut contenir des renseignements protégés et confidentiels. >>> L¹expéditeur ne renonce pas aux droits et obligations qui s¹y rapportent. >>> Toute diffusion, utilisation ou copie de ce courriel ou des renseignements >>> qu¹il contient >>> par une personne autre que le destinataire désigné est interdite. >>> Si vous recevez ce courriel par erreur, veuillez m¹en aviser immédiatement, >>> par retour de courriel ou par un autre moyen. >>> >>> --To unsubscribe from spectrum, send email to [email protected] with the >>> body: unsubscribe spectrum [email protected] >> >> --- >> To unsubscribe from spectrum, send email to [email protected] with the body: >> unsubscribe spectrum [email protected] > > --- To unsubscribe from spectrum, send email to [email protected] with the body: unsubscribe spectrum [email protected]
