VLAN Tagging on Rocket M5 and NanoStation M5

[jsmithkc]

I have been reading that the NanoStations support VLAN tagging, and I wanted to clarify that the Rocket M5 in AP mode will support this as well.

From our Cisco Switch, we would set the port into trunking mode with a native vlan that the ip of the access point would sit on.

Do we need to modify the AP in any way or just the Nanostation M5 (Subscriber)?

We don't do any NAT'ing, just simply a management vlan for the Subscriber device, and passing thru vlans for each customer.

Example would be:

vlan 10 as the management vlan, with the sm ip as: 10.10.50.100
and vlan 20 as the customer vlan, which their router would get a public ip via DHCP on our network.

Any examples would be greatly appreciated!

Thanks,

Jordan Smith

[UBNT-Mike.Ford]

I have been reading that the NanoStations support VLAN tagging, and I wanted to clarify that the Rocket M5 in AP mode will support this as well.

From our Cisco Switch, we would set the port into trunking mode with a native vlan that the ip of the access point would sit on.

Do we need to modify the AP in any way or just the Nanostation M5 (Subscriber)?

We don't do any NAT'ing, just simply a management vlan for the Subscriber device, and passing thru vlans for each customer.

Example would be:

vlan 10 as the management vlan, with the sm ip as: 10.10.50.100
and vlan 20 as the customer vlan, which their router would get a public ip via DHCP on our network.

Any examples would be greatly appreciated!

Thanks,

Jordan Smith


Hello,

We only support VLAN passthrough. We do not support physical VLAN taggin on our devices.

Thanks,

MIke

[ether3al]

We have got VLANs running on our network that is running Microtik AP's and NSL5 CPE's. One Management and one for customers.
This was achieved by bridging the ethernet port to the customer VLAN on the wifi interface (VLANs are configurable by changing keys vlan.clientvid=782 and vlan.managementvid=781 in the ubiquiti config file.)

Correct me if im wrong but I dont see why this would not work on AirOS5.

[cam]

I think what he is trying to do is have a separate VLAN per customer, which is not possible without a "SMART" device on the other end of the "Nano".

VLAN Passthrough is great to have, but if not a hard challenge VLAN tagging would be pretty smooth move to compete with the larger carrier grade companies such as Alvarion.

[jsmithkc]

This is exactly what I want to accomplish. Having a private IP for the radio on our management vlan, and a vlan on the ethernet interface which will passthru the tag to our switches and routers.

[spirited]

+1(0000000000)

[ether3al]

jsmithkc,

To achieve that just follow the instructions in my previous post.

[ciphercore]

We have got VLANs running on our network that is running Microtik AP's and NSL5 CPE's. One Management and one for customers.
This was achieved by bridging the ethernet port to the customer VLAN on the wifi interface (VLANs are configurable by changing keys vlan.clientvid=782 and vlan.managementvid=781 in the ubiquiti config file.)

Correct me if im wrong but I dont see why this would not work on AirOS5.



Would you be able to post an example system.cfg ?

[twinkletoes]

jsmithkc,

To achieve that just follow the instructions in my previous post.

yeah but you are running airos 3 on your locos

has anyone tried this with airos 5? ubnt said they were still writing the functionality

[ciphercore]

If someone could clear this up, that would be great. Myself... I have 2 BulletM5's doing a PtP.

I would like to have a management vlan to, well manage the Bullets. The remote side will be a security camera system.

Can this be done in Air OS5 ? (CLI)

If so does it require router mode or can it work in bridge (WDS) ?

Does anyone have any examples of working vlan tagging in air os 5 ?

[spirited]

This seems to be the buzz on the forum, yet UBNT team has told me that there are other priorities. Honestly, i think this is a huge one, but thats because its my need.
I have seen lots of posting on OS3.5 about this and have lab setup to get this to work.
Is anyone else actively working on it on lab or out in the field?
I need to be able to have AP that passes multiple vlans (10-20) which would plug into a trunk port on Cisco switch, with common management vlan, say vlan 5. Then have cpes having ability to have same management vlan5, an have vlan10 or vlan 11, or ....etc
I assume this will only be able to be done in bridge mode, using WDS....

[ether3al]

Ciphercore,

These are the exact lines in the system.cfg file to enable a client VLAN and a Management VLAN:
vlan.clientvid=xxx
vlan.managementvid=xxx

I am going to try and squeeze in some testing of this functionality in AirOS5 this week.

[jsmithkc]

With the vlan.clientvid and the vlan.managementvid set, will the settings be overwritten if I change something in the GUI or do a firmware upgrade?

[ciphercore]

Ciphercore,

These are the exact lines in the system.cfg file to enable a client VLAN and a Management VLAN:
vlan.clientvid=xxx
vlan.managementvid=xxx

I am going to try and squeeze in some testing of this functionality in AirOS5 this week.

I will give it a try sometime today/tomorrow and let you know.

[ether3al]

With the vlan.clientvid and the vlan.managementvid set, will the settings be overwritten if I change something in the GUI or do a firmware upgrade?
Making changes in the GUI will only alter lines in system.cfg that the GUI is associated to. So no making changes in the GUI will not remove the vlan configs

Ciphercore,

How did your testing go?

[ciphercore]

Making changes in the GUI will only alter lines in system.cfg that the GUI is associated to. So no making changes in the GUI will not remove the vlan configs

Ciphercore,

How did your testing go?
I wasn't able to get it working. I had the main sys admin here give it a go as well, but no luck. We tried both using the system.cfg and writing to mem.... also tried manually using vconfig.... and also with scripts.

[ether3al]

Yeah i tried it also and couldnt get it working... :( sigh!

Cmon UBNT we need VLANs!!!

[spirited]

+1,000,000

[jmbo]

+ 99999999999999999999999999999999999999999

;-)

[UBNT-Mike.Ford]

Hey Guys,

This is something I am pushing for as well. I will let you know when I know.

Thanks,

Mike

[spirited]

Many thanks, I am willing to help by setting it up in our lab. Let me know if I can be of any assistance...

[ciphercore]

I would be willing to test as well. We have a few extra pairs of BulletM5HP's.

[maxman]

We have tried using these Radios and currently have an issue as follows.

In WDS mode using 2 VLANs, any devices behind the second VLAN switch gets dropped in the Radios MAC table. The only way to reach those devices from the upstream side, is you have to source traffic from the remote device. Once the link has been rebooted, or an ARP, any device that is secondary gets dropped.

This will not work for VPN's or any other type of Layer 2 traffic you are trying to do, so these radios really do not pass layer 2 traffic - unless there are settings we are not aware of??

Upstream>AP>SU>Transparent device(VLAN1)>Switch(VLAN)2> *device*

