All things related to multicast

[Toerless Eckert <>]

On Tue, Dec 04, 2001 at 05:35:36PM -0500, Alan Crosswell wrote:
> I was trying to debug why one of my routers wasn't able to learn of its
> pim bsr-router which is advertised with a /32.  Finally I tried "show ip rpf
> 128.59.0.15" and got back a bogus route via an incorrect interface.  The
> RPF was learned via DVMRP.  So, I tried filtering dvmrp since it appears
> there's no way to globally disable it.  I added the following subinterface
> command:
> 
>  ip dvmrp accept-filter 99 neighbor-list 2
> 
> mudd-edge-1#sho access-lists 99
> Standard IP access list 99 (Compiled)
>     permit any log
> mudd-edge-1#sho access-lists 2
> Standard IP access list 2 (Compiled)
>     deny   any (4 matches)
> 
> The wierd thing is since I've added these filters, no more dvmrp routes have
> come in so I can't find who originated them.  Access-list 99 hasn't logged
> once since then.
> 
> Anybody seen this behavior?  Is this really the only way to turn off dvmrp
> poluting my routing table?

You should still be able to see which DVMRP router sent
you messages by enabling "debug ip dvmrp" - the filtering is done
after logging the debugs.

Yes, what you configured is the most generic solution. There
is no other global command to disable DVMRP interoperability simply
on the control-plane - of course you can filter out IGMP/DVMRP messages
via packet filters, but that's typically not advantageous.

You won't see matches against access-list 99 because it won't
be evaluated - the packet will already be denied by matching
against list 2.

You can try to add the "log" option to access-list 2 to get a syslog
for every match against access-list 2. Probably need to configure the
logging levels appropriately to see it on the destination where you want
it (console, monitor, syslog, etc..)

Cheers
        Toerless