CDRouter Support

CDRouter Multiport Test Summaries (Full)

test-summary version 13.5

Test Case Descriptions

  • Modules: 14
  • Test Cases: 100

Below is a full description of the testcases in each module


nat-mp.tcl

NAT tests for multiple WAN interfaces using IP routing

Test Module Name Synopsis
Outbound NAT/TCP connections use assigned WAN IP for each WAN link nat-mp.tcl cdrouter_natmp_1 Outbound NAT/TCP connections use assigned WAN IP for each WAN link


    step 1. Open a TCP connection from the LAN client to the WAN ISP
            IP address of the first WAN link
    step 2. Verify the TCP connection is established
    step 3. Verify the source IP address is the assigned WAN address
            for this WAN interface
    step 4. Repeat for all WAN interfaces

    NOTE: By default, this test opens a TCP connection to port 50000. The
    port number can be modified by configuring the testvar 'defaultTcpEchoPort'.

    Example:

    testvar defaultTcpEchoPort 50000


    References:

    IETF RFC 3022 "Traditional IP Network Address Translator (Traditional NAT)"

    https://tools.ietf.org/html/rfc3022

Test Module Name Synopsis
Outbound UDP connections use assigned WAN IP for each link nat-mp.tcl cdrouter_natmp_2 Outbound UDP connections use assigned WAN IP for each link


    step 1. Send an outbound UDP packet with UDP data length 0 from LAN host
            to ISP IP on first WAN port
    step 2. Verify the packet is received on the correct WAN interface
    step 3. Verify the source IP address is the assigned WAN address
            for this WAN interface
    step 4. Repeat for all WAN interfaces

    NOTE: By default, this test opens a UDP connection to port 50000. The
    port number can be modified by configuring the testvar 'defaultUdpEchoPort'.

    Example:

    testvar defaultUdpEchoPort 50000


    References:

    IETF RFC 3022 "Traditional IP Network Address Translator (Traditional NAT)"

    https://tools.ietf.org/html/rfc3022

Test Module Name Synopsis
Outbound NAPT TCP connections with asymmetric paths nat-mp.tcl cdrouter_natmp_100 Outbound NAPT TCP connections with asymmetric paths


    step 1. Configure the remoteHost to return traffic to the NAT IP address
            using the second WAN port
    step 2. Initiate an outbound TCP connection to HTTP server on the
            remoteHost
    step 3. Verify the IPv4 source address on the WAN side is the router's address
    step 4. Verify HTTP traffic succeeds (return TCP traffic will use different WAN port)
    step 5. Close TCP connection from LAN side
    step 6. Repeat test using all additional WAN ports

    NOTE: Inbound packets that arrive on a different WAN port than the original
    outbound traffic should still find their correct NAPT mapping.


    References:

    IETF RFC 3022 "Traditional IP Network Address Translator (Traditional NAT)"

    https://tools.ietf.org/html/rfc3022

Test Module Name Synopsis
Outbound NAPT UDP connections with asymmetric paths nat-mp.tcl cdrouter_natmp_101 Outbound NAPT UDP connections with asymmetric paths


    step 1. Configure the remoteHost to return traffic to the NAT IP address
            using the second WAN port
    step 2. Initiate an outbound UDP connection
    step 3. Verify the UDP packet is received on WAN side
    step 4. Verify the IPv4 source address on the WAN side is the router's address
    step 5. Send a return response back to LAN using different WAN port
    step 6. Verify return packet is received on the LAN
    step 7. Repeat test using all additional WAN ports

    NOTE: Inbound packets that arrive on a different WAN port than the original
    outbound traffic should still find their correct NAPT mapping.

    NOTE: The UDP port used for this test can be configured using:

    Example:

    testvar defaultUdpEchoPort 50000

    It defaults to UDP port 50000.


    References:

    IETF RFC 3022 "Traditional IP Network Address Translator (Traditional NAT)"

    https://tools.ietf.org/html/rfc3022

Test Module Name Synopsis
Outbound NAPT ICMP with asymmetric paths nat-mp.tcl cdrouter_natmp_102 Outbound NAPT ICMP with asymmetric paths


    step 1. Configure the remoteHost to return traffic to the NAT IP address
            using the second WAN port
    step 2. Initiate an outbound ICMP Echo Request
    step 3. Verify the ICMP Echo Request is received on WAN side
    step 4. Send an ICMP Echo Reply back to LAN using different WAN port
    step 5. Verify ICMP Echo Reply is received on the LAN
    step 6. Repeat test using all additional WAN ports

    NOTE: Inbound packets that arrive on a different WAN port than the original
    outbound traffic should still find their correct NAPT mapping.


    References:

    IETF RFC 3022 "Traditional IP Network Address Translator (Traditional NAT)"

    https://tools.ietf.org/html/rfc3022


rip-wan.tcl

RIPv1/v2 testing with multiple WAN interfaces

Test Module Name Synopsis
Verify router sends RIPv1/v2 update on all WAN interfaces rip-wan.tcl cdrouter_ripwan_1 Verify router sends RIPv1/v2 update on all WAN interfaces


    step 1. Listen for RIP reply on each WAN interface
    step 2. Verify RIP version
    step 3. Verify source address of RIP reply

    NOTE: This test is only run if the 'ripSupported' configuration is
    set to 'yes'. The RIP version used for the test can be configured
    using the 'ripVersion' testvar in your configuration file.


    References:

    IETF RFC 2453 "RIP Version 2"

    https://tools.ietf.org/html/rfc2453

Test Module Name Synopsis
Verify router selects WAN RIP route with lowest metric rip-wan.tcl cdrouter_ripwan_2 Verify router selects WAN RIP route with lowest metric


    step 1. Announce new RIPv1/v2 route with metric 5 from all WAN
            interfaces except the last WAN interface
    step 2. Announce the same RIPv1/v2 route with a metric of 2 from
            the last wan interface
    step 3. Forward UDP packet from LAN client to IP address within the
            new RIPv1/v2 route range
    step 4. Verify the packet is forwarded to WAN interface with the
            lowest metric


    References:

    IETF RFC 2453 "RIP Version 2"

    https://tools.ietf.org/html/rfc2453

Test Module Name Synopsis
Verify router does not announce private LAN network on WAN interface rip-wan.tcl cdrouter_ripwan_3 Verify router does not announce private LAN network on WAN interface


    step 1. Listen for RIP updates for 1 minute
    step 2. Verify RIP route for LAN network is not announced as reachable


    References:

    IETF RFC 2453 "RIP Version 2"

    https://tools.ietf.org/html/rfc2453

Test Module Name Synopsis
Verify WAN interface failover based on RIP routes rip-wan.tcl cdrouter_ripwan_5 Verify WAN interface failover based on RIP routes


    step 1. Announce new RIPv1/v2 route with metric 12 from the first WAN
            interface
    step 2. Verify traffic is forwarded from LAN to WAN correctly
    step 3. Announce the same RIPv1/v2 route with a metric of 2 from
            the next WAN interface
    step 4. Verify traffic is forwarded from LAN to WAN correctly using
            the new WAN interface
    step 5. Repeat for each WAN interface using a new RIPv1/v2 route


    References:

    IETF RFC 2453 "RIP Version 2"

    https://tools.ietf.org/html/rfc2453

Test Module Name Synopsis
Verify router sends triggered update to additional WAN interfaces rip-wan.tcl cdrouter_ripwan_8 Verify router sends triggered update to additional WAN interfaces


    step 1. Wait for RIP update on first WAN interface
    step 2. Announce new RIPv1/v2 route with metric 1 from first WAN interface
    step 3. Verify triggered RIP update is sent to additional WAN interfaces
    step 4. Verify metric for triggered update route is the original metric + 1
    step 5. Verify the packet is forwarded from LAN to correct WAN interface


    References:

    IETF RFC 2453 "RIP Version 2"

    https://tools.ietf.org/html/rfc2453

Test Module Name Synopsis
Verify packets originating from WAN are forwarded to correct WAN interface rip-wan.tcl cdrouter_ripwan_9 Verify packets originating from WAN are forwarded to correct WAN interface


    step 1. Announce new RIPv1/v2 route with metric 1 from second WAN interface
    step 2. Originate UDP packet from first WAN interface with destination
            inside new RIP route
    step 3. Verify the packet is forwarded from first WAN interface to
            second WAN interface


    References:

    IETF RFC 2453 "RIP Version 2"

    https://tools.ietf.org/html/rfc2453

Test Module Name Synopsis
Verify router responds to RIP requests on WAN interface rip-wan.tcl cdrouter_ripwan_14 Verify router responds to RIP requests on WAN interface


    step 1. Send RIP Request from new UDP source port to RIP destination address
    step 2. Verify router returns a RIP response
    step 3. Verify the response is sent to the correct UDP port
    step 4. Verify the response is sent using unicast IP destination
    step 5. Repeat for each WAN interface


    References:

    IETF RFC 2453 "RIP Version 2"

    https://tools.ietf.org/html/rfc2453

Test Module Name Synopsis
Verify RIP route timeout and garbage collection timers rip-wan.tcl cdrouter_ripwan_20 Verify RIP route timeout and garbage collection timers


    step 1. Announce new RIPv1/v2 route with metric 1 from first
            WAN interface
    step 2. Wait for RIP route timer to expire
    step 3. Verify RIP route is announced on other WAN interfaces with
            a metric of 16
    step 4. Wait for the RIP garbage collection timer to expire
    step 5. Verify the RIP route is no longer announced on other WAN
            interfaces


    References:

    IETF RFC 2453 "RIP Version 2"

    https://tools.ietf.org/html/rfc2453

Test Module Name Synopsis
Verify router announces WAN route as unreachable when WAN connection is down rip-wan.tcl cdrouter_ripwan_50 Verify router announces WAN route as unreachable when WAN connection is down


    step 1. Announce new RIPv1/v2 route with metric 1 from first WAN interface
    step 2. Terminate PPP link using PPP LCP Terminate (PPPoE or PPTP)
    step 3. Wait up to 15 seconds for triggered update on second WAN interface
    step 4. Verify the route is announced with metric 16 on second WAN interface

    NOTE: This test is only supported if the first WAN interface uses PPP
    to connect. This includes PPPoE and PPTP.


    References:

    IETF RFC 2453 "RIP Version 2"

    https://tools.ietf.org/html/rfc2453

