Bridge port stuck "inactive" (native VLAN, ether1) despite correct VLAN table, PVID, and frame-types — CCR1016-12G, 7.23.2

**Device:** CCR1016-12G, RouterOS 7.23.2 (stable)

**Setup:**

`ether1` is a trunk uplink to a Cisco switch (`SW_1`, Gi0/1). It carries several tagged VLANs (11-15, 1701-2011) plus one **native/untagged VLAN (1700)**. `ether1` is a slave port of bridge `TBridge` (`vlan-filtering=yes`, `protocol-mode=none`).

Relevant config:

```

/interface bridge

add name=TBridge protocol-mode=none vlan-filtering=yes

/interface bridge port

add bridge=TBridge interface=ether6

add bridge=TBridge interface=ether1

add bridge=TBridge interface=2-proxmox-ether2

/interface bridge vlan

add bridge=TBridge tagged=TBridge,ether6,2-proxmox-ether2 vlan-ids=11-15,1701-2011

add bridge=TBridge tagged=TBridge untagged=ether1 vlan-ids=1700

```

Cisco side (`SW_1`) matches: `switchport trunk native vlan 1700`, VLAN 1700 exists and is active, all Gi0/1 ports forwarding, no STP blocking on 1700.

**Problem:**

`ether1` shows up as **inactive** in the bridge port list, and never gets added as a current-untagged member of VLAN 1700, even though:

- `/interface ethernet monitor ether1` shows `status: link-ok`, 1Gbps full-duplex

- `/interface print detail where name=ether1` shows flags `RS` (Running + Slave) — no inactive flag at this level

- `pvid=1700` is correctly set on the bridge port

- `frame-types=admit-all` (confirmed, not `admit-only-vlan-tagged`)

- The VLAN table entry is not disabled, and `tagged=TBridge` shows as `current-tagged`

- `/interface bridge vlan print detail where vlan-ids=1700` output:

```

0 bridge=TBridge vlan-ids=1700 tagged=TBridge untagged=ether1 mvrp-forbidden="" current-tagged=TBridge current-untagged=""

```

`current-untagged` stays empty — `ether1` never actually gets applied as untagged, even though the static config is correct.

```

/interface bridge port print detail where interface=ether1

Flags: X - DISABLED, I - INACTIVE; D - DYNAMIC; H - HW-OFFLOAD; Y - MANAGED

0 I ;;; port is already slave

    interface=ether1 bridge=TBridge priority=0x80 edge=auto point-to-point=auto learn=auto horizon=none hw=yes auto-isolate=no restricted-role=no

    restricted-tcn=no pvid=1700 frame-types=admit-all ingress-filtering=yes unknown-unicast-flood=yes unknown-multicast-flood=yes broadcast-flood=yes

    tag-stacking=no bpdu-guard=no trusted=no trusted-ra=no trusted-dhcpv6=no mvrp-registrar-state=normal mvrp-applicant-state=normal-participant

    multicast-router=temporary-query fast-leave=no

```

**What I've already ruled out:**

- Not a Cisco-side STP issue (STP is disabled on the MikroTik bridge entirely — `protocol-mode=none`)

- Not a Safe Mode rollback (confirmed disabled, re-applied and verified persistence)

- Not a `frame-types=admit-only-vlan-tagged` mismatch (was actually the culprit for a *different* related issue earlier — silently dropping untagged native traffic — but that's now fixed and confirmed `admit-all`)

- Not physical link/negotiation (link-ok, 1Gbps, full-duplex, `RS` flags at interface level)

- Not a duplicate VLAN-interface-on-slave-port conflict (previously had `/interface vlan` sub-interfaces built directly on `ether1` for PPPoE servers — moved those to sit on `TBridge` instead, per the documented rule that a slave port shouldn't also host a standalone VLAN interface)

**What I haven't tried yet:** removing and re-adding the bridge port (`/interface bridge port remove` + `add`). Found one old forum thread (2011, v4.17) describing similar symptoms fixed this way, but nothing in current documentation confirms this as an expected/known behavior on current RouterOS versions, or explains the root cause.

**Questions:**

1. Is there a known hardware-offload / switch-chip state that can get "stuck" on a bridge port on CCR1016 even when all software-level config (VLAN table, PVID, frame-types) is correct?

2. Is `remove` + `add` on the bridge port expected to reset this reliably, or is there a cleaner way to force re-evaluation (e.g. disable/enable, or an `/interface ethernet switch` level command)?

3. Any way to get more diagnostic detail on *why* a port is flagged inactive beyond the port list itself — logs, counters, anything at the switch-chip level?

Happy to post the full `/export` if useful. Thanks in advance.

Hi,

Could you please describe what you did yourself, not what AI suggests?
Can you try things you "haven't tried yet"

And in the end: "found an old thread from 2011, v 4.17 ....."
I want to remaind you that we are in 2026. Don't you thing that such an old topic is not valid?
It's like mentioning that you found an old topic on similar "two-stroke engine sputtering" that is similar to youe problems of contemporary turbocharged disel DOHC engine fixing.

Be happy and provide full config if you want help as "no config implies less help": Forum rules

This error message claims that the port is already a slave. Is it?

Complete config,

  • for example what is the address of the CCR1016

-what is the management or trusted vlan???

Solved it — the port had a VRF assigned to it (not main). That's what was keeping it stuck inactive, not the VLAN/pvid/frame-types config. Removed the VRF and it came right up. Thanks for the help.

All the VLANs were tagged trunk except native, which was VLAN 1700. The management/trusted access was on that native VLAN (1700, untagged).
Turned out the whole issue wasn't VLAN-related at all — the port had a VRF assigned to it (not main), which was what kept it stuck inactive in the bridge regardless of correct VLAN table, pvid, and frame-types. Removed the VRF and it came up immediately.

Next time stop thinking that you or the AI know what is relevant and what is not, and do as the thread linked by @BartoszP wrote and post the full export.