New to actually using OSPF; have question on areas

[suelange]

we have 2  N7k's connected with VPC.  Off of the 7K's we have 24 floors with a stack of 3850's in each floor.  We are not using VPC to the floors, instead each 7K has a single run to the 3850 stack each a numbered interface with PTP link.  For years we've used EIGRP on those point to point links and it is perfect.  For reasons to long to explain I have to cut over to OSPF on the 4th (this friday).  I have next to no time to prepare or plan for this.  I have found several great articles, https://community.cisco.com/t5/switching/ospf-between-n9k-and-3850/td-p/2883074 which is great because it shows how to do*almost* exactly what I want with a single 3850 stack and 9K's.    The difference being itis putting the links for N1/N2 and the 3850 in a single vlan and turning on OSPF on the vlan on 3850; whereas I have numbered interfaces on the n1/3850 link and a different network for the n2/3850 link.  I figure I can do the same thing this article talks about on the physical interface on the 3850, same as I could a vlan, right?   I was about to "lift" that config and adapt it when i realized it was putting the 3850 in area 0, same as it was the L3 OSPF peer link between the N1 N2.

Would I really want to put all 24 floors-worth of PTP links in area 0?  SHould I put each one in their own area?  I want to do this as simply as possible.

I should mention that another facet is, we have 2 WAN routers connected to the N7Ks, one per each 7K.  Again I do EIGRP there and again it has been flawless for over 8 years.  NOW we gotta change them too.

My original plan was to put the OSPF peer link in area 0, along with the 2 WAN routers.  And the floors in some other area, either all in area 1 or all in their own areas.  Are there some downsides to either of these?  If I followed the example I would put the whole world in area 0.  I am concerned about all the LSAs...but I also readily admit I haven't studied OSPF enough to understand it that well.  I never needed to before now since the combination of EIGRP and BGP suited us so well.

Advice, suggestions, comments would be appreciated.

[paul driver · Accepted solution]

Hello

I would like to ask would you be redistributing routes from your wan rtrs into ospf and if so how large of a number would this be?  - If its a minimum amount i would say keep it as simple as possible and seeing though you would only have around 25 ospf connections then using one area (area 0)would be applicable - however if you are expecting a large number of routes to populate the ospf database then i would definitely be looking at stub or totally stub areas.

As for the ospf network types, depending on your ip address format i would say possibly use p2p between the cores and wan rtrs and p2multipoint non broadcast between the core and the access layer closets.( unicast peering using neighbor command) , this network type will allow you to establish a peer to each access layer from the same mgt subnet also each access stack will use the core as its next hop of all routes and you dont have contend with  DR/BDR elections..

Lastly for the migration i would enable ospf process first and manually adjust the administrative distances so it has a higher and less preferred value than eigrp so when you enable ospf on your interfaces and it wont disrupt the current eigrp routing, then as/when your ready to switch over to ospf it would just be a matter of removing these increased distance values and ospf will then take precedence over eigrp and ospf routes will populate routing table, the beauty of this approach is if you experience any problems you only need to re-add the increased the admin values to ospf preocess and eigrp will then again be preferred.

If you dont run into any problems running ospf you could then keep both routing process running for a interim time period before removing eigrp.

Admin distance example:
router ospf x
distance 171 < remove when ready to migrate

p2multipoint non broadcast example:

core 
ip ospf network point-to-multipoint non-broadcast

router ospf x
neighbor x.x.x.x <--access layer stack
neighbor x.x.x.x <--access layer stack
etc..

access layer
ip ospf network point-to-multipoint non-broadcast

[suelange · Accepted solution]

Thank you for your follow up.  Yes, we do take routes from the MPLS links to all the other offices using BGP between the offices, and redistribute today into EIGRP on the N1/N2.  We would have to do for OSPF when we convert. 

There are, at present, about 124 routes coming in from the various MPLS links, into EIGRP on the route table.  Because we do EIGRP with the floors today, there are another 48 routes in the table from EIGRP between the 3850s on each floor and the Nexus1/Nexus2. 

For reasons I can't explain (after I set up EIGRP I took 2 years off) the person here during that time shared all the EIGRP routes on N1/N2  with all the floors.  While the floors sometimes need to access nodes in offices across the MPLS network, they really only need a default route.  They can't get there any way but through N1/N2.   So having 2 default routes of equal weight given to them by either EIGRP or OSPF should be all they need.    But changing  that at the same time we are doing all this other stuff has me concerned.  It's going to be hard to solve if something doesn't work when so much has been changed.

Question:  so for the wans to be PTP and the access floor switches to be p2multipoint non broadcast...does that mean two instances of OSPF one for floors and one for Wans?  Does that still apply when each floor is connected via two different subnets: one between the floor uplink and N1, and a different subnet between the uplink and N2?  Technically they are all a bunch of P2P links.  For example, N1 tp 15th floor is 172.20.1.0/32 while N2 to 15th floor uses 172.21.1.0/32.  (numbers changed to protect the innocent), but you see what I mean.  I thought multi-point was for 3 or more routers in the same network.  I also thought multi-point non broadcast was a cisco only feature, which I can't use because of company standards. These of course could be misunderstandings on my part.  

I love the idea of putting in a higher AD so I can see how the routes populate before I run.   I am still trying to figure out what I should expect to see.  I'm sure it won't be an exact 1 to 1 route (1 OSPF for each existing 1 EIGRP) especially if I set the floors up as stubs.

[Richard Burts · Accepted solution]

If you would like to move to the implementation where each floor has just a default route to the Nexus it would be easy to do this by putting the floors into an area other than zero and making that area totally stubby. If you want to do that and to isolate the floors from each other (if I understand your description correctly then all floors go through Nexus and no floor communicates directly with any other floor) then it would not be difficult to make each floor into its own totally stubby area.

HTH

Rick

[suelange]

Very Helpful in fact. All the floors converge on the two Nexus. They have no way to talk to each other besides going to the Nexus. I don't want to isolate them in the sense that we can't pass traffic...tech support on one floor may have to connect to and help any user anywhere...but I do want to limit the size of the routing table. All I need the floors to know about is the two Nexus to which they are connected. Since OSPF can load balance over up to 8 links by default, the 3850 should see two equal cost default paths (one to each nexus) and load balance by conversation as best as it can. It should then fail to only one route if a link dies. So that sounds like a totally stubby area. As long as the 3850 floor switch is allowed to send knowledge of it's networks to the N1/N2 units we should be golden there.

So it's starting to sound like my design should be an area 0 for the two Nexus and the WAN links, a different area for each floor and those should be set to TOTALLY stubby areas on the 3850's. I'm still working on Paul's reply about use of multipoint non-broadcast network type as opposed to P2P. Neither would elect a DR/BDR, but it looks like P2MP NB would curtail even more traffic as it won't try to discover it's neighbor. Also it looks like traffic would recover from a failed link faster on P2P given the default hello timer. I can change that of course but I hate to fuss with defaults if I don't have to. Technically though the links aren't MP they are P2P so I'm still pondering that bit of info and the right choice to make in that regard.

I appreciate your response. I'm reading fast and furious but all I read just begs more questions !

[Richard Burts · Accepted solution]

I am glad that my suggestion was very helpful. When I mention isolating each floor it was intended in terms of routing updates and not in terms of impacting access. Tech support would still be able to access any device in the network. What I meant was more like this: if you put all floors into a single OSPF area then every floor will receive the routing updates from every other floor. Do you want it to be that when something changes on floor 4 (some subnet went down or some subnet became available) that 3850s on every floor would receive the update, update their Link State DataBase and run the convergence algorithm? If you put each floor into a separate totally stubby area then each floor sends its updates to both Nexus but not to any other floor.

I might suggest that you put the WAN routers into their own OSPF area rather than directly into area 0. 

A question that you might think about is how to treat the links from Nexus to each floor 3850. Do you put those links into the area set up for that floor or do you put those links into area 0? If you put all of these links into the area set up for the floor then you make the Border router be the Nexus (and Nexus will be Border router for every area). If you put that link into area 0 then the Border router is the 3850 and each floor has its own Border router. (when we think about OSPF we frequently have a tendency to think about what area for the Nexus and what area for the 3850. But the area membership is not per device it is really per link. So one device is going to have membership in 2 areas. Choosing whether the link Nexus to 3850 will belong to area 0 or to the floor area does move the assignment of Border router to one or the other.) You know your network and can decide whether you think it is better to concentrate Border router processing in the Nexus or to distribute it to the 3850. My personal preference would be to distribute it to the 3850.

If I understand your description correctly there are 2 separate routed links between 3850 and the Nexus (2 separate subnets per floor). If you decide to implement the point to multipoint NB then it will require significant reassignment of addressing since all of the 3850 addresses will be in a common subnet. And I believe that this pushes you into the model where all floors belong to the same area. I would prefer to keep the separate subnet per floor and be able to do totally stubby per floor. And I do not believe that election of DR/BDR per link is a big deal.

I am sure that there will be more questions. Don't hesitate to ask them.

HTH

Rick

[suelange]

This is fantastic, info.  I can't thank you or Paul either one enough!  I'm going to chew on this for a while and make sure I'm comfortable then I may have more questions.  Thank you for helping me!

[paul driver · Accepted solution]

Hello

Thank you for sharing this additional information -  
I would say given what you've have explained that each floor wont be a transit for any other and that you are redistributing bgp prefixes I think it would be beneficial to go down the a totally stub area for each access floor, this will provide  and advertise only a default route for each opsf peer for each access stack towards each NX-OS switch, From here you can apply a simple ospf interface cost on the designated least preferred default route be it via N1 or N2  if you deem it applicable.

As for the network types, As i stated earlier it depended on your current ip addressing now if you are saying that you have two  different /30 subnet for each floor then a just using a P2P ospf network type between NX-OS and the Access layer would be fine.

