From: Scott Morris (swm@emanon.com)
Date: Wed Jul 16 2008 - 13:04:15 ART
I'm pretty sure that some of the newer versions of IOS require the use of a
send/accept lifetime. At least that has been my experience when a couple of
strange routers weren't liking anything. *shrug*
May not be a consistent application of a feature. Not that this would be a
first. :)
Scott
-----Original Message-----
From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of
Narbik Kocharians
Sent: Wednesday, July 16, 2008 10:41 AM
To: Jason Madsen
Cc: Petr Lapukhov; Igor Manassypov; GS CCIE-Lab
Subject: Re: rip passive int with neighbor command
ha ha ha ha Petr, i did not know that what we discuss here in reference to
CCIE should all be *STANDARD* and *NOT OBSCURE*.
BUT NO its NOT what you are saying here, this is what i was referring to,
let's say we are doing MD5 RIPv2 authentication between R1 and R2, you don't
even need to use the "lifetime" option, your assumption is incorrect, here
we go:
*We start by configuring R1:*
Router(config)#host R1
R1(config)#key chain TST
R1(config-keychain)#*key 1*
R1(config-keychain-key)#key-string cisco
R1(config-keychain-key)#int s1/0
R1(config-if)#encap frame
R1(config-if)#int s1/0.12 p
R1(config-subif)#ip addr 10.1.12.1 255.255.255.0
R1(config-subif)#frame inter 102
R1(config-if)#int s1/0
R1(config-if)#no shut
R1(config-fr-dlci)#int lo0
R1(config-if)#ip addr 1.1.1.1 255.0.0.0
R1(config)#router rip
R1(config-router)#no au
R1(config-router)#ver 2
R1(config-router)#netw 10.0.0.0
R1(config-router)#netw 1.0.0.0
*Now, here is R2's config:*
R2(config)#key chain TST
R2(config-keychain)#*key 2*
R2(config-keychain-key)#key-string cisco
R2(config)#int s1/0
R2(config-if)#encap frame
R2(config-if)#int s1/0.21 p
R2(config-subif)#ip addr 10.1.12.2 255.255.255.0
R2(config-subif)#frame inter 201
R2(config-if)#int s1/0
R2(config-if)#no shut
R2(config-fr-dlci)#int lo0
R2(config-if)#ip addr 2.2.2.2 255.0.0.0
R2(config-if)#router rip
R2(config-router)#no au
R2(config-router)#ver 2
R2(config-router)#netw 10.0.0.0
R2(config-router)#netw 2.0.0.0
*To verify:*
* *
*Note they are exchanging routes.*
R1#sh ip route rip
R 2.0.0.0/8 [120/1] via 10.1.12.2, 00:00:16, Serial1/0.12
R2#sh ip route rip
R 1.0.0.0/8 [120/1] via 10.1.12.1, 00:00:02, Serial1/0.21
*Now let's configure authentication:*
*On R1*
R1(config)#int s1/0.12
R1(config-subif)#ip rip auth key-chain TST
R1(config-subif)#ip rip authentication mode md5
*On R2*
R2(config)#int s1/0.21
R2(config-subif)#ip rip authentication key-chain TST
R2(config-subif)#ip rip authentication mode md5
*To Verify:*
R1#sh ip route rip
*Note you don't see any routes because the locally configured key number is
lower than R2, it rejects the authentication. *
R2#sh ip route rip
R 1.0.0.0/8 [120/1] via 10.1.12.1, 00:00:15, Serial1/0.21
*R2 accepts the routes and authentication is successful because it has a
higher key number.*
On Wed, Jul 16, 2008 at 6:30 AM, Jason Madsen <madsen.jason@gmail.com>
wrote:
> 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
> > <http://www.internetworkexpert.com/>
> > Toll Free: 877-224-8987
> > Outside US: 775-826-4344
> > Online Community: http://www.IEOC.com <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
>
>
> ______________________________________________________________________
> _ Subscription information may be found at:
> http://www.groupstudy.com/list/CCIELab.html
>
>
>
>
>
-- Narbik Kocharians CCSI#30832, CCIE# 12410 (R&S, SP, Security) www.MicronicsTraining www.Net-Workbooks.com Sr. Technical Instructor
This archive was generated by hypermail 2.1.4 : Mon Aug 04 2008 - 06:11:55 ART