That's great. Thanks a lot, Jeff. So maybe now the OSPF also will work. My fix of the segfault was just adding "if" in "src/vlib/counter.h". So maybe this broke the multicast forwarding from VPP to Linux...
I will try the version with your fixes. On Mon, Oct 9, 2017 at 1:18 PM, Shaw, Jeffrey B <jeffrey.b.s...@intel.com> wrote: > I’ve submitted changes 8716, 8717, and 8718, which should fix the issues > we’ve discussed in this thread. > > > > Thanks, > > Jeff > > > > *From:* Michael Borokhovich [mailto:michael...@gmail.com] > *Sent:* Monday, October 09, 2017 9:07 AM > *To:* Ni, Hongjun <hongjun...@intel.com> > *Cc:* Neale Ranns (nranns) <nra...@cisco.com>; Shaw, Jeffrey B < > jeffrey.b.s...@intel.com>; vppsb-...@lists.fd.io; vpp-dev < > vpp-dev@lists.fd.io> > > *Subject:* Re: [vpp-dev] Multiple VRFs in 1609 > > > > Thanks, Hongjun, > > > > I will check this once I see that the routing plugin works with VPP1707. > > > > On Fri, Oct 6, 2017 at 7:25 PM, Ni, Hongjun <hongjun...@intel.com> wrote: > > Hi Michael and Neale, > > > > As per my previous fixing experience on router plugin, I guess that the > cause may locate at: > > Function tap_inject_enabel(): add IPv4 multicast route. > > Please take a look at this function and multicast route involved. > > > > -Hongjun > > > > *From:* vpp-dev-boun...@lists.fd.io [mailto:vpp-dev-boun...@lists.fd.io] *On > Behalf Of *Michael Borokhovich > *Sent:* Friday, October 6, 2017 11:22 PM > *To:* Neale Ranns (nranns) <nra...@cisco.com> > *Cc:* Shaw, Jeffrey B <jeffrey.b.s...@intel.com>; vppsb-...@lists.fd.io; > vpp-dev <vpp-dev@lists.fd.io> > > > *Subject:* Re: [vpp-dev] Multiple VRFs in 1609 > > > > 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
