Chris Whyte wrote:
> 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.
In both cases, using redistribution and using the 'passive-interface default' workaround, the initial LSA for the connected networks is created by the EDGE router which is an ASBR (to use strict OSPF terms).
The 'redistribute connected subnets' ospf command creates those LSAs as type-5 as-external LSAs, one for each connected network/link. These are then propogated throughout the OSPF network (intra-area and through ABRs into other areas).
Using the workaround described in the Cisco bug ID, and specifically using the configuration I detailed in my second response, the initial LSA generated for all of those connected networks is a type-1 intra-area LSA. The standard requires a single type-1 LSA per router per area which includes ALL links to a given area on that router.
The ABR, in this instance, has to convert the networks learned from that type-1 LSA into individual type-3 summaries so that he can propogate those routes into area 0 (remember that type-3 summary-LSAs are for routes to networks, type-4 summary-LSAs are for routes to ASBRs. Since we haven't done anything to affect LSAs for routes to a given router, only routes to networks connected to that router, the question of type-4 summary-LSAs doesn't enter into it)
In both cases, once these LSAs are in area 0 (i.e. the backbone) there is a single LSA for each connected network that exists on the EDGE ASBR under both configurations...in the former case, the LSAs are type-5 as-external-LSAs, in the latter they are type-3 summary-LSAs.
Additionally, the question arises that if, say, there are 200 such interfaces on a given EDGE/ASBR, and one of them flaps...what is worse for the network? Producing a type-5 as-external-LSA for a single link state change (which propogates throughout the network essentially unchanged) or producing a type-1 intra-area-LSA which the ABR(s) still have to analyze in order to find the (1) network out of the 200 whose state has changed.
As I read it, there is no provision in the standard for an intra-area single-link update...it's all or nothing.
> I'm also curious to see how the existence of a
> type-4 summary-lsas never factored into the explanation.
Answered above.
As a side note, while the RFC for OSPF Version 2 is extensive, and detailed, no vendor who has implemented OSPF has either (a) gotten everything 100% right according to the standard or (b) stopped short of following the letter of the standard when the need arises to meet a unique situation for a paying customer.
Any such vendor would, in all honesty, be throwing away potential revenue...and they aren't in business to lose money.
Truthfully, It is in every vendor's best interest to produce an implementation of OSPF that provides, at minimum, the functionality detailed in the standard. But there are shims in just about every routing protocol implementation by just about every vendor whose taken the time to implement a nearly-complete set of functionality for them. Cisco's is no exception.
Again, as I read it, none of what I have described in this thread is technically a violation of any specific requirements of the standard...but many aspects of Cisco's implementation do bend the rules a bit.
Case in point...and for the record, what I've detailed here is based on what has been observed on functional, up-to-date equipment running fairly bleeding-edge and -STABLE- IOS [ GSRs, 12.0(16)S1, etc. ]...none of what I've written is based on assumptions, and there is no guesswork contained herein.
-J
"The shortest path to wisdom is the path that doesn't end."
-Anonymous
>
>
> 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