Sunday, February 25, 2018

CSR HA in MS Azure

I wanted to have CSR HA pair and I thought its as simple as HSRP or GLBP. Later found its more complicated than that.

I watched one of Cisco Videos and one slid summarized the problem which I didn't see it document else ware. I wanted to share it here.



This is a common HQ topology in CSR

  • For the Private subnet 10.0.1.0/24, ideally you point to HSRP VIP as gateway in order to achieve failover between CSRs
  • HSRP won't work in Azure as multicast isn't supported in Azure
  • You need to configure CSRs to initiate API call to Azure in order to change the default gateway in Azure-Net from CSR-1 to CSR-2 once failure is detected
  • BFD can be used between CSRs to detect failures and trigger API call
  • BFD keepalives are exchanged between CSRs over GRE
  • Azure doesn't support GRE packets and will drop them
  • GRE over IPSec encapsulation (or SVTI) should be used between CSRs to exchange BFDs


at No comments:

Sunday, February 18, 2018

FlexVPN Debugs


FlexVPN IKEv2 Setup can be summarized:


The details are below:

  • FlexVPN follows legacy IKEv2 messaging by exchanging IKE_SA_INIT followed by IKE_AUTH exchange
  • For sites with virtual template interface (such as DVTI spoke), initiator will include CFG_Req in its IKE_AUTH message

*Feb 13 03:58:03.389: IKEv2:(SESSION ID = 23,SA ID = 1):Received Packet [From 10.150.3.1:500/To 10.150.1.1:500/VRF i0:f0]
Initiator SPI : 98DB5FD5979EAC12 - Responder SPI : 1398F140044ABC30 Message id: 1
IKEv2 IKE_AUTH Exchange REQUEST
Payload contents:
 VID IDi AUTH CFG SA TSi TSr NOTIFY(INITIAL_CONTACT) NOTIFY(SET_WINDOW_SIZE) NOTIFY(ESP_TFC_NO_SUPPORT) NOTIFY(NON_FIRST_FRAGS)

  • CFG_Req includes the authorization group name and password configured in the spoke IKEv2 profile which was picked during initiation

Spoke Config
…………………………………………………………………………….

crypto ikev2 profile prof-01
 match identity remote address 0.0.0.0
 authentication local pre-share
 authentication remote pre-share
 keyring local kr-01
 aaa authorization group psk list flex flex
 virtual-template 2


  • Based on the IDi, the appropriate IKEv2 profile is selected with its associated virtual access interface

*Feb 13 03:58:03.402: IKEv2:(SESSION ID = 23,SA ID = 1):Searching policy based on peer's identity '10.150.3.1' of type 'IPv4 address'
*Feb 13 03:58:03.402: IKEv2:found matching IKEv2 profile 'prof-01'
*Feb 13 03:58:03.402: IKEv2:% Getting preshared key from profile keyring kr-01
*Feb 13 03:58:03.403: IKEv2:% Matched peer block 'all'
*Feb 13 03:58:03.404: IKEv2:Searching Policy with fvrf 0, local address 10.150.1.1
*Feb 13 03:58:03.404: IKEv2:Found Policy 'pol-01'
*Feb 13 03:58:03.406: IKEv2:(SESSION ID = 23,SA ID = 1):Verify peer's policy
*Feb 13 03:58:03.408: IKEv2:(SESSION ID = 23,SA ID = 1):Peer's policy verified
*Feb 13 03:58:03.410: IKEv2:(SESSION ID = 23,SA ID = 1):Get peer's authentication method
*Feb 13 03:58:03.410: IKEv2:(SESSION ID = 23,SA ID = 1):Peer's authentication method is 'PSK'
*Feb 13 03:58:03.410: IKEv2:(SESSION ID = 23,SA ID = 1):Get peer's preshared key for 10.150.3.1
*Feb 13 03:58:03.411: IKEv2:(SESSION ID = 23,SA ID = 1):Verify peer's authentication data
*Feb 13 03:58:03.411: IKEv2:(SESSION ID = 23,SA ID = 1):Use preshared key for id 10.150.3.1, key len 8
*Feb 13 03:58:03.411: IKEv2:[IKEv2 -> Crypto Engine] Generate IKEv2 authentication data
*Feb 13 03:58:03.412: IKEv2:[Crypto Engine -> IKEv2] IKEv2 authentication data generation PASSED
*Feb 13 03:58:03.412: IKEv2:(SESSION ID = 23,SA ID = 1):Verification of peer's authentication data PASSED

  • After successful authentication:
    • The responder will create virtual access interface for that peer communication, e.g. Vi1
    • The responder will verify the received aaa group name/password against associated authorization policy with the IKEv2 profile

