.. _example_service_dhcp-client_multiple-interfaces:

###################
Multiple-Interfaces
###################

Test suite to validate DHCP client operation on multiple VLAN interfaces simultaneously.

This suite tests a common production scenario where a router has multiple
VLAN interfaces (VIFs) on the same physical interface, each configured to
obtain an IP address via DHCP from independent DHCP servers (or different
subnets on the same server).

Note: Due to the test environment topology where all physical interfaces
share the same switch/broadcast domain, we use VLANs (802.1Q) to create
separate L2 domains for proper DHCP isolation.

Key scenarios verified:
- Both VLAN interfaces successfully obtain IPs from different subnets
- Each VLAN interface maintains its own independent DHCP lease
- Both interfaces receive their respective default routes
- Routing table correctly handles multiple default gateways (with metrics)
- DHCP renewals and releases work independently per VLAN interface

This is critical for:
- Multi-WAN scenarios with VLAN trunking
- Network segmentation with DHCP per VLAN
- Management VLAN + data VLAN configurations

****************************************
Test Simultaneous DHCP on Two Interfaces
****************************************

Description
===========

This scenario verifies that a DHCP client can successfully obtain
IP addresses on two VLAN interfaces (VIFs) simultaneously from
independent DHCP servers (or different subnets). Each VLAN interface should:
- Obtain an IP in the correct subnet range
- Receive its respective default router
- Maintain independent lease files
- Appear in the DHCP client lease list

This is a fundamental multi-VLAN scenario used in production for
dual-WAN setups with VLAN trunking, management VLANs, or network segmentation.

Configuration:
- Server VLAN 100: 192.168.10.1/24, DHCP pool 192.168.10.50-60
- Server VLAN 101: 192.168.20.1/24, DHCP pool 192.168.20.50-60
- Client VLAN 100: DHCP (should get 192.168.10.x)
- Client VLAN 101: DHCP (should get 192.168.20.x)

Scenario
========

.. include:: multiple-interfaces/testsimultaneousdhcpontwointerfaces

.. raw:: html

  <hr>

*********************************
Test Independent Lease Management
*********************************

Description
===========

This scenario verifies that DHCP leases on multiple interfaces are
managed independently. When one interface releases its DHCP lease,
the other interface should remain unaffected and maintain its active
lease and IP address.

This ensures that the DHCP client implementation correctly handles
per-interface lease state and doesn't interfere with other interfaces
during operations like release, renew, or configuration changes.

Test flow:
1. Both interfaces obtain DHCP leases
2. Release lease on first interface only
3. Verify first interface loses IP
4. Verify second interface maintains its IP (unaffected)
5. Re-enable DHCP on first interface
6. Verify both interfaces have active leases again

Scenario
========

.. include:: multiple-interfaces/testindependentleasemanagement

.. raw:: html

  <hr>

*****************************************
Test Multiple Default Routes with Metrics
*****************************************

Description
===========

This scenario verifies that when multiple VLAN interfaces on the same
physical interface receive default routes via DHCP, the routing table
correctly handles both routes. The kernel may use ECMP (Equal-Cost
Multi-Path) to create a single default route with multiple nexthops,
or install separate routes with different metrics.

When both VLANs are on the same physical interface, Linux typically
creates an ECMP route with multiple nexthops instead of separate routes.
This allows load balancing across both gateways.

Expected behavior (ECMP scenario):
- Single default route with multiple nexthops
- Both gateways (192.168.10.1 and 192.168.20.1) appear as nexthops
- Both VLAN interfaces appear in the routing table
- Traffic can use either gateway for load balancing

This test verifies the routing table structure includes both gateways,
regardless of whether they appear as separate routes or ECMP nexthops.

Scenario
========

.. include:: multiple-interfaces/testmultipledefaultrouteswithmetrics

.. raw:: html

  <hr>