(To Clarify: the radio's do see the device behind the switch - "BUT", they see the device with the MAC address of the "switch port") We assume that is because the VLAN is native on the switch - and the Radios only see the ports on the switch - "UNTIL" you source with the device on outbound traffic. Then the device and its MAC match, the Radio sees it, and traffic flows. And this works - until an aging MAC drop, ARP, or you reboot the radio - then again you have to source from the device or you cannot reach it.

Here you can see, the device on the end of this losses its MAC in the Radio link - if for any reason it is rebooted, or there is an ARP. The only way to get to the *device* is to source outbound traffic.

[quantumx]

I'm seeing the same problem, but also seems to affect 3rd, 4th, etc. VLANS.

We have tried using these Radios and currently have an issue as follows.

In WDS mode using 2 VLANs, any devices behind the second VLAN switch gets dropped in the Radios MAC table. The only way to reach those devices from the upstream side, is you have to source traffic from the remote device. Once the link has been rebooted, or an ARP, any device that is secondary gets dropped.

[maxman]

We are currently installing an additional switch on the remote side, just to get seperation between us and the customer. And to see if it will help store the MAC of the devices on the Second VLAN. Not sure how well this will work though.

I would assume your seeing your devices, but they have the same MAC as the port on your switch - that is - until you source from your device?

[maxman]

Installing an additional switch did not fix the issue.

Ubiquiti??

[UBNT-Edmundas]

Can you prepare network topology drawing, which will help us quickly understand your setup, that we could recreate it in our lab?
Thanks!

[petecarlson]

I am seeing the exact same problem here.

G (Rocket) is AP side of WDS link
H (Rocket) is Client side of WDS link.

On VLAN 10, ARP resolution is not possible from A to B but works fine from B to A.

On VLAN 1 (non tagged traffic) ARP resolution works fine in both directions.

In reality there are multiple devices on the B side and a router on the A side.

This is a major issue for us. Please let me know if you need any additional information.

[maxman]

Here is our set-up.

Initial setup:

[ SW1 ] <--> [ AP-WDS ] <-/\/\/\/\/\/\/\/-> [ Sta-WDS ] <--> [ CPE ] <--> [ SW2 ] <--> [ PC ]

Second setup:

[ SW1 ] <--> [ AP-WDS ] <-/\/\/\/\/\/\/\/-> [ Sta-WDS ] <--> [ SW3 ] <--> [ CPE ] <--> [ SW2 ] <--> [ PC ]

The switches are all Cisco 2940-8TT-S. The CPE is an Adva 825.

The link from SW1 has three VLANs, one native and two tagged. The CPE uses one of the tagged VLANs and passes the other one through (completely transparent, as far as we can tell).

The problem we are having is that the management MAC address of SW2 is getting dropped and then can't be found from the SW1 side. Adding SW3 between the Station and CPE device didn't help any.

[konrad]

I cannot confirm this problem.

Used setup was similar to the one pictured above.

Two 3com 4400 switches with vlan cap. and 2 NS M5's as the transparent bridge, one in ap wds and other in client wds mode. On the remote side i used one bullet 2 as a pingable "pc", on the local side the rest of my network.

Switches have been configured two ways, first the ports connected to nanos were set fully tagged for all tested vlans (means 1 and 10 and 3000).

Everything was pingable, both ways. Except the nanos themselves ofcourse, since ports were tagged.

Later i configured vlan 1 as tagged on ports connected for nanos, as in the described problem. Now nanos were pingable from vlan1. Also the end bullet was pingable from vlan 10. So everything was working as expected.


I don't have the CPE device of any sort, but to investigate it further i would put some kind of monitoring device into the network, be it a linux pc, equipped with 2 NIC's, it just has to have packet capture capability. This way you can accurately pinpoint the ongoing problem.
I prefer tshark for the job.

Hope it helps and you get it sorted.

[maxman]

I dont believe you are correctlly simulating the issue here.

You need to create a Native VLAN on a switch device on the remote end, back into your network. Then create your VLAN's on that switch for your devices.

Please re-review our layout.

[maxman]

Any updates from the UBNT support group on this issue?

Thanks,

[petecarlson]

I cannot confirm this problem.

Used setup was similar to the one pictured above.

Two 3com 4400 switches with vlan cap. and 2 NS M5's as the transparent bridge, one in ap wds and other in client wds mode. On the remote side i used one bullet 2 as a pingable "pc", on the local side the rest of my network.

Switches have been configured two ways, first the ports connected to nanos were set fully tagged for all tested vlans (means 1 and 10 and 3000).

Everything was pingable, both ways. Except the nanos themselves ofcourse, since ports were tagged.

Later i configured vlan 1 as tagged on ports connected for nanos, as in the described problem. Now nanos were pingable from vlan1. Also the end bullet was pingable from vlan 10. So everything was working as expected.

Hope it helps and you get it sorted.

I don't think your setup is going to dup the problem.

Set port 1 on both switches a a trunk ports. allowed vlan add 2, 3, 4, 5. Connect switch 1 port 1 to the AP-WDS rocket and switch 2 port 1 to the Client WDS rocket.

On the first switch set port 2 as a trunk port and allow vlans 2, 3, 4, 5 connect it to a cisco router and add vlan interfaces 2, 3, 4, and 5. ad IP addresses to each vlan and the native interface. The native interface should be in the same range as the Rockets. Run a dhcp server on each vlan.

On the second switch set ports 2,3,4,5 as trunk ports. tag them native 2,3,4, and 5. Connect a bunch of client devices to each port by either connecting another switch to each port or a bridged AP to each port and a bunch of clients to each AP. Have the clients get DHCP and make sure each one is connected. Now wait 24 hours and try to ping the clients from the other side of the router.

UBNT, please help. or ask me what you need me to test or send you. I am quite familiar with ebtables.

[UBNT-Mike.Ford]

Hello,

I have ased my software team to jump back in this thread.

Thanks,

Mike

[petecarlson]

Thanks Mike, I look forward to getting this issue resolved.

[UBNT-Edmundas]

I don't think your setup is going to dup the problem.

Set port 1 on both switches a a trunk ports. allowed vlan add 2, 3, 4, 5. Connect switch 1 port 1 to the AP-WDS rocket and switch 2 port 1 to the Client WDS rocket.

On the first switch set port 2 as a trunk port and allow vlans 2, 3, 4, 5 connect it to a cisco router and add vlan interfaces 2, 3, 4, and 5. ad IP addresses to each vlan and the native interface. The native interface should be in the same range as the Rockets. Run a dhcp server on each vlan.

On the second switch set ports 2,3,4,5 as trunk ports. tag them native 2,3,4, and 5. Connect a bunch of client devices to each port by either connecting another switch to each port or a bridged AP to each port and a bunch of clients to each AP. Have the clients get DHCP and make sure each one is connected. Now wait 24 hours and try to ping the clients from the other side of the router.

UBNT, please help. or ask me what you need me to test or send you. I am quite familiar with ebtables.

The problem appears only after some time, when clients comes to idle state and you don't see such behavior just after you create this network setup? If you reboot STA-WDS device does your network starts working OK again?

[UBNT-Edmundas]

UBNT, please help. or ask me what you need me to test or send you. I am quite familiar with ebtables.

Couple things to test:

1. Enable Extra reporting on AP-WDS and STA-WDS
2. On AP disable auto WDS option and add STA MAC address as peer.
3. Configure AP-WDS <-> AP-WDS PtP link with peers added and auto disabled. (Please note, that WPA/WPA security will not work between two AP-WDS devices, if you are using, you will need to disable it or chose less secure WEP security method)

Let me know about your results by e-mail edmundas@ubnt.com.

[torgeirb]

We're experiencing VLAN trouble as well.
Setup like this
Cisco SW w/trunk <--> Bullet M5 <------>Bullet M5<--> Cisco SW w/trunk ---> CPE vlans
Our native vlan works, and it's passing some traffic on other vlans. At CPE side, DHCP works and echo requests will be passed, but when you try to open a webpage for example. You can't get any data through. It just stalls.

As this is a major error we had to reinstall our old setup. At this point these devices are useless as PtP links.

Any updates on this issue are welcome.

[UBNT-Mike.Ford]

Hey Guys,

My software team informed me that the VLAN patch did not make it into V5.1-Beta. we are going to put it back in with V5.1-RC

In the meantime I woudl suggest going back to V5.0.2 so VLAN's work properly.

Thanks,

Mike

[spirited]

do u have approx date?

[UBNT-Mike.Ford]

do u have approx date?


No, but they are working on it currently.

Thanks,
Mike

[maxman]

Hey Guys,

My software team informed me that the VLAN patch did not make it into V5.1-Beta. we are going to put it back in with V5.1-RC

In the meantime I woudl suggest going back to V5.0.2 so VLAN's work properly.

Thanks,

Mike

So are you saying that the old Firmware will not have any issues?

Thanks,

[UBNT-Mike.Ford]

So are you saying that the old Firmware will not have any issues?

Thanks,


Hello,

The old firmware just does not allow for use of AutoACK.

Thanks,

Mike

[maxman]

Ok, I understand the Auto-Ack, but it will not fix the dropped mac problems - correct?

Any update on that you can share?

Thanks,

[UBNT-Mike.Ford]

Ok, I understand the Auto-Ack, but it will not fix the dropped mac problems - correct?

Any update on that you can share?

Thanks,


Hello,

This is correct.

Thanks,

Mike

[qwp]

VLAN tagging does not work on NS M5 on eth1_real (packets bigger than 1496 are dropped). I have tried transparent bridge br0 created by default settings and bridge created by rc.poststart (eth0_real.111 + eth1_real.111). I have tried fw v5.0.2 and v5.1b2 and the same problem.

my /etc/persistent/rc.poststart:

route del default gw 0.0.0.0
#
ifconfig br0 down
brctl delbr br0
#
vconfig add eth0_real 111
ifconfig eth0_real.111 up
#
vconfig add eth1_real 111
ifconfig eth1_real.111 up
#
brctl addbr br0
brctl addif br0 eth0_real.111
brctl addif br0 eth1_real.111
#
ifconfig br0 10.0.111.42 netmask 255.255.255.0 up
route add default gw 10.0.111.1

Matt

[spirited]

Mike and Company? Any word on the larger MTU packets?

[UBNT-Mike.Ford]

Mike and Company? Any word on the larger MTU packets?


Hello,

This is the first report anyone has posted about Beta2 not passing larger frames. Everyone elses issues have been resolved and VLAN's are passing.

Can you give us access to the unit?

Thanks,

Mike

[maxman]

"Everyone elses issues have been resolved" ??

Was there a fix to the MAC dropping problems I may have missed?

Thanks,

[maxman]

Any update on the VLAN dropping MAC issues?

Thank you,

[UBNT-Edmundas]

Any update on the VLAN dropping MAC issues?

Thank you,

Are you already using v5.10-beta2 firmware?

[veresk]

Yes, on Firmware Version: XM.v5.1-beta2.3269.091127.1805
Build Number: 3269
first ping in non native vlan lost too.
Can you give me documents about command line in device. I want try some workarround.For ptp link "hub mode without mac table" may be temporally solution..

[maxman]

We have just changed the Radios to AP/WDS--AP/WDS to see if this helps with the MAC dropping issues on the VLAN's.

Does the new Firmware upgrade matter what configuration we try in WDS?

Is there any issues with Packet size with the new firmware?

Where do I get the new firmware?

Thanks,

[veresk]

"Is there any issues with Packet size with the new firmware?"
Big packet succesful work with beta2.
Im try ap-wds-ap-wds -first icmp in vlan lost too,and not work wpa.
about beta2-try send letter to mike. Im want newest beta2 too, but mike dont answer to my letter..

[maxman]

How do I get the Firmware upgrade for the VLAN problems?

Thank you,

[maxman]

Found it..

Any updates on the VLAN issue though??

Thanks,

[rconaway]

I have a pair of Rockets set up and we are doing VLAN passthrough with no problems. I don't think that solves your problem but I figured I would throw that in.

[veresk]

Are you send packet in network with management ip rocket or in different vlan and network?
First broadcast frame with vlan tag is missing,if rocket havent sender mac addres in mac table-on sniffer i see that packet sent from pc1 but dont arrived to pc2. next frame send good. when mac dissapear from rocket table (timeout or reboot rocket) first broadcas lost too. May be you have newst firmware, can you give it to me?

[rconaway]

The VLAN's are on the switches. The radios are simply bridging between them.

[veresk]

Are you try broadcast on not native vlan? I suppose that rocket have mac-port table per vlan (as mike say "vlan support in ethernet driver") and have bug in mac table learning process.

[veresk]

mike,rconaway what firmware you use, how can i see arp table on device?

[UBNT-Edmundas]

mike,rconaway what firmware you use, how can i see arp table on device?

Bridge MAC table you can see executing shell command "brctl showmacs br0" and ARP table on device "cat /proc/net/arp".

[maxman]

Has a patch been released for the MAC issue? Anything else we can try?

Thanks,

[UBNT-Edmundas]

Has a patch been released for the MAC issue? Anything else we can try?

Thanks,

maxman, I have sent you an e-mail with test image. Please write me back with your findings.

[maxman]

I have not recieved the email as of yet??

Thanks,

[RavenWing71]

VLAN tagging does not work on NS M5 on eth1_real (packets bigger than 1496 are dropped). I have tried transparent bridge br0 created by default settings and bridge created by rc.poststart (eth0_real.111 + eth1_real.111). I have tried fw v5.0.2 and v5.1b2 and the same problem.

Matt

Hello,

This is the first report anyone has posted about Beta2 not passing larger frames. Everyone elses issues have been resolved and VLAN's are passing.

Can you give us access to the unit?

Thanks,

Mike

Mike,

We have just experienced what qwp is seeing. It only shows up on the Secondary Ethernet port of the Nanostation M5.

The setup:
From a DLink DGS-3612G Managed Switch we have a VLAN trunk connected to a Rocket M5. Connected to this first RM5 we have a NM5. On the NM5's Main Ethernet port we have a Cisco 3524 with stuff on it. On the NM5's Secondary Ethernet port we have another Rocket M5 passing the trunk along. There are no rc.poststart scripts so far.

Now we add 2 NM5s attached to the first RM5 and 2 NM5s attached to the second RM5 that select data VLANs using rc.poststart scripts. I'm going to call these NM5-Vs to indicate the VLAN scripts. For simplicity we choose to keep the Management on the Data VLAN. All of the radios are running 5.1 Beta2. We did try downgrading to 5.0.2 on all the radios from the simple NM5 out, but it didn't fix the problem.

The problem:
We can talk to all of the stuff on the various VLANs on the Cisco just fine once Multicast Data: Allow All is checked. We can log into NM5-Vs attached to the first RM5 just fine.

We can't log into the NM5-Vs attached to the second RM5 through HTTP. We can SSH to them. AirControl talks to them just fine. We can ping them so long as the ping packets don't get too big. Using windows ping -L, 1468 gets through, 1472 does not. This agrees with qwp's limit of 1496. Which is Ethernet's 1500 byte MTU minus VLANs 4 bytes.

The Solution so far...
We pulled a 3rd wire through the 60' of 12" conduit this morning to connect the second RM5 to the Cisco and now the problems with the NM5-Vs attached to it are gone.

[spirited]

Has any tested the Bullet?
What is the large MTU that this will allow in bridged mode?

[RUok0101]

I have a PtP link I am setting up with two NSM5's that will need to have VLANs running over them. I am using RB750G's on each side to deal with the trunking and splitting VLANs out into different ports.

I am running 5.1beta (PM'd Mike to try and get beta2) and am having issues. I was wondering if anyone could confirm my problem is the same as everyone else is having.

I have enabled the Allow All for Multicast and I no longer have packet loss like I originally had. My issue though is packets of 1500 will not pass through. I expect this is because of the extra bytes for the 802.1Q info. I thought I could ssh onto the NSM5s and up the MTU to 1520-ish but it wont let me set a size over 1500.

XM.v5.1-beta.3207.091120.1938# ifconfig eth0_real mtu 1501
ifconfig: SIOCSIFMTU: Invalid argument

XM.v5.1-beta.3207.091120.1938# ifconfig eth0_real mtu 1500
XM.v5.1-beta.3207.091120.1938#

How are people able to use "VLAN Passthru" effectively with the NSM5 ethernet card not letting a 1504 byte packet in? Smaller packets work fine with this VLAN setup, but in the real word, people are going to expect "full size" ethernet packets to be able to pass across the link.

[UBNT-Edmundas]

I have a PtP link I am setting up with two NSM5's that will need to have VLANs running over them. I am using RB750G's on each side to deal with the trunking and splitting VLANs out into different ports.

I am running 5.1beta (PM'd Mike to try and get beta2) and am having issues. I was wondering if anyone could confirm my problem is the same as everyone else is having.

I have enabled the Allow All for Multicast and I no longer have packet loss like I originally had. My issue though is packets of 1500 will not pass through. I expect this is because of the extra bytes for the 802.1Q info. I thought I could ssh onto the NSM5s and up the MTU to 1520-ish but it wont let me set a size over 1500.

XM.v5.1-beta.3207.091120.1938# ifconfig eth0_real mtu 1501
ifconfig: SIOCSIFMTU: Invalid argument

XM.v5.1-beta.3207.091120.1938# ifconfig eth0_real mtu 1500
XM.v5.1-beta.3207.091120.1938#

How are people able to use "VLAN Passthru" effectively with the NSM5 ethernet card not letting a 1504 byte packet in? Smaller packets work fine with this VLAN setup, but in the real word, people are going to expect "full size" ethernet packets to be able to pass across the link.

You need v5.1-beta2 to get this problem solved. You can e-mail to me (edmundas@ubnt.com) and I will send firmware to you.

[rconaway]

What's odd is that we are running VLAN's across a Rocket bridge with 5.1. We are using AP+WDS mode with bridging.

[UBNT-Mike.Ford]

Hey Guys,

Please update to V5.1-RC3 I posted today, it should alleviate the issue.

Thanks,

Mike

[veresk]

Thanks. with beta3 first ping succesful on my lab. Mike,can you tell about airmax priority? it work between station, and therefore its not wmm..access point sent polling marker to station with "high priority" with smaller polling cycle?airmax priority is "priority querry" or "weight querry".client station support wmm and send voice data first in her polling time?

[UBNT-Mike.Ford]

Thanks. with beta3 first ping succesful on my lab. Mike,can you tell about airmax priority? it work between station, and therefore its not wmm..access point sent polling marker to station with "high priority" with smaller polling cycle?airmax priority is "priority querry" or "weight querry".client station support wmm and send voice data first in her polling time?

Hello,

If you have 2 units set to high priority, and 2 units set to low priority, the high priority units will be given longer time slots to transmit, effectively increasing performance and latency for that client (ie Business clients, VOIP clients)

Thanks,

Mike

[veresk]

"will be given longer time slots" but another clients also can send data- "weight querry"..if i have 50 mbit sector,25 hi priority and 25 medium priority client.ebery client want 10 mbit. how much more traffic can pass "hi priority client" (what weight has querry for hi ,medium, low and non priority abonent)

[mspicer]

Hey all,

Has there been any new developments with VLAN tagging? I have been following this thread and haven't seen anything new. I have VLAN pass through working fine with 2 Rocket M5's that are connected to cisco switches at either side. All of my trunks work fine.

I really need NSM5 vlan tagging for CPE. Right now I don't have any management over the CPE... Except for getting on my internet vlan and setting an IP in the range... which is a pain.

Thanks,

-Mike

[spirited]

+!!!!!!!!!

[maxman]

Mike, I cannot find the download for V5.1-RC3?

Also, is this the final fix for multiple VLAN passthrough?

Thanks,

[spirited]

Maxman, you can indeed pass multiple vlans on the RC3, the issue is that you can't seem to have native vlanning on the devices in order to manage radios on separate vlan/subnet.... This is what may separate this product from smart geeks deploying, to a more accepted solution in the industry.
(the last part was my 2 cents and that was at no charge : )

[maxman]

I still cannot find the V5.1-RC3 update to download? And does if finally fix all the issues with the MAC's on multiple VLAN's?

Thank you!

[UBNT-Mike.Ford]

I still cannot find the V5.1-RC3 update to download? And does if finally fix all the issues with the MAC's on multiple VLAN's?

Thank you!


V5.1 was release so V5.1-RC3 is no longer neccessary

[Snowie]

You can’t VLAN tag at the Ethernet port of the CPE for some reason that doesn't work with the M series equipment (You can with the 802.11 series nano stations see here (http://www.ubnt.com/forum/showthread.php?t=10238&highlight=vlan+scripts) This doesn’t work on the M series. I’m not sure why seems there’s some fundamental difference between them).
You can still use a management VLAN for the M series though.

On the CPE:

If in bridge mode add the following to the /etc/persistant/rc.poststart file

vconfig add br0 25
ifconfig br0.25 10.200.6.2
netmask 255.255.0.0 up route add default gw 10.200.1.1 br0.25

(Its fairly self explanatory search other posts. Also google the linux commands vconfig, ifconfig and brctl for more info)

save and reboot :

cfgmtd -w -p /etc/
reboot

You will also have to do something similar on the base station that the CPE is connected to allow the VLAN to pass-through that.

How we do it is we set up a hybrid port on a switch that we plug the base station. We then set the port to tag untagged traffic (IE the traffic from the Ethernet port of the CPE)on to a particular VLAN. We then allow it to pass the management VLAN for the CPE.

This setup doesn’t allow a different VLAN for every customer but it does allow you to separate management traffic from customer data traffic.

I hope this helps.

[Snowie]

Does anyone know the difference between the 802.11 series and the M series why tagging at the Ethernet port is not possible on the M series? (It should be possible using the same method as for the 802.11 series nanos, but for some unknown reason its not!)If any one could point me in the right direction I could look at pulling apart the SDK and creating a custom piece of firmware. Any help would be appreciated.

[Stu]

It appears there is still inconsistent behaviour between Main and Secondary ports of Nanostation M5s (v5.1 firmware) with respect to VLAN tagging.

When VLANs are used on Main, large packets (1500-bytes) can pass and are tagged correctly. When VLANs are used on secondary, large packets do not pass i.e. they still appear to have the VLAN tag stripped.

My setup is Mikrotik router -> NS M5 ---bridge---NS M5 -> Mikrotik router
with 3 VLANs passed through and one management VLAN created on br0 on each NS. A bandwidth test from MT box to MT box (1500 byte packets) will succeed when:

- both NS M5 units are connected to Main OR
- VLAN tagging is not used

When VLAN tagging is used on secondary, the bandwidth test fails.

I believe that there is still an issue with VLAN passthrough on Secondary in release 5.1. This is a significant issue as it has an impact on cabling topology as well as network routing design.

[ambruzzi]

Hi Gays!

I need help testing the vlan separation rocketm5 and mt router.
The rocket m5 connect the mt router eth port and add vlan port but not answer send icmp package:
rocket m5 config:

vconfig add eth0_real 111
ifconfig eth0_real.111 up
#
brctl addbr br0
brctl addif br0 eth0_real.111
#
ifconfig br0 10.0.111.42 netmask 255.255.255.0 up
route add default gw 10.0.111.1

mt router settings:
dd arp=enabled comment="" disabled=no interface=ether2_5ghz_korsugarzo mtu=1500 name=vlan1 use-service-tag=no vlan-id=111

I like use this setting only manage the rocket device,but the mt eth interface running pppoe server service.

Thank you the help.

Best regards

Krisztian
Kapulan Telecomm. Ltd

[foamz]

It appears there is still inconsistent behaviour between Main and Secondary ports of Nanostation M5s (v5.1 firmware) with respect to VLAN tagging.

When VLANs are used on Main, large packets (1500-bytes) can pass and are tagged correctly. When VLANs are used on secondary, large packets do not pass i.e. they still appear to have the VLAN tag stripped.

My setup is Mikrotik router -> NS M5 ---bridge---NS M5 -> Mikrotik router
with 3 VLANs passed through and one management VLAN created on br0 on each NS. A bandwidth test from MT box to MT box (1500 byte packets) will succeed when:

- both NS M5 units are connected to Main OR
- VLAN tagging is not used

When VLAN tagging is used on secondary, the bandwidth test fails.

I believe that there is still an issue with VLAN passthrough on Secondary in release 5.1. This is a significant issue as it has an impact on cabling topology as well as network routing design.

Hey Stu
I think I have a similar problem to what you have. What I have done though is change the MTU on a few on my M5's to 1492 and then they seem to work fine.
I should also add that this only seem to work a few of my M5's and not all of them, but there are other hardware factors I still need to work out.

ssh to the M5 and do:

ifconfig ath0 mtu 1492
ifconfig br0 mtu 1492
ifconfig br0:0 mtu 1492
ifconfig eth0_real mtu 1492
ifconfig eth1_real mtu 1492
ifconfig wifi0 mtu 1492

This probably not the best method, but I'll be doing more testing today.

[foamz]

Just make sure you test all your vlans after the change. I just noticed that our default vlan gave some issues on one M5. Changing it back to 1500 fixed, but now vlan 105 does not.

[Stu]

Changing MTU size does not have any effect for hosts on the same subnet as they cannot know how to change MTU since no router is involved.

I'll get a chance to test this more fully over the weekend and will post results.

[Ixholla]

Does anyone know if the M5's are going ot support larger frames? We have a need to set the MTU's to 1530 end to end for our situation. As is now unless there's a beta code out there we're going to have to replace the radios with some higher end ones in a very remote location.

[cwolff09]

I need vlan tagging at the CPE as well. Does anyone know if this is coming up in a future release?

[guibzh]

I don't think your setup is going to dup the problem.

Set port 1 on both switches a a trunk ports. allowed vlan add 2, 3, 4, 5. Connect switch 1 port 1 to the AP-WDS rocket and switch 2 port 1 to the Client WDS rocket.

On the first switch set port 2 as a trunk port and allow vlans 2, 3, 4, 5 connect it to a cisco router and add vlan interfaces 2, 3, 4, and 5. ad IP addresses to each vlan and the native interface. The native interface should be in the same range as the Rockets. Run a dhcp server on each vlan.

On the second switch set ports 2,3,4,5 as trunk ports. tag them native 2,3,4, and 5. Connect a bunch of client devices to each port by either connecting another switch to each port or a bridged AP to each port and a bunch of clients to each AP. Have the clients get DHCP and make sure each one is connected. Now wait 24 hours and try to ping the clients from the other side of the router.

UBNT, please help. or ask me what you need me to test or send you. I am quite familiar with ebtables.

Well I haven't seen this topic so I posted my own at the wrong place. I noticed that you are familiar with ebtables, perhaps you could help me with my little issue or anyone else:
Hi everyone,
My radio tests are done now and I decided to go with airmax product line.
So i'm working on the network design and I came out with something I'm now trying to configure.

I use 3 vlans:
vlan 1: data
vlan 10: admin
vlan 30: voice

I successfully passt vlan through my Ap (rocket M5) by bridging ath0 and eth0 and creating br0.1, br0.10 and br0.30.
Now I configured my cpe (NSM5) by unbridging every interfaces and creating ath0.1, ath0.10 and ath0.30. Then I bridged like this:
br0: ath0.1 + eth0_real
br1: ath0.30 + eth1_real

Everything is working great i can ping my router through each vlan.
Now I tried to enable IP forward from my ethernet (eth0) port by using ebtables.
I tried a lot of commands and it blocks EVERYTHING. It COMPLETELY IGNORES THE RULESET, the only thing it doesn't ignore is the policy: ebtables -P FORWARD DROP.

I tried:
ebtables -A FORWARD -p IPv4 -j ACCEPT
ebtables -A FORWARD -i eth0_real -o ath0.1 -j ACCEPT
ebtables -A FORWARD -i ath0.1 -o eth0_real -j ACCEPT

Another thing, I noticed that by default there is this set of rules and I don't really get what they do:
ebtables -t nat -A PREROUTING --in-interface ath0 -j arpnat --arpnat-target ACCEPT
ebtables -t nat -A POSTROUTING --out-interface ath0 -j arpnat --arpnat-target ACCEPT

When I use them I forward everything and it's not what I want. I just want port eth0 to be able to use vlan1 and eth1 be able to forward on vlan 30 and vlan10 not forwarded.
Well thanks for your help.

Guillaume

[ambruzzi]

Hi gays!


Someone testing the m5 series vlan support to mikrotik vlan support eth interface?

rb450(eth1)--(vlan separation)----bullet m5(eth0) .
Working to fine , please paste your configuration.

Thank you.

Best regards

Krisztian

[dd-wrt]

Hi,

since MT is mentioned here too:

with dd-wrt you can create use bridge vlans.

We just finalized and tested ns-m5, rocket-m5 and nanobridge m5 with our firmware.

We also tested that positive mtu 1500.

If somebody wants to test our latest version, let me know.

[UBNT-Mike.Ford]

Hi,

since MT is mentioned here too:

with dd-wrt you can create use bridge vlans.

We just finalized and tested ns-m5, rocket-m5 and nanobridge m5 with our firmware.

We also tested that positive mtu 1500.

If somebody wants to test our latest version, let me know.

Hello,

Just keep in mind DD-WRT is not compatible if you have AirMax turned on.

Thanks,

[adnan]

Hi.

I also have a problem with wlan tagging.I've established an point to point bridge connection with two nanostations M5, and when we pass through just IPTV service in Access mode on switch port It works excellent, but when we configure Switch port in trunking mode and try to pass other services as VoIP and Internet we have a problem with dropped packets and we can't establish even one service on the customer site.Please help, Is there any sollution for this problem.

Thanks in advance

[UBNT-Edmundas]

Hi.

I also have a problem with wlan tagging.I've established an point to point bridge connection with two nanostations M5, and when we pass through just IPTV service in Access mode on switch port It works excellent, but when we configure Switch port in trunking mode and try to pass other services as VoIP and Internet we have a problem with dropped packets and we can't establish even one service on the customer site.Please help, Is there any sollution for this problem.

Thanks in advance

What AirOS version are you using? Do you have the same issues ,when running v5.2.1-beta4?

[adnan]

Hi.I'll check It soon and replay to you Ok?

[adnan]

Hi.

Version is XM.v5.1.2. - build number 3998

[UBNT-Mike.Ford]

Hi.

Version is XM.v5.1.2. - build number 3998

Hello,

Please update to V5.2.1-Beta4 and test the link again. Please report your results once done.

Thanks,

[mrkh]

It is very important to support VLAN tagging, and not only provide transparent pasthrought. I tried every way to configure (based on linux experience of doing it), but no chance to work it out.
I tried it also without Airmax, without Agregattion.

[JLR]

We use the mikrotik RB750 on the cpe end as a router and to tag the customer vlan. All the radios in the system are just bridged. cost about $40 us

[mrkh]

Using other equipment to end user its not an option. It is too simple to support VLAN taggin in todays linux based equipment, mostly all equipment vendors like, alvarion, proxim, mikrotik and even UBNT on non-M products supports vlan.

[neo177]

okey, so, if I understand it correctly. NanoStation 5M supports VLAN pass through but, can't tag packet itself?

[UBNT-Mike.Ford]

okey, so, if I understand it correctly. NanoStation 5M supports VLAN pass through but, can't tag packet itself?

Hello,

Until V5.3 gets released, this is the way it works.

Thanks,

[darren]

Any idea when that is ? Its been 2 - 3 weeks for a couple of months now.....

Thanks
Darren

[luhiwu]

Hello,

Until V5.3 gets released, this is the way it works.

Thanks,

Will it have jumbo frames support or just vlan tagging?

regards

[thedeejay]

We have done some testing on Nano 5m with vlan passthrough.
With 5.1.2 packetloss was about 50%. (pinging 1458(1486) bytes)
With 5.2 no packetloss.

But... We have only about 10Mbit throughput with vlan tagged traffic.
Native traffic is about 70Mbit.

The config is 2x Nanostation M5, one in AP WDS and one in station WDS.
WPA2 AES psk...
Tried all sorts of settings...

Any suggestions?

/A

[UBNT-Edmundas]

Any idea when that is ? Its been 2 - 3 weeks for a couple of months now.....

Thanks
Darren

Lets first finish with v5.2.1 and only then talk about v5.3 release ;)

Thanks,
Edmundas

[UBNT-Edmundas]

We have done some testing on Nano 5m with vlan passthrough.
With 5.1.2 packetloss was about 50%. (pinging 1458(1486) bytes)
With 5.2 no packetloss.

But... We have only about 10Mbit throughput with vlan tagged traffic.
Native traffic is about 70Mbit.

The config is 2x Nanostation M5, one in AP WDS and one in station WDS.
WPA2 AES psk...
Tried all sorts of settings...

Any suggestions?

/Andreas

If you are testing with multicast traffic, then you should use v5.2.1-RC.

[thedeejay]

If you are testing with multicast traffic, then you should use v5.2.1-RC.

Thanks for quick reply.
No, unicast TCP.
tptest.sf.net on linux with tptestserver in one end and tptestclient in the other end.

[UBNT-Mike.Ford]

Will it have jumbo frames support or just vlan tagging?

regards


Hello,

Just VLAN tagging.

Thanks,

[Infolink]

It would be so nice to get this cleared up. could the UBNT master tech, please answer this?

[thedeejay]

We have done some testing on Nano 5m with vlan passthrough....

.... We have only about 10Mbit throughput with vlan tagged traffic.
Native traffic is about 70Mbit.


Should we use 5.2.1RC?
Any ideas why we have much worse perfomance with vlan tagged traffic?

/A

[WHT]

Lets first finish with v5.2.1 and only then talk about v5.3 release ;)
Of course when 5.3 is released, everyone will scream why you didn't just drop 5.2.1 and move straight to 5.3.

[UBNT-Edmundas]

Should we use 5.2.1RC?
Any ideas why we have much worse perfomance with vlan tagged traffic?

/A

Please try v5.2.1-RC2 and let us know your test results.

Thanks,
Edmundas

[maggiore81]

Please try v5.2.1-RC2 and let us know your test results.

Thanks,
Edmundas


news on this?
I too am planning to make some backhaul links in ptp bridge mode, and letting pass through a lot of tagged vlans... if the performances decrease, it could be a terribile day!!!

[spirited]

Any word on this?

[Helder]

Digite um texto ou endereço de um site ou traduza um documento.
Cancelar
OuvirTradução do português para inglês
I also find it very useful and import the VLA UBNT implement at least for port trunking, managed switch using today's minimum acceptable for any business to use today Rocket5 35Km link and it goes well, but lack access to client-side port trunking to complete network structure and making a lot missing, already had asked me to evaluate other equipment with wireless VLAN for this link.

I hope to reassess UBNT on VLAN must win because if they put new client who needs VLAN.


Thanks


Helder

[UBNT-Mike.Ford]

Hello,

Our first iteration of VLAN tagging will be in V5.3-Beta firmware.

Thanks,

[spirited]

Hello,

Our first iteration of VLAN tagging will be in V5.3-Beta firmware.

Thanks,

When is this slotted for release?

[WHT]

Two weeks ago Mike said beta would be ready in two weeks.

[UBNT-Mike.Ford]

Hey Guys,

I am hoping for the end of next week for V5.3-Beta.

Thanks,

[drwho17]

Can I pass VLAN tags through a station in router mode right now? If I setup a device with VLAN 30 will it get passed through the Station in router mode right now (with 5.2.xx). Before I mess around with it, I just wish to know.

[Superdust]

Will there only be management VLAN in this new FW, or will we able to untag a VLAN on the ethernet port also? :icon_mrgreen:

[drwho17]

Ah, I think I can run PPPoE as normal on the WAN, and also run a bridge on a VLAN for my VoIP stuff.

vconfig add eth0_real 100
ifconfig eth0_real.100 up

brctl addbr br0
brctl addif br0 eth0_real.100

Set my ATA to tag at 100, and see if I can hit it from the other side, would be excellent if this works, just need to find a way to get it in the config, so I don't have to upload it via rc.poststart to every radio.

[drwho17]

Will there only be management VLAN in this new FW, or will we able to untag a VLAN on the ethernet port also? :icon_mrgreen:
You can select a Tag on your WLAN or on your LAN.

[Superdust]

You can select a Tag on your WLAN or on your LAN.

I dont get it.
Normally one would want to have a management VLAN for reaching the CPEs, and untagging a VLAN on ethernet port so that the customer can connect his wireless router etc...

[drwho17]

You can TAG either your WLAN or your LAN through the GUI.

You select the PVID number and select whether you want this on the WLAN (management IP), or the LAN (customer traffic).

1 Interface will be tagged, 1 will be on the native VLAN, both will pass out over the wireless. You can either have your customer traffic behind the LAN tagged, or your Management network tagged from within the GUI.

[drwho17]

Now, if a linux bridge expert could tell me how to do the following, so I have something to start with.

I would like to add a bridge interface separate from the default eth0 bridge, that only handles a vlan tag, lets say 100, what do I need to include in that bridge group to make that happen. I want to handle untagged and tagged on eth0_real, with untagged going to the existing bridge setup on eth0 and NAT'ed. From research I think it should look like this, looking for feedback.

vconfig add ath0.100
ifconfig ath0.100 up
#
vconfig add eth0_real 100
ifconfig eth0_real.100 up
#
brctl addbr br0
brctl addif br0 eth0_real.100
brctl addif br0 ath0.100

Is this all I need to do to pass tagged traffic on VLAN 100 received on the LAN over the Ubiquity network? Will all vlan 100 traffic into the CPE go out the ath0.100 interface, that is what I'm looking to do. Separate my DATA traffic from my voice.

[900mhzdude]

we still going to get a beta tomorrow Mike? :)

