koffi2k

I've implemented DHCP snooping on parts of the network where I have control over them to avoid rogue DHCP servers being introduced by students or teachers plugging some home routers into the plugs if our wireless APs. However I've come across a situation where I realized that DHCP snooping was doing harm when enabled one one particular (not same model as others) switch impairing DHCP replies from the servers being received by clients. My understanding has been this far as follows: - All uplinks leading to the core and server switch need to be "trusted" - All access ports should stay untrusted - The port of the DHCP server should be trusted as well Is that correct so far? Now I've encountered issues when moving a (wireless) client from sector connected another area that is connected to another switch, thus they don't share the same snooping DB. My network goes (simplified) as follows: server <-> server (and AP) switch <-> wirecenter (fibre) <-> all other switches (A, B, C...) I've checked the switch in the server room has the same settings as all the other access switches. Moving between A, B, or C works DHCP allways works. However when moving from APs connected to the same switch as the server switch to any other, the DHCP server replies never arrive at the client when DHCP snooping is enabled. Going back to APs connected to the server switch it works again, or after waiting for $RANDOM/UNKNOWN period of inactivity. I've tracked down this behaviour to the switch with the DHCP server via wireshark and port mirroring so that I could verifiy the location where the DHCP replies started missing. Any input would be highly appreciated.

In case those PowerConnects have a similar CLI as IOS (some of their switches are OEM-Broadcom Hard- and Software) and share similar Broadcom underlying FastPath software as a couple of Netgears. Anyway, I've even gone this far to ban VLAN 1 from every port (On Netgear in global config mode it's: vlan partitipcation exclude 1 all) since it's otherwise auto-included as untagged on every port. If you want to accept it only tagged without banning, there is no such thing as native VLANs as on Cisco. On those boxes you include a VLAN on a port (if it's not already), then tell it to be tagged (otherwise it's not). Then you don't want to miss the Port VLAN ID (PVID) setting which tells the switch what to do with untagged ingress traffic - that's most likely on default 1. By changing it to another (even blackhole VLAN) you stop accepting traffic on VLAN 1 on those (access?) ports. If you switches are as similar to Netgears according to the snippets I saw in the manual, then you might be able to enable VLAN ingress filtering which will make sure that even if the port is not part of that VLAN - memberships is only applying to egress traffic on a Port - ingress traffic to VLAN 1 will still be accepted on ports that are not members of VLAN (i.e. exclude it). Although not a replacement for a complete CLI manual it's already something, and if you are familiar with Cisco a couple of commands are very similar and I found the CLI to be quicker than clunky webinterfaces ;-) ftp://ftp.dell.com/Manuals/Common/powerconnect-2808_User%27s%20Guide_en-us.pdf Good luck!

While VTP is a Cisco-only thing, there are 2 other similar, yet standards-based protocols called GVRP (GARP VLAN registration procol) and the newer MVRP (multiple vlan registration protocol) that are standards-based. Although I don't use GVRP (I only have 4 VLANs), it is a feature present on our fully managed Netgears. Do you happen to have only their smart managed switches or fully managed ones with serial console ports? If you have the later one, enable SSH on them (disabled by default) and jump to the CLI, it's way quicker to manage VLANs there than on their sluggish Webinterface. On the plus side: Netgear's CLI interface is very (very) similar to Cisco IOS. If you understand one of them, you'll understand the other quickly too. Even on their smart switches you can export the text config as HTTP download or to a TFTP server. As long as you don't mess up the syntax (pretty much identical to the syntax of the syntax of fully managed switches too) you can edit the text config and re-upload it to the switch to apply it.

Not sure if this is going to help you, nonetheless: AFAIK your 7110 "Amber Road" are EoL, thus Oracle is not likely to sell you a contract (maybe at astronomical price tag?). If I remember correct, they used to run an OpenSolaris based OS on those boxes, not vanilla Solaris 10. (simply because they received newer ZFS features than S10, but later than OpenSolaris development branches) If you're lucky you can boot a Solaris-ish OS of a CD or through ILOM and check if your system pools are present and sane, maybe you need to reset root passwords and fix GRUB? At least for root passwod and a "normal" OS, not Amber Road this is describe over there for example: Resetting OpenSolaris passwords For grub, well at least someone describes a problem on S10, but take it with a grain of and and check how the appliance OS is structured if you're able to mount the system pool. (Fixing Solaris hosts that boot to a grub> prompt). I don't know if Amber road used 'rpool' name for the OS pool (NexentaStor systems use 'syspool' for example) If you're willing to lose HA cluster (if you had it) and GUI: What about tossing the (now EoL-ed) appliance OS and install a minimalistic open source derivative, be it illumos or FreeBSD derived?

