S32GのトピックRe: Port-based VLAN (PVID) Mapping and Untagged External Traffic Support in PFE L2 Bridge

Port-based VLAN (PVID) Mapping and Untagged External Traffic Support in PFE L2 Bridge

minJ — Fri, 13 Mar 2026 12:01:50 GMT

1. Environment

Platform: S32G3

Software:

* NXP RTD: SW32G_RTD_4.4_5.0.0_QLP04

* PFE firmware: 1.12.0

* Tool: libfci_cli

PFE is running in VLAN_BRIDGE mode.

---

2. Goal

I want to keep all external traffic untagged, while implementing port-based VLAN isolation only inside the PFE.

Desired behavior:

```

emac0 ↔ hif0 (internal VLAN 10)

emac1 ↔ hif1 (internal VLAN 20)

emac2 ↔ hif2 (internal VLAN 30)

```

That is,

* External PCs send/receive frames without VLAN tags

* VLAN is used only internally in the PFE for port-based traffic separation

* The purpose is to prevent unnecessary broadcast/flooding in a master/slave architecture

---

3. Current configuration

VLAN and Bridge Domain are configured as follows.

Key commands:

```sh

# Bridge Domain and interface configuration

libfci_cli bd-add --vlan 10

libfci_cli bd-add --vlan 20

libfci_cli bd-add --vlan 30

libfci_cli bd-update --vlan 10 --ucast-hit FORWARD --ucast-miss FLOOD --mcast-hit FORWARD --mcast-miss FLOOD

libfci_cli bd-update --vlan 20 --ucast-hit FORWARD --ucast-miss FLOOD --mcast-hit FORWARD --mcast-miss FLOOD

libfci_cli bd-update --vlan 30 --ucast-hit FORWARD --ucast-miss FLOOD --mcast-hit FORWARD --mcast-miss FLOOD

libfci_cli bd-insif --vlan 10 --i hif0 --tag OFF

libfci_cli bd-insif --vlan 10 --i emac0 --tag OFF

libfci_cli bd-insif --vlan 20 --i hif1 --tag OFF

libfci_cli bd-insif --vlan 20 --i emac1 --tag OFF

libfci_cli bd-insif --vlan 30 --i hif2 --tag OFF

libfci_cli bd-insif --vlan 30 --i emac2 --tag OFF

# PHY interface mode configuration

libfci_cli phyif-update --i emac0 -E --promisc OFF --mode VLAN_BRIDGE

libfci_cli phyif-update --i emac1 -E --promisc OFF --mode VLAN_BRIDGE

libfci_cli phyif-update --i emac2 -E --promisc OFF --mode VLAN_BRIDGE

libfci_cli phyif-update --i hif0 -E --promisc OFF --mode VLAN_BRIDGE

libfci_cli phyif-update --i hif1 -E --promisc OFF --mode VLAN_BRIDGE

libfci_cli phyif-update --i hif2 -E --promisc ON --mode VLAN_BRIDGE

libfci_cli bd-stent-add --vlan 10 --mac <MAC Address> --i hif0

libfci_cli bd-stent-update --vlan 10 --mac <MAC Address> --egress hif0

libfci_cli bd-stent-add --vlan 20 --mac <MAC Address> --i hif1

libfci_cli bd-stent-update --vlan 20 --mac <MAC Address> --egress hif1

libfci_cli bd-stent-add --vlan 30 --mac <MAC Address> --i hif2

libfci_cli bd-stent-update --vlan 30 --mac <MAC Address> --egress hif2

```

In summary:

- emac/hif pairs are assigned to each VLAN (10/20/30)

- All traffic is untagged externally

- VLAN is used only internally for separation

4. Problem

When untagged frames arrive from outside (e.g., PC → ping), the ingress counter for each domain remains zero.

```

domain 10 ingress: 0

domain 20 ingress: 0

```

That is, untagged frames are not mapped to internal VLANs, so the intended port-based separation does not work.

# libfci_cli bd-print

domain 01 [default]

