[c-nsp] OSPF NSSA Question

[Dan Armstrong]

An update:

Again, thanks to all who have replied, this discussion is invalueable to me.

I spent much of the night re-implementing my design with EIGRP.

It's stub behaviour is much more like I expect.... 

I add:
ip summary-address eigrp 100 0.0.0.0 0.0.0.0 5
On each interface of the 6509 facing an access router to advertise the default 
route down.  Each access router is setup:


T1C-2.902.1iw2#sh run | beg eigrp 100
router eigrp 100
 network <blahh> 0.0.0.0
 auto-summary
 eigrp stub connected static summary
 no eigrp log-neighbor-changes


I am redistributing static/connected (with appropriate route maps of course) 
to get the customer routes into EIGRP, and routes from access router 1 do NOT 
show up in access router 2.  Perfect!

However I have run into a little gotcha....   I sort of oversimplified my 
design a bit for clarity.  Each 3550 is actually hung off of 2 6509s.  Each 
GigE link spans the two 6509s, and goes through a 3550.  My problem now, is 
that there appears to be no way to stop the 6509s from neighbouring with each 
other over the gig links (of which there could be a hundred or so)....  

I could bump up the costs, but it would be nice if there was a clean way to 
tell EIGRP to "F-Off don't neighbour with this guy"...


After some sleep tonight, I may re-implement it again with RRs & BGP to see 
how that works out.

Dan.





On Monday 04 October 2004 02:44, Jay Hennigan wrote:
> > I don't think you can apply a distribute-list against an OSPF neighbor,
> > can you?  This would violate the technical requirements for OSPF
> > operation.
> >
> > I thought that one could only apply distribute-lists against
> > redistributed protocols.
>
> You can filter OSPF inbound since 12.2(28)S and 12.2(15)T
>
> http://www.cisco.com/en/US/products/sw/iosswrel/ps1829/products_feature_gui
>de09186a008012db77.html  (watch wrap)  or http://tinyurl.com/5gw8v
>
> There is a distinction between the LSA database which must comply with
> the OSPF technical requirements and the IP routing table which does not
> need to match the LSA database.  The URL above addresses that.
>
>     " Users can define a route map to prevent OSPF routes from being
>       added to the routing table. This filtering happens at the moment
>       when OSPF is installing the route in the routing table. This feature
>       has no effect on LSA flooding. In the route map, the user can match
>       on any attribute of the OSPF route. "
>
> So, it looks like indeed, on his access routers, he can if he chooses
> filter all but the default route from OSPF from getting into the routing
> table.  So the answer to the original question is yes, you can prevent
> the customer routes from other routers in your area from showing up in
> the routing table of every access router.  Seeing as those customer routes
> will all have the same next-hop of the distribution router anyway
> (different VLANs from each access router back to distribution), doing this
> shouldn't blackhole one customer from reaching another.
>
> Whether having 100 access routers and the distribution router all in one
> area or splitting them up is a better design, or whether OSPF is even
> the appropriate protocol for this application are still open to debate.
>
> --
> Jay Hennigan - CCIE #7880 - Network Administration - jay at west.net
> WestNet:  Connecting you to the planet.  805 884-6323      WB6RDV
> NetLojix Communications, Inc.  -  http://www.netlojix.com/
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/