Configure replay-window for CTS manual?

[navlrac]

With plain macsec, you can apply an MKA policy with a replay window setting, however I haven't been able to find a way to configure the replay window size for macsec setup by "cts manual".

We need a replay window according to TAC to work around a separate issue, the default for CTS manual however is strict (window 0), and defining a new MKA policy as suggested won't have any effect.

Attempts to use the mka policy setting on an interface, configured for CTS, gives an error saying its incompatible.

[Georg Pauwen · Accepted solution]

Hello,

so 'macsec replay-protection window-size' gives the error ? Can you post the full output of the error message ?

[navlrac]

thanks, that seems to have worked.

I was previously stuck on mka policy and trying to apply that to the interface, which does give an error.

'macsec replay-protection window-size'  works, and now I have:

This looks OK?

SW10-DC1#show cts interface te1/0/1
Global Dot1x feature is Disabled
Interface TenGigabitEthernet1/0/1:
    CTS is enabled, mode:    MANUAL
    IFC state:               OPEN
    Interface Active for 00:01:33.903
    Authentication Status:   NOT APPLICABLE
        Peer identity:       "unknown"
        Peer's advertised capabilities: "sap"
    Authorization Status:    NOT APPLICABLE
    SAP Status:              SUCCEEDED
        Version:             2
        Configured pairwise ciphers:
            gcm-encrypt

        Replay protection:      enabled
        Replay protection mode: STRICT

        Selected cipher:        gcm-encrypt
...

*and*

SW10-DC1#show macsec interface te1/0/1
 MACsec is enabled
  Replay protect : enabled
  Replay window : 300
  Include SCI : yes
  Use ES Enable : no
  Use SCB Enable : no
  Admin Pt2Pt MAC : forceTrue(1)
  Pt2Pt MAC Operational : no
  Cipher : GCM-AES-128
  Confidentiality Offset : 0
...

Let hope that solves my actual issue of random CTS/Macsec link drops.

[Georg Pauwen]

Hello,

looks good to me, size is 300. Keep monitoring, hopefully that resolves the issue of random drops...

[navlrac]

So unfortunately while the replay window seems setup, my underlying issue is not yet fixed. Trying a 15.2(4).E6 now instead of 15.2(6).E1 as it apparently has more fixes than the later, for 3560CX.

[Georg Pauwen]

Hello,

what is the underlying issue ? Not sure if you have already mentioned it in your original post ?

[navlrac]

I had posted here about it separately, with no response. Its both simple and complex, here's a short-ish description:

Setup is 2x  3560CX  connecting 2 sites over dark fiber.

With no CTS/Macsec, link is stable and error free.

With CTS+Macsec (cts manual) - It works, however we get random link drops of around 205 seconds at a time. Happens between 1 and 5 times a day. No traffic passes, and rxL2AuthfailPkts just increments when its down. Then, the link re-establishes by itself.

I tried LACP with two fibers simplex, and both links go down - not at the same time & randomly (and a lot more frequently than single link configuration) - but LACP brings connectivity back after 30 seconds compared to the 200+ seconds. I see LACP errors in the logs.

TAC suggested possibly a known bug that I should turn on replay-window to work around, it didn't work for me, and now want to check another non-public bug, apparently fixed on the version I mentioned (possibly I require both the fix version and replay-window ?).

Also, weird things happen: during the drop, one of the 3560CX units (side A) stops responding to local pings / and SSH connections to it get dropped. It starts responding again 10-15 seconds before the link comes back. While the other side switch seems not to behave this way, I've not tested it much. If I shut/no shut the interface - I get the same behavior, I loose remote console to (side A), but (side B) console stays responsive - both on SSH, (I use a backup link between sites).

Getting highly frustrated and considering looking at other switch brands right now.

[Georg Pauwen]

Hello,

the only bug I could find that is even remotely related is the one below.

Can you post the configs of both switches ? Maybe I or somebody else can spot something...

CTS manual link does not come up

CSCus32213

Description

Symptom:
cts manual link does not come up between 3750 with 15.2(E) CCO image and any other macsec supported peer switch, unless "dot1x system-auth-control" global cli is configured on the 3750 switch.

Conditions:
CTS manual links on 3750 switch without configuring "dot1x system-auth-control" global configuration.
CTS manal link fails to come up, as the SAP negotiation fails to start due to the missing EAP ACL.

