1.. SPDX-License-Identifier: BSD-3-Clause 2 Copyright(c) 2016-2017 Intel Corporation. 3 4IPsec Security Gateway Sample Application 5========================================= 6 7The IPsec Security Gateway application is an example of a "real world" 8application using DPDK cryptodev framework. 9 10Overview 11-------- 12 13The application demonstrates the implementation of a Security Gateway 14(not IPsec compliant, see the Constraints section below) using DPDK based on RFC4301, 15RFC4303, RFC3602 and RFC2404. 16 17Internet Key Exchange (IKE) is not implemented, so only manual setting of 18Security Policies and Security Associations is supported. 19 20The Security Policies (SP) are implemented as ACL rules, the Security 21Associations (SA) are stored in a table and the routing is implemented 22using LPM. 23 24The application classifies the ports as *Protected* and *Unprotected*. 25Thus, traffic received on an Unprotected or Protected port is consider 26Inbound or Outbound respectively. 27 28The application also supports complete IPsec protocol offload to hardware 29(Look aside crypto accelerator or using ethernet device). It also support 30inline ipsec processing by the supported ethernet device during transmission. 31These modes can be selected during the SA creation configuration. 32 33In case of complete protocol offload, the processing of headers(ESP and outer 34IP header) is done by the hardware and the application does not need to 35add/remove them during outbound/inbound processing. 36 37For inline offloaded outbound traffic, the application will not do the LPM 38lookup for routing, as the port on which the packet has to be forwarded will be 39part of the SA. Security parameters will be configured on that port only, and 40sending the packet on other ports could result in unencrypted packets being 41sent out. 42 43The Path for IPsec Inbound traffic is: 44 45* Read packets from the port. 46* Classify packets between IPv4 and ESP. 47* Perform Inbound SA lookup for ESP packets based on their SPI. 48* Perform Verification/Decryption (Not needed in case of inline ipsec). 49* Remove ESP and outer IP header (Not needed in case of protocol offload). 50* Inbound SP check using ACL of decrypted packets and any other IPv4 packets. 51* Routing. 52* Write packet to port. 53 54The Path for the IPsec Outbound traffic is: 55 56* Read packets from the port. 57* Perform Outbound SP check using ACL of all IPv4 traffic. 58* Perform Outbound SA lookup for packets that need IPsec protection. 59* Add ESP and outer IP header (Not needed in case protocol offload). 60* Perform Encryption/Digest (Not needed in case of inline ipsec). 61* Routing. 62* Write packet to port. 63 64 65Constraints 66----------- 67 68* No IPv6 options headers. 69* No AH mode. 70* Supported algorithms: AES-CBC, AES-CTR, AES-GCM, 3DES-CBC, HMAC-SHA1 and NULL. 71* Each SA must be handle by a unique lcore (*1 RX queue per port*). 72 73Compiling the Application 74------------------------- 75 76To compile the sample application see :doc:`compiling`. 77 78The application is located in the ``ipsec-secgw`` sub-directory. 79 80#. [Optional] Build the application for debugging: 81 This option adds some extra flags, disables compiler optimizations and 82 is verbose:: 83 84 make DEBUG=1 85 86 87Running the Application 88----------------------- 89 90The application has a number of command line options:: 91 92 93 ./build/ipsec-secgw [EAL options] -- 94 -p PORTMASK -P -u PORTMASK -j FRAMESIZE 95 -l -w REPLAY_WINOW_SIZE -e -a 96 --config (port,queue,lcore)[,(port,queue,lcore] 97 --single-sa SAIDX 98 --rxoffload MASK 99 --txoffload MASK 100 --mtu MTU 101 --reassemble NUM 102 -f CONFIG_FILE_PATH 103 104Where: 105 106* ``-p PORTMASK``: Hexadecimal bitmask of ports to configure. 107 108* ``-P``: *optional*. Sets all ports to promiscuous mode so that packets are 109 accepted regardless of the packet's Ethernet MAC destination address. 110 Without this option, only packets with the Ethernet MAC destination address 111 set to the Ethernet address of the port are accepted (default is enabled). 112 113* ``-u PORTMASK``: hexadecimal bitmask of unprotected ports 114 115* ``-j FRAMESIZE``: *optional*. data buffer size (in bytes), 116 in other words maximum data size for one segment. 117 Packets with length bigger then FRAMESIZE still can be received, 118 but will be segmented. 119 Default value: RTE_MBUF_DEFAULT_BUF_SIZE (2176) 120 Minimum value: RTE_MBUF_DEFAULT_BUF_SIZE (2176) 121 Maximum value: UINT16_MAX (65535). 122 123* ``-l``: enables code-path that uses librte_ipsec. 124 125* ``-w REPLAY_WINOW_SIZE``: specifies the IPsec sequence number replay window 126 size for each Security Association (available only with librte_ipsec 127 code path). 128 129* ``-e``: enables Security Association extended sequence number processing 130 (available only with librte_ipsec code path). 131 132* ``-a``: enables Security Association sequence number atomic behavior 133 (available only with librte_ipsec code path). 134 135* ``--config (port,queue,lcore)[,(port,queue,lcore)]``: determines which queues 136 from which ports are mapped to which cores. 137 138* ``--single-sa SAIDX``: use a single SA for outbound traffic, bypassing the SP 139 on both Inbound and Outbound. This option is meant for debugging/performance 140 purposes. 141 142* ``--rxoffload MASK``: RX HW offload capabilities to enable/use on this port 143 (bitmask of DEV_RX_OFFLOAD_* values). It is an optional parameter and 144 allows user to disable some of the RX HW offload capabilities. 145 By default all HW RX offloads are enabled. 146 147* ``--txoffload MASK``: TX HW offload capabilities to enable/use on this port 148 (bitmask of DEV_TX_OFFLOAD_* values). It is an optional parameter and 149 allows user to disable some of the TX HW offload capabilities. 150 By default all HW TX offloads are enabled. 151 152* ``--mtu MTU``: MTU value (in bytes) on all attached ethernet ports. 153 Outgoing packets with length bigger then MTU will be fragmented. 154 Incoming packets with length bigger then MTU will be discarded. 155 Default value: 1500. 156 157* ``--reassemble NUM``: max number of entries in reassemble fragment table. 158 Zero value disables reassembly functionality. 159 Default value: 0. 160 161* ``-f CONFIG_FILE_PATH``: the full path of text-based file containing all 162 configuration items for running the application (See Configuration file 163 syntax section below). ``-f CONFIG_FILE_PATH`` **must** be specified. 164 **ONLY** the UNIX format configuration file is accepted. 165 166 167The mapping of lcores to port/queues is similar to other l3fwd applications. 168 169For example, given the following command line:: 170 171 ./build/ipsec-secgw -l 20,21 -n 4 --socket-mem 0,2048 \ 172 --vdev "crypto_null" -- -p 0xf -P -u 0x3 \ 173 --config="(0,0,20),(1,0,20),(2,0,21),(3,0,21)" \ 174 -f /path/to/config_file \ 175 176where each options means: 177 178* The ``-l`` option enables cores 20 and 21. 179 180* The ``-n`` option sets memory 4 channels. 181 182* The ``--socket-mem`` to use 2GB on socket 1. 183 184* The ``--vdev "crypto_null"`` option creates virtual NULL cryptodev PMD. 185 186* The ``-p`` option enables ports (detected) 0, 1, 2 and 3. 187 188* The ``-P`` option enables promiscuous mode. 189 190* The ``-u`` option sets ports 1 and 2 as unprotected, leaving 2 and 3 as protected. 191 192* The ``--config`` option enables one queue per port with the following mapping: 193 194 +----------+-----------+-----------+---------------------------------------+ 195 | **Port** | **Queue** | **lcore** | **Description** | 196 | | | | | 197 +----------+-----------+-----------+---------------------------------------+ 198 | 0 | 0 | 20 | Map queue 0 from port 0 to lcore 20. | 199 | | | | | 200 +----------+-----------+-----------+---------------------------------------+ 201 | 1 | 0 | 20 | Map queue 0 from port 1 to lcore 20. | 202 | | | | | 203 +----------+-----------+-----------+---------------------------------------+ 204 | 2 | 0 | 21 | Map queue 0 from port 2 to lcore 21. | 205 | | | | | 206 +----------+-----------+-----------+---------------------------------------+ 207 | 3 | 0 | 21 | Map queue 0 from port 3 to lcore 21. | 208 | | | | | 209 +----------+-----------+-----------+---------------------------------------+ 210 211* The ``-f /path/to/config_file`` option enables the application read and 212 parse the configuration file specified, and configures the application 213 with a given set of SP, SA and Routing entries accordingly. The syntax of 214 the configuration file will be explained below in more detail. Please 215 **note** the parser only accepts UNIX format text file. Other formats 216 such as DOS/MAC format will cause a parse error. 217 218Refer to the *DPDK Getting Started Guide* for general information on running 219applications and the Environment Abstraction Layer (EAL) options. 220 221The application would do a best effort to "map" crypto devices to cores, with 222hardware devices having priority. Basically, hardware devices if present would 223be assigned to a core before software ones. 224This means that if the application is using a single core and both hardware 225and software crypto devices are detected, hardware devices will be used. 226 227A way to achieve the case where you want to force the use of virtual crypto 228devices is to whitelist the Ethernet devices needed and therefore implicitly 229blacklisting all hardware crypto devices. 230 231For example, something like the following command line: 232 233.. code-block:: console 234 235 ./build/ipsec-secgw -l 20,21 -n 4 --socket-mem 0,2048 \ 236 -w 81:00.0 -w 81:00.1 -w 81:00.2 -w 81:00.3 \ 237 --vdev "crypto_aesni_mb" --vdev "crypto_null" \ 238 -- \ 239 -p 0xf -P -u 0x3 --config="(0,0,20),(1,0,20),(2,0,21),(3,0,21)" \ 240 -f sample.cfg 241 242 243Configurations 244-------------- 245 246The following sections provide the syntax of configurations to initialize 247your SP, SA, Routing and Neighbour tables. 248Configurations shall be specified in the configuration file to be passed to 249the application. The file is then parsed by the application. The successful 250parsing will result in the appropriate rules being applied to the tables 251accordingly. 252 253 254Configuration File Syntax 255~~~~~~~~~~~~~~~~~~~~~~~~~ 256 257As mention in the overview, the Security Policies are ACL rules. 258The application parsers the rules specified in the configuration file and 259passes them to the ACL table, and replicates them per socket in use. 260 261Following are the configuration file syntax. 262 263General rule syntax 264^^^^^^^^^^^^^^^^^^^ 265 266The parse treats one line in the configuration file as one configuration 267item (unless the line concatenation symbol exists). Every configuration 268item shall follow the syntax of either SP, SA, Routing or Neighbour 269rules specified below. 270 271The configuration parser supports the following special symbols: 272 273 * Comment symbol **#**. Any character from this symbol to the end of 274 line is treated as comment and will not be parsed. 275 276 * Line concatenation symbol **\\**. This symbol shall be placed in the end 277 of the line to be concatenated to the line below. Multiple lines' 278 concatenation is supported. 279 280 281SP rule syntax 282^^^^^^^^^^^^^^ 283 284The SP rule syntax is shown as follows: 285 286.. code-block:: console 287 288 sp <ip_ver> <dir> esp <action> <priority> <src_ip> <dst_ip> 289 <proto> <sport> <dport> 290 291 292where each options means: 293 294``<ip_ver>`` 295 296 * IP protocol version 297 298 * Optional: No 299 300 * Available options: 301 302 * *ipv4*: IP protocol version 4 303 * *ipv6*: IP protocol version 6 304 305``<dir>`` 306 307 * The traffic direction 308 309 * Optional: No 310 311 * Available options: 312 313 * *in*: inbound traffic 314 * *out*: outbound traffic 315 316``<action>`` 317 318 * IPsec action 319 320 * Optional: No 321 322 * Available options: 323 324 * *protect <SA_idx>*: the specified traffic is protected by SA rule 325 with id SA_idx 326 * *bypass*: the specified traffic traffic is bypassed 327 * *discard*: the specified traffic is discarded 328 329``<priority>`` 330 331 * Rule priority 332 333 * Optional: Yes, default priority 0 will be used 334 335 * Syntax: *pri <id>* 336 337``<src_ip>`` 338 339 * The source IP address and mask 340 341 * Optional: Yes, default address 0.0.0.0 and mask of 0 will be used 342 343 * Syntax: 344 345 * *src X.X.X.X/Y* for IPv4 346 * *src XXXX:XXXX:XXXX:XXXX:XXXX:XXXX:XXXX:XXXX/Y* for IPv6 347 348``<dst_ip>`` 349 350 * The destination IP address and mask 351 352 * Optional: Yes, default address 0.0.0.0 and mask of 0 will be used 353 354 * Syntax: 355 356 * *dst X.X.X.X/Y* for IPv4 357 * *dst XXXX:XXXX:XXXX:XXXX:XXXX:XXXX:XXXX:XXXX/Y* for IPv6 358 359``<proto>`` 360 361 * The protocol start and end range 362 363 * Optional: yes, default range of 0 to 0 will be used 364 365 * Syntax: *proto X:Y* 366 367``<sport>`` 368 369 * The source port start and end range 370 371 * Optional: yes, default range of 0 to 0 will be used 372 373 * Syntax: *sport X:Y* 374 375``<dport>`` 376 377 * The destination port start and end range 378 379 * Optional: yes, default range of 0 to 0 will be used 380 381 * Syntax: *dport X:Y* 382 383Example SP rules: 384 385.. code-block:: console 386 387 sp ipv4 out esp protect 105 pri 1 dst 192.168.115.0/24 sport 0:65535 \ 388 dport 0:65535 389 390 sp ipv6 in esp bypass pri 1 dst 0000:0000:0000:0000:5555:5555:\ 391 0000:0000/96 sport 0:65535 dport 0:65535 392 393 394SA rule syntax 395^^^^^^^^^^^^^^ 396 397The successfully parsed SA rules will be stored in an array table. 398 399The SA rule syntax is shown as follows: 400 401.. code-block:: console 402 403 sa <dir> <spi> <cipher_algo> <cipher_key> <auth_algo> <auth_key> 404 <mode> <src_ip> <dst_ip> <action_type> <port_id> 405 406where each options means: 407 408``<dir>`` 409 410 * The traffic direction 411 412 * Optional: No 413 414 * Available options: 415 416 * *in*: inbound traffic 417 * *out*: outbound traffic 418 419``<spi>`` 420 421 * The SPI number 422 423 * Optional: No 424 425 * Syntax: unsigned integer number 426 427``<cipher_algo>`` 428 429 * Cipher algorithm 430 431 * Optional: Yes, unless <aead_algo> is not used 432 433 * Available options: 434 435 * *null*: NULL algorithm 436 * *aes-128-cbc*: AES-CBC 128-bit algorithm 437 * *aes-256-cbc*: AES-CBC 256-bit algorithm 438 * *aes-128-ctr*: AES-CTR 128-bit algorithm 439 * *3des-cbc*: 3DES-CBC 192-bit algorithm 440 441 * Syntax: *cipher_algo <your algorithm>* 442 443``<cipher_key>`` 444 445 * Cipher key, NOT available when 'null' algorithm is used 446 447 * Optional: Yes, unless <aead_algo> is not used. 448 Must be followed by <cipher_algo> option 449 450 * Syntax: Hexadecimal bytes (0x0-0xFF) concatenate by colon symbol ':'. 451 The number of bytes should be as same as the specified cipher algorithm 452 key size. 453 454 For example: *cipher_key A1:B2:C3:D4:A1:B2:C3:D4:A1:B2:C3:D4: 455 A1:B2:C3:D4* 456 457``<auth_algo>`` 458 459 * Authentication algorithm 460 461 * Optional: Yes, unless <aead_algo> is not used 462 463 * Available options: 464 465 * *null*: NULL algorithm 466 * *sha1-hmac*: HMAC SHA1 algorithm 467 468``<auth_key>`` 469 470 * Authentication key, NOT available when 'null' or 'aes-128-gcm' algorithm 471 is used. 472 473 * Optional: Yes, unless <aead_algo> is not used. 474 Must be followed by <auth_algo> option 475 476 * Syntax: Hexadecimal bytes (0x0-0xFF) concatenate by colon symbol ':'. 477 The number of bytes should be as same as the specified authentication 478 algorithm key size. 479 480 For example: *auth_key A1:B2:C3:D4:A1:B2:C3:D4:A1:B2:C3:D4:A1:B2:C3:D4: 481 A1:B2:C3:D4* 482 483``<aead_algo>`` 484 485 * AEAD algorithm 486 487 * Optional: Yes, unless <cipher_algo> and <auth_algo> are not used 488 489 * Available options: 490 491 * *aes-128-gcm*: AES-GCM 128-bit algorithm 492 493 * Syntax: *cipher_algo <your algorithm>* 494 495``<aead_key>`` 496 497 * Cipher key, NOT available when 'null' algorithm is used 498 499 * Optional: Yes, unless <cipher_algo> and <auth_algo> are not used. 500 Must be followed by <aead_algo> option 501 502 * Syntax: Hexadecimal bytes (0x0-0xFF) concatenate by colon symbol ':'. 503 The number of bytes should be as same as the specified AEAD algorithm 504 key size. 505 506 For example: *aead_key A1:B2:C3:D4:A1:B2:C3:D4:A1:B2:C3:D4: 507 A1:B2:C3:D4* 508 509``<mode>`` 510 511 * The operation mode 512 513 * Optional: No 514 515 * Available options: 516 517 * *ipv4-tunnel*: Tunnel mode for IPv4 packets 518 * *ipv6-tunnel*: Tunnel mode for IPv6 packets 519 * *transport*: transport mode 520 521 * Syntax: mode XXX 522 523``<src_ip>`` 524 525 * The source IP address. This option is not available when 526 transport mode is used 527 528 * Optional: Yes, default address 0.0.0.0 will be used 529 530 * Syntax: 531 532 * *src X.X.X.X* for IPv4 533 * *src XXXX:XXXX:XXXX:XXXX:XXXX:XXXX:XXXX:XXXX* for IPv6 534 535``<dst_ip>`` 536 537 * The destination IP address. This option is not available when 538 transport mode is used 539 540 * Optional: Yes, default address 0.0.0.0 will be used 541 542 * Syntax: 543 544 * *dst X.X.X.X* for IPv4 545 * *dst XXXX:XXXX:XXXX:XXXX:XXXX:XXXX:XXXX:XXXX* for IPv6 546 547``<type>`` 548 549 * Action type to specify the security action. This option specify 550 the SA to be performed with look aside protocol offload to HW 551 accelerator or protocol offload on ethernet device or inline 552 crypto processing on the ethernet device during transmission. 553 554 * Optional: Yes, default type *no-offload* 555 556 * Available options: 557 558 * *lookaside-protocol-offload*: look aside protocol offload to HW accelerator 559 * *inline-protocol-offload*: inline protocol offload on ethernet device 560 * *inline-crypto-offload*: inline crypto processing on ethernet device 561 * *no-offload*: no offloading to hardware 562 563 ``<port_id>`` 564 565 * Port/device ID of the ethernet/crypto accelerator for which the SA is 566 configured. For *inline-crypto-offload* and *inline-protocol-offload*, this 567 port will be used for routing. The routing table will not be referred in 568 this case. 569 570 * Optional: No, if *type* is not *no-offload* 571 572 * Syntax: 573 574 * *port_id X* X is a valid device number in decimal 575 576 577Example SA rules: 578 579.. code-block:: console 580 581 sa out 5 cipher_algo null auth_algo null mode ipv4-tunnel \ 582 src 172.16.1.5 dst 172.16.2.5 583 584 sa out 25 cipher_algo aes-128-cbc \ 585 cipher_key c3:c3:c3:c3:c3:c3:c3:c3:c3:c3:c3:c3:c3:c3:c3:c3 \ 586 auth_algo sha1-hmac \ 587 auth_key c3:c3:c3:c3:c3:c3:c3:c3:c3:c3:c3:c3:c3:c3:c3:c3:c3:c3:c3:c3 \ 588 mode ipv6-tunnel \ 589 src 1111:1111:1111:1111:1111:1111:1111:5555 \ 590 dst 2222:2222:2222:2222:2222:2222:2222:5555 591 592 sa in 105 aead_algo aes-128-gcm \ 593 aead_key de:ad:be:ef:de:ad:be:ef:de:ad:be:ef:de:ad:be:ef:de:ad:be:ef \ 594 mode ipv4-tunnel src 172.16.2.5 dst 172.16.1.5 595 596 sa out 5 cipher_algo aes-128-cbc cipher_key 0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0 \ 597 auth_algo sha1-hmac auth_key 0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0 \ 598 mode ipv4-tunnel src 172.16.1.5 dst 172.16.2.5 \ 599 type lookaside-protocol-offload port_id 4 600 601 sa in 35 aead_algo aes-128-gcm \ 602 aead_key de:ad:be:ef:de:ad:be:ef:de:ad:be:ef:de:ad:be:ef:de:ad:be:ef \ 603 mode ipv4-tunnel src 172.16.2.5 dst 172.16.1.5 \ 604 type inline-crypto-offload port_id 0 605 606Routing rule syntax 607^^^^^^^^^^^^^^^^^^^ 608 609The Routing rule syntax is shown as follows: 610 611.. code-block:: console 612 613 rt <ip_ver> <src_ip> <dst_ip> <port> 614 615 616where each options means: 617 618``<ip_ver>`` 619 620 * IP protocol version 621 622 * Optional: No 623 624 * Available options: 625 626 * *ipv4*: IP protocol version 4 627 * *ipv6*: IP protocol version 6 628 629``<src_ip>`` 630 631 * The source IP address and mask 632 633 * Optional: Yes, default address 0.0.0.0 and mask of 0 will be used 634 635 * Syntax: 636 637 * *src X.X.X.X/Y* for IPv4 638 * *src XXXX:XXXX:XXXX:XXXX:XXXX:XXXX:XXXX:XXXX/Y* for IPv6 639 640``<dst_ip>`` 641 642 * The destination IP address and mask 643 644 * Optional: Yes, default address 0.0.0.0 and mask of 0 will be used 645 646 * Syntax: 647 648 * *dst X.X.X.X/Y* for IPv4 649 * *dst XXXX:XXXX:XXXX:XXXX:XXXX:XXXX:XXXX:XXXX/Y* for IPv6 650 651``<port>`` 652 653 * The traffic output port id 654 655 * Optional: yes, default output port 0 will be used 656 657 * Syntax: *port X* 658 659Example SP rules: 660 661.. code-block:: console 662 663 rt ipv4 dst 172.16.1.5/32 port 0 664 665 rt ipv6 dst 1111:1111:1111:1111:1111:1111:1111:5555/116 port 0 666 667Neighbour rule syntax 668^^^^^^^^^^^^^^^^^^^^^ 669 670The Neighbour rule syntax is shown as follows: 671 672.. code-block:: console 673 674 neigh <port> <dst_mac> 675 676 677where each options means: 678 679``<port>`` 680 681 * The output port id 682 683 * Optional: No 684 685 * Syntax: *port X* 686 687``<dst_mac>`` 688 689 * The destination ethernet address to use for that port 690 691 * Optional: No 692 693 * Syntax: 694 695 * XX:XX:XX:XX:XX:XX 696 697Example Neighbour rules: 698 699.. code-block:: console 700 701 neigh port 0 DE:AD:BE:EF:01:02 702 703Test directory 704-------------- 705 706The test directory contains scripts for testing the various encryption 707algorithms. 708 709The purpose of the scripts is to automate ipsec-secgw testing 710using another system running linux as a DUT. 711 712The user must setup the following environment variables: 713 714* ``SGW_PATH``: path to the ipsec-secgw binary to test. 715 716* ``REMOTE_HOST``: IP address/hostname of the DUT. 717 718* ``REMOTE_IFACE``: interface name for the test-port on the DUT. 719 720* ``ETH_DEV``: ethernet device to be used on the SUT by DPDK ('-w <pci-id>') 721 722Also the user can optionally setup: 723 724* ``SGW_LCORE``: lcore to run ipsec-secgw on (default value is 0) 725 726* ``CRYPTO_DEV``: crypto device to be used ('-w <pci-id>'). If none specified 727 appropriate vdevs will be created by the script 728 729Note that most of the tests require the appropriate crypto PMD/device to be 730available. 731 732Server configuration 733~~~~~~~~~~~~~~~~~~~~ 734 735Two servers are required for the tests, SUT and DUT. 736 737Make sure the user from the SUT can ssh to the DUT without entering the password. 738To enable this feature keys must be setup on the DUT. 739 740``ssh-keygen`` will make a private & public key pair on the SUT. 741 742``ssh-copy-id`` <user name>@<target host name> on the SUT will copy the public 743key to the DUT. It will ask for credentials so that it can upload the public key. 744 745The SUT and DUT are connected through at least 2 NIC ports. 746 747One NIC port is expected to be managed by linux on both machines and will be 748used as a control path. 749 750The second NIC port (test-port) should be bound to DPDK on the SUT, and should 751be managed by linux on the DUT. 752 753The script starts ``ipsec-secgw`` with 2 NIC devices: ``test-port`` and 754``tap vdev``. 755 756It then configures the local tap interface and the remote interface and IPsec 757policies in the following way: 758 759Traffic going over the test-port in both directions has to be protected by IPsec. 760 761Traffic going over the TAP port in both directions does not have to be protected. 762 763i.e: 764 765DUT OS(NIC1)--(IPsec)-->(NIC1)ipsec-secgw(TAP)--(plain)-->(TAP)SUT OS 766 767SUT OS(TAP)--(plain)-->(TAP)psec-secgw(NIC1)--(IPsec)-->(NIC1)DUT OS 768 769It then tries to perform some data transfer using the scheme described above. 770 771usage 772~~~~~ 773 774In the ipsec-secgw/test directory 775 776to run one test for IPv4 or IPv6 777 778/bin/bash linux_test(4|6).sh <ipsec_mode> 779 780to run all tests for IPv4 or IPv6 781 782/bin/bash run_test.sh -4|-6 783 784For the list of available modes please refer to run_test.sh. 785