[UBNT-Mike.Ford]

we still going to get a beta tomorrow Mike? :)

Negative, ran into some issues and its being pushed a week or two.

Thanks,

Mike

[WHT]

You select the PVID number and select whether you want this on the WLAN (management IP), or the LAN (customer traffic).I'm running VLAN on the customer side to keep them isolated.

But I'm open to other ideas. Like run mgt on VLAN and put the customer on a /2 subnet for isolation.

[oeyre]

I'm running VLAN on the customer side to keep them isolated.

But I'm open to other ideas. Like run mgt on VLAN and put the customer on a /2 subnet for isolation.Subnetting isnt going to stop users spewing trash onto your access network, consider the following approach:

-One VLAN for Infrastructure management
-Another VLAN for customer access

Then use a combination of client separation and clever bridging so that users can only talk "upstream", not to each other.

If you run PPPoE you can take this a step further by only allowing ethertypes 0x8863 and 0x8864 to keep your access segment free of user generated garbage. You can also stop broadcasts going towards the customer on the CPE so people can't run fake PPPoE servers.

[WHT]

-One VLAN for Infrastructure management
-Another VLAN for customer access
FW 5.3 only supports one VLAN, it can be either LAN or WLAN.

[oeyre]

FW 5.3 only supports one VLAN, it can be either LAN or WLAN.Well that is disappointing...

