Re: [vpp-dev] Bond interface won't respond ping #vnet #vpp
Dear Steven Thank you very much for your quick and nice response. I suppose the beginning of my question might misguide you. Let me clear my test scenario: I have a Virtual Machine (VM1) which runs VPP and has an interface called GigabitEthernet0/8/0. I have another Virtual Machine (VM2) that it's interface (eth1) is in the same Kernel bridge as GigabitEthernet0/8/0 (and does not run VPP). So that I am able to ping GigabitEthernet0/8/0 easily (from VM2). After creating a Bond interface (in VM1) with LACP mode (and also setting the state up and giving it IP address) and binding GigabitEthernet0/8/0 to the Bond interface I have neither ping of GigabitEthernet0/8/0 nor Bond interface (from VM2). I traced packets and It seems Bond interface is able to receive ARP packets (and learn it), however is not able to respond back to it. So I went ahead and set arps (for VM2) so that it started to send ICMP packets and again Bond interface (in VM1) was able to receive it but could not respond to it. So my question really is: 1) Why don't Bond interface is not able to respond to either ARP or ICMP packets? 2) Is my config incomplete? (or maybe wrong) 3) Is it logical to ping a Bond Interface? Thank you again for your response, -- Anthony -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#12331): https://lists.fd.io/g/vpp-dev/message/12331 Mute This Topic: https://lists.fd.io/mt/29916205/21656 Mute #vpp: https://lists.fd.io/mk?hashtag=vpp=1480452 Mute #vnet: https://lists.fd.io/mk?hashtag=vnet=1480452 Group Owner: vpp-dev+ow...@lists.fd.io Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [vpp-dev] VPP coredump on handling IPv6 mDNS packets on interface with ipv6 not enabled explicilty
Hi,
Thanks for patch. Please also help in undestanding the use of ip6_input
and use of vnet_feature_arc_start function.
In the ip6_input function "next0" and "next1" is to
LOOKUP_MULTICAST/LOOKUP before invoking the vnet_feature_arc_start
function. As in the case of the interface feature are not initialized
appropriately as in the case of this bug, we end up the
"vnet_have_features" return 0 and the next0 and next1 does NOT get
updated, and will next remain as LOOKUP_MULTICAST/LOOKUP and processed. Is
that correct? Should the next0 and next1 set to IP6_INPUT_NEXT_DROP before
the arc0 and arc1 values will lead to the appropriate update of next0 and
next1 with in the vnet_feature_arc_start call if interface has feature
else it is error dropped. That way we will not lead the buffers handled by
the code with un-initialized datastructures and tables etc leading to
crash.
Please see the relevant lines of the ip6_input function below.
sw_if_index0 = vnet_buffer (p0)->sw_if_index[VLIB_RX];
sw_if_index1 = vnet_buffer (p1)->sw_if_index[VLIB_RX];
if (PREDICT_FALSE (ip6_address_is_multicast (>dst_address)))
{
arc0 = lm->mcast_feature_arc_index;
next0 = IP6_INPUT_NEXT_LOOKUP_MULTICAST;
}
else
{
arc0 = lm->ucast_feature_arc_index;
next0 = IP6_INPUT_NEXT_LOOKUP;
}
if (PREDICT_FALSE (ip6_address_is_multicast (>dst_address)))
{
arc1 = lm->mcast_feature_arc_index;
next1 = IP6_INPUT_NEXT_LOOKUP_MULTICAST;
}
else
{
arc1 = lm->ucast_feature_arc_index;
next1 = IP6_INPUT_NEXT_LOOKUP;
}
vnet_buffer (p0)->ip.adj_index[VLIB_RX] = ~0;
vnet_buffer (p1)->ip.adj_index[VLIB_RX] = ~0;
vnet_feature_arc_start (arc0, sw_if_index0, , p0);
vnet_feature_arc_start (arc1, sw_if_index1, , p1);
Thanks
Rupesh
On Fri, Feb 22, 2019 at 6:13 PM Neale Ranns (nranns)
wrote:
>
>
> Hi Rupesh,
>
>
>
> Thank you for spending the time to investigate. I have pushed a patch to
> fix the issue, and another found, after removing the cast that was masking
> the problem.
>
> https://gerrit.fd.io/r/#/c/1/
>
>
>
> Regards,
>
> neale
>
>
>
> *De : *Rupesh Raghuvaran
> *Date : *vendredi 22 février 2019 à 13:13
> *À : *"Neale Ranns (nranns)"
> *Cc : *"vpp-dev@lists.fd.io"
> *Objet : *Re: [vpp-dev] VPP coredump on handling IPv6 mDNS packets on
> interface with ipv6 not enabled explicilty
>
>
>
> Hi Neale,
>
>
>
> Thanks for all the help.
>
>
>
> I was able to the root cause the issue happening with my private build.
> There was issue with one of the sw_interface_add_del functions invoked via
> the call_elf_section_interface_callbacks during the interface create.
> The vnet_arp_delete_sw_interface definitied of void return type. but in the
> call_elf_section_interface_callbacks expects the callbacks to return
> clib_error_t type. For some reason the execution seems to fail due a
> non-zero error type with the build using gcc7.3 which was build from the
> yocto framework. After fixing this code I was able to get the features
> enabled as required. Even though most of the callbacks do not have any
> error paths and returns 0, it would be good to have some logs with in
> call_elf_section_interface_callbacks to take not of any failure due to
> error.
>
>
>
> Thanks
>
> Rupesh
>
>
>
> On Thu, Feb 21, 2019 at 9:45 PM Neale Ranns (nranns)
> wrote:
>
>
>
> Hi Rupesh,
>
>
>
> Those feature are enabled by default on interfaces that are newly created.
>
>
>
> DBGvpp# loop cre
>
> loop0
>
> DBGvpp# set int state loop0 up
>
> DBGvpp# sh int feat loop0
>
> Feature paths configured on loop0...
>
> …
>
> ip6-multicast:
>
> ip6-not-enabled
>
>
>
> ip6-unicast:
>
> ip6-not-enabled
>
>
>
> DBGvpp# create bridge 1
>
> DBGvpp# set int l2 bridge loop0 1 bvi
>
> DBGvpp# sh int feat loop0
>
> Feature paths configured on loop0...
>
>
>
> ip6-multicast:
>
> ip6-not-enabled
>
>
>
> ip6-unicast:
>
> ip6-not-enabled
>
>
>
>
>
> Add and remove an address:
>
>
>
> DBGvpp# set int ip address loop0 2001::1/64
>
> DBGvpp# sh int feat loop0
>
> Feature paths configured on loop0...
>
> …
>
> ip6-multicast:
>
>
>
> ip6-unicast:
>
>
>
> DBGvpp# set int ip address del loop0 2001::1/64
>
> DBGvpp# sh int feat loop0
>
> Feature paths configured on loop0...
>
> …
>
> ip6-multicast:
>
> ip6-not-enabled
>
>
>
> ip6-unicast:
>
> ip6-not-enabled
>
>
>
>
>
> regards,
>
> neale
>
>
>
>
>
> *De : *Rupesh Raghuvaran
> *Date : *jeudi 21 février 2019 à 16:23
> *À : *"Neale Ranns (nranns)"
> *Cc : *"vpp-dev@lists.fd.io"
> *Objet : *Re: [vpp-dev] VPP coredump on handling IPv6 mDNS packets on
> interface with ipv6 not enabled explicilty
>
>
>
> Hi Neale,
>
> I do not see the interface get this ip6-not-enabled feature enabled on the
> interface on creation, the show
Re: [vpp-dev] VPP doesn't seem to recognise 25GbE link speed NICs logging warning: (18.01)
> On 22 Feb 2019, at 16:51, chetan bhasin wrote: > > Hi Damajan, > > I need your guidance. > > I am working on vpp 18.01 . > > VPP doesn't seem to recognise 25GbE as per the link speed NICs logging > warning. > > Query1 Does it have any impact on the packet processing ? likely not, it is just cosmetic... > > I found a change-list committed by you , is it safe to back-merge only this > change to vpp18.01? > > commit 7c748bbe40f102f15c70bc33ed491be5283ed69a > Author: Damjan Marion mailto:damar...@cisco.com>> > Date: Sun Feb 25 22:55:03 2018 +0100 > vnet: add 25G interface speed flag > Change-Id: I1d3ede2b043e1fd4abc54f540bb1d3ac9863016e > Signed-off-by: Damjan Marion mailto:damar...@cisco.com>> > > Query 2 : If its safe to back-merge , Do I need to take any other changes > which have any link with 25G card handling ? No idea, i suggest moving to newer vpp version -- Damjan -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#12328): https://lists.fd.io/g/vpp-dev/message/12328 Mute This Topic: https://lists.fd.io/mt/2584/21656 Group Owner: vpp-dev+ow...@lists.fd.io Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[vpp-dev] VPP doesn't seem to recognise 25GbE link speed NICs logging warning: (18.01)
Hi Damajan, I need your guidance. I am working on vpp 18.01 . VPP doesn't seem to recognise 25GbE as per the link speed NICs logging warning. Query1 Does it have any impact on the packet processing ? I found a change-list committed by you , is it safe to back-merge only this change to vpp18.01? commit 7c748bbe40f102f15c70bc33ed491be5283ed69a Author: Damjan Marion Date: Sun Feb 25 22:55:03 2018 +0100 vnet: add 25G interface speed flag Change-Id: I1d3ede2b043e1fd4abc54f540bb1d3ac9863016e Signed-off-by: Damjan Marion Query 2 : If its safe to back-merge , Do I need to take any other changes which have any link with 25G card handling ? Your assistance is much appreciated! Thanks, Chetan Bhasin -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#12327): https://lists.fd.io/g/vpp-dev/message/12327 Mute This Topic: https://lists.fd.io/mt/2584/21656 Group Owner: vpp-dev+ow...@lists.fd.io Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [vpp-dev] [tsc] FD.io minisummit at Kubecon EU (May 21-23, Barcelona)
Hi Ed Is participation to fd.io summit free of charge? >From hicn project point of view Kubecon EU in Barcelona is a convenient location. Thanks Luca From: on behalf of Edward Warnicke Date: Thursday 21 February 2019 at 21:15 To: "t...@lists.fd.io" , vpp-dev , "csit-...@lists.fd.io" , "dmm-...@lists.fd.io" , honeycomb-dev , "sweetcomb-...@lists.fd.io" , "hicn-...@lists.fd.io" Subject: Re: [tsc] FD.io minisummit at Kubecon EU (May 21-23, Barcelona) + hicn and sweetcomb, who's lists were misconfigured the first time I sent it :) Ed On Thu, Feb 21, 2019 at 1:04 PM Ed Warnicke wrote: Traditionally in the past FD.io has held collocated minisummits at Kubecon (NA and EU). We are fortunate to have budget to do Kubecon EU, Kubecon NA, and one other collocated event (probably best to be held in Asia and possibly at an embedded event). In the course of discussing this, the FD.io Marketing group felt that doing a separate FD.io booth at Kubecon EU was a clear win, but raised the question: - Is there a better choice for an EU event to collocate with for the FD.io minisummit? This is a good question, and so wanted to open the discussion to the broader community, as it differs from what had previously been discussed in the community and decided on. So, thoughts? Opinions? Ideas? Ed -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#12326): https://lists.fd.io/g/vpp-dev/message/12326 Mute This Topic: https://lists.fd.io/mt/29997902/21656 Group Owner: vpp-dev+ow...@lists.fd.io Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [vpp-dev] VPP coredump on handling IPv6 mDNS packets on interface with ipv6 not enabled explicilty
Hi Neale, Thanks for all the help. I was able to the root cause the issue happening with my private build. There was issue with one of the sw_interface_add_del functions invoked via the call_elf_section_interface_callbacks during the interface create. The vnet_arp_delete_sw_interface definitied of void return type. but in the call_elf_section_interface_callbacks expects the callbacks to return clib_error_t type. For some reason the execution seems to fail due a non-zero error type with the build using gcc7.3 which was build from the yocto framework. After fixing this code I was able to get the features enabled as required. Even though most of the callbacks do not have any error paths and returns 0, it would be good to have some logs with in call_elf_section_interface_callbacks to take not of any failure due to error. Thanks Rupesh On Thu, Feb 21, 2019 at 9:45 PM Neale Ranns (nranns) wrote: > > > Hi Rupesh, > > > > Those feature are enabled by default on interfaces that are newly created. > > > > DBGvpp# loop cre > > loop0 > > DBGvpp# set int state loop0 up > > DBGvpp# sh int feat loop0 > > Feature paths configured on loop0... > > … > > ip6-multicast: > > ip6-not-enabled > > > > ip6-unicast: > > ip6-not-enabled > > > > DBGvpp# create bridge 1 > > DBGvpp# set int l2 bridge loop0 1 bvi > > DBGvpp# sh int feat loop0 > > Feature paths configured on loop0... > > > > ip6-multicast: > > ip6-not-enabled > > > > ip6-unicast: > > ip6-not-enabled > > > > > > Add and remove an address: > > > > DBGvpp# set int ip address loop0 2001::1/64 > > DBGvpp# sh int feat loop0 > > Feature paths configured on loop0... > > … > > ip6-multicast: > > > > ip6-unicast: > > > > DBGvpp# set int ip address del loop0 2001::1/64 > > DBGvpp# sh int feat loop0 > > Feature paths configured on loop0... > > … > > ip6-multicast: > > ip6-not-enabled > > > > ip6-unicast: > > ip6-not-enabled > > > > > > regards, > > neale > > > > > > *De : *Rupesh Raghuvaran > *Date : *jeudi 21 février 2019 à 16:23 > *À : *"Neale Ranns (nranns)" > *Cc : *"vpp-dev@lists.fd.io" > *Objet : *Re: [vpp-dev] VPP coredump on handling IPv6 mDNS packets on > interface with ipv6 not enabled explicilty > > > > Hi Neale, > > I do not see the interface get this ip6-not-enabled feature enabled on the > interface on creation, the show interface feat have the ip4/ip6 > unicast/multicast have arc "none configured". when the interface is > created. > Is this the default state with which interface is expected to come up ? > How does one bring a created loopback into the desired ip6-not-enabled > feature set for ip6-unicast/ip6-multicast arc ? > From the cli commands using the "set interface feature > arc " was able to bring the interface to that > specific state, but I could not find the api doing the same. > > Thanks > Rupesh > > > > On Wed, Feb 20, 2019 at 12:02 AM Neale Ranns (nranns) > wrote: > > > > Hi Rupseh, > > > > Interfaces that are not ip6 enabled show these features enabled: > > > > ip6-multicast: > > ip6-not-enabled > > > > ip6-unicast: > > ip6-not-enabled > > > > it’s the ip6-not-enabled node/feature that is enabled on the interface as > an input feature that drops the packets. > > > > /neale > > > > *De : * au nom de Rupesh Raghuvaran < > rupesh.raghuva...@gmail.com> > *Date : *mardi 19 février 2019 à 18:06 > *À : *"vpp-dev@lists.fd.io" > *Objet : *[vpp-dev] VPP coredump on handling IPv6 mDNS packets on > interface with ipv6 not enabled explicilty > > > > Missed to do a reply all, adding vpp-dev back > > > > Thanks > > Rupesh > > -- Forwarded message - > From: *Rupesh Raghuvaran* > Date: Tue, Feb 19, 2019 at 10:02 PM > Subject: Re: [vpp-dev] VPP coredump on handling IPv6 mDNS packets on > interface with ipv6 not enabled explicilty > To: Neale Ranns (nranns) > > > > Hi Neale,e > > > > I could not spot the specific code in ip6-input which drops the packet if > the rx interface is not ipv6 enabled. Could you please point that to me. > > > > > > Please find the requested information below > > > > DBGvpp# show interface loop1 > > Name IdxState MTU (L3/IP4/IP6/MPLS) > Counter Count > > loop1 5 up 9000/0/0/0 rx > packets 2617 > > rx > bytes 130415 > > tx > packets 2068 > > tx > bytes 111686 > > drops > 3245 > > punt >170 > > ip4 > 240 > > DBGvpp# show interface address > > GigabitEthernet0/14/0 (up): >
Re: [vpp-dev] FD.io outage
Please follow https://status.linuxfoundation.org/ for updates on the ongoing issues with Jenkins and Nexus. Thank you, Vanessa On 02/22/2019 02:26 AM, Vanessa Valderrama wrote: > Multiple LF projects are experiencing issues reaching Jenkins and Nexus, > . We are aware of the issue and are in contact with our vendor who is > working on the issue. Unfortunately we do not have an ETA at this time. > We apologize for the inconvenience. > > Thank you, > Vanessa > -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#12323): https://lists.fd.io/g/vpp-dev/message/12323 Mute This Topic: https://lists.fd.io/mt/29996672/21656 Group Owner: vpp-dev+ow...@lists.fd.io Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
