Netonix Forums

Is Netonix able to be clever enough to forward vlans in the right direction without setting up a vlan table?

For example, tough switch can handle vlans neatly if all are trunks with No vlan specified (factory setting)

Edgeswitch needs them specified, but tough doesn't.

We use these as switches that power the tower and are looking for, set the power, connect, and go. All client traffic is tagged and mgt is on native 1.

So I'm Curious if it will handle forward packets in the right direction neatly without specifying vlans per port.

Thanks!

this is not a bump.

givemesam wrote:Is Netonix able to be clever enough to forward vlans in the right direction without setting up a vlan table?

No, this is not being "clever" any more then when you used to buy a Linksys WRT-54G AP at Best Buy and the AP had no security configured and on channel 6 and it just worked. IT ignorant people just plugged it into their cable modem and it worked but I would not call this "clever". Did it allow a lot IT ignorant people to work wirelessly? - SURE DID!!! Did it lower Tech Support Calls - SURE DID!!!! Was it the AP being "clever" - HELL NO!

When you set up VLANs there are these things called Ingress filters, UBNT simply set their ingress filters to accept both tagged and untagged VLANs because it would appear to just work for those that do not understand what the purpose of VLANs is for.

When you do this you are relying solely on the switch layer 2 mac address table to send your packets to their destination port so in this event what is the purpose of using VLANs if all your packets have access to the same layer 2 fabric?

Our ingress filters are "specific" which means if you do not configure them properly they do not accept the packets.

If I sound a little annoyed it is because of your use of the word "clever" to describe something that is not any more "clever" than people buying an AP at Best Buy and plugging it in and saying gee it just works, how "clever" it must be.

If you want to make our switch behave like a ToughSwitch you can easily setup the VLAN Tab to accept all packets both Tagged (all 4095 possible VLAN IDs) and Untagged packets and then simply rely on the layer 2 MAC to decide where to send the packets but then what is the point of using VLANs which is meant to segregate traffic and keep it separate. To do this make every port a Trunk port, leave all "U" on the default VLAN, then create a second VLAN (any ID) and put a "T" on all ports. Now you have a "clever" stupid switch what does not segregate VLAN traffic and replies solely on the layer 2 switching fabric to decide where to send packets. This will force the switch to accept ALL packets Tagged or Untagged on all ports but what is the point then?

The ToughSwitch is based on a BROADCOM BCM-53118 switch core that cost $7 and was designed for SOHO applications.

Our Switch are based on the VITESSE VSC-742X series of switch cores designed for Enterprise and entry level carrier applications and cost many time more with far more capabilities and is far more "clever" of a switch core.

Could we set up our VLAN ingress filters to accept all packets and many people who do not know how to setup VLANs properly might think "hey this thing is "clever", sure we could, but that is not a good thing!

Hey,

Long time.

I agree. We are pulling all our Toughswitches and have already ordered your 12 port switches. They are all going in at our sites this month to accomodate higher power demands of AF24, Metrolinq, and Mimosa.

The main towers basically has to accept and forward all the Vlans we have. Each of our CPEs are natted over a different vlan, so each time we add a site to one of our legs, we have to simply just add a new vlan to our cisco switch ports (and any cisco switches in the chain) but the toughswitches were good about making sure the vlaned data goes over the right port and doesnt broadcast it everywhere. (we had an issue where we had an extra vlan added to a trunk of one of our cisco switches, and we had so much broadcast data corrupting the networks down the chain, it was VERY odd)

So, since we have to specify the vlans on each port, IF we said say Vlan 13-300 were on ALL ports, would the switch still block data that is not destined for that direction? or would it forward broadcast everywhere, etc?

forgive me if my terminology isnt spot on. I get that we should have been more elegant with our switch configs. We liked how the toughswitch handled the mac table without having to enter vlans per port. Our cisco switches handed ingress/egress well, and i assume the toughswiches werent sending data in the wrong way based on the useage rates per port.

I dont want to be stuck mapping all our vlans out per port, but if i have to to prevent broadcast or other packets from going up the wrong port, i want to know.

===

In my scenario, will i be data efficient, telling ALL ports on the switch to trunk vlan 13-300 for example? If we use the SAME vlan configs downstream, will the down stream switch be ok if some upstream vlans are specified on its ports too?

As always, I appreciate your input Sirhc

No, the ToughSwitch was not good at sorting VLANs, that is not what it was doing but I am not going to get into that. I know the the capabilites of the BCM-53118 switch core and it does not have the ability to "learn" where VLANs go.

But I digress, if you look at the VLAN Tab there is a Checkbox called "Trunk Port / Allowed VLANs" above each port.

You can then define a list of allowed VLANs for that port but remember you need to add that list to both the ingress and egress port or the packet will be dropped.

A list can be like this is you want "100-200,205,217,1000,-1925,4012"

CLICK IMAGE BELOW TO VIEW FULL SIZE

I am very appreciative of your response since I am adding these fancy new switches next week monday.

lets not talk about the toughswitches anymore :) They are going in a box and will be used somewhere as an indoor access point injector. lol.

So, IF i add 1-4000 to ALL the ports, and at towers behind our main tower, am i good? (not elegant, but not broadcasting data the wrong way?)

can you also specify where i configure the ingress and egress port on netonix? (or where you referring to my other switches down stream)

givemesam wrote:I am very appreciative of your response since I am adding these fancy new switches next week monday.

lets not talk about the toughswitches anymore :) They are going in a box and will be used somewhere as an indoor access point injector. lol.

So, IF i add 1-4000 to ALL the ports, and at towers behind our main tower, am i good? (not elegant, but not broadcasting data the wrong way?)

can you also specify where i configure the ingress and egress port on netonix? (or where you referring to my other switches down stream)

LOL - You can talk about ToughSWITCH just do not call them "clever"
The ToughSwitch is a nice little switch good for many things such as camera installs, and even small towers and such just not designed for heavy tower applications "in my opinion"

PLEASE set these up in a LAB and verify your configs will work because the time to ask questions is before you install them, so many people just jump right in and deploy them before playing with them and verifying their configs work as intended then they call me all frantic because their tower is down.

we will.

i will test it at our main tower, with a smart switch in hand, and change its vlans and move it around the ports to make sure it passes traffic and such, my ip changes whenever my vlan changes, etc. Hard to simulate some things on the bench though.

As long as i can get a confirmation that the setup i asked about is all good data wise, and we are not going to send data down the wrong chains before it gets blocked by our downstream switches, im good.

Can you clarify trunking 1-4000 is all good on all ports? And if we have another once doing the same down stream, we will not be passing traffic the wrong way?
Hoping the mac table in the switch will get which vlan goes where without specifying it explicitly.

Also, about my question to clarify where you were referring to about ingress/egress.

Thanks!