In that case you'd want to use untagged for management, and force users into VLAN.

[WHT]

Yeah...Most likely will VLAN the customer to sandbox his data/garbage, then PPPoE for account management, and CPE routing.

[oeyre]

Yeah...Most likely will VLAN the customer to sandbox his data/garbage, then PPPoE for account management, and CPE routing.Don't forget to filter out anything thats not PPPoE, really cuts down on the junk :)

And we haven't even got started on filtering garbage they send us via PPPoE...

[oeyre]

What kind of garbage you seeing or what's not PPPPoE you're seeing?
3 main places where you want to filter traffic:

1. Wireless access segment: between user and AP
2. IP access segment: LNS or aggregation router which is first hop for user
3. Network border: router(s) which connect your network to peering/transit

At wireless access segment the sort of garbage you see are rogue DHCP servers, Windows file sharing broadcasts, ARP, various other discovery protocols (bonjour, UPnP, etc), once I even saw someone trying to talk RIP. All trash which serve no useful purpose and should be blocked.

If you're using PPPoE then I can't think of a good reason why you shouldn't be filtering out non PPPoE frames. Take a look but be careful, its a jungle out there.

[WHT]

What kind of garbage you seeing or what's not PPPPoE you're seeing?What am I thinking?? I'm not even awake yet. Been up all night with a difficult unexpected night-time pregnancy that took two hours to deliver.

