Re: [vpp-dev] About FRR(fast re-routing)

[Ole Troan]

Hehe, wrong TLA mapping. 
See Neale’s response. 

Cheers 
Ole

> On 17 Nov 2018, at 07:08, 倪宝景  wrote:
> 
> HI，
>  https://github.com/FRRouting/frr/wiki/Alternate-forwarding-planes:-VPP
> This wiki offers us the FRR is "free range routing",not "fast re-routing".
> The “fast re-routing” is a method about quickly detect the route fault and 
> switchto a stand-by route to remain the continuity of the network service
> The related technologies may include BFD, LFA and so on.
> 
> thanks
> 
> 
> 
> --
> 
> 
> 
> At 2018-11-16 22:51:10, "Ole Troan"  wrote:
> >> We do not support FRR, nor is there currently a plan to.
> >
> >Although you can run FRR with VPP.
> >https://github.com/FRRouting/frr/wiki/Alternate-forwarding-planes:-VPP
> >
> >Cheers,
> >Ole
> >
> >>  
> >> However, if your label/tunnel/route has only one path, you can achieve a 
> >> similar result to FRR by installing the primary path with a better (lower) 
> >> preference to the backup path. VPP will then cutover when the primary path 
> >> goes down.
> >>  
> >> /neale
> >>  
> >> De :  au nom de 倪宝景 
> >> Date : vendredi 16 novembre 2018 à 09:34
> >> À : "vpp-dev@lists.fd.io" 
> >> Objet : [vpp-dev] About FRR(fast re-routing)
> >>  
> >> Dear Mr/Miss/Ms ：
> >>  I am Baojing Ni, working in FIBERHOME TELECOMMUNICATION TECHNOLOGIES 
> >> Co.,Ltd
> >>  I have a question to consult :
> >>  Do you have the plan about FRR（fast re-routing） MPLS traffic engineering 
> >> in VPP ?
> >>  
> >> I am looking forward for your answers. 
> >> Thank you.
> >>  
> >> --
> >>  
> >>  
> >> 
> >> 
> >> 
> >>  
> >> 
> >> -=-=-=-=-=-=-=-=-=-=-=-
> >> Links: You receive all messages sent to this group.
> >> 
> >> View/Reply Online (#11287): https://lists.fd.io/g/vpp-dev/message/11287
> >> Mute This Topic: https://lists.fd.io/mt/28165403/675193
> >> Group Owner: vpp-dev+ow...@lists.fd.io
> >> Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub  [otr...@employees.org]
> >> -=-=-=-=-=-=-=-=-=-=-=-
> 
> 
>  
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#11297): https://lists.fd.io/g/vpp-dev/message/11297
Mute This Topic: https://lists.fd.io/mt/28165403/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[vpp-dev] Memif with RAW

[satish . gundu]

Hi VPP-Dev,

Can we use memif without attaching to Eth/IP layers. 
This will avoid the need of implementing eth/IP layers on a 
non-VPP-application, if it needs to communicate to a VPP app via memif.
This may need development of a memif mode "RAW", which just reads the packets 
and pushes it onto a custom plugin that decodes the message directly.
Any thoughts on this please.

Really appreciate any views on this and thanks in advance for the help.

Thanks & Regads,
Satish
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#11296): https://lists.fd.io/g/vpp-dev/message/11296
Mute This Topic: https://lists.fd.io/mt/28189776/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[vpp-dev] [FD.io Helpdesk #63805] FD.io compute infra down -

[Vanessa Valderrama via RT]

The hardware has been replace and services have been restored. Thank you for 
your patience. Please open an RT ticket is you are experiencing any issues.  
helpd...@fd.io
Thank you,
Vanessa

On Fri Nov 16 10:26:44 2018, valderrv wrote:
> Apparently, we have an issue with an upstream network provider which
> is impacting some of our CI services.
> 
> We're working on getting more information including an ETA if
> possible. I'll send a notification to the community as well.
> 
> Thank you,
> Vanessa
> 
> 
> On Fri Nov 16 10:18:59 2018, valderrv wrote:
> > Maciek,
> >
> > We're looking into this now.
> >
> > On Fri Nov 16 09:02:19 2018, mackonstan wrote:
> > > Nexus(?) backend to nginx is reporting down.
> > > Resolution time?
> > >
> > > Cheers,
> > > -Maciek
> > >
> > > [cid:876751CF-C733-46B9-9A07-8298C0A0A0C8@cisco.com]
> >
> >



-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#11295): https://lists.fd.io/g/vpp-dev/message/11295
Mute This Topic: https://lists.fd.io/mt/28171040/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] test-ext failures seen on master

[Dave Wallace]

I'll see if I can reproduce the issue.

I seem to recall some python test code which was supposed to detect that 
condition and clean up, but I don't think that I ever verified that it 
worked.


Thanks,
-daw-

On 11/16/2018 11:44 AM, Florin Coras wrote:

I also noticed that although it shouldn’t be different from the vcl test apps 
which seem to be properly killed on test failure. Anyway, it’s on my todo list, 
if nobody beats me to it.

Florin


On Nov 16, 2018, at 5:27 AM, Klement Sekera  wrote:

I've also noticed that quite often a binary called sock_test_client is
left running after a vpp crash or test failure. What's worse, it eats
100% CPU.

Quoting Florin Coras (2018-11-16 00:40:06)

   Thanks, Dave!
   I’ll take a look at those as soon as I can. I’m running multiple
   connections between 2 vpp hosts without issue, so it’s either a
   cut-through session issue or it has to do with how we setup vpp for vrf
   leaking.
   Cheers,
   Florin

 On Nov 15, 2018, at 3:00 PM, Dave Wallace <[1]dwallac...@gmail.com>
 wrote:
 Same here.  However, in the same workspace where all tests passed, I can
 get this test case to fail consistently:

 EXTENDED_TESTS=y TEST=vcl.VCLThruHostStackExtendedBTestCase.* make test
 EXTENDED_TESTS=y TEST=vcl.VCLIpv6ThruHostStackExtendedBTestCase.* make
 test

 In patch 13215, I discovered that making these test cases NOT run
 multiple sockets in parallel the test passes.  My latest patch to that
 has the multiple sockets option commented out with "# ouch! Host Stack
 Bug?" so that all tests pass.

 Thanks,
 -daw-
 On 11/15/2018 4:16 PM, Florin Coras wrote:

That’s an interesting failure. Is the test machine running out of memory?

The extended tests are unstable on my server, so I do see quite a number of 
failures. However this:

make test-ext TEST=vcl.VCLCutThruTestCase.test_vcl_cut_thru_uni_dir_nsock

runs just fine. After the latest test framework changes, are we running 
multiple tests/vpps in parallel? I suspect that may be a source of issues.

Florin


On Nov 15, 2018, at 12:11 PM, Klement Sekera via Lists.Fd.Io 
[2] wrote:

I'm seeing timeouts and coredumps...

e.g.

#6  0x7f9ba0404eb6 in svm_msg_q_try_lock (mq=0x204009440)
at /home/ksekera/vpp/src/svm/message_queue.h:299
299   return pthread_mutex_trylock (>q->mutex);
(gdb) p mq
$1 = (svm_msg_q_t *) 0x204009440
(gdb) p mq->q
$2 = (svm_queue_t *) 0x0

which is part of

#4  
#5  __pthread_mutex_trylock (mutex=0x0) at ../nptl/pthread_mutex_trylock.c:39
#6  0x7f9ba0404eb6 in svm_msg_q_try_lock (mq=0x204009440)
at /home/ksekera/vpp/src/svm/message_queue.h:299
#7  0x7f9ba04055d5 in svm_msg_q_lock_and_alloc_msg_w_ring (mq=0x204009440,
ring_index=1, noblock=1 '\001', msg=0x7f9b5f7c2a80)
at /home/ksekera/vpp/src/svm/message_queue.c:121
#8  0x7f9ba14be449 in mq_try_lock_and_alloc_msg (app_mq=0x204009440,
msg=0x7f9b5f7c2a80) at /home/ksekera/vpp/src/vnet/session/session_api.c:407
#9  0x7f9ba14be509 in mq_send_session_accepted_cb (s=0x7f9b60351400)
at /home/ksekera/vpp/src/vnet/session/session_api.c:432
#10 0x7f9ba1496ba0 in application_local_session_connect (
client_wrk=0x7f9b60805800, server_wrk=0x7f9b60805780, ll=0x7f9b5f4c9e40,
opaque=0) at /home/ksekera/vpp/src/vnet/session/application.c:1646
#11 0x7f9ba14a5a62 in application_connect (a=0x7f9b5f7c2d30)
at /home/ksekera/vpp/src/vnet/session/application_interface.c:327
---Type  to continue, or q  to quit---
#12 0x7f9ba14a69fd in vnet_connect (a=0x7f9b5f7c2d30)
at /home/ksekera/vpp/src/vnet/session/application_interface.c:673
#13 0x7f9ba14c0f27 in vl_api_connect_sock_t_handler (mp=0x1300a6218)
at /home/ksekera/vpp/src/vnet/session/session_api.c:1305
#14 0x7f9ba1b6cb25 in vl_msg_api_handler_with_vm_node (
am=0x7f9ba1d7dc60 , the_msg=0x1300a6218,
vm=0x7f9ba08fc2c0 , node=0x7f9b5f7ba000)
at /home/ksekera/vpp/src/vlibapi/api_shared.c:502
#15 0x7f9ba1b39114 in void_mem_api_handle_msg_i (
am=0x7f9ba1d7dc60 , vm=0x7f9ba08fc2c0 ,
node=0x7f9b5f7ba000, q=0x13004c440)
at /home/ksekera/vpp/src/vlibmemory/memory_api.c:700
#16 0x7f9ba1b39183 in vl_mem_api_handle_msg_main (
vm=0x7f9ba08fc2c0 , node=0x7f9b5f7ba000)
at /home/ksekera/vpp/src/vlibmemory/memory_api.c:710
#17 0x7f9ba1b572dd in vl_api_clnt_process (
vm=0x7f9ba08fc2c0 , node=0x7f9b5f7ba000, f=0x0)
at /home/ksekera/vpp/src/vlibmemory/vlib_api.c:350
#18 0x7f9ba0674a11 in vlib_process_bootstrap (_a=140305300978672)
at /home/ksekera/vpp/src/vlib/main.c:1276
#19 0x7f9b9fef4e74 in clib_calljmp ()
   from 
