Hoi Petr, others,
Petr, in case you were interested to take a look -- I became a bit less
lazy and started VPP in a debugger, and added a breakpoint in the
vnet_hw_interface_add_del_mac_address function.
DBGvpp# create sub HundredGigabitEthernet15/0/0 10
HundredGigabitEthernet15/0/0.10
DBGvpp# show int
Name Idx State MTU (L3/IP4/IP6/MPLS)
Counter Count
GigabitEthernet5/0/0 1 down 9000/0/0/0
GigabitEthernet5/0/1 2 down 9000/0/0/0
GigabitEthernet5/0/2 3 down 9000/0/0/0
GigabitEthernet5/0/3 4 down 9000/0/0/0
HundredGigabitEthernet15/0/0 5 down 9000/0/0/0
HundredGigabitEthernet15/0/0.10 7 down 0/0/0/0
HundredGigabitEthernet15/0/1 6 down 9000/0/0/0
local0 0 down 0/0/0/0
DBGvpp# set interface ip address HundredGigabitEthernet15/0/0.10
192.0.2.1/30
<break>
This is the call stack:
#0 vnet_hw_interface_add_del_mac_address (vnm=0x7ffff7f42ec0 <vnet_main>,
hw_if_index=0, mac_address=0x7fff513e87f0 "\001", is_add=1 '\001')
at /home/pim/src/vpp/src/vnet/interface.c:1580
#1 0x00007ffff77a8b46 in mfib_itf_mac_add_del (itf=0x7fff9c6710c0,
pfx=0x7fff97c69bcc, add=1) at /home/pim/src/vpp/src/vnet/mfib/mfib_itf.c:167
#2 0x00007ffff77a8ad2 in mfib_itf_mac_add (itf=0x7fff9c6710c0,
pfx=0x7fff97c69bcc) at /home/pim/src/vpp/src/vnet/mfib/mfib_itf.c:176
#3 0x00007ffff77ac6a5 in mfib_entry_path_update (mfib_entry_index=1,
source=MFIB_SOURCE_SPECIAL, rpaths=0x7fff97e0ceb0)
at /home/pim/src/vpp/src/vnet/mfib/mfib_entry.c:1070
#4 0x00007ffff77b353c in mfib_table_entry_paths_update_i (fib_index=0,
prefix=0x7ffff7d096e0 <ip4_specials>, source=MFIB_SOURCE_SPECIAL,
entry_flags=MFIB_ENTRY_FLAG_NONE, rpaths=0x7fff97e0ceb0) at
/home/pim/src/vpp/src/vnet/mfib/mfib_table.c:319
#5 0x00007ffff77b31f9 in mfib_table_entry_path_update (fib_index=0,
prefix=0x7ffff7d096e0 <ip4_specials>, source=MFIB_SOURCE_SPECIAL,
entry_flags=MFIB_ENTRY_FLAG_NONE, rpath=0x7fff513e89c0) at
/home/pim/src/vpp/src/vnet/mfib/mfib_table.c:337
#6 0x00007ffff779bbd1 in ip4_mfib_interface_enable_disable (sw_if_index=7,
is_enable=1) at /home/pim/src/vpp/src/vnet/mfib/ip4_mfib.c:158
#7 0x00007ffff720aeec in ip4_add_del_interface_address_internal
(vm=0x7fff96800680, sw_if_index=7, address=0x7fff513e8dd8,
address_length=30,
is_del=0) at /home/pim/src/vpp/src/vnet/ip/ip4_forward.c:807
#8 0x00007ffff720a1f1 in ip4_add_del_interface_address (vm=0x7fff96800680,
sw_if_index=7, address=0x7fff513e8dd8, address_length=30, is_del=0)
at /home/pim/src/vpp/src/vnet/ip/ip4_forward.c:839
#9 0x00007ffff72017e5 in add_del_ip_address (vm=0x7fff96800680,
input=0x7fff513e9e40, cmd=0x7fff97b5c518)
at /home/pim/src/vpp/src/vnet/ip/ip46_cli.c:171
in mfib_itf_mac_add_del(), itf->mfi_sw_if_index==7 (this is the index of
the just created sub-int), the lookup in line 166 yields si->hw_if_index ==
0, which is then passed on to the vnet_hw_interface_add_del_mac_address()
call, provoking the error, because I think it references phy sw index 0
(interface local0)?
DBGvpp# show mfib interface
mFIB interfaces::
0@ HundredGigabitEthernet15/0/0.10: Accept,
1@ HundredGigabitEthernet15/0/0.10: Accept,
Curiously, I would've expected si->hw_if_index to be 5, from
mfi_sw_if_index==7. I'm a bit out of my depth here, so I'll have to defer
to others who are more knowledgeable.
groet,
Pim
On Mon, Jan 17, 2022 at 10:25 AM Pim van Pelt <p...@ipng.nl> wrote:
> Hoi,
>
> I have seen that message, but it is not related to the Linux CP
> plugin, and it seems benign -- that is to say, Linux CP and VPP work just
> fine even though the error is emitted.
> Without Linux CP enabled, the same message appears when adding an IP
> address to a sub-int. I didn't look in to it very long, but the error is
> emitted in src/vnet/interface.c:1583 for
> function vnet_hw_interface_add_del_mac_address() which occurs only in a few
> places:
>
> src/plugins/lldp/lldp_cli.c: vnet_hw_interface_add_del_mac_address
> (lm->vnet_main,
> src/plugins/lldp/lldp_cli.c: vnet_hw_interface_add_del_mac_address
> (lm->vnet_main,
> src/plugins/vrrp/vrrp.c: error = vnet_hw_interface_add_del_mac_address
> src/vnet/interface_api.c: error = vnet_hw_interface_add_del_mac_address
> (vnm, hi->hw_if_index,
> src/vnet/mfib/mfib_itf.c: vnet_hw_interface_add_del_mac_address
> (vnet_get_main(),
> src/vnet/bonding/device.c: error =
> vnet_hw_interface_add_del_mac_address (vnm, s_hi->hw_if_index,
> src/vnet/bonding/device.c: vnet_hw_interface_add_del_mac_address
> (vnm, s_hi->hw_if_index,
> src/vnet/bonding/cli.c: vnet_hw_interface_add_del_mac_address (vnm,
> s_hwif->hw_if_index,
> src/vnet/interface_cli.c: vnet_hw_interface_add_del_mac_address (vnm,
> si->hw_if_index, mac, is_add);
>
> If you're curious, you could take a look at these call sites. One other
> place you might look is ip6_add_del_interface_address()
> and ip4_add_del_interface_address() which are the functions that get called
> when you issue the CLI 'set interface ip address' command.
>
> But it would also be okay to ignore the error for now -- maybe others have
> a recollection of how vnet_hw_interface_add_del_mac_address() does its
> business.
>
> groet,
> Pim
>
> On Mon, Jan 17, 2022 at 9:27 AM Petr Boltík <petr.bol...@gmail.com> wrote:
>
>> Hello,
>>
>> did you notice this error message from systemctl?
>>
>> Message from systemctl status vpp-dataplane:
>> vnet[2526]: interface: hw_add_del_mac_address:
>> vnet_hw_interface_add_del_mac_address: Secondary MAC Addresses not
>> supported for interface index 0
>> Jan 17 03:16:05 stredni vnet[2526]: interface: hw_add_del_mac_address:
>> vnet_hw_interface_add_del_mac_address: Secondary MAC Addresses not
>> supported for interface index 0
>>
>> Vpp run in separated netns. Latest vpp v22.02-rc0~503-gf8dd9d8af. Message
>> is related to ip address configuration on vlan subinterface.
>>
>> Config below...
>>
>> Regards Petr
>>
>> #!/bin/sh
>> vppctl lcp default netns controlplane
>> vppctl lcp lcp-sync on
>> vppctl lcp lcp-auto-subint on
>> vppctl set interface mtu packet 1500 enp3s0
>> vppctl lcp create enp3s0 host-if enp3s0
>> vppctl set interface state enp3s0 up
>> vppctl create sub enp3s0 10
>> vppctl set interface ip address enp3s0.10 192.168.18.1/24
>> vppctl set interface state enp3s0.10 up
>>
>>
>> pá 14. 1. 2022 v 17:42 odesílatel Petr Boltík via lists.fd.io
>> <petr.boltik=gmail....@lists.fd.io> napsal:
>>
>>> Hi,
>>> Yes, I have tested the latest code that includes
>>> https://gerrit.fd.io/r/c/vpp/+/33709. Test:
>>> "lcp lcp-sync on" => everything work fine
>>> "lcp lcp-sync off" => issue appears
>>>
>>> Here is a video with an example
>>> https://youtu.be/wwyXyVilvOk
>>>
>>> Regards
>>> Petr
>>>
>>> pá 14. 1. 2022 v 16:59 odesílatel Pim van Pelt <p...@ipng.nl> napsal:
>>>
>>>> Hoi Petr,
>>>>
>>>> We merged a relevant VPP -> Linux interface sync change in
>>>> https://gerrit.fd.io/r/c/vpp/+/33709 just this week.
>>>> The code that does this sync is in lcp_interface_sync.c:100
>>>> and lcp_interface.c:1004.
>>>> Does your build include that code, and did you issue "lcp lcp-sync on" ?
>>>>
>>>>
>>>> On Fri, Jan 14, 2022 at 3:34 PM Petr Boltík <petr.bol...@gmail.com>
>>>> wrote:
>>>>
>>>>> Hello,
>>>>> I have found a cosmetic issue with a linux-cp TAP device (tested both
>>>>> plugins - original and patched linux-cp 31122 ). If you try to add
>>>>> multiple
>>>>> LCP TAP interfaces, sometimes there is bug in "vppctl show interface"
>>>>> output. MTU at the TAP is randomly shown incorrectly like:
>>>>> tap10 11 up 4/0/0/0
>>>>> tap18 19 up 1500/0/0/0
>>>>> tap26 27 up 9216/0/0/0
>>>>>
>>>>> MTU 1500 pass to the control plane successfully and MTU inside netns
>>>>> is correct. Test script below, you may run it a few times to see an issue.
>>>>> I have run it inside netns "controlplane". Tested 21.10 and
>>>>> 22.02-rc0~347-g5dec92de6.
>>>>>
>>>>> Regards
>>>>> Petr
>>>>>
>>>>> #!/bin/bash
>>>>> vppctl lcp default netns controlplane
>>>>> for i in $(seq 1 30); do
>>>>> vppctl create loopback interface instance $i
>>>>> vppctl set interface mtu packet 1500 loop$i
>>>>> vppctl lcp create loop$i host-if br$i
>>>>> vppctl set interface state loop$i up
>>>>> done
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>> --
>>>> Pim van Pelt <p...@ipng.nl>
>>>> PBVP1-RIPE - http://www.ipng.nl/
>>>>
>>>
>>>
>>>
>>>
>
> --
> Pim van Pelt <p...@ipng.nl>
> PBVP1-RIPE - http://www.ipng.nl/
>
--
Pim van Pelt <p...@ipng.nl>
PBVP1-RIPE - http://www.ipng.nl/
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#20735): https://lists.fd.io/g/vpp-dev/message/20735
Mute This Topic: https://lists.fd.io/mt/88421552/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
