RE: Slattery/Burton Ch. 4 IGRP Distribute-List question

From: Jason Graun (jgraun@xxxxxxxxxx)
Date: Tue Nov 06 2001 - 17:53:52 GMT-3


   
Well your statement "The classful nature of IGRP will summarize the /28
routes to their parent /24 network when re-distributed" is not accurate.
You would see the same thing if it were a class B address. Try changing
the mask to something not a class boundary. It accepts the classfull
/24 bit mask because the 192.x.x.x is a class C address. I believe
split horizon is keeping the loop from happening which is why you do not
see a difference with or with out the distribute lists. Double check
your config and/or trying turning split horizon off to test. If I have
time, I will simulate this in my lab.

-----Original Message-----
From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of
R. Benjamin Kessler
Sent: Tuesday, November 06, 2001 11:14 AM
To: CCIELab
Subject: RE: Slattery/Burton Ch. 4 IGRP Distribute-List question

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