roadhouse1387

Wow.. ! i mean, Who mentioned Cisco ?

thats a classic sign of egress buffer exhaustion. Basically, the switch isnt up to the job.

mhowell, that is an excellent document, thanks for sharing it. I have stuck it in my library :-) I think though the answer would be to redesign, reposition or even add to, the AP inventory so that the 5ghz band is better propagated. The aim is to make use of the greater number of non overlapping channels (19 on band A and B for indoor use, as opposed to 3 for 2.4) thereby taking advantage of the considerable less congested 5ghz band. Also, channel bonding is really only available on the 5ghz frequencies so the extra throughput can be realized there and not on the 2.4. The band steering features of most controllers will help by actively encouraging clients to use the less congested 5ghz where its possible.

Chris, I am a Cisco design specialist with 20 odd years designing and building small and very very large cisco networks. The feature you are thinking about is known (by cisco at least) as 'trunking'. Trunking, in its simplest form, is the process of forwarding multiple vlans across a single physical port. The protocol that is used for this is 802.1q. Without going into the deep technicals, when you connect a simple , single vlan port to a server or even another switch, that port is said to be in 'access' mode as it carries only one vlan. The datagram used to get traffic from its source to its destination at layer 2 is a 'frame' and it consists of an 'ethernet header' which is wrapped around the original ip packet, which you will find further inside the frame. Now, a frame identifies the source and destination MAC address of the traffic but it does not identify the vlan that traffic originated from. So the point to remember here is that the vlan is defined on the ingress and egress of the switch itself and not the traffic flow. With an access link, traffic is carried across a link without caring which vlan it belongs to, that decision is made as it leaves or enters the physical switchport. So thats cool when we have one vlan, now if we want to trunk multiple vlans, we need a method of identifying the individual vlans within the trunk so that traffic for vlan X leaves and arrives on vlan X at both ends of the link. This is where 802.1q comes in. 802.1q adds a few extra bytes to the ethernet header, a couple of which are used to 'tag' a particular frame with the vlan number is belongs to. So there are two things that are needed for a trunk link to work, A, the switch or other devices at both ends of the link must be told the vlan numbers which will be carried on the link, and B, 802.1q must be used to 'tag' the traffic with the vlan it belongs to as it leaves the source , so that when it arrives at the destination, it can be placed into the correct vlan. There you go, if you are using a single link from your hyper-v server, to carry multiple vlans, you need to use 802.1q to tag all the vlans you want on the link, not just one or two, you must tag all vlans on the link. At the switch end, you configure the switch to carry the same vlan load your hyper-v nic is carrying. So if you want to carry all your vlans over the trunk link between your hyper-v server and your cisco switch, you would need to configure hyper-v to 'tag' all vlans with the same vlan id number as you have defined on the switch, then decide what your native vlan should be. I dont use hyper-v that much but i know VM Ware very well, and on VM Ware you need to tag the native vlan as well. The native vlan caters for traffic which is not tagged as it arrives or leaves a switch. but ive given you enough headaches for now, suffice to say that you can only have one native vlan and that its definition must match at both ends and is usually used as a management vlan. Any traffic arriving at the ingress of a trunk link 'untagged' is dropped onto the native vlan. PM me if you want to know more. Cheers

Guys, We are a meraki Partner and around the time the OP is talking about, there was a known issue with MR16's where a software update was pushed out from Meraki and it caused AP's with a certain type and manufacturing cycle or Wireless chipset to fail. As far as we know it only affected MR16's but it was certainly there. It wiped one of our clients out completely and caused about 30 ish (if i recall) AP's out if 90 to fail at another client. Must say though, Meraki were great and dealt with it very promptly, replacements next day. The kit is rock solid now and has been for some time, even before the introduction of the the MR18. we have loads of customers with Meraki AP's installed now and have no problems at all with them. if you are still having issues with MR16's failing with a red light and no amount of hardware resets will fixit, its likely that its one of these old bits of kit. You should be able to tell because they are marked with the 'Meraki' logo rather than the 'Cisco' one as this was before Cisco 'borged' them. Cheers

