hwaddr for layered stacks
Jan Tluka
jtluka at redhat.com
Fri Aug 31 10:03:44 UTC 2012
Hi guys,
I came over specific case that results in exception.
I have eth interface put into vlan. LNST has problems with resolving hwaddr
function template for the vlan interface.
The traceback
File "/home/igyn/tmp/lnst/Common/XmlTemplates.py", line 202, in _process_func_template
result = self._call_preprocessor_func(func_name, param_values)
File "/home/igyn/tmp/lnst/Common/XmlTemplates.py", line 210, in _call_preprocessor_func
result = self._hwaddr_func(params)
File "/home/igyn/tmp/lnst/Common/XmlTemplates.py", line 262, in _hwaddr_func
mac_addr = machine['netconfig'][if_id]['hwaddr']
KeyError: 'hwaddr'
The netconfig snippet:
<netconfig>
<interface id="1" phys_id="1" type="eth" />
<interface id="201" type="vlan">
<options>
<option name="vlan_tci" value="22" />
</options>
<slaves>
<slave id="1" />
</slaves>
<addresses>
<address value="192.168.122.201/24"/>
</addresses>
</interface>
</netconfig>
The command snippet:
<command machine_id="1" type="test" value="PktgenTx">
<options>
<option name="netdev_name" value="{devname(1,100)}" />
<option name="addr" value="{ip(2,201)}" />
<option name="hwaddr" value="{hwaddr(2,201)}" />
<option name="skb_clone" value="0" />
<option name="count" value="1000000" />
</options>
</command>
Since the 'hwaddr' is added for physical interfaces only (having phys_id
attribute), we're screwed in case of vlan, bond, etc. hwaddr resolutions.
This is needed for example for PktGenTx test case that needs mac address
where to sent traffic.
I'd like to get your opinions whether we should set hwaddr in some
cases. For example in case of vlan over eth the hw address of vlan
interface is the same as underlying physical interface. On the other
hand, in case of bonding the hwaddr does not have to be stable, so the
hwaddr should not be set.
Another approach would be to use the underlying hwaddr as a workaround.
It would work for vlan case. Will it work in case of bonding as well?
I'd be happy for any suggestions, comments.
Thanks,
Jan
More information about the LNST-developers
mailing list