phyifs (tagged) : ---

phyifs (untagged) : ---

ucast-hit action : 3 (DISCARD)

ucast-miss action : 3 (DISCARD)

mcast-hit action : 3 (DISCARD)

mcast-miss action : 3 (DISCARD)

ingress : 4173

ingress bytes : 560619

egress : 958

egress bytes : 234538

domain 00 [fallback]

phyifs (tagged) : ---

phyifs (untagged) : ---

ucast-hit action : 3 (DISCARD)

ucast-miss action : 3 (DISCARD)

mcast-hit action : 3 (DISCARD)

mcast-miss action : 3 (DISCARD)

ingress : 0

ingress bytes : 0

egress : 0

egress bytes : 0

domain 10

phyifs (tagged) : ---

phyifs (untagged) : emac0,hif0

ucast-hit action : 0 (FORWARD)

ucast-miss action : 1 (FLOOD)

mcast-hit action : 0 (FORWARD)

mcast-miss action : 1 (FLOOD)

ingress : 0

ingress bytes : 0

egress : 0

egress bytes : 0

domain 20

phyifs (tagged) : ---

phyifs (untagged) : emac1,hif1

ucast-hit action : 0 (FORWARD)

ucast-miss action : 1 (FLOOD)

mcast-hit action : 0 (FORWARD)

mcast-miss action : 1 (FLOOD)

ingress : 0

ingress bytes : 0

egress : 0

egress bytes : 0

domain 30

phyifs (tagged) : ---

phyifs (untagged) : emac2,hif2

ucast-hit action : 0 (FORWARD)

ucast-miss action : 1 (FLOOD)

mcast-hit action : 0 (FORWARD)

mcast-miss action : 1 (FLOOD)

ingress : 0

ingress bytes : 0

egress : 0

egress bytes : 0

Command successfully executed.

---

5. Question

Is it possible to keep external traffic untagged, and achieve VLAN-based isolation only inside the PFE?

* Map untagged ingress frames to a specific VLAN per port (PVID function)

* VLAN is used only inside the PFE

* External devices operate without VLAN tags

In other words,

```

ingress (untagged) → VLAN 10 -> egress (untagged)

ingress (untagged) → VLAN 20 -> egress (untagged)

ingress (untagged) → VLAN 30 -> egress (untagged)

```

is the desired behavior.

1. Does the PFE support port-based VLAN?

2. If yes, which firmware feature or configuration enables it?

3. Is it related to the vlan_conf or ingress_vlan features shown in fwfeat-print?

Re: Port-based VLAN (PVID) Mapping and Untagged External Traffic Support in PFE L2 Bridge

alejandro_e — Fri, 13 Mar 2026 18:08:38 GMT

Hello @minJ,

Please find my answers below:

Is it possible to keep external traffic untagged, and achieve VLAN-based isolation only inside the PFE?
- For what I can see in the documentation, no, you cannot use external unteagged traffic and only used VLAN tags internally. If you configure a port to a BD (Bridge domain) It can have three ways of operation, Default BD, Fall-back BD and Standard BD, in all three the VLAN is checked to either accept or discard the frame depending on certain rules. You can check section L2 Bridge VLAN Awareness and Domains of the PFE-SW_S32G_FCI_API_ReferenceManual_2.7.0. for more details on those rules.
Does the PFE support port-based VLAN?
- Not directly, you would need to create different BDs for each VLAN and configure each port to their respective domain. In summary, you can configure BD-based VLAN, where each BD uses a different port. Please check the same document and section I mentioned above.
If yes, which firmware feature or configuration enables it?
- This should answered with the information from the other two questions.
Is it related to the vlan_conf or ingress_vlan features shown in fwfeat-print?
- If you mean vlan_conf_check, yes both are related to this topic, however enabling/configuring this options will configure the ports so that frames without vlan are discarded.

