01-05-2011 11:56 AM - edited 03-06-2019 02:50 PM
Can I solicit some expert help on an OSPF design issue.
Core net: 10.0.0.0 /22
Remote nets:
10.10.0.0 /22
10.10.4.0 /22
10.10.8.0 /22
.
.
.
10.10.192.0 /22 - so far and growing
No remote office has more than 200 hosts presently, but /22 allowed for growth.
10.11.0.0 /31 being used for links to core.
Should I have a separate area for each remote net or all in one area?
Should the link between the core and each remote be in area 0 or the remote area?
I'm running all remotes as totally stub at present.
Currently using a Cat3560G with IPSERVICES at core.
It has needless to say 48+ VLANs and SVIs at present plus one trunk to the metroethernet's Cat6509.
I have to trunk to the metro provider, but am wondering how large I can scale the 3560G.
What is a a better solution?
Thx
Solved! Go to Solution.
01-05-2011 01:11 PM
I understand from your description that you have 48 sites now, and are continually growing...right? If so, are you going to be growing to somewhere outside your metro area? How large do you think you're going to get?
I would think that for your local metro sites, I would keep them as 1 area...but probably not area 0. I would also replace that 3560 with a proper core switch... I would definitely not make each of these small sites in to their own area. Now, if you had a single large (20+ L3 devices, and 1000+ users) site or datacenter that you add, then that would possibly be an exception.
I probably also wouldn't add too many more sites on to your metro E cloud either and have the carrier create another. If for no other reason then to give you some redundancy.
HTH
01-05-2011 01:11 PM
I understand from your description that you have 48 sites now, and are continually growing...right? If so, are you going to be growing to somewhere outside your metro area? How large do you think you're going to get?
I would think that for your local metro sites, I would keep them as 1 area...but probably not area 0. I would also replace that 3560 with a proper core switch... I would definitely not make each of these small sites in to their own area. Now, if you had a single large (20+ L3 devices, and 1000+ users) site or datacenter that you add, then that would possibly be an exception.
I probably also wouldn't add too many more sites on to your metro E cloud either and have the carrier create another. If for no other reason then to give you some redundancy.
HTH
01-05-2011 03:12 PM
So you would recommend instead of:
!
interface vlan2
ip address 10.11.0.1 255.255.255.254
!
interface vlan3
ip address 10.11.0.3 255.255.255.254
!
interface vlan4
ip address 10.11.0.5 255.255.255.254
!
router ospf 1
area 2 stub no-summary
area 3 stub no-summary
area 4 stub no-summary
network 10.11.0.1 0.0.0.1 area 2
network 10.11.0.3 0.0.0.1 area 3
network 10.11.0.5 0.0.0.1 area 4
That I do this instead:
router ospf 1
area 1 stub no-summary
network 10.11.0.0 0.0.0.255 area 1
Thx
01-05-2011 07:50 PM
Yes, I would make all the sites in to 1 single area. I think I would still add each network statement for each PTP link, or maybe do it in blocks...otherwise you're limiting yourself. Say that you add a second datacenter or DR site at a colo that is also in the metro area. You may not want that to be in area 1, but given that you've added in you're entire alloted PTP subnet to area 1 you're kind of in a bind.
Just as a general rule, I like to know specifically every interface that will be running the protocol, and that they only run it when specifically configured to do so. It does add config, but in this case I think it's worth it.
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide