Good afternoon to all.

I have a mock up using a Nano Bridge M2 , Nano Bridge M5 and a Cisco 2950 switch.

The switch port in use are configured for vlan 2. The M5 DHCP has been disabled . This will allow the M2 to serve all DHCP addresses.

Problem :: Neither radio can see the other. no traffic is flowing between the radios

with a static address on the laptop I can connect to the M5 I don't see the M2 when I look at OLSR

dhcp on the M2 I connect and I don't see M5 in OLSR

Wireshark only shows the individual M2 & M5 . No coms between the two units . This is odd, what I have seen on previous captures of neighbor relations between nodes. 

The switch port needs to be configured as a dot1q TRUNK port on Cisco.

Vlan 2 is a trunked vlan.

You could use vlan 10 and 20 for each node  so you don't have to disable dhcp/etc if you want as well as the native vlan but that's optional.

See: http://www.broadband-hamnet.org/hsmm-mesh-forums/view-postlist/forum-910/topic-910-managed-switch-configuration.html as an example.

Webmaster: please recategorize to one of the other forums (problems and answers perhaps) for tracking as this is not firmware development related.

Not ment to be a slam just asking the webmaster to tag it for us.

The site search doesn't search the forum so that limits the ability.  I only could find it because I knew for see it existed and used google search. It's one item that the webmaster should be fixing in a future site upgrade.

Not sure why it would of worked on 1.1.2 vs 3.0.0 as we made no changes to Ubiquiti on dtdlink (we did disable it on Linksys )   It's always been a dot1q tagged vlan port. 

And the guide I sent is just an example, I haven't owned a new cisco switch in a while I've been using different gear because of work.

Just to verify all devices are running 3.0.0b02 correct  when testing the 3.0 dtdlink right ?

What happens if you plug them in directly to each other bypassing the switch?

Nothing changed between 1.1.2 and 3.0.0* on the Ubiquiti side for DTDLINK (though the upper level protocol did change) 

The fact it worked on 1.1.2 without configuration is a mystery to me unless Cisco has added some auto route vlan feature since I was last around.

You should be able to verify this with a wireshark directly to the node seeing a dot1q tagged vlan which the switch should honor and then flood out the rest of the ports (as a dot1q tagged vlan -- hence the need for trunk mode). If it doesn't have the tag then something is wrong or if the switch strips the tag the nodes won't be able to see the packet.

Let me clarify one thing. I set the vlan on the switch ports used by the UBNT devices to access mode and to vlan 2. no trunk mode. Without anything coming up in search engine on the page I knew from earlier research that the dtdlink was vlan2. So that's all I setup.

I didn't see a need for any other vlans, let alone a trunk. Hind site all my wireless AP's at work are all on trunk ports. Last weekend I was testing 1.1.2 and 3.0.0 and then I was testing 3.0.0b2 .The idea was to simulate a three sector tower setup. I had a total of Five M5's. Three to form the ring ( three 120 degree sectors ) and two out on perimeters to act as clients. I set the switch ports to access mode on vlan 2 and I could see the traffic and pass traffic between the nodes on what I'm designating RING 0.

Then earlier this week with an M2 running 1.1.2 and it worked. I upgraded the M2 to the 3.0.0 The same switch config but only a single M5 and the M2. no go it was all broke. upgraded to 3.0.0b2 and same scenario. I went over everything that I did, notes, drawings, configs. I had been monitoring with Wireshark the whole time this was taking place.

Earlier in the week I saw the traffic Now since i went back to my original three M5's as ring 0 and running 1.1.2 its all working again. ?????? Step 2 . This evening. I upgraded back to 3.0.0b2 on all nodes with just VLAN2 and it didn't work. This proved something had changed. Step 3 . I set all UBNT device ports to trunk mode with vlan 10 native allowing 1,2,& 10 on the trunk. Everything is working. I can pass traffic both to and from 2.4 & 5.8 and from one band to the other. The confusion only came in when I simplified my setup and used a single M5 & M2. I could see the DTDLink traffic with the three M5 on the original testing last weekend. Its all working now. Thank you

=========

Switch configuration

This configuration was done for a three sector array with two backbone nodes setup to pass traffic from This site to the next.

This assumed you have a console cable connected to a computer and that there is no configuration on the switch. The switch has had a Factory reset preformed. All commands were done on a Cisco 2950 switch running 12.3 code. This may or may not work with other versions of code.

1. First we setup the VLANs and second the ports that need these vlan's
   
2.  Cisco 2950 running 12.3 code connect using a console cable. 8N1 / 9600
   
3. 
   
4. #Setup the vlan database:
   
5. switch>enable
   
6. switch#
   
7. switch#config t
   
8. switch(config)#
   
9. switch(config)#vlan 10
   
10. switch(config-vlan)#name BBHN
    
11. switch(config-vlan)#no shutdown
    
12. switch(config-vlan)#exit
    
13. switch(config)#vlan 2
    
14. switch(config-vlan)#name DTDLINK
    
15. switch(config-vlan)#no shutdown
    
16. switch(config-vlan)#exit
    
17. switch(config)#exit
    
18. 
    
19. switch# show vlan
    
20.  VLAN   NAME  STATUS
    
21.      1 default    active
    
22.      2 DTDLINK active
    
23.    10 BBHN      active
    
24. 
    
25. switch# config t
    
26. switch(config)#interface range Fa0/1 - 3 << Program up all three ports at once
    
27. switch(config-if-range)#Description BBHN Sector Array XX
    
28. switch(config-if-range)#switchport mode trunk
    
29. switch(config-if-range)#switchport trunk allowed vlan 2,10
    
