2

I’m trying to figure out if there is an inherent flaw in the way JUNOS handles sticky-mac addresses across their switch-ports versus how Cisco handles them. I’ll elaborate.

Below, you can see that port Fa0/1 is configured for sticky-mac, and once a device is plugged into the port, it loads the mac address into running-configuration for that single port.

interface FastEthernet0/1
switchport mode access
switchport port-security
switchport port-security violation restrict
switchport port-security mac-address sticky
switchport port-security mac-address sticky 0010.9400.0002
!

Now, let’s say an end user has the mobility of a laptop, and decides to plug the laptop in somewhere else; we’ll assume they plug into port Fa0/2 on the same switch.

Obviously, Cisco switches will throw the port into an err-disabled state since port Fa0/2 is attempting to connect with a mac-address that is already registered on the switch.

CiscoSwitch>show interface status

Port      Name               Status       Vlan       Duplex  Speed Type
Fa0/1                        notconnect   1            auto   auto 10/100BaseTX
Fa0/2                        err-disabled 1            auto   auto 10/100BaseTX
Fa0/3                        notconnect   1            auto   auto 10/100BaseTX
Fa0/4                        notconnect   1            auto   auto 10/100BaseTX
Fa0/5                        notconnect   1            auto   auto 10/100BaseTX
Fa0/6                        notconnect   1            auto   auto 10/100BaseTX

Now, from my understanding, this isn’t necessarily a security mechanism. It’s more of a basic switch function; not really knowing what to do with more than 2 mac-address entires being registered on the same switch. Although this isn’t a security control, per se, it does work twofold in ensuring the administrator has proper port control; with a fully populated 6550, this might mean the difference of entire floors, VLANs, or even subnets.

Now, the configuration that will net you the same desired outcome in JUNOS are as follows. Also, yes, I understand that the family ethernet-switching commands are missing. We will also assume we are using the same laptop in the Cisco example.

user@switch# show
interface ge-0/0/0.0 {
    mac-limit 1;
    persistent-learning;
}
interface ge-0/0/1.0 {
    mac-limit 1;
    persistent-learning;
}

After verifying the mac-address has been registered persistently.

user@switch> show ethernet-switching table persistent-mac
VLAN              MAC address       Type       Interface
default           00:10:94:00:00:02 installed    ge-0/0/0.0

Now comes the strange part, if you change the port, JUNOS automatically migrates the mac-address over to the port it sees the mac-address on next.

user@switch> show ethernet-switching table persistent-mac
VLAN              MAC address       Type       Interface
default           00:10:94:00:00:02 installed    ge-0/0/1.0

I’m not sure if this was the design goal, but from someone who is in a heavy transition to Juniper, I find this shortcoming a big deal since 802.1X is not yet feasible in our environment.

What have others done? Has anyone else found a way around this dynamically?

Ryan Foley
  • 190
  • 3
  • 11
  • Which behavior are you looking to achieve? We accomplish Juniper-like behavior with DHCP MAC filtering (though we also use sticky MAC). – Nathan V Nov 28 '12 at 14:11

2 Answers2

0

I am not too familar with Juniper switches, but I am sure it supports Local RADIUS server (i.e. the RADIUS server running on the switch itself) and MAC authentication. In fact, using the local RADIUS server and MAC authentication would have been my first choice in your situation rather than trying to mimic the proprietary behaviour of Cisco devices. What's the reason for not being able to use 802.1x? Do the clients not support it?

wookie919
  • 279
  • 3
  • 12
0

It’s bizarre how difficult this answer was to find. The feature that mimics Cisco’s switchport port-security mac-address sticky feature on Juniper platforms is ethernet-switching-options secure-access-port vlan (all | vlan-name) mac-move-limit;.

Juniper’s Technical Documentation on MAC Move Limiting:

MAC Move Limiting

MAC move limiting prevents hosts whose MAC addresses have not been learned by the switch from accessing the network. Initial learning results when the host sends DHCP requests. If a new MAC address is detected on an interface, the packet is trapped to the switch. In general, when a host moves from one interface to another, the host has to renegotiate its IP address and lease (or be reauthenticated if 802.1X is configured on the switch). The DHCP request sent by the host can be one for a new IP address or one to validate the old IP address. If 802.1X is not configured, the Ethernet switching table entry is flushed from the original interface and added to the new interface. These MAC movements are tracked, and if more than the configured number of moves happens within one second, the configured action is performed.

Actions for MAC Limiting and MAC Move Limiting

You can choose to have one of the following actions performed when the limit of MAC addresses or the limit of MAC moves is reached:

  • drop—Drop the packet and generate an alarm, an SNMP trap, or a system log entry.
  • log—Do not drop the packet but generate an alarm, an SNMP trap, or a system log entry.
  • none—Take no action.
  • shutdown—Block data traffic on the interface and generate an alarm. If you do not set an action, then the action is none. You can also explicitly set none as the action.
Ryan Foley
  • 190
  • 3
  • 11