/home/ksekera/vpp/build-root/install-vpp_debug-native/vpp/lib/libvppinfra.so.19.01

could this be the result of a timeout and the killing of the child
process?

Thanks,
Klement


Quoting Dave Wallace (2018-11-15 20:27:55)

   Klement,

   I just pulled the top-of-tree on master and ran only VCL tests on my 18.04
   box and they all passed 

[vpp-dev] [FD.io Helpdesk #63805] FD.io compute infra down -

[Vanessa Valderrama via RT]

Maciek,

We're looking into this now. 

On Fri Nov 16 09:02:19 2018, mackonstan wrote:
> Nexus(?) backend to nginx is reporting down.
> Resolution time?
> 
> Cheers,
> -Maciek
> 
> [cid:876751CF-C733-46B9-9A07-8298C0A0A0C8@cisco.com]



-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#11292): https://lists.fd.io/g/vpp-dev/message/11292
Mute This Topic: https://lists.fd.io/mt/28168082/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[vpp-dev] [FD.io Helpdesk #63805] FD.io compute infra down -

[Vanessa Valderrama via RT]

Apparently, we have an issue with an upstream network provider which is 
impacting some of our CI services.

We're working on getting more information including an ETA if possible. I'll 
send a notification to the community as well.

Thank you,
Vanessa


On Fri Nov 16 10:18:59 2018, valderrv wrote:
> Maciek,
> 
> We're looking into this now. 
> 
> On Fri Nov 16 09:02:19 2018, mackonstan wrote:
> > Nexus(?) backend to nginx is reporting down.
> > Resolution time?
> > 
> > Cheers,
> > -Maciek
> > 
> > [cid:876751CF-C733-46B9-9A07-8298C0A0A0C8@cisco.com]
> 
> 



-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#11293): https://lists.fd.io/g/vpp-dev/message/11293
Mute This Topic: https://lists.fd.io/mt/28168083/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] test-ext failures seen on master

[Florin Coras]

I also noticed that although it shouldn’t be different from the vcl test apps 
which seem to be properly killed on test failure. Anyway, it’s on my todo list, 
if nobody beats me to it.

Florin

> On Nov 16, 2018, at 5:27 AM, Klement Sekera  wrote:
> 
> I've also noticed that quite often a binary called sock_test_client is
> left running after a vpp crash or test failure. What's worse, it eats
> 100% CPU.
> 
> Quoting Florin Coras (2018-11-16 00:40:06)
>>   Thanks, Dave!
>>   I’ll take a look at those as soon as I can. I’m running multiple
>>   connections between 2 vpp hosts without issue, so it’s either a
>>   cut-through session issue or it has to do with how we setup vpp for vrf
>>   leaking. 
>>   Cheers,
>>   Florin
>> 
>> On Nov 15, 2018, at 3:00 PM, Dave Wallace <[1]dwallac...@gmail.com>
>> wrote:
>> Same here.  However, in the same workspace where all tests passed, I can
>> get this test case to fail consistently:
>> 
>> EXTENDED_TESTS=y TEST=vcl.VCLThruHostStackExtendedBTestCase.* make test
>> EXTENDED_TESTS=y TEST=vcl.VCLIpv6ThruHostStackExtendedBTestCase.* make
>> test
>> 
>> In patch 13215, I discovered that making these test cases NOT run
>> multiple sockets in parallel the test passes.  My latest patch to that
>> has the multiple sockets option commented out with "# ouch! Host Stack
>> Bug?" so that all tests pass.
>> 
>> Thanks,
>> -daw-
>> On 11/15/2018 4:16 PM, Florin Coras wrote:
>> 
>> That’s an interesting failure. Is the test machine running out of memory?
>> 
>> The extended tests are unstable on my server, so I do see quite a number of 
>> failures. However this:
>> 
>> make test-ext TEST=vcl.VCLCutThruTestCase.test_vcl_cut_thru_uni_dir_nsock
>> 
>> runs just fine. After the latest test framework changes, are we running 
>> multiple tests/vpps in parallel? I suspect that may be a source of issues.
>> 
>> Florin
>> 
>> 
>> On Nov 15, 2018, at 12:11 PM, Klement Sekera via Lists.Fd.Io 
>> [2] wrote:
>> 
>> I'm seeing timeouts and coredumps...
>> 
>> e.g.
>> 
>> #6  0x7f9ba0404eb6 in svm_msg_q_try_lock (mq=0x204009440)
>> at /home/ksekera/vpp/src/svm/message_queue.h:299
>> 299   return pthread_mutex_trylock (>q->mutex);
>> (gdb) p mq
>> $1 = (svm_msg_q_t *) 0x204009440
>> (gdb) p mq->q
>> $2 = (svm_queue_t *) 0x0
>> 
>> which is part of
>> 
>> #4  
>> #5  __pthread_mutex_trylock (mutex=0x0) at ../nptl/pthread_mutex_trylock.c:39
>> #6  0x7f9ba0404eb6 in svm_msg_q_try_lock (mq=0x204009440)
>>at /home/ksekera/vpp/src/svm/message_queue.h:299
>> #7  0x7f9ba04055d5 in svm_msg_q_lock_and_alloc_msg_w_ring 
>> (mq=0x204009440,
>>ring_index=1, noblock=1 '\001', msg=0x7f9b5f7c2a80)
>>at /home/ksekera/vpp/src/svm/message_queue.c:121
>> #8  0x7f9ba14be449 in mq_try_lock_and_alloc_msg (app_mq=0x204009440,
>>msg=0x7f9b5f7c2a80) at 
>> /home/ksekera/vpp/src/vnet/session/session_api.c:407
>> #9  0x7f9ba14be509 in mq_send_session_accepted_cb (s=0x7f9b60351400)
>>at /home/ksekera/vpp/src/vnet/session/session_api.c:432
>> #10 0x7f9ba1496ba0 in application_local_session_connect (
>>client_wrk=0x7f9b60805800, server_wrk=0x7f9b60805780, ll=0x7f9b5f4c9e40,
>>opaque=0) at /home/ksekera/vpp/src/vnet/session/application.c:1646
>> #11 0x7f9ba14a5a62 in application_connect (a=0x7f9b5f7c2d30)
>>at /home/ksekera/vpp/src/vnet/session/application_interface.c:327
>> ---Type  to continue, or q  to quit---
>> #12 0x7f9ba14a69fd in vnet_connect (a=0x7f9b5f7c2d30)
>>at /home/ksekera/vpp/src/vnet/session/application_interface.c:673
>> #13 0x7f9ba14c0f27 in vl_api_connect_sock_t_handler (mp=0x1300a6218)
>>at /home/ksekera/vpp/src/vnet/session/session_api.c:1305
>> #14 0x7f9ba1b6cb25 in vl_msg_api_handler_with_vm_node (
>>am=0x7f9ba1d7dc60 , the_msg=0x1300a6218,
>>vm=0x7f9ba08fc2c0 , node=0x7f9b5f7ba000)
>>at /home/ksekera/vpp/src/vlibapi/api_shared.c:502
>> #15 0x7f9ba1b39114 in void_mem_api_handle_msg_i (
>>am=0x7f9ba1d7dc60 , vm=0x7f9ba08fc2c0 ,
>>node=0x7f9b5f7ba000, q=0x13004c440)
>>at /home/ksekera/vpp/src/vlibmemory/memory_api.c:700
>> #16 0x7f9ba1b39183 in vl_mem_api_handle_msg_main (
>>vm=0x7f9ba08fc2c0 , node=0x7f9b5f7ba000)
>>at /home/ksekera/vpp/src/vlibmemory/memory_api.c:710
>> #17 0x7f9ba1b572dd in vl_api_clnt_process (
>>vm=0x7f9ba08fc2c0 , node=0x7f9b5f7ba000, f=0x0)
>>at /home/ksekera/vpp/src/vlibmemory/vlib_api.c:350
>> #18 0x7f9ba0674a11 in vlib_process_bootstrap (_a=140305300978672)
>>at /home/ksekera/vpp/src/vlib/main.c:1276
>> #19 0x7f9b9fef4e74 in clib_calljmp ()
>>   from 
>> /home/ksekera/vpp/build-root/install-vpp_debug-native/vpp/lib/libvppinfra.so.19.01
>> 
>> could this be the result of a timeout and the killing of the child
>> process?
>> 
>> Thanks,
>> Klement
>> 
>> 
>> Quoting Dave Wallace (2018-11-15 20:27:55)
>> 
>>   Klement,
>> 
>>   I just pulled the top-of-tree on master and ran only 

