Now, the configuration that will net you the same desired outcome in JUNOS are as follows. 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. 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.
Now, from my understanding, this isn’t necessarily a security mechanism. CiscoSwitch>show interface statusįa0/1 notconnect 1 auto auto 10/100BaseTXįa0/2 err-disabled 1 auto auto 10/100BaseTXįa0/3 notconnect 1 auto auto 10/100BaseTXįa0/4 notconnect 1 auto auto 10/100BaseTXįa0/5 notconnect 1 auto auto 10/100BaseTXįa0/6 notconnect 1 auto auto 10/100BaseTX 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. 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. Switchport port-security mac-address sticky 0010.9400.0002 Switchport port-security mac-address sticky
Switchport port-security violation restrict I’ll elaborate.īelow, 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. 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.