UPDATE: 85 pounds. Litter feller is doing fine now, he's even trying to run after momma.

[drwho17]

I'm running VLAN on the customer side to keep them isolated.

But I'm open to other ideas. Like run mgt on VLAN and put the customer on a /2 subnet for isolation.
Well, the Management VLAN is all that works at this point with the M Series, VLAN'ing on the LAN causes all kinds of havoc. Something isn't right there, I'm still working at it though.

I really want untagged into eth0_real to route out ppp0, and tagged 100 into eth0_real to route outside of ppp0, I think over ath0 should be fine (it should pass the tags, but maybe not). Still working it out, UBNT keeps crashing though.

[maggiore81]

news on this?
I too am planning to make some backhaul links in ptp bridge mode, and letting pass through a lot of tagged vlans... if the performances decrease, it could be a terribile day!!!

Any news in the 5.3fw about vlan passthrough?
Will be any performance impact in passthrough of vlan tagged traffic?

My ptp bridges are planned to let through a lot of tagged vlans, and if the tagged vlans are slow it will be terrible!

[doush]

I havent seen any performance decrease tagging VLAN on the LAN side with the development image.

But I will be testing more and report back.

[doush]

Well, the Management VLAN is all that works at this point with the M Series, VLAN'ing on the LAN causes all kinds of havoc. Something isn't right there, I'm still working at it though.

