From: Brian McGahan (bmcgahan@internetworkexpert.com)
Date: Tue Jul 15 2008 - 15:53:37 ART
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...
>>
>>>> ____________________________________________________________________
>>>> ___ 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
This archive was generated by hypermail 2.1.4 : Mon Aug 04 2008 - 06:11:55 ART