From: Joseph D. Phillips (josephdphillips@fastmail.us)
Date: Fri Jul 16 2004 - 13:09:27 GMT-3
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