From: Felice Russell (felicear@sbcglobal.net)
Date: Fri Jul 16 2004 - 13:23:10 GMT-3
1.) To limit the eigrp hellos
http://www.cisco.com/en/US/tech/tk365/tk207/technologies_tech_note09186a0080
093f0a.shtml
2.) to limit specific neighbor communications
neighbor (Enhanced IGRP)
To define a neighboring router with which to exchange routing information,
use the neighbor router configuration command. To remove an entry, use the
no form of this command.
neighbor ip-address
no neighbor ip-address
Syntax Description
ip-address
IP address of a peer router with which routing information will be
exchanged.
Defaults
No neighboring routers are defined.
Command Modes
Router configuration
Command History
Release
Modification
10.0
This command was introduced.
Usage Guidelines
This command permits the point-to-point (nonbroadcast) exchange of routing
information. When used in combination with the passive-interface router
configuration command, routing information can be exchanged between a subset
of routers and access servers on a LAN.
Multiple neighbor commands can be used to specify additional neighbors or
peers.
Examples
In the following example, Enhanced Interior Gateway Routing Protocol (EIGRP)
updates are sent to all interfaces on network 192.168.0.0 except Ethernet
interface 1. However, in this case a neighbor router configuration command
is included. This command permits the sending of routing updates to specific
neighbors. One copy of the routing update is generated per neighbor.
router eigrp 109
network 192.168.0.0
passive-interface ethernet 1
neighbor 192.168.20.4
Related Commands
Command
Description
passive-interface
Disables sending routing updates on an interface.
http://www.cisco.com/univercd/cc/td/doc/product/software/ios122/122cgcr/fipr
rp_r/1rfeigrp.htm#wp1031261
And also as you mentioned:
When the passive-interface command is used in EIGRP, the router cannot form
neighbor adjacencies on the interface, or send or receive routing updates.
However, if you want the outgoing routing updates alone be suppressed but
the inbound updates continue to be received (and the routers still continue
to be neighbors), then use the distribute-list command as follows:
R1(config)#access-list 20 deny any
R1(config)#router eigrp 1
R1(config-router)#no passive-interface serial 0
R1(config-router)#distribute-list 20 out serial 0
However...will verfifying this information I found this:
Q. What does the neighbor statement in the EIGRP configuration section do?
A. Although the neighbor command is accepted by the Cisco IOSR parser,
it should not be used. The neighbor statement does not behave as intended
and can have a negative effect on EIGRP neighbors.
http://www.cisco.com/en/US/tech/tk365/tk207/technologies_q_and_a_item09186a0
08012dac4.shtml#ten
-----Original Message-----
From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of
Lord, Chris
Sent: Friday, July 16, 2004 8:39 AM
To: ccielab@groupstudy.com
Subject: EIGRP connection to backbone routers
I have come across several sample scenarios where, say, Rx is connected to a
backbone router and they run eigrp between them. You are then asked not to
send eigrp updates from your pod (Rx) to the backbone but you must be able
to recieve routes from the bb. Two different solutions seem to be
forthcoming:
1) Rx: router eigrp 10
distribute-list 10 out e0/0
access-list 10 deny any
2) Rx: router eigrp 10
eigrp stub receive-only
If we were faced with this in the lab, provided that no other specific
information was provided, do you think either solution could be used. Or
have I missed some subtle difference between the two approaches?
Cheers,
Chris
**********************************************************************
The information contained in this email is confidential and is intended for
the recipient only. If you have received it in error, please notify us
immediately by reply email and then delete it from your system. Please do
not copy it or use it for any purposes, or disclose its contents to any
other person or store or copy this information in any medium. The views
contained in this email are those of the author and not necessarily those of
Lorien plc.
Thank you for your co-operation.
**********************************************************************
This archive was generated by hypermail 2.1.4 : Sun Aug 01 2004 - 10:11:57 GMT-3