I really want untagged into eth0_real to route out ppp0, and tagged 100 into eth0_real to route outside of ppp0, I think over ath0 should be fine (it should pass the tags, but maybe not). Still working it out, UBNT keeps crashing though.

I didnt understand this.
What is the problem tagging VLANs on the LAN side ? Im using it now without any problems.

[drwho17]

I didnt understand this.
What is the problem tagging VLANs on the LAN side ? Im using it now without any problems.
With M series, and firmware 5-3? Are you doing tagged and untagged over eth0_real?

vconfig add eth0_real 100

ifconfig eth0_real.100 10.99.99.1 netmask 255.255.255.0

I put 10.99.99.2 on a linux box in VLAN 100 and can't ping between the two.

vconfig add ath0 100
ifconfig ath0.100 10.100.100.2 netmask 255.255.255.0

can ping 10.100.100.1 that is hooked up to a linux box on the other side of my wireless network on VLAN 100 fine.

What are you doing differently on the ethernet side? I've not focused on getting it to work, until the public 5.3 comes out, but I've alerted UBNT to these issues, and provided them logs/config, and they didn't say I was crazy.

[doush]

I have created the VLAN on the LAN by the GUI and I can ping without any problem with FW 5.3.

[900mhzdude]

I have created the VLAN on the LAN by the GUI and I can ping without any problem with FW 5.3.