*Feb 13 03:58:03.417: IKEv2:Using mlist flex and username flex for group author request    …… This was received from initiator
*Feb 13 03:58:03.418: IKEv2:(SA ID = 1):[IKEv2 -> AAA] Authorisation request sent    …… IKEv2 process is sending the verification request to AAA process
*Feb 13 03:58:03.418: IKEv2:(SESSION ID = 22,SA ID = 2):Check for existing active SA
*Feb 13 03:58:03.419: IKEv2:(SESSION ID = 22,SA ID = 2):Deleting SA
*Feb 13 03:58:03.437: %LINEPROTO-5-UPDOWN: Line protocol on Interface Virtual-Access2, changed state to down
*Feb 13 03:58:03.440: %LINK-3-UPDOWN: Interface Virtual-Access2, changed state to down

  • After successful authorization, configuration data will be sent to initiator (IP, Mask, Route, etc)


*Feb 13 03:58:03.449: IKEv2:(SA ID = 1):[AAA -> IKEv2] Received AAA authorisation response
*Feb 13 03:58:03.451: IKEv2:(SESSION ID = 23,SA ID = 1):Received valid config mode data
*Feb 13 03:58:03.452: IKEv2:Config data recieved:
………………output omitted………………

*Feb 13 03:58:03.517: IKEv2:(SESSION ID = 23,SA ID = 1):Config-type: Config-reply
*Feb 13 03:58:03.517: IKEv2:(SESSION ID = 23,SA ID = 1):Attrib type: ipv4-addr, length: 4, data: 192.168.1.13
*Feb 13 03:58:03.518: IKEv2:(SESSION ID = 23,SA ID = 1):Attrib type: ipv4-subnet, length: 8, data: 192.168.1.1 255.255.255.255


*Feb 13 03:58:03.526: IKEv2:(SESSION ID = 23,SA ID = 1):Building packet for encryption.
Payload contents:
 VID IDr AUTH CFG SA TSi TSr NOTIFY(SET_WINDOW_SIZE) NOTIFY(ESP_TFC_NO_SUPPORT) NOTIFY(NON_FIRST_FRAGS)

  • Initiator will apply the received configuration and send INFORMATIONAL message to responder.
    • This message will include CFG_Set payload to configure host route  towards the initiator tunnel IP (route set interface command)

*Feb 13 03:59:05.377: IKEv2:(SESSION ID = 26,SA ID = 2):Received Packet [From 10.150.3.1:500/To 10.150.1.1:500/VRF i0:f0]
Initiator SPI : 8F721AF1CE7527FD - Responder SPI : E891556AF0D35777 Message id: 2
IKEv2 INFORMATIONAL Exchange REQUEST
Payload contents:
 CFG

*Feb 13 03:59:05.381: IKEv2:Config data recieved:
*Feb 13 03:59:05.381: IKEv2:(SESSION ID = 26,SA ID = 2):Config-type: Config-set
*Feb 13 03:59:05.384: IKEv2:(SESSION ID = 26,SA ID = 2):Attrib type: ipv4-subnet, length: 8, data: 192.168.1.13 255.255.255.255
*Feb 13 03:59:05.385: IKEv2:VPN Route Added 192.168.1.13 255.255.255.255 via Virtual-Access2 in vrf global
*Feb 13 03:59:05.386: IKEv2:(SESSION ID = 26,SA ID = 2):Set received config mode data

  • The responder will acknowledge this message with CFG_Ack payload

*Feb 13 03:59:05.390: IKEv2:Config data to send:
*Feb 13 03:59:05.390: IKEv2:(SESSION ID = 26,SA ID = 2):Config-type: Config-ack
*Feb 13 03:59:05.391: IKEv2:(SESSION ID = 26,SA ID = 2):Attrib type: ipv4-subnet, length: 0
*Feb 13 03:59:05.392: IKEv2:(SESSION ID = 26,SA ID = 2):Have config mode data to send
*Feb 13 03:59:05.392: IKEv2:(SESSION ID = 26,SA ID = 2):Sending info exch config resp
*Feb 13 03:59:05.393: IKEv2:(SESSION ID = 26,SA ID = 2):Building packet for encryption.
Payload contents:

 CFG
at No comments:

Sunday, February 11, 2018

