From: Narbik Kocharians (narbikk@gmail.com)
Date: Wed Jul 16 2008 - 13:45:06 ART
Scott,
In your experience as a CCIE instructor/consultant, how often do we
implement solutions that are not consistent application of the feature/s
provided by a protocol or technology?
I think the way candidates and/or consultants should look at things like
this is that they need to get creative, otherwise, they are as good as the
other person. Just to give you an example, Johny Cochran was an excellent
lawyer, he went to the same School/college as Mr. XYZ, but MR. XYZ did not
make as much money because he could not get creative.
In any field you need to get creative in order to be different (In a good
way). I was trying to show how the behavior of a given protocol can be used
to resolve a problem that has nothing to do with the issue.
Another example, you could use SPAN or RSPAN to get bunch of RIP routes from
one router to another without redistribution, now, i know its way up there,
but hey, does it work? hell yeh. Would i implement it? if my back is against
the wall, you bet.
On Wed, Jul 16, 2008 at 9:04 AM, Scott Morris <swm@emanon.com> wrote:
> 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/>
> > > <http://www.internetworkexpert.com/>
> > > Toll Free: 877-224-8987
> > > Outside US: 775-826-4344
> > > Online Community: http://www.IEOC.com <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 <http://www.net-workbooks.com/> Sr. Technical
> Instructor
>
>
> _______________________________________________________________________
> 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