Glad you got it working, but do really want to route your BYOD traffic on the same router as your internal traffic ? There is a security implication here.. a canny big one. presumabley , the byod users are indeed bringin their own devices, are you vetting their kit ? or enforcing MDM management of some kind ? if not, they could be bringing all sorts of stuff into the organization. Because you have to route the BYOD clients through you internal VLAN to hit the proxy, they can get anywhere and everywhere. Do your servers sit on the 10.103.163.1/23 subnet as well ? Can you at least configure a separate interface on your proxy for your BYOD users, and propagate vlan 10 at layer 2 only through your switch, then route vlan 10 directly from the proxy to negate the need for them to route through your corporate network ? failing that, the least you should do is consider applying an ACL on vlan 10 to allow users access to the proxy only. Cheers

I have built a lot of Cisco WLC wireless networks and have successfully deployed 1000+ ipads on the them with good results. However, i recognize your issue and I suspect whats happening here is that the ipad is either having trouble deciding if it should be using the 2.4Ghz band or the 5Ghz band or the signal is not as good as you are expecting and the ipad is jumping from one band to the other. I have seen this a lot with ipads. The roaming mechanisms are not really very good and they tend to hang on to weak signals rather than roaming when a better one is seen. That siad, its not always the ipad to blame, bad AP placement is equally a common cause i.e too many or not enough AP's in an area, but by far the bigger is low SNR caused by bad AP placement You say you have good signal, do you know what that signal is in dbm ? and what your noise floor and resulting SNR is ? you should be looking for -65 min and about 20db snr. if you are outside this, then i would expect devices to start seeing either throughput or stability issues. It could also be plain old congestion if you have stacks of ipads on the 2.4ghz band. Check that out and then you could try band steering to push ipads onto the 5ghz band as its less congested. 2 simple things to check as well, check that you have configured you ipad to auto-connect when in range... a simple thing often missed and make sure you havent got 802.11n channel bonding enabled on the 2.4ghz band, its not really suported on the 2.4ghz as there are only three non-overlapping channels available so channel bonding effectively uses the whole of the 2.4 spectrum on a single AP leaving nothing for the other AP's (although you can turn it on and the WLC 'should' automatically disable it if it sees other AP's in the area). drop me a PM and we can have a chat about it if it helps. Cheers

Its exactly what you previous poster said. Its part of the offcom rules which state that because some of the 5ghz specturm allocated to outdoor bridging is shared with some types of radar (actually, some military radar) they get the priority i its use. It used to be the case that tx power on these frequencies was limited to a couple of hundred watts but not so long ago, that was raised to maximum of 1w for 5ghz band B, which is probably what your bridge is using. A condition of this was the implementation of TPC and DFS, Transmit Power Control and Dynamic Frequency Selection. The first is designed to automatically reduce tx power in order to use only that strength which is required to maintain the link. The second, and the source of your issues, is designed to listen specifically for allocated users of that spectrum such as radar, and move frequency when its detected. This can lead to drop outs because A, the process isnt seamless, and B, the rules also state that the radio must wait for bit before transmitting again to make sure the interference has gone. remember using the 5ghz is license free for wifi use on bands A and B (you need one for band C), but you (we actually) are really just squatting on it because it is already allocated to these other uses. The theory is, as long as wifi license free use is limited in tx power and frequency, then it can be safely shared. even if we are treat as the poor relation in the partnership. If your problem is that it goes off and stays off for quite some time, it may be that your bridge has been set to use a specific frequency rather than a selection so it has no where to run when radar is detected. Check you bridge config out and see what it says. HTH Cheers

Some good advice from Stuclark there Elliot, Its always more efficient to have your layer 3 switch doing the inter vlan routing than say a TMG (gawd! !) or some other software box because in general the switch will do it in hardware so its significantly faster, more efficient and doesn't slow down when it gets busy doing other things (as a TMG would do, or any other PC based product will do). Be aware though, as Stuclark says, you absolutely do not want to route your internal traffic/vlans on the same switch as your public or byod carrying vlans. By default, the switch will happily route between them providing no security whatever between them. Security is the watchword here. VLANS by themselves will not solve the problem. You can... if you have the management time to spare, configure access control lists of the layer 3 interfaces between the vlans, but this will be very prone to error and is management intensive. Better if you can implement layer 3 path separation, which you cant do on an HP, so your only other option is to connect the layer 2 byod/public and so on vlans into your firewall as DMZ's and route from there. This works quite well as long as you dont have mountains of vlans to secure, otherwise you will either run out of ports on the firewall or out of patience configuring gazillions of access rules for the individual vlans you will have to bring into the firewall on an 802.1q trunk. Cheers

a pair of Cisco cat4500X in your core with a VSS configuration will give you 1.6Tbps of throughput max, along with resilience. The bulk of the price in a 10Gig network is usually the optics, but in fact, most schools dont really need 10Gbps. egress buffer size and efficiency are far more important than raw bandwidth. You would be surprised how cheap a Cisco 4500X VSS core coupled with 2960X switches at the edge will be. And of course, you are getting all those really valuable enterprise features you usually have to pay extra for in an HP box, such as RPVST+ (not available at all in HP or anyone else switches for that matter), Enterprise routing, VRF , PIM Multicast suport and so on, and at 1:1 port to back-plane over-subscription, i.e none. You can of course, save even more cash buy going 1gig SFP to start with then move to 10Gig on a stack by stack basis when you need to. There are fewer industries where the phrase 'you get what you pay for' applies more than networks. PM me if you want to chat Cheers

Hi Sam, Did you get to the bottom of this ? If it helps, it sounds like you are having some issues with ARP. Its not uncommon to loose a ping or two when trying to talk to a box for the first time on a LAN, this is just the ARP protocol doing its stuff, but the loss of one or two pings (we are talking about 10's of miliseconds) shouldn't cause a box to fail to respond consistently as you describe. Try pinging a misbehaving box and note any packet loss and RTT times, on a LAN you should be seeing RTT's of less than 1ms and you should have no packet loss save from possibly one or two the first time you ping it if it has seen no traffic for a few hours. check the layer 3 interfaces for the relevant vlans on your switch and make sure proxy-arp and ip-redirects are turned off, this is particularly important where there is more than one router connected to a subnet, say where you have a split core architecture. These features can cause delays in ARP replies and cause the type of issues you are seeing. Before you do that though, make sure all your servers/pc's etc are configured with the correct subnet masks and gateways as the proxy-arp feature hides issues that would otherwise be caused by devices with no default gateway configured. There are other things which could be causing it but this is a good place to start. Cheers Shaun

Hi Reggiep All good advice from the previous posters, if I could add to that by adding some further points. if you add your new vlan to a trunk (cisco speak.. 802.1q link, not an HP channel) port carrying all other vlans to your core switch, you will see no improvement on performance as in the end a vlan is nothing more than an Ethernet frame with a vlan tag in it and as such it will consume bandwidth along with all other vlans on the link. You may get some benefit from using a seperate link as a last resort but be mindful of spanning tree. If you are experiencing performance issues over your netgear with your cameras on the go , its more likely related to the throughput performance of the netgear rather than bandwidth congestion. Netgear switches in common with other low end tin have small egress buffers and processors and in general will have difficulty maintaining the packet forwarding rates required as your network scales and you add more cameras, of course, it all depends on the codec being used. 720p can be anywhere from 5 to 10 mbps depending on the codec. QoS may help here but you cant create more buffer space out of thin air if the switch isnt big enough. Consider a switch from a tier one vendor such as Cisco if you need to upgrade. IPCCTV uses Multicast to forward traffic, whilst this will work ok if all the cameras/recorders/controllers etc are on a single vlan/broadcast domain, you will need a multicast capable layer 3 switch or router to get that traffic across from one vlan to another. Even then you may find that it doesn't work due to TTL counts which are hardcoded into the multicast IP header by the camera manufacturers. Some vendors set this to one which effectively means routers throw it in the bin as soon as they see it and dont forward it. This would mean that you would need to span a vlan across all your switches where you have cameras. Of course we know that this is common practice (flat networks), but its actually a very bad practice as it increases the size of a failure domain to every switch carrying a common vlan. Flat networks are suseptable to instabilities caused by spanning tree and bad root bridge placement as well as broadcast storms and MAC over subscription. Routed designs are much better. Cheers Shaun

Hi Ben, its hobsons choice really and all down to acceptable risk, but there is some mileage in preventing users connecting with uncontrolled devices from being able to see each other on wireless networks. The main reason is that you have no knowledge of what malicious tool sets may be on those devices and so you would want to prevent folk from targeting others on your network. on the whole though, securing BYOD and Public networks from private or corporate ones can really only be done properly by using layer 3 separation technologies such as VRF. Relying on VLANs alone isn't all that secure. Cheers Shaun