PC5324 protocol groups / protocol VLAN bug

Question

I'm running a small local WISP.  I have a few of these switches bought at auctions (allegro.pl - a bit like ebay), they generally work fine but I came across a strange issue with a nice but rarely used feature: protocol groups / VLANs. The setup is fairly complex, but basically I'm trying to separate PPPoE traffic (to/from my customers) from IP/ARP traffic (management of Ubiquiti radios, including some legacy ones that don't support 802.1q yet) into separate VLANs.  There is a lot more PPPoE (YouTube etc.) than management traffic.  I've tried to do it in two ways: - match PPPoE (8863/8864 hex) and put that traffic in a separate PPPoE VLAN, leave the rest in the management VLAN. - match IP/ARP (0800/0806 hex) and put that traffic in a separate management VLAN, leave the reset in the PPPoE VLAN. The first one seems to cause high CPU load on the switches with just 50-60 Mbps of PPPoE traffic (and I expect more soon); I guess that means the feature is actually implemented in software, only the initial ethernet protocol number matching is accelerated by hardware.  So it would be better to use the second option (the IP/ARP management traffic is much less). The second one would be perfect, if not for one detail: it works fine when set up initially using the web GUI, but after the changes are saved (copy running-config startup-config) and the switch rebooted, it does some very strange things.  The config looks normally but the code that reads it after the switch boots probably sets up wrong switch chip configuration, causing some untagged (Access) ports other than defined General ports to stop working.   I've also seen the bridge address table entries to age very quickly (in about one second) making the switch flooding like a hub.  I want this feature for ports g9-g16, and after reboot at least g17 and g21 are affected but g7 is not.  These ports (which are untagged Access ports in other unrelated VLANs) simply stop working; tagged (Trunk, General) ports still work fine.  , They work again when I delete all the Protocol Port rules (8 of them, one for each of g9-g16 port putting it in VLAN 49 if matched protocol group 1), then delete the two entries for IP and ARP in protocol group 1.  Now I can re-create the setup (define protocol group 1 for IP and ARP, and add protocol ports g9-g16 as before) and it's all working fine agai - until reboot.  This is 100% reproducible for me (switch chip set up correctly immediately after making the changes, but not when reading the config after reboot - tested on two different 5324 switches to be sure), any chance for another firmware release with a fix?  Thanks!  (BTW, the CLI manual mentions protocol 'ip-arp' which is wrong syntax and doesn't work.)

DELL-Willy M · Answer

The last firmware update was 10/18/2010. I do not see that we have a firmware update in the works. The 5324 is 2 model generations away from the current shipping 5524 model. If you feel like this is something that you need to be resolved you may want to call in and provide the information to a phone agent. This will allow the processes to take place in order to get it submitted to the firmware engineers.

Be advised that the current shipping switches are going to receive the priority when it comes to providing any firmware updates.

marekm · Answer

Thanks for your fast response.  Yes, I have the latest firmware (2.0.1.4 from 2010).  Apart from this protocol VLAN issue (it took me a few good nights to debug), the 5324 switches have been rock solid for me.  And they are not RoHS yet so should last a long time to come, I don't see an immediate need to replace them.  I wouldn't refuse a new 5524 as a bug-bounty though :emotion-1:.  Low priority is no big problem, I can wait a few months for the fix without rebooting as I have the switches running on two power supplies (AC from an on-line UPS, and DC via my own hacked reverse-engineered RPS cable from a 12V battery backup).  I'd prefer to contact the engineers by e-mail if possible, as it's easiest to explain the issue by sending the complete config file which triggers it.  I don't have any kind of support contract, just happen to own the second-hand hardware, so I don't think I can ask for phone support, and English is not my native language.

Networking General

Was this post helpful?