From: Narbik Kocharians (narbikk@gmail.com)
Date: Tue Jul 15 2008 - 23:09:36 ART
In RIPv2 If you only wanted one of the sides to receive the routes you could
also use authentication.
On Tue, Jul 15, 2008 at 2:34 PM, David Chances <davidchances@yahoo.com>
wrote:
> Yeahm thanks Mcgahan. Thats really cleared it up for me, and perhaps Khan
> too.
>
> :)
>
> --- On Tue, 7/15/08, Fahad Khan <fahad.khan@gmail.com> wrote:
> From: Fahad Khan <fahad.khan@gmail.com>
> Subject: Re: rip passive int with neighbor command
> To: "Brian McGahan" <bmcgahan@internetworkexpert.com>
> Cc: "Jonathan Greenwood II" <gwood83@gmail.com>, "Cisco Addicted" <
> cisco.addicted@gmail.com>, "Peter Stephan" <engpeter@gmail.com>, "Nate
> Cielieska" <ncielieska@gmail.com>, "Igor Manassypov" <
> imanassypov@rogers.com>, "GS CCIE-Lab" <ccielab@groupstudy.com>
> Date: Tuesday, July 15, 2008, 5:11 PM
>
> Thanks McGahan, Kindly shed light over OSPF and RIP in the similar way.
>
> Thanks and regards,
>
>
> On 7/15/08, Brian McGahan <bmcgahan@internetworkexpert.com> wrote:
> >
> > Actually there is another important point to be added onto this. EIGRP
> > only uses multicast to discover neighbors and for periodic keepalives.
> > The actual exchange of the topology table is done through unicast. This
> > means that by default EIGRP actually uses multicast AND unicast, but if
> > you use the neighbor statement it uses JUST unicast. The fact that the
> > neighbor statement suppresses the multicast hello/keepalive implies that
> > any other neighbors on the segment also need to unicast their
> > hellos/keepalives, otherwise they will never discover each other. You
> > can see this operation in action if you "debug ip packet
> detail". Take
> > the following case with R1 having the address 10.0.0.1 and forming
> > adjacency with the neighbor 10.0.0.2.
> >
> > R1 initializes its EIGRP process.
> >
> > R1#config t
> > Enter configuration commands, one per line. End with CNTL/Z.
> > R1(config)#router eigrp 1
> > R1(config-router)#no auto-summary
> > R1(config-router)#network 0.0.0.0
> > R1(config-router)#end
> > R1#
> >
> > Hellos are multicast out all links running EIGRP.
> >
> > Jul 15 11:39:54.695: IP: s=10.0.0.1 (local), d=224.0.0.10
> > (FastEthernet0/0), len 60, sending broad/multicast, proto=88
> > Jul 15 11:39:54.699: IP: s=1.1.1.1 (local), d=224.0.0.10 (Loopback0),
> > len 60, sending broad/multicast, proto=88
> > Jul 15 11:39:54.699: IP: s=1.1.1.1 (Loopback0), d=224.0.0.10, len 60,
> > rcvd 2, proto=88
> >
> > A hello packet comes in from 10.0.0.2 via multicast and neighbor
> > adjacency occurs.
> >
> > Jul 15 11:39:54.707: IP: s=10.0.0.2 (FastEthernet0/0), d=224.0.0.10, len
> > 60, rcvd 2, proto=88
> > Jul 15 11:39:54.711: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 10.0.0.2
> > (FastEthernet0/0) is up: new adjacency
> >
> > The topology is exchanged via unicast.
> >
> > Jul 15 11:39:54.711: IP: tableid=0, s=10.0.0.2 (FastEthernet0/0),
> > d=10.0.0.1 (FastEthernet0/0), routed via RIB
> > Jul 15 11:39:54.711: IP: s=10.0.0.2 (FastEthernet0/0), d=10.0.0.1
> > (FastEthernet0/0), len 40, rcvd 3, proto=88
> > Jul 15 11:39:54.715: IP: s=10.0.0.1 (local), d=224.0.0.10
> > (FastEthernet0/0), len 60, sending broad/multicast, proto=88
> > Jul 15 11:39:54.719: IP: s=10.0.0.1 (local), d=10.0.0.2
> > (FastEthernet0/0), len 40, sending, proto=88
> > Jul 15 11:39:54.719: IP: s=10.0.0.2 (FastEthernet0/0), d=224.0.0.10, len
> > 77, rcvd 2, proto=88
> > Jul 15 11:39:54.723: IP: s=10.0.0.2 (FastEthernet0/0), d=224.0.0.10, len
> > 69, rcvd 2, proto=88
> > Jul 15 11:39:54.727: IP: s=10.0.0.1 (local), d=224.0.0.10
> > (FastEthernet0/0), len 77, sending broad/multicast, proto=88
> > Jul 15 11:39:54.727: IP: s=10.0.0.1 (local), d=224.0.0.10
> > (FastEthernet0/0), len 69, sending broad/multicast, proto=88
> > Jul 15 11:39:54.731: IP: tableid=0, s=10.0.0.2 (FastEthernet0/0),
> > d=10.0.0.1 (FastEthernet0/0), routed via RIB
> > Jul 15 11:39:54.731: IP: s=10.0.0.2 (FastEthernet0/0), d=10.0.0.1
> > (FastEthernet0/0), len 69, rcvd 3, proto=88
> > Jul 15 11:39:54.735: IP: tableid=0, s=10.0.0.2 (FastEthernet0/0),
> > d=10.0.0.1 (FastEthernet0/0), routed via RIB
> > Jul 15 11:39:54.735: IP: s=10.0.0.2 (FastEthernet0/0), d=10.0.0.1
> > (FastEthernet0/0), len 40, rcvd 3, proto=88
> > Jul 15 11:39:54.739: IP: s=10.0.0.1 (local), d=10.0.0.2
> > (FastEthernet0/0), len 69, sending, proto=88
> > Jul 15 11:39:54.747: IP: tableid=0, s=10.0.0.2 (FastEthernet0/0),
> > d=10.0.0.1 (FastEthernet0/0), routed via RIB
> > Jul 15 11:39:54.747: IP: s=10.0.0.2 (FastEthernet0/0), d=10.0.0.1
> > (FastEthernet0/0), len 69, rcvd 3, proto=88
> > Jul 15 11:39:54.751: IP: tableid=0, s=10.0.0.2 (FastEthernet0/0),
> > d=10.0.0.1 (FastEthernet0/0), routed via RIB
> > Jul 15 11:39:54.755: IP: s=10.0.0.2 (FastEthernet0/0), d=10.0.0.1
> > (FastEthernet0/0), len 40, rcvd 3, proto=88
> > Jul 15 11:39:54.755: IP: s=10.0.0.1 (local), d=10.0.0.2
> > (FastEthernet0/0), len 40, sending, proto=88
> > Jul 15 11:39:54.963: IP: s=10.0.0.1 (local), d=10.0.0.2
> > (FastEthernet0/0), len 69, sending, proto=88
> > Jul 15 11:39:54.971: IP: tableid=0, s=10.0.0.2 (FastEthernet0/0),
> > d=10.0.0.1 (FastEthernet0/0), routed via RIB
> > Jul 15 11:39:54.971: IP: s=10.0.0.2 (FastEthernet0/0), d=10.0.0.1
> > (FastEthernet0/0), len 40, rcvd 3, proto=88
> > Jul 15 11:39:55.139: %SYS-5-CONFIG_I: Configured from console by console
> > R1#
> >
> > Once converged only periodic multicast hellos are exchanged until
> > something changes in the topology.
> >
> > Jul 15 11:39:59.551: IP: s=10.0.0.2 (FastEthernet0/0), d=224.0.0.10, len
> > 60, rcvd 2, proto=88
> > Jul 15 11:39:59.579: IP: s=1.1.1.1 (local), d=224.0.0.10 (Loopback0),
> > len 60, sending broad/multicast, proto=88
> > Jul 15 11:39:59.579: IP: s=1.1.1.1 (Loopback0), d=224.0.0.10, len 60,
> > rcvd 2, proto=88
> > Jul 15 11:39:59.687: IP: s=10.0.0.1 (local), d=224.0.0.10
> > (FastEthernet0/0), len 60, sending broad/multicast, proto=88
> > Jul 15 11:40:04.202: IP: s=10.0.0.1 (local), d=224.0.0.10
> > (FastEthernet0/0), len 60, sending broad/multicast, proto=88
> > Jul 15 11:40:04.495: IP: s=1.1.1.1 (local), d=224.0.0.10 (Loopback0),
> > len 60, sending broad/multicast, proto=88
> > Jul 15 11:40:04.495: IP: s=1.1.1.1 (Loopback0), d=224.0.0.10, len 60,
> > rcvd 2, proto=88
> > Jul 15 11:40:04.539: IP: s=10.0.0.2 (FastEthernet0/0), d=224.0.0.10, len
> > 60, rcvd 2, proto=88
> > Jul 15 11:40:08.838: IP: s=10.0.0.1 (local), d=224.0.0.10
> > (FastEthernet0/0), len 60, sending broad/multicast, proto=88
> > Jul 15 11:40:09.190: IP: s=10.0.0.2 (FastEthernet0/0), d=224.0.0.10, len
> > 60, rcvd 2, proto=88
> > Jul 15 11:40:09.270: IP: s=1.1.1.1 (local), d=224.0.0.10 (Loopback0),
> > len 60, sending broad/multicast, proto=88
> > Jul 15 11:40:09.270: IP: s=1.1.1.1 (Loopback0), d=224.0.0.10, len 60,
> > rcvd 2, proto=88
> >
> >
> >
> > HTH,
> >
> > Brian McGahan, CCIE #8593 (R&S/SP/Security)
> > bmcgahan@internetworkexpert.com
> <mailto:bmcgahan@internetworkexpert.com>
> >
> > Internetwork Expert, Inc.
> > http://www.InternetworkExpert.com <http://www.internetworkexpert.com/>
> > Toll Free: 877-224-8987 x 705
> > Outside US: 775-826-4344 x 705
> > Online Community: http://www.IEOC.com <http://www.ieoc.com/>
> > CCIE Blog: http://blog.internetworkexpert.com
> >
> >
> > Jonathan Greenwood II wrote:
> > > Peter well said you hit it right on the nail.
> > >
> > > On Tue, Jul 15, 2008 at 12:38 PM, Cisco Addicted <
> > cisco.addicted@gmail.com>
> > > wrote:
> > >
> > >
> > >> Peter,
> > >> Thank you very much for the sharp and bright clarification.
> Really you
> > >> shot
> > >> the head of this issue.
> > >>
> > >> Regards.
> > >> Moe
> > >>
> > >> -----Original Message-----
> > >> From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On
> Behalf Of
> > >> Peter Stephan
> > >> Sent: Tuesday, July 15, 2008 7:42 PM
> > >> To: 'Nate Cielieska'; 'Igor Manassypov'
> > >> Cc: 'Jonathan Greenwood II'; 'GS CCIE-Lab'
> > >> Subject: RE: rip passive int with neighbor command
> > >>
> > >> Just to remember:
> > >>
> > >> In EIGRP:
> > >> If you enable unicast updates on an interface, you DISABLE
> multicasting
> > >> updates to 224.0.0.10 through that particular interface.
> > >>
> > >> In RIP v2:
> > >> If you enable unicast updates on an interface (through neighbor
> cmd),
> > you
> > >> 'DO NOT STOP' multicasting updates.
> > >> You use then passive-interface to stop multicasting updates if it
> was
> > >> required.
> > >>
> > >>
> > >> Don't confuse yourself... just remember in EIGRP you either
> have unicast
> > or
> > >> multicast, in RIP you can have both (unless you use passive-int).
> > >>
> > >> Cheers,
> > >> Peter.
> > >>
> > >> -----Original Message-----
> > >> From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On
> Behalf Of
> > >> Nate
> > >> Cielieska
> > >> Sent: Tuesday, July 15, 2008 8:24 PM
> > >> To: Igor Manassypov
> > >> Cc: Jonathan Greenwood II; GS CCIE-Lab
> > >> Subject: Re: rip passive int with neighbor command
> > >>
> > >> Igor,
> > >>
> > >> When you turn on unicast updates with the "neighbor
> x.x.x.x" command,
> > this
> > >> does not disable the multicast updates out of that interface. It
> merely
> > >> sends that particular neighbor a unicast update and sends out a
> > >> 224.0.0.9multicast update as well.. to stop the multicast updates
> you
> > used
> > >> the passive-interface command. The passive-interface command has
> no
> > bearing
> > >> on your unicast updates so your updates will be seen on your
> router..
> > >> meeting your requirements.
> > >>
> > >> Regards,
> > >> Nate
> > >>
> > >> On Tue, Jul 15, 2008 at 10:58 AM, Igor Manassypov <
> > imanassypov@rogers.com>
> > >> wrote:
> > >>
> > >>
> > >>> if I configure that interface on which my neighbor sits as
> passive,
> > >>> and I also configure a neighbor command explicitly, are
> routes going
> > >>> to be exchanged?
> > >>>
> > >>> Jonathan Greenwood II <gwood83@gmail.com> wrote: Igor
> when you use the
> > >>> neighbor command you are sending RIP updates via unicast by
> > >>> specifiying the IP Address of the neighboring router as
> opposed to the
> > >>> multicast address 224.0.0.9 which all rip enabled interfaces
> listen
> > >>> on. Passive interface with RIP doesn't allow updates to
> be sent out
> > >>> the interface but an interface can still receive updates from
> my
> > >>>
> > >> understanding.
> > >>
> > >>> To actually form the neighbor relationship the interface
> should not be
> > >>> configured for passive interface. You could also peform RIP
> > >>> authentication on both sides depending on the
> requirements/restrictions
> > >>>
> > >> of
> > >> the question.
> > >>
> > >>> HTH
> > >>>
> > >>> Jonathan
> > >>>
> > >>> On Tue, Jul 15, 2008 at 9:44 AM, Igor Manassypov
> > >>> wrote:
> > >>>
> > >>>
> > >>>> 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
> > >>>
> > >>
> _______________________________________________________________________
> > >> 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
> >
> >
> > _______________________________________________________________________
> > Subscription information may be found at:
> > http://www.groupstudy.com/list/CCIELab.html
> >
> >
> >
> >
> >
>
>
> --
> *FAHAD KHAN
>
> *
>
>
> _______________________________________________________________________
> 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