From: amilabs (amilabs@optonline.net)
Date: Fri Jul 16 2004 - 13:14:37 GMT-3
The stub option, especially for spokes was designed to reduce the DUAL
process time and in some designs shorten the DUAL boundaries of the eigrp
topology for quicker convergence.
-----Original Message-----
From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of
Joseph D. Phillips
Sent: Friday, July 16, 2004 12:09 PM
To: group study
Subject: EIGRP connection to backbone routers
From what I can gather, configuring a router as an EIGRP stub is desirable
when it's a spoke. If there are no other routers in the EIGRP autonomous
system, the two methods work the same.
The distribute list has the advantage of denying updates to a specific
neighbor. If you're being asked on the real exam to keep updates from
flowing to a specific neighbor, I would think a distribute list is in order.
Configuring a router as an EIGRP stub affects not just one neighbor, but all
of them, present and future.
Anyone care to comment?
----- Original message -----
From: "Lord, Chris" <chris.lord@lorien.co.uk>
To: ccielab@groupstudy.com
Date: Fri, 16 Jul 2004 16:38:33 +0100
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