Re: rip passive int with neighbor command

From: Jason Madsen (madsen.jason@gmail.com)
Date: Wed Jul 16 2008 - 10:30:07 ART


Thanks for the explanation. Without testing, I just assumed Narbik was
referring to "turning on" rip authentication on one end of a link and not
the other, which really didn't make much sense at the moment.

Jason

On Wed, Jul 16, 2008 at 2:42 AM, Petr Lapukhov <petr@internetworkexpert.com>
wrote:

> Narbik references to somewhat obscure features of the RIP authentication
> process. Specifically, you can simulate unidirectional filtering using one
> of the following (non-standard) methods:
> 1) Using RIP plain-text authentication, configure a key-chain with two
> different keys on first router (R1) and a key chain of just one of those
> key
> on the other router (R2). RIP does not send "key-id" with plaintext
> authentication and always sends the lowest numbered key. However, when it
> verifies the received key, the match is performed agains every key in the
> key-chain configured for the interface.
>
> So if you have the following configuration:
>
> R1:
> key chain RIP2
> key 1
> key-string CISCO1
> key 2
> key-string CISCO2
>
> R2:
> key chain RIP2
> key 1
> key-string CISCO2
>
> In this situation, R1 will accept R2 updates, but R2 will NOT accept R1
> updates (key mismatch)
>
> 2) Configure key-chains using mismatching send/accept time-ranges (works
> for
> MD5-based authentication)
>
> R1:
> Key-chain RIP:
> key 1 -- text "CISCO"
> accept lifetime (00:00:00 UTC Jan 1 2001) - (infinite) [valid now]
> send lifetime (00:00:00 UTC Jan 1 2001) - (infinite) [valid now]
>
> R2:
> Key-chain RIP:
> key 1 -- text "CISCO"
> accept lifetime (00:00:00 UTC Jan 1 2005) - (infinite)
> send lifetime (00:00:00 UTC Jan 1 2001) - (infinite) [valid now]
>
> In this case, R2 will NOT accept updates from R1 (accept time invalid) but
> R1 will accept updates from R2 (accept time valid). Both routers always
> send
> keys, since the send time is valid.
>
> --
> Petr Lapukhov, CCIE #16379 (R&S/Security/SP/Voice)
> petr@internetworkexpert.com
>
> Internetwork Expert, Inc.
> http://www.InternetworkExpert.com
> Toll Free: 877-224-8987
> Outside US: 775-826-4344
> Online Community: http://www.IEOC.com
> CCIE Blog: http://blog.internetworkexpert.com
>
> 2008/7/15 Igor Manassypov <imanassypov@rogers.com>:
>
> > Could someone please clarify rip's neighbor command mixed with a
> > passive-interface? For example, if you are asked to make sure that
> routing
> > updates are only sent to a particular router, I will configure a
> > corresponding 'neighbor' entry under my rip process, but to satisfy the
> > requirement that only that particular router gets updates I would also
> need
> > to enable the passive interface. As soon as I do that, there are no more
> > routing updates coming from that interface even though I have an explicit
> > neighbor configured... If I do not use the passive interface, then other
> > routers will get updates breaking the requirement...
> >
> >
> > _______________________________________________________________________
> > Subscription information may be found at:
> > http://www.groupstudy.com/list/CCIELab.html
>
>
> _______________________________________________________________________
> Subscription information may be found at:
> http://www.groupstudy.com/list/CCIELab.html



This archive was generated by hypermail 2.1.4 : Mon Aug 04 2008 - 06:11:55 ART