VSP4000 VLAN tagging

[sbilde]

I'm testing various VLAN modes on VSP400 and have difficulties making a "trunk" port _not_ to strip the Default VLAN tag from outgoing packets.

Testbed:
There is a single VSP4450 rel 4.1 and two laptops with IPs 10.1.1.1/8 and 10.1.1.2/8 connected to 1/1 and 1/2

First surprise is that there is almost nothing on how to configure VLANs on a port in the most recent doc collection or anywhere else.
There seem to be two commands: encapsulation dot1q and vlan tagging tagall to switch between Trunk and Access modes.

Anyway, ports are trunks now, untag default VLAN is disabled.

VSP-4450GSX-PWR+:1(config)#sh interfaces gigabitEthernet vlan

================================================================================
                                   Port Vlans
================================================================================
PORT          DISCARD DISCARD   DEFAULT VLAN         PORT     UNTAG    DYNAMIC
NUM   TAGGING TAGFRAM UNTAGFRAM VLANID  IDS          TYPE     DEFVLAN  VLANS
--------------------------------------------------------------------------------
1/1   enable  false   false     50      50,150       normal   disable  P
1/2   enable  false   false     50      50,150       normal   disable  P
1/3   disable false   false     1       1            normal   disable  P
1/4   disable false   false     1       1            normal   disable  P
...

There shall be no ping between 1/1 and 1/2 since all the incoming packets are tagged with PVID and all the outgoing packets shall be tagged as well.
Yet the ping continues.
Enabling/disabling untag-port-default-vlan makes no difference.

Assumptions?

[zakabog]

I'm not quite sure what you're doing but if you build a trunk port it's not going to tag the VLANs, you're going to be able to ping between port 1 and port 2 because the VLANs exist on both ports. Are you sure you need trunk ports and not access ports?

[sbilde]

if you build a trunk port it's not going to tag the VLANs, you're going to be able to ping between port 1 and port 2 because the VLANs exist on both ports.

Did you mean "Access port"? On trunk port I'm expecting all the outgoing traffic to be tagged - and that' exactly what's not happening.

I keep investigating and it turns out that two ports with identical settings in the same VLAN are able to pass both tagged and untagged packets depending on what kind of host is connected (I have a Laptop and a Cisco3750 as hosts, untagged and tagged correspondingly).

It all looks and works like an AutoPVID feature, only there shall be no AutoPVID on the VSP platform and there is no way to disable it.
Weird.

[zakabog]

I'm sorry, I mant to say it IS going to tag the VLANs but since the VLANs exist on both ports and you're using a subnet that overlaps, there is nothing keeping the two networks from communicating.

[sbilde]

I'm sorry, I mant to say it IS going to tag the VLANs but since the VLANs exist on both ports and you're using a subnet that overlaps, there is nothing keeping the two networks from communicating.

Well, a laptop doesn't understand tagged traffic. Therefore if a port sends tagged traffic a laptop won't be able to read it and the ping stops.

[zakabog]

Do you have the VSP set to discard untagged frames on those two ports?

[sbilde]

Do you have the VSP set to discard untagged frames on those two ports?

Nope, because they shall not _send_ untagged frames in the first place with this configuration.
It is explicitly configured NOT to untag the default VLAN.

[zakabog]

I don't have a VSP 4000 on my desk to test this with but looking at your config it seems like everything is working exactly as programmed. The port is tagging your untagged frames and the responses come back untagged because they were sent untagged. It looks like you need to enable discard untagged frames and do a test, or just start a wireshark capture and look for the tags..

[sbilde]

looking at your config it seems like everything is working exactly as programmed. The port is tagging your untagged frames and the responses come back untagged because they were sent untagged.

Not exactly as programmed. I program it NOT to remove the PVID tag yet it removes the tag anyway.

I don't want the box to make tag/untag decision based on some previous packets (auto-PVID), I want to explicitly program it NOT to untag the PVID and be sure it won't change its mind.

[zakabog]

What exactly is your end goal? If you want the laptop to not receive ping replies then you'll need to drop untagged frames. The switch isn't untagging your traffic, your laptop is never tagging the traffic to begin with. I just did a test here with an ERS 3500 which isn't exactly the same but a lot of the configuration is similar as the VSP is built upon the ERS platform. If I have a tagged port and I send untagged frames without filtering, I get a reply. If I filter untagged frames then I only receive a reply when I set the VLAN ID on my NIC to match the VLAN of the trunk port.

[sbilde]

What exactly is your end goal? If you want the laptop to not receive ping replies then you'll need to drop untagged frames. The switch isn't untagging your traffic, your laptop is never tagging the traffic to begin with.

That's not the point.
I want the box to work in a predictable way in consistence with the settings configured.
What I observe here is an inconsistent behavior - the tag is removed even if the box is configured not to do so, and changing the setting makes no effect.
If that AutoPVID is the default behavior - Id like to have it documented in the first place, and it would be nice to know the mechanism. How exactly does the switch decide which traffic goes where? First packet on the port? First ARP? First broadcast? First with this particular source MAC?

For example, there are plenty networks out there with a router having several subinterfaces tagged and untagged on the same physical port with a single source MAC address. I can't predict the VSPs behavior if such a port is connected.

Before I understand all that I can't put the box in production because the real life scenarios are well beyond a simple laptop connectivity described here

[zakabog]

Yeah, documentation would be great but I no longer expect to find any. Everything I've ever learned on these things has from been scanning through any documentation I can find as well as lots of trial and error, the more you go through the process the more everything starts to make sense.

Basically in your config, untagged traffic is going to travel across the default VLAN (VLAN 50) for the port it's coming from. Since your second port is configured as a trunk port and carrying traffic from both 50 and 150, it passes along the untagged traffic since it's on the same Layer 2 network (VLAN 50). You didn't tag the traffic from your laptop so it's not dropping any tags, it's just passing along the traffic as it was given, as if you had a flat switch.

[sbilde]

Since your second port is configured as a trunk port and carrying traffic from both 50 and 150, it passes along the untagged traffic since it's on the same Layer 2 network (VLAN 50). You didn't tag the traffic from your laptop so it's not dropping any tags, it's just passing along the traffic as it was given, as if you had a flat switch.

I may be misunderstanding your explanation, but that's not how the 802.1q Ethernet switch works.
There are no untagged packets "inside" the switch. Every untagged packet received is tagged with a default VLAN (a.k.a. PVID) and treated accordingly.

The outgoing port may be a member of several VLANs, but only the default VLAN a.k.a. PVID can be either removed from the outgoing packet (Access Port) or left as it is (Trunk).
I configure the port _not_ to remove the PVID, the switch removes it instead hence the problem.

[zakabog]

When you did encapsulation dot1q did you specify the two ports? Have you tried that to see if it makes any difference? Are you absolutely certain your laptops NIC does not understannd 802.1q tagged frames? Is there any reason you want to go against the recommended practice of dropping untagged frames?

[sbilde]

When you did encapsulation dot1q did you specify the two ports?

The system won't allow you to assign more than one VLAN if the port is in Access mode, that answers the question. And the laptops - yes, as untagged as can be.

As for the rest - again, the problem is not the scheme itself, but the fact that a switch isn't working the way it is configured.

Thanks for confirming the same behavior on the other product!
I'll escalate it to Avaya itself.