Product
Search Results

Testvar Network Constraints

Testvar Network Constraints

The network property and the valid_address constraint command is a generic and flexible way to describe a testvar’s place in the network topology and have all network validation done in a single place.

The network property

This property is assigned to IPv4/IPv6 testvars in config.dic which are used by CDRouter stacks or the DUT’s LAN/WAN interfaces.

buddy::testvar_define TESTVAR {
    network { SIDE [ ADDRESS/MASK ] }
}
  • SIDE indicates which side of the device the testvar is on, must be lan or wan

  • ADDRESS/MASK given as two testvar names i.e. lanIp/lanMask

  • ADDRESS/MASK testvar values can take the form 1.1.1.1/24, 1.1.1.1/255.255.255.0, or 3001::1/64

  • If ADDRESS/MASK not specified, ADDRESS is testvar’s name, MASK is 32/128 (for IPv4/IPv6)

  • ADDRESS/MASK declares that the testvar must be a member of the given network

NOTE: Assigning a testvar a network property simply adds the information to the config dictionary, verification only occurs when valid_address is called from within the testvar’s constraints property.

The example below declares that testvar hostIp is a LAN-side address which should be within the lanIp/lanMask network. Because there are no conditionals around the valid_address call, hostIp will always be verified if defined.

buddy::testvar_define hostIp {
    network { lan lanIp/lanMask }
    constraints {
        valid_address [ this ]
    }
}

The next example declares that testvar ipv6DsliteAftr is a WAN-side address which should be in its own (/128) network disjoint from any other WAN-side network. Because its valid_address call is wrapped in conditionals, it will only be verified if the IPv6 expansion is enabled.

buddy::testvar_define ipv6DsliteAftr {
    network { wan }
    constraints {
        if { [ cdrouter_addon ipv6 ] } {
            valid_address [ this ]
        }
    }
}

The ip-range property

Some testvars have an ip-range property in config.dic which indicates that two testvars taken together describe a range of addresses.

buddy::testvar_define TESTVAR {
    ip-range { START END }
}

For example dhcpClientStart/dhcpClientEnd have an ip-range property:

buddy::testvar_define dhcpClientStart {
    ip-range { dhcpClientStart dhcpClientEnd }
}

The ip-range property is only significant during data type validation for testvars with a type property of IPv4 or IPv6. In such cases, the validation proc ensures that END is greater than or equal to START.

The valid_address constraint command

  • Verifies testvar’s value using a network specification

  • If called without PROPERTY-NAME, property name is assumed to be network

valid_address TESTVAR [ PROPERTY-NAME ]

Some testvars have different network requirements based on other testvars. In this case, valid_address can be passed a different property name in order to verify different network types. Current network types used in config.dic:

Network Type Description
network Default
switched-network forwardingMode is bridge
relay-network wanIspGateway is defined
l2tp-network wanMode is L2TP
pptp-network wanMode is PPTP

The example below shows how to pass different property names to valid_address

buddy::testvar_define dhcpClientStart {
    network { lan lanIp/lanMask }
    switched-network { wan main:wanIspIp/main:wanIspMask }
    constraints {
        if { [ tv forwardingMode ] != "bridge" } {
            valid_address [ this ] network
        } else {
            valid_address [ this ] switched-network
        }
    }
}

The valid_addresses constraint command

Some testvars are allowed to be in more than one network. The valid_addresses command takes any number of network specifications and validates that a testvar’s value is validate for one of them.

valid_addresses TESTVAR [ PROPERTY-NAME . / dynamic DYNAMIC-SPEC ]...

For example, the following testvar definition would validate that ipsecTunnelEndpoint is in one of two possible networks:

buddy::testvar_define ipsecTunnelEndpoint* {
    network { wan }
    constraints {
        foreach w [ wildcards [ this ] ] {
            valid_addresses [ this name $w ] network . dynamic "wan ipsecTunnelRemoteNetwork$w/ipsecTunnelRemoteMask$w"
            must_exist ipsecTunnelRemoteNetwork$w ipsecTunnelRemoteMask$w ipsecTunnelHost$w 
        }
    }
}