Test Module Name Synopsis
Verify router sends RIP request when WAN link is reestablished rip-wan.tcl cdrouter_ripwan_52 Verify router sends RIP request when WAN link is reestablished


    step 1. Terminate PPP link using PPP LCP Terminate (PPPoE or PPTP)
    step 2. Wait up to 90 seconds for router to send RIP request to learn
            initial routing table

    NOTE: This test is only supported if the first WAN interface uses PPP
    to connect. This includes PPPoE and PPTP.


    References:

    IETF RFC 2453 "RIP Version 2"

    https://tools.ietf.org/html/rfc2453

Test Module Name Synopsis
Verify the maximum number of RIP routes supported on WAN rip-wan.tcl cdrouter_ripwan_100 Verify the maximum number of RIP routes supported on WAN


    step 1. Announce new RIPv1/v2 routes with metric 1 from each WAN interface

            NOTE: The 'ripMaxRoutes' testvar in your configuration file
            determines the number of RIPv1/v2 routes that are announced. This
            number is divided by the number of WAN interfaces to determine
            how many RIPv1/2 routes to announce on each WAN interface.

    step 2. Forward from original LAN client to IP address within the
            each new route range
    step 3. Verify packets are forwarded to correct WAN interface
    step 4. Repeat for each RIP route that was announced


    References:

    IETF RFC 2453 "RIP Version 2"

    https://tools.ietf.org/html/rfc2453


wan-fail.tcl

Failover tests for multiple WAN interfaces

Test Module Name Synopsis
Traffic fails over to second WAN interface when current WAN fails wan-fail.tcl cdrouter_wanfail_1 Traffic fails over to second WAN interface when current WAN fails


    step 1. Initiate an outbound TCP connection to the remoteHost on port 6000
    step 2. Verify the TCP connection is established
    step 3. Determine which WAN link was used
    step 4. Close the TCP connection
    step 5. Configure the used WAN link to drop all incoming packets
    step 6. Continue to initiate a new TCP connection to the remoteHost
    step 7. Wait for connection to establish or wanFailoverTimeout to expire


Test Module Name Synopsis
Traffic restarts after all WAN interfaces fail wan-fail.tcl cdrouter_wanfail_2 Traffic restarts after all WAN interfaces fail


    step 1. Configure all WAN links to drop incoming packets
    step 2. Wait for wanFailoverTimeout to expire
    step 3. Enable all WAN links
    step 4. Initiate an outbound TCP connection to remoteHost port 6000
    step 5. Verify the TCP connection succeeds


Test Module Name Synopsis
Traffic fails over to second WAN interface when DHCP stops responding wan-fail.tcl cdrouter_wanfail_10 Traffic fails over to second WAN interface when DHCP stops responding


    step 1. Initiate an outbound TCP connection to the remoteHost on port 6000
    step 2. Verify the TCP connection is established
    step 3. Determine which WAN link was used
    step 4. Close the TCP connection
    step 5. Disable the DHCP server on the WAN
    step 6. Wait for the DHCP lease to expire on the LAN
    step 7. Continue to initiate a new TCP connection to the remoteHost
    step 8. Wait for connection to establish on other WAN interface
            or wanFailoverTimeout to expire

    NOTE: This test verifies that the router fails over to a second WAN interface
    when the DHCP lease cannot be renewed.


Test Module Name Synopsis
Existing TCP sessions resume or fail gracefully after initial WAN link fails wan-fail.tcl cdrouter_wanfail_18 Existing TCP sessions resume or fail gracefully after initial WAN link fails


    step 1. Initiate an outbound TCP connection to the remoteHost on port 6000
    step 2. Verify the TCP connection is established
    step 3. Determine which WAN link was used
    step 4. Configure the used WAN link to drop all incoming packets
    step 5. Continue to initiate a new TCP connection to the remoteHost
            until the link fails over
    step 6. Wait for connection to establish or wanFailoverTimeout to expire
    step 7. Verify that the original TCP connection can still pass data (or)
            verify that the original TCP connection is reset by the remoteHost

    NOTE: The behavior of existing TCP connections when a WAN interface fails
    is dependent on the type of NAT in use. Typically, when a TCP session fails
    from one WAN interface to another, the TCP packets sent out the second
    WAN interface use a different NAPT source address. In these cases, the
    remote end of the TCP connection will detect an invalid TCP session state
    with the new IP address and Reset the connection. It is also possible to
    configure some devices to use the same NAPT IP address on all WAN links.


Test Module Name Synopsis
DNS queries are forwarded to secondary WAN link DNS after WAN failure wan-fail.tcl cdrouter_wanfail_20 DNS queries are forwarded to secondary WAN link DNS after WAN failure


    step 1. Initiate a DNS query to the router's LAN IP address
    step 2. Verify the query is received by real DNS server on the WAN side
    step 3. Send a return response back to LAN
    step 4. Verify the response is received by LAN client
    step 5. Disable the outbound WAN interface
    step 6. Continue to send a DNS query to the router's LAN IP address
    step 7. Wait for DNS query response or wanFailoverTimeout to expire

    NOTE: In order to pass this test, the router must relay all DNS requests
    sent to its LAN IP address onto the current DNS server for one of the
    WAN interfaces. If multiple WAN links are connected to multiple ISPs,
    each ISP will assign a DNS server for use on the WAN connection.


forward-mp.tcl

Forwarding tests with multiple WAN interfaces

Test Module Name Synopsis
Multiple WAN port forwarding test (LAN to WAN) forward-mp.tcl cdrouter_forward_mp_10 Multiple WAN port forwarding test (LAN to WAN)

    step 1. Send an outbound UDP packet with UDP data length 0 from LAN host
            to ISP IP on first WAN port
    step 2. Verify the packet is received on the correct WAN interface
    step 3. Send UDP packet from LAN to next WAN interface
    step 4. Repeat for all WAN interfaces
    step 5. Repeat for all packet sizes until the maximum packet size is
            reached

    NOTE: The maximum packet size can be configured using the testvar 'lanMtu'.
    When the lanMtu value is set to 'default', CDRouter will automatically
    determine the maximum size packet based on the WAN connection type of the
    first interface.

    NOTE: This test will stop if the number of max failures is reached. This
    value may be configured using testvar forwardingMaxFailures. Setting this
    value to 0 will test each packet size regardles of the result.

    testvar forwardingMaxFailures 20

Test Module Name Synopsis
Multiple WAN port forwarding test (WAN to LAN) forward-mp.tcl cdrouter_forward_mp_11 Multiple WAN port forwarding test (WAN to LAN)

    step 1. Initiate an outbound UDP connection to each WAN IP address to
            establish an initial NAT port mapping
    step 2. Send an inbound UDP packet with UDP data length 0 from WAN host
            on first WAN port to router's public IP address
    step 3. Verify the packet is received on the correct LAN interface
    step 4. Send UDP packet from next WAN interface to LAN
    step 5. Repeat for all WAN interfaces
    step 6. Repeat for all packet sizes until the maximum packet size is
            reached

    NOTE: The maximum packet size can be configured using the testvar lanMtu.
    When the lanMtu value is set to 'default', CDRouter will automatically
    determine the maximum size packet based on the WAN connection type of the
    first interface.

    NOTE: This test will stop if the number of max failures is reached. This
    value may be configured using testvar forwardingMaxFailures. Setting this
    value to 0 will test each packet size regardles of the result.

    testvar forwardingMaxFailures 20


jumbo-mp.tcl

Jumbo MTU forwarding tests with multiple WAN interfaces

Test Module Name Synopsis
Multiple WAN port jumbo MTU forwarding test (LAN to WAN) jumbo-mp.tcl cdrouter_jumbo_mp_10 Multiple WAN port jumbo MTU forwarding test (LAN to WAN)

    step 1. Send an outbound UDP packet that utilizes the maximum supported
            standard mtu of both interfaces from LAN host to ISP IP on first WAN
            port
    step 2. Verify the packet is received on the correct WAN interface
    step 3. Repeat incrementing packet size by 4 until the maximum supported
            jumbo mtu of both interfaces is reached
    step 4. Repeat for all WAN interfaces

    NOTE: The maximum jumbo packet size is configured using the testvar
    jumboMtu.

    NOTE: This test will stop if the number of max failures is reached. This
    value may be configured using testvar forwardingMaxFailures. Setting this
    value to 0 will test each packet size regardles of the result.

    testvar forwardingMaxFailures 20

Test Module Name Synopsis
Multiple WAN port jumbo MTU forwarding test (WAN to LAN) jumbo-mp.tcl cdrouter_jumbo_mp_11 Multiple WAN port jumbo MTU forwarding test (WAN to LAN)

    step 1. Initiate an outbound UDP connection to first WAN IP address to
            establish an initial NAT port mapping that utilizes the maximum
            supported standard mtu of both interfaces
    step 2. Send an inbound UDP packet that utilizes the maximum supported
            standard mtu of both interfaces from WAN host on first WAN port to
            router's public IP address
    step 3. Verify the packet is received on the correct LAN interface
    step 4. Repeat incrementing packet size by 4 until the maximum supported
            jumbo mtu of both interfaces is reached
    step 5. Repeat for all WAN interfaces

    NOTE: The maximum jumbo packet size is configured using the testvar
    jumboMtu.

    NOTE: This test will stop if the number of max failures is reached. This
    value may be configured using testvar forwardingMaxFailures. Setting this
    value to 0 will test each packet size regardles of the result.

    testvar forwardingMaxFailures 20


l2gre.tcl

L2 over GRE related test cases

Test Module Name Synopsis
Verify traffic sent to remote GRE host from LAN is forwarded over L2 GRE tunnel l2gre.tcl l2gre_1 Verify traffic sent to remote GRE host from LAN is forwarded over L2 GRE tunnel


    step 1. Initiate outbound ICMPv4 Echo Requests from a host on the LAN to a
            host within the remote GRE network on the WAN
    step 2. Verify ICMPv4 Echo Replies are received


    References:

    IETF RFC 2784 "Generic Routing Encapsulation (GRE)"

    https://tools.ietf.org/html/rfc2784

