> For each broadcast, each device on the same layer2 segment must respond
They must listen, but not respond. So for example an ARP asks who has this IP address and every device listens but only one (hopefully) answers with its MAC address. From: Josh Reynolds Sent: Tuesday, January 26, 2016 9:45 PM To: [email protected] Subject: Re: [AFMUG] Router for VLANs 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
