Trying to understand and modify Cisco Router RV345

You have two options.
1. Use multiple networks. One network for APs and cameras, another network for mobile devices, etc. This way you can get some IP addresses. 
2. Supernetting - you combine multiple networks into one (for instance 192.168.4.0 and 192.168.5.0).This might be a better option but it depends on how many IP addresses you need.

Then I want to setup VLAN's on Cisco Router for different subnet they have.  Is this possible?

Sure, this is possible. 

Why use the Cisco router behind the Sonicwall? I'd just remove it. Saying that, you could just use the Peplink if you want to simplify things. It will support 16 VLANs so you could just connect a switch to it to add port capacity.

2 questions

1.  Using multiple network may create problem.  Employees on mobile devices are handheld scanners that need to access the AP to communicate and perform tasks.  Creating multiple network may not work unless I modify routing table for various networks.  Am I correct?

2.  Using Peplink only and no Cisco?  Peplink is being used as load balancer between ISP should one go down.  Is cisco router more powerful and feature enabled than peplink?  If so, I can only use peplink to load balance and let cisco do all other routing.  Basically using peplink as a pass-through.  Correct?

3.  I am planning on using Sonicwall firewall to perform all firewall rules and traffic management

What are the suggestions?

1. You are running out of IP addresses. Extending the range (no matter which way you choose) requires additional configuration. And if you configure it correctly, your APs can be in a different network. I don't see any problem here.

2. 3. I am not much familiar with SonicWall or Peplink so someone else should answer these questions.

The Peplink is a capable device. It will do most of what the Cisco router will do - most likely everything you need. If you were to put a router behind it you would need to add routing configuration which is probably unnecessary.

The scanners don't need to access the AP usually - it just bridges traffic to the wired network, so as long as the scanners are on the right part of the network it doesn't matter which part of the network the AP management sits.

ok. but peplink will be sitting outside of firewall. is that a good idea to have all routing and dhcp ip on it?  honestly that doesn't add up to me. we are basically going to be vulnerable to outside world.

The Peplink has firewall capability. It's basic, but if that's all you need it will do fine.

Think about what the Peplink is doing. It is routing and load-balancing internet connections. The IP addresses from your ISPs will terminate at the Peplink so it will be doing NAT. You could run the Peplink in routed mode for each ISP link if you have a range of IP addresses from each, but if you don't you can't, so you have to run NAT at the Peplink. That means it has to do the firewalling too.

If you don't want the Peplink to do inter-VLAN routing for your LAN clients, sure, put a router behind the Peplink to do that. You could even do that on a layer-3 switch, which would probably be better.

DHCP doesn't have to be on the Peplink. In fact it doesn't even need to run on a router. It is usually running on a server in an enterprise environment.

we have no server. so dhcp has to be done inside the firewall. was planning on using Cisco router to do dhcp via VLAN inside firewall. want to utilize sonicwall as it has been purchased

in that case you probably want to create vlan interfaces in the sonicwall, and let it handle all the routing and setup adequate rules. ... you have no need for an additional router and it will only make your work more complex.

So you bought a Sonicwall that you didn't need, and now you want to implement a difficult network because you bought it. Ok.

Put the Sonicwall in routed mode (no NAT) behind the Peplink. You'll have to NAT at the Peplink or you won't be able to load-balance the traffic across the ISPs. This makes the firewall on the Sonicwall pretty useless though from the internet.

(skullnobrains) - I have been debating on that suggestion.  I don't mind using firewall to handle layer 3 and rules.  so what would the setup look like?

(someone) - based on your suggestions, I don't mind simple network, if I can retain peplink and sonicwall and use cisco router as a switch, if i really have to.  honestly, I don't have to use cisco whatsoever.  

Can you share youre topology in a drawing. then we can help you redesign. screaming that you can remove all kinda devices is not the way to go.

Network Diagram.pdf

What does the peplink do, you have 2 ISP's is this device doing bgp or something. ?

load balance.  comcast is primary and active.  at&t is on standby

so it does not do load ballance, but fail over. what kind of sonicwall do you have ? the cisco router what type is this ?

Sonicwall TZ570.  Cisco Router RV345

the last question what kind of switches are you using ?

They are all Netgear managed PoE switches (24 port, 48 port)

But we do need peplink for failover.  We have no servers in-house.  Business is dependent on active internet service

The sonicwall will also do the failover for you, you can setup 2 interfaces in the wan side. and set the primair. and preempt on the interface, when it fails, the box will do a fail over.