Test Module Name Synopsis
Verify traffic sent to LAN from remote GRE host is forwarded over L2 GRE tunnel l2gre.tcl l2gre_2 Verify traffic sent to LAN from remote GRE host is forwarded over L2 GRE tunnel


    step 1. Initiate inbound ICMPv4 Echo Requests from a host within the remote
            GRE network to a host on the LAN
    step 2. Verify ICMPv4 Echo Replies are received


    References:

    IETF RFC 2784 "Generic Routing Encapsulation (GRE)"

    https://tools.ietf.org/html/rfc2784

Test Module Name Synopsis
Verify GRE header fields for L2GRE packet l2gre.tcl l2gre_4 Verify GRE header fields for L2GRE packet


    step 1. Send an IPv4 UDP packet from a host on the LAN to a host within the
            remote GRE network on the WAN
    step 2. Verify that the IPv4 over GRE packet is received on the WAN
    step 3. Verify the following GRE header fields within the received packet:

            Checksum Present (bit 0):      May be 0 or 1
            Reserved0 (bits 1-12):         Must be set to 0
            Version Number (bits 13-15):   Must be set to 0


    References:

    IETF RFC 2784 "Generic Routing Encapsulation (GRE)" Section 2.1: GRE Header

    https://tools.ietf.org/html/rfc2784#section-2.1

Test Module Name Synopsis
Verify DUT fragments large outbound packets sent over GRE tunnel l2gre.tcl l2gre_30 Verify DUT fragments large outbound packets sent over GRE tunnel


    step 1. Send an IPv4 UDP packet from the LAN to a remote GRE host on the WAN
            using a size that requires IPv4 fragmentation
    step 2. Verify that the packet and any fragments are received on the WAN
    step 3. Reassemble the packet and verify the original contents
    step 4. Repeat steps 1 through 3 with IPv4 packets that range in size from
            1490 bytes to 1500 bytes (these packets have a UDP payload size of
            1462 to 1472 bytes)


    References:

    IETF RFC 2784 "Generic Routing Encapsulation (GRE)"

    https://tools.ietf.org/html/rfc2784

Test Module Name Synopsis
Verify DUT sends ICMPv4 Destination Unreachables if a GRE packet needs fragmentation and DF=1 l2gre.tcl l2gre_31 Verify DUT sends ICMPv4 Destination Unreachables if a GRE packet needs fragmentation and DF=1


    step 1. Send an IPv4 UDP packet from the LAN to a remote GRE host on the WAN
            using a size that requires IPv4 fragmentation with DF=1
    step 2. Verify that the DUT sends an ICMPv4 Destination Unreachable
    step 3. Verify that the ICMP code is 4 'fragmentation needed and DF set'


    References:

    IETF RFC 1191 "Path MTU Discovery" Section 2: Protocol overview

    In this memo, we describe a technique for using the Don't Fragment
    (DF) bit in the IP header to dynamically discover the PMTU of a path.
    The basic idea is that a source host initially assumes that the PMTU
    of a path is the (known) MTU of its first hop, and sends all
    datagrams on that path with the DF bit set.  If any of the datagrams
    are too large to be forwarded without fragmentation by some router
    along the path, that router will discard them and return ICMP
    Destination Unreachable messages with a code meaning "fragmentation
    needed and DF set" [7].  Upon receipt of such a message (henceforth
    called a "Datagram Too Big" message), the source host reduces its
    assumed PMTU for the path.

    https://tools.ietf.org/html/rfc1191#section-2

    IETF RFC 2784 "Generic Routing Encapsulation (GRE)"

    https://tools.ietf.org/html/rfc2784

Test Module Name Synopsis
Verify DUT reassembles and forwards fragmented IPv4 UDP packets from the LAN over GRE tunnel l2gre.tcl l2gre_32 Verify DUT reassembles and forwards fragmented IPv4 UDP packets from the LAN over GRE tunnel


    step 1. Send an IPv4 UDP packet from the LAN to a remote GRE host on the WAN
            using a size that does not require fragmentation; send the packet as
            two IPv4 fragments
    step 2. Verify that the packet is reassembled and forwarded over the GRE
            tunnel by the DUT and received by the GRE host on the WAN


    References:

    IETF RFC 2784 "Generic Routing Encapsulation (GRE)"

    https://tools.ietf.org/html/rfc2784

Test Module Name Synopsis
Verify DUT reassembles and forwards fragmented IPv4 UDP packets from the WAN over GRE tunnel l2gre.tcl l2gre_34 Verify DUT reassembles and forwards fragmented IPv4 UDP packets from the WAN over GRE tunnel


    step 1. Send an IPv4 UDP packet from the LAN to a remote GRE host on the WAN
            to establish an outbound connection
    step 2. Verify that the packet is received on the WAN
    step 3. Send an IPv4 UDP packet with a total UDP length of 1470 bytes from
            a remote GRE host on the WAN to a host on the LAN; send the packet
            as two IPv4 fragments
    step 4. Verify that the packet is reassembled and forwarded over the GRE
            tunnel by the DUT and received by the LAN host
    step 5. Repeat steps 2 through 4 for packets with total UDP lengths from
            1470 to 1480


    References:

    IETF RFC 2784 "Generic Routing Encapsulation (GRE)"

    https://tools.ietf.org/html/rfc2784

Test Module Name Synopsis
Verify DUT reassembles and forwards fragmented IPv4 UDP packets from the WAN over GRE tunnel that also require fragmentation on the LAN l2gre.tcl l2gre_35 Verify DUT reassembles and forwards fragmented IPv4 UDP packets from the WAN over GRE tunnel that also require fragmentation on the LAN


    step 1. Send an IPv4 UDP packet from the LAN to a remote GRE host on the WAN
            to establish an outbound connection
    step 2. Verify that the packet is received on the WAN
    step 3. Send an IPv4 UDP packet with a total UDP length of 7997 bytes from
            a remote GRE host on the WAN to a host on the LAN; send the packet
            using multiple IPv4 fragments
    step 4. Verify that the packet is reassembled and forwarded over the GRE
            tunnel by the DUT and received by the LAN host
    step 5. Repeat steps 2 through 4 for packets with total UDP lengths from
            7997 to 8000


    References:

    IETF RFC 2784 "Generic Routing Encapsulation (GRE)"

    https://tools.ietf.org/html/rfc2784

Test Module Name Synopsis
Verify DUT properly reassembles and forwards out of order IPv4 fragments l2gre.tcl l2gre_36 Verify DUT properly reassembles and forwards out of order IPv4 fragments


    step 1. Send an IPv4 UDP Echo packet from the LAN to a remote GRE host on
            the WAN
    step 2. Send an IPv4 UDP Echo response packet from the remote GRE host on
            the WAN to the LAN host; fragment the packet and send the fragments
            in reverse order
    step 3. Verify that the packet is reassembled and forwarded over the GRE
            tunnel by the DUT and received by the LAN host


    References:

    IETF RFC 2784 "Generic Routing Encapsulation (GRE)"

    https://tools.ietf.org/html/rfc2784

Test Module Name Synopsis
Verify DUT sets the DF flag in the GRE delivery header l2gre.tcl l2gre_50 Verify DUT sets the DF flag in the GRE delivery header


    step 1. Send an IPv4 UDP packet to a remote GRE host on the WAN with the DF
            flag set to 0
    step 2. Verify packet is received by remote GRE host on the WAN
    step 3. Verify the DF flag in the GRE header based on the testvar greDFflag:

            When payload DF=0:

                "inherit" - the DF flag should be 0
                "off"     - the DF flag should be 0
                "on"      - the DF flag should be 1

            When payload DF=1

                "inherit" - the DF flag should be 1
                "off"     - the DF flag should be 0
                "on"      - the DF flag should be 1

    step 4. Repeat steps 1 through 3 for DF flag set to 1


    References:

    IETF RFC 2784 "Generic Routing Encapsulation (GRE)"

    https://tools.ietf.org/html/rfc2784

    IETF RFC 7588 "A Widely Deployed Solution to the Generic Routing Encapsulation (GRE) Fragmentation Problem" Section 3.3.2.1: Tunneling GRE over IPv4

    By default, the GRE ingress node does not fragment delivery packets.
    However, the GRE ingress node includes a configuration option that
    allows delivery packet fragmentation.

    By default, the GRE ingress node sets the DF bit in the delivery
    header to 1 (Don't Fragment).  However, the GRE ingress node also
    supports a configuration option that invokes the following behavior:

    o  When the GRE payload is IPv6, the DF bit on the delivery header is
      set to 0 (Fragments Allowed).

    o  When the GRE payload is IPv4, the DF bit is copied from the
       payload header to the delivery header.

    When the DF bit on an IPv4 delivery header is set to 0, the GRE
    delivery packet can be fragmented by any router between the GRE
    ingress and egress nodes.

    https://tools.ietf.org/html/rfc7588#section-3.3.2.1

Test Module Name Synopsis
Verify DUT drops invalid GRE packets l2gre.tcl l2gre_60 Verify DUT drops invalid GRE packets


    step 1. Initiate an outbound ICMPv4 Echo Request from a host on the LAN to a
            host within the remote GRE network on the WAN
    step 2. Send an invalid ICMPv4 Echo Reply packet with a shortened GRE header
    step 3. Verify that the ICMPv4 Echo Reply packet is not forwarded to the LAN
    step 4. Repeat


    References:

    IETF RFC 2784 "Generic Routing Encapsulation (GRE)"

    https://tools.ietf.org/html/rfc2784

Test Module Name Synopsis
Verify DUT supports PMTU discovery for packets sent over GRE tunnel l2gre.tcl l2gre_80 Verify DUT supports PMTU discovery for packets sent over GRE tunnel


    step 1. Send 1500 byte UDP packet with IP Don't Fragment Flag = 1 to the
            remoteVpn host over the L2GRE tunnel
    step 2. Check for an ICMP Destination Unreachable packet with code = 4
    step 3. Repeat process two more times until an ICMP Destination
            Unreachable is received, or all 3 packets are sent
    step 4. If an ICMP Destination Unreachable was sent, verify the
            the code value is 4 and verify MTU value in the ICMP header
    step 5. Reduce the UDP packet size by 1 byte and repeat the process
            until no ICMP Destination Unreachable is sent
    step 6. When a packet size is found that does not generate an
            ICMP Destination Unreachable, verify packets can be forwarded over
            L2GRE tunnel using this packet size
    step 7. Verify the final MTU size is the same as the MTU size
            reported in the ICMP Destination Unreachable packet

    NOTE: Some devices rate limit the number of ICMP packets that may be
          sent. This test will sent 3 UDP packets over a 15 second window
          in order to generate an ICMP unreachable packet. If your device
          uses rate limiting on ICMP packets, it must allow at least 1
          ICMP packet every 10 seconds.


    References:

    IETF RFC 1191 "Path MTU Discovery"

    https://tools.ietf.org/html/rfc1191

    IETF RFC 2784 "Generic Routing Encapsulation (GRE)"

    https://tools.ietf.org/html/rfc2784


lan-mp.tcl

Layer 2 connectivity tests between multiple LAN interfaces

Test Module Name Synopsis
Verify layer 2 broadcast between all LAN ports lan-mp.tcl cdrouter_lan_mp_1 Verify layer 2 broadcast between all LAN ports


    step 1. Initiate ARP broadcast request from first LAN interface to next LAN
    step 2. Repeat ARP request for each LAN interface
    step 3. Move on to the next LAN interface and repeat all combinations
    step 4. Verify ARP broadcast succeeds for each LAN to LAN combination


Test Module Name Synopsis
Verify layer 2 multicast between all LAN ports lan-mp.tcl cdrouter_lan_mp_2 Verify layer 2 multicast between all LAN ports


    step 1. Initiate IGMP Join request from first LAN interface
    step 2. Attempt to forward layer 2 multicast from second LAN interface to first
    step 3. Move on to the next LAN interface and repeat all combinations
    step 4. Verify IGMP multicast succeeds for each LAN to LAN combination


Test Module Name Synopsis
Verify layer 2 unicast between all LAN ports lan-mp.tcl cdrouter_lan_mp_10 Verify layer 2 unicast between all LAN ports


    step 1. Initiate ICMP Echo Request from first LAN interface to next LAN
    step 2. Verify ICMP Echo Reply is received
    step 3. Move on to the next LAN interface and repeat all combinations
    step 4. Verify unicast traffic succeeds for each LAN to LAN combination


Test Module Name Synopsis
Verify ICMP routing between multiple LAN ports lan-mp.tcl cdrouter_lan_mp_20 Verify ICMP routing between multiple LAN ports


    step 1. Initiate ICMP Echo Request from first LAN interface to next LAN
    step 2. Send ICMP Echo Request using the destination MAC address of router's LAN interface
    step 3. Verify ICMP Echo Reply is received by second host
    step 4. Move on to the next LAN interface and repeat all combinations
    step 5. Verify unicast traffic succeeds for each LAN to LAN combination

    NOTE: Forwarding from a LAN client to another LAN client through the router's
    MAC address on the LAN may cause the router to issue an ICMP Redirect.


Test Module Name Synopsis
Verify TCP routing between multiple LAN ports lan-mp.tcl cdrouter_lan_mp_21 Verify TCP routing between multiple LAN ports


    step 1. Initiate HTTP Get from first LAN interface to next LAN
    step 2. Send HTTP Get using the destination MAC address of router's LAN interface
    step 3. Verify HTTP Response is received by second host
    step 4. Move on to the next LAN interface and repeat all combinations
    step 5. Verify unicast traffic succeeds for each LAN to LAN combination

    NOTE: Forwarding from a LAN client to another LAN client through the router's
    MAC address on the LAN may cause the router to issue an ICMP Redirect.


Test Module Name Synopsis
Verify UDP routing between multiple LAN ports lan-mp.tcl cdrouter_lan_mp_22 Verify UDP routing between multiple LAN ports


    step 1. Initiate UDP Echo from first LAN interface to next LAN
    step 2. Send UDP Echo request using the destination MAC address of router's LAN interface
    step 3. Verify UDP Echo response is received by second host
    step 4. Move on to the next LAN interface and repeat all combinations
    step 5. Verify unicast traffic succeeds for each LAN to LAN combination

    NOTE: Forwarding from a LAN client to another LAN client through the router's
    MAC address on the LAN may cause the router to issue an ICMP Redirect.


Test Module Name Synopsis
Verify IP TTL is decremented when routing to multiple LAN ports lan-mp.tcl cdrouter_lan_mp_30 Verify IP TTL is decremented when routing to multiple LAN ports


    step 1. Initiate ICMP Echo Request from first LAN interface to next LAN
    step 2. Send ICMP Echo Request using the destination MAC address of router's LAN interface
    step 3. Verify ICMP Echo Reply is received by second host
    step 4. Verify IPv4 TTL is decremented by 1
    step 5. Move to the second LAN interface and repeat
    step 6. Verify unicast traffic succeeds for each LAN to LAN combination

    NOTE: Forwarding from a LAN client to another LAN client through the router's
    MAC address on the LAN may cause the router to issue an ICMP Redirect.


Test Module Name Synopsis
Verify multi-client multicast support (LAN-LAN) lan-mp.tcl cdrouter_lan_mp_40 Verify multi-client multicast support (LAN-LAN)


    Test Procedure:

    Step 1. For all LAN clients, send an IGMP join to the DUT to subscribe to
            multicast messages on a group within the multicast pool.
    Step 2. For each client send a multicast message to the group.
    Step 3. Send an IGMP leave to the DUT from one of the subscribed clients.
    Step 4. Repeat steps 2 and 3 until there are no more multicast clients.

    Test Metrics:

    1. At step 2, every client that is subscribed to the multicast group or
       shares an interface with a client that is subscribed to the multicast
       group receives a multicast message.
    2. At step 3, every client that has left the multicast group does not
       receive a multicast message if it doesn't share an interface with a
       client that is still a member of the multicast group.


Test Module Name Synopsis
Verify multi-client multicast support (WAN-LAN) lan-mp.tcl cdrouter_lan_mp_45 Verify multi-client multicast support (WAN-LAN)


    Test Procedure:

    Step 1. For all LAN clients, send an IGMP join to the DUT to subscribe to
            multicast messages on a group within the multicast pool.
    Step 2. Send a multicast message to the group from a host on the WAN.
    Step 3. Send an IGMP leave to the DUT from one of the subscribed clients.
    Step 4. Repeat steps 2 and 3 until there are no more multicast clients.

    Test Metrics:

    1. At step 2, every client that is subscribed to the multicast group or
       shares an interface with a client that is subscribed to the multicast
       group receives a multicast message.
    2. At step 3, every client that has left the multicast group does not
       receive a multicast message if it doesn't share an interface with a
       client that is still a member of the multicast group.



nat-static.tcl

Static NAT tests for individual static NAT hosts

Test Module Name Synopsis
Verify ARP Request on WAN interface for each static NAT hosts on same WAN network nat-static.tcl nat_static_1 Verify ARP Request on WAN interface for each static NAT hosts on same WAN network


    step 1. Loop through all static NAT hosts with public IP on the same network as the WAN
    step 2. Send ARP Request for static NAT public IP
    step 3. Verify valid ARP Reply is returned

    NOTE: This test is only run if the WAN interface mode supports ARP. This
    test is skipped for wanMode PPPoE.


    References:

    IETF RFC 3022 "Traditional IP Network Address Translator (Traditional NAT)"

    https://tools.ietf.org/html/rfc3022

Test Module Name Synopsis
Outbound TCP connections through static NAT do not modify TCP src port nat-static.tcl nat_static_2 Outbound TCP connections through static NAT do not modify TCP src port


    step 1. Initiate an outbound TCP connection to TCP server on WAN
    step 2. Verify the connection is established
    step 3. Compare the src port on the LAN and WAN sides of the connection
    step 4. Verify the TCP src port does not change when going through static NAT
    step 5. Close TCP connection from LAN side


    References:

    IETF RFC 3022 "Traditional IP Network Address Translator (Traditional NAT)"

    https://tools.ietf.org/html/rfc3022

Test Module Name Synopsis
Outbound UDP connections through static NAT do not modify UDP src port nat-static.tcl nat_static_3 Outbound UDP connections through static NAT do not modify UDP src port


    step 1. Initiate an outbound UDP connection to UDP server on WAN
    step 2. Verify the UDP packet is received on the WAN
    step 3. Compare the src port on the LAN and WAN sides of the connection
    step 4. Verify the UDP src port does not change when going through static NAT


    References:

    IETF RFC 3022 "Traditional IP Network Address Translator (Traditional NAT)"

    https://tools.ietf.org/html/rfc3022


guest.tcl

Guest mode related test cases

Test Module Name Synopsis
Verify basic behavior of guest mode isolation guest.tcl guest_1 Verify basic behavior of guest mode isolation


    step 1. Verify the client on Guest LAN can ping a remote host.

    step 2. Verify the client on Guest LAN can establish a TCP connection
            with a remote host.

    step 3. Verify that the client on the Guest LAN cannot ping the client
            on the Main LAN.

            a) Verify that a broadcast ARP Request from the client on the
               Guest LAN is not received by the client on the Main LAN.
            b) If the broadcast ARP is received by the client on the Main
               LAN, then verify that a ICMP Echo sent by the client on
               the Guest LAN is not received by the client on the Main LAN.

    step 4. Verify that the client on the Main LAN cannot ping the client
            on the Guest LAN.

            a) Verify that a broadcast ARP Request from the client on the
               Main LAN is not received by the client on the Guest LAN.
            b) If the broadcast ARP is received by the client on the Guest
               LAN, then verify that a ICMP Echo sent by the client on
               the Main LAN is not received by the client on the Guest LAN.

    step 5. Verify that the client on the Guest LAN cannot establish a TCP
            session with the client on the Main LAN.

            a) Verify that a broadcast ARP Request from the client on the
               Guest LAN is not received by the client on the Main LAN.
            b) If the broadcast ARP is received by the client on the Main
               LAN, then verify that the client on the Guest LAN cannot
               establish a TCP session with the client on the Main LAN.

    step 6. Verify that the client on the Main LAN cannot establish a TCP
            session with the client on the Guest LAN.

            a) Verify that a broadcast ARP Request from the client on the
               Main LAN is not received by the client on the Guest LAN.
            b) If the broadcast ARP is received by the client on the Guest
               LAN, then verify that the client on the Main LAN cannot
               establish a TCP session with the client on the Guest LAN.

    NOTE: This test requires the multiport add-on, because it requires at least
          two (2) defined LAN interfaces. The LAN interfaces may either be
          wired or wireless. The only other requirement is that one of the LAN
          interfaces must be defined as a 'guest' interface with the
          testvar lanGuestMode.


