> Here's a curious question on the subject of this feature,
> regarding the network impact.
>
> Under normal conditions, let's say an ISP has the following
> standard OSPF network...each POP is it's own OSPF area, the
> backbone is area 0. Also, let's assume we aren't using NSSA
> (since it's still buggier than hell in large environments)
> and we aren't using stubs of course. Besides, we need to
> know the route to every connected neighbor because some or
> all of them on EDGE routers are running BGP...next-hop
> requirements and all that.
>
> Kind of a no-brainer, but just to set the baseline.
>
> 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.
>
> 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.
>
> So, instead of a type-5 LSA per network, we have a single
> type-1 LSA for all networks.
>
>
> Now, going back to the original type-5 LSA schema, the ABR in
> this case (CORE router) would have to perform its standard
> SPF work (LSA analysis, database insertion, Dykstra, etc.)
> and forward the type-5 on into area 0 everytime a given
> network flapped.
>
> If all of these routes are now part of a single type-1 LSA,
> the ABR has to break that up into it's component networks
> first, then do the standard SPF stuff, and then he has to
> create an individual type-3 LSA for each network to pass them
> to area 0.
See above. It won't work like this...
>
> What has the ISP really gained by using this feature?
Nothing. Especially since it won't work like you explained, yet again.
Sorry to sound like a broken record.
>
> They haven't reduced the number of LSAs in the backbone,
> they've just shuffled a lot of them from type-5 to type-3.
Which won't happen.
>
> What extra burden (if any) is placed on the DR in a
> multi-access network environment under this configuration?
Can't answer this question since all of the above is not true.
>
> My goal here is to find justification for using this
> feature...someone obviously though it important enough to
> request it, but I'm just not seeing the benefit, certainly
> not in a large OSPF environment.
Well, put it this way. You supposedly described an optimal machinery,
that doesn't exist, yet you still didn't find any benefit to using the
command. The reality is that it's much uglier than you described.
Thanks,
Chris
>
> -J
>
>
>
>
> Faraz Shamim wrote:
>
> > This feature was added via CSCdj77319. Documentation
> > can be found in the release notes of this bug at:
> >
> >
> http://www.cisco.com/cgi->
bin/Support/Bugtool/onebug.pl?bugid=CSCdj7731
> > 9
> >
> > Support for MSFC was added through CSCdr11394.
> > Relase notes are at:
> >
> >
> http://www.cisco.com/cgi->
bin/Support/Bugtool/onebug.pl?bugid=CSCdr1139
> > 4
> >
> > The problem mentioned in this e-mail that why a new
> > interface added comes up as "no passive-interface..." is
> fixed under
> > CSCdr09263. Release notes are at:
> >
> >
> http://www.cisco.com/cgi->
bin/Support/Bugtool/onebug.pl?bugid=CSCdr0926
> > 3
> >
> > Faraz Shamim
> > Cisco Systems Inc.
> > sshamim@cisco.com
> >
> > >
> > > Dave Spencer <dspencer@nightfall.forlorn.net> writes:
> > >
> > > > So *my* question is, when I use "passive-interface default" and
> > > > then later create a new interface in the RSM for a new
> VLAN, why
> > > > does a "no passive-interface <new-vlan-interface>" show
> up in my
> > > > OSPF configuration? Cutting and pasting here from an RSM in
> > > > question:
> > >
> > > This undocumented 'feature' appears not to be present on the MSFC
> > > (presumably someone had got round to fixing it by then,
> in much the
> > > same way as 'no ip route-cache cef' appearing in the
> configuration
> > > of newly created VLANs).
> > >
> > > M.
> > >
>
>
This archive was generated by hypermail 2b29 : Sun Aug 04 2002 - 04:12:40 EDT