Junos Port Security: MAC Limit and Allowed MAC Configuration

Juniper EX and QFX switches expose two complementary port security mechanisms under ethernet-switching-options: MAC limiting, which caps how many MAC addresses an access port may learn, and allowed MAC lists, which lock a port to a handful of pre-approved addresses. Both defend against DHCP starvation and Ethernet switching table overflow attacks that can turn a LAN into a broadcast storm. This guide walks through the Junos CLI configuration for each feature, the actions you can take when the limit is exceeded, how to recover a port that has been shut down, and the verification commands that prove the policy is working.

Why Junos Port Security Matters on Access Ports

An attacker who floods an access port with frames carrying random source MAC addresses fills the switch forwarding table. Legitimate MACs then age out, traffic is flooded out of every port, and the network effectively becomes a hub. DHCP starvation attacks exhaust the DHCP pool so legitimate clients cannot get an address. Junos port security stops both by controlling MAC learning on the interface with mac-limit and allowed-mac statements.

Without these features an access port has no opinion about who connects. Anyone who unplugs a desk phone and plugs in a laptop inherits the port, and a small script that cycles through 8,000 random source MACs can flush the forwarding table of a 48-port switch in seconds. Port security turns an access port from an open door into a door with a guest list, and it does so at line rate in hardware rather than in a software daemon.

Configuring a MAC Limit on an Interface

MAC limiting is configured per interface under the secure-access-port hierarchy. The following example limits interface ge-0/0/1 to three learned MAC addresses and drops frames with new addresses once the limit is hit:

[edit ethernet-switching-options secure-access-port]
user@switch# set interface ge-0/0/1 mac-limit 3 action drop

You can apply the same limit to a single access port per VLAN, or to all access interfaces at once:

[edit ethernet-switching-options secure-access-port]
user@switch# set interface ge-0/0/1 vlan employee-vlan mac-limit 3
user@switch# set interface all mac-limit 5

The interface all form is a blunt instrument that applies the same ceiling to every access interface on the switch, and it is a common starting point for hardening a distribution closet quickly. When you scope the limit to a VLAN (interface ge-0/0/1 vlan employee-vlan mac-limit 3), the limit applies only to that VLAN's MAC learning on the port - the same physical port can carry a different limit for a second VLAN if you configure it explicitly.

Two practical notes on selecting a number:

• Set the limit to the number of devices that legitimately sit behind the port plus one or two for headroom. A single workstation gets mac-limit 2 when the desk has an IP phone chaining to a PC.
• Pick a limit of at least 2 for anything that could carry a virtualisation host, and much higher for uplinks. A limit of 1 on a port carrying a hypervisor will break the moment the hypervisor starts a second VM.

What Happens When the Limit Is Exceeded

The action keyword decides the penalty. The available actions are:

During a roll-out, start with action log for a week, review the syslog output for legitimate devices you would have broken, then switch to action drop. The staged approach costs nothing and routinely prevents a helpdesk incident on day one.

Configuring Allowed MAC Addresses

For ports where only specific devices are allowed - printers, IP phones, or servers - use the allowed MAC list. Any address not on the list is never learned:

[edit ethernet-switching-options secure-access-port]
user@switch# set interface ge-0/0/2 allowed-mac 00:05:85:3A:82:80
user@switch# set interface ge-0/0/2 allowed-mac 00:05:85:3A:82:81
user@switch# set interface ge-0/0/2 allowed-mac 00:05:85:3A:82:83

Allowed MAC entries take precedence over the dynamic MAC limit on the same interface. If you change the MAC limit, clear the existing forwarding table entries first so the new limit applies cleanly.

The two features answer different questions, and picking the wrong one is a common design error:

A sensible policy uses both: a generous mac-limit on all user ports as a safety net, and allowed-mac on the handful of ports where the connected device is known and never changes.

Clearing the Forwarding Table and Port Errors

After changing a limit, stale entries learned under the old policy can keep counting against the new one. Clear them explicitly:

user@switch> clear ethernet-switching table
user@switch> clear ethernet-switching table interface ge-0/0/1
user@switch> clear ethernet-switching table persistent-mac

If you configured action shutdown, the port goes into a port-error state and must be brought back by hand. Always fix the underlying cause first - removing the offending device or raising the limit - and then clear the error:

user@switch> show ethernet-switching interfaces ge-0/0/1
user@switch> show ethernet-switching port-error
user@switch> clear ethernet-switching port-error ge-0/0/1
user@switch> clear ethernet-switching port-error