30. switch(config-if-range)#switchport trunk native vlan 10
    
31. switch(config-if-range)#speed 100
    
32. switch(config-if-range)#duplex full
    
33. switch(config-if-range)#no shutdown
    
34. switch(config-if-range)#exit
    
35. 
    
36. switch(config)#interface range Fa0/4 - 5 << Program up two backbone link ports at once
    
37. switch(config-if-range)#Description Link to site XX
    
38. switch(config-if-range)#switchport mode trunk
    
39. switch(config-if-range)#switchport trunk allowed vlan 2,10
    
40. switch(config-if-range)#switchport trunk native vlan 10
    
41. switch(config-if-range)#speed 100
    
42. switch(config-if-range)#duplex full
    
43. switch(config-if-range)#no shutdown
    
44. switch(config-if-range)#exit
    
45. switch(config)# interface fa0/6
    
46. switch(config-if)#Description TestPortUseOnly 
    
47. switch(config-if)#switchport mode access
    
48. switch(config-if)#switchport access vlan 10
    
49. switch(config-if)#switchport speed 100
    
50. switch(config-if)#switchport duplex full
    
51. switch(config-if)#switchport spanning-tree portfast
    
52. switch(config-if)#no shutdown
    
53. switch(config-if)#exit
    
54. switch(config)#exit
    
55. 
    
56. switch# copy run start << Copy the running configuration to the startup configuration
    
57. 
    
58. switch#show interface trunk
    
59. 
    
60. Port Mode encapsulation Status Native Vlan
    
61. Fa0/1 on 802.1q Trunking 10
    
62. Fa0/2 on 802.1q Trunking 10
    
63. Fa0/3 on 802.1q Trunking 10
    
64. Fa0/4 on 802.1q Trunking 10
    
65. Fa0/5 on 802.1q Trunking 10
    
66. Port Vlans Allowed
    
67. Fa0/1 2,10
    
68. Fa0/2 2,10
    
69. Fa0/3 2,10
    
70. Fa0/4 2,10
    
71. Fa0/5 2,10

Glad it is working when in trunk mode.

Jist a note for anyone else who may come across the config in the future:

The hard coding of the speed and duplex is not handled in our default BBHN builds.  While this config may work for a LAN a potential for collisions is possible as the network card aboard the Ubiquiti should fall back to 10mbps/half duplex.

I was pointing out that we do not have a setting in the BBHN GUI for changing the network port speed settings to lock them down, instead we stick with letting the device choose under Ethernet autonegotiation protocol (often cited as addendum 802.3u but now bundled into the official 802.3 spec's)

When you hard code the speed on a device it (usually) disables autonegotiation of speed and duplex on that link

Cisco confirms this is the case:

http://www.cisco.com/c/en/us/support/docs/lan-switching/ethernet/10561-3.html

"If you want to hard code the speed and duplex on a switch that runs Cisco IOS Software (turn off auto-negotiation), issue the speed and duplex commands underneath the specific interface. Duplex is subservient to speed in the sense that if speed is set to auto, then the duplex cannot be manually set."

The Usual fallback I've seen in the 10/100 world was 10/Half (though I've sen some smart drivers upgrade the link to 100/half if they see 100mbhs traffic)

When you get into gigabit it gets even stricter it seems (quoting same article)

"By default, all devices are supposed to perform autonegotiation. 802.3z does not specifically define a way to turn Autonegotiation off, for both 1GigabitEthernet and 10GigabitEthernet."

You could hard program the speed into the back-end of the BBHN device  and the operating system will honor it,  its just we don't expose a hard interface config setting via the GUI (at this time).

Same Article:

"Cisco recommends to leave auto-negotiation on for those devices compliant with 802.3u."

Though despite that recommendation , like you, I have had portions of my network where I have hard coded link data. Though I have also have portions where I have hard coded, and it actually mucks things up (I had a buggy version of VMWARE ESX at one time that had issues where the interfaces woudl periodically reset itself to half duplex unless you left autonegotiation in place as one example)

So yes we will fully support 100mbps on 100mbps devices, its just we tend to let autonegotiation set the link speed rather then exposing a GUI setting where mistakes can be made.

Correct, when you use an unmanaged switch (a 'dumb' switch) they will generally (i won't say always, but I have never seen one yet that doesn't) forward the entire Ethernet frame through the switch.

802.1q vlan tagging is done inside the data portion of the frame. An unmanaged switch only cares about the Source and Destination MAC address (some don't even verify the packet is not corrupt while others do but that is just a CRC check.)  Knowing the source and destination an unmanaged switch can forward the packet out the correct interface (in the case of an OLSRD packet it should be broadcast to all ports as a broadcast frame)

A easy image of this is: http://en.wikipedia.org/wiki/IEEE_802.1Q#mediaviewer/File:Ethernet_802.1Q_Insert.svg

A smart/managed switch on the other hand actually looks into the frames (to one degree or another) and performs additional actions.   Layer 3 managed switches will go all the way up to IP address parts of the frame while others will only act on Layer 2. Cisco has both these options available.

A managed switch can go "the extra mile" of setting and checking policies.  In the case of a Cisco switch if the interface is not tagged as a trunk port it will STRIP the trunk data off (this acts as a method to prevent an end user from feeding 802.1q up the interface and bypassing your routing/firewall systems) to ensure the data transiting the port meets the ports policy setup.

So if you use an unmanaged switch you end up in a situation where the tagged frames can pass as the switch knows nothing about it, when you use a smart switch you end up in a situation where it 'violates policy' to let the frame pass unless the switch has been specifically configured to permit it. 

I'm sure some managed switch out there is more permissive in that regard, but I haven't had one in my hands yet.