VRF-Aware IKEv2 DMVPN (+ iVRF/fVRF + EIGRP)




R1
……………………………………………………………………………………………………………………………………………

vrf definition dmvpn
 !
 address-family ipv4
 exit-address-family
!
crypto ikev2 proposal prop-01
 encryption aes-cbc-128 aes-cbc-192
 integrity sha256 sha512
 group 14 15
!
crypto ikev2 policy pol-01
 proposal prop-01
!
crypto ikev2 keyring dmvpn-key
 peer ALL
  address 0.0.0.0 0.0.0.0
  pre-shared-key cisco123
!
crypto ikev2 profile prof-01
 match identity remote address 0.0.0.0
 authentication local pre-share
 authentication remote pre-share
 keyring local dmvpn-key
!
crypto ipsec transform-set tset esp-aes 192 esp-sha512-hmac
 mode tunnel
!
crypto ipsec profile dmvpn
 set transform-set tset
 set ikev2-profile prof-01
!
interface Loopback0
 vrf forwarding dmvpn
 ip address 10.150.10.1 255.255.255.255
!
interface Tunnel0
 vrf forwarding dmvpn          !!! …. This is to define iVRF
 ip address 192.168.1.1 255.255.255.0
 no ip redirects
 no ip split-horizon eigrp 102
 ip nhrp map multicast dynamic
 ip nhrp network-id 1
 ip nhrp redirect
 tunnel source GigabitEthernet0/0
 tunnel mode gre multipoint
 tunnel protection ipsec profile dmvpn
!
interface GigabitEthernet0/0
 ip address 10.150.1.1 255.255.255.0
!
router eigrp 1
 !
 address-family ipv4 vrf dmvpn autonomous-system 102
  network 10.150.10.1 0.0.0.0
  network 192.168.1.1 0.0.0.0
 exit-address-family
!
ip route 0.0.0.0 0.0.0.0 10.150.1.2

R1# sh cry ikev2 sa
 IPv4 Crypto IKEv2  SA

Tunnel-id Local                 Remote                fvrf/ivrf            Status
1         10.150.1.1/500        10.150.5.1/500        none/dmvpn           READY
      Encr: AES-CBC, keysize: 128, PRF: SHA256, Hash: SHA256, DH Grp:14, Auth sign: PSK, Auth verify: PSK
      Life/Active Time: 86400/5847 sec

Tunnel-id Local                 Remote                fvrf/ivrf            Status
2         10.150.1.1/500        10.150.6.1/500        none/dmvpn           READY
      Encr: AES-CBC, keysize: 128, PRF: SHA256, Hash: SHA256, DH Grp:14, Auth sign: PSK, Auth verify: PSK
      Life/Active Time: 86400/4183 sec

 IPv6 Crypto IKEv2  SA


R5
……………………………………………………………………………………………………………………………………………

vrf definition dmvpn
 !
 address-family ipv4
 exit-address-family
!
crypto ikev2 proposal prop-01
 encryption aes-cbc-128 aes-cbc-192
 integrity sha256 sha512
 group 14 15
!
crypto ikev2 policy pol-01
 match fvrf dmvpn     !!! ….. Because tunnel is invoked using VRF, this policy should be assigned to same Front VRF
 match address local 10.150.5.1     !!! ….. This source interface should be defined as its in VRF Routing Table instead of Global Routing Table
 proposal prop-01
!
crypto ikev2 keyring dmvpn-key
 peer R1
  address 0.0.0.0 0.0.0.0
  pre-shared-key cisco123
!
crypto ikev2 profile prof-01
 match fvrf dmvpn         !!! ….. Because tunnel is invoked using VRF, this profile should be assigned to same Front VRF
 match identity remote address 0.0.0.0
 authentication local pre-share
 authentication remote pre-share
 keyring local dmvpn-key
!
crypto ipsec transform-set tset esp-aes 192 esp-sha512-hmac
 mode tunnel
!
crypto ipsec profile dmvpn
 set transform-set tset
 set ikev2-profile prof-01
!
interface Loopback0
 vrf forwarding dmvpn
 ip address 10.150.50.1 255.255.255.255
!
interface Tunnel0
 vrf forwarding dmvpn    !!! …. Assign iVRF same as fVRF
 ip address 192.168.1.2 255.255.255.0
 no ip redirects
 ip nhrp map 192.168.1.1 10.150.1.1
 ip nhrp map multicast 10.150.1.1
 ip nhrp network-id 1
 ip nhrp nhs 192.168.1.1
 ip nhrp shortcut
 tunnel source GigabitEthernet0/0
 tunnel mode gre multipoint
 tunnel vrf dmvpn    !!! … Invoke the tunnel using Front VRF used on the source interface
 tunnel protection ipsec profile dmvpn
