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:

• MACsec and the MACsec Key Agreement (MKA) Protocol

• MACSEC and MKA Configuration Guide, Cisco IOS XE 17

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  

Command Line Interface

The configuration mode CLI to enable HSEC on the IR1101 is the following:

IR1101(config)# license feature hsec9

To benefit from the HSEC license, a new bandwidth will be available. The new bandwidth is called uncapped, and it is available with the following CLI from configuration mode:

IR1101(config)# platform hardware throughput level ?
250M throughput in bps
uncapped throughput in bps
IR1101# platform hardware throughput level uncapped

After performing the above commands, write mem and reload the router. The configuration will take effect when the router comes back up.

License Types

With this new feature, the IR1101 will support the following bandwidth/license types:

• Network-essentials 250 Mbps

• Network-advantage 250 Mbps

• Network-essentials uncapped

• Network-advantage uncapped

• HSEC

Ordering

The following is an example from the IR1101-K9. The license will be available on the IR1101-A-K9 as well.

In the following example, select the SL-1101-NE/UNCP-K9 (Network Essentials Uncapped License):

The L-1101-HSEC-K9 license will get auto included when you select the uncapped license, as shown in the following:

Cisco Software Central

This guide provides information on how to order, activate, and manage your Cisco Smart Licenses.

https://software.cisco.com/software/csws/ws/platform/home?locale=en_US&locale=en_US&locale=en_US#

Private VLAN is used to divide a normal VLAN into isolated L2 partitions. Every host port in a private VLAN is one of three types:

• Isolated — An isolated port cannot talk to any other port in that PVLAN, except the promiscuous port. If an end device only wants to have access to a gateway router, then it would be attached to an isolated port.

• Community — A community port is part of a group of ports. The ports within the same community can have layer 2 communications with one another and can also talk to the promiscuous port.

• Promiscuous — A promiscuous port can talk to all other types of ports. A promiscuous port can talk to isolated ports and community ports and vice versa. Layer 3 gateways are typically connected to the switch via a promiscuous port.

The following is a summary of the supported features:

• Isolated access port: Access port which can only communicate with promiscuous port.

• Promiscuous access port: Access ports which can communicate with all ports in private VLAN.

• Community access port: Access ports which can communicate with ports in same community and promiscuous ports.

• Private VLAN across switches: Private VLAN traffic can be carried across normal trunk ports and the feature can span across switches.

• Promiscuous trunk port: A trunk port carrying primary VLAN traffic for multiple private VLAN. The secondary VLANs are explicitly mapped to primary VLAN for multiple private VLAN.

• Multicast in Private VLAN: Multicast communication in and out of private VLAN.

• Layer 3 communication between isolated ports: Isolated ports can communicate at layer 3

The following features are NOT supported:

• 2-way community VLAN: The community ports send and receive traffic in same VLAN.

• Trunk isolated/community ports: Isolated and community ports are trunk with secondary VLANs of multiple private VLAN.

Performing a Secure Data Wipe

To enable the feature, perform the following:

Router#factory-reset all secure
The factory reset operation is irreversible for securely reset all. Are you sure? [confirm]Y

Important

This operation may take hours. Please do not power cycle. To check the log after the command is executed, and booting up IOS XE, perform the following: Router#show platform software factory-reset secure log Factory reset log: #CISCO DATA SANITIZATION REPORT:# IR1800 Purge ACT2 chip at 12-08-2022, 15:17:28 ACT2 chip Purge done at 12-08-2022, 15:17:29 mtd and backup flash wipe start at 12-08-2022, 15:17:29 mtd and backup flash wipe done at 12-08-2022, 15:17:29.

CLI Changes

On IOS-XE platforms starting from 17.10.1a, there is a CLI correction and an additional CLI was added as part of raw-socket.

The correction is for the raw-socket idle timeout command. There is now an option to configure the timeout based on minutes and seconds, whereas the previous configuration used only minutes.

Router(config-line)# raw-socket tcp idle-timeout [0-1440] [<0-59> | cr]

The additional CLI is for clearing the raw-socket TCP clients. The command syntax is clear raw-socket line [1-145|tty|x/y/z] for example:

Router# clear raw-socket line 0/2/0

Note	When initiating clear raw-socket line, raw-socket sessions will be cleared for raw-socket clients from the show raw-socket tcp sessions command. Connections will be re-established after a TCP hand-shake, which can be done by doing shut/no shut on TCP connection interface.