keep it simple and clean.

OK.  So configure sonicwall with failover, vlan, dhcp, nat, and firewall rules?

Yes, build it like this. it will give you 1 point of administration. and makes youre life so mutch easyer.

I will take your suggestion but I won't be able to implement this and test it for at least 3-4 weeks out.  Once I know it works, I will come back here and update as to how my setup went.

Thanks

i am globally with benjamin : the peplink is indeed useless as well. the router had better be used as a regular switch.

note that this whole setup lacks redundancy. i feel more comfortable with a single device being a spof rather than a chain of 3.



you can also consider plugging all the switches directly to the sonicwall if possible.

if you do not have enough ports on the sonicwall, you can connect some of the switches and the sonicwall in a ring using stp, but note that this is more like an early 2k design. and you can also plug the uplinks in dedicated vlans on the core switches. something we don't really like to do for essentially cosmetic reasons, but indeed a frequent setup nowadays.

... or plug exactly 2 switches on the sonicwall and use them as redundant core switches. if you have 2 or more stackable switches, you had better rely on lacp than spanning.

how many ports does the sonicwall have ? how many switch ports ? are the netgear switches stackable ?

stp ring wont work, the sonicwall does not do spanning tree. there is an option the make failoverlinks

actually i was unsure about than and googled it before posting. apparently most models do... maybe i missed something.

anyway, totally agreed stp is more like a failsafe than something you want to use nowadays if you have another solution. if the netgears are stackable, or if that sonicwal features a bunch of switch ports, i feel way more comfortable with lacp.

just curious:  can i use peplink as a passthrough and keep it ONLY for internet failovers using the static ip that we have and let sonicwall do everything else including nat?  i would feel more comfortable if this can be achieved.  I don't mind removing cisco out of the network topology.

yes. i am unsure this works in passthru mode on that specific piece of equipment but you most definitely can forward all or some ports to the wan address of the sonicwall and apply a second nat layer so you do not need to bother with routes.

that said it is rather useless security wise and adds one extra spof. it is also more complex to setup, very likely the sonicwall handles the failover more graciously and additionally will let you use both links at the same time should that be useful later on.

Ok.  Thanks.  Just trying to get some assistance here with sharp minds in this thread.  I will look into all options as I get close to starting this project.

Why dont you connect the backup line first to the sonicwall. test the fail over and, then move the primary connection.
the config is not that hard. to do. if you need help, we can have a teamvieuwer session and config everything.

That's a very nice gesture Benjamin.  Yes, I will post any attempts I make and post any developments.  Most of this work has to be done on a weekend, especially Sunday.  LOL.  If I stumble badly (hopefully not), we can initiate the session.  Thanks 

working in the weekend is normal. the nework i maintain has 198.000 users. and it's a 24/7 company. so everything is in the evening/night and weekends. ;)

Mind blowing.  Yes, I am used to working weekends and evenings too but here, they have 2 shifts Mon-Fri 5 am to 11 pm and Saturday 5 am to 1 pm.  I only get part of Saturday and all of Sunday's to tinker with any network concerns.

The Peplink will do your internet load-balancing and failover better than the Sonicwall. If that's important to you, leave the Peplink in. If not, just remove it and use the internet in a failover setup straight from the Sonicwall.

If you use the Peplink in passthrough mode, just take it out.

Had submitted a ticket to peplink last week and got a response today.  

According to peplink tech support, peplink 20 can definitely be configured as internet failover ONLY and let firewall do the rest.    

This is the setup per peplink
peplink setup.pdf

do you own 210.10.10/24 ? if you do not. don t do this. use local address space.

such issues is one reason why double nat is going to be a pain to maintain

understood.  sharing what peplink sent.

i kinda recollect this must be a reserved address space but anyway you are both overcomplexifying the network and introducing a useless spof for no reason.

what about the switches stackability ?

(skullnoibrains) - the ip scheme in the diagram has nothing to do with my address space.  peplink has this in their forum and it is just an example.  

the answer is it can work but is mostly pointless, than.

imho, the only case when multiple layers of nat is actually useful is to deal with routeless hosts or elsewhere routed hosts either for security or technical reasons ( such as overlaping lans ). other than such setups, there is little point.

Got it

First thing, don't worry about a SPOF. You will always have one if you use the Peplink anyway, and again if you put the SonicWall behind it. The only way you'll get around that is with 2 internet routers, 2 switches, then 2 Peplinks, 2 more switches, then 2 SonicWalls...