!
interface GigabitEthernet0/0
 vrf forwarding dmvpn
 ip address 10.150.5.1 255.255.255.0
!
router eigrp 1
 !
 address-family ipv4 vrf dmvpn autonomous-system 102
  network 10.150.50.1 0.0.0.0
  network 192.168.1.2 0.0.0.0
 exit-address-family
!
ip route vrf dmvpn 0.0.0.0 0.0.0.0 10.150.5.2

R5#sh cry ikev2 sa
 IPv4 Crypto IKEv2  SA

Tunnel-id Local                 Remote                fvrf/ivrf            Status
2         10.150.5.1/500        10.150.6.1/500        dmvpn/dmvpn          READY
      Encr: AES-CBC, keysize: 128, PRF: SHA256, Hash: SHA256, DH Grp:14, Auth sign: PSK, Auth verify: PSK
      Life/Active Time: 86400/2475 sec

Tunnel-id Local                 Remote                fvrf/ivrf            Status
1         10.150.5.1/500        10.150.1.1/500        dmvpn/dmvpn          READY
      Encr: AES-CBC, keysize: 128, PRF: SHA256, Hash: SHA256, DH Grp:14, Auth sign: PSK, Auth verify: PSK
      Life/Active Time: 86400/6088 sec

 IPv6 Crypto IKEv2  SA

R6 (This is same as R5 except that F-VRF is different from I-VRF)
……………………………………………………………………………………………………………………………………………

vrf definition fvrf-dmvpn
 !
 address-family ipv4
 exit-address-family
!
vrf definition ivrf-dmvpn
 !
 address-family ipv4
 exit-address-family
!
crypto ikev2 proposal prop-01
 encryption aes-cbc-128 aes-cbc-192
 integrity sha256 sha512
 group 14 15
!
crypto ikev2 policy pol-01
 match fvrf fvrf-dmvpn
 proposal prop-01
!
crypto ikev2 keyring dmvpn-key
 peer R1
  address 0.0.0.0 0.0.0.0
  pre-shared-key cisco123
!
crypto ikev2 profile prof-01
 match fvrf fvrf-dmvpn
 match identity remote address 0.0.0.0
 identity local address 10.150.6.1
 authentication local pre-share
 authentication remote pre-share
 keyring local dmvpn-key
!
crypto ipsec transform-set tset esp-aes 192 esp-sha512-hmac
 mode tunnel
!
crypto ipsec profile dmvpn
 set transform-set tset
 set ikev2-profile prof-01
!
interface Loopback0
 vrf forwarding ivrf-dmvpn
 ip address 10.150.60.1 255.255.255.255
!
interface Tunnel0
 vrf forwarding ivrf-dmvpn
 ip address 192.168.1.3 255.255.255.0
 no ip redirects
 ip nhrp map 192.168.1.1 10.150.1.1
 ip nhrp map multicast 10.150.1.1
 ip nhrp network-id 1
 ip nhrp nhs 192.168.1.1
 ip nhrp shortcut
 tunnel source GigabitEthernet0/0
 tunnel mode gre multipoint
 tunnel vrf fvrf-dmvpn
 tunnel protection ipsec profile dmvpn
!
interface GigabitEthernet0/0
 vrf forwarding fvrf-dmvpn
 ip address 10.150.6.1 255.255.255.0
!
router eigrp 1
 !
 address-family ipv4 vrf ivrf-dmvpn autonomous-system 102
  network 10.150.60.1 0.0.0.0
  network 192.168.1.3 0.0.0.0
 exit-address-family
!
ip route vrf fvrf-dmvpn 0.0.0.0 0.0.0.0 10.150.6.2

R6# sh cry ikev2 sa
 IPv4 Crypto IKEv2  SA

Tunnel-id Local                 Remote                fvrf/ivrf            Status
1         10.150.6.1/500        10.150.1.1/500        fvrf-dmvpn/ivrf-dm   READY
      Encr: AES-CBC, keysize: 128, PRF: SHA256, Hash: SHA256, DH Grp:14, Auth sign: PSK, Auth verify: PSK
      Life/Active Time: 86400/4924 sec

