I will look into it. It looks like the calling function is in the file "
turbotap/turbotap/device.c" in vppsb. However, I'm not familiar with the
logic there...
I will try to fix it temporary locally directly in the "
vlib_increment_simple_counter" function and see if it works.
Thanks!
On Fri, Oct 6, 2017 at 11:08 AM, Neale Ranns (nranns) <nra...@cisco.com>
wrote:
> Hi Michael,
>
>
>
> It would be best if you fixed the caller to not pass ~0. In this case the
> ~0 is coming from the packet VLIB_RX interface. So best to find and fix the
> input node that should have set this correctly.
>
>
>
> /neale
>
>
>
> *From: *Michael Borokhovich <michael...@gmail.com>
> *Date: *Friday, 6 October 2017 at 15:49
> *To: *"Shaw, Jeffrey B" <jeffrey.b.s...@intel.com>
> *Cc: *"Pierre Pfister (ppfister)" <ppfis...@cisco.com>, Florin Coras <
> fcoras.li...@gmail.com>, vpp-dev <vpp-dev@lists.fd.io>, "Neale Ranns
> (nranns)" <nra...@cisco.com>, "vppsb-...@lists.fd.io" <
> vppsb-...@lists.fd.io>
>
> *Subject: *Re: [vpp-dev] Multiple VRFs in 1609
>
>
>
> Hi Jeff,
>
>
>
> Regarding the workaround for the problem [3] (segfault). Do you think it
> is enough just to add a simple check e.g., if(index != ~0)? Or we have a
> problem somewhere else since the ~0 index should not be passed to this
> function?
>
>
>
> Thanks,
>
> Michael.
>
>
>
>
>
> On Thu, Oct 5, 2017 at 1:03 PM, Shaw, Jeffrey B <jeffrey.b.s...@intel.com>
> wrote:
>
> Hi Michael, do you really need the router plugin? Based on the commands
> you’re using it seems you’re adding routes using the vpp cli interface,
> which is not how the router plugin is supposed to work. Those routes won’t
> show up on the control side (i.e. Linux). Nor is there any support for
> multiple routing tables. The routes should be added from the control side,
> then they are mirrored to VPP.
>
>
>
> @Pierre,
>
> I was able to get the router plugin to work with VPP 1707 (348edb1
> [origin/stable/1707] Set MAC address needs the HW interface index).
>
> I used vppsb commit 529ec1b [origin/master] Fix name of VCL LD_PRELOAD lib
> dir env var.
>
>
>
> A few things went wrong:
>
> 1) Had to disable testrtnl_plugin in vppsb/netlink[1] to get netlink
> to compile
>
> 2) Delete the reference to vlib_buffer_chain_validate() in
> vppsb/router after symbol lookup failure[2]
>
> 3) Work-around a segmentation fault[3] in
> vlib_increment_simple_counter()due to an index being set to ~0
>
>
>
> I can submit two patches to fix 1 and 2.
>
>
>
> For number 3, it looks like we might want to check for an invalid
> interface? This function is probably used often, so adding that check will
> be bad for performance. Maybe we can check for invalid interface in
> process_drop_punt() instead.
>
>
>
> always_inline void
>
> vlib_increment_simple_counter (vlib_simple_counter_main_t * cm,
>
> u32 thread_index, u32 index, u64 increment)
>
> {
>
> counter_t *my_counters;
>
>
>
> my_counters = cm->counters[thread_index];
>
> my_counters[index] += increment;
> <--- seg-fault happens here when index is ~0, maybe check it?
>
> }
>
>
>
>
>
> -Jeff
>
>
>
> More details…
>
>
>
> [1] Building netlink fails... need to disable test.c
>
>
>
> /root/vpp/build-data/../netlink/test/test.c: In function
> ‘mapper_ns_add_command_fn’:
>
> /root/vpp/build-data/../netlink/test/test.c:125:14: error: implicit
> declaration of function ‘ip4_fib_index_from_table_id’
> [-Werror=implicit-function-declaration]
>
> u32 fib4 = ip4_fib_index_from_table_id(table_id);
>
> ^
>
> /root/vpp/build-data/../netlink/test/test.c:126:14: error: implicit
> declaration of function ‘ip6_fib_index_from_table_id’
> [-Werror=implicit-function-declaration]
>
> u32 fib6 = ip6_fib_index_from_table_id(table_id);
>
> ^
>
> cc1: all warnings being treated as errors
>
>
>
>
>
> [2] After "enable tap-inject", we see vpp0 in the Linux "ip link". Setting
> "ip link set dev vpp0 up" produces the following error... need to not call
> that function.
>
>
>
> /root/vpp/build-root/install-vpp_debug-native/vpp/bin/vpp: symbol lookup
> error: /usr/lib/vpp_plugins/router.so: undefined symbol:
> vlib_buffer_chain_validate
>
>
>
>
>
> [3] Segmentation fault because the "index" is ~0
>
> Thread 1 "vpp_main" received signal SIGSEGV, Segmentation fault.
>
> 0x00007ffff6d985a6 in vlib_increment_simple_counter (cm=0x7fffb67143bc,
> thread_index=0, index=4294967295, increment=1) at
> /root/vpp/build-data/../src/vlib/counter.h:84
>
> 84 my_counters[index] += increment;
>
> (gdb) bt
>
> #0 0x00007ffff6d985a6 in vlib_increment_simple_counter
> (cm=0x7fffb67143bc, thread_index=0, index=4294967295, increment=1) at
> /root/vpp/build-data/../src/vlib/counter.h:84
>
> #1 0x00007ffff6d9c8d8 in process_drop_punt (vm=0x7ffff7b9d440
> <vlib_global_main>, node=0x7fffb6758ec0, frame=0x7fffb5c92400,
> disposition=VNET_ERROR_DISPOSITION_DROP) at /root/vpp/build-data/../src/
> vnet/interface_output.c:1018
>
> #2 0x00007ffff6d9cebb in process_drop (vm=0x7ffff7b9d440
> <vlib_global_main>, node=0x7fffb6758ec0, frame=0x7fffb5c92400) at
> /root/vpp/build-data/../src/vnet/interface_output.c:1155
>
> #3 0x00007ffff78f40f0 in dispatch_node (vm=0x7ffff7b9d440
> <vlib_global_main>, node=0x7fffb6758ec0, type=VLIB_NODE_TYPE_INTERNAL,
> dispatch_state=VLIB_NODE_STATE_POLLING, frame=0x7fffb5c92400,
> last_time_stamp=1322800753683)
>
> at /root/vpp/build-data/../src/vlib/main.c:1016
>
> #4 0x00007ffff78f46a9 in dispatch_pending_node (vm=0x7ffff7b9d440
> <vlib_global_main>, pending_frame_index=1, last_time_stamp=1322800753683)
> at /root/vpp/build-data/../src/vlib/main.c:1166
>
> #5 0x00007ffff78f6725 in vlib_main_or_worker_loop (vm=0x7ffff7b9d440
> <vlib_global_main>, is_main=1) at /root/vpp/build-data/../src/
> vlib/main.c:1625
>
> #6 0x00007ffff78f67d6 in vlib_main_loop (vm=0x7ffff7b9d440
> <vlib_global_main>) at /root/vpp/build-data/../src/vlib/main.c:1644
>
> #7 0x00007ffff78f6e61 in vlib_main (vm=0x7ffff7b9d440 <vlib_global_main>,
> input=0x7fffb669efb0) at /root/vpp/build-data/../src/vlib/main.c:1774
>
> #8 0x00007ffff79647d1 in thread0 (arg=140737349538880) at
> /root/vpp/build-data/../src/vlib/unix/main.c:514
>
> #9 0x00007ffff663100c in clib_calljmp () at /root/vpp/build-data/../src/
> vppinfra/longjmp.S:110
>
> #10 0x00007fffffffd380 in ?? ()
>
> #11 0x00007ffff7964c24 in vlib_unix_main (argc=25, argv=0x6f6840) at
> /root/vpp/build-data/../src/vlib/unix/main.c:577
>
> #12 0x00000000004079ea in main (argc=25, argv=0x6f6840) at
> /root/vpp/build-data/../src/vpp/vnet/main.c:202
>
>
>
>
>
> *From:* Michael Borokhovich [mailto:michael...@gmail.com]
> *Sent:* Thursday, October 05, 2017 9:39 AM
> *To:* Pierre Pfister (ppfister) <ppfis...@cisco.com>
> *Cc:* Florin Coras <fcoras.li...@gmail.com>; vpp-dev <vpp-dev@lists.fd.io>;
> Neale Ranns (nranns) <nra...@cisco.com>; Shaw, Jeffrey B <
> jeffrey.b.s...@intel.com>
> *Subject:* Re: [vpp-dev] Multiple VRFs in 1609
>
>
>
> Hi Pierre,
>
>
>
> I would like to have two VRFs. The first interface belongs to VRF-1, the
> second to VRF-2 and the third should be shared between the VRFS (i.e., the
> default VRF-0, as I understand...).
>
>
>
> Now, if a packet arrives at the first or the second interface, it should
> be forwarded via the third interface.
>
>
>
> I tried multiple routing configurations but they didn't work. However,
> they do work in VPP 1710... In my first email in this thread, I mention
> what configurations I tried and what were the symptoms.
>
>
>
> Ideally, would be to use 1710. But unfortunately, router plugin works only
> with VPP 1609...
>
>
>
> Thanks!
>
> Michael.
>
>
>
>
>
>
>
>
>
>
>
> On Thu, Oct 5, 2017 at 3:41 AM, Pierre Pfister (ppfister) <
> ppfis...@cisco.com> wrote:
>
> Hello Michael,
>
>
>
> Can you be more specific about what doesn't work ?
>
>
>
> Jeff, do you have some time to look at the router plugin ?
>
>
>
> Thanks,
>
>
>
> - Pierre
>
>
>
>
>
> Le 5 oct. 2017 à 05:22, Michael Borokhovich <michael...@gmail.com> a
> écrit :
>
>
>
> Hi Florin,
>
>
>
> Thank you for the response. The reason I stick to 1609 is the router
> plugin (vppsb) that works with 1609 but does not with any other VPP version
> I tried. So, I'm trying to get multiple VRFs works with 1609 since I also
> need the router plugin for the project...
>
>
>
> Thanks,
>
> Michael.
>
>
>
>
>
> On Wed, Oct 4, 2017 at 10:33 PM, Florin Coras <fcoras.li...@gmail.com>
> wrote:
>
> Michael,
>
>
>
> I would recommend you switched to a newer release (17.07 or the soon to be
> release 17.10) since the fib code has been completely reworked in 17.01.
>
>
>
> Florin
>
>
>
> On Oct 4, 2017, at 7:13 PM, Michael Borokhovich <michael...@gmail.com>
> wrote:
>
>
>
> Hi,
>
>
>
> I'm trying to configure the following setup.
>
>
>
> GigabitEthernet0/4/0 - Table 1
>
> GigabitEthernet0/5/0 - Table 2
>
> GigabitEthernet0/6/0 - Table 0 (default)
>
>
>
> If a packet with DST_IP="10.5.1.0/24" received at GigabitEthernet0/4/0 or
> GigabitEthernet0/5/0 it needs to be sent via GigabitEthernet0/6/0.
>
>
>
> The following works for VPP 1710:
>
> vppctl ip route add 10.5.1.0/24 table 1 via 10.5.4.11 GigabitEthernet0/6/0
>
>
>
> vppctl ip route add 10.5.1.0/24 table 2 via 10.5.4.11 GigabitEthernet0/6/0
>
> But for 1609 it does not work. The routes are added to the default table 0
> instead of tables 1 and 2.
>
> If I do just this (just interface name, without the next ho IP):
>
> vppctl ip route add 10.5.1.0/24 table 1 via GigabitEthernet0/6/0
>
> Then the route is installed correctly to table 1 but the outgoing packets
> are messed up - sent without ethernet header.
>
>
>
> Any ideas how to make multiple VRFs woks in 1609?
>
>
>
> Thanks,
>
> Michael.
>
>
>
> _______________________________________________
> vpp-dev mailing list
> vpp-dev@lists.fd.io
> https://lists.fd.io/mailman/listinfo/vpp-dev
>
>
>
>
>
> _______________________________________________
> vpp-dev mailing list
> vpp-dev@lists.fd.io
> https://lists.fd.io/mailman/listinfo/vpp-dev
>
>
>
>
>
>
>
>
_______________________________________________
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev
