Nexus 3172TQ - Access ports seem not to accept vlan tagged traffic

[urbaman]

Hi,

I set up vlans, interface vlans with IPs, access ports, link aggregations and trunk on my Cisco 3172TQ.

I also set up a linux machine as a test machine to check the configuration.

If I send tagged traffic to the access ports of the switch, it seems to drop the traffic, while it accepts only untagged traffic.

The documentation seem to say the opposite: "If an access port receives a packet with an 802.1Q tag in the header other than the access VLAN value, that port drops the packet without learning its MAC source address."

For example, this configuration in the linux machine works:

iface enp129s0f0 inet manual
    mtu 9000

auto vmbr6
iface vmbr6 inet static
    address 10.0.100.11/24
    gateway 10.0.100.5
    bridge-stp off
    bridge-fd 0
    mtu 9000

While this one not (can't reach the upstream vlan IP, can't reach devices on other access ports within the same vlan)

iface enp129s0f0 inet manual
    mtu 9000

auto vmbr6
iface vmbr6 inet static
    bridge-stp off
    bridge-fd 0
    bridge-vlan-aware yes
    bridge-vids 100
    mtu 9000

auto vmbr6.100
    address 10.0.100.11/24
    gateway 10.0.100.5
    mtu 9000

This also works for a trunk port (can ping the upstream vlan IP, can ping the linux machine from other devices on other access ports on same vlan, ...), for all of the trunked vlans, if tagged on that linux bridge.

auto enp5s0f0
iface enp5s0f0 inet manual
mtu 9000
#bond-trunk

auto enp129s0f1
iface enp129s0f1 inet manual
mtu 9000
#bond-trunk

auto bond2
iface bond2 inet manual
bond-slaves enp129s0f1 enp5s0f0
bond-miimon 100
bond-mode 802.3ad
mtu 9000
#trunk

auto vmbr5
iface vmbr5 inet manual
bridge-ports bond2
bridge-stp off
bridge-fd 0
bridge-vlan-aware yes
bridge-vids 10 20 30 40 50 60 70 80 100
mtu 9000
#trunk

auto vmbr5.20
iface vmbr5.20 inet static
address 10.0.20.11/24
vlan-raw-device vmbr5
mtu 9000
#vlan20 - Proxmox Cluster

auto vmbr5.40
iface vmbr5.40 inet static
address 10.0.40.11/24
vlan-raw-device vmbr5
mtu 9000
#vlan40 - Ceph Public

auto vmbr5.60
iface vmbr5.60 inet static
address 10.0.60.11/24
vlan-raw-device vmbr5
mtu 9000
#vlan60 - pfSense Sync

auto vmbr5.80
iface vmbr5.80 inet static
address 10.0.80.11/24
vlan-raw-device vmbr5
mtu 9000
#vlan80

So, it seems the switch does not accept tagged traffic on access ports, even of the access vlan, and the docs are wrong.
...or am I missing something?

[Elliot Dierksen · Accepted solution]

'Access port' by definition means a port that only handles a single VLAN. The only exception would be in edge switches with an IP phone. In switches that support it, you can use the 'switchport voice vlan <X>' to make it accept a single tagged VLAN. If you want more than 1 tagged VLAN, you have to trunk. I can't see any benefit to tagging for an access port unless you have an IP phone there. Are you just experimenting, or is there something specific you are trying to accomplish?

[MHM Cisco World]

why you config it with access port if the Server send tag frame?
you can config port with trunk, 
server dont care if you run access or trunk, and server will send tag frame and NSK can receive not drop. 

[urbaman]

Hi,

Actually I do not really need tags on those ports, probably they would only help avoinding asyncroneus traffic on the server between the various ports/IPs if I do potential cross-vlan connections.

The real thing is why the documentation is confusing, giving me the hint that tagging would work with access ports (and it's right it does not work, to follow the network guidelines).

Anyway, you're saying they do not work with tagging, so I'll go with untagged ports on the server.

Thank you very much.

[willzhmic]

The access port can receive data frames with vlan tags, but why the server and switch cannot communicate in this configuration.

The key point is how the switch handles the frames when sending them back to the server:

1. The server sends a frame with VLAN 10 tag to the switch
2. The switch port configured as Access 10 receives this frame
3. The switch processes the frame and generates a reply frame
4. However, according to the Access port sending principle, the switch strips the VLAN tag from the reply frame before sending it out
5. When the reply frame reaches the server, it no longer has the VLAN 10 tag
6. The server's VLAN 10 subinterface cannot recognize frames without the VLAN tag

It is precisely because the Access port strips the VLAN tag from outgoing frames that the server's VLAN subinterface cannot receive the reply data, thus preventing communication with the switch.