Thank for all your feedbacks, that was helpful !

G'day This perhaps a stupid question, but I am unsure if our fibre installation was done right or if I'm just thinking about it the wrong way. I'm looking for feedback from people who also have fibre patch panels with LC connectors - basically what most switches now come default with. Do you need to flip polarity on one side of your patch cords with default polarity LC duplex patch cords? Longer explanation: For years we only had the old style ST connectors on the fibre patch panels, since that's what was standard like 15y ago. As long as they don't break, they will stay installed and they seem to be quite trusty. :-) This kind of connector is simplex only, checking fibre polarity on them is normal procedure then. I'm not a fibre guy, my normal network connection in 99% of daily work is RJ45 :-) Now a new fibre run has been added to a building with the nowadays default-style LC connectors. These ports are duplex - I've once seen simplex LC patch cords but they seem to be rather seldom used. Until now I've never used LC to LC connections other than for switch to switch cabling, no passive coupling in between like a patch panel. With duplex LC cables I've never had to think default polarity although lots of LC patch cords allow flipping fibre pairs at the connector if you need to (but not all as I've found) Now with the new install I've realized that using default-polarity patch cables I've had to flip the connectors on one of the 2 ends to get correct polarity. Is this considered to be normal? Reading white papers about fibre polarity standards like this one from AMP makes me think that one should not nned to flip pairs but if connections were done right, one should not need to bother about fibre polarity ? http://www.ampnetconnect.com/documents/WHITEPAPER_Fiber_Polarity_Simplified_090813.pdf

Yes, they use netcat, scp should work once you enable SSH login on pfSense. scp should be available on most reasonably modern Linux / BSD / UNIX / OS X. If you're on Windows, you may use WinSCP instead. Good luck!

