9 Replies Latest reply: May 3, 2012 10:44 PM by Bradford Chatterjee (CCIEx2/CCDE) RSS

    OSPF stub/NSSA areas...why bother?

    Greg, CCNP, JNCIP

      Cons:

      1. You must configure {stub|nssa} on every router in the area.
      2. You cannot build a virtual link through a stub/NSSA area.
      3. Stub area routers cannot be ASBRs (i.e. redistribute from other proto's).
      4. Stub/NSSA areas add more LSA logic to understand & remember.

       

      Pros:

      1. Reduces LSDB in non-backbone areas.

       

       

      Alternative:

      Let all non-backbone areas be normal.  If you want to reduce LSDB in non-backbone areas, then filter on ABRs.  If you want a default route in non-backbone areas, then configure ABRs to send a default.

       

      Pros:

      1. Extra configuration on ABRs only (to reduce LSDB, send default route).
      2. You can build virtual-links through normal areas if needed, without having to reconfigure every router in the area.
      3. Normal area routers can be ASBRs, without having to reconfigure every router in the area.

       

      Cons:

      1. Some network engineers might be more used to stub/NSSA?

       

       

      As long as ABRs can be configured to send default and filter routes to non-backbone areas, stub/NSSA seem needless and inflexible.  You're guaranteed to have to reconfigure every router in a stub/NSSA area when their shortcomings stand in the way of new requirements.  So why bother w/ stub/NSSA in the first place?

       

      Am I missing some great benefits that can't be achieved w/ normal areas and ABR policy?

        • 1. Re: OSPF stub/NSSA areas...why bother?
          Greg, CCNP, JNCIP

          Another Pro for ABR+policy:

          1. You can selectively allow routes into non-backbone areas.
          • 2. Re: OSPF stub/NSSA areas...why bother?
            Fabrizio Chessa

            Hi

             

            I think that depends from your case:

             

            You imagine a big cloud (internet cloud) with a lot of routes and a lot of networks. Your router has limited memory and you need to "filter" and optimize routing table of this router. In this network you can have some routing protocols (RIP, EIGRP, IGRP, OSPF, IS-IS).

             

            Area 0 need to be contiguous... All traffic from other to other ares must pass through area 0. In this case you can use normal area, stub area (i.e.: area 10) and abr in the middle (at least 1 interface in area 0 and 1 in area 10.

            Now you need to make a redundancy in your network and you make a link from area 100 and area 10. In this case (because area 0 need to be contiguous) you need to make a virtual link and your area 10 cannot be stub area.

            You need to redistribute another routing protocol in area 10 on your ASBR... Area 10 cannot be a stub.

            In a stub area you cannot redistribute connected subnets or other routing protocol but in this area you can summarize your routing table with very few LSA.

            In a NSSA you can redistribute connected subnets or other routing protocol and you can summarize your routing table with very few LSA.

             

            It depends from your actual network tolology and future implementations routing summarizations etc...

             

            Bye

            • 3. Re: OSPF stub/NSSA areas...why bother?
              Greg, CCNP, JNCIP

              Hmm, maybe you only read the subject line, and not my question?

              • 4. Re: OSPF stub/NSSA areas...why bother?
                Fabrizio Chessa

                Sorry!!!

                 

                You're right!!!

                 

                Some network engineers might be more used to stub/NSSA? Probably not (I think)

                 

                So why bother w/ stub/NSSA in the first place? Hmmm... I don't know

                 

                Am I missing some great benefits that can't be achieved w/ normal areas and ABR policy?

                • Distribute list
                • Filter list

                 

                Bye

                • 5. Re: OSPF stub/NSSA areas...why bother?
                  Nuno

                  Hi Greg,

                   

                  The way i see it, these points and more are taken into consideration when you are planning a new infrastructure or optimizing a given network. The best benifits you can have with applying these areas when designing OSPF networks are the compartmentalization and structuring of a network. These can be spread out on multiple things that range from lower memory/processor routers (older routers that can be used a.k.a saving money, instead of buying new ones), better control of LSAs, reduce routing traffic within each area, reduce the convergence time, security by layering and compartmentalize, reduce routing tables, reduce control and data plane.

                   

                  1. You must configure {stub|nssa} on every router in the area.

                          seriously, doesnt seam like a con to me, its a very easy configuration.

                   

                  2. You cannot build a virtual link through a stub/NSSA area.

                          You really dont want to build virtual links in your network, they are strickly a "bandage" for a temporary case.

                   

                  3. Stub area routers cannot be ASBRs (i.e. redistribute from other proto's).

                         This is one of the things we must look for in the design phase, but you can always have a normal or backbone area to have these redistributions and link them to special area types, so no biggy.

                   

                  4. Stub/NSSA areas add more LSA logic to understand & remember.

                         Not really, its a matter of being used to them and have lots of practice, the LSA logic is pretty simple and easier to understand than like having full routing tables being dump in each area, believe me its harder to understand them.

                   

                  "Alternative:

                  Let all non-backbone areas be normal.  If you want to reduce LSDB in non-backbone areas, then filter on ABRs.  If you want a default route in non-backbone areas, then configure ABRs to send a default."

                   

                  It's simple to simplify but these are not options we have to make just by judging what we percieve as simpler to implement and to maintain. we are the guys who in the most simple way must make business run and enable the business to make money with the lower downtime we can and with the best design we can get all towards business so, all those considerations and simplifications are headed towards the business needs so in my opinion we dont have to "reinvent the weel" sort of say.

                   

                   

                  "As long as ABRs can be configured to send default and filter routes to non-backbone areas, stub/NSSA seem needless and inflexible.  You're guaranteed to have to reconfigure every router in a stub/NSSA area when their shortcomings stand in the way of new requirements.  So why bother w/ stub/NSSA in the first place?"

                   

                  Again, if you plan your network right your not gonna have any surprises in the long run, but take in consideration that networks and Cisco equipment (or nay equipment for that matter) have a life span, which is well expected if you follow their design methodologies much like ITIL practices ex. SONA (Cisco Oriented Network Arch), and Cisco Life Chycle (PPDIOO). If you follow these you wont have surprises when expanding your business and take in mind that a OSPF special area type can take a lot of workers in it so expansion is taken into consideration.

                   

                  "Am I missing some great benefits that can't be achieved w/ normal areas and ABR policy?"

                  Yup

                   

                  NL

                  • 6. Re: OSPF stub/NSSA areas...why bother?
                    Bradford Chatterjee (CCIEx2/CCDE)

                    This supposes that the level of configuration for both options is the same, but it really isn't. Configuring "area x.x.x.x stub no-summary" on a couple of routers is really not the same as maintaining prefix and access lists on every ABR. That could turn into an administrative nightmare. Especially when one can login to a stub router, look at the config of the non-ABR, non-backbone router and realize "oh, that's why there's only a default route." Also, the whole point of NSSAs and LSA type 7 is that NSSA stub routers can be ASBRs, so one of your cons is incorrect.

                     

                    IMO, stub areas should be small and isolated parts of your network. They are suited to devices that cannot maintain a large LSDB and don't need to, a branch office router or a customer access device that needs to send dynamic routing information but does not need to receive more than a default route. These are places where you should literally never have to construct a virtual link, and which should only ever require a handful of routes. Could you configure them as normal areas? Yes, but why should you? At least two of the cons don't apply and it really comes down to comfort and convenience.

                    • 7. Re: OSPF stub/NSSA areas...why bother?
                      Greg, CCNP, JNCIP

                      Thanks for the thoughtful reply.

                       

                      Re: "...is that NSSA stub routers can be ASBRs, so one of your cons is incorrect."  Sorry for that; for that particular con I said "stub areas", implying "not NSSA", but I guess I could've arranged my thoughts more discretely for clarity.

                       

                      From the rest, I hear differences of operator preference/training/expectations, but no concrete technical features to be gained by using stub/NSSA that you absolutely cannot accomplish with normal areas and extra ABR config.  Not that the operator is to be ignored; it's important that a network design be easily supportable by one's peers+successors.  But I was really looking for unique technical benefits of stub/NSSA.  It makes me wonder, if stub/NSSA had never been invented, and operators were accustomed to using ABR policy to achieve the same goals as stub/NSSA, if they'd be repulsed by a proposal to introduce stub or NSSA area types?

                       

                      One reason you might want to use normal areas is to be able to change policy in a non-backbone area to satisfy new requirements (i.e. route flooding, virtual links) without flapping existing OSPF adjacencies in that area.

                      • 8. Re: OSPF stub/NSSA areas...why bother?
                        Greg, CCNP, JNCIP

                        Thanks for taking the time.  Some of what I said to Brad also applies, so I won't repeat that.

                         

                        I will respond to "If you follow these you wont have surprises when expanding your business..."  It's been my experience that business requirements drive network design, and business requirements are influenced by market pressures and other non-technical factors.  Surprises happen with the best designed networks.  Change is one of the few constant expectations I have, so I like to be ready - and as far as I can tell, stub/NSSA make it harder to adapt.  But if this is what most OSPF operators are used to...c'est la vie.

                        • 9. Re: OSPF stub/NSSA areas...why bother?
                          Bradford Chatterjee (CCIEx2/CCDE)

                          You are probably correct that there are no strictly technical reasons to use stub areas in OSPF that absolutely cannot be solved with normal areas and enough configuration and oversight (not being able to create an ASBR could be a feature for some organizations with poor change control) but not all network design requirements are technical requirements.