[c-nsp] Forcing "point-to-point" PIM operation over Ethernet

[Keegan Holley]

Theses are the only traps for pim that I could find.

traps pim neighbor-change rp-mapping-change invalid-pim-message

Link up-down is disabled per interface with the following.

notproduction(config)#int g0/1
notproduction(config-if)#no snmp trap link-status

 You may not want to do this depending on how critical the devices are.  An
easier way would be to set thresholds in your NMS.  For example the device
has to go away for 30 minutes or so and if not the alarm is discarded.





On Thu, Oct 7, 2010 at 9:47 AM, John Neiberger <jneiberger at gmail.com> wrote:

> I was looking for that command!  lol  I think that's exactly what I
> want. The document I was looking at last night didn't have it, at
> least that I saw. I was wondering if there was a way to disable them.
> One potential hitch is that these aren't showing up in the NMS as
> neighbor changes. They are showing up as link up/down messages. That
> seems to indicate that the router is sending actual link status traps.
> I'll try that command and see if that fixes the problem.
>
> Thanks!
>
> On Wed, Oct 6, 2010 at 10:49 PM, Keegan Holley
> <keegan.holley at sungard.com> wrote:
> > "no snmp-server enable traps pim neighbor-change" should disable the
> > messages.  You could also suppress them in your NMS.
> >
> >
> > On Thu, Oct 7, 2010 at 12:19 AM, John Neiberger <jneiberger at gmail.com>
> > wrote:
> >>
> >> Ah, that explains it. I guess I need to brush up on PIM.  lol  That's
> >> scary, since I deal with it every day.  heh heh...  I guess I had OSPF
> >> on the brain.  I have a TAC case open with an NMS engineer right now.
> >> This is a really frustrating issue for us. It creates all sorts of
> >> false positives. We don't want to disable traps entirely because then
> >> we'll miss all the important ones, but it sure is a pain to deal with
> >> all the false alerts.
> >>
> >> My suspicion is that PIM DR elections usually only occur when a link
> >> changes status, so maybe that part of IOS assumes that if a DR change
> >> occurred, a link status change must have occurred, so send a trap! I'm
> >> hoping we'll figure out a solution.
> >>
> >> As always, thanks!
> >> John
> >>
> >> On Wed, Oct 6, 2010 at 10:14 PM, Benjamin Lovell <belovell at cisco.com>
> >> wrote:
> >> > Can't speak to the traps as I am not an NMS/SNMP guy but PIM does not
> >> > have a P2P network designation. DR is elected for all PIM neighbor
> >> > associations.
> >> >
> >> > -Ben
> >> >
> >> >
> >> > On Oct 6, 2010, at 5:42 PM, John Neiberger wrote:
> >> >
> >> >> We have a bunch of multicast devices connected to dozens of gigabit
> >> >> ethernet interfaces. Because it is Ethernet, a PIM DR is elected.
> >> >> These devices occasionally go in and out of service at an
> >> >> administrative level. When the device becomes administratively active
> >> >> again, a PIM DR election occurs again. For some reason, and Cisco TAC
> >> >> doesn't have an answer for this, this causes a link up/down trap for
> >> >> that interface to be sent to our NMS, which pages our on-call people.
> >> >> Very annoying. I'd like to find a way to have these Ethernet links
> >> >> treated as point-to-point links, but I see no such command.
> >> >>
> >> >> Can anyone here think of a way to do this? I'd really like to stop
> the
> >> >> whole DR election since we can't figure out how to stop the traps.
> >> >>
> >> >> Any thoughts?
> >> >> _______________________________________________
> >> >> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> >> >> https://puck.nether.net/mailman/listinfo/cisco-nsp
> >> >> archive at http://puck.nether.net/pipermail/cisco-nsp/
> >> >
> >> >
> >>
> >> _______________________________________________
> >> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> >> https://puck.nether.net/mailman/listinfo/cisco-nsp
> >> archive at http://puck.nether.net/pipermail/cisco-nsp/
> >>
> >>
> >
> >
>
>
>