From: Erick B. (erickbe@xxxxxxxxx)
Date: Sun May 19 2002 - 22:51:11 GMT-3
Hi,
What is really happening is that under IGRP you have
the 135 network specified, so when you redist IGRP
into OSPF this is an external route to OSPF also and a
summary-address is created based on the
summary-address config you have.
They fixed this in 12.1(3)... no need to have both a
intra/inter LSA and an external LSA as it eats up
additional memory.
See:
http://www.cisco.com/warp/public/104/redist-conn.html
--- David Luu <wicked01@ix.netcom.com> wrote:
> i may be the one with the bugged IOS since others
> aren't able to summarize
> outgoing without the 2nd ospf process..im running an
> old 11.something IOS
>
> At 09:34 AM 5/19/2002 -0400, Ludwig A. Morales
> wrote:
> >Unless all my router has bugs on the IOS the
> summary address command *DOES
> >NOTHING* to summarize outgoing advertisements, if
> any one have a working
> >config with these pleases post it to prove-test
> this.
> >
> >Now, how would I use a second ospf process? do I
> create a second process
> >and redistribute my original ospf, use summary
> address here and redistribute
> >this one to igrp, or do I run the network I want
> to summarize in a second
> >process, summarize it under my original process.
> please post an example if
> >anyone have it.
> >
> >
> >Regards,
> >
> >Ludwig----- Original Message -----
> >From: "David Luu" <wicked01@ix.netcom.com>
> >To: "Jonathan Hays" <jhays@jtan.com>;
> <ccielab@groupstudy.com>
> >Sent: Sunday, May 19, 2002 3:50 AM
> >Subject: RE: FATKID 502 Expert Redistribution
> >
> >
> > > i did some testing out of curiosity, and the
> summary-address will be
> > > advertised out of ospf with or without the 2nd
> ospf process...so i retract
> > > the statement below...however i couldnt get it
> to ping across, buts its
> > > probably some human error on my end...i will do
> some more testing to get
> > > the ping to work...
> > >
> > > learning something new everyday
> > >
> > > At 11:51 PM 5/18/2002 -0700, David Luu wrote:
> > > >summary-address summarizes going into ospf, not
> out
> > > >
> > > >if you looked at his config, the 135.1.20.0/22
> subnet originated in ospf,
> > > >so the summary-address would not be advertised
> to igrp
> > > >
> > > >since R4 is an ASBR, you need to summarize to a
> /24 by creating a second
> > > >ospf process and redistributing it into and
> using the summary-address
> > > >command on the first process
> > > >
> > > >
> > > >At 11:13 PM 5/18/2002 -0700, Jonathan Hays
> wrote:
> > > >>Yes - I know what you are thinking - this:
> > > >>
> > >
> >>http://www.cisco.com/warp/public/104/3.html#12.0
> > > >>
> > > >>"External Route Summarization
> > > >>
> > > >>External route summarization is specific to
> external routes that are
> > > >>injected into OSPF via redistribution. Also,
> make sure that external
> > > >>ranges that are being summarized are
> contiguous. Summarization
> > > >>overlapping ranges from two different routers
> could cause packets to be
> > > >>sent to the wrong destination. Summarization
> is done via the following
> > > >>router ospf subcommand:
> > > >>
> > > >> summary-address ip-address mask
> > > >>
> > > >>This command is effective only on ASBRs doing
> redistribution into OSPF."
> > > >>---
> > > >>The above CCO verbiage WOULD seem to indicate
> that the command is
> > > >>effective only one way. However, don't forget,
> this is an ASBR which
> > > >>also has the duty to tell external networks
> about what routes are
> > > >>available in the OSPF cloud.
> > > >>
> > > >>The configuration you gave is only the part
> where IGRP is redistributed
> > > >>into OSPF:
> > > >>
> > > >>router ospf 100
> > > >> router-id 4.4.4.4
> > > >> log-adjacency-changes
> > > >> summary-address 135.1.20.0 255.255.255.0
> > > >> redistribute igrp 100 subnets
> > > >>
> > > >>I haven't seen the write-up in question, but
> you are correct that the
> > > >>above configuration by itself does nothing to
> redistribute routes into
> > > >>IGRP. To do that statements like the ones
> below are needed:
> > > >>
> > > >>router igrp
> > > >> redistribute ospf 100 metric 10000 2000 255
> 1 1500 subnets
> > > >>
> > > >>And the trick here, is that since the
> 135.1.20.0/22 network has been
> > > >>summarized in OSPF as a /24, then *that* /24
> is what gets redistributed
> > > >>into IGRP. This "trick" is necessary because
> IGRP won't understand the
> > > >>classless subnets. Essentially, you are using
> the OSPF ASBR's summary
> > > >>network statement to "adjust" the mask of OSPF
> classless networks to
> > > >>something that IGRP will understand.
> > > >>
> > > >>HTH,
> > > >>
> > > >>Jonathan
> > > >>
> > > >>
> > > >>-----Original Message-----
> > > >>From: nobody@groupstudy.com
> [mailto:nobody@groupstudy.com] On Behalf Of
> > > >>Todd Spencer
> > > >>Sent: Saturday, May 18, 2002 4:54 PM
> > > >>To: ccielab@groupstudy.com
> > > >>Subject: FATKID 502 Expert Redistribution
> > > >>
> > > >>
> > > >>I am trying to do the FatKid 502 Expert
> Redistribution
> > > >>Lab, and I don't understand the solution
> provided. I
> > > >>will try to briefly explain.
> > > >>
> > > >>The problem has to do with the classic VLSM to
> FLSM
> > > >>problem (IGRP/OSPF). The lab requires that
> OSPF area
> > > >>4 be configured with a /22 subnet, and the
> IGRP domain
> > > >>be configured with a /24. OSPF area 4 is
> using the
> > > >>following subnet 135.1.20.x/22 and the IGRP
> domain is
> > > >>using 135.1.1.x/24. The OSPF configuration
> below is
> > > >>taken from the solution:
> > > >>
> > > >>router ospf 1
> > > >> summary-address 135.1.20.0 255.255.255.0
> > > >> redistribute igrp 1 subnets
> > > >> network 135.1.14.0 0.0.0.255 area 4
> > > >> network 135.1.20.0 0.0.3.255 area 4
> > > >>
> > > >>I am unsure what the summary-address command
> is doing
> > > >>in this configuration. How is it able to
> summarize a
> > > >>/22 into a /24? How is the /22 subnet getting
> into
> > > >>the IGRP domain? If anyone has done this lab
> and can
> > > >>provide assistance, it would be greatly
> appreciated.
> > > >>
> > > >>-Todd
This archive was generated by hypermail 2.1.4 : Thu Jun 13 2002 - 10:59:01 GMT-3