Native/management vlan not working?

Jeroen1001 · ‎02-26-2011

Hello everybody,

I've got a SLM 2008 smart switch. I've set the following options to switch port 1 which has the role of being a trunk port.

1) Enable Tx force untag: disabled

2) Ingress filter: disabled

3) Acceptable frame type: tagged only

4) PVID: 1

All ports, including port 1 are still in VLAN 1. The management interface is also in VLAN 1. Yet above configuration immediately breaks the native VLAN = the untagged VLAN, right?

Configuration (for testing) is as follows:

Cisco smart switch P1 ------------------------------------------------- Dumb incapable VLAN switch

| |

PC1 PC2 (this one can set dot1q packets)

The dotted line is a trunk. PC2 has an Intel NIC which can send tagged packets but this is irrelevant to the problem.

The problem is that PC1, sending untagged packets over the trunk, cannot access the any devices nor the management interface. The switch should forward tagged packets to the native VLAN 1 but it does not do this (unless I set acceptable frame type to all). Having PC2 send packets with a VLAN 1 tage doesn't help either.

What could be the problem here?

IAN WHITMORE · ‎02-26-2011

I've never used one of these switches so don't really know how they function but in 3) Acceptable frame type: tagged only looks like the problem because PC1 can't send tagged frames so they will be discarded.

My question is, if all ports are in VLAN 1, why do you need to configure the trunk port? Is it for testing with PC2?

Maybe if you enable 1) Enable Tx force untag: disabled, it will also work. Give it a try,

Regards,

Ian

Jeroen1001 · ‎02-26-2011

Dear Ian,

How this thing functions is more like a riddle wrapped in an enigma.

I'm basically trying to figure out what every option does with the gear available to me but I'm not really making any progress.

If you have the time to answer, here is the first hurdle regarding ingress filtering:

Following VLANs exist:

VLAN 1 (port 1, is in it).

VLAN 30 (port 6 and port 1 are in it).

VLAN 20 (no ports are in it).

1)I've put a device in VLAN 30 (port 6).

Port 6 PVID = 30, accepts all frame types, Tx force untag is disabled, ingress filter is disabled

2)The trunk, port 1, accepts all frame types, Tx force untag is disabled, ingress filter is disabled.

3) The trunk is connected to the PC that can send dot1q frames (see my drawing in the first post).

When the PC that can send dot1q frames, is set to be in VLAN 30, I can reach device on port 6 in VLAN 30. When I remove the pc from that VLAN 30, I can no langer reach the device on port 6. So far so good.

I have then moved the device in VLAN 30 (port 6) from VLAN 30 to VLAN 20 (so I put port 6 in VLAN 20). Please note that the trunk, port 1, is not in VLAN 20.

So we now have:

VLAN 1 (port 1, is in it).

VLAN 30 (port 1 is in it).

VLAN 20 (port 6 is in it).

I then configure the PC to be in VLAN 20. If I understand ingress filtering (described below) port 1, the trunk, will forward the frame to port 6 because the VLAN ID (20) is in its database. It will do so because ingress filtering is disabled. Well gues what, ingress filtering IS disabled and I can't reach the device on port 6.

So how on earth does one test ingress filtering? I'd be a massive help if I could do that.

Many thanks,

Jeroen

----------------------------------------------------

The options as described in the manual:

Enable Tx Force Untag
When this option is enabled, all egress frames from this port become untagged. The default value is Disable. When this function is disabled, only frames with the VLAN ID equal to the PVID will become untagged, otherwise, frames are sent with a VLAN tag.
Enable Ingress Filter
Determines how to process frames tagged for VLANs for which the ingress port is not a member. The default value is enabled. Ingress filtering only affects tagged frames. If ingress filtering is disabled and a port receives frames with a VLAN tag that uses a different PVID than the receiving port, the packet types will be forwarded to the port belonging to the appropriate VLAN (determined by the VLAN tag). If ingress filtering is enabled and a port receives frames tagged for VLANs for which it is not a member, these frames will be discarded.
Acceptable Frame Type
Sets the interface to accept all frame types, including tagged or untagged frames, or only tagged frames. When set to receive all frame types, any received frames that are untagged are forwarded to the VLAN based on the PVID of its ingress port. All frame types are selected by default.
PVID (Port VLAN identifier)