Second, you CAN set up the Peplink in the way your link describes, but ONLY if you have your own IP address space. If you don't you will have to use private addressing and therefore NAT on the Peplink. If your ISPs give you some static IP addresses you may be able to do load-balancing via the Peplink to an extent but it won't be worth using. If you NAT on the Peplink you DON'T need to double-NAT.

1 spof is better than multiple ones

agreed double nat is useless at best

i wouldn't have thought do double nat anyways as it would make no sense and make things more complicated and unmanageable

Keep by the idee to remove all the extra devices, and dont do double nat.

and see whether you can connect the switches directly to the fw, preferably using double links with lacp so you minimise thf number of spofs

great.  we all agree Peplink to be failovers between ISP and NAT, and everything else on Soniwall (VPN, DHCP, VLAN, Rules, etc, etc) ?

Cloud -----> ISP's -----> Peplink -----> Sonicwall -----> Switches ----------------------------------------------

i disagree. the peplink in merely a useless device and a spof. and i am pretty sure benjamin said the same thing

why would you mention double NAT in earlier chat if you disagree above.  LOL.  Double NAT was in the conversation because 2 devices were mentioned.  Peplink and Sonicwall.  Did anything change?

As far as I am aware, the TZ-series don't support LACP, or any other form of link-aggregation.

It seems to me like you already know what you want to do, but you're just looking to get someone to back up your plan? You purchased a Sonicwall without any real design and now you are having to justify why you spent the cash? Is that an accurate assessment?

If I'm correct, just take the Peplink out and do internet failover or Policy Routing with ECMP on the Sonicwall. The Sonicwall won't do load-balancing like the Peplink will, but it doesn't sound like you want that anyway.

FW was bought not just for short term but long term solution as we will be moving in 6-8 months. Sorry but I have pre-planned its use. But for immediate need I am trying to understand and fix the issue.

Obviously FW has specific purpose and Peplink has specific purpose. I don't have to use both but I am hoping with suggestions, we find common ground to help me.

If both in place, that would be wonderful. If not, I can drop one and go with the other.

we are in Opinion chat, therefore looking for various opinions.

Ok, I appreciate your honesty.

So maybe don't look to change anything too drastically yet - keep the Sonicwall warm in a cupboard for a few months and just sort the issue with IP exhaustion. You don't need to install the Sonicwall in order to do that. Let's take a step back...

You have a subnet which is running out of IP addresses. As Hello There said right at the top of the thread, the obvious solutions to this are:

1] Increase the subnet size, or
2] Move some devices to a new VLAN/subnet.

Given your current IP schema uses 192.168.0.0, 192.168.2.0 and 192.168.3.0. Looking at that I would assume that the 192.168.0.0 subnet uses a /23 mask (255.255.254.0)? If so, you can't expand the subnet as you have 192.168.2.0 and 192.168.3.0 already used, so that only leaves option 2.

If, however the 192.168.0.0 subnet uses a /24 (255.255.255.0) mask you can adjust this to a /23 relatively simply and give yourself 256 more addresses.

What isn't clear to me at the moment is what is actually doing the routing, or are all 3 devices (Cisco, Netgear and D-Link) routers set up as home-style routers doing NAT behind the Peplink? Do you have a diagram we can review?

If I am not mistaken, Peplink is doing the NAT.  I will have to take a closer look at it tomorrow.

Ok, I'm interested to know how the 3 routers link to the Peplink and how the routing works.

i merely mentioned double nat as a bad idea in the very first post pertaining that subject as a way to illustrate keeping both devices is quite pointless and as a backup plan if the peplink cannot do passthrough. no change there.

again, you need to remove spofs. the peplink is useless and a spof.

likewise making all the traffic go through a router is pointless if your firewall can be directly plugged to the switches.

stack your switches if you can and use link aggregation. remove useless devices. consider purchasing a secondary identical sonicwall so you end up with an ha pair.

thanks. will update once I make a move. appreciate everyone's suggestion.

NAT is being done on Peplink.

As far as how things are being done or setup, in simple words, it's a spaghetti.  Cables are everywhere.  Apparently network architecture and topology was not properly planned or a priority for whoever set this up.

I wish I can give everyone a simple answer on how things are setup.  In my opinion, it looks like a kid was left alone in network closet to run cables every which way possible to get things up and running.  