Re: [vpp-dev] Using clang-format ForEachMacros?

[Stephen Hemminger]

Ok. Thanks I didn't want to head down the dead end

On Fri, Nov 16, 2018, 2:09 AM Damjan Marion 
>
> > On 16 Nov 2018, at 02:02, Stephen Hemminger 
> wrote:
> >
> > I just discovered the clang-format file and noticed that Linux kernel
> used
> > the ForEachMacros option to format for() wrappers.
> >
> > VPP seems to be riddled with INDENT-OFF when it does vector loops. (2123
> times!)
> > Has anyone looked into replacing these with ForEachMacros?
>
> Yes, i looked into it, and found 2 big issues:
>
> - clang-format gnu mode produces different result than gnu indent so we
> will need to reformat whole repo
>
> - clang-format doesn't produce consistent output between 2 versions, which
> means mess every time we move to newer distro
>
> I looked into it 1+ yr ago, so things maybe changed, if yes we can
> reevaluate
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#11290): https://lists.fd.io/g/vpp-dev/message/11290
Mute This Topic: https://lists.fd.io/mt/28156993/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[vpp-dev] Enabling unit tests in VPP job for ARM and make test failures

[Juraj Linkeš]

Hi vpp-dev,

As many of you already know, we tried enabling unit tests in ARM VPP jobs the 
last release cycle, but we only managed to fix all make test failures during 
release procedures and we agreed that enabling it would be better after 1810 is 
released.

Enabling the unit testing (i.e. running full make verify) when there are 
failures is, in my opinion, a fool's errand. If people see consistent failures 
that are not related to their patches, they're much less likely to investigate 
whether this time there's really a legitimate failure and more likely to just 
ignore the job since it's just not working. That means we'll really need to 
iron out all of the failures before doing anything else.

So let's talk about the failures. There were new failures in master almost 
immediately after the release and these are seemingly also reproducible on x86 
(although I have no idea why they don't show up in CI):

*VPP-1475 - IP4 random reassembly 
failure

*VPP-1476 - L2fib missing packets

Not long after these issues, new issues cropped up. At one point even the 
sanity test didn't pass (that was addressed by 
https://gerrit.fd.io/r/#/c/15841/, thanks, Neale!) and there was an issue with 
sessions tests (fixed by https://gerrit.fd.io/r/#/c/15947/, thanks, Florin!). 
But there are still more issues that need our attention:

*VPP-1490 - Looks like traffic 
isn't working on ARM on Ubuntu1604

*VPP-1491 - GBD l2 endpoint 
learning. The tests actually pass with the debug build

*VPP-1497 - Parallel test execution 
on ARM produced many more failures. I haven't investigated this much yet

*And there is a new failure in a CDP test, this is not in Jira yet 
(there are some problems with accessing stuff in lab, curses!)

This very much seems like a game of whack-a-mole - we fix a few issues and new 
appear right away. This might suggest that the current approach of me finding 
issues on an ARM server and then notifying vpp-dev might not be ideal if we 
want to enable unit testing in 1901 (and we really do! :)). Or maybe this is 
not the right time to enable testing and we should focus on it more a few weeks 
before release? What's the best way to ensure that we'll get testing in as soon 
as possible?

In any case, we'll need a lot of help from you. I urge everyone (or at least a 
few key people) to get access to the FD.io lab (you'll need a GPG key that Ed 
Warnicke or some other trusted anchor will sign and then request access using 
the fd.io helpdesk) so that you can use our hardware we're reserved for this 
purpose. We could also always debug via a call, but that's just not efficient 
and you'll need some ARM hardware for development anyway (or to just fix issues 
that show up in verify jobs).

When it comes to the individual issues, any feedback is appreciated, like just 
the author acknowledging the issue and maybe adding whether they have time to 
look at it or what more information they need.

Let's make VPP development much more smoother for ARM ASAP, guys. :)

