-
Posts
14 -
Joined
-
Last visited
Content Type
Forums
News
20th
EduGeek EDIT Conference
Blogs
Everything posted by ericscher
-
It's actually possible to drill under a roadbed horizontally. The expense is governed mainly by the width of the road. Your contractor can give you the details. You will also want to enclose in direct-bury metallic conduit, because otherwise rodents will cut your link on a regular basis. Also, if there overhead telephone/electrical wires suspended on telephone poles (ubiquitous here in the USA) you can usually manage to get permission to use the poles to cross the road. And of course, if the buildings in question are of sufficient height and local zoning allows, it may be viable to run an overhead wire from building to building. There is special cable for that which contains it's own tool-steel suspension wire. Having said all that, AButters may have made the best suggestion, unspoken though it is. At 50m your 60% 1st Fresnel zone for 2.4GHz is only about 1m. Heck, your 100% zone is only about 1.5m. A wireless link may be your best overall option, assuming your weather/atmospheric conditions are amenable to that.
-
Wow. Yes, I can see why you did what you did.
-
Amazon UK sells a Ubiquiti Radome for £91.65, which honestly looks a lot like the Laird Technologies radome that Pro Telecom Supplies in NY sells for about $70 (£40.00). Point being, there are a number of fairly cheap commercial solutions available to you. Just do a web search on "radome" and you should find plenty of options. Having said that, I once installed a WAP in a YMCA gym where I used a plastic milk crate that I picked up from WalMart for about $5. I would suggest that a determination be made as to whether money or aesthetics is the primary consideration here.
-
I haven't used their controller based WLAN products but I have always found their autonomous access points to be rock solid.
-
I'm curious... Have you priced out the possibility of going to a chassis system like a 4507 instead of multiple 3750's? Assuming this is still in the future and you don't already own them...
-
Nobody ever got fired for buying Cisco. That's just an old saying. I have no idea if it's true, but I've never seen it. And Cisco trained techs the most numerous, easiest to find and most affordable. Of course, Cisco is like Fluke. More expensive than 3 ex-wives and a boat. I think you want to look at TCO. Total cost of ownership over a defined period of time.
-
Ethernet is Ethernet, whether over copper or fiber. True, when you are talking about the big multi-gigabit links you're talking about fiber, but that's for back-haul. However, glass doesn't conduct electricity. Which is GOOD if you would prefer not to have a power surge come up the link and take out your switch, especially if it happens to be a 4507 or a 6509. It's BAD if you ever want to run PoE over the link. I like to see Fiber from the site's main switch to the cluster commander and then copper to the access switches. For example... Cisco 4503 <---2 or more Trunked Gigabit Fiber Links to each Cluster Commander---> Cisco 3750 PoE Switches <---1 or more 100 Megabit Cat5e links to each Access Switch---> Cisco 2960 Switch or 561AP's Now, the brand names and the models don't really matter. Plus, you can eliminate things you don't need. The parts that I think are worth remembering are to use copper at the access level so that you can carry Power over Ethernet, and segregate your access layer switches (either 802.3 or 802.11) from your higher level (more expensive) equipment with fiber optics. BTW, it was drilled into me years ago to never forget... An ether channel isn't 400 meg of bandwidth (100m each way, assuming full duplex, times two channels), it is TWO INSTANCES of 200 meg bandwidth. That really only matters once you get above two ports in an ether channel and then mainly in 3, 5, 6 & 7 port channels. So, not really something that should matter for you in a single school no matter how large. Still worth reminding ourselves of though.
-
Yeah... I thought you would say something like that rather than risk getting into an actual technical discussion. But I figured, hey... it's your foot, your mouth and your decision about which direction said foot moves. By the way... Disabling the LOWEST rates (1 & 2 meg 802.11 Prime) improves throughput for the same reason that Airtime Fairness was developed. They are Media hogs, taking up to TEN TIMES longer to transmit the same data as even 802.11b. Disabling the highest rates reduces you maximum potential throughput. I'll tell you what. I'm going to let my posts stand, you can do what you like with your posts and everyone who reads the thread can decide for themselves what they think. I'm going to unsubscribe now and you should feel free to have the last word.
-
I don't take it personally, so there is no need for you to fret about that. But if you believe that my advice is incorrect and believe it so strongly that you feel it necessary to comment upon it, then it is incumbent upon you to explain why. And for what it's worth, I'm pretty sure you don't have an obligation to care whether I understand you, although I do appreciate the concern for my feelings. But let me see if I can show my gratitude by helping to narrow my ignorance down for you a bit so as to save you some effort in educating me. 802.11b certainly is Direct Sequence Spread Spectrum, specifically HR-DSSS using Complimentary Key Coding for modulation as opposed to DSSS and Barker Code as defined under 802.11 Prime. So you couldn't be talking about that... 802.11g specifies ERP-OFDM along with ERP-DSSS/CCK for backward compatibility with 802.11b and specifies mandatory data rates of 6, 12 and 24 in "G" mode and 1, 2, 5.5 & 11 in "B" or "Mixed" mode. So you couldn't be talking about that either... 802.11n or HT-OFDM, leaving aside the differences in bandwidth (20Mhz vs 40MHz) is not really any different from "G" in it's behavior. In fact, the 802.11n Amendment only specifies 3 mandatory technologies: Support for at least two spatial streams on the AP. Aggregate Media Access Control Protocol Data Units in transmit mode and Aggregate Media Access Control Service Data Units in receive mode Block ACK So... you couldn't be talking about that either. So what's left... Oh yes... Protected mode. When running an AP in B/G/N mode or "Mixed Mode", 802.11-2007 requires backwards compatibility for the client stations. The data rates are defined by a Modulation and Coding Scheme Matrix so the AP can talk to client stations based on the client's ability. The problem is that new developments in Full Duplex WiFi using "noise" cancelling techniques notwithstanding, WiFi is a half-duplex medium that used CSMA/CA or Carrier Sense Multiple Access / Collision Avoidance. Unfortunately, the way that it avoids collisions is through a Network Allocation Vector or NAV Timer. A station can't broadcast until it's NAV timer is zero. When a data frame is transmitted the Duration/ID field is used by the other stations to reset their NAV timers and begin the count to zero again. But "B" stations won't understand "G/N" station frames because DSSS and OFDM are not mutually understandable. So, in order to compensate the "G/N" stations begin to use RTS/CTS (Request to Send / Clear to Send) or CTS-to-Self using a Modulation method which the "B" stations DO understand. The problem is that this adds so much overhead that whereas you can usually count on getting a throughput of about half of the claimed data rate, protected mode cuts it in half again. Which certainly SEEMED to be the behavior described in the original post. So it couldn't be that either... Perhaps you were referring to my failure to discuss Packet Binary Convolutional Code, Differential Binary Phase Shift Keying, Differential Quadrature Phase Shift Keying, Binary Phase Shift Keying, Quadrature Phase shift keying or the various levels of Quadrature Amplitude Modulation; OR how the relate to the various available data rates. But then, if I didn't mention it then I couldn't have been wrong about it... Maybe, you objected to my solution... But no... co-located WAP's with UTP back-haul (as opposed to Mesh, which loses half it's throughput on every hop.) is certainly a valid solution, as is turning off "B" mode altogether and having a pure OFDM WLAN that wouldn't need a protection system. Oh wait... I've got it! You meant that I misunderstood the QUESTION posed by the original poster. Well, that is certainly possible. If you would be kind enough to explain it to me so that I may learn from my mistake, I would be grateful. Thank you in advance.
-
Wrong because I misunderstand the question or wrong because I don't know what I'm talking about. Either way, please... be helpful and elaborate. I wouldn't want to miss an opportunity to learn.
-
I may be in error since I cannot see the full config and may be analyzing this incorrectly. However... The switch needs an IP address for the management VLAN, which is typically VLAN 1, plus any other VLAN's on the switch. But those don't get applied to the individual interfaces. The individual interfaces will get a much simpler config. I can't recall HP syntax off the top of my head but it should look something like this: Switch(config)# interface fastethernet0/1 Switch(config-if)# switchport mode access Switch(config-if)# switchport access vlan "X" And of course you'll have to trunk up at least one of the ports to connect up to the next higher level device, but I assume that config is already there on the assumption that the switch in question is not new. I hope that helps.
-
Are these autonomous access points in individual classrooms or groups of classrooms, which are NOT intended to overlap to provide roaming? If so, and assuming you already have a channel re-use plan that keeps the AP's that are on the same channel as far away from each other as possible, try turning down the power on your AP's until the cell size has been reduced to a point where it is just sufficient for the necessary coverage area. Also, if it were me, I would stick to a 1/6/11 channel plan, since anything less than 4 channels of separation BETWEEN each channel you are using for clients with overlap on the side-lobes.
-
Assuming that I correctly understand your description of the problem; your speeds are dropping because of b-mode clients. 802.11b is a DSSS technology. (Direct Sequence Spread Spectrum) 802.11g/n is OFDM (Orthogonal Frequency Division Multiplexing) When your AP is set to mixed mode, it has to have a way for both MCS's (Modulation & Coding Scheme) to exist on the same BSS. (Basic Service Set) That's done through what's called Protected Mode. It's because 802.11 networks are still only half-duplex and they use CSMA/CA to avoid collisions. I freely admit to being too lazy to get into a whole discourse on things like Network Allocation Vectors, but the basic deal is that the moment a mixed mode AP hears a probe request from a DSSS or HR-DSSS client, it goes into protected mode. They don't even have to associate with the AP to trigger Protected Mode. They only have to send out a single probe request. Even worse... Your AP doesn't even have to hear that "ping" from an authorized client. It can be ANY client station that happens to be within range. On a 54meg connection that would otherwise have an aggregate throughput of 20-25meg, it will actually drop to less than 10meg aggregate. The solution is to either have co-located WAP's using UTP cable for back-haul to the network, with "b" clients segregated on one and "g/n" clients on the other; or turn off mixed mode altogether.