I Hope they are bringing VLAN by SSID Not Eth Tagging there is not much of a point to that

[drwho17]

I have created the VLAN on the LAN by the GUI and I can ping without any problem with FW 5.3.
Yea, so what you said you were doing really doesn't have anything to do with what I was explaining.

When you enable the VLAN on the LAN in the GUI, you are taking untagged in on the ethernet (eth0 bridge of eth0_real.100 and eth1_real.100). This is not biggie.

I'm talking about taking tagged and untagged traffic in on the LAN side, and sending them out different interfaces. You are only forwarding all untagged traffic received at the eth0_real and forwarding it on and tagging.

[900mhzdude]

doush,

Where did you get the 5.3 firmware?

[UBNT-Edmundas]

doush,

Where did you get the 5.3 firmware?

We have some beta testers, who got v5.3-devel firmwares from me to confirm one or other problem fix.

-Edmundas

[900mhzdude]

We have some beta testers, who got v5.3-devel firmwares from me to confirm one or other problem fix.

-Edmundas

How Can I Become A Beta Tester? PM me if you want :)

[UBNT-Mike.Ford]

Hey Guys,

The firmware is now released, first thread at the top of the AirMax product forums.

Thanks,

[drwho17]

Yea, I'm thinking for what I want to do, I just need to work out ebtables. The UBNT's already do VLAN passthrough, I think I just need to create a second bridge interface "ath1", or subinterface, and get ebtables to look for a certain VLAN tag and route it out ath1, everything else just route normally. Can't find a whole lot of good info on ebtables vlan redirecting though, so it looks like some experimentation is required.