For kicks and giggles: 6 wireless ap/routers are in server rack.  Why, I have no idea (your guess is as good as mine).  Which unit is performing what tasks and who is connected to which unit and how, I have no clue.  Maybe one of these days, will send picture.

that could be fun, but all the more a good reason to remove everything that is not strictly necessary.

in this case : you need
- a firewall ( or rather a firewall pair )
- an unknown number of switches depending on what you need to plug. if you have 2 stackable switches, you can start with that.
- one or multiple wireless appliances. if you have multiple ones, i assume they handle different lan segments. ( most older such appliances did not handle vlan segmentation on a single ap )

anything else it quite superfluous and it is obviously a bad idea to bundle users and cameras.

you probably should start by moving stuff one lan at a time.  maybe all cameras. if they only communicate with the wan, they can be moved around without making a mess. it is quite difficult to help you without more context than you can provide.

yes, I know I did not provide more info.  i was not shown this part of closet until this week.  my brain hurts to see the mess.  my heart cries to feel the pain that users are facing with handheld scanner's not able to get access to wireless network 

#1.  i have to do vlan to segment my ip subnet.  i rather have 3 vlan's (192.168.0.x, 192.168.2.x, 192.168.3.x) first assigning vlan ID to ports and connecting switches to each vlan port for  (i prefer to do this on sonicwall?  does this make sense)

BTW:  i see no reason for wireless ap in closet room (netgear, linksys, d-link, etc, etc).  someone here most likely bought various types, on sale, to put together internet (looks like).  there are lot of collision in channels, password issue.  ok.  enough of my frustration.  wireless is a different devil that i am working on, on the side.  hahaha  

it's a warehouse with concrete and brick walls.  wireless signal from small closet will not penetrate this concerete wall to full potential to reach to users on far end of the warehouse.  lol

we have 6 EnGenius AP (it's a business solution ap).  i plan to use these in warehouse for users to use for their handheld scanners, in near future.  

you probably should configure trunks to the switches and allow said vlans on those trunks. and the whole thing over lacp.

keep the gateways on the sonicwall. configure them on virtual vkan interfaces on the lacp interface.

and preferrably do not use 192.168.0 and 1 if you expect to use vpns in the future so you do not end up with collisions with home networks.

lacp?

link aggregation.

if you can stack 2 switches, you gain failover and throughput

would you mind sending me your version of setup in a topology/network diagram?  Thanks

i cannot right now as i am on a mobile phone, but basically

the sonic is plugged to the 2 wan links

2 stacked switches are plugged to a virtual lacp interface on the sonicwall. the link type is trunk and all vlans are allowed.

you create a number of vlan interfaces on the sonicwall on the previous virtual interfaces. these hold the gateways and dhcp

everything else is plugged on these 2 switches, with redundancy whenever possible.

at some point in time, you buy an additional sonic to redund the first one and remove the last SPOF

clear enough ? this is pretty much an abc whitepaper for a reasonably small lan using a star topology

TZ doesn’t do link aggregation, as I’ve already said. Aside from that, the firewall is not a core switchso don’t try to use it as such.

I’d be very careful unless you understand what everything is doing. Don’t change too much too quick or you could end up with a bigger mess than you started with.

if lag is actually unavailable, you'll have to accept spofs. in that case, it might be simpler to simply plug the switches to the firewall. assuming the TZ can handle switching inside a ports group ?

if not you'll indeed need to use a switch as a core switch at the cost of an additional spof.

to be honest, if the TZ can do neither lag nor switching, you are probably better of with your existing equipment.

Spoke to tech support at sonicwall.  per tech support, sonicwall does not do NATing.  However it does have a robust failover similar or better than Peplink.  NATing has to be done either on Peplink or our own routers.

I am definitely keeping sonicwall in my topology.  Now I need to understand the NATing, my network architecture and how everything ties up.   

wow, never used a TZ, but i really thought they had more features and they only advertised the most basic ones. i hope you can at least create firewall rules ^^

honestly, this is no enterprise grade firewall, and you'd probably be better of with an old machine running pfsense for example.

the way i see it, you will end up doing NAT in the peplink, filtering on the sonic, and probably use acls to complete the whole thing on the routers... you're heading towards many SPOFs, and difficulties to maintain the whole thing.

i advise you rethink your strategy. maybe pick a more robust firewall, build one, or do everything in the routers

Sonicwall TZ 100% does NAT. Here's the guide...
https://www.sonicwall.com/support/knowledge-base/how-do-i-configure-nat-policies-on-a-sonicwall-firewall/170505782921100/

I suspect what they were suggesting is that it shouldn't in your scenario, which is what I've said.

If you want to keep the internet failover, you can do that on the TZ. Just get rid of the Peplink and NAT on the Sonicwall - no problem. Install a "core" switch then connect that to the Sonicwall, then hang your access switches off the core. Simple.

Benjamin's post shows exactly what it would look like...
https://www.experts-exchange.com/questions/29198478/Trying-to-understand-and-modify-Cisco-Router-RV345.html#a43182502 

SonicWall TZ570 does not support true NATing like most routers do, but only NAT policy.  The above link might be outdated because my SonicWall interface has no clear options or path to NATing.  

No, your appliance really does support NAT.

I take my word back "some one".  Sorry.  Just spoke to senior engineer at SonicWall because I had some other issue.  He mentioned that SonicWall will do everything that a regular router and Peplink does plus it's a high end security appliance. So basically 3 in 1 (Router, Failover, and Security)

so back to square one : not reason to keep the peplink. you may want to check link aggregation as well just in case. that is quite the standard feature. i suggest you look at the capabilities, be it nat or else yourself. many features might have evolved between versions and it is fairly possible the tz does more than we know.

the one sure thing is the less equipments, the less complexity, and in this case, the less SPOFs since you have only one peplink, only one TZ ( you may want to check whether they can run in pairs. other sonicwalls do for sure ), and your routers probably can be stacked.

If peplink and Sonic, then no need for cisco router.  If only sonic, then no need for peplink either

100% agreed the router should not route if you have a sonic. see my first posts. depending on the number of ports on the sonic and wether it can act as a switch, you may need to use it as a core switch, though

sonic has 6 lan ports, 2 wan ports, and 1 terminal port

and yes, 6 lan ports on sonic can act as switch

then i suggest you use a sonic centric topology : just plug all the needed switches directly to the sonic. let it handle dhcp and routing. pretty much the very first thing we suggested ;)

