From: P729 (p729@cox.net)
Date: Thu Dec 19 2002 - 03:20:56 GMT-3
Mmmm...you may be overcomplicating the issue. A protocol is a set of
agreed-upon rules to follow (well illustrated in the RFCs). These rules are
typically implemented as state machine processes in a router. I believe
'passive-interface' alters the state machine so that the protocol packets
are suppressed. Likewise, specifying a 'neighbor' also alters the state
machine--in a way that 'passive-interface' is overridden or has no effect
(it makes sense when you think about it--why would you explicitly specify a
neighbor to send updates to, only to suppress them?).
Regards,
Mas Kato
https://ecardfile.com/id/mkato
----- Original Message -----
From: "tan" <tan@dia.janis.or.jp>
To: "'P729'" <p729@cox.net>; "'Ccielab (E-mail)'" <ccielab@groupstudy.com>
Sent: Wednesday, December 18, 2002 8:42 PM
Subject: RE: internals of passive interface
>
> In any event, the net result is disabling the transmission of protocol
> packets on the specified interface(s).
So you are saying across both DV and LS protocols, the blocking mechanism is
based on protocol identification in outgoing header, not a destination layer
3 address or some combination? Are there any subtleties that show otherwise?
How about passive and neighbor together. Unicasts will still go out with
protocol bit being overlooked. Shouldn't some sort of all_hosts or
all_subnet_hosts variable be included in the drop decision?
Your knowledge of the specific
> protocol behavior would lead you to deduce the net effect.
Yes, that is what I am after. As it is now, I feel I still need to take time
and check results with debug. This may go away as I do more and more
scenarios though...
.
This archive was generated by hypermail 2.1.4 : Fri Jan 17 2003 - 17:21:49 GMT-3