Netonix Forums

Hey there, I'm currently trying to figure out how to remove an ARP entry from our Netonix Switches.

I do not see any remove button in the GUI And the BusyBox CLI help command does not show a direct ARP command.

Is there any way to force clear an ARP entry?

I'm moving a wireless bridge from a single link to the netonix to split out redundant trunks and I'm having some issues. I've restarted the switch and moved ports and reconfigured and double checked everything from end to end and it works in another netonix across the bridge but this switch shows different ARP entries and I'd like to clear them and test it again.

If this is possible some direction would be appreciated.

Thanks

If you rebooted the switch then the MAC table is cleared, if you're still seeing it then the switch can still see it.

What firmware version are you running?

If you're running up to date firmware, I suggest v1.4.5rc2 then yes there is a Clear/FLush Arp Table button in the upper right corner, it looks like an [X]

I'm still on Firmware Version 1.4.2.

Downside to having these be the main backhaul for a 24/7 business is there's never time to upgrade.

If that's the only option then I'll try to find some time to get new firmware on there.

Off topic but how's the QoS coming along?

CVPB wrote:I'm still on Firmware Version 1.4.2.

Downside to having these be the main backhaul for a 24/7 business is there's never time to upgrade.

If that's the only option then I'll try to find some time to get new firmware on there.

Off topic but how's the QoS coming along?

There are some discussions about the NEW QOS that is currently implemented in v1.4.5rc2 and requests to have some things changed which Eric is working on now and should be released this or next week.

sirhc wrote:
There are some discussions about the NEW QOS that is currently implemented in v1.4.5rc2 and requests to have some things changed which Eric is working on now and should be released this or next week.

http://forum.netonix.com/viewtopic.php? ... QOS#p15533

I get "You are not authorised to read this forum." when trying to view that.

We're still getting some VoIP complaints so definitely looking forward to getting QoS functional here. I'll look into the newer firmware and see if I can find a good enough excuse for some downtime to upgrade and test.

The idea of switching to Ubiquiti's EdgeSwitch has come up and I'm trying to avoid that conversation because I like your products quite a bit.

Thanks for the info.

You have VoIP problem because of congestion at the switch ? Else, QoS at the switch won't change anything. You would probably need the change header's DSCP value for VoIP paquets, a job done at the router, or have link that support QoS custom config. Edgerouter is not a option since changing DSCP would mean disable offload. CCR would be a a option if not too much bandwidth, hardware router like Cisco or Junieper even better but best would be a specialise product like paquetlogic or something similar.

P.S. : If using airfiber, you must have a tagged VLAN and change CoS value instead of DSCP (or based on DSCP value), unless DSCP is now support and I miss it.

mike99 wrote:You have VoIP problem because of congestion at the switch ? Else, QoS at the switch won't change anything. You would probably need the change header's DSCP value for VoIP paquets, a job done at the router, or have link that support QoS custom config. Edgerouter is not a option since changing DSCP would mean disable offload. CCR would be a a option if not too much bandwidth, hardware router like Cisco or Junieper even better but best would be a specialise product like paquetlogic or something similar.

P.S. : If using airfiber, you must have a tagged VLAN and change CoS value instead of DSCP (or based on DSCP value), unless DSCP is now support and I miss it.

The reason I suspect the Netonix as being the culprit for our VoIP is that we have our internet going over a Mimosa wireless bridge between two Netonix switches, the Mimosas do not have QoS (at least not the B5-Lite's on our current but not latest firmware) which is another issue but the Mimosas and Netonix devices are the only things on the network that don't directly support VoIP QoS/CoS at the moment so it's down to those two devices that would be behind our VoIP quality issues.

We have a Cambium EPMP1000 Pont-to-Multi-Point system that has VLAN Identification for QoS control which would be awesome to see in the Netonix switches, but the Cambiums are for local traffic and does not handle the incoming internet traffic directly.

I run my entire WISP with Netonix, see video on YouTube https://www.youtube.com/watch?v=8JvBEAD4MFM

Many of my customers including all 5 of my businesses and my house have perfect VOIP

sirhc wrote:I run my entire WISP with Netonix, see video on YouTube https://www.youtube.com/watch?v=8JvBEAD4MFM

Many of my customers including all 5 of my businesses and my house have perfect VOIP

This is now on my list for Sunday study, as I said the Netonix and the Mimosa's are the only devices I would point at for the issues we're having.

Calls get bogged down sometimes and completely garbled to where it's completely incoherent, but it's not laggy, per say, as my google voice behaves on wifi sometimes it is noticeably slow and deformed.

We have ShoreTel VoIP and I don't really have a great reference for their overall quality but they are going through their own firewall not on our network, however they still pass over a Mimosa to our main WISP connection coming in.

Thanks for the video, I'll definitely be checking it out.

A lot of things affect VOIP first and foremost if you run a large flat networks with large IP segments this can be bad for VOIP as ARP and broadcast traffic can impact performance.

Running VOIP through multiple NAT is very bad.

Interference, link congestion, pack drops as it is UDP not TCP traffic which is where Flow Control comes into play but Flow Control is broken or non existent on a lot of wireless equipment.

MIMOSA radios do not implement Flow Control
airFIBER firmware has a bug in Flow Control

Normal network traffic should not exceed 75 percent of link capacity on full duplex links or 50 percent of half duplex links so that traffic spikes do not force packet drops.

The use of Half Duplex links in succession is very bad if link capacity is too high as packet drops will occur.

Less than 1% packet loss over a 24 hour period is a must.

Building a good wireless network to handle VOIP is an artwork.