Hi Jeff,

Yes, I really need the router plugin. The experiment I described is a
preliminary test for multiple VRF functionality. Once we see that it works
we will use the Linux control plane to create the routes.

So, if you will push the changes to vppsb that will make it work with 1707
it would be great!

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

Reply via email to