The network . part of the valid_addresses call specifies that the testvar’s value can be on the WAN in its own /32 network (taken from the network property). The dynamic wan ipsecTunnelRemoteNetwork$w/ipsecTunnelRemoteMask$w part of the call specifies that the testvar can be on the WAN in the ipsecTunnelRemoteNetwork/ipsecTunnelRemoteMask network (taken from the second dynamic network specification argument). Calls to valid_addresses can have an arbitrary number of network property/dynamic spec arguments.

Verification steps in valid_address

  1. The testvar must not be a member of any network on the same side and same interface besides the one it declared in its network property.

  2. If the testvar is on the WAN-side, the testvar must not be a member of any WAN networks on other WAN interfaces.

  3. If the testvar is on the WAN-side, the testvar’s network must not overlap with any LAN-side networks and vice versa.

  4. Testvar must be within the network specified in its network property.

  5. Testvar must be unique within the network specified in its network property.

If valid_address is called on a testvar with an ip-range property, step 5 is modified such that all values between START and END are checked for uniqueness.

Examples

wanIspAssignIp has same value as wanIspIp

$ cdrouter-cli -check-config -config duplicate_wan_address.conf

Config file:

testvar wanIspAssignIp        192.168.200.1

testvar wanIspIp              192.168.200.1
testvar wanIspMask            255.255.255.0

Error:

CONFIG-ERROR: Error during configuration file constraint validation
CONFIG-ERROR: line(s) 116 3341, Invalid value '192.168.200.1' for testvar(s) wanIspAssignIp on main interface, overlaps with wanIspIp (192.168.200.1)

lanIp/lanMask is in same network as wanIspIp/wanIspMask

$ cdrouter-cli -check-config -config wan_lan_overlap.conf

Config file:

testvar lanIp                 192.168.200.8
testvar lanMask               255.255.255.0

testvar wanIspIp              192.168.200.1
testvar wanIspMask            255.255.255.0

Error:

CONFIG-ERROR: Error during configuration file constraint validation
CONFIG-ERROR: line(s) 112 3340, Invalid value '192.168.200.1' for testvar wanIspIp in network wanIspIp/wanIspMask (192.168.200.1/24) on main interface, network already exists on LAN on main interface (see lanIp/lanMask (192.168.200.8/24))

remoteHostIp is in wanIspIp/wanIspMask network

$ cdrouter-cli -check-config -config wan_network_overlap.conf

Config file:

testvar remoteHostIp          192.168.200.8

testvar wanIspIp              192.168.200.1
testvar wanIspMask            255.255.255.0

Error:

CONFIG-ERROR: Error during configuration file constraint validation
CONFIG-ERROR: line(s) 3122, Invalid value '192.168.200.8' for testvar remoteHostIp in network remoteHostIp (192.168.200.8) on main interface, overlaps with network wanIspIp/wanIspMask (192.168.200.1/24)

wanIspAssignIp is not in wanIspIp/wanIspMask network

$ cdrouter-cli -check-config -config wrong_wan_network.conf

Config file:

testvar wanIspAssignIp        192.168.100.2

testvar wanIspIp              192.168.200.1
testvar wanIspMask            255.255.255.0

Error:

CONFIG-ERROR: Error during configuration file constraint validation
CONFIG-ERROR: line(s) 116 3341, Invalid value '192.168.100.2' for testvar wanIspAssignIp in network wanIspIp/wanIspMask (192.168.200.1/24) on main interface, must be in network wanIspIp/wanIspMask (192.168.200.1/24).

dhcpClientStart/End 192.168.1.2-7 overlap with lanIp 192.168.1.3

$ cdrouter-cli -check-config -config range_overlap.conf

Config file:

testvar lanIp                 192.168.1.3

testvar dhcpClientStart       192.168.1.2
testvar dhcpClientEnd         192.168.1.7

Error:

CONFIG-ERROR: Error during configuration file constraint validation
CONFIG-ERROR: line(s) 582, Invalid value '192.168.1.2-192.168.1.7' for testvar(s) dhcpClientStart-dhcpClientEnd on main interface, overlaps with lanIp (192.168.1.3)