If I use sonic as the only device to perform all network routing and etc, support engineer suggested that I add Sonic High Availability device which would be a failover device should the primary device fail.  Apparently Sonicwall HA replicates everything in real time.  

This setup would prevent SPOF.  Currently I am running Sonic in a test environment with our backup ISP and drilling into it's features and setups.

yeah, also as suggested

and look into lacp as well. if your hosts have 2 network cards, you can hafe full redundancy.

can your switches stack ?

what do you mean by switches stack?

Can you connect your switches together to make them logically appear as one switch from a management perspective?

Got it.  No my switches are not stackable.

then, just plug all the switches to the sonic and let it handle the WAN links as well.

you can probably use your router as a regular switch if you need more ports.

the wifi routers can be plugged to a switch or the sonic indifferently. better plug most things on the sonic if you have available ports. if the wifi routers support passthru mode, you may let the sonic handle dhcp for the wifi networks but that is not required. with a regular setup, you need to setup a route on the sonic.

I am only going to use Sonicwall for all networking needs.  My 3 Netgear switches have 52 ports all PoE on each.  Therefore I will not have an issue of running out of ports behind Sonicwall as I have 6 LAN ports on Sonicwall.  Only 3 switches will be connected behind Sonicwall.  In the future, if need arises, I can definitely look into other solutions.

I may need guidance on subnetting as I am not very comfortable yet.  I will post this in new topic.  

seems decent, though the setup obviously lacks redundancy. you may want to connect the wireless routers directly to the sonic as well if possible.

regarding subnetting, the setup obviously depends on the needs.
i advise you only use /24 and match the vlan number to the 3rd octet of the ips.
and use only .1 or .254 for the gateways, and reserve a few adjacent ips in each lan for future use.

you would connect the sonic to the switches using trunks so you can create new lans pretty much on the fly as needed

forgot to mention.  it does not lack redundancy because I order sonicwall high availability unit which replicates the configuration and takes over if the production sonicwall fails.

Every part of production sonicwall's configuration gets replicated to high availability sonicwall.  I just have to make sure the physical setup and connections are identical on HA Sonicwall.    

the switches are still a spof, and you may need to negociate with your internet providers if you expect to plug both wan links on both sonics. if you cannot, it seems reasonable to plug one link on each firewall.

start to look good imho : redundancy at the core, simple design, fits the needs...