A possible solution to avoid flooding in a master-slave configuration could be avoid using that mode and instead forward the frames using IPCF to the other domain, for example if the M7_0 is the owner of the PFE, it forwards only some frames to the A53/Linux domain. Depending on your requirements this can be a viable option. Let me know if you require more elaboration on this idea.

Please let me know if you have more question.

Re: Port-based VLAN (PVID) Mapping and Untagged External Traffic Support in PFE L2 Bridge

minJ — Sat, 14 Mar 2026 01:30:13 GMT

Hello,
Thank you for the detailed explanation.

I would like to confirm whether the Linux commands I described in “3. Current configuration”represent a configuration that is fundamentally unsupported, or if there might be some missing configuration on my side.

My current test environment is as follows:

• One PC

• The PC has three NICs

• Each NIC is directly connected to one of the board’s EMAC ports

On the PC side, I am not configuring any VLAN interface. I am simply sending a normal ping.

The behavior I expect is the following:

When the PC sends a ping, the board should forward the packet based on the destination IP and the corresponding Bridge Domain (BD), and then transmit it to the ports that belong to that VLAN.

The configuration I would like to achieve is:

VLAN10 : HIF0, EMAC0

VLAN20 : HIF1, EMAC1

VLAN30 : HIF2, EMAC2

VLAN40 : HIF3, EMAC0, EMAC1, EMAC2

In other words:

• EMAC0/1/2 are each connected to their dedicated VLANs (10/20/30).

• At the same time, they also participate in a shared VLAN40, which communicates with HIF3.

With the current Linux commands:

• If I put all ports into VLAN1, everything works as expected.

• However, when I separate them into VLAN10/20/30, the ingress/egress counters only increase in VLAN1, and not in VLAN10/20/30.

Therefore I have two questions:

1. Is this type of VLAN configuration supported by the PFE VLAN_BRIDGE model, or is there some configuration step that I may have missed?

2. Currently, the PC sends untagged packets (just a normal ping).

In this case, is it impossible for the PFE to classify the ingress traffic into a specific VLAN BD?

In other words, does this setup require the PC to send VLAN-tagged packets?

For example, should the PC be configured like this to send tagged traffic?

ip link add link eth0 name eth0.40 type vlan id 40

ip link set eth0.40 up

ping -I eth0.40 192.168.x.x

Any guidance on whether this configuration is feasible, or if there is a recommended approach for this scenario, would be greatly appreciated.

Thank you.

Re: Port-based VLAN (PVID) Mapping and Untagged External Traffic Support in PFE L2 Bridge

alejandro_e — Tue, 17 Mar 2026 19:20:15 GMT

Hello @minJ,

To which document are your referring when mentioning 3. Current configuration I checked all documents in the PFE Linux Documentation and I was not able to find that section. Please indicated the page of the section and revision of the document.

Regarding the classification of untagged packages in a VLAN port, I misunderstood the documentation before, for that you would need to configure a BD with the default configuration, it has de following description:

Default BD:
Factory default VLAN ID of this bridge domain is 1. This domain processes ingress frames which either have a VLAN tag equal to the Default BD VLAN ID, or do not have a VLAN tag at all (untagged Ethernet frames).

This is the only BD configuration that can handle untagged frames, Therefore with this configuration you don't need to send tagged messages from your host. Moreover, other type of BDs will not process Frames without VLAN tag.

Sorry for the confusion before. Let me know if you have more questions.

Re: Port-based VLAN (PVID) Mapping and Untagged External Traffic Support in PFE L2 Bridge

minJ — Wed, 18 Mar 2026 09:38:53 GMT

Hello,

The '3. Current configuration' I mentioned refers to the Linux commands in my first question.
I apologize for not making this clear earlier.