Test Module Name Synopsis
Verify ARP traffic from the main LAN is not leaked into the guest network guest.tcl guest_10 Verify ARP traffic from the main LAN is not leaked into the guest network


    step 1. Send a broadcast ARP request from the client on the Main LAN
            looking for the MAC Address of the client on the Guest LAN.

    step 2. Verify that the ARP request is not received by the client on
            the Guest LAN.

    NOTE: This test requires the multiport add-on, because it requires at least
          two (2) defined LAN interfaces. The LAN interfaces may either be
          wired or wireless. The only other requirement is that one of the LAN
          interfaces must be defined as a 'guest' interface with the
          testvar lanGuestMode.


Test Module Name Synopsis
Verify ARP traffic from the guest LAN is not leaked into the main LAN network guest.tcl guest_11 Verify ARP traffic from the guest LAN is not leaked into the main LAN network


    step 1. Send a broadcast ARP request from the client on the Guest LAN
            looking for the MAC Address of the client on the Main LAN.

    step 2. Verify that the ARP request is not received by the client on
            the Main LAN.

    NOTE: This test requires the multiport add-on, because it requires at least
          two (2) defined LAN interfaces. The LAN interfaces may either be
          wired or wireless. The only other requirement is that one of the LAN
          interfaces must be defined as a 'guest' interface with the
          testvar lanGuestMode.


Test Module Name Synopsis
Verify unicast traffic from main LAN is not leaked into the guest network guest.tcl guest_12 Verify unicast traffic from main LAN is not leaked into the guest network


    step 1. Add static ARP entry for client on Guest LAN into ARP table of
            client on the Main LAN.

    step 2. Add static ARP entry for client on Main LAN into ARP table of
            client on the Guest LAN.

    step 3. Send a unicast frame from the client on the Main LAN to the IP
            address of the client on the Guest LAN.

    step 4. Verify that the unicast frame is not received by the client on
            the Guest LAN.

    NOTE: This test requires the multiport add-on, because it requires at least
          two (2) defined LAN interfaces. The LAN interfaces may either be
          wired or wireless. The only other requirement is that one of the LAN
          interfaces must be defined as a 'guest' interface with the
          testvar lanGuestMode.


Test Module Name Synopsis
Verify unicast traffic from guest LAN is not leaked into the main LAN network guest.tcl guest_13 Verify unicast traffic from guest LAN is not leaked into the main LAN network


    step 1. Add static ARP entry for client on Guest LAN into ARP table of
            client on the Main LAN.

    step 2. Add static ARP entry for client on Main LAN into ARP table of
            client on the Guest LAN.

    step 3. Send a unicast frame from the client on the Guest LAN to the IP
            address of the client on the Main LAN.

    step 4. Verify that the unicast frame is not received by the client on
            the Main LAN.

    NOTE: This test requires the multiport add-on, because it requires at least
          two (2) defined LAN interfaces. The LAN interfaces may either be
          wired or wireless. The only other requirement is that one of the LAN
          interfaces must be defined as a 'guest' interface with the
          testvar lanGuestMode.


Test Module Name Synopsis
Verify broadcast traffic from the main LAN is not leaked into the guest network guest.tcl guest_14 Verify broadcast traffic from the main LAN is not leaked into the guest network


    step 1. Send a broadcast frame from the client on the Main LAN.

    step 2. Verify that the broadcast frame is not received by the client on
            the Guest LAN.

    NOTE: This test requires the multiport add-on, because it requires at least
          two (2) defined LAN interfaces. The LAN interfaces may either be
          wired or wireless. The only other requirement is that one of the LAN
          interfaces must be defined as a 'guest' interface with the
          testvar lanGuestMode.


Test Module Name Synopsis
Verify broadcast traffic from guest LAN is not leaked into the main LAN network guest.tcl guest_15 Verify broadcast traffic from guest LAN is not leaked into the main LAN network


    step 1. Send a broadcast frame from the client on the Guest LAN.

    step 2. Verify that the broadcast frame is not received by the client on
            the Main LAN.

    NOTE: This test requires the multiport add-on, because it requires at least
          two (2) defined LAN interfaces. The LAN interfaces may either be
          wired or wireless. The only other requirement is that one of the LAN
          interfaces must be defined as a 'guest' interface with the
          testvar lanGuestMode.


Test Module Name Synopsis
Verify multicast traffic from LAN is not leaked into the guest network guest.tcl guest_16 Verify multicast traffic from LAN is not leaked into the guest network


    step 1. Send a multicast frame from the client on the Main LAN.

    step 2. Verify that the multicast frame is not received by the client on
            the Guest LAN.

    NOTE: This test requires the multiport add-on, because it requires at least
          two (2) defined LAN interfaces. The LAN interfaces may either be
          wired or wireless. The only other requirement is that one of the LAN
          interfaces must be defined as a 'guest' interface with the
          testvar lanGuestMode.


Test Module Name Synopsis
Verify multicast traffic from guest LAN is not leaked into the LAN network guest.tcl guest_17 Verify multicast traffic from guest LAN is not leaked into the LAN network


    step 1. Send a multicast frame from the client on the Guest LAN.

    step 2. Verify that the multicast frame is not received by the client on
            the Main LAN.

    NOTE: This test requires the multiport add-on, because it requires at least
          two (2) defined LAN interfaces. The LAN interfaces may either be
          wired or wireless. The only other requirement is that one of the LAN
          interfaces must be defined as a 'guest' interface with the
          testvar lanGuestMode.


Test Module Name Synopsis
Verify router does not forward packets into guest network from LAN guest.tcl guest_20 Verify router does not forward packets into guest network from LAN


    step 1. Add static ARP entry of the LAN gateway's MAC to represent the
            client on Guest LAN into ARP table of client on the Main LAN.

    step 2. Add static ARP entry of the LAN gateway's MAC to represent the
            client on Main LAN into ARP table of client on the Guest LAN.

    step 3. Verify the client on Guest LAN can ping a remote host.

    step 4. Verify the client on Guest LAN can establish a TCP connection
            with a remote host.

    step 5. Verify that the client on the Guest LAN cannot ping the client
            on the Main LAN.

    step 6. Verify that the client on the Main LAN cannot ping the client
            on the Guest LAN.

    step 7. Verify that the client on the Guest LAN cannot establish a TCP
            session with the client on the Main LAN.

    step 8. Verify that the client on the Main LAN cannot establish a TCP
            session with the client on the Guest LAN.

    NOTE: This test requires the multiport add-on, because it requires at least
          two (2) defined LAN interfaces. The LAN interfaces may either be
          wired or wireless. The only other requirement is that one of the LAN
          interfaces must be defined as a 'guest' interface with the
          testvar lanGuestMode.


Test Module Name Synopsis
Verify guest network does not expose LAN management port guest.tcl guest_30 Verify guest network does not expose LAN management port


    step 1. Initiate a Nmap IPv4 scan for OS detection with version
            detection from the LAN using the first port in
            dutMgmtPort.

    step 2. Display the Nmap report.

    step 3. Repeat steps 1 and 2 for each port in dutMgmtPort.

    NOTE: The list of the DUT's management ports is taken from the
          testvar dutMgmtPort.  Please read the documentation for
          dutMgmtPort for more information its usage.


Test Module Name Synopsis
Verify ARP traffic is not leaked on the guest network guest.tcl guest_40 Verify ARP traffic is not leaked on the guest network


    step 1. Send a broadcast ARP request from client1 on Guest LAN looking for
            the MAC Address of client2 on the Guest LAN.

    step 2. Verify that the ARP request is not received by client2 on the Guest
            LAN.

    NOTE: This test requires the multiport add-on, because it requires at least
          two (2) defined LAN interfaces. The LAN interfaces may either be wired
          or wireless. The only other requirement is that a minimum of two
          interfaces must be defined as 'guest' interfaces with the testvar
          lanGuestMode.


Test Module Name Synopsis
Verify unicast traffic is not leaked on the guest network guest.tcl guest_42 Verify unicast traffic is not leaked on the guest network


    step 1. Add static ARP entry for client1 on the Guest LAN into ARP table of
            client2 on the Guest LAN.

    step 2. Add static ARP entry for client2 on the Guest LAN into ARP table of
            client1 on the Guest LAN.

    step 3. Send a unicast frame from client1 on the Guest LAN to the IP address
            of client2 on the Guest LAN.

    step 4. Verify that the unicast frame is not received by client2 on the
            Guest LAN.

    NOTE: This test requires the multiport add-on, because it requires at least
          two (2) defined LAN interfaces. The LAN interfaces may either be wired
          or wireless. The only other requirement is that a minimum of two
          interfaces must be defined as 'guest' interfaces with the testvar
          lanGuestMode.


Test Module Name Synopsis
Verify broadcast traffic is not leaked on the guest network guest.tcl guest_44 Verify broadcast traffic is not leaked on the guest network


    step 1. Send a broadcast frame from client1 on the Guest LAN.

    step 2. Verify that the broadcast frame is not received by client2 on the
            Guest LAN.

    NOTE: This test requires the multiport add-on, because it requires at least
          two (2) defined LAN interfaces. The LAN interfaces may either be wired
          or wireless. The only other requirement is that a minimum of two
          interfaces must be defined as 'guest' interfaces with the testvar
          lanGuestMode.


Test Module Name Synopsis
Verify multicast traffic is not leaked on the guest network guest.tcl guest_46 Verify multicast traffic is not leaked on the guest network


    step 1. Send a multicast frame from client1 on the Guest LAN.

    step 2. Verify that the multicast frame is not received by client2 on the
            Guest LAN.

    NOTE: This test requires the multiport add-on, because it requires at least
          two (2) defined LAN interfaces. The LAN interfaces may either be wired
          or wireless. The only other requirement is that a minimum of two
          interfaces must be defined as 'guest' interfaces with the testvar
          lanGuestMode.



lan-mp-v6.tcl

Layer 2 connectivity tests between multiple LAN interfaces using IPv6