Tunnel-id Local                 Remote                fvrf/ivrf            Status
2         10.150.6.1/500        10.150.5.1/500        fvrf-dmvpn/ivrf-dm   READY
      Encr: AES-CBC, keysize: 128, PRF: SHA256, Hash: SHA256, DH Grp:14, Auth sign: PSK, Auth verify: PSK
      Life/Active Time: 86400/2973 sec

 IPv6 Crypto IKEv2  SA

at 1 comment:
Labels:

Friday, February 9, 2018

How Diffie Hellman Secret Session Key is Generated?

  • DH RFCs predefine p and g values for each DH group
    • Example is RFC 5114 which defines

p = B10B8F96 A080E01D DE92DE5E AE5D54EC 52C99FBC FB06A3C6
       9A6A9DCA 52D23B61 6073E286 75A23D18 9838EF1E 2EE652C0
       13ECB4AE A9061123 24975C3C D49B83BF ACCBDD7D 90C4BD70
       98488E9C 219A7372 4EFFD6FA E5644738 FAA31A4F F55BCCC0
       A151AF5F 0DC8B4BD 45BF37DF 365C1A65 E68CFDA7 6D4DA708
       DF1FB2BC 2E4A4371
g = A4D1CBD5 C3FD3412 6765A442 EFB99905 F8104DD2 58AC507F
       D6406CFF 14266D31 266FEA1E 5C41564B 777E690F 5504F213
       160217B4 B01B886A 5E91547F 9E2749F4 D7FBD7D3 B9A92EE1
       909D0D22 63F80A76 A6A24C08 7A091F53 1DBF0A01 69B6A28A
       D662A4D1 8E73AFA3 2D779D59 18D08BC8 858F4DCE F97C2A24
       855E6EEB 22B3B2E5

  • How it works?
    • Initiator chooses a secret integer a = 4, then sends Responder A = ga mod p
      • A = 54 mod 23 = 4
    • Responder chooses a secret integer b = 3, then sends Initiator B = gb mod p
      • B = 53 mod 23 = 10
    • Initiator computes s = Ba mod p
      • s = 104 mod 23 = 18
    • Responder computes s = Ab mod p
      • s = 43 mod 23 = 18
    • Initiator and Responder now share a secret (the number 18)
    • Note that a and b can be as large as 600 digits
at No comments:
Labels:

Diffie Hellman Group Selection in IKEv2

  • Because the initiator sends its KEi value in the IKE_SA_INIT, it must guess the DH group that the responder will select from its list of supported groups.  If the initiator guesses wrong, the responder will respond with a Notify payload of type INVALID_KE_PAYLOAD indicating the selected group.  In this case, the initiator MUST retry the IKE_SA_INIT with the corrected DH group.

*Feb  7 16:17:56.924: IKEv2:(SESSION ID = 1,SA ID = 1):[IKEv2 -> Crypto Engine] Computing DH public key, DH Group 14
*Feb  7 16:17:56.924: IKEv2:(SA ID = 1):[Crypto Engine -> IKEv2] DH key Computation PASSED
*Feb  7 16:17:56.925: IKEv2:(SESSION ID = 1,SA ID = 1):Request queued for computation of DH key
*Feb  7 16:17:56.926: IKEv2:IKEv2 initiator - no config data to send in IKE_SA_INIT exch
*Feb  7 16:17:56.926: IKEv2:(SESSION ID = 1,SA ID = 1):Generating IKE_SA_INIT message
*Feb  7 16:17:56.927: IKEv2:(SESSION ID = 1,SA ID = 1):IKE Proposal: 1, SPI size: 0 (initial negotiation),
Num. transforms: 11
   AES-CBC   AES-CBC   SHA256   SHA384   SHA256   SHA384   DH_GROUP_2048_MODP/Group 14   DH_GROUP_256_ECP/Group 19   DH_GROUP_1536_MODP/Group 5   DH_GROUP_4096_MODP/Group 16   DH_GROUP_3072_MODP/Group 15

*Feb  7 16:17:56.931: IKEv2:(SESSION ID = 1,SA ID = 1):Sending Packet [To 10.150.2.1:500/From 10.150.1.1:500/VRF i0:f0]
Initiator SPI : 97211F401E241BD2 - Responder SPI : 0000000000000000 Message id: 0
IKEv2 IKE_SA_INIT Exchange REQUEST
Payload contents:
 SA KE N VID VID NOTIFY(NAT_DETECTION_SOURCE_IP) NOTIFY(NAT_DETECTION_DESTINATION_IP)

