From: R. Benjamin Kessler (ben@xxxxxxxxxxxxxxxxxxxxx)
Date: Tue Nov 06 2001 - 14:13:44 GMT-3
No takers? Re-posting on the off chance that the best and brightest on the
list missed this one.
FYI - the Slattery/Burton book was one of the texts distributed to ECP-1
students; for those of you who have attended (and/or read this book) I'd
appreciate some clarification on the below.
Thanks,
Ben
-----Original Message-----
From: nobody@groupstudy.com [mailto:nobody@groupstudy.com]On Behalf Of
R. Benjamin Kessler
Sent: Sunday, November 04, 2001 3:37 PM
To: CCIELab
Subject: Slattery/Burton Ch. 4 IGRP Distribute-List question
OK, so I *thought* I understood how the distribute-list command worked...I'm
a bit confused by the statements on ppg. 163-164 (2nd edition) where it says
the following:
"...there are special cases in which it is advantageous to configure
multiple IGRP routing domains and control the flow of routes between them.
Imagine that in Figure 4-14, the connection between NewYork and Moscow is an
expansive serial link and that you want reduce the routing protocol overhead
on this link. You also want to be able to restrict each region to access
only the backbone ethernets and not each other. The configuration in Code
Listing 4-10 implements this and significantly reduces the size of the
routing updates over the backbone between NewYork and Moscow. Each region,
including the backbone, receives a summary route to the other regions."
For those of you without the book:
IGRP 2 consists of three routers NewYork, Tokyo, and London; all interfaces
(except NY's E0) are addressed with subnets (/28) of 192.168.2.0/24.
IGRP 1 consists of three routers Moscow, Paris, and Rome; all interfaces
(except Moscow's E0) are addressed with subnets (/28) of 192.168.1.0/24.
IGRP 100 runs across the E0's of NY and Moscow using the network
172.16.1.0/24
NewYork's IGRP config is as follows:
!
router igrp 2
redistribute igrp 100
network 192.168.2.0
distribute-list 1 out igrp 100 ****
!
router igrp 100
redistribute igrp 2
network 172.16.0.0
!
access-list 1 deny 192.168.2.0
access-list 1 permit any
Moscow's IGRP config is as follows:
!
router igrp 1
redistribute igrp 100
network 192.168.1.0
distribute-list 1 out igrp 100 ****
!
router igrp 100
redistribute igrp 1
network 172.16.0.0
!
access-list 1 deny 192.168.1.0
access-list 1 permit any
!
If I've got this straight, the distribute-list statements (**** above) do
nothing to restrict access to certain networks nor does it reduce the size
of the routing updates across the backbone.
The classful nature of IGRP will summarize the /28 routes to their parent
/24 network when re-distributed.
Per http://www.cisco.com/warp/public/105/34.html:
Using the distribute-list command as above will check list 1 as outbound
routing updates from igrp 100 are being redistributed into igrp 1/2. Only
those updates matching list 1 are redistributed into igrp 1/2.
In this form it appears that the sole purpose of these distribute-list
statements is to protect against a "feedback" route getting looped because
of the mutual re-distribution that is happening (generaly good form in my
book; if you must re-dist both ways). In this particular example we're
protected by split-horizon but if any redundancy (read: loops) existed we'd
need the distribute-list statements.
I tried this config with and without the distribute-list commands and didn't
see a difference in the routing tables or in the periodic updates (debug ip
igrp events and transactions); I just wanted to bounce my thoughts off the
list to make sure I'm not missing something here. Is my understanding
valid? Are the statements made in the book given this particular example
inaccurate?
Thanks,
Ben
This archive was generated by hypermail 2.1.4 : Fri Jun 21 2002 - 06:45:05 GMT-3