From: David Chances (davidchances@yahoo.com)
Date: Tue Jul 15 2008 - 18:34:14 ART
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
> Toll Free: 877-224-8987 x 705
> Outside US: 775-826-4344 x 705
> Online Community: 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...
> >>
> >>>>
This archive was generated by hypermail 2.1.4 : Mon Aug 04 2008 - 06:11:55 ART