maybe at least some servers with 2 links can be plugged on 2 different switches. multiple links are rather easy to implement in most operatimg systems.

logic says, connect both wan on both sonics.  only one sonic will be active at a time, anyways.

obviously. if your providers provide 2 links each.

Do yourself a favour and use one switch as a "core". Call it the central switch if you like. Connect the other two switches to it.

Connect the Sonicwalls to the core. Don't connect all switches to the Sonicwall.

If you want to connect both internet circuits to both Sonicwalls you'll need to use a pair of switches between the Sonicwalls and the ISP routers to achieve a decent level of redundancy. Connect one ISP router to one switch on VLAN 101 and the other ISP router to the other switch on VLAN 102. Link the two switches together using a trunk. Connect two WAN links from each Sonicwall to the switches; one link on VLAN 101 and one link on VLAN 102. This can be a trunk from each Sonicwall using a single link if you want, but that removes resilience.

Configure the Sonicwall to do internet failover using VLAN 101 interface as the primary and VLAN 102 as the secondary.

These VLANs are examples, of course.

i see little point in using core switches in this situation. we use core switches when we have multiple firewalls, or not enough firewall ports, or occasionally when some internal flow needs to bypass the firewall. additionally, since the op has no stackable switches, the core switch would become a  SPOF.

adding 2 intermediate switches for the WAN links brings no additional redundancy : you merely move the same issue to the switch layer. the only way to achieve full redundancy would be to make sure the isps each provide 2 links / 2 ports on their router so each of them could be plugged to both firewalls. when isps provide a link and an in-house remotely administered router, this usually comes at the cost of a phone call.

Those are not great scenarios for using "core" switches.

There is absolutely a need to use a core here. Never, never, never connect all of your LAN-side switches directly into the firewall, unless they each do something different. Why would you want to push all your L2 traffic through the firewall? It makes no sense whatsoever.

With the WAN, how do you propose to connect the ISP router to both Sonicwalls? If the ISP routers are SoHo kit with switchports, maybe that's fine, just plug each ISP router into each Sonicwall directly. However, I am making the assumption that they are proper routers, therefore they will present a single link to the CE so switches between the Sonicwalls and the ISP routers are 100% required in order to allow each Sonicwall to see each ISP.

You keep banging on about SPOF. There's sometimes just no way to get around it. A well-designed network can contain many. A badly designed network includes many. An underfunded network also contains many. Work with what you have. We could all say what's the perfect network but unless you have the money and the kit we have to compromise. We know that the Sonicwalls have just been purchased and that HA is possible given there are two units. It would be easy enough to purchase two stackable switches in addition to do it properly and eliminate your SPOF.

Why would you want to push all your L2 traffic through the firewall? It makes no sense whatsoever.

- because the firewall can handle it
- because said traffic can be minimal or even non existent if you decide to use different vlans on different switches even though you may decide to allow inter lan traffic
- because the firewall is redunded while the op does not possess stackable core switches
- because there is no point in traversing one more layer of equipments
- because the resulting topology is simpler

However, I am making the assumption that they are proper routers, therefore they will present a single link to the CE so switches

there is no difference between plugging one cable on each switch of a pair, or one cable on each firewall of a pair : either way, if the corresponding equipment goes down, the link goes down.

it is better to ask the isp to open a second port if possible. in that case, an additional layer of switches iis useless for the exact same reasons.

Work with what you have.

agreed. the op does not have stackable switches nor plans to buy any apparently.

a full redundant switch setup is useless if you are going to plug desktop machines on a single switch, so that part of the network is just besides the point ( on a reasonably small network )

a small number of servers with double links can perfectly handle failover themselves for zero cost by being plugged on two separate non stackable switches

i have been suggesting stackable switches since the beginning of this thread, and revert to other simpler schemas because the op has none. anyway, i see no point in adding a layer of redundant core switches between a redundant firewall layer and a non redundant switch layer unless you are going to plug the servers to the core switches.

Just because you can doesn't mean you should.

Firewall may be able to handle the traffic, but is it a good idea to use it as a switch? No.
You say there's no point traversing more than one layer of equipment, but then you suggest traversing the firewalls for no reason.
If your firewall configuration is broken, how do LAN clients see each other across switches? The topology is more complicated.

ISPs rarely open more than one port on their CE. I know this. I work for a large global ISP as a network architect.

On the one hand you are worried about a SPOF, then you say you see no point adding redundancy. Which is it?

