DHCP client in container test

[jcralbino]

I would like to know if this was tested already.

The use case is having PODMAN running a container using macvlan driver for the network. In this case the container would sent a DHCP messages out to get a DHCP assigned IPv4 address

I had a look in the code and i did not see this scenario included there, is this correct?

[olichtne]

Hi,

you're correct, we don't currently have a simple dhcp test, most of our test set is focused on manual ip configuration and measurement of performance. But it shouldn't be a problem to implement a dhcp test in lnst.

wrt. containers, i'm not sure what you mean, lnst has a concept of defining "hardware test requirements" that specify what kind of network is required to run the test, in this case I imagine you'd want two hosts - one with a dhcp server and one with a dhcp client.

Following from there you can define a test machine pool that points at containers that run lnst agents to run this test. LNST itself will however view these as just normal machines... same as if they were baremetal machines or virtual machines.

Additionally, we do have a limited support for "automatically creating" the requested network with podman containers, which currently doesn't support creation of multiple nics for the same network for the containers, but i think this shouldn't be a problem for a basic dhcp test.

So we could write a dhcp test that is universal and you could opt in to run it with podman containers... hopefully nothing got broken with that feature since i've last used it.

[jcralbino]

Hi additional details about our use case is that We aim to use two separate host devices , where the test will be executed. As this re physical machines working as lnst agents, and are physically connected to different switch environments I am creating several logical nics using 802.1q tags. Inside Linux os we try to have one ip interface used for management

The podman will then use this separate nics to create distinct container networks namespaces using the macvlan driver. Inside those several network namespaces provided Macvlan driver, that use different logical interfaces(802.1q tagged) in the os host we will run the containers where the actual tests should run.

I would like to test inside the containers using the dhcp client functionality, validating the service across different dhcp client source networks

What do you mean by

" Additionally, we do have a limited support for "automatically creating" the requested network with podman containers, which currently doesn't support creation of multiple nics for the same network for the containers, but i think this shouldn't be a problem for a basic dhcp test. "

Is lnst capable of creating postman network namespaces using different 802.1q tagged interfaces ?

Is lnst capable of creating different 802.1q tagged interfaces ?

Can we have only containers using one network namespace?

Is this a supported scenario ?

[jtluka]

Hi additional details about our use case is that We aim to use two separate host devices , where the test will be executed. As this re physical machines working as lnst agents, and are physically connected to different switch environments I am creating several logical nics using 802.1q tags.

I think there's some misunderstanding. If you need to create the containers on two different physical hosts then this is not possible with LNST by means of ContainerPoolManager.

The container support is meant as dynamic creation of lnst-agents (so, you don't have to define a LNST agent pool) and network between them, not that the lnst-agents can create containers on their own.

Additionally, we do have a limited support for "automatically creating" the requested network with podman containers, which currently doesn't support creation of multiple nics for the same network for the containers, but i think this shouldn't be a problem for a basic dhcp test.

This is a podman API limitation. It is not possible to have lnst-agent created dynamically as a container with multiple interfaces us as test interfaces. More details are in https://github.com/containers/podman/issues/15062

Since I'd like to clarify your use case first, I did not answer the followup questions.

[jcralbino]

Currently we are using the following environment for our testing ( not using lnst but manual configured interfaces and containers)

• one physical host ( DCA-PERF01) running rhce 8 and podman
• that host ( DCA-PERF01) has one physical interfaces dedicated for testing. In this physical interface we create vlan interfaces using 802.1q tagging
• in those vlan interface i create then corresponding network namespaces Using podman
• we then deploy several containers in the different network namespaces
• we don't want to have ip configured in the physical host os( to mitigate security risks) . Therefore IPs are assigned only to containers

As we are doing this at the moment manually, I wanted to use lnst to automate this setup

As this is a physical host located only in one DC (DCA) I plan to create a second physical host in a second DC (DCB) and create a similar environment to test network across the two dc.

Considering this requirement can you tell me what are the supported scenarios from the lnst point of view ?

[jtluka]

Thanks for additional details. The short answer is that it is possible to automate only parts of your setup, not the whole environment in one run. Also, it is not possible to create containers on two different physical hosts and use them for testing done with LNST.

In your setup I see two distinct parts that could be automated but this needs to be done separately:

• physical host setup (physical interface + vlan on top of it)
• containers setup - but there's no way to connect the setup to the underlying network (vlan interface)

Important part is that you either use physical hosts as LNST agents (using the default LNST pool manager) or you would use LNST to dynamically create containers that start agents in them (the ContainerPoolManager). The agents are then controlled by LNST controller by the actions defined in a recipe.

Given the complexity of your setup and LNST missing support for mixed physical host and container agent pool I'm not sure if LNST is the best tool to prepare your testbed.