Closed denis-tingaikin closed 4 years ago
@ondrej-fabry Could you have a look?
So I did a little bit of parsing for Case 1.
```
vpp_config:<
interfaces:
```
<
interfaces:
And it is looks like you are expecting to see phys_address
set for linux side of TAP interface to be also phys_address
of VPP side of TAP. Or am I missing something here?
yeah, I think, it is not working this way. In client.Dump()
response you have vpp_config
which will tell you about VPP side of TAP and linux_config
which contains info about Linux side of TAP.
If you are setting phys_address
for Linux side, then you may check it in linux_config
and in the container (or whatever this interface was put) and expect it to match.
For the Case 1, you are setting 2a:42:a5:73:90:97
for linux interface, and not for vpp side, but in config you see VPP generated address 02:fe:b0:95:4e:b9
for interface in VPP and it's ok that they are different. (I'm not sure why linux_config
is empty though)
And as for the Case 2, I think you've compared address of interface in VPP with address of interface in target container and again it's ok that they are different.
One more thing, I think, it would be more practical to give TAP interfaces names like awesomeLinuxTap
and awesomeVPPTap
, so no confusion in future will happen.
@rewenset is correct here.
(I'm not sure why linux_config is empty though)
Unfortunately Linux dump is not implemented in Configurator. Opened issue for this: #1528
@rewenset yes, you are right. The problem is not absolutely correct. The main problem of dump response is it has not linux config.
@rewenset , @ondrej-fabry got it, thanks for answers.
@rewenset yes, you are right. The problem is not absolutely correct. The main problem of dump response is it has not linux config.
Is this currently a blocker for you?
Is this currently a blocker for you?
Yes, it blocks me.
I need to get a generated mac address for linux interfaces right after creation. It is needed for updating arp table in some cases for SRC interface(for example DST interface was recreated). We have few scenarios where the container with SRC interface has wrong arp entry (means that entry has correct IP, but wrong MAC).
Do you know some workaround without using dump requests to fix arp table? For example, can we somehow clear arp entries for SRC interface via vpp-agent?
@ondrej-fabry ^^^
Do you know some workaround without using dump requests to fix arp table? For example, can we somehow clear arp entries for SRC interface via vpp-agent?
Unfortunately it is not possible to clear dynamically created ARP entries via VPP-Agent. One workaround (until linux dump is available) could be to generate MAC address for the VETH/TAP on the CNF side and create static ARP entries on VPP yourselves - then if you remember the generated MAC address, you will know what to remove once it is re-created. Btw., do you not have this issue also on CNFs that were connected to a restarted client/endpoint? I would expect their ARP table to contain an invalid entry for some time too.
@ondrej-fabry Progress on this?
@edwarnicke should be fixed in #1574
Please re-test to confirm.
looks like fixed
Steps to reproduce:
Case 1
Notice: Interface DST-1 has phys_address:
2a:42:a5:73:90:97
Notice: interfaces: DST-1 has phys_address:\"02:fe:b0:95:4e:b9\",
Actual: Dump request returns strange phys_address. Expected: Dump request returns actual phys_address.
Case 2
Use vppagnet version 2.3.0 and use startup-config: https://github.com/networkservicemesh/networkservicemesh/blob/master/dataplane/vppagent/conf/vpp/startup.conf 2) Create configurator.ConfiguratorClient with grpc connection via TCP localhost:9111 3) Do client.Update(config) where config is
Notice: Interface DST-1 has not phys_address. Let vpp generate it.
4) Do client.Dump() 5) Check phys address of the interface in target container.
Actual: Dump request returns strange phys_address. Expected: Dump request returns actual phys_address.
Logs
1) Get response for case 1 is