Overview
All existing Cisco IOS XE based router/switch use special transceiver to do MACsec encryption/decryption. This software MACsec
uses CDAL infrastructure in QFP to do crypto operation. Comparing to the hardware choice, the way configuration/status/datapath
is done is different thus creating some limitation on the functionality.
Release 17.10.1a only supports MACsec on L2 interfaces. The MACsec port must be put into access mode. As the encryption happens
on the egress SVI interface, the vlan used for the port should be unique, meaning no other interface can use that vlan. This
limitation is because the QFP does not have MAC table information.
Note
|
Since MACsec is being done through software, performances are not line rate on L2 interfaces.
|
Note
|
Cisco supports only the should secure MACsec mode for IR1101, which allows unencrypted traffic even in a secured state.
Limitation:
The IR1101 does not support the must secure mode.
|
For an egress packet, SVI only know the packet needs to go out on a vlan without info about any specific interface. It is
up to the switch chip to decide which port to go. All the packets without MACsec tag can come in as usual. Outgoing L2 packet
will also egress without encryption or modification.
Both the NE and NA license support GCM-AES-128. This feature is not available running the NPE image.
The MACsec protocol is defined in IEEE802.1AE.
Feature Limitations
-
MACsec is not supported in controller mode in this release.
-
There must be a unique vlan id for a MACsec interface.
-
Only gcm-aes-128 is supported in this initial release.
-
Both explicit and non-explicit SCI are supported on ingress side. The IR1101 sends out only explicit SCI packets as it is
not an end system.
-
The IR1101 does not support confidentiality offset.
-
Integrity only is not supported in this first release.
-
For gcm-aes-128, up to 32 bytes are added to an encrypted packet compared to a plain packet. So the MTU setup should add 32
for it to work properly.
-
The MACsec key is managed by the MKA module. For that device, it requires a static key for MKA to negotiate MACsec key.
-
There is no MIB support.
-
IP Device Tracking (IPDT) is not supported in the host-to-switch MACsec configurations.
Related Documentation
Further information can be found at the following:
Sample MKA Configuration
See the following example:
conf t
aaa new-model
mka policy p1
key-server priority 1
macsec-cipher-suite gcm-aes-128
sak-rekey interval 3600
end
conf t
key chain cak1 macsec
key 414243
cryptographic-algorithm aes-128-cmac
key-string 0 12345678901234567890123456789012
lifetime local 00:00:00 29 November 2021 infinite
end
conf t
int fa 0/0/2
switchport mode access
switchport access vlan 77
mtu 1532
mka policy p1
mka pre-shared-key key-chain cak1
macsec network-link
macsec replay-protection window-size 128
end
Show Commands
Show cpp_cp internal info:
show platform hardware cpp active feature soft-macsec server tx [dp] [item]
show platform hardware cpp active feature soft-macsec server rx [dp] [item]
show platform hardware cpp active feature soft-macsec server control [dp] [item]
Other show commands:
show macsec summary
show macsec status int fa 0/0/2
show macsec statistics int fa 0/0/2A
Clear Statistics
Clear macsec statis int fa 0/0/2
Test Command
Print 10 MKA packet for debug:
test platform software smacsec mka-ingress