Test Module Name Synopsis
Verify layer 2 multicast between all IPv6 LAN ports lan-mp-v6.tcl ipv6_lan_mp_2 Verify layer 2 multicast between all IPv6 LAN ports


    step 1. Initiate MLD Report for new IPv6 multicast group from first LAN interface
    step 2. Attempt to forward layer 2 multicast from second LAN interface to first
    step 3. Move on to the next LAN interface and repeat all combinations
    step 4. Verify IPv6 multicast succeeds for each LAN to LAN combination

    NOTE: Multicast IPv6 addresses are allocated using the IPv6 Multicast Address
    pool that is configured using testvar ipv6MulticastPoolStart and testvar
    ipv6MulticastPoolStop.

    For example:

    testvar ipv6MulticastPoolStart ff0e::1
    testvar ipv6MulticastPoolStop  ff0f::0


Test Module Name Synopsis
Verify layer 2 unicast between all IPv6 LAN ports lan-mp-v6.tcl ipv6_lan_mp_10 Verify layer 2 unicast between all IPv6 LAN ports


    step 1. Initiate ICMPv6 Echo Request from first LAN interface to next LAN
    step 2. Verify ICMPv6 Echo Reply is received
    step 3. Move on to the next LAN interface and repeat all combinations
    step 4. Verify unicast traffic succeeds for each LAN to LAN combination


Test Module Name Synopsis
Verify ICMPv6 routing between multiple IPv6 LAN ports lan-mp-v6.tcl ipv6_lan_mp_20 Verify ICMPv6 routing between multiple IPv6 LAN ports


    step 1. Initiate ICMPv6 Echo Request from first LAN interface to next LAN
    step 2. Send ICMPv6 Echo Request using the destination MAC address of router's LAN interface
    step 3. Verify ICMPv6 Echo Reply is received by second host
    step 4. Move on to the next LAN interface and repeat all combinations
    step 5. Verify unicast traffic succeeds for each LAN to LAN combination

    NOTE: Forwarding from a LAN client to another LAN client through the router's
    MAC address on the LAN may cause the router to issue an ICMPv6 Redirect.


Test Module Name Synopsis
Verify TCP routing between multiple IPv6 LAN ports lan-mp-v6.tcl ipv6_lan_mp_21 Verify TCP routing between multiple IPv6 LAN ports


    step 1. Initiate HTTP Get from first LAN interface to next LAN
    step 2. Send HTTP Get using the destination MAC address of router's LAN interface
    step 3. Verify HTTP response is received by second host
    step 4. Move on to the next LAN interface and repeat all combinations
    step 5. Verify unicast traffic succeeds for each LAN to LAN combination

    NOTE: Forwarding from a LAN client to another LAN client through the router's
    MAC address on the LAN may cause the router to issue an ICMPv6 Redirect.


Test Module Name Synopsis
Verify UDP routing between multiple IPv6 LAN ports lan-mp-v6.tcl ipv6_lan_mp_22 Verify UDP routing between multiple IPv6 LAN ports


    step 1. Initiate UDP Echo from first LAN interface to next LAN
    step 2. Send UDP Echo using the destination MAC address of router's LAN interface
    step 3. Verify UDP Echo response is received by second host
    step 4. Move on to the next LAN interface and repeat all combinations
    step 5. Verify unicast traffic succeeds for each LAN to LAN combination

    NOTE: Forwarding from a LAN client to another LAN client through the router's
    MAC address on the LAN may cause the router to issue an ICMPv6 Redirect.


Test Module Name Synopsis
Verify IPv6 Hop-Limit is decremented when routing to multiple IPv6 LAN ports lan-mp-v6.tcl ipv6_lan_mp_30 Verify IPv6 Hop-Limit is decremented when routing to multiple IPv6 LAN ports


    step 1. Initiate ICMPv6 Echo Request from first LAN interface to next LAN
    step 2. Send ICMPv6 Echo Request using the destination MAC address of router's LAN interface
    step 3. Verify ICMPv6 Echo Reply is received by second host
    step 4. Verify IPv6 Hop-Limit is decremented by 1
    step 5. Move to the second LAN interface and repeat
    step 6. Verify unicast traffic succeeds for each LAN to LAN combination

    NOTE: Forwarding from a LAN client to another LAN client through the router's
    MAC address on the LAN may cause the router to issue an ICMP Redirect.


Test Module Name Synopsis
Verify layer 2 unicast using unique local addresses between all IPv6 LAN ports lan-mp-v6.tcl ipv6_lan_mp_40 Verify layer 2 unicast using unique local addresses between all IPv6 LAN ports


    step 1. Initiate ICMPv6 Echo Request using unique local addresses from first
            LAN interface to next LAN
    step 2. Verify ICMPv6 Echo Reply is received
    step 3. Move on to the next LAN interface and repeat all combinations
    step 4. Verify unicast traffic succeeds for each LAN to LAN combination


Test Module Name Synopsis
Verify multi-client multicast support (LAN-LAN) lan-mp-v6.tcl ipv6_lan_mp_50 Verify multi-client multicast support (LAN-LAN)


    Test Procedure:

    Step 1. For all LAN clients, send an MLD join to the DUT to subscribe to
            multicast messages on group within the multicast pool.
    Step 2. For each client send a multicast message to the group.
    Step 3. Send a MLD leave to the DUT from one of the subscribed clients.
    Step 4. Repeat steps 2 and 3 until there are no more multicast clients.

    Test Metrics:

    1. At step 2, every client that is subscribed to the multicast group or
       shares an interface with a client that is subscribed to the multicast
       group receives a multicast message.
    2. At step 3, every client that has left the multicast group does not
       receive a multicast message if it doesn't share an interface with a
       client that is still a member of the multicast group.


Test Module Name Synopsis
Verify multi-client multicast support (WAN-LAN) lan-mp-v6.tcl ipv6_lan_mp_55 Verify multi-client multicast support (WAN-LAN)


    Test Procedure:

    Step 1. For all LAN clients, send an MLD join to the DUT to subscribe to
            multicast messages on group within the multicast pool.
    Step 2. For each client send a multicast message to the group.
    Step 3. Send a MLD leave to the DUT from one of the subscribed clients.
    Step 4. Repeat steps 2 and 3 until there are no more multicast clients.

    Test Metrics:

    1. At step 2, every client that is subscribed to the multicast group or
       shares an interface with a client that is subscribed to the multicast
       group receives a multicast message.
    2. At step 3, every client that has left the multicast group does not
       receive a multicast message if it doesn't share an interface with a
       client that is still a member of the multicast group.



rip-ng-wan.tcl

RIPng testing with multiple WAN interfaces

Test Module Name Synopsis
Verify router sends RIPng update on all WAN interfaces rip-ng-wan.tcl ipv6_ripngwan_1 Verify router sends RIPng update on all WAN interfaces


    step 1. Listen for RIPng reply on each WAN interface
    step 2. Verify RIPng version
    step 3. Verify source address of RIPng reply

    NOTE: This test is only run if the 'supportsRIPng' configuration
    is set to 'yes'.

    NOTE: This test is skipped if there is only one WAN interface.


    References:

    IETF RFC 2080 "RIPng for IPv6" Section 2.3: Timers

    https://tools.ietf.org/html/rfc2080#section-2.3

Test Module Name Synopsis
Verify router selects WAN RIPng route with lowest metric rip-ng-wan.tcl ipv6_ripngwan_2 Verify router selects WAN RIPng route with lowest metric


    step 1. Announce new RIPng route with metric 5 from all WAN
            interfaces except the last WAN interface
    step 2. Announce the same RIPng route with a metric of 2 from
            the last wan interface
    step 3. Forward UDP packet from LAN client to IP address within the
            new RIPng route range
    step 4. Verify the packet is forwarded to WAN interface with the
            lowest metric

    NOTE: This test is skipped if there is only one WAN interface.


    References:

    IETF RFC 2080 "RIPng for IPv6" Section 2.4.2: Response Messages

    https://tools.ietf.org/html/rfc2080#section-2.4.2

Test Module Name Synopsis
Verify router does not announce ULA prefixes on WAN interface rip-ng-wan.tcl ipv6_ripngwan_3 Verify router does not announce ULA prefixes on WAN interface


    step 1. Listen for RIPng updates for 1 minute
    step 2. Verify RIPng route for ULA prefixes is not announced as reachable

    NOTE: The testvar ipv6LanUlaPrefix must be configured to match the
    expected unique local prefix advertised by the DUT.

    NOTE: This test is skipped if there is only one WAN interface.


    References:

    IETF RFC 2080 "RIPng for IPv6" Section 2.5.2: Generating Response Messages

    https://tools.ietf.org/html/rfc2080#section-2.5.2

Test Module Name Synopsis
Verify WAN interface failover based on RIPng routes rip-ng-wan.tcl ipv6_ripngwan_5 Verify WAN interface failover based on RIPng routes


    step 1. Announce new RIPng route with metric 12 from the first WAN
            interface
    step 2. Verify traffic is forwarded from LAN to WAN correctly
    step 3. Announce the same RIPng route with a metric of 2 from
            the next WAN interface
    step 4. Verify traffic is forwarded from LAN to WAN correctly using
            the new WAN interface
    step 5. Repeat for each WAN interface using a new RIPng route

    NOTE: This test is skipped if there is only one WAN interface.


    References:

    IETF RFC 2080 "RIPng for IPv6" Section 2.4.2: Response Messages

    https://tools.ietf.org/html/rfc2080#section-2.4.2

Test Module Name Synopsis
Verify router sends triggered update to additional WAN interfaces rip-ng-wan.tcl ipv6_ripngwan_8 Verify router sends triggered update to additional WAN interfaces


    step 1. Wait for RIPng update on first WAN interface
    step 2. Announce new RIPng route with metric 1 from first WAN interface
    step 3. Verify triggered RIPng update is sent to additional WAN interfaces
    step 4. Verify metric for triggered update route is the original metric + 1
    step 5. Verify the packet is forwarded from LAN to correct WAN interface

    NOTE: This test is skipped if there is only one WAN interface.


    References:

    IETF RFC 2080 "RIPng for IPv6" Section 2.5.1: Triggered Updates

    https://tools.ietf.org/html/rfc2080#section-2.5.1