[wi2]

Hi, I am very new here, we intend to setup a Rocket M5 as Base Station and NanoBridge M5 as Client, PtMP. The Rocket M5 will connect to a cisco 2960 port configured as vlan trunk port which again trunk connect to series of switches/radio bridge/fibre link to a remote pppoe server in a data cetnre. Customer will install a pppoe router after the NanoBridge M5, which will pppoe connect the remote pppoe server in the data centre. Can this setup work? We still want to manage the Rocket M5 and clients NanoBridge M5 using the native vlan and assign the management IP, which is 10.x.x.x IP. The pppoe router will get a Public IP after connected.

[UBNT-Edmundas]

Hi, I am very new here, we intend to setup a Rocket M5 as Base Station and NanoBridge M5 as Client, PtMP. The Rocket M5 will connect to a cisco 2960 port configured as vlan trunk port which again trunk connect to series of switches/radio bridge/fibre link to a remote pppoe server in a data cetnre. Customer will install a pppoe router after the NanoBridge M5, which will pppoe connect the remote pppoe server in the data centre. Can this setup work? We still want to manage the Rocket M5 and clients NanoBridge M5 using the native vlan and assign the management IP, which is 10.x.x.x IP. The pppoe router will get a Public IP after connected.

It should work without any issues.

-Edmundas

[900mhzdude]

I put everyone code all in one thread for VLAN it was scattered all over the forum

hope it helps

http://www.ubnt.com/forum/showthread.php?t=24531