From: marvin greenlee (marvin@ccbootcamp.com)
Date: Tue Apr 05 2005 - 21:34:54 GMT-3
EIGRPs' hop-count limitation is 224.
"...Increased network width-With IP RIP, the largest possible width of your
network is 15 hops. When IP Enhanced IGRP is enabled, the largest possible
width is 224 hops..."
Cisco - Configuring IP Enhanced IGRP -
http://www.cisco.com/en/US/products/sw/iosswrel/ps1828/products_configuratio
n_guide_chapter09186a00800ca56e.html
Marvin Greenlee, CCIE#12237, CCSI# 30483
Network Learning Inc
marvin@ccbootcamp.com
www.ccbootcamp.com (Cisco Training)
-----Original Message-----
From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of
Brian Dennis
Sent: Tuesday, April 05, 2005 4:12 PM
To: John Matus; ccielab@groupstudy.com
Subject: RE: blocking eigrp routes [bcc][faked-from][bayes]
Importance: Low
There is a hop count limitation in EIGRP but the offset list does not
affect the number of hops for EIGRP.
Brian Dennis, CCIE #2210 (R&S/ISP-Dial/Security)
bdennis@internetworkexpert.com
Internetwork Expert, Inc.
http://www.InternetworkExpert.com
Toll Free: 877-224-8987
Direct: 775-745-6404 (Outside the US and Canada)
-----Original Message-----
From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of
John Matus
Sent: Tuesday, April 05, 2005 4:02 PM
To: ccie2be@nyc.rr.com; simon.hart@btinternet.com;
ccielab@groupstudy.com
Subject: RE: blocking eigrp routes
i was under the impression, from what i have read in the past, that
eigrp
actually does consider a metric of 255 to be unreachable <hops that is>.
in
that situation i suppose you could use an offset list with a metric of
255,
but mani seems to say differently.
does anyone else recall eigrps hop limitations?
>From: "ccie2be" <ccie2be@nyc.rr.com>
>To: "'simon hart'" <simon.hart@btinternet.com>, "'John Matus'"
><john_matus@hotmail.com>, <ccielab@groupstudy.com>
>Subject: RE: blocking eigrp routes
>Date: Tue, 5 Apr 2005 18:55:08 -0400
>
>Simon,
>
>I missed that. The doc-cd does say the value is added to the delay
>component although not where you would expect it to say so. It's in
>explanation of the example, not where they define what each variable of
the
>command does. Oh, well.
>
>As far as where to use this command, I did think of one scenario:
>
>Let's say you have to configure equal cost load-balancing and you're
>prohibited from using any interface commands.
>
>To be sure, not a real world scenario, but not too unlikely a Cisco lab
>task.
>
>What do ya think?
>
>Tim
>
>-----Original Message-----
>From: simon hart [mailto:simon.hart@btinternet.com]
>Sent: Tuesday, April 05, 2005 6:40 PM
>To: ccie2be; 'John Matus'; ccielab@groupstudy.com
>Subject: RE: blocking eigrp routes
>
>Tim,
>
>The Doc-CD does provide a hint
>
>http://www.cisco.com/univercd/cc/td/doc/product/software/ios122/122cgcr
/fipr
>rp_r/1rfeigrp.htm#wp1022565
>
>'For IGRP the offset is added to the delay component only'
>
>Now my assumption is that this is what also happens with EIGRP. If I
get a
>chance, and remember when I boot up my routers, I will test to see.
With
>that said, the offset will only be able to adjust one of the components
for
>the reasons stated before.
>
>When would you use eigrp offset ??? I am not sure either, have not
seen up
>come up as a requirement.
>
>Simon
>
>-----Original Message-----
>From: nobody@groupstudy.com [mailto:nobody@groupstudy.com]On Behalf Of
>ccie2be
>Sent: 05 April 2005 23:17
>To: 'simon hart'; 'John Matus'; ccielab@groupstudy.com
>Subject: RE: blocking eigrp routes
>
>
>Simon,
>
>How interesting.
>
>Unfortunately, but as usual, the Doc-CD sheds no light on this. Did
you
>discover this by testing?
>
>I'm still trying to think of a scenario where using the offset command
is
>the only way to achieve the required result, but can't think of any.
>
>Have you come across any eigrp scenario's which would require this
command
>to be used?
>
>Tim
>
>-----Original Message-----
>From: simon hart [mailto:simon.hart@btinternet.com]
>Sent: Tuesday, April 05, 2005 6:05 PM
>To: ccie2be; 'John Matus'; ccielab@groupstudy.com
>Subject: RE: blocking eigrp routes
>
>Tim,
>
>I believe the offset is added to the delay component. The offset
cannot be
>the composite metric as the TLV's that eigrp advertised do not include
the
>composite value, but the delay, bandwidth, MTU, Load and Reliability
(MTU
>not used though!!). This is why the K values have to be the same
througout
>the domain.
>
>Now what I said below is was slightly incorrect (whoops!!). If the
>originating route has a delay function of 1000, an offset list of 255
will
>in fact add 255 to that delay function, thus the delay will now be
>advertised as 1255 to the next hop.
>
>Simon
>
>
>
>-----Original Message-----
>From: ccie2be [mailto:ccie2be@nyc.rr.com]
>Sent: 05 April 2005 22:50
>To: 'simon hart'; 'John Matus'; ccielab@groupstudy.com
>Subject: RE: blocking eigrp routes
>
>
>Hi Simon,
>
>Excellent post!!!!
>
>But, you raise an interesting question.
>
>Given that eigrp has 2 types of metrics: bandwidth, delay, etc, and
>composite, I assume that the metric used with the offset command is the
>composite version, right?
>
>Now, normally with eigrp, whenever you manipulate metric values you're
>manipulating the component (b/w, delay, etc,) values of the metric, not
the
>composite itself. So, what happens to the component values when you
>manipulate the composite instead of the component values?
>
>Does eigrp use it's formula for computing the composite metric in
reverse
>when the composite itself is changed?
>
>Also, given what you've said, it seems like there's no good reason for
>using
>the offset-list command with eigrp.
>
>If you wanted or needed to change Eigrp's metric, for example, for the
>purpose of load-balancing, you would change one of the component
metrics
>such as bandwidth or delay on the interfaces to do so rather than
>manipulate
>the composite metric with the offset command.
>
>So, what reason might there be for using the offset command?
>
>TIA, Tim
>
>-----Original Message-----
>From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of
>simon hart
>Sent: Tuesday, April 05, 2005 5:04 PM
>To: John Matus; ccielab@groupstudy.com
>Subject: RE: blocking eigrp routes
>
>Hi John,
>
>You cannot use the offset list to make a route(s) unreachable with
eigrp,
>although you can do this with rip.
>
>Rip has the philosophy that an infinite metric......anything over
15.....
>is
>unreachable, therefore making the metric 16 effectively makes those
routes
>effected by the offset list unreachable.
>
>Eigrp does not have the same philosophy, the composite metric in eigrp
can
>be anything and as far as the protocol is concerned it is still
reachable
>(within the confines fo FD's and FS's etc. etc.)
>
>The example you have given in RIP environment would dictate that every
>route
>advertised out of that interface would unreachable (bearing in mind
that
>you
>could not use 255 in RIP, it would have to be 16). This really would
seem
>a
>little pointless, may as well make the interface passive.
>
>If you used the example below for eigrp you would be advertising eigrp
with
>a metric of 255, and probably making those routes the most favourable.
>Eigrp uses a composite metric, derived by default as function of
bandwidth
>and delay. The metrics are normally quite high, in fact a lot higher
than
>255 (for information the highest eigrp figure you can use on the offset
>list
>is 2147483647).
>
>In order not to advertise to the next hop router you could use:
>
>router eigrp 100
>distribute-list 10 out s0/0
>
>access-list 10 deny 0.0.0.0 255.255.255.255
>
>Change the access list if you wish to deny a subset of routes.
>
>HTH
>
>Simon
>
>-----Original Message-----
>From: nobody@groupstudy.com [mailto:nobody@groupstudy.com]On Behalf Of
>John Matus
>Sent: 05 April 2005 21:30
>To: ccielab@groupstudy.com
>Subject: blocking eigrp routes
>
>
>if i wanted to block all eigrp routes from exiting to the next hop
would it
>be:
>
>offset-list 1 out 255 s0/0
>
>access-l 1 permit 0.0.0.0 255.255.255.255 ?
>
>i wasn't sure since rip's metric would be '16' for offset but i'm not
sure
>about eigrp.
>thanks in advance
>
>_________________________________________________________________
>Express yourself instantly with MSN Messenger! Download today - it's
FREE!
>http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/
>
>_______________________________________________________________________
>Subscription information may be found at:
>http://www.groupstudy.com/list/CCIELab.html
>--
>No virus found in this incoming message.
>Checked by AVG Anti-Virus.
>Version: 7.0.308 / Virus Database: 266.9.2 - Release Date: 05/04/2005
>
>--
>No virus found in this outgoing message.
>Checked by AVG Anti-Virus.
>Version: 7.0.308 / Virus Database: 266.9.2 - Release Date: 05/04/2005
>
>_______________________________________________________________________
>Subscription information may be found at:
>http://www.groupstudy.com/list/CCIELab.html
>
>--
>No virus found in this incoming message.
>Checked by AVG Anti-Virus.
>Version: 7.0.308 / Virus Database: 266.9.2 - Release Date: 05/04/2005
>
>--
>No virus found in this outgoing message.
>Checked by AVG Anti-Virus.
>Version: 7.0.308 / Virus Database: 266.9.2 - Release Date: 05/04/2005
>
>_______________________________________________________________________
>Subscription information may be found at:
>http://www.groupstudy.com/list/CCIELab.html
>--
>No virus found in this incoming message.
>Checked by AVG Anti-Virus.
>Version: 7.0.308 / Virus Database: 266.9.2 - Release Date: 05/04/2005
>
>--
>No virus found in this outgoing message.
>Checked by AVG Anti-Virus.
>Version: 7.0.308 / Virus Database: 266.9.2 - Release Date: 05/04/2005
>
This archive was generated by hypermail 2.1.4 : Tue May 03 2005 - 07:54:53 GMT-3