Test Module Name Synopsis
Verify packets originating from WAN are forwarded to correct WAN interface rip-ng-wan.tcl ipv6_ripngwan_9 Verify packets originating from WAN are forwarded to correct WAN interface


    step 1. Announce new RIPng route with metric 1 from second WAN interface
    step 2. Originate UDP packet from first WAN interface with destination
            inside new RIPng route
    step 3. Verify the packet is forwarded from first WAN interface to
            second WAN interface

    NOTE: This test is skipped if there is only one WAN interface.


    References:

    IETF RFC 2080 "RIPng for IPv6" Section 2.4.2: Response Messages

    https://tools.ietf.org/html/rfc2080#section-2.4.2

Test Module Name Synopsis
Verify router responds to RIPng requests on WAN interface rip-ng-wan.tcl ipv6_ripngwan_14 Verify router responds to RIPng requests on WAN interface


    step 1. Send RIPng Request from new UDP source port to RIPng destination address
    step 2. Verify router returns a RIPng response
    step 3. Verify the response is sent to the correct UDP port
    step 4. Verify the response is sent using unicast IP destination
    step 5. Repeat for each WAN interface

    NOTE: This test is skipped if there is only one WAN interface.


    References:

    IETF RFC 2080 "RIPng for IPv6" Section 2.4.2: Response Messages

    https://tools.ietf.org/html/rfc2080#section-2.4.2

Test Module Name Synopsis
Verify RIPng route timeout and garbage collection timers rip-ng-wan.tcl ipv6_ripngwan_20 Verify RIPng route timeout and garbage collection timers


    step 1. Announce new RIPng route with metric 1 from first
            WAN interface
    step 2. Wait for RIPng route timer to expire
    step 3. Verify RIPng route is announced on other WAN interfaces with
            a metric of 16
    step 4. Wait for the RIPng garbage collection timer to expire
    step 5. Verify the RIPng route is no longer announced on other WAN
            interfaces

    NOTE: This test is skipped if there is only one WAN interface.


    References:

    IETF RFC 2080 "RIPng for IPv6" Section 2.3: Timers

    https://tools.ietf.org/html/rfc2080#section-2.3

Test Module Name Synopsis
Verify router announces WAN route as unreachable when WAN connection is down rip-ng-wan.tcl ipv6_ripngwan_50 Verify router announces WAN route as unreachable when WAN connection is down


    step 1. Announce new RIPng route with metric 1 from first WAN interface
    step 2. Bring down WAN link
    step 3. Wait up to 15 seconds for triggered update on second WAN interface
    step 4. Verify the route is announced with metric 16 on second WAN interface
    step 5. Bring up WAN link

    NOTE: This test is skipped if there is only one WAN interface.


    References:

    IETF RFC 2080 "RIPng for IPv6" Section 2.5.1: Tiggered Updates

    https://tools.ietf.org/html/rfc2080#section-2.5.1

Test Module Name Synopsis
Verify router sends RIPng request when WAN link is reestablished rip-ng-wan.tcl ipv6_ripngwan_52 Verify router sends RIPng request when WAN link is reestablished


    step 1. Bring down WAN link
    step 2. Wait up to 90 seconds for router to send RIPng request to learn
            initial routing table
    step 3. Bring up WAN link

    NOTE: This test is skipped if there is only one WAN interface.


    References:

    IETF RFC 2080 "RIPng for IPv6" Section 2.4.1: Request Messages

    https://tools.ietf.org/html/rfc2080#section-2.4.1

Test Module Name Synopsis
Verify the maximum number of RIPng routes supported on WAN rip-ng-wan.tcl ipv6_ripngwan_100 Verify the maximum number of RIPng routes supported on WAN


    step 1. Announce new RIPng routes with metric 1 from each WAN interface

            NOTE: The 'ripMaxRoutes' testvar in your configuration file
            determines the number of RIPng routes that are announced. This
            number is divided by the number of WAN interfaces to determine
            how many RIPng routes to announce on each WAN interface.

    step 2. Forward from original LAN client to IP address within the
            each new route range
    step 3. Verify packets are forwarded to correct WAN interface
    step 4. Repeat for each RIPng route that was announced

    NOTE: This test is skipped if there is only one WAN interface.


    References:

    IETF RFC 2080 "RIPng for IPv6" Section 2.1: Message Format

    https://tools.ietf.org/html/rfc2080#section-2.1


forward-v6-mp.tcl

IPv6 forwarding tests with multiple WAN connections

Test Module Name Synopsis
IPv6 Multiple WAN port forwarding test (LAN to WAN) forward-v6-mp.tcl ipv6_forward_mp_10 IPv6 Multiple WAN port forwarding test (LAN to WAN)

    step 1. Send an outbound UDP packet with UDP data length 0 from LAN host
            to ISP IPv6 on first WAN port
    step 2. Verify the packet is received on the correct WAN interface
    step 3. Send UDP packet from LAN to next WAN interface
    step 4. Repeat for all WAN interfaces
    step 5. Repeat for all packet sizes until the maximum packet size is
            reached

    NOTE: The maximum packet size can be configured using the testvar 'lanMtu'.
    When the lanMtu value is set to 'default', CDRouter will automatically
    determine the maximum size packet based on the WAN connection type of
    the first interface.

    NOTE: This test will stop if the number of max failures is reached. This
    value may be configured using testvar forwardingMaxFailures. Setting this
    value to 0 will test each packet size regardless of the result.

    testvar forwardingMaxFailures 20

Test Module Name Synopsis
IPv6 Multiple WAN port forwarding test (WAN to LAN) forward-v6-mp.tcl ipv6_forward_mp_11 IPv6 Multiple WAN port forwarding test (WAN to LAN)

    step 1. Initiate an outbound UDP connection to each WAN IPv6 address to
            establish an initial firewall mapping
    step 2. Send an inbound UDP packet with UDP data length 0 from WAN host
            on first WAN port to LAN client's global IPv6 address
    step 3. Verify the packet is received on the correct LAN interface
    step 4. Send UDP packet from next WAN interface to LAN
    step 5. Repeat for all WAN interfaces
    step 6. Repeat for all packet sizes until the maximum packet size is
            reached

    NOTE: The maximum packet size can be configured using the testvar lanMtu.
    When the lanMtu value is set to 'default', CDRouter will automatically
    determine the maximum size packet based on the WAN connection type of the
    first interface.

    NOTE: This test will stop if the number of max failures is reached. This
    value may be configured using testvar forwardingMaxFailures. Setting this
    value to 0 will test each packet size regardless of the result.

    testvar forwardingMaxFailures 20


jumbo-v6-mp.tcl

Jumbo MTU IPv6 forwarding tests with multiple WAN connections

Test Module Name Synopsis
IPv6 Multiple WAN port jumbo MTU forwarding test (LAN to WAN) jumbo-v6-mp.tcl ipv6_jumbo_mp_10 IPv6 Multiple WAN port jumbo MTU forwarding test (LAN to WAN)

    step 1. Send an outbound UDP packet that utilizes the maximum supported
            standard mtu of both interfaces from LAN host to ISP IPv6 on first
            WAN port
    step 2. Verify the packet is received on the correct WAN interface
    step 3. Repeat incrementing packet size by 4 until the maximum supported
            jumbo mtu of both interfaces is reached
    step 4. Repeat for all WAN interfaces

    NOTE: The maximum jumbo packet size is configured using the testvar
    jumboMtu.

    NOTE: This test will stop if the number of max failures is reached. This
    value may be configured using testvar forwardingMaxFailures. Setting this
    value to 0 will test each packet size regardless of the result.

    testvar forwardingMaxFailures 20

Test Module Name Synopsis
IPv6 Multiple WAN port jumbo MTU forwarding test (WAN to LAN) jumbo-v6-mp.tcl ipv6_jumbo_mp_11 IPv6 Multiple WAN port jumbo MTU forwarding test (WAN to LAN)

    step 1. Initiate an outbound UDP connection to first WAN IPv6 address to
            establish an initial firewall mapping that utilizes the maximum
            supported standard mtu of both interfaces
    step 2. Send an inbound UDP packet that utilizes the maximum supported
            standard mtu of both interfaces from WAN host on first WAN port to
            LAN client's global IPv6 address
    step 3. Verify the packet is received on the correct LAN interface
    step 4. Repeat incrementing packet size by 4 until the maximum supported
            jumbo mtu of both interfaces is reached
    step 5. Repeat for all WAN interfaces

    NOTE: The maximum jumbo packet size is configured using the testvar
    jumboMtu.

    NOTE: This test will stop if the number of max failures is reached. This
    value may be configured using testvar forwardingMaxFailures. Setting this
    value to 0 will test each packet size regardless of the result.

    testvar forwardingMaxFailures 20


guest-v6.tcl

IPv6 guest mode related test cases

Test Module Name Synopsis
Verify IPv6 basic behavior of guest mode isolation guest-v6.tcl ipv6_guest_1 Verify IPv6 basic behavior of guest mode isolation


    step 1. Verify the IPv6 client on Guest LAN can ping an IPv6 remote host.

    step 2. Verify the IPv6 client on Guest LAN can establish a TCP connection
            with an IPv6 remote host.

    step 3. Verify that the IPv6 client on the Guest LAN cannot ping the IPv6
            client on the Main LAN.

            a) Verify that a multicast Neighbor Solictation from the client on
               the Guest LAN is not received by the client on the Main LAN.
            b) If the broadcast ARP is received by the client on the Main
               LAN, then verify that a ICMPv6 Echo sent by the client on
               the Guest LAN is not received by the client on the Main LAN.

    step 4. Verify that the IPv6 client on the Main LAN cannot ping the IPv6
            client on the Guest LAN.

            a) Verify that a multicast Neighbor Solictation from the client on
               the Main LAN is not received by the client on the Guest LAN.
            b) If the broadcast ARP is received by the client on the Guest
               LAN, then verify that a ICMPv6 Echo sent by the client on
               the Main LAN is not received by the client on the Guest LAN.

    step 5. Verify that the IPv6 client on the Guest LAN cannot establish a TCP
            session with the IPv6 client on the Main LAN.

            a) Verify that a multicast Neighbor Solictation from the client on
               the Guest LAN is not received by the client on the Main LAN.
            b) If the broadcast ARP is received by the client on the Main
               LAN, then verify that the client on the Guest LAN cannot
               establish a TCP session with the client on the Main LAN.

    step 6. Verify that the IPv6 client on the Main LAN cannot establish a TCP
            session with the IPv6 client on the Guest LAN.

            a) Verify that a multicast Neighbor Solicitation from the client on
               the Main LAN is not received by the client on the Guest LAN.
            b) If the broadcast ARP is received by the client on the Guest
               LAN, then verify that the client on the Main LAN cannot
               establish a TCP session with the client on the Guest LAN.

    NOTE: This test requires the multiport add-on, because it requires at least
          two (2) defined LAN interfaces. The LAN interfaces may either be
          wired or wireless. The only other requirement is that one of the LAN
          interfaces must be defined as a 'guest' interface with the
          testvar lanGuestMode. Obviously, it also requires the IPv6 add-on.


