HELP! vlan config help needed

[WirelessRudy]

If you mean this;

Screenshot 2015-10-21 01.01.57.png (123.99 KiB) Viewed 22436 times

No, I don't see oversize. Checked the same on port 6, same result.

I have a ping running from the CCR to other end, so there should be packages (=traffic) send but the CCR shows tx traffic but rx stays '0'

[sirhc]

OK, well Eric is finishing up with Dave on the changes to firmware v1.3.5 relating to improved I2C error handling (hardware stuff).

I get Eric next for my list of Bug Fixes and changes so I will take some time to re-visit VLAN configs and test your config which is simple.

If we are doing something wrong we will fix it.

This will not happen tonight but maybe v1.3.5 will be released tomorrow night or Thursday.

Getting ready to Skype Eric here shortly.

[WirelessRudy]

ok, its 2am here so time to get some sleep before next day comes again. See what you guys will make tomorrow...

[Eric Stern]

I tested this in my lab using 1.3.5. I setup the VLANs exactly as you have shown. I had a Nanostation M2 plugged into port 5, and a laptop in port 6. Initially neither was configured for VLANs and I was able to access the Nanostation from the laptop, so untagged frames worked. I then used the laptop to reconfigure the Nanostation to be on VLAN 2000 and then lost communication with it (as expected) until I reconfigured the laptop to also be on VLAN 2000 and then I was able to communicate with the Nanostation again, so tagged frames worked.

There are no functional changes to VLANs between 1.3.3 and 1.3.5, so the newer version should not make any difference, but you can try it when it is released.

Maybe trying looking at Device -> MAC Table to make sure the switch is seeing the devices you expect on the correct port and VLAN.

[WirelessRudy]

Ok, we took a look in the mac table.
The port 6 of the switch that connects to a route towards some remote units that should get an IP (dhcp-client) through this vlan2000 are visible in the mac table of the switch.
The port 5 of the switch that connect to the CCR 'sees' the mac of the CCR interface twice. One time with ID 3, which is the normal Untagged ethernet traffic and one time with ID 2000.

Is this normal? The same doesn't happen on the 'other' end (port 6).

The ethernet interface of the CCR that connects to the switch has an IP and traffic that is part of that network flows normally up and down to other routers within the same IP network through the port 5&6 combi.
But the vlan interface that is bond to this physical interface of the CCR is part of an internal bridge. This bridge connects several other similar vlan2000 interfaces and is therefore called 'vlan2000-bridge'.

Now, the switch 'sees' the mac of the physical interface with ID 3
The switch also 'sees' the mac of the vlan interface bond to this physical interface but now (off course) with ID2000
AND the switch 'sees' the mac of the bridge, which is different off course. It 'sees' this mac with ID2000 (off course I would say).

But still vlan2000 traffic doesn't pass.

We tried disabling the service tag on both vlan interface on either end of the switch, but no change...

I also removed the vlan2000 interface from the CCR internal bridge, gave it a new IP in another range and mount a dhcp-server on it. So now its just an vlan interface that connects via its physical 'dad' to the switch to reach through the "T" tagged ports 5&6 the other end.... not. It still doesn't pass any traffic.

Don't know what to try more...... but if we can't get it to work I either can't deploy more of the Netonix switches (which would be a pain) or I have to sort of re-design my otherwise good working vlan network.....

[sirhc]

Ok, we took a look in the mac table.
The port 6 of the switch that connects to a route towards some remote units that should get an IP (dhcp-client) through this vlan2000 are visible in the mac table of the switch.
The port 5 of the switch that connect to the CCR 'sees' the mac of the CCR interface twice.

If you have multiple VLANs or Sub-Interfaces (Logical Interfaces) plugged into a port on the switch you will see an entry for each VLAN on that interface.

Below are screen grabs from one of the WISP Switches at a towers at my WISP.