lets agree to disagree regarding the architecture.

btw i also worked recently for 2 major ISPs as a saas architect ;) and i totally agree your suggestion would work...

i see value in adding redundancy to the core, to the wan links, and to the servers, or at least the servers that are not in a replicated cluster. those goals seem achievable with the existing hardware.

i see no value in achieving a redudant setup in edge switches if they only will bare desktop machines that each have a single network port.

the day the network grows, i would recommend buying a couple of stackable cores. but i bielieve using one of the existing switch as such is currently less optimal and the transition will be easy.

I hope we all agree in a compromising path. this thread seems to grow exponentially. I am only interested in Sonicwall and HA. I am not a network architect and therefore would get buried into situation that would be beyond control. We are about 100 user warehouse company that highly depend on WiFi. We have no servers. I am hoping this simple setup can be achieved without thinking more than we have to. When we are ready for more complicated network, definitely these suggestions will help.

totally agreed. i believe you have more than enough material to complete a simple setup.

you can plug the wifi boxes on either individual switches or the sonics. assuming they handle only one uplink, there is no difference. better use the sonic directly if you have enough ports left.

regards

SaaS design is hardly network architecture, but hey! :-)

Plugging the APs straight into the sonicwalls would be a bad idea. They're HA so if you plug an AP into the active, it will break when the standby sonicwall takes over. This is simple stuff.

If you're highly-dependent on Wi-Fi you need to build in some resilience. If you have a single switch with all your APs connected (or a single sonicwall where APs connect), and it dies, so does your Wi-Fi, then you're dead in the water.

agreed, an active active design would be better. but afaik, the sonic only does active-passive so there is no good way with the provided equipment. if the aps have multiple uplinks, it is better to plug them to multiple equipments.

the gain of using an intermediate switch is clearly not null, but debatable. if the switch dies, the aps die all the same. both are bad design. this is simple stuff ;)

i would rather focus on the possibility to redund the aps with one-another ( which implies either having one ap shut down when the uplink dies or multiple uplinks AND be able to expect the clients to failover from an AP to another properly )... assuming each ap supports a single uplink and the clients cannot failover, the extra layer of switches allows all aps to be active at the same time and more gracious handling of wan link failover which would indeed be worth the complexity.

if the aps can use 2 uplinks, just plug the aps to both sonics ( or 2 separate switches ).
if they can be used redundantly keeping a passive ap, plug an ap on each sonic

--

i am against the layer of switches between the WAN links and firewalls because i deem them plain useless.

i am actually in favor of a layer of core switches under the firewall to plug the APs and other switches.
... but as long as there are no available stackable switches, i believe adding the current ones will make future network evolutions more complex, and may or may not be worth the effort, power consumption, etc...

@some one : do not worry, saas architecture implies quite a bit of network architecture as well. we just hardly ever work with a huge number of desktops but on the other hand take many more things into account since the network designs are profiled to run specific platforms.

Most APs don't have multiple uplinks. Some do, but it is rare and usually not desirable to use it without LAG. That means connecting to a switch. Surely you're not suggesting consuming 2 ports per AP connected directly to a firewall?

the gain of using an intermediate switch is clearly not null, but debatable. if the switch dies, the aps die all the same. both are bad design. this is simple stuff ;)

So, I said stacked core. This eliminates your massive SPOF worry. Each switch connects to both cores. APs are distributed across switches. This is simple stuff but you don't seem to be getting it. You keep saying just do this and just do that without any real consideration as to the implications of what may/will/could happen.

I'm dubious as to how much network architecture SaaS design entails. Sure it uses a network but software service design and network service design are two completely different arenas. Saying that though, I'll leave you to it. You've got all the answers and clearly know way more than me when it comes to network architecture and design principles. ;-)

i am not i a fight here... we are both trying to help out the same person and pretty much agree on principles... i see no need for further discussion.

Once my sonicwall goes into production with all the help and suggestions I have received here, I will let everyone know on it's performance and we can take it from there.

All suggestions are warmly welcomed here.  Everyone has their own opinions.  I wish I can say one is better than the other but that is not the case.  Everyone has their weakness and their strengths.  I am the weakest link of all.  LOL.

I managed to get sonic up and running but to a small department (group of 5) on a single switch.  There is no failover's setup yet as this is being tested using AT&T ISP.  Setup is as follows:

AT&T Modem ----> SonicWall ----> Netgear PoE Switch

Very simple setup.