Because a shut-down port is invisible to the user on the other end of the cable, action drop is usually the better production choice for user-facing ports, with shutdown reserved for ports where an unauthorised device is a security event worth stopping the traffic entirely.

Verifying Junos Port Security

Check the configured policy and the resulting forwarding table:

user@switch> show configuration ethernet-switching-options secure-access-port
user@switch> show ethernet-switching table
user@switch> show ethernet-switching table interface ge-0/0/1
user@switch> show ethernet-switching statistics mac-learning interface ge-0/0/1
user@switch> show log messages | match "mac limit"

In the table output, only the configured allowed MACs appear on the protected port, and packets from any other source are silently dropped - visible as a Flood entry instead of a learned MAC. The statistics command shows how many addresses the interface has learned and how many attempts exceeded the limit, which is the fastest way to tell an over-tight limit from a genuine attack. A port that suddenly logs thousands of violations is either badly provisioned or under attack; the source MAC list in show log messages tells you which.

Complementary Layer 2 Defences

Port security is one control among several, and it works best alongside the rest of the access-edge toolkit:

• Storm control caps broadcast, unknown-unicast and multicast traffic on an interface so a loop or a flood cannot saturate the switch - see the Junos storm control configuration guide.
• DHCP snooping with trusted ports prevents rogue DHCP servers and is a stronger answer to DHCP starvation than MAC limiting alone.
• Dynamic ARP inspection builds on the DHCP snooping database to reject forged ARP replies inside a VLAN.
• 802.1X and MAC RADIUS authenticate the user or device rather than just counting addresses, which is the right answer when "how many" is not the real question.
• BPDU guard stops a user port from participating in spanning tree if someone plugs in an unauthorised switch.

The Same Idea on Other Vendors

Every enterprise switch OS has some form of this feature, with different syntax and different defaults. Cisco's implementation is the most widely documented: Cisco port security and sticky MAC uses maximum, sticky, and violation modes of protect, restrict and shutdown, which map almost one-for-one onto Junos drop, log and shutdown. Huawei switches use a similar model under the interface, described in this 华为交换机端口安全配置 walkthrough. The conceptual mapping is straightforward; only the hierarchy and the reset commands differ.

Putting It Together: A Baseline Access-Port Policy

A defensible default for a user-facing access port combines both features with a staged penalty: log first, enforce after you have reviewed the traffic, and keep the number generous enough that a docking station or a visiting laptop does not trip it. The following statements are the whole policy:

set ethernet-switching-options secure-access-port interface ge-0/0/5 mac-limit 4 action drop
set ethernet-switching-options secure-access-port interface ge-0/0/5 vlan employee-vlan mac-limit 4
set ethernet-switching-options secure-access-port interface ge-0/0/5 allowed-mac 00:1B:44:11:3A:B7
set ethernet-switching-options secure-access-port interface all mac-limit 8 action log
set ethernet-switching-options secure-access-port interface ge-0/0/2 allowed-mac 00:05:85:3A:82:80
set ethernet-switching-options secure-access-port interface ge-0/0/2 allowed-mac 00:05:85:3A:82:81

Read those lines as two layers of control. The interface all statement is the fleet-wide safety net: eight addresses is far more than any legitimate desk needs, and action log means a misconfigured port generates a syslog entry rather than a support call. The per-port statements are the exceptions - a specific port pinned to a known MAC list, and a phone-plus-PC desk given its own four-address ceiling. Because the specific interface configuration takes effect for that port, you can tighten individual ports without changing the global rule.

Operational Tips

• Apply MAC limits to access ports only; trunk and aggregate (LACP) ports need to learn many addresses. If you must configure the uplink, use a high limit and test it, and remember that the aggregated Ethernet bundle statistics will show the drops.
• Layer 2 control traffic such as LLDP is not subject to the MAC address check.
• Set mac-limit 1 carefully - a VLAN containing routed VLAN interfaces (IRB) or an aggregated Ethernet bundle with LACP can break if it can only learn one MAC.
• Document the limit value next to the port description so the next engineer knows why the number is what it is.
• Re-check limits after any access layer change: a new IP phone model, a docking station, or a virtualisation host on a desk will silently violate a limit set three years ago.

For related reading, see our Cisco port security sticky MAC guide, the Junos VLAN access and trunk configuration examples, and the multi-vendor CLI cheat sheet.

原文链接：https://www.juniper.net/documentation/en_US/junos/topics/topic-map/example-configuring-port-limiting.html