IAN WHITMORE · ‎02-26-2011

On port 1 you have ingress filtering disabled as I understand. Right.

Enable Ingress Filter
Determines how to process frames tagged for VLANs for which the ingress port is not a member. The default value is enabled. Ingress filtering only affects tagged frames. If ingress filtering is disabled and a port receives frames with a VLAN tag that uses a different PVID than the receiving port, the packet types will be forwarded to the port belonging to the appropriate VLAN (determined by the VLAN tag). If ingress filtering is enabled and a port receives frames tagged for VLANs for which it is not a member, these frames will be discarded.

What should happen if you enable ingress filtering is what you described. First it should be PC2 that does it because it needs to be a tagged frame. PC2 sends a frame tagged for VLAN 20. Port 1 with ingress filtering disabled forwards the port to the appropriate VLAN, in this case 20 where you have another device installed. It should work.

I hate all this ingress/egress stuff on old switches. I have seen this on old HP switches and blades (the 10p blade - I finally got it all working and the blade packed up)...and enterasys besides others.

Anyway, hope that helps.

Ian

Jeroen1001 · ‎02-26-2011

So basically, [with ingress filtering disabled] the ingress port only checks whether the switch has the VLAN in its VLAN database. It doesn't care whether it is a member of that VLAN. It will check the VLAN-tag of the frame and forward it to any port corresponding to the VLAN-ID in the tag.

Great, so ingress filtering is stuck on enabled on the switch.

These things can really rack your brain:)

Any ideas on Tx force untag?

My best bet is that normally, a device connected to an access port (untagged port?) does not send tagged frames. Devices connected to access ports are said to be VLAN-unware.

Say the device connected to port 6 (with a PVID of 30) DOES tag its frames itself we have 2 options:

Tx force untag is disabled:

=> the switch will untag frames with VLAN-id 30 because 30 is the PVID.

and the switch will not untag any tagged frames with a VLAN-ID different from 30. Whether the tagged frames with an VLAN-ID different than 30 get forwarded to where they want to go, depends on the ingress filter of port 6.

Tx force untag is enabled:

Simple, all tagged frames become untagged. So, this prevents devices (that can tag their frames themselves) from accessing VLANs where they are not supposed to have access to. So all tagged frames end up with only access to the ports that are in the same VLAN equalling the PVID of the port they are received on. So if tagged frames on port 6 (with PVID 30) have a tag other than 30, they'll get untagged so they can only access other ports that are also in VLAN 30. It's a safety thing to outsmart malicious devices.

I can't think of any other uses for this option...

If what I've posted above is correct, I hope this will help out other hunting for the same information.

Ian, you're always welcome to correct my ramblings if I'm wrong:).

IAN WHITMORE · ‎02-27-2011

After I read it like 5 times I think I agree with your rambling on this one

Ever thought of just buying another switch??

Regards,

Ian

Jeroen1001 · ‎02-27-2011

I took 25 minutes to type that haha. It is often hard to convery things about VLANs clearly.

The main issue I had is that descriptions seldomly state the flow/direction of traffic. For the Tx force untagging I didn't now whether they meant

A)device -------------> switch (switch untags frames received by device IF they're tagged)

untagging

or B)switch ------------> device (switch untags frames before sending them to the device to shield unaware devices from frames with VLAN information)

untagging

Now that I know there is no tagging involved between access ports, and the rest of the untagging happens at the trunk it became obvious that A was correct answer for access ports.

The switch I have is in the basement, in a small encasing. The good thing about is that it can be powered by POE (gigabit midspan adaptor), it cost about only 80 euros and it looked easy enough to configure:). If I only had known at the time.

Cisco's are generally out of budget unless I go for a used one. Which is what I will do next time:)

I really want to thank you for the sanity check as I'm now confident I actually know what I'm doing!

IAN WHITMORE · ‎02-27-2011

No probs man. It can only get easier from here, can't it?? Lol.

Ian

Jeroen1001 · ‎02-27-2011

Oh no:), now I need to trunk my VLANs to the router.But we don't do networking on Sundays:))