Hi all,
I have few APs which are connected to Central location, Central service. Now I have this setup, so I need to upgrade it. Can you recommend me what to do? Whato to add, how to connect, via switch or...?
Thx

Maybe sameone can recommend me some good book or article about this topic. Thx

No response...
All gurus are on vacation

Anyone...?

You're asking a very generic question that - in my opinion - is impossible to answer. What do you want to upgrade? What does 'upgrade' mean to you - buy new equipment, or make the existing equipment perform better? Why do you feel you need to upgrade? What is the actual business or design goal you're after? How many users are these devices supporting? What are those devices? How are they currently connected? What versions are they running? What services do they provide, and to whom?

If you ask a proper, well thought out, detailed and specific question then maybe you'll get some replies.

http://catb.org/~esr/faqs/smart-questions.html

Well for a non-specific question and a design opening problems that will cause quite a few headaches over time.

http://www.ciscopress.com/index.asp

Also your drawing does not show yours APs, you are only showing your central location, is your problem at the central location? or where?

I dont think your heading or captions relate to the problem you are trying to solve. You can go through this! http://forum.mikrotik.com/viewtopic.php?f=2&t=45259

Hi to all. I'll try to make more sense to my central location picture. I heve lots of access points connected to my "MT hotspot" router at central location via EoIP tunnels. All authorization is done on that router. All network outside central location is routed with OSPF and there I don't have any problems. Neither I have problems in my central location, but I think that it can be optimised. I have around 1000 users (100-200 mbits od traffic) and want to make central location more scalable and redudant. As you can see from my current setup, all data is going trought central router multiple times. This is my critical point and it is used more then it should be. Now I want to change data flow to minimize impact on one router. Beside that now I have only hotspot users, soon I'll expand my offer to PPPoE and business users with static IP's.
Example:
User request http://www.google.com web page.
1. Request is coming trought "MT router" to "MT hotspot" router over EoIP tunnel.
2. Then from "MT hotspot router" via "MT router" to Proxy
3. From proxy via "MT router" to "MT gateway"
4. From "MT gateway" replay is going trought "MT router" to proxy
5. From proxy via "MT router" to "MT hotspot"
6. From "Mt hotspot via "MT router" to user over EoIP
* All names of routers and servers are from picture from first post

My goal is to reduce packet flow over "MT router", to add more routers (if needed) for redundancy and to make central location expandable due future requests. So, my original question was what to do with current setup, where to put new routers, should I put my proxy, web and other servers on switch etc...

This is my idea how to put it.. Please comment, give ideas,,, I'm new to network design (reading some Cisco books to get more ideas about this topic) and I need push in right direction. Thx to all.

That's much better information. If you're good with buying and reading some books (which I'd recommend) I'd suggest "Top Down Network Design" from CiscoPress. Ignore the vendor specific information, the ideas in the book are excellent and apply to any network.

If you are looking to be scalable I would recommend the classic three tier access-distribution-core model. Each router that customers connect to directly is an access router. Multiple access routers connect redundantly to two each distribution routers. The distribution routers connect to your two core routers redundantly. Then introduce an ISP zone with routers connecting to the Internet, redundantly linking back to the core.

The most important idea for the core is that it is simple. It consists of high speed links and high speed routers that are designed to route packets as fast as possible. Any security to/from the Internet is handled on the SP (service provider) edge by that dedicated router. The core doesn't have to inspect packets, it just routes them. The core also doesn't have to secure customers, that security is run on the access routers (or, in the case of EoIP tunnels to a Hotspot, on the Hotspot router).

By now you're wondering how this scales better. You can run - for now - your services in the core. Your proxy server, web server, and RADIUS servers connect directly to the core routers as central services and be used more or less like they are now. If the load becomes too big you simply install one proxy server, web server, and RADIUS server per distribution pair of routers. Now every access router (and its customers behind it) use those services within their distribution block, and that traffic doesn't have to traverse the core at all. When you're bringing up more access routers you introduce new distribution blocks with two routers each that connect to the core, and replicate the services (proxy, Hotspot, RADIUS) - though you could argue that RADIUS is a network global service that doesn't take much traffic and should always be provided off of the core for truly central user administration; you can introduce proxy RADIUS servers per distribution block that talk back to a central database backend for users.

This model scales extremely well, and is very commonly used in large campus designs. It helps to think of this as a campus, in fact. Each distribution block is a house on a campus. The houses contain in their basement a couple of big redundant routers that route all traffic for the building to other buildings via the core. The houses also have smaller routers per floor that users connect to. The core connects the different buildings to one another, including one (or more) building(s) where the campus connects to the Internet. If you've got more wireless/wired users coming in and a distribution block and its services are getting overloaded it's equivalent to a building on the campus being full. The obvious solution is to build a new building (a new distribution block) and move users into the new building, which contained in itself can provide all the services they need.

Once you've got your network built this way bringing up new distribution blocks is fairly easy. Just make sure you get your IP addressing right - ideally you want to be able to summarize each distribution block in the core so that there's just a few, simple routes.

Again, the book I recommended goes into this design in great detail.

That's much better information. If you're good with buying and reading some books (which I'd recommend) I'd suggest "Top Down Network Design" from CiscoPress. Ignore the vendor specific information, the ideas in the book are excellent and apply to any network.

If you are looking to be scalable I would recommend the classic three tier access-distribution-core model. Each router that customers connect to directly is an access router. Multiple access routers connect redundantly to two each distribution routers. The distribution routers connect to your two core routers redundantly. Then introduce an ISP zone with routers connecting to the Internet, redundantly linking back to the core.

The most important idea for the core is that it is simple. It consists of high speed links and high speed routers that are designed to route packets as fast as possible. Any security to/from the Internet is handled on the SP (service provider) edge by that dedicated router. The core doesn't have to inspect packets, it just routes them. The core also doesn't have to secure customers, that security is run on the access routers (or, in the case of EoIP tunnels to a Hotspot, on the Hotspot router).

By now you're wondering how this scales better. You can run - for now - your services in the core. Your proxy server, web server, and RADIUS servers connect directly to the core routers as central services and be used more or less like they are now. If the load becomes too big you simply install one proxy server, web server, and RADIUS server per distribution pair of routers. Now every access router (and its customers behind it) use those services within their distribution block, and that traffic doesn't have to traverse the core at all. When you're bringing up more access routers you introduce new distribution blocks with two routers each that connect to the core, and replicate the services (proxy, Hotspot, RADIUS) - though you could argue that RADIUS is a network global service that doesn't take much traffic and should always be provided off of the core for truly central user administration; you can introduce proxy RADIUS servers per distribution block that talk back to a central database backend for users.

This model scales extremely well, and is very commonly used in large campus designs. It helps to think of this as a campus, in fact. Each distribution block is a house on a campus. The houses contain in their basement a couple of big redundant routers that route all traffic for the building to other buildings via the core. The houses also have smaller routers per floor that users connect to. The core connects the different buildings to one another, including one (or more) building(s) where the campus connects to the Internet. If you've got more wireless/wired users coming in and a distribution block and its services are getting overloaded it's equivalent to a building on the campus being full. The obvious solution is to build a new building (a new distribution block) and move users into the new building, which contained in itself can provide all the services they need.

Once you've got your network built this way bringing up new distribution blocks is fairly easy. Just make sure you get your IP addressing right - ideally you want to be able to summarize each distribution block in the core so that there's just a few, simple routes.

Again, the book I recommended goes into this design in great detail.

Fewi, I forgot to say thank you... So, Thanks you!