Thanks,
Juraj
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#11289): https://lists.fd.io/g/vpp-dev/message/11289
Mute This Topic: https://lists.fd.io/mt/28167603/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] About FRR(fast re-routing)

[Ole Troan]

> We do not support FRR, nor is there currently a plan to.

Although you can run FRR with VPP.
https://github.com/FRRouting/frr/wiki/Alternate-forwarding-planes:-VPP

Cheers,
Ole

>  
> However, if your label/tunnel/route has only one path, you can achieve a 
> similar result to FRR by installing the primary path with a better (lower) 
> preference to the backup path. VPP will then cutover when the primary path 
> goes down.
>  
> /neale
>  
> De :  au nom de 倪宝景 
> Date : vendredi 16 novembre 2018 à 09:34
> À : "vpp-dev@lists.fd.io" 
> Objet : [vpp-dev] About FRR(fast re-routing)
>  
> Dear Mr/Miss/Ms ：
>  I am Baojing Ni, working in FIBERHOME TELECOMMUNICATION TECHNOLOGIES Co.,Ltd
>  I have a question to consult :
>  Do you have the plan about FRR（fast re-routing） MPLS traffic engineering in 
> VPP ?
>  
> I am looking forward for your answers. 
> Thank you.
>  
> --
>  
>  
> 
> 
> 
>  
> 
> -=-=-=-=-=-=-=-=-=-=-=-
> Links: You receive all messages sent to this group.
> 
> View/Reply Online (#11287): https://lists.fd.io/g/vpp-dev/message/11287
> Mute This Topic: https://lists.fd.io/mt/28165403/675193
> Group Owner: vpp-dev+ow...@lists.fd.io
> Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub  [otr...@employees.org]
> -=-=-=-=-=-=-=-=-=-=-=-

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#11288): https://lists.fd.io/g/vpp-dev/message/11288
Mute This Topic: https://lists.fd.io/mt/28165403/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] About FRR(fast re-routing)

[Neale Ranns via Lists.Fd.Io]

Hi,

We do not support FRR, nor is there currently a plan to.

However, if your label/tunnel/route has only one path, you can achieve a 
similar result to FRR by installing the primary path with a better (lower) 
preference to the backup path. VPP will then cutover when the primary path goes 
down.

/neale

De :  au nom de 倪宝景 
Date : vendredi 16 novembre 2018 à 09:34
À : "vpp-dev@lists.fd.io" 
Objet : [vpp-dev] About FRR(fast re-routing)

Dear 
Mr/Miss/Ms
 ：
 I am Baojing Ni, working in FIBERHOME TELECOMMUNICATION TECHNOLOGIES Co.,Ltd
 I have a question to consult :
 Do you have the plan about FRR（fast re-routing） MPLS traffic engineering in 
VPP ?

I am looking forward for your answers.
Thank you.

--







-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#11287): https://lists.fd.io/g/vpp-dev/message/11287
Mute This Topic: https://lists.fd.io/mt/28165403/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[vpp-dev] FD.io compute infra down -

[Maciek Konstantynowicz (mkonstan) via Lists.Fd.Io]

Nexus(?) backend to nginx is reporting down.
Resolution time?

Cheers,
-Maciek

[cid:876751CF-C733-46B9-9A07-8298C0A0A0C8@cisco.com]
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#11286): https://lists.fd.io/g/vpp-dev/message/11286
Mute This Topic: https://lists.fd.io/mt/28166437/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 Load Balancer

[erenogluesin]

[Edited Message Follows]

Hello eveyone,
I need some information about VPP. I have a server side and client side. Also I 
use VPP as load balancer. When client send request to server, server view load 
baloancer(VPP)' s IP address but * I want to view client's IP* that send 
request to server. I use load balancer plugin. Is it possible to using with 
TOA(TCP Option Adress) or something else? I need this information as soon as 
possible. Have a nice day!
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#11284): https://lists.fd.io/g/vpp-dev/message/11284
Mute This Topic: https://lists.fd.io/mt/28165741/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] test-ext failures seen on master

[Klement Sekera via Lists.Fd.Io]

I've also noticed that quite often a binary called sock_test_client is
left running after a vpp crash or test failure. What's worse, it eats
100% CPU.

Quoting Florin Coras (2018-11-16 00:40:06)
>Thanks, Dave!
>I’ll take a look at those as soon as I can. I’m running multiple
>connections between 2 vpp hosts without issue, so it’s either a
>cut-through session issue or it has to do with how we setup vpp for vrf
>leaking. 
>Cheers,
>Florin
> 
>  On Nov 15, 2018, at 3:00 PM, Dave Wallace <[1]dwallac...@gmail.com>
>  wrote:
>  Same here.  However, in the same workspace where all tests passed, I can
>  get this test case to fail consistently:
> 
>  EXTENDED_TESTS=y TEST=vcl.VCLThruHostStackExtendedBTestCase.* make test
>  EXTENDED_TESTS=y TEST=vcl.VCLIpv6ThruHostStackExtendedBTestCase.* make
>  test
> 
>  In patch 13215, I discovered that making these test cases NOT run
>  multiple sockets in parallel the test passes.  My latest patch to that
>  has the multiple sockets option commented out with "# ouch! Host Stack
>  Bug?" so that all tests pass.
> 
>  Thanks,
>  -daw-
>  On 11/15/2018 4:16 PM, Florin Coras wrote:
> 
>  That’s an interesting failure. Is the test machine running out of memory?
> 
>  The extended tests are unstable on my server, so I do see quite a number of 
> failures. However this:
> 
>  make test-ext TEST=vcl.VCLCutThruTestCase.test_vcl_cut_thru_uni_dir_nsock
> 
>  runs just fine. After the latest test framework changes, are we running 
> multiple tests/vpps in parallel? I suspect that may be a source of issues.
> 
>  Florin
> 
> 
>  On Nov 15, 2018, at 12:11 PM, Klement Sekera via Lists.Fd.Io 
> [2] wrote:
> 
>  I'm seeing timeouts and coredumps...
> 
>  e.g.
> 
>  #6  0x7f9ba0404eb6 in svm_msg_q_try_lock (mq=0x204009440)
>  at /home/ksekera/vpp/src/svm/message_queue.h:299
>  299   return pthread_mutex_trylock (>q->mutex);
>  (gdb) p mq
>  $1 = (svm_msg_q_t *) 0x204009440
>  (gdb) p mq->q
>  $2 = (svm_queue_t *) 0x0
> 
>  which is part of
> 
>  #4  
>  #5  __pthread_mutex_trylock (mutex=0x0) at ../nptl/pthread_mutex_trylock.c:39
>  #6  0x7f9ba0404eb6 in svm_msg_q_try_lock (mq=0x204009440)
> at /home/ksekera/vpp/src/svm/message_queue.h:299
>  #7  0x7f9ba04055d5 in svm_msg_q_lock_and_alloc_msg_w_ring 
> (mq=0x204009440,
> ring_index=1, noblock=1 '\001', msg=0x7f9b5f7c2a80)
> at /home/ksekera/vpp/src/svm/message_queue.c:121
>  #8  0x7f9ba14be449 in mq_try_lock_and_alloc_msg (app_mq=0x204009440,
> msg=0x7f9b5f7c2a80) at 
> /home/ksekera/vpp/src/vnet/session/session_api.c:407
>  #9  0x7f9ba14be509 in mq_send_session_accepted_cb (s=0x7f9b60351400)
> at /home/ksekera/vpp/src/vnet/session/session_api.c:432
>  #10 0x7f9ba1496ba0 in application_local_session_connect (
> client_wrk=0x7f9b60805800, server_wrk=0x7f9b60805780, ll=0x7f9b5f4c9e40,
> opaque=0) at /home/ksekera/vpp/src/vnet/session/application.c:1646
>  #11 0x7f9ba14a5a62 in application_connect (a=0x7f9b5f7c2d30)
> at /home/ksekera/vpp/src/vnet/session/application_interface.c:327
>  ---Type  to continue, or q  to quit---
>  #12 0x7f9ba14a69fd in vnet_connect (a=0x7f9b5f7c2d30)
> at /home/ksekera/vpp/src/vnet/session/application_interface.c:673
>  #13 0x7f9ba14c0f27 in vl_api_connect_sock_t_handler (mp=0x1300a6218)
> at /home/ksekera/vpp/src/vnet/session/session_api.c:1305
>  #14 0x7f9ba1b6cb25 in vl_msg_api_handler_with_vm_node (
> am=0x7f9ba1d7dc60 , the_msg=0x1300a6218,
> vm=0x7f9ba08fc2c0 , node=0x7f9b5f7ba000)
> at /home/ksekera/vpp/src/vlibapi/api_shared.c:502
>  #15 0x7f9ba1b39114 in void_mem_api_handle_msg_i (
> am=0x7f9ba1d7dc60 , vm=0x7f9ba08fc2c0 ,
> node=0x7f9b5f7ba000, q=0x13004c440)
> at /home/ksekera/vpp/src/vlibmemory/memory_api.c:700
>  #16 0x7f9ba1b39183 in vl_mem_api_handle_msg_main (
> vm=0x7f9ba08fc2c0 , node=0x7f9b5f7ba000)
> at /home/ksekera/vpp/src/vlibmemory/memory_api.c:710
>  #17 0x7f9ba1b572dd in vl_api_clnt_process (
> vm=0x7f9ba08fc2c0 , node=0x7f9b5f7ba000, f=0x0)
> at /home/ksekera/vpp/src/vlibmemory/vlib_api.c:350
>  #18 0x7f9ba0674a11 in vlib_process_bootstrap (_a=140305300978672)
> at /home/ksekera/vpp/src/vlib/main.c:1276
>  #19 0x7f9b9fef4e74 in clib_calljmp ()
>from 
> /home/ksekera/vpp/build-root/install-vpp_debug-native/vpp/lib/libvppinfra.so.19.01
> 
>  could this be the result of a timeout and the killing of the child
>  process?
> 
>  Thanks,
>  Klement
> 
> 
>  Quoting Dave Wallace (2018-11-15 20:27:55)
> 
>Klement,
> 
>I just pulled the top-of-tree on master and ran only VCL tests on my 18.04
>box and they all passed (see below).  Another strange thing about your
>failure is that the test that failed is NOT an extended test.
> 
>I'm currently working on a patch ([1][3]https://gerrit.fd.io/r/#/c/13215/) 
> to
>shorten the run time for the 

