VPLS and EoIP allow operators to extend Ethernet connectivity between locations. That is useful for subscriber aggregation, business services, and connecting remote access networks. However, an extended broadcast domain can also carry discovery advertisements and management protocols that were never intended to reach customers. A customer opening a neighbor-discovery tool should not receive a convenient inventory of the provider’s infrastructure.

MPLS is commonly described as Layer 2.5 because it forwards traffic using labels between Ethernet and the network-layer payload. VPLS provides an Ethernet service over an MPLS network, while EoIP carries Ethernet over an IP connection using GRE-based encapsulation. EoIP is therefore not itself an MPLS Layer 2.5 protocol, even when it serves a similar operational purpose. The customer-facing isolation requirements remain important with either transport.

Begin with a clear separation between the transport network, the provider management network, and each customer Ethernet service. Keep infrastructure management addresses and management interfaces out of customer bridges wherever possible. Use dedicated management connectivity with explicit access controls, rather than depending on discovery being difficult to find. A management VLAN only provides useful separation when its membership and access policy are enforced throughout the path.

Also decide what the customer service is supposed to transport. A subscriber access network may intentionally block customer discovery and management protocols at the edge. A transparent business Ethernet service may require the customer’s own control protocols to pass between its locations. Blocking those protocols changes the service behavior, so document exceptions rather than applying one global policy to every circuit.

The MikroTik discovery protocol is MNDP, sometimes shortened informally to MDP. CDP and LLDP are separate discovery protocols, while RoMON provides a management overlay. Disabling one does not disable the others, so the policy must identify each relevant traffic type.

CDP is not an ordinary IPv4 protocol, so an IP firewall rule alone cannot identify it as such. Likewise, dropping all multicast to remove discovery would also disrupt legitimate customer applications. Match narrowly enough to implement the intended service policy. Cisco documents the shared address in its VTP documentation and describes CDP encapsulation in its control-protocol guidance.

Use an explicit interface allowlist for local neighbor discovery. Include only the interfaces where provider discovery is intentionally permitted. Be careful with bridge membership because including a master bridge can enable discovery on its member interfaces. The following example assumes ether1 is a dedicated management interface outside every customer service bridge.

# Example: create once and replace ether1 with the real management interface.
/interface list
add name=PROVIDER-MGMT comment="Approved provider management interfaces"

/interface list member
add list=PROVIDER-MGMT interface=ether1

/ip neighbor discovery-settings
set discover-interface-list=PROVIDER-MGMT

If discovery is unnecessary, disable it globally using the alternative command below. This controls the router’s own discovery participation and does not establish a transit filter for frames received from another device. Review MikroTik neighbor discovery settings when auditing bridge and interface-list membership.

# Alternative: disable local neighbor discovery on every interface.
/ip neighbor discovery-settings set discover-interface-list=none

Disable RoMON where it is not required. If retained, explicitly restrict its participating interfaces to the approved management topology. RoMON uses its own forwarding mechanisms, so do not assume an ordinary bridge or IP firewall policy controls local participation. MikroTik also notes that received RoMON traffic is not shown by its sniffer or Torch when the service is enabled.

# Recommended where RoMON is not required:
/tool romon set enabled=no

# Restrict MAC-based management using the existing management allowlist:
/tool mac-server set allowed-interface-list=PROVIDER-MGMT
/tool mac-server mac-winbox set allowed-interface-list=PROVIDER-MGMT
/tool mac-server ping set enabled=no

Disabling local RoMON does not prevent a bridge from carrying RoMON generated elsewhere. MAC WinBox and MAC Telnet are also separate services, so hiding the router from discovery does not disable them. Verify IP-based management restrictions independently and preserve authorized recovery access before changing these settings. References: RoMON and MAC server.

Place enforcement where the customer Ethernet frame is visible after tunnel decapsulation or before encapsulation. Filtering the outer EoIP or MPLS transport header does not selectively remove discovery from the enclosed customer frame. Apply the policy at every relevant edge, including paths that can bypass the tunnel endpoint. The example below targets a dedicated customer bridge named br-customer and assumes the traffic is processed by the software bridge.

# Create the policy chain once.
/interface bridge filter
add chain=LTI-CUSTOMER-CONTROL action=drop \
    mac-protocol=ip ip-protocol=udp dst-port=5678 \
    comment="LTI: block untagged MNDP"