# Bridge Domain and interface configuration
libfci_cli bd-add --vlan 10
libfci_cli bd-add --vlan 20
libfci_cli bd-add --vlan 30
libfci_cli bd-update --vlan 10 --ucast-hit FORWARD --ucast-miss FLOOD --mcast-hit FORWARD --mcast-miss FLOOD
libfci_cli bd-update --vlan 20 --ucast-hit FORWARD --ucast-miss FLOOD --mcast-hit FORWARD --mcast-miss FLOOD
libfci_cli bd-update --vlan 30 --ucast-hit FORWARD --ucast-miss FLOOD --mcast-hit FORWARD --mcast-miss FLOOD
libfci_cli bd-insif --vlan 10 --i hif0 --tag OFF
libfci_cli bd-insif --vlan 10 --i emac0 --tag OFF
libfci_cli bd-insif --vlan 20 --i hif1 --tag OFF
libfci_cli bd-insif --vlan 20 --i emac1 --tag OFF
libfci_cli bd-insif --vlan 30 --i hif2 --tag OFF
libfci_cli bd-insif --vlan 30 --i emac2 --tag OFF
# PHY interface mode configuration
libfci_cli phyif-update --i emac0 -E --promisc OFF --mode VLAN_BRIDGE
libfci_cli phyif-update --i emac1 -E --promisc OFF --mode VLAN_BRIDGE
libfci_cli phyif-update --i emac2 -E --promisc OFF --mode VLAN_BRIDGE
libfci_cli phyif-update --i hif0 -E --promisc OFF --mode VLAN_BRIDGE
libfci_cli phyif-update --i hif1 -E --promisc OFF --mode VLAN_BRIDGE
libfci_cli phyif-update --i hif2 -E --promisc ON --mode VLAN_BRIDGE
libfci_cli bd-stent-add --vlan 10 --mac <MAC Address> --i hif0
libfci_cli bd-stent-update --vlan 10 --mac <MAC Address> --egress hif0
libfci_cli bd-stent-add --vlan 20 --mac <MAC Address> --i hif1
libfci_cli bd-stent-update --vlan 20 --mac <MAC Address> --egress hif1
libfci_cli bd-stent-add --vlan 30 --mac <MAC Address> --i hif2
libfci_cli bd-stent-update --vlan 30 --mac <MAC Address> --egress hif2

The Linux commands I wrote were based on the following documents: LNX PFE Driver User Manual (Rev. 25.0) p19, p30, and demo_feature_L2_bridge_vlan.c from PFE FCI API Reference (Rev. 2.7.0) p144.

According to your answer, does it mean that if I configure the L2 bridge and VLAN as in the Linux commands above, the untagged packets sent from the PC cannot be processed?
Even if I specify a static MAC address, I would like to know if untagged packets still cannot be handled by the VLAN members (HIF, EMAC).
Additionally, I am also curious if it is possible to forward the packets back to the PC without a VLAN tag (i.e., as untagged packets).

Thanks.

Re: Port-based VLAN (PVID) Mapping and Untagged External Traffic Support in PFE L2 Bridge

alejandro_e — Thu, 19 Mar 2026 23:33:43 GMT

Hello @minJ,

Sorry for the late reply, I am somewhat overloaded at the moment and I will need more time to analyze your problem.

Thanks for your patience.

Re: Port-based VLAN (PVID) Mapping and Untagged External Traffic Support in PFE L2 Bridge

alejandro_e — Wed, 25 Mar 2026 23:14:38 GMT

Hello again @minJ,

Sorry again for such a long wait. Answering to the following questions "does it mean that if I configure the L2 bridge and VLAN as in the Linux commands above, the untagged packets sent from the PC cannot be processed?" I was not able to find a direct reference to answer it, however, comparing the commands you are using and the main difference is that in the Linux PFE documentation the VLAN 1 is used, which is the Default BD (note that it cannot be removed) that VLAN catches all messages with ID 1 or without a VLAN tag. Although it is not explicitly said that the configuration you are trying is not supported, given that only the Default BD can handle untagged frames and Standard BD's will only get tagged frames with a matching ID.

Searching in some internal documentation I noticed that there is only one Default BD and there is no option to create another one. The recommended workaround for this usecase is to use different multicast address for each port, I am aware that this may not be a viable solution, however it is worth mentioning.

Again, sorry for the wait.

Let me know if you have more questions.