Actually the DB size of @Achandler amd @chrisrowlands made me aware of a not so unimportant difference, and made me think of a difference: Mac and Windows packages are installers providing MongoDB bundled. Linux packages and the UNIX archive (like for your use on pfSense) require you to install MongoDB via OS/distro packages or from source The Mac and Windows installers will configure MongoDB for the use of UniFi only while the Debian mongodb package comes with a default config and the init script that will launch a mongod. On Debian and Ubuntu installing a service will automatically enable its execution on system start or after installation of MongoDB. The thing I realized, was that you can stop the package-installed mongod and see UniFi continue to running. It's actually UniFi who controls and starts its own MongoDB server process and (in case of the Debian package) points DB and Journ to /var/lib/unifi). This means that you end up with 2 mongod processes runningg if you don't pay attention depending on your system default assumptions. For pfSense the FreeBSD mongodb port and its according package also ship a BSD rc script, but if you didn't add it to /etc/rc.conf(.local) mongodb rc script won't be executed during boot. Similarly RHEL and Fedora distributions require you to explicitely enable daemons via chkconfig. (on Debian you'd use update-rc.d with parameters to disable things) Having 2 mongod's running wouldn't be much of a problem, BUT: MongoDB has a preallocation mechanism which generates prealloc.X files by default. They are reserved space for mongod in case it quickly needs to allocate more space - which for web applications may be better instead of waiting for the FS to allocate the space. On Debian these default prealloc files take up to 3.1GB - now with 2 mongod's running, one via system ini script, one via UniFi, you end up with 2x 3.1GB of pre-allocated space. If you delete the prealloc files you'll see them recreated at every restart of mongod. (See: mongodb - Monogo "prealloc" files taking up room - Stack Overflow) Lesson learned and thank you for your hints :-)

Thank you! Hmm, /var/lib/unifi/db/journal takes 3.1GB now, the rest in the unifi folder comes to a total of 4GB. Although chrisrowlands has more APs in use than I - may depend on the number of users, SSIDs, $whatever - your number seems to be in the range to what I get. The content of /var/lib/mongodb has a couple of larger files that have not been modified for a longer period of time (Jul. 2012 actually), I suspect that during an update UniFi has switched the DB location somehow, not yet sure. Since the Windows controller comes with MongoDB included, things may be a bit different for the Linux / UNIX packages who require to install MongoDB on your own from package management. @Achandler: Thanks other than the regular memory consumption log and other informational MongoDB log, no errors spotted so far *uff*, hope it stays this way.

G'day In case some UniFi users are around and willing to post back their real life sizes of their UniFI controllers. I happen to see a not-so unimportant growth of my Debian squeeze based UniFi controller here with 40 APs (ecpected yet to grow to 60-70). We don't have many users yet (only teachers allowed right now) but the /var/lib/mongodb and /var/lib/unifi/db both occupy > 7GB after about 6 months of operation which I consider quite hefty simply for logging connections. Actually this urged me to expand the partitions to not break things. Also I haven't found a way to depreciate log data after a defined period, so my current guess is that the system keeps the logged data in MongoDB for like forever? *ouch* Anyone willing to post their number of UAPs and disk use of their controllers via some 'du -h /var/lib/unifi' and 'du -h /var/lib/mongodb'?

Actually a couple of Netgear managed switches (and as it seems some Dell PowerConnect too) additionally support a discovery protocol they call ISDP or "industry standard discovery protocol". I guess this is somehow a pun on Cisco since that's their CDP-compatible discovery protocol - if you're in a mixed Cisco network and already use CDP, you might be interested in this capability. If you want to show all remote devices you can issue 'show lldp remote-device all' (the CLI manual for the switch shows other available commands) As a sidenote: On the couple of Netgear managed and smart switches I've had on my desk I've seen both LLDP and ISDP to be enabled globally and on all ports in both send and receive mode. This means that you switches blast out some valuable system data like its management IP, model and firmware version on all ports. Without being a networking expert, I wasn't really happy about that default behaviour. I decided to at disable ISDP globally and set all access ports to LLDP receive only.

Just as short update: For a project I needed a couple of switches and for one run, I implement a 10G link. I have bought all SFPs from them now, including the 10G ones. The SFPs truly get recognized as if they were from original vendor and work as expected. Since we don't need that many SFPs, buying a Flexbox wasn't worth the effort, but their pre-programmed SFPs are also sold at interesting prices. - And if they don't have the exact SFP you want, mail them and they'll check their customers or their stock to make you the SFP you want (i.e. our Netgear MM SFP+) What was good is their knowledge and experience with older fibre runs, as they have gained experience in running > 1G over older MM fibre without hickups - as opposed to install new OM3/OM4 fibre.. (look at their blog, it's german though)

Not 802.1x I'd like but there isn't the time for - neither do all device support 802.1x, think of network printers. All ports are configured as access ports as normally recommended. The VLANs are set to these ports according to the groupe of people who can access the ports. Meaning: Staff ports are only in staff work rooms and all the rest is students. Up to a certain level you have to trust your teachers to close the doors by key, yes, the physical protection can be circumvented, but at least you first need to get a key from a teacher first. I don't think we can really start setting up access points for one or the other wifi network exclusively - which would add much higher cost and also complicate cabling and configuration...

G'day We're deploying UniFi UAP/UAP-Pro here and plan to offer a student and a teacher SSID, they'll be separate from the rest of the network via a packet filter, so they can only access a limited range of ports and hosts. But for multiple SSIDs, the switch port connecting the Access Point to the network needs to transport more than 1 VLAN via VLAN tagging - thus the need to have 802.1q trunk ports. I was aware of VLAN hopping danger, but stumbling upon a talk at DEFCON 19 about VoIP VLAN hopping made me think more about the risks (See where the issue is explained) Now this means that the RADIUS authentication barrier to your staff network can easily circumvented: Ignore the Access Point, just plug into the port where the Access Point normally is connected Optionally set up a transparent bridge in between Sniff traffic and get the VLAN tags used (simple with Linux and OS X, Windows is more depending on the NIC driver) Spawn a interface with correct VLAN tag and set yourself and IP, *boom* done. Now I guess that controller based systems like Cisco LAP using the their LWAPP protocol encapsulate all traffic to the controller and VLANs get separated at the controller level - so there is no need to use trunk ports in locations people can access the network plugs. Anyone who has spent on thinking about this issue and perhaps up to some levels this can be mitigated? (no, I can't install plugs in secure places just for access points, that would be far to expensive)

The switches feature a scheduling functionality for specified ports - if things work well, it means that we'd not have to touch that configuration manually afterwards. I wouldn't even be considering this if there was no option to do that on automated basis (even scripted) - I definitely don't want to chase after 100's of ports. I'll have to figure out if rebooting the APs doesn't mess up the wireless network. Definitely something to check out with our switches. AFAIK it should cut the power so that the AP will be powered off and re-powered when the port is scheduled to come back online. Ubiquiti's dual radios and Gbit-uplink AP seems to be drawing compareable power when, I gave a look at the Cisco 1142N (13W). Yup, we absolutely want UAP-Pro (UAP 4W is 2.4GHz only) and real PoE without adapters if we can (48V to their 24V is also adding losses). In general I don't expect the power draw of APs to go down with future wireless standards if I'm not too pessimistic. Allas, the only air con is in the server room and "quite required", we've already taken measures where we could (or could afford with meanigful ivestments/replacements). ATM it's about measuring the expected grow in the required power budget simply because of this new network.