add chain=LTI-CUSTOMER-CONTROL action=drop \
    dst-mac-address=01:00:0C:CC:CC:CC/FF:FF:FF:FF:FF:FF \
    comment="LTI: block CDP and shared Cisco control MAC"

add chain=LTI-CUSTOMER-CONTROL action=drop \
    mac-protocol=0x88cc \
    comment="LTI: block untagged LLDP"

add chain=LTI-CUSTOMER-CONTROL action=drop \
    dst-mac-address=01:80:C2:00:88:BF/FF:FF:FF:FF:FF:FF \
    comment="LTI: block standard RoMON destination"

add chain=LTI-CUSTOMER-CONTROL action=return \
    comment="LTI: return other traffic to existing policy"

# Attach to this customer bridge's transit path.
add chain=forward in-bridge=br-customer \
    action=jump jump-target=LTI-CUSTOMER-CONTROL \
    comment="LTI: customer transit control policy"

The forward chain handles traffic crossing between bridge ports. Traffic addressed to the router and traffic generated by the router are different paths, so the transit rule is only one part of the design. Keep local services restricted as described above and review any required bridge input protection separately. MikroTik documents the chains and match fields in its Bridging and Switching reference.

A VLAN-tagged frame presents a different encapsulation to a filter than an untagged frame. The untagged MNDP and LLDP rules above must not be treated as a complete policy for arbitrary customer trunks. Destination-MAC matches can still identify their specified addresses, but deeper IP and EtherType matches depend on how tags are presented at the filtering point. QinQ and priority-tagged frames add more cases that require testing.

For a defined untagged handoff, enforce the permitted frame format rather than accepting unexpected customer tags. For a tagged service, build and validate VLAN-aware matches or supported switch ACLs for the actual encapsulation. Capture the frame at the enforcement point to confirm whether service tags have been removed, retained, or added. MikroTik’s packet-flow documentation explains why VLAN processing changes what a filter sees.

A software filter cannot enforce policy on traffic that never traverses it. On hardware-switched paths, use supported switch-chip ACLs or deliberately move the required path into software processing. The correct choice depends on the device, switch chip, topology, and required throughput. A counter incrementing for a CPU copy does not by itself prove that every hardware-forwarded copy was blocked.

Do not disable offload across an entire deployment without measuring the consequences. Bridge filters and other processing changes can affect acceleration and CPU utilization, especially at higher packet rates. Benchmark the intended configuration with representative traffic sizes and service load. Review the device’s switch-chip capabilities and packet path before selecting an enforcement method.

Avoid blocking all broadcast or multicast traffic as a shortcut. Customer services may require ARP, DHCP, IPv6 neighbor discovery, multicast applications, or agreed control protocols. IPv6 neighbor discovery is different from MikroTik neighbor discovery and must not be confused with MNDP. Define a service-specific allow and deny policy rather than treating every discovery-related packet as unnecessary.

Keep loop prevention, MAC learning, and broadcast containment in the design. Review VPLS split-horizon behavior and avoid redundant EoIP paths that create an uncontrolled Layer 2 loop. Size the transport MTU for the actual encapsulation, including VLAN tags and any additional security overhead. Filtering management protocols improves separation, but it does not replace these fundamentals or provide encryption.

Test with known protocol traffic rather than relying only on an empty neighbor list. Capture on the customer side and at the remote service edge, preferably using an external capture point when local tools cannot see the relevant path. Verify both directions and repeat the tests after failover or configuration changes. An aged neighbor entry disappearing does not prove that new frames are being blocked correctly.

• Confirm provider MNDP, CDP, and LLDP advertisements do not reach the customer handoff.
• Confirm customer-generated control traffic is blocked or transported according to the service agreement.
• Verify RoMON cannot form an unauthorized management path across the customer service.
• Test untagged, priority-tagged, VLAN-tagged, and stacked-tagged traffic where those formats are relevant.
• Confirm ordinary IPv4, IPv6, DHCP, and required multicast services still work.
• Measure CPU load, throughput, and packet loss with the final enforcement method enabled.

/ip neighbor discovery-settings print
/interface list member print
/tool romon print
/tool romon port print
/tool mac-server print
/tool mac-server mac-winbox print
/interface bridge port print
/interface bridge filter print stats

Record the RouterOS release, hardware model, rule ordering, and capture results with the service documentation. Repeat the acceptance tests when hardware, forwarding modes, or major software versions change. The goal is a verified customer boundary that remains understandable to the next engineer maintaining the network.