A tunnel ISA can only be provisioned on an FP2- or FP3-based IOM. The following output displays a card and ISA configuration.
The following output displays a tunnel group configuration in the ISA context. The multi-active command specifies that there could be multiple active ISAs in the tunnel group, the mda command specifies the MDA ID of the ISA in the tunnel group. There could be multiple MDA commands in the tunnel group.
The following output displays an interface “internet” configured using the network port (1/1/1), which provides network connection on the public side.
The following output displays an IPsec configuration example.
The following output displays an IES and VPRN service with IPsec parameters configured.
The following displays steps to configure certificate enrollment.
The following displays steps to configure CA certificate/CRL import.
The following displays a certificate authentication for IKEv2 static LAN-to-LAN tunnel configuration.
The following displays an example of the syntax to import a certificate from the pem format.
The following displays and example of the syntax to export a certificate to the pem format.
The following is an MIMP configuration example.
The peer’s tunnel-group id is not necessarily the same as the local tunnel-group id. With bfd-enable, the BFD parameters are specified under the interface that the MIMP source address resides on, which must be a loopback interface in the base routing instance. The default source address of MIMP is the system address.
The keep-alive-interval and hold-on-neighbor-failure define the MIMP alive parameter, however, BFD could be used for faster chassis failure detection.
The SR OS also provides a tool command to manually trigger the switchover such as:
The following displays an MCS for MC-IPsec configuration.
The sync-tag must matched on both chassis for the corresponding tunnel-groups.
The following configuration is an example using a route policy to export /32 local tunnel address route:
The following configuration shows shunting in public and private service.
Shunting in public service:
Shunting in private service:
Shunting is enabled by configuring redundant next-hop on a public or private IPsec interface
static-tunnel-redundant-next-hop — Shunting nexthop for a static tunnel.
dynamic-tunnel-redundant-next-hop — Shunting next-hop for a dynamic tunnel.
CMPv2 server information is configured under corresponding ca-profile by using following key commands:
The url command specifies the HTTP URL of the CMPv2 server, the service specifies the routing instance that the system used to access the CMPv2 server (if omitted, then system will use base routing instance).
The service ID is only needed for inband connections to the server via VPRN services. IES services are not to be referenced by the service ID as any of those are considered base routing instance.
The response-signing-cert command specifies a imported certificate that is used to verify the CMP response message if they are protected by signature. If this command is not configured, then CA’s certificate will be used.
The keylist specifies a list of pre-shared-key used for CMPv2 initial registration message protection.
For example:
All CMPv2 operations are invoked by using the admin certificate cmpv2 command.
If there is no key-list defined under the cmpv2 configuration, the system will default to the cmpv2 transaction input for the command line for authenticating a message without a sender ID. Also, if there is no sender ID in the response message, and there IS a key-list defined, it will choose the lexicographical first entry only, if that fails, it will have a fail result for the transaction.
Refer to the command reference section for details about syntax and usage. The system supports optional commands (such as, always-set-sender-ir) to support inter-op with CMPv2 servers.
OCSP server information is configured under the corresponding ca-profile:
The responder-url command specifies the HTTP URL of the OCSP responder. The service command specifies the routing instance that system used to access the OCSP responder.
Example:
For a given ipsec-tunnel or ipsec-gw, the user can configure a primary method, a secondary method and a default result.
Example:
The following are configuration tasks for an IKEv2 remote-access tunnel:
The following shows an example using cert-radius:
The following are configuration tasks of IKEv2 remote-access tunnel:
The following output shows an example using cert-auth:
The following is an example config for secured interface. In this example, a SI tunnel “t1” is configured under interface “toPeer-1” in Base routing instance, along with an exception filter 100 that allows OSPF packets bypass IPsec processing: