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.
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.
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.
What has the ISP really gained by using this feature?
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.
What extra burden (if any) is placed on the DR in a multi-access network environment under this configuration?
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.
-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=CSCdj77319
>
> Support for MSFC was added through CSCdr11394.
> Relase notes are at:
>
> http://www.cisco.com/cgi-bin/Support/Bugtool/onebug.pl?bugid=CSCdr11394
>
> 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=CSCdr09263
>
> 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