Test Module Name Synopsis
Verify IPv6 neighbor discovery traffic from LAN is not leaked into the guest network guest-v6.tcl ipv6_guest_10 Verify IPv6 neighbor discovery traffic from LAN is not leaked into the guest network


    step 1. Send a multicast Neighbor Solicitation from the IPv6 client on the
            Main LAN.

    step 2. Verify that the Neighbor Solicitation request is not received by
            the IPv6 client on the Guest LAN.

    NOTE: This test requires the multiport add-on, because it requires at least
          two (2) defined LAN interfaces. The LAN interfaces may either be
          wired or wireless. The only other requirement is that one of the LAN
          interfaces must be defined as a 'guest' interface with the
          testvar lanGuestMode. Obviously, it also requires the IPv6 add-on.


Test Module Name Synopsis
Verify IPv6 neighbor discovery traffic from guest LAN is not leaked into the LAN network guest-v6.tcl ipv6_guest_11 Verify IPv6 neighbor discovery traffic from guest LAN is not leaked into the LAN network


    step 1. Send a multicast Neighbor Solicitation from the IPv6 client on the
            Guest LAN.

    step 2. Verify that the Neighbor Solicitation request is not received by
            the IPv6 client on the Main LAN.

    NOTE: This test requires the multiport add-on, because it requires at least
          two (2) defined LAN interfaces. The LAN interfaces may either be
          wired or wireless. The only other requirement is that one of the LAN
          interfaces must be defined as a 'guest' interface with the
          testvar lanGuestMode. Obviously, it also requires the IPv6 add-on.


Test Module Name Synopsis
Verify IPv6 unicast traffic from LAN is not leaked into the guest network guest-v6.tcl ipv6_guest_12 Verify IPv6 unicast traffic from LAN is not leaked into the guest network


    step 1. Add static MAC and neighbor cache entry for the IPv6 client on
            Guest LAN into neighbor cache of IPv6 client on the Main LAN.

    step 2. Add static MAC and neighbor cache entry for the IPv6 client on
            Main LAN into neighbor cache of IPv6 client on the Guest LAN.

    step 3. Send a V6 unicast frame from the client on the Main LAN to the IPv6
            address of the client on the Guest LAN.

    step 4. Verify that the V6 unicast frame is not received by the client on
            the Guest LAN.

    NOTE: This test requires the multiport add-on, because it requires at least
          two (2) defined LAN interfaces. The LAN interfaces may either be
          wired or wireless. The only other requirement is that one of the LAN
          interfaces must be defined as a 'guest' interface with the
          testvar lanGuestMode. Obviously, it also requires the IPv6 add-on.


Test Module Name Synopsis
Verify IPv6 unicast traffic from guest LAN is not leaked into the LAN network guest-v6.tcl ipv6_guest_13 Verify IPv6 unicast traffic from guest LAN is not leaked into the LAN network


    step 1. Add static MAC and neighbor cache entry for the IPv6 client on
            Guest LAN into neighbor cache of the IPv6 client on the Main LAN.

    step 2. Add static MAC and neighbor cache entry for the IPV6 client on
            Main LAN into neighbor cache of the IPv6 client on the Guest LAN.

    step 3. Send a V6 unicast frame from the client on the Guest LAN to the IPv6
            address of the client on the Main LAN.

    step 4. Verify that the V6 unicast frame is not received by the client on
            the Main LAN.

    NOTE: This test requires the multiport add-on, because it requires at least
          two (2) defined LAN interfaces. The LAN interfaces may either be
          wired or wireless. The only other requirement is that one of the LAN
          interfaces must be defined as a 'guest' interface with the
          testvar lanGuestMode. Obviously, it also requires the IPv6 add-on.


Test Module Name Synopsis
Verify IPv6 multicast traffic from LAN is not leaked into the guest network guest-v6.tcl ipv6_guest_16 Verify IPv6 multicast traffic from LAN is not leaked into the guest network


    step 1. Send a V6 multicast frame from the client on the Main LAN.

    step 2. Verify that the V6 multicast frame is not received by the client on
            the Guest LAN.

    NOTE: This test requires the multiport add-on, because it requires at least
          two (2) defined LAN interfaces. The LAN interfaces may either be
          wired or wireless. The only other requirement is that one of the LAN
          interfaces must be defined as a 'guest' interface with the
          testvar lanGuestMode. Obviously, it also requires the IPv6 add-on.


Test Module Name Synopsis
Verify IPv6 multicast traffic from guest LAN is not leaked into the LAN network guest-v6.tcl ipv6_guest_17 Verify IPv6 multicast traffic from guest LAN is not leaked into the LAN network


    step 1. Send a V6 multicast frame from the client on the Guest LAN.

    step 2. Verify that the V6 multicast frame is not received by the client on
            the Main LAN.

    NOTE: This test requires the multiport add-on, because it requires at least
          two (2) defined LAN interfaces. The LAN interfaces may either be
          wired or wireless. The only other requirement is that one of the LAN
          interfaces must be defined as a 'guest' interface with the
          testvar lanGuestMode. Obviously, it also requires the IPv6 add-on.


Test Module Name Synopsis
Verify IPv6 router does not forward packets into guest network from LAN guest-v6.tcl ipv6_guest_20 Verify IPv6 router does not forward packets into guest network from LAN


    step 1. Add static MAC and neighbor cache entry for client on Guest LAN
            into neighbor cache of client on the Main LAN.

    step 2. Add static MAC and neighbor cache entry for client on Main LAN
            into neighbor cache of client on the Guest LAN.

    step 3. Verify the client on Guest LAN can ping a IPv6 remote host.

    step 4. Verify the client on Guest LAN can establish a TCP connection
            with a IPv6 remote host.

    step 5. Verify that the V6 client on the Guest LAN cannot ping the V6 client
            on the Main LAN.

    step 6. Verify that the V6 client on the Main LAN cannot ping the V6 client
            on the Guest LAN.

    step 7. Verify that the V6 client on the Guest LAN cannot establish a TCP
            session with the V6 client on the Main LAN.

    step 8. Verify that the V6 client on the Main LAN cannot establish a TCP
            session with the V6 client on the Guest LAN.

    NOTE: This test requires the multiport add-on, because it requires at least
          two (2) defined LAN interfaces. The LAN interfaces may either be
          wired or wireless. The only other requirement is that one of the LAN
          interfaces must be defined as a 'guest' interface with the
          testvar lanGuestMode. Obviously, it also requires the IPv6 add-on.


Test Module Name Synopsis
Verify IPv6 guest network does not expose LAN management port guest-v6.tcl ipv6_guest_30 Verify IPv6 guest network does not expose LAN management port


    step 1. Initiate a Nmap IPv6 scan for OS detection with version
            detection from the LAN using the first port in
            dutMgmtPort.

    step 2. Display the Nmap report.

    step 3. Repeat steps 1 and 2 for each port in dutMgmtPort.

    NOTE: The list of the DUT's management ports is taken from the
          testvar dutMgmtPort.  Please read the documentation for
          dutMgmtPort for more information its usage.


Test Module Name Synopsis
Verify IPv6 neighbor discovery traffic is not leaked on the guest network guest-v6.tcl ipv6_guest_40 Verify IPv6 neighbor discovery traffic is not leaked on the guest network


    step 1. Send a multicast Neighbor Solicitation from IPv6 client1 on the
            Guest LAN.

    step 2. Verify that the Neighbor Solicitation request is not received by
            IPv6 client2 on the Guest LAN.

    NOTE: This test requires the multiport add-on, because it requires at least
          two (2) defined LAN interfaces. The LAN interfaces may either be wired
          or wireless. The only other requirement is that a minimum of two
          interfaces must be defined as 'guest' interfaces with the testvar
          lanGuestMode.


Test Module Name Synopsis
Verify IPv6 unicast traffic is not leaked on the guest network guest-v6.tcl ipv6_guest_42 Verify IPv6 unicast traffic is not leaked on the guest network


    step 1. Add static MAC and neighbor cache entry for IPv6 client1 on Guest
            LAN into neighbor cache of IPv6 client2 on the Guest LAN.

    step 2. Add static MAC and neighbor cache entry for IPv6 client2 on Guest
            LAN into neighbor cache of IPv6 client1 on the Guest LAN.

    step 3. Send a V6 unicast frame from client1 on the Guest LAN to the IPv6
            address of client2 on the Guest LAN.

    step 4. Verify that the V6 unicast frame is not received by client2 on the
            Guest LAN.

    NOTE: This test requires the multiport add-on, because it requires at least
          two (2) defined LAN interfaces. The LAN interfaces may either be wired
          or wireless. The only other requirement is that a minimum of two
          interfaces must be defined as 'guest' interfaces with the testvar
          lanGuestMode.


Test Module Name Synopsis
Verify IPv6 multicast traffic is not leaked on the guest network guest-v6.tcl ipv6_guest_46 Verify IPv6 multicast traffic is not leaked on the guest network


    step 1. Send a V6 multicast frame from client1 on the Guest LAN.

    step 2. Verify that the V6 multicast frame is not received by client2 on the
            Guest LAN.

    NOTE: This test requires the multiport add-on, because it requires at least
          two (2) defined LAN interfaces. The LAN interfaces may either be wired
          or wireless. The only other requirement is that a minimum of two
          interfaces must be defined as 'guest' interfaces with the testvar
          lanGuestMode.


Contents

×

About CDRouter

QA Cafe CDRouter is a comprehensive and powerful test automation solution focused on feature, security, and performance testing for broadband and enterprise edge gateways, Wi-Fi and mesh systems, and other CPE.

Get in touch via our Contact page or by following us on your favorite service: