5

I'm thinking about doing a routed access layer datacenter design with OSPF.

  1. couple TORs switches from every rack connect to a pair of core switches via l3 links
  2. every rack is it's own totally stubby area. About 200 racks, total about 400 switches. TORs are either 4948s or nexus 3k
  3. Core Acts as ABRs. Cores are chassis bases high end boxes (nexus 7k, or juniper 9200 etc)

The idea is to just have a default on the TORs and keep the LSA database small, hence unique area per rack. Should i be concerned about ABRs (cores) generating that many type 3 LSA for different areas?

  • Thank you for asking; could you rephrase the question without an open-ended poll for "if anyone has done a similar design...". I suggest adding your own personal fears and concerns for us to respond to; without this, the question is off-topic since it is a Poll – Mike Pennington Apr 11 '14 at 13:15
  • edited. I'm really just trying to find out info from people who may be running similar designs – iosjunos Apr 11 '14 at 14:20
  • I need to edit the poll out...looks fine otherwise. FYI polls are welcome in our chat room but you need 20 points – Mike Pennington Apr 11 '14 at 14:21
  • Why do you feel the need to divide it up into so many areas? Your design doesn't offer any advantages (that I can think of) over keeping things at L2, using per-rack VLANs, trunking data back to the core, and letting the core handle all routing. – Avery Abbott Apr 11 '14 at 15:27
  • 1
    Also, if you run ESXi and want to be able to vMotion from rack to rack, you'll be out of luck if you don't have the ability to trunk VLANs to different racks. Even with physical servers/devices, if you ever need to shift something to a different rack, you'll need to update DNS, IP addresses, etc. From my point of view, you're setting yourself up for a lot of hurt. – Avery Abbott Apr 11 '14 at 15:30
5

I would strongly recommend moving to an OSPF/iBGP design for something of this scale, with the core switches acting as BGP route reflectors. BGP has so many more administrative handles for tinkering with routes over OSPF, allowing better scale and filtering.

If you scale to the point that you have more networks than your ToR switches can program into CAM (unlikely if each is a different stub), you run into issues. Each additional zone is more CPU load on your ABRs (core switches) as well.

Have one OSPF area 0, with all loopbacks and router-to-router links in it. Then setup iBGP sessions between your cores and ToR, advertising default-only to ToR, and redistribute connected/static routes on ToR into BGP.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.