That's not true at all. For each broadcast, each device on the same layer2
segment must respond. As you contain each broadcast in a smaller segment in
your network, you have much less chatter.

It's not so much about decreasing the Mac table size as it is increasing
performance over a HD wireless network, by breaking things down into more
manageable pieces - unless the network is obviously 4000+ devices on the
segment. The larger the layer2, the more pronounced this is.
On Jan 26, 2016 9:23 PM, "Sterling Jacobson" <[email protected]> wrote:

> Unless you have switches in between handling the VLANs and untagging  you
> aren’t going to reduce much of anything.
>
>
>
> The MAC tables will still be there, but then have to also track VLAN
> tables as well.
>
> The MAC table won’t shrink unless that device is completely removed from
> one or more VLANs.
>
>
>
> If each AP is on one VLAN only and whatever port it’s tied to is on an
> untagged port, then I don’t see why it would reduce performance.
>
>
>
> Most any device now days except a $20 dumb switch will do port based VLAN
> and trunk to an uplink no problem (at wire speed).
>
>
>
> If your router can’t handle assigning a subnet to a VLAN one to one
> without CPU going up, then something is really wrong.
>
>
>
> We can meet at my office sometime this week and take a closer look.
>
>
>
>
>
> *From:* Af [mailto:[email protected]] *On Behalf Of *Brett A Mansfield
> *Sent:* Tuesday, January 26, 2016 7:28 PM
> *To:* [email protected]
> *Subject:* Re: [AFMUG] Router for VLANs
>
>
>
> I do give every customer a public. I had a router port to each AP before,
> so that is kinda the same thing. But I'm still not sure how this would
> eliminate the issue of maxing out the CPU on the router? It's still a bunch
> of VLANs bridged to the WAN port.
>
>
> Thank you,
>
> Brett A Mansfield
>
>
> On Jan 26, 2016, at 7:21 PM, Josh Reynolds <[email protected]> wrote:
>
> Divide part of the block you were given and hand out the ips allocated to
> the block on the vlan. Only works if you are given every customer a public
> though, and each site or group of APs / AP would be on its own vlan.
>
> On Jan 26, 2016 8:18 PM, "Brett A Mansfield" <[email protected]>
> wrote:
>
> You said I could allocate a subnet per VLAN. How would I do that and not
> max out the CPU? Is that the FastPath you speak of?
>
> Thank you,
>
> Brett A Mansfield
>
>
> On Jan 26, 2016, at 6:21 PM, Josh Reynolds <[email protected]> wrote:
>
> Yes, you can create /30 for each client, which which is fairly wasteful,
> or you could allocate a subnet per vlan, which you can under/over estimate
> during provisioning there. PPPoE is another option, and one I'm personally
> not a fan of. You could 1:1 NAT them, but that scales very poorly.
>
> You could also simply get more IPv4, which is likely the easiest.
>
> At some point soon, you really need to be looking at IPv6 though.
>
> On Jan 26, 2016 7:14 PM, "Brett A Mansfield" <[email protected]>
> wrote:
>
> I currently have a router with two ports that are not bridged to each
> other, but are statically routed. On each port I have the untagged Public
> LAN with Public IPs, and a tagged VLAN with internal IPs for management.
> But yes, after the router it is just a large bridged/switched network. Some
> of my older devices have run out of ram due to a large bridge table. The
> newer devices do not have that issue.
>
> I'm not really having any major issues. I did have each and every access
> point on their own dedicated port to the router with their own network. My
> issue with that was I had several ports running out of public IPs while
> others had more than enough to spare. I don't want to waste all of these
> IPs routing them like that, and I want to be able to move them around at
> will. PPPoE is not an option for me.
>
> Thank you,
> Brett A Mansfield
>
> > On Jan 26, 2016, at 5:38 PM, Josh Reynolds <[email protected]> wrote:
> >
> > So, if you tried to create a bunch of vlans and then bridged them all
> > together to terminate them on a single router interface/subnet/ip,
> > thats not going to work. What you just did didn't really segment
> > anything at all, and turned a fairly high performance (relatively
> > speaking) router into a kind of "hub". Remember hubs? Before swithces?
> > Terrible, terrible things.
> >
> > VLANs are not complicated constructs, and it drives me nuts that they
> > are so poorly understood.
> >
> > For you to segment your network, there are two ways to do it. You can
> > do it at layer2 with vlans, but those vlans will still terminate on
> > their own subnet at a router somewhere. The other way to do it is via
> > layer3, and route everything through your network. Both have
> > advantages, and the advantages of both depend on the network design,
> > transport medium used, etc.
> >
> > Are you currently running a large bridged/switch network and having
> issues?
> >
> > On Tue, Jan 26, 2016 at 6:06 PM, Brett A Mansfield
> > <[email protected]> wrote:
> >> What is a good router with FastPath. If I recall, the CCR had that, but
> I wasn't impressed with anything Mikrotik.
> >>
> >> I just want to segment my network into VLANs to limit the broadcast
> domain. I would also like to segregate services such as video and Internet.
> >>
> >> Thank you,
> >> Brett A Mansfield
> >>
> >>> On Jan 26, 2016, at 4:57 PM, Josh Reynolds <[email protected]>
> wrote:
> >>>
> >>> Okay, bridging a VLAN is where you are going wrong. Bridging is ALWAYS
> >>> going to send traffic to a low performance management CPU as opposed
> >>> to some type of FastPath hardware offloaded implementation.
> >>>
> >>> You need to attach a network diagram, and explain what you are trying
> to do.
> >>>
> >>> On Tue, Jan 26, 2016 at 5:54 PM, Brett A Mansfield
> >>> <[email protected]> wrote:
> >>>> I'm looking for the best router available to handle Internet over
> VLANs that doesn't peg the CPU.
> >>>>
> >>>> Currently I use a UBNT EdgeRouter Pro, but I cannot get more than
> 100Mb from a bridged VLAN and that pegs the CPU to 100%. I get the same
> issue on CCRs.
> >>>>
> >>>> Thank you,
> >>>> Brett A Mansfield
>
>

Reply via email to