Example: AS PIC IKE Dynamic SA Configuration
Figure 1: AS PIC IKE Dynamic SA Topology Diagram

Figure 1 shows the same IPSec topology as seen in the AS PIC manual SA example. However, this configuration requires Routers 2 and 3 to establish an IPSec tunnel using an IKE dynamic SA, enhanced authentication, and stronger encryption. Routers 1 and 4 continue to provide basic connectivity and are used to verify that the IPSec tunnel is operational.
![]() | Note: When you do not specify an IKE proposal, an IPSec proposal, and an IPSec policy on an AS PIC, the Junos OS defaults to the highest level of encryption and authentication. As a result, the default authentication protocol is ESP, the default authentication mode is HMAC-SHA1-96, and the default encryption mode is 3DES-CBC. For more information about default IKE and IPSec policies and proposals on the AS PIC, see IKE and IPSec Proposal and Policy Default Values for the AS and MultiServices PICs. |
On Router 1, provide basic OSPF connectivity to Router 2.
Router 1
On Router 2, enable OSPF as the underlying routing protocol to connect to Routers 1 and 3. Configure a bidirectional IKE dynamic SA in a rule called rule-ike at the [edit ipsec-vpn rule] hierarchy level. Reference this rule in a service set called service-set-dynamic-BiEspsha3des at the [edit services service-set] hierarchy level.
Using default values in the AS PIC, you do not need to specify an IPSec proposal, IPSec policy, or IKE proposal. However, you do need to configure a preshared key in an IKE policy with the pre-shared-key statement at the [edit services ipsec-vpn ike policy policy-name] hierarchy level. (For more information about default IKE and IPSec policies and proposals on the AS PIC, see IKE and IPSec Proposal and Policy Default Values for the AS and MultiServices PICs.)
To direct traffic into the AS PIC and the IPSec tunnel, configure a next-hop style service set and add the adaptive services logical interface used as the IPSec inside interface into the OSPF configuration.
Router 2
On Router 3, enable OSPF as the underlying routing protocol to connect to Routers 2 and 4. Configure a bidirectional IKE dynamic SA in a rule called rule-ike at the [edit ipsec-vpn rule] hierarchy level. Reference this rule in a service set called service-set-dynamic-BiEspsha3des at the [edit services service-set] hierarchy level.
Again, use the same default policies and proposals that you used on Router 2. However, remember to configure a preshared key in an IKE policy with the pre-shared-key statement at the [edit services ipsec-vpn ike policy policy-name] hierarchy level. The key must match the one you specified on Router 2. (For more information about default IKE and IPSec policies and proposals on the AS PIC, see IKE and IPSec Proposal and Policy Default Values for the AS and MultiServices PICs.)
To direct traffic into the AS PIC and the IPSec tunnel, configure a next-hop style service set and add the adaptive services logical interface used as the IPSec inside interface into the OSPF configuration.
Router 3
On Router 4, provide basic OSPF connectivity to Router 3.
Router 4
Verifying Your Work
To verify proper operation of an IKE-based dynamic SA on the AS PIC, use the following commands:
- ping
- show services ipsec-vpn ike security-associations (detail)
- show services ipsec-vpn ipsec security-associations (detail)
- show services ipsec-vpn ipsec statistics
- traceroute
The following sections show the output of these commands used with the configuration example:
Router 1
On Router 1, issue a ping command to the so-0/0/0 interface on Router 4 to send traffic across the IPSec tunnel.
user@R1> ping 10.1.56.2
PING 10.1.56.2 (10.1.56.2): 56 data bytes 64 bytes from 10.1.56.2: icmp_seq=0 ttl=254 time=1.351 ms 64 bytes from 10.1.56.2: icmp_seq=1 ttl=254 time=1.187 ms 64 bytes from 10.1.56.2: icmp_seq=2 ttl=254 time=1.172 ms 64 bytes from 10.1.56.2: icmp_seq=3 ttl=254 time=1.154 ms 64 bytes from 10.1.56.2: icmp_seq=4 ttl=254 time=1.156 ms ^C --- 10.1.56.2 ping statistics --- 5 packets transmitted, 5 packets received, 0% packet loss round-trip min/avg/max/stddev = 1.154/1.204/1.351/0.074 ms
Router 2
To verify that the IKE SA negotiation is successful, issue the show services ipsec-vpn ike security-associations command.
user@R2> show services ipsec-vpn ike
security-associations
Remote Address State Initiator cookie Responder cookie Exchange type 10.1.15.2 Matured 03075bd3a0000003 4bff26a5c7000003 Main
To verify that the IPSec security association is active, issue the show services ipsec-vpn ipsec security-associations detail command. Notice that the SA contains the default settings inherent in the AS PIC, such as ESP for the protocol and HMAC-SHA1-96 for the authentication algorithm.
user@R2> show services ipsec-vpn ipsec
security-associations detail
Service set: service-set-dynamic-BiEspsha3des Rule: rule-ike, Term: term-ike, Tunnel index: 1 Local gateway: 10.1.15.1, Remote gateway: 10.1.15.2 Local identity: ipv4_subnet(any:0,[0..7]=10.1.12.0/24) Remote identity: ipv4_subnet(any:0,[0..7]=10.1.56.0/24) Direction: inbound, SPI: 2666326758, AUX-SPI: 0 Mode: tunnel, Type: dynamic, State: Installed Protocol: ESP, Authentication: hmac-sha1-96, Encryption: 3des-cbc Soft lifetime: Expires in 26863 seconds Hard lifetime: Expires in 26998 seconds Anti-replay service: Enabled, Replay window size: 64 Direction: outbound, SPI: 684772754, AUX-SPI: 0 Mode: tunnel, Type: dynamic, State: Installed Protocol: ESP, Authentication: hmac-sha1-96, Encryption: 3des-cbc Soft lifetime: Expires in 26863 seconds Hard lifetime: Expires in 26998 seconds Anti-replay service: Enabled, Replay window size: 64
To verify that traffic is traveling over the bidirectional IPSec tunnel, issue the show services ipsec-vpn statistics command:
user@R2> show services ipsec-vpn ipsec
statistics
PIC: sp-1/2/0, Service set: service-set-dynamic-BiEspsha3des ESP Statistics: Encrypted bytes: 2248 Decrypted bytes: 2120 Encrypted packets: 27 Decrypted packets: 25 AH Statistics: Input bytes: 0 Output bytes: 0 Input packets: 0 Output packets: 0 Errors: AH authentication failures: 0, Replay errors: 0 ESP authentication failures: 0, ESP decryption failures: 0
Bad headers: 0, Bad trailers: 0
Router 3
To verify that the IKE SA negotiation is successful, issue the show services ipsec-vpn ike security-associations command. To be successful, the SA on Router 3 must contain the same settings you specified on Router 2.
user@R3> show services ipsec-vpn ike
security-associations
Remote Address State Initiator cookie Responder cookie Exchange type 10.1.15.1 Matured 03075bd3a0000003 4bff26a5c7000003 Main
To verify that the IPSec SA is active, issue the show services ipsec-vpn ipsec security-associations detail command. To be successful, the SA on Router 3 must contain the same settings you specified on Router 2.
user@R3> show services ipsec-vpn ipsec
security-associations detail
Service set: service-set-dynamic-BiEspsha3des Rule: rule-ike, Term: term-ike, Tunnel index: 1 Local gateway: 10.1.15.2, Remote gateway: 10.1.15.1 Local identity: ipv4_subnet(any:0,[0..7]=10.1.56.0/24) Remote identity: ipv4_subnet(any:0,[0..7]=10.1.12.0/24) Direction: inbound, SPI: 684772754, AUX-SPI: 0 Mode: tunnel, Type: dynamic, State: Installed Protocol: ESP, Authentication: hmac-sha1-96, Encryption: 3des-cbc Soft lifetime: Expires in 26598 seconds Hard lifetime: Expires in 26688 seconds Anti-replay service: Enabled, Replay window size: 64 Direction: outbound, SPI: 2666326758, AUX-SPI: 0 Mode: tunnel, Type: dynamic, State: Installed Protocol: ESP, Authentication: hmac-sha1-96, Encryption: 3des-cbc Soft lifetime: Expires in 26598 seconds Hard lifetime: Expires in 26688 seconds Anti-replay service: Enabled, Replay window size: 64
To verify that traffic is traveling over the bidirectional IPSec tunnel, issue the show services ipsec-vpn statistics command:
user@R3> show services ipsec-vpn ipsec
statistics
PIC: sp-1/2/0, Service set: service-set-dynamic-BiEspsha3des ESP Statistics: Encrypted bytes: 2120 Decrypted bytes: 2248 Encrypted packets: 25 Decrypted packets: 27 AH Statistics: Input bytes: 0 Output bytes: 0 Input packets: 0 Output packets: 0 Errors: AH authentication failures: 0, Replay errors: 0 ESP authentication failures: 0, ESP decryption failures: 0
Bad headers: 0, Bad trailers: 0
Router 4
On Router 4, issue a ping command to the so-0/0/0 interface on Router 1 to send traffic across the IPSec tunnel.
user@R4> ping 10.1.12.2
PING 10.1.12.2 (10.1.12.2): 56 data bytes 64 bytes from 10.1.12.2: icmp_seq=0 ttl=254 time=1.350 ms 64 bytes from 10.1.12.2: icmp_seq=1 ttl=254 time=1.161 ms 64 bytes from 10.1.12.2: icmp_seq=2 ttl=254 time=1.124 ms 64 bytes from 10.1.12.2: icmp_seq=3 ttl=254 time=1.142 ms 64 bytes from 10.1.12.2: icmp_seq=4 ttl=254 time=1.139 ms 64 bytes from 10.1.12.2: icmp_seq=5 ttl=254 time=1.116 ms ^C --- 10.1.12.2 ping statistics --- 6 packets transmitted, 6 packets received, 0% packet loss round-trip min/avg/max/stddev = 1.116/1.172/1.350/0.081 ms
The final way you can confirm that traffic travels over the IPSec tunnel is by issuing the traceroute command to the so-0/0/0 interface on Router 1. Notice that the physical interface between Routers 2 and 3 is not referenced in the path; traffic enters the IPSec tunnel through the adaptive services IPSec inside interface on Router 3, passes through the loopback interface on Router 2, and ends at the so-0/0/0 interface on Router 1.
user@R4> traceroute 10.1.12.2
traceroute to 10.1.12.2 (10.1.12.2), 30 hops max, 40 byte packets 1 10.1.15.2 (10.1.15.2) 0.987 ms 0.630 ms 0.563 ms 2 10.0.0.2 (10.0.0.2) 1.194 ms 1.058 ms 1.033 ms 3 10.1.12.2 (10.1.12.2) 1.073 ms 0.949 ms 0.932 ms