*Feb  7 16:17:56.937: IKEv2:(SESSION ID = 1,SA ID = 1):Insert SA

*Feb  7 16:17:56.950: IKEv2:(SESSION ID = 1,SA ID = 1):Received Packet [From 10.150.2.1:500/To 10.150.1.1:500/VRF i0:f0]
Initiator SPI : 97211F401E241BD2 - Responder SPI : 0000000000000000 Message id: 0
IKEv2 IKE_SA_INIT Exchange RESPONSE
Payload contents:
 NOTIFY(INVALID_KE_PAYLOAD)

*Feb  7 16:17:56.952: IKEv2:(SESSION ID = 1,SA ID = 1):Processing IKE_SA_INIT message
*Feb  7 16:17:56.952: IKEv2:(SESSION ID = 1,SA ID = 1):Processing invalid ke notification, we sent group 14, peer prefers group 5
*Feb  7 16:17:56.953: IKEv2-ERROR:(SESSION ID = 1,SA ID = 1):
*Feb  7 16:17:56.953: IKEv2:(SESSION ID = 1,SA ID = 1):[IKEv2 -> Crypto Engine] Computing DH public key, DH Group 5
*Feb  7 16:17:56.954: IKEv2:(SA ID = 1):[Crypto Engine -> IKEv2] DH key Computation PASSED
*Feb  7 16:17:56.954: IKEv2:(SESSION ID = 1,SA ID = 1):Request queued for computation of DH key
*Feb  7 16:17:56.955: IKEv2:IKEv2 initiator - no config data to send in IKE_SA_INIT exch

*Feb  7 16:17:56.956: IKEv2:(SESSION ID = 1,SA ID = 1):Generating IKE_SA_INIT message
at No comments:
Labels:

PFS in IKEv2

  • Unlike IKEv1, the Perfect Forwarding Secrecy (PFS) Diffie-Hellman (DH) group value displays as 'PFS (Y/N): N, DH group: none' during the first tunnel negotiation.
  • After a rekey occurs, the correct values appear. This is not a bug even though the behavior is described in Cisco bug ID CSCug67056.
  • The reason that IKE_AUTH messages do not contain KEi/KEr or Ni/Nr payloads. Thus, the SA payloads in the IKE_AUTH exchange cannot contain PFS DH group other than NONE.
  • The CREATE_CHILD_SA request used in rekeying MAY optionally contain a KE payload for an PFS DH exchange

For rekeying IKE_SA, the structure of CREATE_CHILD_SA is

   Initiator                                                 Responder
   -------------------------------------------------------------------
   HDR, SK {SA, Ni, KEi} -->
                          <-- hdr="" ker="" nbsp="" nr="" p="" sk="">

For rekeying CHILD_SA, the structure of CREATE_CHILD_SA is

   Initiator                                                 Responder
   -------------------------------------------------------------------
   HDR, SK {N(REKEY_SA), SA, Ni, [KEi,]
       TSi, TSr}   -->


                                          <-- br="" hdr="" nbsp="" nr="" r="" sk="">                                                           TSi, TSr}
at No comments:
Labels:

IKEv1 vs. IKEv2

  • IKEv1 and v2 aren't interoperable
  • Fragmentation
    • In IKEv1, large packets are encrypted then segmented. The segments are encapsulated in UDP packets
    • In IKEv2, large packets are segmented then segments are encrypted.
  • Delete Notification
    • In IKEv1, delete notifications aren't acknowledged. Once delete is sent, SA will be deleted from local SAD
    • In IKEv2, delete notifications are acknowledged. The initiator will wait for ACK or re-Xmit timeout before deleting SA from SAD
      • This is resolved if DPD is used



at No comments:
Labels:
Subscribe to: Posts (Atom)

DNS Performance Troubleshooting

When you are troubleshooting internet performance, there are different parts of the connection should be verified:   ·         DNS Pe...

  • PxGrid Part # 3 - Troubleshooting FMC-ISE Identity Sync
    From FMC CLI, verify ISE integration status using the command   root@vFPMC:/etc/rc.d# cat /var/sf/run/adi-health $status = {      'ADI&#...
  • Enable ISE SSH Access
    If you missed enabling SSH access during the initial setup of ISE, you can enable it using console by pasting the command   service sshd enable
  • CUCM SIP Early Offer
    By default CUCM uses SIP Delayed Offer. In order to enable Early Offer, use one of the following methods: MTP is required ...