[vpp-dev] VPP Load Balancer

[erenogluesin]

Hello eveyone,
I need some information about VPP. I have a server side and client side. Also I 
use VPP as load balancer. When client send request to server, server view load 
baloancer(VPP)' s IP address but * I want to view client's IP* that send 
request to server. I use load balancer plugin. Is it possible to using with 
TOA(TCP Option Adress) or something else? I need this information as soon as 
possible. Have a nice day!
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#11284): https://lists.fd.io/g/vpp-dev/message/11284
Mute This Topic: https://lists.fd.io/mt/28165741/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[vpp-dev] About FRR(fast re-routing)

[倪宝景]

Dear Mr/Miss/Ms ：
 I am Baojing Ni, working in FIBERHOME TELECOMMUNICATION TECHNOLOGIES Co.,Ltd
 I have a question to consult :
 Do you have the plan about FRR（fast re-routing） MPLS traffic engineering in 
VPP ?


I am looking forward for your answers. 
Thank you.


--




-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#11283): https://lists.fd.io/g/vpp-dev/message/11283
Mute This Topic: https://lists.fd.io/mt/28165403/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] Using clang-format ForEachMacros?

[Damjan Marion via Lists.Fd.Io]

> On 16 Nov 2018, at 02:02, Stephen Hemminger  
> wrote:
> 
> I just discovered the clang-format file and noticed that Linux kernel used
> the ForEachMacros option to format for() wrappers.
> 
> VPP seems to be riddled with INDENT-OFF when it does vector loops. (2123 
> times!)
> Has anyone looked into replacing these with ForEachMacros?

Yes, i looked into it, and found 2 big issues:

- clang-format gnu mode produces different result than gnu indent so we will 
need to reformat whole repo

- clang-format doesn't produce consistent output between 2 versions, which 
means mess every time we move to newer distro

I looked into it 1+ yr ago, so things maybe changed, if yes we can 
reevaluate -=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#11282): https://lists.fd.io/g/vpp-dev/message/11282
Mute This Topic: https://lists.fd.io/mt/28156993/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] Andrew Yourtchenko is now a vpp project committer!

[Marco Varlese]

Congratulations Andrew!!!

On Thu, 2018-11-15 at 16:43 +, Dave Barach via Lists.Fd.Io wrote:
> The TSC formally approved Andrew’s vpp committer nomination a short while ago.
>  
> Congratulations, and thanks in advance for your participation as a committer.
>  
> Dave
>  
> 
> -=-=-=-=-=-=-=-=-=-=-=-
> Links: You receive all messages sent to this group.
> 
> View/Reply Online (#11261): 
> https://lists.fd.io/g/vpp-dev/message/11261
> 
> Mute This Topic: 
> https://lists.fd.io/mt/28147575/675056
> 
> Group Owner: 
> vpp-dev+ow...@lists.fd.io
> 
> Unsubscribe: 
> https://lists.fd.io/g/vpp-dev/unsub
>   [
> mvarl...@suse.de
> ]
> -=-=-=-=-=-=-=-=-=-=-=-

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#11281): https://lists.fd.io/g/vpp-dev/message/11281
Mute This Topic: https://lists.fd.io/mt/28147575/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] Using clang-format ForEachMacros?

[Klement Sekera via Lists.Fd.Io]

clang can format the macros just fine as they are. I added clang for
checking the style of c++ code (mainly vapi code). C files are still
checked using indent, which doesn't understand the macros ... Also I
wasn't able to come up with a clang-format which matches the current
indent style 1:1 so I don't see a switch to clang-format coming any time
soon...

Thanks,
Klement

Quoting Stephen Hemminger (2018-11-16 02:02:55)
> I just discovered the clang-format file and noticed that Linux kernel used
> the ForEachMacros option to format for() wrappers.
> 
> VPP seems to be riddled with INDENT-OFF when it does vector loops. (2123 
> times!)
> Has anyone looked into replacing these with ForEachMacros?
> 
> 
> -=-=-=-=-=-=-=-=-=-=-=-
> Links: You receive all messages sent to this group.
> 
> View/Reply Online (#11274): https://lists.fd.io/g/vpp-dev/message/11274
> Mute This Topic: https://lists.fd.io/mt/28156993/675704
> Group Owner: vpp-dev+ow...@lists.fd.io
> Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub  [ksek...@cisco.com]
> -=-=-=-=-=-=-=-=-=-=-=-
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#11280): https://lists.fd.io/g/vpp-dev/message/11280
Mute This Topic: https://lists.fd.io/mt/28156993/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] test-ext failures seen on master

[Klement Sekera via Lists.Fd.Io]

No, it's on my laptop and out of 16g mem, 11g is caches so there
shouldn't be any OOM issue there.

Unless you change TEST_JOBS option (setting it to either auto or ), the test framework still runs 1 job at a time.

Klement

Quoting Florin Coras (2018-11-15 22:16:05)
> That’s an interesting failure. Is the test machine running out of memory?
> 
> The extended tests are unstable on my server, so I do see quite a number of 
> failures. However this:
> 
> make test-ext TEST=vcl.VCLCutThruTestCase.test_vcl_cut_thru_uni_dir_nsock
> 
> runs just fine. After the latest test framework changes, are we running 
> multiple tests/vpps in parallel? I suspect that may be a source of issues. 
> 
> Florin
> 
> > On Nov 15, 2018, at 12:11 PM, Klement Sekera via Lists.Fd.Io 
> >  wrote:
> > 
> > I'm seeing timeouts and coredumps...
> > 
> > e.g.
> > 
> > #6  0x7f9ba0404eb6 in svm_msg_q_try_lock (mq=0x204009440)
> > at /home/ksekera/vpp/src/svm/message_queue.h:299
> > 299   return pthread_mutex_trylock (>q->mutex);
> > (gdb) p mq
> > $1 = (svm_msg_q_t *) 0x204009440
> > (gdb) p mq->q
> > $2 = (svm_queue_t *) 0x0
> > 
> > which is part of
> > 
> > #4  
> > #5  __pthread_mutex_trylock (mutex=0x0) at 
> > ../nptl/pthread_mutex_trylock.c:39
> > #6  0x7f9ba0404eb6 in svm_msg_q_try_lock (mq=0x204009440)
> >at /home/ksekera/vpp/src/svm/message_queue.h:299
> > #7  0x7f9ba04055d5 in svm_msg_q_lock_and_alloc_msg_w_ring 
> > (mq=0x204009440, 
> >ring_index=1, noblock=1 '\001', msg=0x7f9b5f7c2a80)
> >at /home/ksekera/vpp/src/svm/message_queue.c:121
> > #8  0x7f9ba14be449 in mq_try_lock_and_alloc_msg (app_mq=0x204009440, 
> >msg=0x7f9b5f7c2a80) at 
> > /home/ksekera/vpp/src/vnet/session/session_api.c:407
> > #9  0x7f9ba14be509 in mq_send_session_accepted_cb (s=0x7f9b60351400)
> >at /home/ksekera/vpp/src/vnet/session/session_api.c:432
> > #10 0x7f9ba1496ba0 in application_local_session_connect (
> >client_wrk=0x7f9b60805800, server_wrk=0x7f9b60805780, ll=0x7f9b5f4c9e40, 
> >opaque=0) at /home/ksekera/vpp/src/vnet/session/application.c:1646
> > #11 0x7f9ba14a5a62 in application_connect (a=0x7f9b5f7c2d30)
> >at /home/ksekera/vpp/src/vnet/session/application_interface.c:327
> > ---Type  to continue, or q  to quit---
> > #12 0x7f9ba14a69fd in vnet_connect (a=0x7f9b5f7c2d30)
> >at /home/ksekera/vpp/src/vnet/session/application_interface.c:673
> > #13 0x7f9ba14c0f27 in vl_api_connect_sock_t_handler (mp=0x1300a6218)
> >at /home/ksekera/vpp/src/vnet/session/session_api.c:1305
> > #14 0x7f9ba1b6cb25 in vl_msg_api_handler_with_vm_node (
> >am=0x7f9ba1d7dc60 , the_msg=0x1300a6218, 
> >vm=0x7f9ba08fc2c0 , node=0x7f9b5f7ba000)
> >at /home/ksekera/vpp/src/vlibapi/api_shared.c:502
> > #15 0x7f9ba1b39114 in void_mem_api_handle_msg_i (
> >am=0x7f9ba1d7dc60 , vm=0x7f9ba08fc2c0 , 
> >node=0x7f9b5f7ba000, q=0x13004c440)
> >at /home/ksekera/vpp/src/vlibmemory/memory_api.c:700
> > #16 0x7f9ba1b39183 in vl_mem_api_handle_msg_main (
> >vm=0x7f9ba08fc2c0 , node=0x7f9b5f7ba000)
> >at /home/ksekera/vpp/src/vlibmemory/memory_api.c:710
> > #17 0x7f9ba1b572dd in vl_api_clnt_process (
> >vm=0x7f9ba08fc2c0 , node=0x7f9b5f7ba000, f=0x0)
> >at /home/ksekera/vpp/src/vlibmemory/vlib_api.c:350
> > #18 0x7f9ba0674a11 in vlib_process_bootstrap (_a=140305300978672)
> >at /home/ksekera/vpp/src/vlib/main.c:1276
> > #19 0x7f9b9fef4e74 in clib_calljmp ()
> >   from 
> > /home/ksekera/vpp/build-root/install-vpp_debug-native/vpp/lib/libvppinfra.so.19.01
> > 
> > could this be the result of a timeout and the killing of the child
> > process?
> > 
> > Thanks,
> > Klement
> > 
> > 
> > Quoting Dave Wallace (2018-11-15 20:27:55)
> >>   Klement,
> >> 
> >>   I just pulled the top-of-tree on master and ran only VCL tests on my 
> >> 18.04
> >>   box and they all passed (see below).  Another strange thing about your
> >>   failure is that the test that failed is NOT an extended test.
> >> 
> >>   I'm currently working on a patch ([1]https://gerrit.fd.io/r/#/c/13215/) 
> >> to
> >>   shorten the run time for the extended tests and convert them to regular
> >>   tests.  In the past, I have seen some unexplained failures of some of the
> >>   extended tests.  I'll let you know if I encounter any of them again.
> >> 
> >>   Thanks,
> >>   -daw-
> >> 
> >>   - %< -
> >>   TEST=vcl.* make test-ext
> >>   . . .
> >>   make[2]: Leaving directory '/scratch/dwallacelf/lf/vpp/test/ext'
> >>   
> >> ==
> >>   Sanity test case - verify if VPP is able to start
> >>   
> >> ==
> >>   Running tests using custom test runner
> >>   Active filters: file=test_vcl.py, class=None, function=None
> >>   Adding tests from directory tree /scratch/dwallacelf/lf/vpp/test
> >>   28 out of 858 tests match specified 