Workaround:
enabled the global "dot1x system-auth-control" CLI on 3750 switches.

[navlrac]

Defect suspected: CSCvh10409

Current configuration : 4256 bytes
!
! Last configuration change at 21:23:55 AEST Thu May 31 2018 by xxx
! NVRAM config last updated at 21:24:33 AEST Thu May 31 2018 by xxx
!
version 15.2
no service pad
service timestamps debug datetime msec localtime
service timestamps log datetime msec
no service password-encryption
service sequence-numbers
!
hostname SWXXXXX
!
boot-start-marker
boot-end-marker
!
logging buffered 8200000
no logging console
enable secret 5 xxxxx
enable password xxxxx
!
username xxxxx
aaa new-model
!
!
aaa authentication login default local
aaa authorization exec default local
aaa authorization network default local
!
!
!
!
!
!
aaa session-id common
clock timezone AEST 10 0
clock summer-time AEDT recurring last Sun Oct 2:00 1 Sun Apr 3:00
switch 1 provision ws-c3560cx-8xpd-s
system mtu routing 1500
!
!
!
!
!
!
ip domain-name xxxxx
!
!
!
!
!
!
!
!
!
crypto pki trustpoint TP-self-signed-xxx
!
!
crypto pki certificate chain TP-self-signed-xxx
xxxxxxxxxxxxxxxxxxxxxx
        quit
!
spanning-tree mode rapid-pvst
spanning-tree extend system-id
!
!
!
!
vlan internal allocation policy ascending
vlan dot1q tag native
!
!
!
!
!
!
!
!
!
!
!
!
!
interface GigabitEthernet1/0/1
!
interface GigabitEthernet1/0/2
!
interface GigabitEthernet1/0/3
!
interface GigabitEthernet1/0/4
!
interface GigabitEthernet1/0/5
!
interface GigabitEthernet1/0/6
!
interface GigabitEthernet1/0/7
!
interface GigabitEthernet1/0/8
!
interface TenGigabitEthernet1/0/7
 shutdown
!
interface TenGigabitEthernet1/0/8
 shutdown
!
interface TenGigabitEthernet1/0/1
 switchport trunk allowed vlan 5,7,20,21
 switchport trunk pruning vlan 2-4,6,8-19,22-1001
 switchport mode trunk
 macsec replay-protection window-size 300
 cts manual
  no propagate sgt
  sap pmk xxxxxxxxxxx mode-list gcm-encrypt
!
interface TenGigabitEthernet1/0/2
 switchport trunk allowed vlan 5,7,20,21
 switchport trunk pruning vlan 2-4,6,8-19,22-1001
 switchport mode trunk
!
interface Vlan1
 no ip address
 shutdown
!
interface Vlan20
 ip address 10.xx.xx.xx 255.255.255.0
!
ip forward-protocol nd
ip http server
ip http secure-server
!
ip ssh version 2
!
!
logging trap debugging
logging host 10.xx.xx.xx
!
!
!
no vstack
!
line con 0
line vty 0 4
 password xxxx
line vty 5 15
 password xxxx
!
ntp server 10.xx.xx.xx
!
end

[Georg Pauwen]

Hello,

configs look normal as far as I can tell.

The bug fix for the bug previously mentioned is to globally configure "dot1x system-auth-control". You might want to give that a try...

[navlrac]

Any simple example configs showing dot1x system-auth-control?

Anyway more log trawling, this time on the peer has found the following at the exact time the link dropped:

925534: Jun  5 14:26:00.592: CTS SAP ev (Te1/0/1): EAPOL-Key message from 701F.53CD.2F0B.
925535: Jun  5 14:26:00.592: CTS SAP er (Te1/0/1): Old replay counter:
  received: 00000000 0000210E, expected: 00000000 0000210F.
925536: Jun  5 14:26:00.592: CTS-SAP err:  (Te1/0/1): Rcvd packet dropped due to old replay counter
925537: Jun  5 14:26:00.592: CTS SAP er (Te1/0/1): Received packet being dropped due to 
  parsing/validation errors.
925538: Jun  5 14:26:04.570: CTS SAP er (Te1/0/1): Resend timer expired

No other occurrence of these messages in 10 hrs of debug log output.