You can also see them in action here:
https://www.youtube.com/watch?v=8JvBEAD4MFM&spfreload=1
https://www.youtube.com/watch?v=cMv7JfG9cjI

Now I have a Static LAG between the Router and the Switch using ports 22 & 23 which is a little different but basically the same.

But notice the same Cisco router listed for each VLAN all with the same MAC but different VLAN IDs

I am not sure why you are running into this problem?

CLICK IMAGES BELOW TO VIEW FULL SIZE

VLAN MACS.jpg (218.62 KiB) Viewed 22386 times

VLANS.jpg (249.37 KiB) Viewed 22386 times

[WirelessRudy]

If you have multiple VLANs or Sub-Interfaces (Logical Interfaces) plugged into a port on the switch you will see an entry for each VLAN on that interface.

Ok, we sort of figured that too. Normal.


But your next screendumb are raising my eyebrows....

As you say your port 22&23 are aggregated ('lagged' or in Mikrotik I believe they call it 'bonded') so they actually work as one they have the letter "T" from "Tagged".
But if I then look at the other port that is supposed to be part of that switch combi (port 13 with ID 20 for instance) you have the letter "U" from untagged assigned to it?

This is then different than what you showed us before how it should be done... Both the 'incoming' as the 'outgoing' port in the combi have to have the same "T"ag or "U"ntagged?

I'l have to try this now. See who is first with an reply...

[sirhc]

If you have multiple VLANs or Sub-Interfaces (Logical Interfaces) plugged into a port on the switch you will see an entry for each VLAN on that interface.

Ok, we sort of figured that too. Normal.


But your next screendumb are raising my eyebrows....

As you say your port 22&23 are aggregated ('lagged' or in Mikrotik I believe they call it 'bonded') so they actually work as one they have the letter "T" from "Tagged".
But if I then look at the other port that is supposed to be part of that switch combi (port 13 with ID 20 for instance) you have the letter "U" from untagged assigned to it?

This is then different than what you showed us before how it should be done... Both the 'incoming' as the 'outgoing' port in the combi have to have the same "T"ag or "U"ntagged?

I'l have to try this now. See who is first with an reply...

No, if you look at VLAN IDs 97, 98, 99, and 100 those are Bonded with just Us as they are setup as MID-Spans powering back hauls such as airFIBER links. The powered side goes to the radios and the unpowered port goes to the Router. Now since I run a routed network meaning no VLANs from tower to tower I use a U which will only accept Untagged packets. If I ran Tagged VLANs between towers I would use Ts on each port, and if I ran both Untagged and Tagged traffic between towers I would need to define two VLANs, one for Untagged traffic and one for each VLAN Tagged traffic or just one for Tagged VLANs and use the Trunk Port/Allowed VLANs list.

I Untag all traffic when exiting at an AP port so I do not have to mess with Tagged crap beyond the switch I tell the switch to Untag all traffic as it leaves the port connected to the AP. If I was using QinQ where I encapsulated VLANs inside the primary VLAN such as running say VLAN ID 200 inside VLAN ID 20 on port 13 with QinQ I would put a Q on port 13 that way the outer VLAN ID would be stripped off (VLAN ID 20) when the packet leaves port 13 and then I would have VLAN ID 200 intact on the packet and could then pass that through to a customer radio where I would then strip off the VLAN ID 200 at the radio since I run all customer radios in either router or router NAT mode to prevent them from getting Layer 2 access to my net, but if you had a radio in bridge mode you could strip that ID off at the customer router.

[WirelessRudy]

Ok, I think I can follow you, a bit....

First, the switch just sits as midspan in a link starting from the CCR as main node router (it combines several lines and routes it all to another remote location with the backbone
On the other side of the switch (other side seen from the CCR) we have radio's that are just the start points of backhauls towards remote towers were traffic might be routed again to more towers etc. Utimately traffic finds the last radio, an CPE that is like yours a nat router so client sits behind a nat firewall and can do what he want there...

The vlans we use to create a 2nd virtual bridged network to interconnect several Hotspot AP's to a central router. Since I wasn't planning t make a separate physical network for that but still wanted to separate the hotspot clients generated traffic from the normal clients traffic we made one big vlan network. But off course on some units (like the CCR or this Switch) several ports have different networks connected but at the same time have to pass one and the same vlan network...

Now, If I understand you well, in creating an ID in the switch to interconnect two ports we basically make a local vlan that only exists in the switch itself between the ports that we want to interconnect and that then are either untagged or tagged or Q'd for that ID?

So if traffic that already enters a port with some vlan headers (id=2000), the ingress port puts a new vlan header (the one from the switch, for instance ID=3 in my example) on top of it. So we have now a QinQ?
By putting the "Q" again on the port where traffic is supposed to leave, this internal vlan header "3" gets stripped and the traffic leaves the switch to destination with only its original vlan header "2000"

So I have to set "Q" on the ports 5 & 6 and give it an ID=3. I disable the separate ID 2000 for these ports and see what happens............ Nothing. Normal traffic still flows, vlan2000 traffic not....

What more am I doing wrong?

[sirhc]

So if traffic that already enters a port with some vlan headers (id=2000), the ingress port puts a new vlan header (the one from the switch, for instance ID=3 in my example) on top of it. So we have now a QinQ?

NO, the switch does not add a Tag to a packet entering the switch on a T port, it just only accepts a Tagged packet that matches the VLAN ID or from the Allowed VLAN List under Trunk Ports/Allowed VLANs. Or any defined VLAN on the switch for that port. You can have as many T's from different VLANs on a single port but only 1 Untagged per port.

If an Untagged packet enters a U port and the VLAN pushes that packet out of another Tagged port then the switch will add a VLAN ID Tag to the packet as it leaves the T port.

So in my situation above and all my towers as they are cookie cutters:
Talking about a client attached to say AP20 on port 13 which has an Untagged VLAN ID of 20.

Now when a client sends a packet to the internet the packet would come from from the AP and enter Port 13 of the switch as UnTagged, the switch would send that packet to the router out Port 22 or 23 (Static LAG) to the router. When that packet leaves Port 22 or 23 of the switch destined to the router the switch will add the VLAN ID Tag 20 to the Packet so the Router will know where to send it when it receives it. Since I am using a Cisco 2951 it is destined to a Sub-Interface which is a Virtual Interface not a Physical Interface. When the packet reaches the Virtual Interface the router will then removed the VLAN Tag and route it to its destination somewhere out on the internet or somewhere else in my network.

Now if a packet from the internet reached the router and is destined to that same client the Router Tags that Packet when it leaves the Virtual Interface and goes out of the Router and arrives at port 22 or 23 of the switch with a VLAN ID Tag of 20 so now the switch says OK this packet is headed out Port 13 according to my VLAN definitions.

Now when the packet leaves Port 13 of the switch which is defined as Untagged the Switch will strip off the VLAN ID Tag and then push it out port 13 to go to the AP. If port 13 had a T on it the switch would leave the packet VLAN ID Tag on but I do not do it that way and I want to stop messing with VLANs at the switch if all possible.

So in my config I am not using Trunking / Allowed VLANs so Ports 22 & 23 will only accept Tagged packets with VLAN ID tags of 20, 21, 22, 51, 52, 53, 54, 55, 56, 60, 70, 71, 72 and 96 from the router. Any packets with other VLAN Tags or no VLAN Tag would be dropped.

We are not doing anything differently with VLANs than any other switch, it is a standard. Now our interface is different maybe (simpler) but the way VLANs are handled is standard.

Now with that said some manufacturers turn the filters off to avoid tech support issues but that is silly. Why would you want a port that is defined as Tagged to accept Untagged packet and vice versa. But some manufacturers do this. They set their ingress filters to accept both which to the average person appears to work but you are defeating the purpose of VLANs.

Our ingress filters only allow what you have configured.