[vpp-dev] NAT44 && VXLAN tunnel && ip reassembly && ip frag can not work correctly at vpp stable/1810

[王传国]

Hi all,
ping 192.168.123.2 -s 6000  from 192.168.123.3 that out of remote 
vxlan-tunnel-endpoint failed when the NAT44 config was added!
And not NAT44 -> correct;   add NAT44 -> faild!

Who can help? Maybe, this is a bug.
#
set int state TenGigabitEthernet6/0/0 up
set int ip addr TenGigabitEthernet6/0/0 172.16.0.3/24

create bridge-domain 11 learn 1 forward 1 uu-flood 1 flood 1 arp-term 1
loopback create
set int l2 bridge loop0 11 bvi
set int ip address loop0 192.168.123.1/24
set int state loop0 up

tap connect lstack address 192.168.123.2/24
set int l2 bridge tapcli-0 11
set int state tapcli-0 up

nat44 add interface address TenGigabitEthernet6/0/0
set interface nat44 in loop0 out TenGigabitEthernet6/0/0
nat44 add static mapping local 192.168.123.2 22 external 
TenGigabitEthernet6/0/0 22 tcp
nat44 forwarding enable



王传国

山东华辰泰尔信息科技股份有限公司 研发中心
电话：0531-62325309 88877658-8019
手机：18615184689
传真：0531-88870859
网址：http://www.huachentel.com
地址：山东省济南市高新区舜华路2000号舜泰广场8号楼西区17层
邮编：250101
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#11277): https://lists.fd.io/g/vpp-dev/message/11277
Mute This Topic: https://lists.fd.io/mt/28164668/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-