From: Narbik Kocharians (narbikk@gmail.com)
Date: Wed Jul 16 2008 - 11:41:03 ART
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