Forgive me but I have a large problem with the below statement.
Especially since it's your main point and I, therefore, viewed it as a
major flaw in your entire explanation which made all other statements
null and void in my mind (not that the were *all* independently
inaccurate).
> The larger point is that this command, in some environments,
> does nothing for the backbone except convert type-5 LSAs to
> type-3 LSAs.
I must admit I'm a visual person so maybe I'm missing something but you
chose particular words that do not correspond with my undersanding of
how OSPF works. Can you please explain the above in some more detail?
Maybe that will help me. I'm also curious to see how the existence of a
type-4 summary-lsas never factored into the explanation.
Thanks,
Chris
>
> Chris Whyte wrote:
>
> > > In each POP, the ISP is aggregating dedicated customers
> on his EDGE
> > > routers...lot's of connected routes, lot's of static
> routes, both of
> > > which are being re-distributed into the local OSPF area as type-5
> > > LSAs, one per network.
> >
> > Yikes!! Don't do that! First, why do you want to redist connected
> > routes in to OSPF when they'll already be there assumming proper
> > configuration via network statements? No need to (as I've stated
> > before). Second, don't redistribute static into OSPF,
> redist them into
> > BGP.
>
> I'm not going to get into the religious argument regarding
> why we propogate connected routes within our IGP vs. BGP.
>
> It is not always feasible, or preferred, to run BGP on every
> router in an ISP network.
>
> Point in fact, the text of the bug itself specifies the
> desire of the ISP requesting the change to propogate these
> routes into OSPF.
>
> There are two ways to do this...redistribution (which does
> scale with some tweaking, and I know...nobody likes to do
> it...I don't like to do it...but sometimes the solution that
> is the least elegant is the most effective and easiest to
> troubleshoot), and the commands added to OSPF which this bug
> describes.
>
> There are numerous reasons for this in our environment (and
> apparently in others, hence the bug ID in question), too
> numerous to detail in the context of this discussion, so I'll
> focus on responding to the issues you raise with the command
> itself and my description of it's potential use and effects:
>
> I will simply say that the ISP that asked for this change ain't us.
>
> > > Using this feature, it is technically possible to coalesce all
> > > connected networks into a single type-1 LSA by
> configuring an OSPF
> > > network statement in the EDGE router large enough to
> encompass all
> > > connected networks on the router itself.
> >
> > No. Too long to explain why. But read the (very long) RFC
> and it will
> > explain.
>
> Actually, the assessment I gave above is correct. Allow me
> to explain.
>
> We have tested this configuration in a very simple
> environment and found the following:
>
> The combination of the 'passive-interface default' OSPF
> sub-command, specific 'no passive-interface' commands for
> your OSPF-speaking interfaces, and a network statement which
> is broad enough to encompass the respective subnets of all
> interfaces on the box has the effect of:
>
> 1) making all interfaces whose subnets are part of the
> network statement mentioned above part of the area.
> (This can be confirmed by performing a 'show ip ospf interface')
> 2) ensuring the OSPF Hellos will not be generated on all but
> the specified interfaces
> (Confirmed by spanning the port, just to be safe, and
> making sure no OSPF hellos were being seen)
>
> Net effect being that the EDGE router produces a single
> type-1 LSA for all his interfaces, as opposed to individual
> type-5 LSAs under a 'redistribute' configuration.
>
> This is actually a fundamental component of RFC2328/STD54
> (which I have read by the way...thoroughly).
>
> Specifically with regard to Intra-area router-LSAs (Type-1):
>
> From section 12.4.1:
>
> "A router originates a router-LSA for each area that it
> belongs to. Such an LSA describes the collected states of
> the router's links to the area."
>
> From section A.4.2:
>
> "All of the router's links to the area must be described in a
> single router-LSA."
>
>
> So, the EDGE router generates a single type-1 for the POP
> area (the only area he's in), the ABR generates type-3s for
> area 0 from the networks included in the type-1 from the EDGE
> router and not much has changed really in terms of LSA counts
> on the Backbone.
>
> The type-5 LSAs for the EDGE router no longer appeared in
> it's own OSPF database (duh), but no other routers experience
> a palpable benefit in terms of LSA count, since the ABR
> between area 0 and the POP area still (a) generates the
> type-3 LSAs per network to be propogated into area 0 and (b)
> places those into his own database.
>
>
> If you want the details of our tests which show this result,
> I'll be happy to provide them.
>
>
> The larger point is that this command, in some environments,
> does nothing for the backbone except convert type-5 LSAs to
> type-3 LSAs.
>
>
> If you have the perfect network (hands please?) you don't
> need this command in the first place...and actually, about a
> third of what is currently in IOS probably fits into that category. :)
>
>
> Regards,
> -J
>
>
This archive was generated by hypermail 2b29 : Sun Aug 04 2002 - 04:12:40 EDT