Ok, but hold on a second. You originally said that you have an edge
router with static and connected networks being redistributed into ospf.
And by just adding this new feature you would get the gains of
coalescing all these into a type-1 lsa via the new default-interface
passive command.
Either the tune of your explanation changed a bit or I just completely
misunderstood that you were presenting an either/or scenario but my
understanding is as long as your still redistributing anything (eg
static and connected) into ospf the default-interface passive command
does nothing for you as far as coalescing them into a type-1 lsa and
referring to the RFC on what would occur was the best explanation.
I believe I now understand what you were presenting so my apologies if I
oringinally misunderstood. Sorry, it just wasn't clear to me how your
scenario could be painted as an either/or scenario since you made it a
point to say that you're redistributing more than just connected.
Anyway, maybe I'm just reading too much into it...
And btw, I do understand and completely agree wrt the benefits of
"bending the rules" on ospf implementations. My years at cisco,
wellfleet and others have taught me that well.
Thanks,
Chris
> -----Original Message-----
> From: James Rushing [mailto:rushingj@swbell.net]
> Sent: Wednesday, June 06, 2001 10:30 PM
> To: Chris Whyte
> Cc: cisco-nsp@puck.nether.net
> Subject: Re: [nsp] OSPF not distributing 1 interface
>
>
> 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