Lasty as for the Higher AD for migration - basically you wont see anything populated into the ospf until you remove the distance values but you will have all the ospf adjacencys up and running with the interface costs applied so then it would be matter of initiating the migration and testing.

The above is my own personal view on a suggested migration approach based on what you have shared with this forum, I hope and sure others will post their own thoughts as well and from all that you will be able to be succeed in your forthcoming migration

Happy New Year @suelange

[suelange]

thank you!  Indeed you have been very helpful! as I stated above I got a lot now to think about.  I'm going to study a bit more and see what else I come up with.  When I'm sure I've got  good plan I may ask this forum to review for 'gotchas'. seeing as nexus appears to configure OSPF a bit differently.  I found a good link that compares the Nexus ospf command set to the IOS version.  that has been helpful but I still have some gaps.

[suelange]

Thanks to everyone who has provided me with ideas. I've come up with a design, which may be more complicated than need be, but looked pretty simple. Our floors have about 5 networks per floor (workstations, voips, vtc, wireless, and some others, plus their loop backs). All of those networks fall into the 10.2.0.0 range (hypothetically), ultimately. In a GNS exercise, I could not make the floor networks summarize into a single 10.2 route for the benefit of advertising to the MPLS routers, who should then in turn use BGP to redistribute to the offices across the WAN. What I read lead me to conclude I can't summarize unless I am an ABR. I may have misunderstood but...hence I did make the ABR be the Nexus devices. They will get about 100 routes from all the floors combined, and they will roll that into 10.2.0.0/16 to provide via OSPF to the routers. I hope. OSPF on the routers will redistribute into BGP...and the rest is magic. I'm going to work this up on GNS3 starting with using EIGRP and then test my migration process to OSPF. But if anyone has time to look at the design and tell me how to improve (or avoid potential issues) again I would be grateful and, Happy New year to all of you! (I do realize GNS3 has its limits starting with the configs don't mimic Nexus but...it's what I have so I will use to at least get comfortable with show commands! :) I have a feeling I will need them! Can I vote all these suggestions as the solution? I've borrowed from them all!!

[Richard Burts · Accepted solution]

I have looked at your diagram and it is a workable design. If all of the floors are in area 3 then you certainly do want the Nexus to be the Border router for the area. My suggestion had been to have an OSPF area per floor. If all of the links 3850 to Nexus are very stable and if all the links on the floor are very stable then it does not matter much whether it is all floors in area 3 or an area per floor. The difference being if there is some change on floor 11 do you want every 3850 to receive the update and run the convergence algorithm?

You are correct about summarization in OSPF. One of the differences between EIGRP and OSPF is about summarization. While EIGRP will let you summarize at any router in the network OSPF will allow summarization only by Border routers for routes in the area and by ASBR for routes being redistributed into OSPF. I see in your drawing that the links in 10.2.1 and 10.2.2 and that makes sense for the P2P links, do you really have 5 user subnets in 10.2.1 and 5 user subnets in 10.2.2? 

It is possible to mark multiple posts as accepted solutions.

HTH

Rick

[suelange]

thank you sir!   You are right, you did say one area per floor.  It's okay to have N1 and N2 both in a single area for that floor, is it not?   Also  no, there are not 5 sets of subnets per floor, per link.  There are the subnets the links are in (2) then 5 'usable' subnets for voice, data, etc, and finally a single subnet/32 for the loopback.  My diagram is confusing and I am sorry for that.

I will mark these solutions.  you have all been so helpful.  They have postponed my maintenance date (just 10 minutes ago) but that means I now have more time to get comfortable with this process.  Much obliged to you all!

[Richard Burts]

You are quite welcome. I am glad that you are finding the discussion helpful. I did suggest an area per floor and from some perspective I do still prefer this. But as I think about it I realize that there are other perspectives that might come into play. I tend to look at questions like this in terms of what scales better. And as networks get larger it becomes more important to isolate different parts of the network. An area per floor does effectively isolate each floor from impacts of changes in other parts of the network. But as I think about it you will have 48 transit links and about 144 internal subnets. This is not really a large network and putting all floors into area 3 should not subject the OSPF Link State DataBase to all that much volitility. Some people would say that putting all floors into area 3 simplifies the network and if you like that feel free to go with it.

If you do an area per floor it is certainly ok to have both Nexus links in that area.

Glad to know that you now have more time to work with this and to get more comfortable with what you need to do. If you do come up with more questions feel free to ask.

HTH

Rick

[Joseph W. Doherty · Accepted solution]

From what you've described, I wouldn't be overly concerned about using just one OSPF area, especially if your Cisco device support Cisco's OSPF's ISPF.

For a single area, it doesn't matter much whether its area 0 or some other number beyond future conversion to a multi-area topology.

I've experience in fairly large OSPF topologies, with Cisco equipment (and Brand X) too. Cisco's OSFP implementations generally have built-in governors (BTW, adjustable - and other optional features, such as ISPF and dampening) that avoid issues with rapid rerunning of Dijkstra's algorithm.