Re: [vpp-dev] periodical build failure of external dependency ipsec-mb

[Neale Ranns]

Hi Laszlo,

As Stanislav said, probably not enough RAM on your box to handle the build 
parallelism. On subsequent runs, once some files are compiled, the parallelism 
drops and the build will pass.

/neale

From: vpp-dev@lists.fd.io  on behalf of Stanislav Zaikin 
via lists.fd.io 
Date: Monday, 13 February 2023 at 21:59
To: vpp-dev@lists.fd.io 
Subject: Re: [vpp-dev] periodical build failure of external dependency ipsec-mb
Hi Laszlo,

Have you checked the system's logs? It might be killed by an out-of-memory 
killer.

On Mon, 13 Feb 2023 at 11:45, Laszlo Király  wrote:
Hello,

Time to time our automated build fails during ipsec-mb external dependency. It 
is not a constant failure, usually passing for second run.
The failure have been seen on vpp versions  22.06 and 22.04.

--- building ipsec-mb 1.1 - log: /vpp/build/external/rpm/tmp/ipsec-mb.build.log
[91mmake[4]: *** [Makefile:791: obj/aes256_gcm_by48_api_vaes_avx512.o] Killed

Seems to me like the nasm (nasm 2.14.02) target is not ready when the gcc tries 
to use it as source. It can be some nasty dependency or timing issue in 
ipsec-mb build.

Did you faced similar phenomenon?

--
Thanks,
Laszlo Kiraly





--
Best regards
Stanislav Zaikin

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#22595): https://lists.fd.io/g/vpp-dev/message/22595
Mute This Topic: https://lists.fd.io/mt/96933164/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/leave/1480452/21656/631435203/xyzzy 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [vpp-dev] veth alternative in VPP

[Neale Ranns]

I’d suggest a pipe, each end can be in a different VRF. See 
src/scripts/vnet/ipsec for a config example.

/neale

From: vpp-dev@lists.fd.io  on behalf of Benoit Ganne 
(bganne) via lists.fd.io 
Date: Thursday, 5 January 2023 at 00:18
To: vpp-dev@lists.fd.io 
Subject: Re: [vpp-dev] veth alternative in VPP
> Hi, I am looking for veth pair alternative in VPP. I want to pass traffics
> between two VRFs and I want them to be processed as input packets to an
> interface( to use NAT or other ip features), so route leakage is not gonna
> help. Also, since I'm using one instance of VPP with multiple VRFs, using
> memifs are not viable. Are there any methods in VPP to achieve the same
> goal?

You can use loopback or pipe interfaces for this.

Best
ben

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#22415): https://lists.fd.io/g/vpp-dev/message/22415
Mute This Topic: https://lists.fd.io/mt/96048462/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/leave/1480452/21656/631435203/xyzzy 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [vpp-dev] Procedure to send API from VPP to agent based on event

[Neale Ranns]

Hi Alok,

There are a few examples of these sort of “want” APIs. For example, from 
src/vnet/interface.api:
service {
  rpc want_interface_events returns want_interface_events_reply
events sw_interface_event;
};


/neale

From: vpp-dev@lists.fd.io  on behalf of Alok Tiwari via 
lists.fd.io 
Date: Thursday, 15 December 2022 at 17:22
To: vpp-dev@lists.fd.io 
Subject: [vpp-dev] Procedure to send API from VPP to agent based on event
Hi Folks,
I understand that VPP handles two types of API exchanges

1.   There is a simple "request and reply" type.
2.   The second type of message exchange is a "dump" request and a repeated 
reply message in the form of multiple "details".

In our case, I have a requirement to send some event based information from VPP 
to the agent without any request from the agent.  Please guide how I can 
achieve this through VPP.

Regards,
Alok

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#22340): https://lists.fd.io/g/vpp-dev/message/22340
Mute This Topic: https://lists.fd.io/mt/95684042/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/leave/1480452/21656/631435203/xyzzy 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [vpp-dev] There is bug in esp decrypt

[Neale Ranns]

A SA is in-use if it is referred to by a policy. Remove it from the policy and 
no more traffic will use it. If you’re doing that with the workers running, 
then wait one worker loop before deleting the SA.

/neale


From: vpp-dev@lists.fd.io  on behalf of jiangxiaoming via 
lists.fd.io 
Date: Monday, 21 November 2022 at 12:30
To: vpp-dev@lists.fd.io 
Subject: Re: [vpp-dev] There is bug in esp decrypt
Hi neale,
Currently there is only one way detecting whether the sa is in using by 
checking sa counter. But if the ike is timeout and is rekeying the  sa which 
first used by ipsec4-input-feature, the sa may has been deleted in esp_encrypt 
node.
I rewrite the ike plugin, in my test case, there are 10k ike sessions with 20k 
sa in ipsec layer, and the ike timeout is 30s sa rekey timeout is 10s. The 
esp_encrypt node crashed frequently.

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#3): https://lists.fd.io/g/vpp-dev/message/3
Mute This Topic: https://lists.fd.io/mt/95086868/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/leave/1480452/21656/631435203/xyzzy 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [vpp-dev] There is bug in esp decrypt

[Neale Ranns]

Deleting an SA that is in-use, should return an error and be prevented.

/neale


From: vpp-dev@lists.fd.io  on behalf of Guangming via 
lists.fd.io 
Date: Saturday, 19 November 2022 at 00:27
To: vpp-dev 
Subject: Re: [vpp-dev] There is bug in esp decrypt
I  got the same issue   when use cli  "ipsec sa del id"  delete sa that was 
used by esp  encrypt/decrypt


zhangguangm...@baicells.com

From: jiangxiaoming
Date: 2022-11-18 19:13
To: vpp-dev
Subject: Re: [vpp-dev] There is bug in esp decrypt

Hi neale,

The function ipsec_sa_get call in esp_encrypt_inline/esp_decrypt_inline has 
mem issue.
In ipsec4-input-feature node, vnet_buffer (b[0])->ipsec.sad_index was setted by 
sa,
but the sa maybe freed by main thread just after the node dispatch finish, the 
next dispatch loop the sa referenced by
vnet_buffer (b[0])->ipsec.sad_index become invalid and will cause memory issue 
in esp_encrypt_inline.
esp_decrypt/ah_encrypt/ah_decrpty all have same issue.
Below is the crash stack I got:

2: /root/code/net-base/.vpp-22.02/src/vnet/ipsec/ipsec_sa.h:649 (ipsec_sa_get) 
assertion `! pool_is_free (ipsec_sa_pool, _e)' fails

Program received signal SIGABRT, Aborted.
[Switching to Thread 0x7ffa38472700 (LWP 4067)]
0x735c11f7 in raise () from /lib64/libc.so.6
Missing separate debuginfos, use: debuginfo-install glibc-2.17-196.el7.x86_64 
libgcc-4.8.5-16.el7.x86_64 libpcap-1.5.3-12.el7.x86_64 
libstdc++-4.8.5-16.el7.x86_64 libuuid-2.23.2-43.el7.x86_64
(gdb)
(gdb) bt
#0  0x735c11f7 in raise () from /lib64/libc.so.6
#1  0x735c28e8 in abort () from /lib64/libc.so.6
#2  0x0040b31b in os_panic () at 
/root/code/net-base/.vpp-22.02/src/vpp/vnet/main.c:413
#3  0x73f081ff in debugger () at 
/root/code/net-base/.vpp-22.02/src/vppinfra/error.c:84
#4  0x73f088d5 in _clib_error (how_to_die=2, function_name=0x0, 
line_number=0, fmt=0x76a26380 "%s:%d (%s) assertion `%s' fails") at 
/root/code/net-base/.vpp-22.02/src/vppinfra/error.c:143
#5  0x75767800 in ipsec_sa_get (sa_index=24723) at 
/root/code/net-base/.vpp-22.02/src/vnet/ipsec/ipsec_sa.h:649
#6  0x7576f6ed in esp_encrypt_inline (vm=0x7ffefb476380, 
node=0x7ffefc5f5580, frame=0x7fff1cd85c80, lt=VNET_LINK_IP4, is_tun=0, 
async_next_node=1) at 
/root/code/net-base/.vpp-22.02/src/vnet/ipsec/esp_encrypt.c:661
#7  0x75773afe in esp4_encrypt_node_fn (vm=0x7ffefb476380, 
node=0x7ffefc5f5580, from_frame=0x7fff1cd85c80) at 
/root/code/net-base/.vpp-22.02/src/vnet/ipsec/esp_encrypt.c:1171
#8  0x7fffefc4f3ad in dispatch_pcap_trace (vm=0x7ffefb476380, 
node=0x7ffefc5f5580, frame=0x7fff1cd85c80) at 
/root/code/net-base/.vpp-22.02/src/plugins/dispatch-trace/main.c:210
#9  0x7475bb0d in dispatch_node (vm=0x7ffefb476380, 
node=0x7ffefc5f5580, type=VLIB_NODE_TYPE_INTERNAL, 
dispatch_state=VLIB_NODE_STATE_POLLING, frame=0x7fff1cd85c80, 
last_time_stamp=3114277064272384) at 
/root/code/net-base/.vpp-22.02/src/vlib/main.c:977
#10 0x7475cf25 in dispatch_pending_node (vm=0x7ffefb476380, 
pending_frame_index=0, last_time_stamp=3114277064272384) at 
/root/code/net-base/.vpp-22.02/src/vlib/main.c:1134
#11 0x74760dcc in vlib_main_or_worker_loop (vm=0x7ffefb476380, 
is_main=0) at /root/code/net-base/.vpp-22.02/src/vlib/main.c:1600
#12 0x74762594 in vlib_worker_loop (vm=0x7ffefb476380) at 
/root/code/net-base/.vpp-22.02/src/vlib/main.c:1734
#13 0x747b5e68 in vlib_worker_thread_fn (arg=0x7ffef0b822c0) at 
/root/code/net-base/.vpp-22.02/src/vlib/threads.c:1533
#14 0x73f32790 in clib_calljmp () at 
/root/code/net-base/.vpp-22.02/src/vppinfra/longjmp.S:123
#15 0x7ffa38471dd0 in ?? ()
#16 0x747a9820 in vlib_worker_thread_bootstrap_fn (arg=0x7ffef0b822c0) 
at /root/code/net-base/.vpp-22.02/src/vlib/threads.c:413
Backtrace stopped: previous frame inner to this frame (corrupt stack?)

Xiaoming

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#22208): https://lists.fd.io/g/vpp-dev/message/22208
Mute This Topic: https://lists.fd.io/mt/95086868/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/leave/1480452/21656/631435203/xyzzy 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [vpp-dev] There is bug in esp decrypt

[Neale Ranns]

https://gerrit.fd.io/r/c/vpp/+/37677

/neale

From: vpp-dev@lists.fd.io  on behalf of Guangming via 
lists.fd.io 
Date: Friday, 18 November 2022 at 13:55
To: vpp-dev 
Subject: Re: [vpp-dev] There is bug in esp decrypt
Thanks neale

 Guangming


zhangguangm...@baicells.com

From: Neale Ranns<mailto:ne...@graphiant.com>
Date: 2022-11-18 09:32
To: vpp-dev@lists.fd.io<mailto:vpp-dev@lists.fd.io>
Subject: Re: [vpp-dev] There is bug in esp decrypt
Hi,

I’ll push a patch with UT shortly.

Many thanks,
neale

From: vpp-dev@lists.fd.io  on behalf of jiangxiaoming via 
lists.fd.io 
Date: Friday, 18 November 2022 at 11:58
To: vpp-dev@lists.fd.io 
Subject: Re: [vpp-dev] There is bug in esp decrypt

Hi Guangming,
   You are right, you can push a patch to https://gerrit.fd.io/r , ipsec 
maintainers will review it

Xiaoming

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#22199): https://lists.fd.io/g/vpp-dev/message/22199
Mute This Topic: https://lists.fd.io/mt/95086868/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/leave/1480452/21656/631435203/xyzzy 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [vpp-dev] There is bug in esp decrypt

[Neale Ranns]

Hi,

I’ll push a patch with UT shortly.

Many thanks,
neale

From: vpp-dev@lists.fd.io  on behalf of jiangxiaoming via 
lists.fd.io 
Date: Friday, 18 November 2022 at 11:58
To: vpp-dev@lists.fd.io 
Subject: Re: [vpp-dev] There is bug in esp decrypt

Hi Guangming,
   You are right, you can push a patch to https://gerrit.fd.io/r , ipsec 
maintainers will review it

Xiaoming

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#22196): https://lists.fd.io/g/vpp-dev/message/22196
Mute This Topic: https://lists.fd.io/mt/95086868/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/leave/1480452/21656/631435203/xyzzy 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [vpp-dev] Move VNET features to plugins

[Neale Ranns]

Hi Dave,

I fully support pluginification 😊
Is it fair though to say that if the remaining functions of vnet have a 
dependency on one of the modules below then that module is not a good candidate 
to move to a plugin?

I thinking about the dependency between IPIP and TEIB. Some of the IPIP 
functionality (i.e. p2p tunnels) can be provided without TEIB but some cannot 
(i.e. p2mp tunnels).

  *   Any thoughts on infrastructure to ease plugin on plugin dependencies. For 
example I seem to recall a system that used a ‘registry’ that the producer 
would populate and the consumer would invoke and that invocation would be sane 
in the absence of a producer.
  *   How do we [unit] test the various combinations of loaded plugins? Perhaps 
the default is not to load any plugins and the test-case specifies which set to 
load.


/neale

From: vpp-dev@lists.fd.io  on behalf of Dave Wallace via 
lists.fd.io 
Date: Tuesday, 18 October 2022 at 08:57
To: vpp-dev 
Subject: [vpp-dev] Move VNET features to plugins
Folks,

There has been a long standing chore to move VNET features to plugins
for which I've created a Jira ticket [0] to coordinate getting this work
done for VPP 23.02 release.

Can the maintainers of the VNET features [1] please sign up for the
associated subtask in [0] and complete the work before the 23.02 RC1
milestone (01/18/2023).  It would be great to get this done before the
end of 2022 to avoid a large influx of changes in early January.

Thanks in advance for your help!
-daw-

[0] 
https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fjira.fd.io%2Fbrowse%2FVPP-2040&data=05%7C01%7Cneale%40graphiant.com%7C888ed5dcf8744e783a0708dab08a892d%7C162101cdceb34e62ab2e3abc7aeede47%7C0%7C0%7C638016406459814597%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=qtN1mKiFVnGYzcW3lAsg7%2FSFLd5%2Bl8NICwMuqrG0m1M%3D&reserved=0

[1] Current set of VNET features to be moved:
 BFD
 BIER
 CRYPTO
 GRE
 IPFIX-EXPORT
 IPIP
 IPSEC
 LAWFUL-INTERCEPT
 MPLS
 OSI
 POLICER
 PPP
 QOS
 SRMPLS
 SRV6
 TEIB
 TLS
 VXLAN
 VXLAN-GPE
 DEVICES:
 AF_PACKET
 PIPE
 TAP
 VIRTIO


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#22045): https://lists.fd.io/g/vpp-dev/message/22045
Mute This Topic: https://lists.fd.io/mt/94396253/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/leave/1480452/21656/631435203/xyzzy 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [vpp-dev] A question about fib-id with ip neighbor

[Neale Ranns]

Hi Huawei,

The fib-ID should be removed from the cmd’s help.

/neale

From: lihuawei 
Date: Friday, 14 October 2022 at 16:01
To: Neale Ranns , vpp-dev@lists.fd.io 
Subject: A question about fib-id with ip neighbor
Hi Neale&community,

As the following picture shows:
I have not see any support for the fib-id in the code, but fib-id is in cmd’s 
help.
Is the fib-id deleted before？Or it will to be add in the future?
Anyone knows about this, please help.
[cid:F10A2B2E-67EE-4C98-8F46-D025A877EDEE]


Thanks and Regards,
Huawei LI



-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#22028): https://lists.fd.io/g/vpp-dev/message/22028
Mute This Topic: https://lists.fd.io/mt/94321039/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/leave/1480452/21656/631435203/xyzzy 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [vpp-dev] Gerrit Review Id 37303

[Neale Ranns]

Hi Huawei,

Patch merged. Thank you.

/neale

From: vpp-dev@lists.fd.io  on behalf of lihuawei via 
lists.fd.io 
Date: Tuesday, 11 October 2022 at 13:17
To: vpp-dev@lists.fd.io 
Subject: [vpp-dev] Gerrit Review Id 37303
Hi community,

I have added a fix as gerrit review id 37303.

gerrit link: 
https://gerrit.fd.io/r/c/vpp/+/37303

short description: Vpp will crash when create vxlan/vxlan-gpe/geneve/gtpu 
tunnel with 
0.0.0.0
 dst ip in debug build. The ASSERT in fib_prefix_from_ip46_addr will raise 
crash under debug build, when create vxlan/vxlan-gpe/geneve/gtpu tunnel with 
0.0.0.0
 dst ip.

Please have a look at my patch and review it.

Thanks and Regards,
Huawei LI


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#21990): https://lists.fd.io/g/vpp-dev/message/21990
Mute This Topic: https://lists.fd.io/mt/94251382/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/leave/1480452/21656/631435203/xyzzy 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [vpp-dev] Combined statistics for all traffic mapped to a MPLS LSP path

[Neale Ranns]

Hi Mohit,

In which case to calculate the total amount of traffic sent over an LSP you 
should sum the counts of all IP and MPLS FIB entries that use/pint-to the LSP; 
i.e. those that have the output label of the LSP.

/neale

From: vpp-dev@lists.fd.io  on behalf of Gupta, Mohit via 
lists.fd.io 
Date: Tuesday, 11 October 2022 at 01:25
To: vpp-dev@lists.fd.io 
Subject: Re: [vpp-dev] Combined statistics for all traffic mapped to a MPLS LSP 
path
Hi Neale,

Thanks for your response.
We can install the LSP by configuring MPLS FIB and IP FIB. The detailed 
instructions are given concisely in
https://wiki.fd.io/view/VPP/MPLS_FIB<https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwiki.fd.io%2Fview%2FVPP%2FMPLS_FIB&data=05%7C01%7Cneale%40graphiant.com%7Cf1c6e1d385b04788145e08daaacb1c34%7C162101cdceb34e62ab2e3abc7aeede47%7C0%7C0%7C638010087047424430%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=IWiflLWZxVhezidnXbaEeNPrzIGvO3%2Fjj8eFXrg6bgs%3D&reserved=0>

Brief instructions on installing a LSP is as under :

1.   Configure Ingress LER to add a mpls label on incoming packets 
belonging to a FEC :

ip route add 1.1.1.1/32 via 10.10.10.10 GigE0/0/0 out-labels 33



2.   Configure transit/egress LSR to do one of following :

1)   Pop the label and perform an IPv[46] lookup in a specified table

2)   Pop the label and forward via a specified next-hop (this is 
penultimate-hop-pop, PHP)

3)   Swap the label and forward via a specified next-hop.

These can be programmed respectively by:

1)   mpls local-label 33 eos ip4-lookup-in-table X

2)   mpls local-label 33 [eos] via 10.10.10.10 GigE0/0/0

3)   mpls local-label 33 [eos] via 10.10.10.10 GigE0/0/0 out-labels 66


Regards,
Mohit

From: vpp-dev@lists.fd.io  On Behalf Of Neale Ranns
Sent: Friday, October 7, 2022 2:43 AM
To: vpp-dev@lists.fd.io
Subject: [**EXTERNAL**] Re: [vpp-dev] Combined statistics for all traffic 
mapped to a MPLS LSP path

Hi Mohit,

VPP doesn’t have a single object with stats that represents an LSP in its broad 
sense. You’ll have to combine the states from the objects that use/point-to the 
LSP (or rather use the out-going label value of the LSP) – for example IP or 
MPLS FIB entries, or MPLS tunnel interfaces, etc.

If you tell me how you install the LSP in VPP I can help further.

/neale

From: vpp-dev@lists.fd.io<mailto:vpp-dev@lists.fd.io> 
mailto:vpp-dev@lists.fd.io>> on behalf of Gupta, Mohit via 
lists.fd.io 
mailto:mohgupta=ciena@lists.fd.io>>
Date: Thursday, 6 October 2022 at 21:17
To: vpp-dev@lists.fd.io<mailto:vpp-dev@lists.fd.io> 
mailto:vpp-dev@lists.fd.io>>
Subject: [vpp-dev] Combined statistics for all traffic mapped to a MPLS LSP path
Hi Team,

I need to fetch all Rx/Tx statistics for all traffic that goes over a MPLS 
Label switched path, whether it is OAM/L2VPN/L3VPN etc.
Basically, we are creating a MPLS LSP using RSVP-TE.  Later other l2vpn/l3vpn 
services are enabled and mapped to the LSP.
We have MPLS tunnels in VPP for pseudowires, which can be used to fetch stats 
for l2vpn services.
I am looking for a way to fetch all the combined statistics for a given LSP 
path, irrespective of the service, mapped to it.
Is there a VPP construct or a segment in VPP enabling to fetch those stats.

Regards,
Mohit

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#21987): https://lists.fd.io/g/vpp-dev/message/21987
Mute This Topic: https://lists.fd.io/mt/94154561/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/leave/1480452/21656/631435203/xyzzy 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [vpp-dev] Combined statistics for all traffic mapped to a MPLS LSP path

[Neale Ranns]

Hi Mohit,

VPP doesn’t have a single object with stats that represents an LSP in its broad 
sense. You’ll have to combine the states from the objects that use/point-to the 
LSP (or rather use the out-going label value of the LSP) – for example IP or 
MPLS FIB entries, or MPLS tunnel interfaces, etc.

If you tell me how you install the LSP in VPP I can help further.

/neale

From: vpp-dev@lists.fd.io  on behalf of Gupta, Mohit via 
lists.fd.io 
Date: Thursday, 6 October 2022 at 21:17
To: vpp-dev@lists.fd.io 
Subject: [vpp-dev] Combined statistics for all traffic mapped to a MPLS LSP path
Hi Team,

I need to fetch all Rx/Tx statistics for all traffic that goes over a MPLS 
Label switched path, whether it is OAM/L2VPN/L3VPN etc.
Basically, we are creating a MPLS LSP using RSVP-TE.  Later other l2vpn/l3vpn 
services are enabled and mapped to the LSP.
We have MPLS tunnels in VPP for pseudowires, which can be used to fetch stats 
for l2vpn services.
I am looking for a way to fetch all the combined statistics for a given LSP 
path, irrespective of the service, mapped to it.
Is there a VPP construct or a segment in VPP enabling to fetch those stats.

Regards,
Mohit

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#21974): https://lists.fd.io/g/vpp-dev/message/21974
Mute This Topic: https://lists.fd.io/mt/94154561/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/leave/1480452/21656/631435203/xyzzy 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [vpp-dev] Insert Custom Node Into ip4-unicast Feature Arc

[Neale Ranns]

Hi Padraig,

From: vpp-dev@lists.fd.io  on behalf of Pádraig Connolly 
via lists.fd.io 
Date: Saturday, 1 October 2022 at 09:52
To: vpp-dev@lists.fd.io 
Subject: [vpp-dev] Insert Custom Node Into ip4-unicast Feature Arc
Hi,

For purely my own learning, I am trying to insert my custom node into the 
ip4-unicast feature arc. Based on what I know so far, I would expect the 
following FEATURE_INIT struct to achieve what I want :
VNET_FEATURE_INIT (padraig, static) =
{
  .arc_name = "ip4-unicast",
  .node_name = "padraig",
  .runs_before = VNET_FEATURES ("ip4-lookup"),
};

This and a call to vnet_feature_enable_disable(“ip4-unicast”, “Padraig”, 
sw_if_index_foo, 1, NULL, 0) shoud be all you need.

But sadly no vectors reach my custom node "padraig" when I send a IPv4 ping 
through (A trace shows no interaction with the vector).
The next thing I tried was:
VNET_FEATURE_INIT (padraig, static) =
{
  .arc_name = "ip4-unicast",
  .node_name = "padraig",
  .runs_after = VNET_FEATURES ("ip4-input"),
  .runs_before = VNET_FEATURES ("ip4-lookup"),
};

But with this I get the following runtime error:
vpp[39613]: vnet_feature_arc_init:272: feature node 'ip4-input' not found 
(before 'padraig', arc 'ip4-unicast')

ip4-input is the node at which the ip4 input feature arcs start, so it is not a 
feature on the arc, therefore other nodes cannot run before it.

I have inserted the node in the device-input feature arc before ethernet-input 
as per the wiki doc and it works perfectly but should I assume ip4-unicast 
feature arc is not really meant to have any custom nodes added to it? Or is 
this just a bad configuration on my side?

Ip4-unicast can have custom features added, see e.g. IP reassembly; 
ip4_full_reass_enable_disable()

For vectors to reach my node, does a vnet node have to have my custom node set 
as a "next_node"?

No. next nodes automatically added when the feature is enabled for the first 
time.

/neale

Thanks in advance,
Padraig


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#21951): https://lists.fd.io/g/vpp-dev/message/21951
Mute This Topic: https://lists.fd.io/mt/94037156/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/leave/1480452/21656/631435203/xyzzy 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [vpp-dev] Stats (rx/tx bytes) per MAC address

[Neale Ranns]

Hi Andre,

The adjacency counters are for TX. There’s no way currently to get RX stats per 
MAC.

/neale

From: vpp-dev@lists.fd.io  on behalf of Andre Courchesne 
via lists.fd.io 
Date: Thursday, 29 September 2022 at 04:00
To: vpp-dev@lists.fd.io 
Subject: Re: [vpp-dev] Stats (rx/tx bytes) per MAC address
Thanks Neale.

This seems to provide only total packet/bytes and does not split between RX and 
TX. Know any way to get the discrete RX and TX counters ?

Andre Courchesne - Consultant
http://net-forces.blogspot.ca<https://nam12.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.net-forces.com%2F&data=05%7C01%7Cneale%40graphiant.com%7C29b06cd3424248607ec308daa17b1a8d%7C162101cdceb34e62ab2e3abc7aeede47%7C0%7C0%7C637999848565627091%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000%7C%7C%7C&sdata=DXDl5SJ%2FagTleDd8BH4oiPEVlPlYoKRjWpCA%2Boh89MU%3D&reserved=0>
https://www.co2.click<https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.co2.click%2F&data=05%7C01%7Cneale%40graphiant.com%7C29b06cd3424248607ec308daa17b1a8d%7C162101cdceb34e62ab2e3abc7aeede47%7C0%7C0%7C637999848565627091%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000%7C%7C%7C&sdata=Gf52RnRC9%2B1QWuBDRo40zg%2BE8LkSu7gYPbLJ3T%2BlMw0%3D&reserved=0>
Twitter: @IndianaTux
LinkedIn: 
http://www.linkedin.com/pub/andr%C3%A9-courchesne/0/b0b/688<https://nam12.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.linkedin.com%2Fpub%2Fandr%25C3%25A9-courchesne%2F0%2Fb0b%2F688&data=05%7C01%7Cneale%40graphiant.com%7C29b06cd3424248607ec308daa17b1a8d%7C162101cdceb34e62ab2e3abc7aeede47%7C0%7C0%7C637999848565627091%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000%7C%7C%7C&sdata=Uo%2FW6Q0LKjeB%2Bcs1l57xChwPmbsnSetmjuRPhDvJMVs%3D&reserved=0>

L'information contenue dans le présent document est la propriété de Andre 
Courchesne. Et est divulguée en toute confidentialité. Cette information ne 
doit pas être utilisée, divulguée à d'autres personnes ou reproduite sans le 
consentement écrit explicite de Andre Courchesne.

The information contained in this document is confidential and property of 
Andre Courchesne. It shall not be used, disclosed to others or reproduced 
without the express written consent of Andre Courchesne.


On Tue, Sep 27, 2022 at 8:43 PM Neale Ranns 
mailto:ne...@graphiant.com>> wrote:

Hi Andre,

For L3 forwarding you can use the per-adjacency counters. This are not enabled 
by default, because, like all stats, they come with a performance cost.

DBGvpp# adjacency counters ?

  adjacency counters   adjacency counters [enable|disable]

you’ll then find then in the ‘sh adj’ output and also in the stats segment at 
‘/net/adjacency’’.

/neeale

From: vpp-dev@lists.fd.io<mailto:vpp-dev@lists.fd.io> 
mailto:vpp-dev@lists.fd.io>> on behalf of Andre Courchesne 
via 
lists.fd.io<https://nam12.safelinks.protection.outlook.com/?url=http%3A%2F%2Flists.fd.io%2F&data=05%7C01%7Cneale%40graphiant.com%7C29b06cd3424248607ec308daa17b1a8d%7C162101cdceb34e62ab2e3abc7aeede47%7C0%7C0%7C637999848565627091%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000%7C%7C%7C&sdata=3XJbNpv1nMAGg%2BragRAOHO1ea5EsF5aoNa3PabR34II%3D&reserved=0>
 mailto:net-forces@lists.fd.io>>
Date: Wednesday, 28 September 2022 at 05:47
To: vpp-dev@lists.fd.io<mailto:vpp-dev@lists.fd.io> 
mailto:vpp-dev@lists.fd.io>>
Subject: [vpp-dev] Stats (rx/tx bytes) per MAC address
Hi,

Is there a way to retrieve the number of bytes per MAC address transferred 
through VPP ?

Thanks.

Andre



-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#21945): https://lists.fd.io/g/vpp-dev/message/21945
Mute This Topic: https://lists.fd.io/mt/93958112/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/leave/1480452/21656/631435203/xyzzy 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [vpp-dev] Stats (rx/tx bytes) per MAC address

[Neale Ranns]

Hi Andre,

For L3 forwarding you can use the per-adjacency counters. This are not enabled 
by default, because, like all stats, they come with a performance cost.

DBGvpp# adjacency counters ?

  adjacency counters   adjacency counters [enable|disable]

you’ll then find then in the ‘sh adj’ output and also in the stats segment at 
‘/net/adjacency’’.

/neeale

From: vpp-dev@lists.fd.io  on behalf of Andre Courchesne 
via lists.fd.io 
Date: Wednesday, 28 September 2022 at 05:47
To: vpp-dev@lists.fd.io 
Subject: [vpp-dev] Stats (rx/tx bytes) per MAC address
Hi,

Is there a way to retrieve the number of bytes per MAC address transferred 
through VPP ?

Thanks.

Andre

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#21937): https://lists.fd.io/g/vpp-dev/message/21937
Mute This Topic: https://lists.fd.io/mt/93958112/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/leave/1480452/21656/631435203/xyzzy 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [vpp-dev] ISIS with VPP+FRR

[Neale Ranns]

VPP accepts the frame based on the MAC, but there is no handler for the ISIS 
MAC type, so it is dropped. You’ll need to add support for this.

/neale

From: vpp-dev@lists.fd.io  on behalf of Mohamed Naiem via 
lists.fd.io 
Date: Thursday, 15 September 2022 at 21:08
To: vpp-dev@lists.fd.io 
Subject: Re: [vpp-dev] ISIS with VPP+FRR

Looks for me like problem is VPP doesn't know about AllIntermediateSystems MAC 
so it drops received packet, I tired to switch network-type to broadcast but 
still doesn't work considering AllL2ISs MAC as well.
Not sure if thats right but I'm trying to let VPP know about ISIS MACs
16:43:14:359481: bond-input
  src 40:01:7b:77:5d:d0, dst 09:00:2b:00:00:05, TwentyFiveGigabitEthernet41/0/0 
-> BondEthernet0
16:43:14:359482: ethernet-input
  0x057a: 40:01:7b:77:5d:d0 -> 09:00:2b:00:00:05 802.1q vlan 2000
16:43:14:359482: llc-input
  LLC osi_layer5 -> osi_layer5
16:43:14:359482: osi-input
  OSI isis
16:43:14:359482: error-drop
  rx:BondEthernet0.2000
16:43:14:359482: drop
  osi-input: unknown osi protocol

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#21900): https://lists.fd.io/g/vpp-dev/message/21900
Mute This Topic: https://lists.fd.io/mt/93683140/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/leave/1480452/21656/631435203/xyzzy 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [vpp-dev] Query regarding neos mpls fib entry for tunnel interface

[Neale Ranns]

From: vpp-dev@lists.fd.io  on behalf of sreejith n via 
lists.fd.io 
Date: Thursday, 25 August 2022 at 13:10
To: vpp-dev@lists.fd.io 
Subject: [vpp-dev] Query regarding neos mpls fib entry for tunnel interface
Hi All,

I have a query regarding neos mpls fib entry for tunnel interface. I have 
observed when we create mpls fib entry with neos bit set for tunnel label it 
always sets forwarding as drop ("dpo-drop mpls"). For the eos bit the issue is 
not seen the forwarding is set correctly.

Is this expected to have neos mpls fib entry created as drop for mpls tunnel 
interface. Is this due to any reason. I am checking on a use case in which I 
have to set the tunnel label with both neos and eos fib bit entry for the 
lookup and forwarding .

Logs:

CLI:
"mpls local-label add 51999 via l2-input-on mpls-tunnel0"

You are adding the local-label entry to point to l2-input, that is, after 
popping the label consider what remains to be an ethernet frame and pretend 
that it arrived on mpls-tunnel0. That works when the label popped is 
end-of-stack, but not when it’s not end-of-stack. Hence the neos entry is a 
drop.

/neale


MPLS FIB:
51999:neos/21 fib:0 index:35 locks:2
  CLI refs:1 entry-flags:attached, src-flags:added,contributing,active,
path-list:[30] locks:4 flags:shared, uPRF-list:27 len:0 itfs:[]
  path:[34] pl-index:30 ethernet weight=1 pref=0 intf-rx:  
oper-flags:resolved, cfg-flags:interface-rx,
[@0]: mpls-tunnel0-rx-dpo: ethernet

 forwarding:   mpls-neos-chain  NEOS
  [@0]: dpo-load-balance: [proto:mpls index:40 buckets:1 uRPF:27 to:[0:0]]
[0] [@0]: dpo-drop mpls  DROP
51999:eos/21 fib:0 index:24 locks:2
  API refs:1 entry-flags:attached, src-flags:added,contributing,active,
path-list:[30] locks:4 flags:shared, uPRF-list:27 len:0 itfs:[]
  path:[34] pl-index:30 ethernet weight=1 pref=0 intf-rx:  
oper-flags:resolved, cfg-flags:interface-rx,
[@0]: mpls-tunnel0-rx-dpo: ethernet

 forwarding:   mpls-eos-chain >> EOS
  [@0]: dpo-load-balance: [proto:mpls index:26 buckets:1 uRPF:27 to:[34:1700]]
[0] [@6]: mpls-tunnel0-rx-dpo: ethernet  VALID

Thanks & Regards,
Sreejith


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#21824): https://lists.fd.io/g/vpp-dev/message/21824
Mute This Topic: https://lists.fd.io/mt/93241741/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/leave/1480452/21656/631435203/xyzzy 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [vpp-dev] Bridge-domain function and usage.

[Neale Ranns]

Hi Pargya,

That’s a multicast destination address.

/neale

From: vpp-dev@lists.fd.io  on behalf of Pragya Nand Bhagat 
via lists.fd.io 
Date: Tuesday, 2 August 2022 at 12:25
To: vpp-dev@lists.fd.io 
Subject: Re: [vpp-dev] Bridge-domain function and usage.
Hi Steven,

I'm sending unknown unicast packets with source and destination mac as :
 IP4: a4:bf:01:89:9d:cf -> ab:cd:ef:ab:cd:ef 802.1q vlan 100
Please have a look in the packet trace.

Thanks
Pragya Nand


On Tue, Aug 2, 2022 at 4:51 AM steven luong via 
lists.fd.io
 mailto:cisco@lists.fd.io>> wrote:
Pragya,

UU-Flood stands for Unknown Unicast Flooding. It does not flood multicast or 
broadcast packets. You need “Flooding” on to flood multicast/broadcast packets.

Steven

From: mailto:vpp-dev@lists.fd.io>> on behalf of Pragya 
Nand Bhagat 
mailto:pragya.nand.bhaga...@gmail.com>>
Reply-To: "vpp-dev@lists.fd.io" 
mailto:vpp-dev@lists.fd.io>>
Date: Monday, August 1, 2022 at 2:59 AM
To: "vpp-dev@lists.fd.io" 
mailto:vpp-dev@lists.fd.io>>
Subject: Re: [vpp-dev] Bridge-domain function and usage.

Hi Stanislav,

Following is the trace :

with flooding enabled:

vpp# show bridge-domain 100 det
  BD-ID   Index   BSN  Age(min)  Learning  U-Forwrd   UU-Flood   Flooding  
ARP-Term  arp-ufwd Learn-co Learn-li   BVI-Intf
   100  1   0off  onon  
floodon   offoff1   
16777216 N/A
span-l2-input l2-input-classify l2-input-feat-arc l2-policer-classify 
l2-input-acl vpath-input-l2 l2-ip-qos-record l2-input-vtr l2-learn l2-rw l2-fwd 
l2-flood l2-flood l2-output

   Interface   If-idx ISN  SHG  BVI  TxFlood
VLAN-Tag-Rewrite
port0/0  1 10-  * none
port0/1  2108   0-  * none
port0/2  3 10-  * none

Packet 1

00:11:47:356640: dpdk-input
  port0/0 rx queue 0
  buffer 0xfc9fc3: current data 0, length 60, buffer-pool 0, ref-count 1, trace 
handle 0x0
   ext-hdr-valid
  PKT MBUF: port 0, nb_segs 1, pkt_len 60
buf_len 2176, data_len 60, ol_flags 0x180, data_off 128, phys_addr 
0x3f27f140
packet_type 0x0 l2_len 0 l3_len 0 outer_l2_len 0 outer_l3_len 0
rss 0x0 fdir.hi 0x0 fdir.lo 0x0
Packet Offload Flags
  PKT_RX_IP_CKSUM_GOOD (0x0080) IP cksum of RX pkt. is valid
  PKT_RX_IP_CKSUM_NONE (0x0090) no IP cksum of RX pkt.
  PKT_RX_L4_CKSUM_GOOD (0x0100) L4 cksum of RX pkt. is valid
  PKT_RX_L4_CKSUM_NONE (0x0108) no L4 cksum of RX pkt.
  ARP: a4:bf:01:89:9d:cf -> ff:ff:ff:ff:ff:ff
  request, type ethernet/IP4, address size 6/4
  
a4:bf:01:89:9d:cf/30.30.30.6
 -> 
01:03:05:07:09:00/30.30.30.6
00:11:47:356665: ethernet-input
  frame: flags 0x3, hw-if-index 1, sw-if-index 1
  ARP: a4:bf:01:89:9d:cf -> ff:ff:ff:ff:ff:ff
00:11:47:357793: l2-input
  l2-input: sw_if_index 1 dst ff:ff:ff:ff:ff:ff src a4:bf:01:89:9d:cf [l2-learn 
l2-flood ]
00:11:47:357796: l2-learn
  l2-learn: sw_if_index 1 dst ff:ff:ff:ff:ff:ff src a4:bf:01:89:9d:cf bd_index 1
00:11:47:357799: l2-flood
  l2-flood: sw_if_index 1 dst ff:ff:ff:ff:ff:ff src a4:bf:01:89:9d:cf bd_index 1
  l2-flood: sw_if_index 1 dst ff:ff:ff:ff:ff:ff src a4:bf:01:89:9d:cf bd_index 1
00:11:47:357804: l2-output
  l2-output: sw_if_index 3 dst ff:ff:ff:ff:ff:ff src a4:bf:01:89:9d:cf data 08 
06 00 01 08 00 06 04 00 01 a4 bf
  l2-output: sw_if_index 2 dst ff:ff:ff:ff:ff:ff src a4:bf:01:89:9d:cf data 08 
06 00 01 08 00 06 04 00 01 a4 bf
00:11:47:357807: port0/2-output
  port0/2
  ARP: a4:bf:01:89:9d:cf -> ff:ff:ff:ff:ff:ff
  request, type ethernet/IP4, address size 6/4
  
a4:bf:01:89:9d:cf/30.30.30.6

Re: [vpp-dev] Crash in vlib_buffer_enqueue_next

[Neale Ranns]

From: vpp-dev@lists.fd.io  on behalf of Vijay Kumar via 
lists.fd.io 
Date: Wednesday, 27 July 2022 at 11:27
To: vpp-dev 
Subject: [vpp-dev] Crash in vlib_buffer_enqueue_next
Hi experts,

I am seeing this callstack where the enque next crashes due to sig abort. Pls 
let me know possible reasons for this call stack. I highly appreciate any 
response related to this bt.


Program terminated with signal SIGABRT, Aborted.
#0  __pthread_kill_implementation (threadid=, 
signo=signo@entry=6, no_tid=no_tid@entry=0) at pthread_kill.c:44
Downloading source file 
/usr/src/debug/glibc-2.34-25.fc35.x86_64/nptl/pthread_kill.c...
44return INTERNAL_SYSCALL_ERROR_P (ret) ? INTERNAL_SYSCALL_ERRNO 
(ret) : 0;
[Current thread is 1 (Thread 0x7ff3a7fff640 (LWP 113))]
(gdb) bt
#0  __pthread_kill_implementation (threadid=, 
signo=signo@entry=6, no_tid=no_tid@entry=0) at pthread_kill.c:44
#1  0x7ff79fe828f3 in __pthread_kill_internal (signo=6, threadid=) at pthread_kill.c:78
#2  0x7ff79fe356a6 in __GI_raise (sig=sig@entry=6) at 
../sysdeps/posix/raise.c:26
#3  0x7ff79fe1f865 in __GI_abort () at abort.c:100
#4  0x557244c3d30a in os_exit (code=) at 
/usr/src/debug/vpp-21.06.0-5~g18265fb04_dirty.x86_64/src/vpp/vnet/main.c:477
#5  
#6  vlib_next_frame_change_ownership (node_runtime=0x7ff53dd56500, 
node_runtime=0x7ff53dd56500, next_index=28, vm=0x7ff5269d83c0)
at /usr/src/debug/vpp-21.06.0-5~g18265fb04_dirty.x86_64/src/vlib/main.c:344
#7  vlib_get_next_frame_internal (vm=vm@entry=0x7ff5269d83c0, 
node=node@entry=0x7ff53dd56500, next_index=next_index@entry=28, 
allocate_new_next_frame=allocate_new_next_frame@entry=0)
at /usr/src/debug/vpp-21.06.0-5~g18265fb04_dirty.x86_64/src/vlib/main.c:418
#8  0x7ff7a02816d0 in enqueue_one (tmp=0x7ff3ac254ec0, n_left=2, 
n_buffers=2, nexts=0x7ff3ac2553c0, buffers=0x7ff53e10f9d0, next_index=28, 
used_elt_bmp=0x7ff3ac254e80, node=0x7ff53dd56500,
vm=0x7ff5269d83c0) at 
/usr/src/debug/vpp-21.06.0-5~g18265fb04_dirty.x86_64/src/vlib/buffer_funcs.c:74
#9  vlib_buffer_enqueue_to_next_fn_skx (vm=0x7ff5269d83c0, node=, buffers=, nexts=, count=)
at 
/usr/src/debug/vpp-21.06.0-5~g18265fb04_dirty.x86_64/src/vlib/buffer_funcs.c:165
#10 0x7ff51e7975c7 in ?? () from 
/usr/lib/vpp_plugins/an_ppe_vppctrl_plugin.so

You’re doing something wrong in here. An invalid next node would be my guess.

/neale


#11 0x7ff7a01c62c2 in dispatch_node (last_time_stamp=, 
frame=, dispatch_state=VLIB_NODE_STATE_POLLING, 
type=VLIB_NODE_TYPE_INTERNAL, node=0x7ff53dd56500,
vm=0x7ff5269d83c0) at 
/usr/src/debug/vpp-21.06.0-5~g18265fb04_dirty.x86_64/src/vlib/main.c:1074
#12 dispatch_pending_node (vm=vm@entry=0x7ff5269d83c0, 
pending_frame_index=pending_frame_index@entry=4, last_time_stamp=)
at /usr/src/debug/vpp-21.06.0-5~g18265fb04_dirty.x86_64/src/vlib/main.c:1252
#13 0x7ff7a01c79c7 in vlib_main_or_worker_loop (is_main=0, 
vm=0x7ff5269d83c0) at 
/usr/src/debug/vpp-21.06.0-5~g18265fb04_dirty.x86_64/src/vlib/main.c:1841
#14 vlib_worker_loop (vm=0x7ff5269d83c0) at 
/usr/src/debug/vpp-21.06.0-5~g18265fb04_dirty.x86_64/src/vlib/main.c:1975
#15 0x7ff7a013c68c in clib_calljmp () at 
/usr/src/debug/vpp-21.06.0-5~g18265fb04_dirty.x86_64/src/vppinfra/longjmp.S:123
#16 0x7ff3a7ffec80 in ?? ()
#17 0x7ff51b2af1f2 in eal_thread_loop.cold () from 
/usr/lib/vpp_plugins/dpdk_plugin.so
#18 0x in ?? ()
(gdb) fr 10
#10 0x7ff51e7975c7 in ?? () from 
/usr/lib/vpp_plugins/an_ppe_vppctrl_plugin.so
(gdb) info args


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#21731): https://lists.fd.io/g/vpp-dev/message/21731
Mute This Topic: https://lists.fd.io/mt/92641507/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/leave/1480452/21656/631435203/xyzzy 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [vpp-dev] questions about fib

[Neale Ranns]

[]
  path:[0] pl-index:0 ip4 weight=1 pref=0 special:  cfg-flags:drop,
[@0]: dpo-drop ip4

 forwarding:   unicast-ip4-chain
  [@0]: dpo-load-balance: [proto:ip4 index:1 buckets:1 uRPF:65 to:[518:183020] 
via:[285:13148]]
[0] [@13]: dpo-load-balance: [proto:ip4 index:48 buckets:1 uRPF:62 to:[0:0] 
via:[30:5268]]
  [0] [@5]: ipv4 via 10.120.0.253 G0: mtu:9000 
eeff00163e002e8f0800

at the moment, the default route is correct now, the higher priority is 
contributing to forwarding. but others with red color also use the wrong 
default route.

vpp# show ip fib

10.10.22.0/30
  unicast-ip4-chain
  [@0]: dpo-load-balance: [proto:ip4 index:19 buckets:1 uRPF:20 to:[140:13440] 
via:[10:960]]
[0] [@6]: ipv4 [features] via 0.0.0.0 gre2001: mtu:9000 
4500fe2f2f10c61200cfc61200cb0800
stacked-on entry:17:
  [@5]: arp-ipv4: via 10.10.20.1 G0
10.10.25.0/30
  unicast-ip4-chain
  [@0]: dpo-load-balance: [proto:ip4 index:24 buckets:1 uRPF:26 to:[140:13440] 
via:[10:960]]
[0] [@6]: ipv4 [features] via 0.0.0.0 gre2002: mtu:9000 
4500fe2f2f0dc61200cfc61200ce0800
stacked-on entry:22:
  [@5]: arp-ipv4: via 10.10.20.1 G0


These 2 above are the subnets configured on the tunnel, they will always 
resolve through the tunnel (the default route does not affect this).


198.18.0.203/32
  unicast-ip4-chain
  [@0]: dpo-load-balance: [proto:ip4 index:18 buckets:1 uRPF:58 to:[0:0]]
[0] [@3]: arp-ipv4: via 10.10.20.1 G0
198.18.0.205/32
  unicast-ip4-chain
  [@0]: dpo-load-balance: [proto:ip4 index:13 buckets:1 uRPF:58 to:[0:0]]
[0] [@3]: arp-ipv4: via 10.10.20.1 G0
198.18.0.206/32
  unicast-ip4-chain
  [@0]: dpo-load-balance: [proto:ip4 index:23 buckets:1 uRPF:58 to:[0:0]]
[0] [@3]: arp-ipv4: via 10.10.20.1 G0


These are how to reach the tunnel endpoints  ….

198.18.0.207/32
  unicast-ip4-chain
  [@0]: dpo-load-balance: [proto:ip4 index:29 buckets:1 uRPF:33 to:[38:4560]]
[0] [@2]: dpo-receive: 198.18.0.207 on loop2003

vpp# show fib entry 17
17@198.18.0.203/32 fib:0 index:17 locks:4
  src:API refs:1 src-flags:added,contributing,active,

… which you have explicitly programmed to be ….

path-list:[63] locks:6 flags:shared, uPRF-list:58 len:1 itfs:[1, ]
  path:[88] pl-index:63 ip4 weight=1 pref=0 attached-nexthop:  
oper-flags:resolved,
10.10.20.1 G0
  [@0]: arp-ipv4: via 10.10.20.1 G0

… via G0, although with the wrong next-hop.

  src:recursive-resolution refs:1 src-flags:added, cover:-1

 forwarding:   unicast-ip4-chain
  [@0]: dpo-load-balance: [proto:ip4 index:18 buckets:1 uRPF:58 to:[0:0]]
[0] [@3]: arp-ipv4: via 10.10.20.1 G0
 Delegates:
  track: sibling:29
  Children:{adj:11}{adj:2}
 Children:{fib-entry-track:4}
vpp# show fib en
entry   entry-delegate
vpp# show fib entry 22
22@198.18.0.206/32 fib:0 index:22 locks:4
  src:API refs:1 src-flags:added,contributing,active,
path-list:[63] locks:6 flags:shared, uPRF-list:58 len:1 itfs:[1, ]
  path:[88] pl-index:63 ip4 weight=1 pref=0 attached-nexthop:  
oper-flags:resolved,
10.10.20.1 G0
  [@0]: arp-ipv4: via 10.10.20.1 G0

…. And here too.

  src:recursive-resolution refs:1 src-flags:added, cover:-1

 forwarding:   unicast-ip4-chain
  [@0]: dpo-load-balance: [proto:ip4 index:23 buckets:1 uRPF:58 to:[0:0]]
[0] [@3]: arp-ipv4: via 10.10.20.1 G0
 Delegates:
  track: sibling:39
  Children:{adj:14}{adj:3}
 Children:{fib-entry-track:6}
vpp# show ip fib 0.0.0.0/0
ipv4-VRF:0, fib_index:0, flow hash:[src dst sport dport proto ] 
locks:[src:plugin-hi:2, src:adjacency:2, src:recursive-resolution:3, 
src:default-route:1, src:(nil):1, ]
0.0.0.0/0 fib:0 index:0 locks:3
  src:API refs:1 src-flags:added,contributing,active,
path-list:[62] locks:8 flags:shared, uPRF-list:65 len:2 itfs:[1, 2, ]
  path:[87] pl-index:62 ip4 weight=1 pref=0 recursive:  oper-flags:resolved,
via 10.120.0.253 in fib:0 via-fib:46 via-dpo:[dpo-load-balance:48]
  path:[86] pl-index:62 ip4 weight=1 pref=20 recursive:  
oper-flags:resolved,
via 10.10.20.1 in fib:0 via-fib:42 via-dpo:[dpo-load-balance:44]

this looks fine.

/neale

  src:default-route refs:1 entry-flags:drop, src-flags:added,
path-list:[0] locks:1 flags:drop, uPRF-list:0 len:0 itfs:[]
  path:[0] pl-index:0 ip4 weight=1 pref=0 special:  cfg-flags:drop,
[@0]: dpo-drop ip4

 forwarding:   unicast-ip4-chain
  [@0]: dpo-load-balance: [proto:ip4 index:1 buckets:1 uRPF:65 to:[524:183432] 
via:[1737:80008]]
[0] [@13]: dpo-load-balance: [proto:ip4 index:48 buckets:1 uRPF:62 to:[0:0] 
via:[1816:84791]]
  [0] [@5]: ipv4 via 10.120.0.253 G0: mtu:9000 
eeff00163e002e8f0800



From: Neale Ranns<mailto:ne...@graphiant.com>
Date: 2022-07-26 06:02
To: vpp-dev@lists.fd.io<mailto:vpp-dev@lists.fd.io>
Subject: Re: [vpp-dev] questions about fib

Hi,

Before I answer can you please elaborate on what you mean by ‘stacked on’. Can 
you please give t

Re: [vpp-dev] questions about fib

[Neale Ranns]

Hi,

Before I answer can you please elaborate on what you mean by ‘stacked on’. Can 
you please give the config example.

/neale

From: vpp-dev@lists.fd.io  on behalf of 
haiyan...@ilinkall.cn via lists.fd.io 
Date: Monday, 25 July 2022 at 11:12
To: vpp-dev 
Subject: [vpp-dev] questions about fib
Hello  vpps

1. first we add a default route using api like this:
ip route add 0.0.0.0/0 via 10.121.20.1 weight 1 preference 20

2.  than add some other routes which will stacked on default route above

3. add another defalut route using api with same weight value but higher 
priority (lower preference value) like this:
 ip route add 0.0.0.0/0 via 10.120.0.253 weight 1 preference 0

my question is: when the third step completed, does routes added by step 2 will 
stacked on the new default routes added by step 3?

actually the default route added by step 3 is correct.

 I think step 3 route is higher priority than step 1, when it's added, it will 
back forward to all its children, am i right ? or did i miss something ?

Thanks very much .



-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#21721): https://lists.fd.io/g/vpp-dev/message/21721
Mute This Topic: https://lists.fd.io/mt/92596414/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/leave/1480452/21656/631435203/xyzzy 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [vpp-dev] #mpls enabling mpls at interface

[Neale Ranns]

From: vpp-dev@lists.fd.io  on behalf of Sastry Sista via 
lists.fd.io 
Date: Wednesday, 22 June 2022 at 05:06
To: vpp-dev@lists.fd.io 
Subject: Re: [vpp-dev] #mpls enabling mpls at interface
Hi,
My question is more on clarity. It was enabled and working fine. 
But, some times I see this behavior.

I need answer on what shall be the output when we enable mpls at interface and 
why it shows mpls-not-enabled but it works fine.

when do we see:  none configured

when the interface is MPLS enabled.

when do we see:  mpls-not-enabled
when the interface is NOT MPLS enabled.
You’ll see similar behaviour for IP.
The rationale for having the feature present when the interface is not enabled 
is so that we can default the behaviour to accept and thus not pay the 
performance cost of a check. In the general case we receive more MPLS traffic 
on an enabled interface, than we do on a non-enabled interface.
/neale


With Regards
Sastry

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#21566): https://lists.fd.io/g/vpp-dev/message/21566
Mute This Topic: https://lists.fd.io/mt/91906032/21656
Mute #mpls:https://lists.fd.io/g/vpp-dev/mutehashtag/mpls
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/leave/1480452/21656/631435203/xyzzy 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [vpp-dev] Support of "qos egress map" with GTP tunnels

[Neale Ranns]

Hi Martin,

QoS marking takes the buffer’s pre-classified QoS source:value and translate it 
through the egress map into the value at the layer the marking is specified. If 
we take your map id=0 as an example you are mapping a classification of IP:0 to 
a value 30 and since the marking is an IP features, this means IP DSCP of 30.
However, you don’t have a pre-classification, so the marking node doesn’t know 
what to map from (hence the use:no in the trace). To classify you need either 
the QoS record or store node. Since your map indicates you want to map from IP, 
then my guess is you want the record node as an IP input feature on the 
interface[s] from which packets are received before being transmitted into the 
GTPU tunnel.

/neale

From: vpp-dev@lists.fd.io  on behalf of Martin Dzuris via 
lists.fd.io 
Date: Wednesday, 8 June 2022 at 20:42
To: vpp-dev@lists.fd.io 
Subject: [vpp-dev] Support of "qos egress map" with GTP tunnels
Hi

We need to update DSCP value on gtp output traffic (inside and outside of the 
tunnel too ).

I'm creating GTP tunnel :

...
vppctl set in state GigabitEthernet0/9/0  up
vppctl create sub-interfaces GigabitEthernet0/9/0 5 dot1q 100 exact-match
vppctl set interface state GigabitEthernet0/9/0.5 up
vppctl set int ip address GigabitEthernet0/9/0.5  
22.22.2.2/24
vppctl create gtpu tunnel src 22.22.2.2 dst 22.22.2.4 teid 13 tteid 14 
encap-vrf-id 0 decap-next ip4
vppctl set interface ip table gtpu_tunnel0 22
vppctl set in state gtpu_tunnel0 up
vppctl set int ip address gtpu_tunnel0 50.50.50.1/24


and I tried to mark packet on gtp interface :

vppctl qos egress map id 0 [ip][0]=30
vppctl qos egress map id 1 [ip][1]=31
vppctl qos mark ext gtpu_tunnel0 id 0
vppctl qos mark ext GigabitEthernet0/9/0.5 id 1


Example from Trace :

04:16:56:227608: ip4-qos-mark
  source:ext qos:30 used:no
04:16:56:227611: gtpu4-encap
  GTPU encap to gtpu_tunnel0 tteid 14


Result is that packets are not updated . Is QOS mark feature supported on GTP 
interface and on sub-interfaces ? Can you advise me how to do it?

Martin

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#21519): https://lists.fd.io/g/vpp-dev/message/21519
Mute This Topic: https://lists.fd.io/mt/91620408/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/leave/1480452/21656/631435203/xyzzy 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [vpp-dev] Query regarding MPLS Tunnel

[Neale Ranns]

Hi Sreejith,

No good reason. Please provide a patch to add that capability.

/neale

From: vpp-dev@lists.fd.io  on behalf of sreejith n via 
lists.fd.io 
Date: Friday, 27 May 2022 at 00:34
To: vpp-dev@lists.fd.io 
Subject: [vpp-dev] Query regarding MPLS Tunnel
Hi All,

I have a query regarding Mpls Tunnel delete option.

I have observed we can delete the mpls tunnel created using the CLI by only 
passing the tunnel index.

CLI (To delete mpls tunnel):

mpls tunnel del mpls-tunnel0

But in API option I have observed we cannot delete the mpls tunnel by passing 
tunnel index alone we need to pass rpath details (mandatory) .

API:
vl_api_mpls_tunnel_add_del_t_handler

 if (!vnet_mpls_tunnel_path_remove (tunnel_sw_if_index, rpaths))
vnet_mpls_tunnel_del (tunnel_sw_if_index);

I wanted to ask is there any specific reason to pass the rpath details in the 
API option, can we delete the tunnel directly using the tunnel index similar to 
CLI.

In the CLI API, I have observed it is handled as below, the tunnel is deleted 
directly using tunnel index if rpath is NULL:

CLI API:
vnet_create_mpls_tunnel_command_fn

if (NULL == rpaths)
{
vnet_mpls_tunnel_del(sw_if_index);
 }
else if (!vnet_mpls_tunnel_path_remove(sw_if_index, rpaths))
{
   vnet_mpls_tunnel_del(sw_if_index);
}

Can we consider a similar handling for API option in 
"vl_api_mpls_tunnel_add_del_t_handler".

Thanks & Regards,
Sreejith




-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#21474): https://lists.fd.io/g/vpp-dev/message/21474
Mute This Topic: https://lists.fd.io/mt/91355659/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] Regarding DES support in VPP

[Neale Ranns]

Hi Vijay,

It sounds like the SA you programme did not install. As you say, DES is 
insecure, so we don’t even test it anymore. I would suggest you start with a UT 
in VPP and go from there. Maybe extend the algos in MyParameters in 
test/test_ipsec_esp.py

/neale

From: vpp-dev@lists.fd.io  on behalf of Vijay Kumar via 
lists.fd.io 
Date: Thursday, 26 May 2022 at 21:52
To: vpp-dev 
Subject: [vpp-dev] Regarding DES support in VPP
Hi Neale/Benoit,

I know we must not talk about DES and MD5 these days as they are insecure and 
must not be configured. My QA has raised an issue that DES is not working. I 
have myself not tested it as the customers would never configure it.

The QA says the "show ipsec sa" command does not show anything if DES is 
configured.

 Also the show node counters had this counter incremented for DES.
"4 ipsec4-tun-input no matching tunnel"

Not sure if I am missing something.

NOTE:
==
1) We don't use the vpp ikev2 plugin. We have our own IKE stack that programs 
the VPP with IPSEC SA. Basically our application receives the SA and calls the 
ipsec_sa_add_and_lock() API to install the SA.

2) We have tested AES128, ASE256, 3DES and they were working fine. The code to 
receive keys from IKE stack and program the vnet/ipsec is the same.



Regards,
Vijay Kumar N.

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#21473): https://lists.fd.io/g/vpp-dev/message/21473
Mute This Topic: https://lists.fd.io/mt/91352430/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] creating mpls tunnel with instance ID #mpls

[Neale Ranns]

There’s no good reason MPLS tunnels don’t have that feature. We’d gladly accept 
the patch.

/neale


From: vpp-dev@lists.fd.io  on behalf of Pim van Pelt via 
lists.fd.io 
Date: Monday, 9 May 2022 at 12:28
To: Halit 
Cc: vpp-dev@lists.fd.io 
Subject: Re: [vpp-dev] creating mpls tunnel with instance ID #mpls
Hoi,

I don't know about the answer to MPLS, but did notice that GENEVE tunnels also 
cannot be explicitly created by id:
  create geneve tunnel create geneve tunnel local 
 {remote |group  
} vni  [encap-vrf-id ] [decap-next [l2|node ]] 
[l3-mode] [del]

I agree that it (greatly) simplifies automation. Halit: contributions are 
welcome, in case you want to give it a go!
groet,
Pim

On Sun, May 8, 2022 at 6:58 PM Halit 
mailto:hustu...@gmail.com>> wrote:
Looks like this question has been asked before a few times and as far i see, 
answer was negative. I wonder if there is any change in plans.
Is there any plan to create mpls tunnel with an ID like other 
tunnels/interfaces? - This would simplify certain automation.

create ipip tunnel   create ipip tunnel src  dst 
 [instance ] [outer-table-id ] [p2mp]
create gre tunnelcreate gre tunnel src  dst 
 [instance ] [outer-fib-id ] [teb | erspan ] [del] 
[multipoint]
create vxlan tunnel  create vxlan tunnel src 
 {dst |group  } 
vni  [instance ] [encap-vrf-id ]
create loopback interfacecreate loopback interface [mac 
] [instance ]

mpls tunnel ?
  mpls tunnel  mpls tunnel [multicast] [l2-only] 
via [next-hop-address] [next-hop-interface] [next-hop-table ] [weight 
] [preference ] [udp-encap-id ] [ip4-lookup-in-table 
] [ip6-lookup-in-table ] [mpls-lookup-in-table ] 
[resolve-via-host] [resolve-via-connected] [rx-ip4 ] [out-labels 
]

Thanks,
Halit



--
Pim van Pelt mailto:p...@ipng.nl>>
PBVP1-RIPE - http://www.ipng.nl/

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#21386): https://lists.fd.io/g/vpp-dev/message/21386
Mute This Topic: https://lists.fd.io/mt/90981638/21656
Mute #mpls:https://lists.fd.io/g/vpp-dev/mutehashtag/mpls
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: Private: Re: [vpp-dev] Queries regarding mfib and multicast support in VPP

[Neale Ranns]

You need to add them both in the same command


DBGvpp# ip mroute add 1.1.1.1 239.1.1.1 via loop0 Accept Forward

DBGvpp# sh ip mfib 1.1.1.1 239.1.1.1

ipv4-VRF:0, fib_index:0 flags:none

(1.1.1.1, 239.1.1.1/32):

 fib:0 index:8 locks:1

  src:CLI flags:none locks:1:

path-list:[13] locks:2 flags:no-uRPF, uRPF-list: None

  path:[13] pl-index:13 ip4 weight=1 pref=0 attached:

 loop0

Extensions:

 path:13 flags:Accept,Forward,

Interface-Forwarding:

 loop0: Accept,Forward,   <<<<<



  Interfaces:

   loop0: Accept,Forward,

  multicast-ip4-chain

  [@0]: dpo-drop ip4

DBGvpp#


/neale

From: arunmitta...@gmail.com 
Date: Wednesday, 20 April 2022 at 05:47
To: Neale Ranns 
Subject: Private: Re: [vpp-dev] Queries regarding mfib and multicast support in 
VPP
Thanks Neale,

I think this information will help me a lot to understand multicast forwarding 
in VPP.

I am using "ip mroute add 1.1.1.1 239.1.1.1 via Eth0/2 Accept" to configure a 
mroute from VPP CLI. I have observed that, I can configure the interface as 
FORWARD or ACCEPT for the given S, G entry but not both.
With you input, I understand that we can configure an interface with both 
FORWARD as well as ACCEPT attributes. Am I missing something or still there is 
some gap in my understanding ?


root@cnfp:/# cnfp-dbg vpp ip mroute add 1.1.1.1 239.1.1.1 via 
TenGigabitEthernet3/0/1.205 Accept
root@cnfp:/# cnfp-dbg vpp show ip mfib
ipv4-VRF:0, fib_index:0 flags:none
(*, 0.0.0.0/0):  flags:Drop,
  Interfaces:
  multicast-ip4-chain
  [@0]: dpo-drop ip4
(*, 224.0.0.1/32):
  Interfaces:
  multicast-ip4-chain
  [@2]: dpo-replicate: [index:0 buckets:1 flags:[has-local ] to:[0:0]]
[0] [@1]: dpo-receive
(*, 224.0.0.2/32):
  Interfaces:
  multicast-ip4-chain
  [@2]: dpo-replicate: [index:1 buckets:1 flags:[has-local ] to:[0:0]]
[0] [@1]: dpo-receive
(1.1.1.1, 239.1.1.1/32):
  Interfaces:
   TenGigabitEthernet3/0/1.205: Accept,
  multicast-ip4-chain
  [@0]: dpo-drop ip4

root@cnfp:/# cnfp-dbg vpp ip mroute add 1.1.1.1 239.1.1.1 via 
TenGigabitEthernet3/0/1.205 Forward
root@cnfp:/# cnfp-dbg vpp show ip mfib
ipv4-VRF:0, fib_index:0 flags:none
(*, 0.0.0.0/0):  flags:Drop,
  Interfaces:
  multicast-ip4-chain
  [@0]: dpo-drop ip4
(*, 224.0.0.1/32):
  Interfaces:
  multicast-ip4-chain
  [@2]: dpo-replicate: [index:0 buckets:1 flags:[has-local ] to:[0:0]]
[0] [@1]: dpo-receive
(*, 224.0.0.2/32):
  Interfaces:
  multicast-ip4-chain
  [@2]: dpo-replicate: [index:1 buckets:1 flags:[has-local ] to:[0:0]]
[0] [@1]: dpo-receive
(1.1.1.1, 239.1.1.1/32):
  Interfaces:
   TenGigabitEthernet3/0/1.205: Forward,
  multicast-ip4-chain
  [@2]: dpo-replicate: [index:6 buckets:1 flags:[none] to:[0:0]]
[0] [@2]: ipv4-mcast: TenGigabitEthernet3/0/1.205: mtu:9000 next:4 
01005e003cecef457f4b81640800



-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#21273): https://lists.fd.io/g/vpp-dev/message/21273
Mute This Topic: https://lists.fd.io/mt/90579491/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] User traffic is going down the wrong tunnel when multiple IKEv2/IPsec tunnels are added, removed then added.

[Neale Ranns]

Hi Sonia,

How are you routing into the tunnels, and what changes to that routing do you 
make when removing and adding tunnels.

/neale

From: vpp-dev@lists.fd.io  on behalf of Sonia Rovner via 
lists.fd.io 
Date: Tuesday, 12 April 2022 at 22:57
To: vpp-dev@lists.fd.io 
Subject: [vpp-dev] User traffic is going down the wrong tunnel when multiple 
IKEv2/IPsec tunnels are added, removed then added.

Hi All,

So we are creating multiple (3) IKEv2/IPsec tunnels between two vpp instances. 
When the setup is clean, vpp restart, all the tunnels come up and traffic flows 
as it should.
So when we make configuration changes by removing two of the tunnels, then make 
another change by adding the tunnels back. The IPsec tunnels come up.  user 
traffic does not flow correctly on the added IKEv2/IPsec tunnels. From packet 
trace we can see traffic using credentials for one tunnel but sending it down 
to the other added tunnel.

Below is the diagram of the testbed setup.  Start off with 3 IKE/IPsec tunnels. 
 The config change was to remove 2nd and 3rd tunnels below.  Then, another 
config change to add the 2nd and 3rd tunnels back.

192.168.10.6 ==192.168.30.6
192.168.11.6 ==192.168.31.6
192.168.12.6 ==192.168.32.6
[cid:attach_0_16E541AB9E465AA2_11385@groups.io]

When traffic does flow, it's always when the ipip_add_tunnel api returns 
sw_if_index in ascending order
for 192.168.31.6==192.168.11.6, sw_if_index is 7, ipip1.
for 192.168.32.6==192.168.12.6, sw_if_index is 8, ipip 2.

When traffic doesn't flow, it's always when the ipip_add_tunnel api returns 
sw_if_index out of order.
For example on vpp2, when adding ipip tunnel
for 192.168.31.6==192.168.11.6, sw_if_index is 8, ipip2.
for 192.168.32.6==192.168.12.6, sw_if_index is 7, ipip1.

In the attached packet trace, vpp2dpdkbroken.trace, you can see that TCP 
packets from 192.168.220.20 -> 192.168.200.20 for ipip2 is sent to IPSEC_ESP: 
192.168.32.6 -> 192.168.12.6

packet generator is runing from vpp2 Testnode using
 nping --tcp 192.168.200.20 -p 2001-4000 --rate 100

Regards,
-Sonia


dummyfile.0.part
Description: dummyfile.0.part

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#21250): https://lists.fd.io/g/vpp-dev/message/21250
Mute This Topic: https://lists.fd.io/mt/90427455/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] Queries regarding mfib and multicast support in VPP

[Neale Ranns]

Hi Arun,

From: vpp-dev@lists.fd.io  on behalf of arunmittal88 via 
lists.fd.io 
Date: Tuesday, 12 April 2022 at 15:24
To: vpp-dev@lists.fd.io 
Subject: [vpp-dev] Queries regarding mfib and multicast support in VPP
Hi,

Just want to know if the mfib-lookup node is attached to the default packet 
processing node graph or do we need to explicitly enable this.
It’s enabled by default.
Also wanted to understand if the following things are achievable with mfib in 
VPP (To understand the mfib in VPP I am following 
"https://wiki.fd.io/view/VPP/MFIB"; page).

Lets assume I have 3 interfaces Eth0/1 Eth0/2 and Eth0/3 and I want to 
configure the multicast rule for Group G (236.1.2.3) as follow:
1.) The group G stream is acceptable on interface Eth0/1 and Eth0/2 and it is 
blocked on interface Eth0/3.
2.) If group G stream is received on Eth0/1, it is forwarded to Eth0/2 and if 
Eth0/2 receives it then, it should be forwarded to Eth0/1 as well.
If eth0/1 and eth0/2 are both ACCEPT and FROWARDING, that is the behaviour you 
will get. But N.B, multicast will never forward back out the interface on which 
the packet was received (I think that’s what you want but it’s not entirely 
clear).
/neale


Thanks,
Arun

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#21249): https://lists.fd.io/g/vpp-dev/message/21249
Mute This Topic: https://lists.fd.io/mt/90417743/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] Prevent blackhole routes being leaked into VPP

[Neale Ranns]

Hi,

You need to choose an appropriate priority for:

  lcp_rt_fib_src =
fib_source_allocate ("lcp-rt", FIB_SOURCE_PRIORITY_HI, FIB_SOURCE_BH_API);

in plugins/linux-cp/lcp_router.c

from vnet/fb/fib_source.h

/**
* The fixed source to priority mappings.
* Declared here so those adding new sources can better determine their 
respective
* priority values.
*/
#define foreach_fib_source  \
/** you can't do better then the special source */ \
_(FIB_SOURCE_SPECIAL,   0x00, FIB_SOURCE_BH_SIMPLE)\
_(FIB_SOURCE_CLASSIFY,  0x01, FIB_SOURCE_BH_SIMPLE)\
_(FIB_SOURCE_PROXY, 0x02, FIB_SOURCE_BH_SIMPLE)\
_(FIB_SOURCE_INTERFACE, 0x03, FIB_SOURCE_BH_INTERFACE) \
_(FIB_SOURCE_SR,0x10, FIB_SOURCE_BH_API)   \
_(FIB_SOURCE_BIER,  0x20, FIB_SOURCE_BH_SIMPLE)\
_(FIB_SOURCE_6RD,   0x30, FIB_SOURCE_BH_API)   \
_(FIB_SOURCE_API,   0x80, FIB_SOURCE_BH_API)   \
_(FIB_SOURCE_CLI,   0x81, FIB_SOURCE_BH_API)   \
_(FIB_SOURCE_LISP,  0x90, FIB_SOURCE_BH_LISP)  \
_(FIB_SOURCE_MAP,   0xa0, FIB_SOURCE_BH_SIMPLE)\
_(FIB_SOURCE_DHCP,  0xb0, FIB_SOURCE_BH_API)   \
_(FIB_SOURCE_IP6_ND_PROXY,  0xc0, FIB_SOURCE_BH_API)   \
_(FIB_SOURCE_IP6_ND,0xc1, FIB_SOURCE_BH_API)   \
_(FIB_SOURCE_ADJ,   0xd0, FIB_SOURCE_BH_ADJ)   \
_(FIB_SOURCE_MPLS,  0xe0, FIB_SOURCE_BH_MPLS)  \
_(FIB_SOURCE_AE,0xf0, FIB_SOURCE_BH_SIMPLE)\
_(FIB_SOURCE_RR,0xfb, FIB_SOURCE_BH_RR)\
_(FIB_SOURCE_URPF_EXEMPT,   0xfc, FIB_SOURCE_BH_RR)\
_(FIB_SOURCE_DEFAULT_ROUTE, 0xfd, FIB_SOURCE_BH_DROP)  \
_(FIB_SOURCE_INTERPOSE, 0xfe, FIB_SOURCE_BH_INTERPOSE) \
_(FIB_SOURCE_INVALID,   0xff, FIB_SOURCE_BH_DROP)

/**
* Some priority values that plugins might use when they are not to concerned
* where in the list they'll go.
*/
#define FIB_SOURCE_PRIORITY_HI 0x10
#define FIB_SOURCE_PRIORITY_LOW 0xd0


/neale


From: vpp-dev@lists.fd.io  on behalf of Chinmaya Aggarwal 
via lists.fd.io 
Date: Tuesday, 5 April 2022 at 16:55
To: vpp-dev@lists.fd.io 
Subject: Re: [vpp-dev] Prevent blackhole routes being leaked into VPP
Hi,

We are adding blackhole routes via linux command "sudo ip netns exec dataplane 
ip -6 route add blackhole 2001:50:10:a111::101/64 table 1203"

After adding blackhole routes on linux (that are leaked to vpp), if we try to 
view the route in vpp ,we get the below output
[root@j3chysr01stg05 ~]# vppctl show ip6 fib table 1203 2001:50:10:a111::/64
ipv6-VRF:1203, fib_index:3, flow hash:[src dst sport dport proto flowlabel ] 
epoch:0 flags:none locks:[CLI:3, lcp-rt:1, ]
2001:50:10:a111::/64 fib:3 index:86 locks:2
  lcp-rt refs:1 entry-flags:drop, src-flags:added,contributing,active,
path-list:[126] locks:2 flags:drop, uPRF-list:76 len:0 itfs:[]
  path:[126] pl-index:126 ip6 weight=1 pref=0 deag:  cfg-flags:drop,
 fib-index:0

 forwarding:   unicast-ip6-chain
  [@0]: dpo-load-balance: [proto:ip6 index:88 buckets:1 uRPF:76 to:[0:0]]
[0] [@0]: dpo-drop ip6
[root@j3chysr01stg05 ~]#

Now, if we add another route via ipip tunnel (that supposedly should overwrite 
the blackhole route) using the API. We get below below output for command "show 
ip6 fib table 1203 2001:50:10:a111::/64"

[root@j3chysr01stg05 ~]# vppctl show ip6 fib table 1203 2001:50:10:a111::/64
ipv6-VRF:1203, fib_index:3, flow hash:[src dst sport dport proto flowlabel ] 
epoch:0 flags:none locks:[CLI:3, lcp-rt:1, ]
2001:50:10:a111::/64 fib:3 index:86 locks:3
  lcp-rt refs:1 entry-flags:drop, src-flags:added,contributing,active,
path-list:[126] locks:2 flags:drop, uPRF-list:76 len:0 itfs:[]
  path:[126] pl-index:126 ip6 weight=1 pref=0 deag:  cfg-flags:drop,
 fib-index:0

  API refs:1 entry-flags:attached,import, src-flags:added,
path-list:[161] locks:1 flags:shared, uPRF-list:106 len:1 itfs:[40, ]
  path:[211] pl-index:161 ip6 weight=100 pref=0 attached:  
oper-flags:resolved,
 ipip19

 forwarding:   unicast-ip6-chain
  [@0]: dpo-load-balance: [proto:ip6 index:88 buckets:1 uRPF:76 to:[0:0]]
[0] [@0]: dpo-drop ip6
[root@j3chysr01stg05 ~]#

lcp-rt gets added the moment the blackhole routes get leaked to VPP.  I think 
"lcp-rt" denotes the blackhole routes.
API is still below the "lcp-rt" route. How can we prioritize API route over 
lcp-rt route?

Thanks and Regards,
Chinmaya Agarwal.

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#21207): https://lists.fd.io/g/vpp-dev/message/21207
Mute This Topic: https://lists.fd.io/mt/90236408/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] Prevent blackhole routes being leaked into VPP

[Neale Ranns]

From: vpp-dev@lists.fd.io  on behalf of Chinmaya Aggarwal 
via lists.fd.io 
Date: Monday, 4 April 2022 at 09:08
To: vpp-dev@lists.fd.io 
Subject: [vpp-dev] Prevent blackhole routes being leaked into VPP
Hi,

We have integrated linux-cp and linux-nl plugin in VPP. We create table 1203 on 
VPP and on linux (in namespace dataplane). We added a blackhole route on linux 
using below command:-
sudo ip netns exec dataplane ip -6 route add blackhole 2001:50:10:a111::101/64 
table 1203

When I view this route on VPP it shows something like this:-
vpp# show ip6 fib table 1203
2001:50:10:a111::/64
  unicast-ip6-chain
  [@0]: dpo-load-balance: [proto:ip6 index:88 buckets:1 uRPF:76 to:[164:17056]]
[0] [@0]: dpo-drop ip6

If you ‘show ip6 fib table 1203 2001:50:10:a111::/64’ you’ll see more detailed 
output. It will show that the entry now has two ‘sources’ the API and the CLI. 
FIB has a simple priority mechanism for choosing with source ‘wins’ and thus 
contributes the forwarding (i.e. the DPOs you see display here). The API source 
has higher priority than the CPI source. This was done on purpose to get 
exactly the behaviour you see, that is the *debug* CLI cannot disrupt the 
routes provided by the control plane. If you want to change this behaviour, 
you’ll need to recompile VPP with the source priorities changed.


After this If I try to add or overwrite this route with another route but VPP 
is not able to overwrite it. I executed below command:-
vppctl ip route add 2001:50:10:a111::101/64 table 1203 via ipip19

where ipip19 is an ipip tunnel created by us.

When I try to view the updated route on VPP it is still showing blackhole 
route:-
vpp# show ip6 fib table 1203
2001:50:10:a111::/64
  unicast-ip6-chain
  [@0]: dpo-load-balance: [proto:ip6 index:88 buckets:1 uRPF:76 to:[164:17056]]
[0] [@0]: dpo-drop ip6

Why VPP is not able to overwrite the blackhole route with the new route?
Also, is there a way by which we can prevent blackhole routes (added in linux) 
getting leaked into VPP?

I would suggest that VPP (i.e. the data plane) should always have an exact copy 
of the routes from the control plane . So the question to ask is how to prevent 
black hole routes being installed in linux, for which I do not have an answer 
(assuming your example above is contrived and you get blackhole routes from a 
routing protocol).

/neale


Thanks and Regards,
Chinmaya Agarwal.

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#21194): https://lists.fd.io/g/vpp-dev/message/21194
Mute This Topic: https://lists.fd.io/mt/90236408/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] Crash in BVI and Loopback interaction

[Neale Ranns]

From: vpp-dev@lists.fd.io  on behalf of Pim van Pelt via 
lists.fd.io 
Date: Sunday, 27 March 2022 at 14:01
To: Stanislav Zaikin 
Cc: vpp-dev 
Subject: Re: [vpp-dev] Crash in BVI and Loopback interaction
Hoi Stanislav,

Thanks for the response. As I noted in my original email, I am aware that 
loopbacks work as BVI members, but since they are there (and have a whole 
device class dedicated to them!) I was hoping to

  1.  get some historical context on the need/differences between BVI and 
Loopback devices, and

I’m guilty there. My rationale for introducing the BVI interface was to have an 
interface type dedicated to, and optimised for, the L2 function, rather than 
overloading the loopback type, which in the L3 world has a very different 
purpose. However, since there is a large installed base using the loopback for 
the purpose of l2, its L2 functions were never deprecated.

/neale

(b) get to the bottom of this bug and fix it :)

I can certainly work around the bug for now by dedicating a set of loopback 
interfaces and avoiding the use of BVIs, for now.

groet,
Pim

On Sun, Mar 27, 2022 at 12:43 PM Stanislav Zaikin 
mailto:zsta...@gmail.com>> wrote:
Hi Pim,

Well, I wasn't aware of "bvi ..." commands. Anyway, usually I go with something 
like:

create loopback interface instance 20
set interface state loop20 up
create bridge-domain 20 learn 1 forward 1 flood 1 arp-term 1 arp-ufwd 0
set interface l2 bridge loop20 20 bvi

On Sun, 27 Mar 2022 at 00:41, Pim van Pelt mailto:p...@ipng.nl>> 
wrote:
Hoi,

I've noticed that a pattern of 'create loopback; delete loopback; create bvi' 
as well as 'create bvi; delete bvi; create loopback' makes VPP at HEAD unhappy.
I've actually long since wondered what the difference is between BVI and 
Loopback interface types, other than the BVI plumbing lives in l2/l2_bvi.c and 
the loopback lives in ethernet/interface.c their _use_ seems very similar if 
not identical. I understand that BVIs are used in bridges, but a loopback in 
practice serves that purpose equally well.

I assume the issue is in the bvi/loop deletion not the creation, but I stared 
at this for an hour or so and could not understand it. Can somebody more 
knowledgeable help me out ?
Take the following simple repro to crash VPP. The assertion in noce.c:194 fails 
in both cases:

1) create loop after bvi:
DBGvpp# show version
vpp v22.06-rc0~268-g4859d8d8e built by pim on hippo at 2022-03-23T19:23:53
DBGvpp# bvi create instance 0
bvi0
DBGvpp# bvi delete bvi0
DBGvpp# create loopback interface instance 0
0: /home/pim/src/vpp/src/vlib/node.c:194 (vlib_node_add_next_with_slot) 
assertion `slot == p[0]' fails

Thread 1 "vpp_main" received signal SIGABRT, Aborted.
__GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
50  ../sysdeps/unix/sysv/linux/raise.c: No such file or directory.
(gdb) bt
#0  __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
#1  0x769de859 in __GI_abort () at abort.c:79
#2  0x004072f3 in os_panic () at 
/home/pim/src/vpp/src/vpp/vnet/main.c:413
#3  0x76d2ebc9 in debugger () at 
/home/pim/src/vpp/src/vppinfra/error.c:84
#4  0x76d2e92d in _clib_error (how_to_die=2, function_name=0x0, 
line_number=0, fmt=0x76f3b19c "%s:%d (%s) assertion `%s' fails")
at /home/pim/src/vpp/src/vppinfra/error.c:143
#5  0x76ea462b in vlib_node_add_next_with_slot (vm=0x7fff96800740, 
node_index=696, next_node_index=648, slot=2)
at /home/pim/src/vpp/src/vlib/node.c:194
#6  0x76ea61d8 in vlib_node_add_named_next_with_slot 
(vm=0x7fff96800740, node=696, name=0x77cc7c86 "l2-input", slot=2)
at /home/pim/src/vpp/src/vlib/node.c:267
#7  0x770d5ce5 in vnet_create_loopback_interface 
(sw_if_indexp=0x7fff515421e8, mac_address=0x7fff515421e2 "", is_specified=1 
'\001',
user_instance=0) at /home/pim/src/vpp/src/vnet/ethernet/interface.c:890
#8  0x770d98df in create_simulated_ethernet_interfaces 
(vm=0x7fff96800740, input=0x7fff51542e40, cmd=0x7fff99b88088)
at /home/pim/src/vpp/src/vnet/ethernet/interface.c:930
#9  0x76e681d4 in vlib_cli_dispatch_sub_commands (vm=0x7fff96800740, 
cm=0x4312e0 , input=0x7fff51542e40,
parent_command_index=1146) at /home/pim/src/vpp/src/vlib/cli.c:592
#10 0x76e67f4e in vlib_cli_dispatch_sub_commands (vm=0x7fff96800740, 
cm=0x4312e0 , input=0x7fff51542e40,
parent_command_index=33) at /home/pim/src/vpp/src/vlib/cli.c:549
#11 0x76e67f4e in vlib_cli_dispatch_sub_commands (vm=0x7fff96800740, 
cm=0x4312e0 , input=0x7fff51542e40,
parent_command_index=0) at /home/pim/src/vpp/src/vlib/cli.c:549
#12 0x76e66e98 in vlib_cli_input (vm=0x7fff96800740, 
input=0x7fff51542e40, function=0x76ef2c40 , 
function_arg=0)
at /home/pim/src/vpp/src/vlib/cli.c:695
#13 0x76ef48dd in unix_cli_process_input (cm=0x76f69748 
, cli_file_index=0) at /home/pim/src/vpp/src/vlib/unix/cli.c:2617
#14 0x76ef1cb1 in unix_cli_process (vm=0x7f

Re: [vpp-dev] vpp hangs with bfd configuration along with mpls (inner and outer ctxt)

[Neale Ranns]

Hi Sastry,

There are lots of examples of MPLS routes and VRF creation in test/test_mpls.py 
and BFD session creation in test/test_bfd.py.

Or if you’d prefer there’s src/plugins/unittest/fib_test.c with fib_test_bfd.

/neale


From: vpp-dev@lists.fd.io  on behalf of Sastry Sista via 
lists.fd.io 
Date: Monday, 21 March 2022 at 11:13
To: vpp-dev@lists.fd.io 
Subject: Re: [vpp-dev] vpp hangs with bfd configuration along with mpls (inner 
and outer ctxt)
Hi Neale,
   Thank you so much for extending the help.

I am not sure how do I run/configure unit test. I can try If you can provide me 
steps to configure VRFs using VL APIs in unit test framework.

We can have a call to discuss?

With Regards
Sastry

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#21082): https://lists.fd.io/g/vpp-dev/message/21082
Mute This Topic: https://lists.fd.io/mt/89811914/21656
Mute #mpls:https://lists.fd.io/g/vpp-dev/mutehashtag/mpls
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 hangs with bfd configuration along with mpls (inner and outer ctxt)

[Neale Ranns]

Hi Sastry,

If you can reproduce it with a unit test, I’ll look into it.

/neale


From: vpp-dev@lists.fd.io  on behalf of Sastry Sista via 
lists.fd.io 
Date: Thursday, 17 March 2022 at 10:07
To: vpp-dev@lists.fd.io 
Subject: Re: [vpp-dev] vpp hangs with bfd configuration along with mpls (inner 
and outer ctxt)
Hi Neale,
   The same issue is report little while ago:

vpp-dev@lists.fd.io | Infinite loop in 
fib_walk_sync

Could you please check if its fixed or worked around?. I see that its loop of 
vrfs i.e outter and inner context associated and its into fib_walk_advance 
taking same vrfs again and again fwi {0,1,}. Ideally once processing is 
over 0 and 1, it shall exit the loop but, its into loop.

With Regards
Sastry

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#21079): https://lists.fd.io/g/vpp-dev/message/21079
Mute This Topic: https://lists.fd.io/mt/89811914/21656
Mute #mpls:https://lists.fd.io/g/vpp-dev/mutehashtag/mpls
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [vpp-dev] Coredump occur when duplicate a packet at "interface-output" arc. #vpp

[Neale Ranns]

Hi,

You decrement/increment n_left_to_next/to_next twice in one iteration of the 
loop, so you are writing out of bounds. Have a look at other nodes that do 
packet copying like l2_flood.

/neale

From: vpp-dev@lists.fd.io  on behalf of Smith Beirvin via 
lists.fd.io 
Date: Monday, 7 March 2022 at 04:02
To: vpp-dev@lists.fd.io 
Subject: [vpp-dev] Coredump occur when duplicate a packet at "interface-output" 
arc. #vpp
Hi fellows:
I got a problem when duplicate a packet at "interface-output" arc, this 
will trigger a coredump as below. while I can't find any issue for the sorce 
code. So pls help me.

Coredump information;

Mar  7 02:54:24 localhost vnet[9542]: vlib_buffer_validate_alloc_free:367: 
freeing known-free buffer 0x9f947
Mar  7 02:54:24 localhost vnet[9542]: received signal SIGABRT, PC 0x7f2b4330ce87
Mar  7 02:54:24 localhost vnet[9542]: #0  0x7f2b44e5e914 
unix_signal_handler + 0x2a4
Mar  7 02:54:24 localhost vnet[9542]: #1  0x7f2b446f1980 0x7f2b446f1980
Mar  7 02:54:24 localhost vnet[9542]: #2  0x7f2b4330ce87 gsignal + 0xc7
Mar  7 02:54:24 localhost vnet[9542]: #3  0x7f2b4330e7f1 abort + 0x141
Mar  7 02:54:24 localhost vnet[9542]: #4  0x00407263 0x407263
Mar  7 02:54:24 localhost vnet[9542]: #5  0x7f2b441ed7f9 debugger + 0x9
Mar  7 02:54:24 localhost vnet[9542]: #6  0x7f2b441ed577 _clib_error + 0x3b7
Mar  7 02:54:24 localhost vnet[9542]: #7  0x7f2b44d6b4a7 
vlib_buffer_validate_alloc_free + 0x117
Mar  7 02:54:24 localhost vnet[9542]: #8  0x7f2afa231267 
vlib_buffer_free_inline.constprop.9 + 0x1167
Mar  7 02:54:24 localhost vnet[9542]: #9  0x7f2afa2328bb tap_inject_tx + 
0x64b
Mar  7 02:54:24 localhost vnet[9542]: #10 0x7f2b44dd9fd5 dispatch_node + 
0x365
Mar  7 02:54:24 localhost vnet[9542]: #11 0x7f2b44dda8a7 
dispatch_pending_node + 0x3c7
Mar  7 02:54:24 localhost vnet[9542]: #12 0x7f2b44dd4d01 
vlib_main_or_worker_loop + 0xc51
Mar  7 02:54:24 localhost vnet[9542]: #13 0x7f2b44dd6a4a vlib_main_loop + 
0x1a
Mar  7 02:54:24 localhost vnet[9542]: #14 0x7f2b44dd681f vlib_main + 0xacf

Source Code:
// decode
typedef enum
{
UDP_TCP_FAKE_OUT_NEXT_DROP,
UDP_TCP_FAKE_OUT_NEXT_INT_TX,
UDP_TCP_FAKE_OUT_N_NEXT,
} UDP_TCP_FAKE_OUT_NEXT_E;

always_inline uword
tcp_fake_out_inline (vlib_main_t * vm, vlib_node_runtime_t * node, vlib_frame_t 
* frame, u8 is_ip4)
{
u32 n_left_from, *from, *to_next, next_index, matches;
from = vlib_frame_vector_args (frame);
n_left_from = frame->n_vectors;
next_index = node->cached_next_index;
matches = 0;

while (n_left_from > 0)
{
u32 n_left_to_next;

vlib_get_next_frame (vm, node, next_index, to_next, n_left_to_next);

while (n_left_from > 0 && n_left_to_next > 0 && n_left_to_next <= 256)
{
u32 next0;
vlib_buffer_t* b0;
u32 bi0;

bi0 = from[0];
b0 = vlib_get_buffer (vm, bi0);

vnet_feature_next (&next0, b0);

if (is_ip4)
{
u8 is_send_syn = 1;

if (is_send_syn && (1 < n_left_to_next))
{
u32 syn_bi = 0;
vlib_buffer_t* syn_b;

// syn_b = vlib_buffer_copy3(vm, b0, &syn_bi);

syn_b = vlib_buffer_copy(vm, b0);

// send syn ack
if (syn_b)
{
syn_bi = vlib_get_buffer_index(vm, syn_b);
to_next[0] = syn_bi;
to_next += 1;
n_left_to_next -= 1;

vlib_validate_buffer_enqueue_x1 (vm, node, next_index,
to_next, n_left_to_next, bi0, next0);
printf("%s %d %s %s: tcp_fake track.\r\n", 
__FUNCTION__, __LINE__, __DATE__, __TIME__);
}
else
{
printf("beirvin note %s %d: syn_b is NULL;\r\n", 
__FUNCTION__, __LINE__);
}
}
}

to_next[0] = bi0;
from += 1;
to_next += 1;
n_left_from -= 1;
n_left_to_next -= 1;

vlib_validate_buffer_enqueue_x1 (vm, node, next_index,
  to_next, n_left_to_next, bi0, next0);
}

vlib_put_next_frame (vm, node, next_index, n_left_to_next);
}

// vlib_node_increment_counter (vm, fast-vxlan-output.index, 
FWABF_ERROR_MATCHED, matches);
return frame->n_vectors;
}

always_inline uword
tcp_fake_out_ipv4 (vlib_main_t * vm, vlib_node_runtime_t * node, vlib_frame_t * 
frame)
{
return tcp_fake_out_inline (vm, node, frame, 1);
}


/* *INDENT-OFF* */
VLIB_REGISTER_NODE (tcp_fake_out_node) =
{
.function = tcp_fake_out_ipv4,
.name = "udp-tcp-fake-out",
  /* Takes a vector of packets. */
.vector_size = sizeof (u32),
.type = VLIB_NODE_TYPE_IN

Re: [vpp-dev] Ping to loopback behind Vxlan tunnel is failing #vpp-dev

[Neale Ranns]

From: vpp-dev@lists.fd.io  on behalf of suresh vuppala via 
lists.fd.io 
Date: Friday, 4 March 2022 at 22:40
To: vpp-dev@lists.fd.io 
Subject: [vpp-dev] Ping to loopback behind Vxlan tunnel is failing #vpp-dev
HI VPP-DEV team,

ubuntu 20.04
vpp v22.06-rc0~79-g48bdf24ad

I have my ubuntu 20.04 running the latest VPP code. The ubuntu machine is 
connected to a router. I have a static vxlan tunnel configured between bare 
metal and VPP. The tunnel is up.
Now I have created a loop5007 and added the vxlan tunnel in the same BD. Ping 
is failing from external router to the loopback behind vxlan in VPP. I see that 
l2 mac learning is happening on VPP but ping is failing. Can you please suggest 
what went wrong here




VPP trace:


create loopback interface instance 0

lcp create loop0 host-if loop0

set interface state loop0 up

set interface ip address loop0 2001:db8::1/64

set interface ip address loop0 192.0.2.1/24



create bond mode lacp load-balance l34 id 0

set interface state TenGigabitEthernetd8/0/0 up

set interface state TenGigabitEthernet5e/0/0 up

bond add BondEthernet0 TenGigabitEthernetd8/0/0 long-timeout

bond add BondEthernet0 TenGigabitEthernet5e/0/0 long-timeout

lcp create BondEthernet0 host-if bond0



create sub-interfaces BondEthernet0 80

lcp create BondEthernet0.80 host-if bond0.80



create sub-interfaces BondEthernet0 70

lcp create BondEthernet0.70 host-if bond0.70



set interface state BondEthernet0 up

set interface ip address BondEthernet0.70 
172.16.101.229/24

set interface state BondEthernet0.70 up



create vxlan tunnel src 172.16.101.229 dst 172.12.168.9 vni 5007 decap-next l2

create bridge-domain 5007 learn 1 forward 1 flood 1 arp-term 1 bd-tag 5007

create loopback interface mac cc:cc:cc:dd:dd:01 instance 5007



set interface mtu packet 9000 vxlan_tunnel0

set interface state vxlan_tunnel0 up

set interface l2 bridge vxlan_tunnel0 5007

set interface l2 bridge loop5007 5007



you need the ‘bvi’ flag to indicate this loopback interface is the BVI.



/neale



set interface ip address loop5007 192.168.7.9/24

set interface state loop5007 up



Packet 12



00:43:02:602880: dpdk-input

  TenGigabitEthernet5e/0/0 rx queue 0

  buffer 0x4c3fd8: current data 0, length 152, buffer-pool 0, ref-count 1, 
trace handle 0xb

   ext-hdr-valid

  PKT MBUF: port 0, nb_segs 1, pkt_len 152

buf_len 2176, data_len 152, ol_flags 0x180, data_off 128, phys_addr 
0x130ff680

packet_type 0x291 l2_len 0 l3_len 0 outer_l2_len 0 outer_l3_len 0

rss 0x0 fdir.hi 0x0 fdir.lo 0x0

Packet Offload Flags

  PKT_RX_IP_CKSUM_GOOD (0x0080) IP cksum of RX pkt. is valid

  PKT_RX_IP_CKSUM_NONE (0x0090) no IP cksum of RX pkt.

  PKT_RX_L4_CKSUM_GOOD (0x0100) L4 cksum of RX pkt. is valid

  PKT_RX_L4_CKSUM_NONE (0x0108) no L4 cksum of RX pkt.

Packet Types

  RTE_PTYPE_L2_ETHER (0x0001) Ethernet packet

  RTE_PTYPE_L3_IPV4_EXT_UNKNOWN (0x0090) IPv4 packet with or without 
extension headers

  RTE_PTYPE_L4_UDP (0x0200) UDP packet

  IP4: 2c:f8:9b:57:a5:df -> 3c:fd:fe:e1:61:08 802.1q vlan 70

  UDP: 172.12.168.9 -> 172.16.101.229

tos 0x00, ttl 253, length 134, checksum 0x75be dscp CS0 ecn NON_ECN

fragment id 0x7ee3, flags DONT_FRAGMENT

  UDP: 58360 -> 4789

length 114, checksum 0x

00:43:02:602892: bond-input

  src 2c:f8:9b:57:a5:df, dst 3c:fd:fe:e1:61:08, TenGigabitEthernet5e/0/0 -> 
BondEthernet0

00:43:02:602980: ethernet-input

  IP4: 2c:f8:9b:57:a5:df -> 3c:fd:fe:e1:61:08 802.1q vlan 70

00:43:02:603046: ip4-input

  UDP: 172.12.168.9 -> 172.16.101.229

tos 0x00, ttl 253, length 134, checksum 0x75be dscp CS0 ecn NON_ECN

fragment id 0x7ee3, flags DONT_FRAGMENT

  UDP: 58360 -> 4789

length 114, checksum 0x

00:43:02:603110: ip4-lookup

  fib 0 dpo-idx 14 flow hash: 0x

  UDP: 172.12.168.9 -> 172.16.101.229

tos 0x00, ttl 253, length 134, checksum 0x75be dscp CS0 ecn NON_ECN

fragment id 0x7ee3, flags DONT_FRAGMENT

  UDP: 58360 -> 4789

length 114, checksum 0x

00:43:02:603184: ip4-receive

UDP: 172.12.168.9 -> 172.16.101.229

  tos 0x00, ttl 253, length 134, checksum 0x75be dscp CS0 ecn NON_ECN

  fragment id 0x7ee3, flags DONT_FRAGMENT

UDP: 58360 -> 4789

  length 114, checksum 0x

00:43:02:603261: ip4-udp-lookup

  UDP: src-port 58360 dst-port 4789

00:43:02:603342: vxlan4-input

  VXLAN decap from vxlan_tunnel0 vni 5007 next 1 error 0

00:43:02:603421: l2-input

  l2-input: sw_if_index 12 dst cc:cc:cc:dd:dd:01 src 88:d9:8f:25:f9:25 
[l2-learn l2-fwd l2-flood arp-term-l2bd l2-flood ]

00:43:02:603502: l2-learn

  l2-learn: sw_if_index 12 dst cc:cc:cc:dd:dd:01 src 88:d9:8f:25:f9:25 bd_index 
1

00:43:02:603591: l2-fwd

  l2-fwd:   sw_if_index 12 dst cc:cc:cc:dd:dd:01 src 88:d9:8f:25:f9:25 bd_index 
1 result [0x1130d, 13] none

00:43:02:603683: l2-output

  l2-output: sw_if_index

Re: [vpp-dev] MPLS Tunnel Interface on Provider Router

[Neale Ranns]

Hi Sreejith,

There is no CLI for that. Contributions welcome.

/neale

From: vpp-dev@lists.fd.io  on behalf of 
sreejithsurendrannair2 via lists.fd.io 

Date: Friday, 11 February 2022 at 14:37
To: vpp-dev@lists.fd.io 
Subject: Re: [vpp-dev] MPLS Tunnel Interface on Provider Router
Hi All,

I have a query regarding the IP and MPLS FIB counters. Is it possible to clear 
the fib counters for the individual FEC or local label  value.

In the below output if we want to clear the counter for 37.37.37.37/32, is 
there any CLI option to clear the same. I could not find any option to clear ip 
fib counter.

Logs:

IP FIB :
37.37.37.37/32
  unicast-ip4-chain
  [@0]: dpo-load-balance: [proto:ip4 index:24 buckets:1 uRPF:19 to:[10:840]]
[0] [@11]: mpls-label[@1]:[36000:64:0:eos]
[@1]: mpls via 9.1.1.2 GigabitEthernet0/6/0.17512: mtu:1500 next:2 
525400b16c865254005b8a8681098847

Also in the code I saw the counter is reset during the "load_balance_alloc_i" I 
did not observe it reset in another place.
vlib_zero_combined_counter(&(load_balance_main.lbm_to_counters),
   load_balance_get_index(lb));

Can you please suggest if I missed anything is there any CLI or API option to 
reset the IP FIB and MPLS FIB counters.

Thanks & Regards,
Sreejith

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#20862): https://lists.fd.io/g/vpp-dev/message/20862
Mute This Topic: https://lists.fd.io/mt/88418846/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] multipoint ipsec!!

[Neale Ranns]

Hi Sagar,

You protection needs to be for the peer on the tunnel (44.44.44.44) not the 
peer on the Ethernet.

/neale

From: vpp-dev@lists.fd.io  on behalf of sagar g via 
lists.fd.io 
Date: Friday, 11 February 2022 at 12:44
To: vpp-dev@lists.fd.io 
Subject: [vpp-dev] multipoint ipsec!!
Hi All,

Am currently working on supporting the multipoint ipsec interface(p2mp) feature 
on our product.

Issue is that packets are sent out without being encrypted.

Packets are taking following graph nodes path "tcp4-output ---> 
ipv4-lookup--->ip4-midchain---> adj-midchain-tx"

But i want my packets to take "tcp4-output ---> ipv4-lookup--->ip4-midchain---> 
esp4_encrypt_tun-->"

Below is the fib entry,
===
inner packet destination = 44.44.44.44
outer packet(tunnel) destination = 20.20.99.215

44.44.44.44/32
  unicast-ip4-chain
  [@0]: dpo-load-balance: [proto:ip4 index:14 buckets:1 uRPF:16 to:[12:720]]
[0] [@6]: ipv4 via 44.44.44.44 ipip0: mtu:9000 next:12 
45004004626f50505050141463d7
stacked-on entry:13:
  [@2]: dpo-load-balance: [proto:ip4 index:15 buckets:1 uRPF:19 
to:[6:1324] via:[12:960]]
[0] [@5]: ipv4 via 20.20.99.215 VirtualFuncEthernet0/7/0.1556: 
mtu:1500 next:11 fa163e4b6b42fa163eeb7f86810006140800


vpp# show adj nbr
[@16]  ipv4 via 44.44.44.44 ipip0: mtu:9000 next:12 
45004004626f50505050141463d7
  stacked-on entry:13:
[@2]: dpo-load-balance: [proto:ip4 index:15 buckets:1 uRPF:19 to:[8:1540] 
via:[15:1200]]
  [0] [@5]: ipv4 via 20.20.99.215 VirtualFuncEthernet0/7/0.1556: mtu:1500 
next:11 fa163e4b6b42fa163eeb7f86810006140800



ipsec protect output.

vpp# show ipsec protect
ipip0: 20.20.99.215
 output-sa:
  [0] sa 68092 (0x109fc) spi 3249629366 (0xc1b168b6) protocol:esp 
flags:[anti-replay ]
 input-sa:
  [1] sa 68093 (0x109fd) spi 12413 (0x307d) protocol:esp flags:[anti-replay 
inbound ]


Can you please point out any basic issue with my routing or any issue here?

Thanks,
Sagar

--
Regards,
sagar g

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#20861): https://lists.fd.io/g/vpp-dev/message/20861
Mute This Topic: https://lists.fd.io/mt/89069167/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] VXLAN overlay routing

[Neale Ranns]

L3 mode means there is no L2 header. Both ends need to agree to that.

/neale

From: vpp-dev@lists.fd.io  on behalf of David Gohberg via 
lists.fd.io 
Date: Sunday, 6 February 2022 at 15:57
To: vpp-dev@lists.fd.io 
Subject: Re: [vpp-dev] VXLAN overlay routing
Hi,

I'm not interested in bridging so I tried creating the tunnels in L3 mode
and perform routing between VNI 50 and VNI 70 using 2 linux namespaces :
create loopback interface
set interface mac address loop0 02:10:18:34:9f:cd
set interface ip address loop0  11.11.11.3/24
set int l2 bridge loop0 1
set int state loop0 up

create host-interface name eth-t1
create host-interface name eth-t2
set interface ip address host-eth-t1 11.11.10.3/24

set interface state host-eth-t1 up
set interface state host-eth-t2 up
set interface mac address host-eth-t1 02:fe:ef:20:a0:ed

create vxlan tunnel src 11.11.11.3 dst 100.0.0.2 vni 50 l3
create vxlan tunnel src 11.11.11.3 dst 101.0.0.2 vni 70 l3

ip route add 100.0.0.2/32 via 11.11.11.3 loop0
ip route add 101.0.0.2/32 via 11.11.11.3 loop0
Sending this packet from host-eth-t1:

Ether(dst="02:fe:ef:20:a0:ed")/IP(dst="11.11.11.3",src="100.0.0.2")/UDP(sport=1337,dport=4789)/VXLAN(vni=50,flags=8)/Ether()/IP()/UDP()
As a first stage, I'm trying to just have the packet go through vxlan decap and 
perform ip4 lookup (which currently should not find a suitable route). However, 
after vxlan decap inner ethernet header is treated as IP header:
00:00:43:753410: ip4-udp-lookup
  UDP: src-port 1337 dst-port 4789
00:00:43:753414: vxlan4-input
  VXLAN decap from vxlan_tunnel0 vni 50 next 2 error 0
00:00:43:753417: ip4-input
  unknown 238: 8.0.69.0 -> 0.28.0.1
version 10, header length 40
I'm probably making a simple mistake in my setup.

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#20849): https://lists.fd.io/g/vpp-dev/message/20849
Mute This Topic: https://lists.fd.io/mt/88906491/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] VXLAN overlay routing

[Neale Ranns]

Hi David,

If you want to combine L2 and L3 forwarding on a VXLAN interface, use a BVI as 
Petr suggests. If you want the VXLAN tunnels to only act like an L3 interface, 
then you can use create the tunnels in L3 mode.

/neale


From: vpp-dev@lists.fd.io  on behalf of Petr Boltík via 
lists.fd.io 
Date: Friday, 4 February 2022 at 15:15
To: David Gohberg 
Cc: vpp-dev 
Subject: Re: [vpp-dev] VXLAN overlay routing
Hi,

as in the article mentioned at the link 
https://wiki.fd.io/view/VPP/Using_VPP_as_a_VXLAN_Tunnel_Terminator - you can 
use bridge domain with BVI.

Petr

pá 4. 2. 2022 v 14:52 odesílatel David Gohberg 
mailto:gohb...@gmail.com>> napsal:
Hello,

All of the VXLAN use cases I've found make VPP act as a VXLAN endpoint, example:
https://wiki.fd.io/view/VPP/Using_VPP_as_a_VXLAN_Tunnel_Terminator

The packet is either going through vxlan encap or decap. What I want is to have 
a packet
flow that:

1. performs vxlan decap -> routing on the overlay packet -> vxlan encap, such 
as in the case of overlay routing between 2 VNIs.
2. allows configuring overlay routes in VPP that points to VXLAN tunnels.

Is this supported natively in VPP? If so, is there an example configuration 
sequence I can use as a reference?

Thanks,
David



-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#20832): https://lists.fd.io/g/vpp-dev/message/20832
Mute This Topic: https://lists.fd.io/mt/88906491/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] MPLS Tunnel Interface on Provider Router

[Neale Ranns]

From: vpp-dev@lists.fd.io  on behalf of Amit Mehra via 
lists.fd.io 
Date: Monday, 17 January 2022 at 09:30
To: vpp-dev@lists.fd.io 
Subject: Re: [vpp-dev] MPLS Tunnel Interface on Provider Router
Thanks Neale for the response.

We are trying to simulate L3VPN usecase and want to maintain counters per 
FEC(on both PE and P nodes).
Yes, we can achieve label swap/pop without tunnel interface too but that way we 
are not maintaining per FEC counters. As per my understanding, with tunnels, we 
can have counters per FEC.

VPP keeps counters for each entry in the MPLS table. Each entry represents a 
local label and so a FEC.


 forwarding:   mpls-neos-chain

  [@0]: dpo-load-balance: [proto:mpls index:21 buckets:1 uRPF:21 to:[0:0]]   
<<< Here at the end.

You can also get them from the stats segment.


I have few follow-up questions based on your responses

  1.  Are tunnel interfaces meant only for having statistics per FEC or are 
there any other usecase for creating mpls tunnel? In other words, we can 
achieve label encapsulation, label swap/pop operations without tunnel too then 
what's the need of having a tunnel?

Two reason of the top of my head;
1 – to change the topology of the network. For example the tunnel could be a 
link visible to the IGP
2 – to send a packet whose addresses are not understood by the network, i.e. v4 
packet over a v6 network.

2) As per the sample configuration of L3VPN given in 
https://wiki.fd.io/view/VPP/MPLS_FIB, tunnel interface is not considered. Any 
reason why tunnel interface is not considered for realizing L3VPN ? Does it 
have any other implication (if considered for L3VPN) or we can configure L3VPN 
even with tunnel interface (on both PE and P devices) too and it would be 
another alternative way?

Tunnels don’t scale. You can’t create as many tunnels as one might have routes 
in an L3VPN.

There are lots of good free resources on L3VPN architecture that can explain 
more than I will ever know 😉

/neale

Regards
Amit

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#20743): https://lists.fd.io/g/vpp-dev/message/20743
Mute This Topic: https://lists.fd.io/mt/88418846/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] MPLS Tunnel Interface on Provider Router

[Neale Ranns]

Hi Amit,

From: vpp-dev@lists.fd.io  on behalf of Amit Mehra via 
lists.fd.io 
Date: Friday, 14 January 2022 at 12:50
To: vpp-dev@lists.fd.io 
Subject: [vpp-dev] MPLS Tunnel Interface on Provider Router

Hi,



I was doing a PoC to simulate label swap operation on Service Provider 
Router(non PE Routers) by creating a mpls tunnel interface and using that 
tunnel interface as a target in mpls route entry.



Reference:https://wiki.fd.io/view/VPP/MPLS_FIB



Please find below the set of configs that I tried and the corresponding 
observation with VPP 21.01



Config 1: Configured MPLS FIB entry without eos bit set.

mpls table add 0

set interface mpls GigabitEthernet0/6/0 enable--->Incoming 
Interface is GigabitEthernet0/6/0

set interface mpls GigabitEthernet0/7/0 enable--->Outgoing 
Interface is GigabitEthernet0/7/0

mpls tunnel add via 10.10.10.10 GigabitEthernet0/7/0 out-labels 44

set interface state mpls-tunnel0 up

mpls local-label add 33 via mpls-tunnel0



non-eos is the default when programming local-labels. In order to forward 
non-eos traffic the egress path must have output labels. This is so that the 
next label in the stack is not exposed, accidently, to the next/intermediate 
devices. If the next label in the stack is meant for the next downstream 
device, i.e. it is directly connected, then you must specify and out-label of 
implicit-null. i.e:

  mpls local-label add 33 non-eos via 0.0.0.0 mpls-tunnel0 out-labels 
implicit-null



Expectation:- On receiving an MPLS encapsulated label with in-label as 33 and 
without "eos" bit set, it should swap the label 33 with label 44 and send to 
it's neighbor i.e. 10.10.10.10 via GigabitEthernet0/7/0 interface.

Observation:- I am seeing the forwarding action as dpo-drop in mpls fib table. 
Please find the output of mplf-fib tables below

33:neos/21 fib:0 index:18 locks:2

  CLI refs:1 entry-flags:attached, src-flags:added,contributing,active,

path-list:[25] locks:2 flags:shared, uPRF-list:21 len:1 itfs:[96, ]

  path:[27] pl-index:25 mpls weight=1 pref=0 attached-nexthop:  
oper-flags:resolved, cfg-flags:attached,

2100::200:0:0:0 mpls-tunnel0 (p2p)

  [@0]: mpls via 0.0.0.0 mpls-tunnel0: mtu:9000 next:2

 stacked-on:

   [@2]: dpo-load-balance: [proto:mpls index:20 buckets:1 uRPF:-1 
to:[0:0]]

 [0] [@6]: mpls-label[@0]:[44:64:0:neos]

 [@1]: arp-mpls: via 10.10.10.10 GigabitEthernet0/7/0

 forwarding:   mpls-neos-chain

  [@0]: dpo-load-balance: [proto:mpls index:21 buckets:1 uRPF:21 to:[0:0]]

[0] [@0]: dpo-drop mpls



On receiving an MPLS packet, it is getting dropped in mpls-lookup node. Please 
find the vpp trace output below.



..snip…



Config 2:- Configured MPLS FIB entry with eos bit set.

mpls table add 0

set interface mpls GigabitEthernet0/6/0 enable--->Incoming 
Interface is GigabitEthernet0/6/0

set interface mpls GigabitEthernet0/7/0 enable--->Outgoing 
Interface is GigabitEthernet0/7/0

mpls tunnel add via 10.10.10.10 GigabitEthernet0/7/0 out-labels 44

set interface state mpls-tunnel0 up

mpls local-label add 33 eos via mpls-tunnel0



when programming eos routes, it is necessary for VPP to know what type of 
traffic is exposed when the label is popped. When programming via the API 
you’ll see that this is an input parameter. However, the CLI takes a shortcut 
and attempts to derive it from the next-hop address path. Your path though is 
attached (it doesn’t specify a next-hop) so this doesn’t work and the wheels 
fall off. If you change the CLI command to:

  mpls local-label add 33 eos via 0.0.0.0 mpls-tunnel0

it will work. Clearly that assumes IPv4 is being carried.





Expectation:- On receiving an MPLS encapsulated label with in-label as 33 and 
with "eos" bit set, it should swap the label 33 with label 44 and send to it's 
neighbor i.e. 10.10.10.10 via GigabitEthernet0/7/0 interface.

Observation:- Observing a crash in vpp on issuing the CLI "mpls local-label add 
33 eos via mpls-tunnel0". Is this some known issue?

The following is the stack trace



…snip…



The only difference between config 1 and config 2 was that of "eos" bit i.e. 
bit was set in the latter.



Config 3:- Also, I tried configuring PE Router by creating tunnel interface and 
used that interface as a target in IP Route.

Following is the config used.

mpls table add 0

set interface mpls GigabitEthernet0/6/0 enable--->Incoming 
Interface is GigabitEthernet0/6/0

set interface mpls GigabitEthernet0/7/0 enable--->Outgoing 
Interface is GigabitEthernet0/7/0

mpls tunnel add via 20.20.20.20 GigabitEthernet0/7/0 out-labels 44

set interface state mpls-tunnel0 up

ip route add 10.10.10.10/32 via mpls-tunnel0-->It seems to be 
working as expected



Expectation:- On receiving IP packet, it should be able to encapsulate an MPLS 
header with label 44 and send the packet out via GigabitEthe

Re: [vpp-dev] VXLAN and RSS

[Neale Ranns]

Hi Pim,

The logic there (I think) is that the since the source port is the one you send 
with, it is also the one you receive on, so the source-port setting determines 
the key to match incoming traffic, i.e. it’s the peer’s dst-port.

/neale

From: Pim van Pelt 
Date: Friday, 14 January 2022 at 11:28
To: Neale Ranns 
Cc: vpp-dev 
Subject: Re: [vpp-dev] VXLAN and RSS
Hoi,

Neale, thank you for pointing that out! I verified the intent, and I can 
confirm that VXLAN uses random source ports [1], and so does GENEVE [2], so 
this is WAI. I mirrored traffic between the two VPP hosts, while running a 
T-Rex bench.py with vm=var2 to scramble the src/dst IP addresses of the inner 
payload. It resulted in the outer src_port scrambling, which is great. So it 
seems I was reading the wrong part of the vxlan source code, and the thing I 
wanted is already there. I'll update my article with this info, and I'm only 
left wondering why there would be an option to set src_port when creating a 
VXLAN tunnel (such an option is not present in GENEVE)?

create vxlan tunnel src  {dst |group 
 } vni  [instance ] [encap-vrf-id ] 
[decap-next [l2|node ]] [del] [l3] [src_port ] 
[dst_port ]
create geneve tunnel local  {remote |group 
 } vni  [encap-vrf-id ] [decap-next 
[l2|node ]] [l3-mode] [del]

groet,
Pim

[1] (on the mirrored interface, watching traffic between rhino:Hu12/0/1 and 
hippo:Hu12/0/1) tcpdump -ni enp5s0f3 port 4789
11:19:54.887763 IP 10.0.0.1.4452 > 10.0.0.0.4789: VXLAN, flags [I] (0x08), vni 
8298
11:19:54.888283 IP 10.0.0.1.42537 > 10.0.0.0.4789: VXLAN, flags [I] (0x08), vni 
8298
11:19:54.888285 IP 10.0.0.0.17895 > 10.0.0.1.4789: VXLAN, flags [I] (0x08), vni 
8298
11:19:54.899353 IP 10.0.0.1.40751 > 10.0.0.0.4789: VXLAN, flags [I] (0x08), vni 
8298
11:19:54.899355 IP 10.0.0.0.35475 > 10.0.0.1.4789: VXLAN, flags [I] (0x08), vni 
8298
11:19:54.904642 IP 10.0.0.0.60633 > 10.0.0.1.4789: VXLAN, flags [I] (0x08), vni 
8298
11:19:54.908642 IP 10.0.0.1.54881 > 10.0.0.0.4789: VXLAN, flags [I] (0x08), vni 
8298
11:19:54.910201 IP 10.0.0.1.11787 > 10.0.0.0.4789: VXLAN, flags [I] (0x08), vni 
8298
11:19:54.910204 IP 10.0.0.0.13300 > 10.0.0.1.4789: VXLAN, flags [I] (0x08), vni 
8298
11:19:54.919702 IP 10.0.0.1.55752 > 10.0.0.0.4789: VXLAN, flags [I] (0x08), vni 
8298
11:19:54.919714 IP 10.0.0.0.22122 > 10.0.0.1.4789: VXLAN, flags [I] (0x08), vni 
8298
11:19:54.944301 IP 10.0.0.0.42756 > 10.0.0.1.4789: VXLAN, flags [I] (0x08), vni 
8298
11:19:54.944303 IP 10.0.0.1.8992 > 10.0.0.0.4789: VXLAN, flags [I] (0x08), vni 
8298
11:19:54.954043 IP 10.0.0.1.49613 > 10.0.0.0.4789: VXLAN, flags [I] (0x08), vni 
8298
11:19:54.954045 IP 10.0.0.0.16483 > 10.0.0.1.4789: VXLAN, flags [I] (0x08), vni 
8298
11:19:54.954411 IP 10.0.0.0.37118 > 10.0.0.1.4789: VXLAN, flags [I] (0x08), vni 
8298
11:19:54.954412 IP 10.0.0.1.26825 > 10.0.0.0.4789: VXLAN, flags [I] (0x08), vni 
8298
11:19:54.959725 IP 10.0.0.1.5643 > 10.0.0.0.4789: VXLAN, flags [I] (0x08), vni 
8298

[1] (on the mirrored interface, watching traffic between rhino:Hu12/0/1 and 
hippo:Hu12/0/1) tcpdump -ni enp5s0f3 port 6081
11:20:55.802406 IP 10.0.0.0.32299 > 10.0.0.1.6081: Geneve, Flags [none], vni 
0x206a: IP 16.0.0.45.1025 > 48.0.0.45.12: UDP, length 18
11:20:55.802409 IP 10.0.0.1.44011 > 10.0.0.0.6081: Geneve, Flags [none], vni 
0x206a: IP 48.0.0.45.1025 > 16.0.0.45.12: UDP, length 18
11:20:55.807711 IP 10.0.0.1.45503 > 10.0.0.0.6081: Geneve, Flags [none], vni 
0x206a: IP 48.0.0.47.1025 > 16.0.0.47.12: UDP, length 18
11:20:55.807712 IP 10.0.0.0.45532 > 10.0.0.1.6081: Geneve, Flags [none], vni 
0x206a: IP 16.0.0.47.1025 > 48.0.0.47.12: UDP, length 18
11:20:55.841494 IP 10.0.0.1.10795 > 10.0.0.0.6081: Geneve, Flags [none], vni 
0x206a: IP 48.0.0.50.1025 > 16.0.0.50.12: UDP, length 18
11:20:55.841495 IP 10.0.0.0.61694 > 10.0.0.1.6081: Geneve, Flags [none], vni 
0x206a: IP 16.0.0.50.1025 > 48.0.0.50.12: UDP, length 18
11:20:55.851719 IP 10.0.0.1.47581 > 10.0.0.0.6081: Geneve, Flags [none], vni 
0x206a: IP 48.0.0.48.1025 > 16.0.0.48.12: UDP, length 18
11:20:55.851719 IP 10.0.0.0.52458 > 10.0.0.1.6081: Geneve, Flags [none], vni 
0x206a: IP 16.0.0.48.1025 > 48.0.0.48.12: UDP, length 18
11:20:55.851772 IP 10.0.0.0.12360 > 10.0.0.1.6081: Geneve, Flags [none], vni 
0x206a: IP 16.0.0.52.1025 > 48.0.0.52.12: UDP, length 18
11:20:55.855768 IP 10.0.0.1.39531 > 10.0.0.0.6081: Geneve, Flags [none], vni 
0x206a: IP 48.0.0.52.1025 > 16.0.0.52.12: UDP, length 18
11:20:55.856296 IP 10.0.0.0.28635 > 10.0.0.1.6081: Geneve, Flags [none], vni 
0x206a: IP 16.0.0.51.1025 > 48.0.0.51.12: UDP, length 18

On Fri, Jan 14, 2022 at 10:40 AM Neale Ranns 
mailto:ne...@graphiant.com>> wrote:
Hi Pim,

For VXLAN the intention is to use random source ports. The code you sight 
builds the ‘static’ portion of the imposed header. The source ports are 
overwritten with the hash of the e

Re: [vpp-dev] VXLAN and RSS

[Neale Ranns]

Hi Pim,

For VXLAN the intention is to use random source ports. The code you sight 
builds the ‘static’ portion of the imposed header. The source ports are 
overwritten with the hash of the encapped packet in encap.c:246

/neale


From: vpp-dev@lists.fd.io  on behalf of Pim van Pelt via 
lists.fd.io 
Date: Thursday, 13 January 2022 at 23:37
To: vpp-dev 
Subject: [vpp-dev] VXLAN and RSS
Hoi folks,

I did a deep dive today on VXLAN, GENEVE and compared it to GRE and L2XC - the 
full read is here:
https://ipng.ch/s/articles/2022/01/13/vpp-l2.html

One thing that I observed is that both VXLAN and GENEVE use static source 
ports. In the case of VLLs, (an l2 xconnect from a customer ethernet interface 
into a tunnel), the customer port will be receiving IPv4 or IPv6 traffic 
(either tagged or untagged) and this allows the NIC to use RSS to assign this 
inbound traffic to multiple queues, and thus multiple CPU threads. That’s 
great, it means linear encapsulation performance.
However,, once the traffic is encapsulated, it’ll become single flow with 
respect to the remote host, ie we're sending from 
10.0.0.0:4789 to the remote 
10.0.0.1:4789 and it is for this reason, that all 
decapsulation is single threaded.
One common approach is to use an ingress hash algorithm to choose from a pool 
of source ports, or possibly a simpler round-robin over a pool of ports 
4000-5000, say, based on the inner payload. That way, the remote would be able 
to use multiple RSS queues. However, VPP currently does not implement that.

I think the original author has this in mind as a future improvement based on 
the comment on L295 in vxlan.c
  /* UDP header, randomize src port on something, maybe? */
  udp->src_port = clib_host_to_net_u16 (t->src_port);
  udp->dst_port = clib_host_to_net_u16 (t->dst_port);

What would it take for src_port to not be static? It would greatly improve 
VXLAN (and similarly, GENEVE) throughput on ingress.

groet,
Pim
--
Pim van Pelt mailto:p...@ipng.nl>>
PBVP1-RIPE - http://www.ipng.nl/

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#20713): https://lists.fd.io/g/vpp-dev/message/20713
Mute This Topic: https://lists.fd.io/mt/88408739/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] MPLS: fib table 1 display issue #mpls

[Neale Ranns]

You are configuring it incorrectly. Please re-read the emails I have already 
sent you.

/neale


From: vpp-dev@lists.fd.io  on behalf of Sastry Sista via 
lists.fd.io 
Date: Thursday, 30 December 2021 at 04:49
To: vpp-dev@lists.fd.io 
Subject: Re: [vpp-dev] MPLS: fib table 1 display issue #mpls
On Mon, Dec 13, 2021 at 08:39 AM, Sastry Sista wrote:
Hi Neale,
I have used only these 2 below and its not crashing but 
"MPLS DROP DPO".

vppctl ip route add table 2 1.1.1.1/32 via 107.243.21.116 
VirtualFuncEthernet0/9/0.1800 out-labels 18

vppctl mpls local-label 17 1.1.1.2/32 via ip4-lookup-in-table 2

Here, I have created loop18 at table 2 and added 1.1.1.2/24. With and without 
loop18 is also not working.

Do you say that loop18 is not suggested?

If bind works,  I love to use bind/unbind rather MPLS route (ILM route).

I am sure its crashing for those 2 lines when we receive mpls ping req from 
peer.

One more point is, I am using VL_APIs  only and hope they work fine.

With Regards
Sastry
Hi Neale,
 Could you pls help me above?
With Regards
Sastry

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#20676): https://lists.fd.io/g/vpp-dev/message/20676
Mute This Topic: https://lists.fd.io/mt/87373182/21656
Mute #mpls:https://lists.fd.io/g/vpp-dev/mutehashtag/mpls
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [vpp-dev] searching for all routes that point to an attached next-hop neighbor #routing

[Neale Ranns]

Hi David,

Here’s some back ground on FIB graph walks:
  
https://s3-docs.fd.io/vpp/21.10/gettingstarted/developers/fib20/graphwalks.html

I can’t think of any examples similar to what you are attempting, but you could 
conceivably achieve it with:
1 – a pub/sub API. Similar to want_ip_neighbor_events
2 – when an ip-neighbour resolution state changes walk all the adjacencies for 
that next-hop. You’ve probably already seen uses of adj_nbr_walk_nh() in the 
ip-neighbour code to do this
3 – from the adjacency back walk the FIB graph with fib_walk_[a]sync(). You’ll 
need to define a new back-walk type. In fib_entry_back_walk_notify you can push 
an event to your subscribers. You can decide at this point if you want to 
continue the walk to recursive prefixes or not.

For 1 you can work in a plugin, for 2 and 3 you’ll need to change the core code.

Have fun,
neale

From: vpp-dev@lists.fd.io  on behalf of David Gohberg via 
lists.fd.io 
Date: Wednesday, 29 December 2021 at 13:09
To: vpp-dev@lists.fd.io 
Subject: Re: [vpp-dev] searching for all routes that point to an attached 
next-hop neighbor #routing
Hi Neale,

I have a custom plugin in which I want to extract this information and I much 
prefer this approach.
Do you have any references on how to walk the FIB graph or existing features 
that perform similar tasks?

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#20673): https://lists.fd.io/g/vpp-dev/message/20673
Mute This Topic: https://lists.fd.io/mt/87917518/21656
Mute #routing:https://lists.fd.io/g/vpp-dev/mutehashtag/routing
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [vpp-dev] searching for all routes that point to an attached next-hop neighbor #routing

[Neale Ranns]

Hi David,

Are you hoping to get these routes from queries via the CLI/API or are you 
prepared to write a plugin in VPP to extract and publish this information to 
your control plane via new events? For the former, Stanislav’s advice is your 
best option. So I would suggest you consider the latter, then you have the 
option of walking the FIB graph from the neighbour/adjacency and pushing to the 
CP all the routes that were affected.

/neale

From: vpp-dev@lists.fd.io  on behalf of David Gohberg via 
lists.fd.io 
Date: Thursday, 23 December 2021 at 17:55
To: vpp-dev@lists.fd.io 
Subject: Re: [vpp-dev] searching for all routes that point to an attached 
next-hop neighbor #routing
posting again because not sure message went through:

Thanks for the quick reply Stanislav,

I'm inserting hooks into the VPP control plane in order to offload certain 
information to an external hardware dataplane.
In the case of route resolutions, I want to be able to say : "Ok, I got the arp 
reponse for 10.0.0.2, let's get all the routes that point to this nexthop"
so I can send them to the hardware.
For now, routes are added using vpp cli, but this logic should hold regardless 
of the route source (BGP etc).

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#20671): https://lists.fd.io/g/vpp-dev/message/20671
Mute This Topic: https://lists.fd.io/mt/87917518/21656
Mute #routing:https://lists.fd.io/g/vpp-dev/mutehashtag/routing
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [vpp-dev] MPLS: fib table 1 display issue #mpls

[Neale Ranns]

Hi Sastry,

For the last time… you bind a label to a prefix first by defining the 
forwarding for the prefix:
  Ip route table X 1.2.3.4/32 via 10.10.10.10 eth0
And then you bind a label to it:
  Mpls local-label 44 1.2.3.4/32 table X

That’s all.

If you’re building a product, then you are strongly encouraged to use the API 
(the debug CLI is not supported), and the API makes this distinction between 
forwarding and binding more clear.

Regards,
Neale


From: vpp-dev@lists.fd.io  on behalf of Sastry Sista via 
lists.fd.io 
Date: Saturday, 11 December 2021 at 04:47
To: vpp-dev@lists.fd.io 
Subject: Re: [vpp-dev] MPLS: fib table 1 display issue #mpls
Hi Neale,
  I tried all combinations of bind (vppctl mpls local-label 
17 1.1.1.2/32). Vpp is crashing once we receive mpls ping req.

I am using fdio 20.05.

Please confirm if its an open bug:

crashed with below:
=

vppctl ip route add table 2 1.1.1.1/32 via 107.243.21.116 
VirtualFuncEthernet0/9/0.1800 out-labels 18

vppctl mpls local-label 17 eos via ip4-lookup-in-table 2
vppctl mpls local-label 17 1.1.1.2/32

crashed with below also:


vppctl ip route add table 2 1.1.1.1/32 via 107.243.21.116 
VirtualFuncEthernet0/9/0.1800 out-labels 18

vppctl mpls local-label 17 1.1.1.2/32 eos via ip4-lookup-in-table 2

With Regards
Sastry

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#20624): https://lists.fd.io/g/vpp-dev/message/20624
Mute This Topic: https://lists.fd.io/mt/87373182/21656
Mute #mpls:https://lists.fd.io/g/vpp-dev/mutehashtag/mpls
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [vpp-dev] MPLS: fib table 1 display issue #mpls

[Neale Ranns]

From: vpp-dev@lists.fd.io  on behalf of Sastry Sista via 
lists.fd.io 
Date: Thursday, 9 December 2021 at 02:17
To: vpp-dev@lists.fd.io 
Subject: Re: [vpp-dev] MPLS: fib table 1 display issue #mpls
Hi Neale,
  Thank you for detailed explanation. Its working fine by 
providing nh and interface.

Just a small Q:

without bind API, label to prefix, I could manage to make this working.

I just wanted to know what is the real value of bind API?

Is it that bind will just help us to get label and prefix ?. anyway there is no 
dump of bind also.

I can add as many as labels to same VRF using (vppctl mpls local-label 17 eos 
via ip4-lookup-in-table 2)

how is it different when I bind label and prefix?

any performance improvements using bind?

Yes. Try it and see. Compare the packet traces.

/neale


With Regards
Sastry

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#20613): https://lists.fd.io/g/vpp-dev/message/20613
Mute This Topic: https://lists.fd.io/mt/87373182/21656
Mute #mpls:https://lists.fd.io/g/vpp-dev/mutehashtag/mpls
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [vpp-dev] MPLS: fib table 1 display issue #mpls

[Neale Ranns]

From: vpp-dev@lists.fd.io  on behalf of Sastry Sista via 
lists.fd.io 
Date: Wednesday, 8 December 2021 at 03:35
To: vpp-dev@lists.fd.io 
Subject: Re: [vpp-dev] MPLS: fib table 1 display issue #mpls
Hi Neale,
   Thank you for the help. We are trying to exercise vpp mpls 
vpn and we are preferring label per prefix only. Anyway I am fine even with per 
VRF label but  adding more local labels which seems fine while adding.

I am trying to evaluate VRF with non-default ip fib tables.

While I tried default VRF, I always see mpls out-label and dpo rules as below:

Example: Case 1, with default VRF
=

vppctl ip route add 1.1.1.1/32 via 107.243.21.116 VirtualFuncEthernet0/9/0.1800 
out-labels 18

this is a non-recursive route, that is you have specified both the next-hop and 
the interface. Forwarding state can thus be built directly from the adjacency 
with that {nh,interface} key.


for this, I see sh ip fib

1.1.1.1/32

  unicast-ip4-chain

  [@0]: dpo-load-balance: [proto:ip4 index:134 buckets:1 uRPF:160 to:[0:0]]

[0] [@16]: mpls-label[@1]:[18:64:0:eos]



[@1]: mpls via 107.243.21.116 VirtualFuncEthernet0/9/0.1800: mtu:9000 
next:2 fa163e9c9c94fa163ebe37d3810007088847

This is indicating use mpls proto and out label as 18.

Case2: Non default VRF i.e table 2:
=

ip route add table 2 1.1.1.1/32 via 107.243.21.116 next-hop-table 0 out-labels 
18

this is a recursive route, you have only passed the next-hop. Forwarding state 
is built by recursing through/stacking on the forwarding state built for the 
next-hop (which we sometimes refer to as the via-fib in this scenario). If the 
recursive route has outgoing labels, the it must stack on the non-eos chain/DPO 
of the via-fib (you can include the ‘details’ keyword in the show command to 
see all of an entry’s chains). If the via FIB does not have a non-eos chain 
then the recursive route must drop. A via-fib will not have a non-eos chain if 
it does not have out-going labels of its own.

The reason for this is that the device that is advertising the label for the 
recursive route might not be directly connected (maybe it’s an iBGP peer). 
Therefore if we were to forward packets from the device with only that label, 
then that label would be seen by an intermediate device for whom the label 
value means something different and would thus result in mis-forwarding, which 
must not happen.

If the peer advertising the recursive route is directly connected (an eBGP 
peer) and so the via-fib is an adj-fib (i.e. it matches an ARP entry) then you 
need to add an implicit-null label as an out-label. This is how the control 
plane explicitly states that it is safe to forward with only the label of the 
recursive route.

/neale


VRF is table 2 and outer VRF for L2 is table 0.

sh ip fib table 2

1.1.1.1/32

  unicast-ip4-chain

  [@0]: dpo-load-balance: [proto:ip4 index:129 buckets:1 uRPF:160 to:[0:0]]



[0] [@0]: dpo-drop ip4

No out-label or mpls dpo rule. Rather its a drop.

Could you please let me know if I have to use always 2 out-labels for non 
default VRF cases?

As per your doc: non default VRF:

ip route add 10.0.0.1/32 via 192.168.1.2 Eth0 out-labels 33

VRF at table 2

ip route add table 2 10.10.10.0/24 via 10.0.0.1 next-hop-table 0 out-label 121

With Regards
Sastry

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#20600): https://lists.fd.io/g/vpp-dev/message/20600
Mute This Topic: https://lists.fd.io/mt/87373182/21656
Mute #mpls:https://lists.fd.io/g/vpp-dev/mutehashtag/mpls
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [vpp-dev] MPLS: fib table 1 display issue #mpls

[Neale Ranns]

From: vpp-dev@lists.fd.io  on behalf of Sastry Sista via 
lists.fd.io 
Date: Thursday, 2 December 2021 at 13:25
To: vpp-dev@lists.fd.io 
Subject: Re: [vpp-dev] MPLS: fib table 1 display issue #mpls
Thank you Neale. We may need to develop something like show mpls bind for our 
purpose.

My test setup ping is not working. Error is :  "MPLS DROP DPO"  because of fib 
next node is drop-dpo. COuld you please help me what is worng?

I am trying to try mpls ping between 1.1.1.1/24 to 2.2.2.2/24.
vpp is one side having local-label = 102
router label = 103

VPP side commands:
=
mpls table add 0
set interface mpls VirtualFuncEthernet0/8/0.1800 enable ( IP addr: 
107.243.21.115)
ip route add 2.2.2.2/24 via 107.243.21.115 VirtualFuncEthernet0/8/0.1800 
out-labels 103
mpls local-label 102 add 1.1.1.1/24 non-eos via 107.243.21.115 
VirtualFuncEthernet0/8/0.1800 out-labels 103
This local-label config is incorrect – the CLI should probably be fixed to 
reject it. When you are binding a label to a prefix, first you add the route
  ip route 1.1.1.1/24 non-eos via 107.243.21.115 VirtualFuncEthernet0/8/0.1800 
out-labels 103
then you bind the label to the same prefix
  mpls local-label 102 1.1.1.1/24
then the [n]eos forwarding for label 102 will be derived from the paths 
configured for 1.1.1.1/24
/neale




sh mpls fib:
=
vpp# show mpls fib 102
MPLS-VRF:0, fib_index:0 locks:[CLI:2, ]
102:neos/21 fib:0 index:127 locks:2
  special refs:1 entry-flags:exclusive, src-flags:added,contributing,active,
path-list:[145] locks:2 flags:exclusive, uPRF-list:164 len:0 itfs:[]
  path:[219] pl-index:145 mpls weight=1 pref=0 exclusive:  
oper-flags:resolved, cfg-flags:exclusive,
[@0]: dpo-load-balance: [proto:mpls index:122 buckets:1 uRPF:165 
to:[0:0]]
  [0] [@0]: dpo-drop mpls

 forwarding:   mpls-neos-chain
  [@0]: dpo-load-balance: [proto:mpls index:122 buckets:1 uRPF:165 to:[0:0]]
[0] [@0]: dpo-drop mpls
102:eos/21 fib:0 index:119 locks:3
  special refs:1 entry-flags:exclusive, src-flags:added,contributing,active,
path-list:[147] locks:2 flags:exclusive, uPRF-list:166 len:0 itfs:[]
  path:[221] pl-index:147 mpls weight=1 pref=0 exclusive:  
oper-flags:resolved, cfg-flags:exclusive,
[@0]: dpo-load-balance: [proto:mpls index:132 buckets:1 uRPF:165 
to:[0:0]]
  [0] [@0]: dpo-drop mpls

  CLI refs:1 src-flags:added,
path-list:[146] locks:1 flags:exclusive, uPRF-list:167 len:1 itfs:[35, ]
  path:[222] pl-index:146 ip4 weight=1 pref=0 attached-nexthop:  
oper-flags:resolved,
107.243.21.115 VirtualFuncEthernet0/8/0.1800
  [@0]: arp-ipv4: via 107.243.21.115 VirtualFuncEthernet0/8/0.1800
Extensions:
 path:222  labels:[[103 pipe ttl:0 exp:0]]
 forwarding:   mpls-eos-chain
  [@0]: dpo-load-balance: [proto:mpls index:132 buckets:1 uRPF:165 to:[0:0]]
[0] [@0]: dpo-drop mpls


With Regards
Sastry


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#20598): https://lists.fd.io/g/vpp-dev/message/20598
Mute This Topic: https://lists.fd.io/mt/87373182/21656
Mute #mpls:https://lists.fd.io/g/vpp-dev/mutehashtag/mpls
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [vpp-dev] Use ABF to route UDP traffic to different paths

[Neale Ranns]

Hi Wei,

I think you need to specify proto=UDP in your ACL setup so that your desired 
port is honoured.

You might also want to pass a ‘priority’ to your attachments so they run in a 
deterministic order.

/neale


From: Wei Huang 
Date: Tuesday, 7 December 2021 at 20:13
To: vpp-dev@lists.fd.io 
Cc: Neale Ranns 
Subject: Use ABF to route UDP traffic to different paths
On my VPP setup, I have two IPSec tunnels can reach 192.168.200.0/24, the 
interfaces for those two IPSec tunnels are ipip0 and ipip1.
I try to set up abf to direct UDP packets to 192.168.200.20 based on 
destination port. If dport is 5001, use ipip0, if dport is 5002, use ipip1.
All those packets will be received on interface tn-eth2.
When I send iperf UDP traffic to 192.168.200.20 dport 5001, dport 5002, from 
packet trace, I can see they go to abf-input-ip4, but they all use ipip0.
Could you please point me what's wrong in the configuration commands? Thanks in 
advance.

This is the commands I used to set the abf:
VAT#acl_add_replace permit dst 192.168.200.0/24 dport 5001
vl_api_acl_add_replace_reply_t_handler:72: ACL index: 0
VAT#acl_add_replace permit dst 192.168.200.0/24 dport 5002
vl_api_acl_add_replace_reply_t_handler:72: ACL index: 1

vppctl abf policy add id 0 acl 0 via ipip0
vppctl abf policy add id 1 acl 1 via ipip1

vppctl abf attach ip4 policy 0 tn-eth2
vppctl abf attach ip4 policy 1 tn-eth2

vpp# show acl-plugin acl
acl-index 0 count 1 tag {}
  0: ipv4 permit src 0.0.0.0/0 dst 192.168.200.0/24 proto 0 sport 
0-65535 dport 5001
  used in lookup context index: 0
acl-index 1 count 1 tag {}
  0: ipv4 permit src 0.0.0.0/0 dst 192.168.200.0/24 proto 0 sport 
0-65535 dport 5002
  used in lookup context index: 0
vpp# show abf policy
abf:[0]: policy:0 acl:0
 path-list:[42] locks:1 flags:shared,no-uRPF, uRPF-list: None
  path:[53] pl-index:42 ip4 weight=1 pref=0 attached:  oper-flags:resolved,
 ipip0
abf:[1]: policy:1 acl:1
 path-list:[43] locks:1 flags:shared,no-uRPF, uRPF-list: None
  path:[54] pl-index:43 ip4 weight=1 pref=0 attached:  oper-flags:resolved,
 ipip1
vpp# show trace
--- Start of thread 0 vpp_main ---
Packet 1

00:08:53:122877: dpdk-input
  tn-eth2 rx queue 0
  buffer 0x96a80: current data 0, length 1512, buffer-pool 0, ref-count 1, 
totlen-nifb 0, trace handle 0x0
  ext-hdr-valid
  l4-cksum-computed l4-cksum-correct
  PKT MBUF: port 2, nb_segs 1, pkt_len 1512
buf_len 2176, data_len 1512, ol_flags 0x0, data_off 128, phys_addr 
0xac3aa080
packet_type 0x0 l2_len 0 l3_len 0 outer_l2_len 0 outer_l3_len 0
rss 0x0 fdir.hi 0x0 fdir.lo 0x0
  IP4: fa:16:3f:a9:2c:cc -> fa:16:3f:3e:79:00
  UDP: 192.168.100.20 -> 192.168.200.20
tos 0x00, ttl 64, length 1498, checksum 0x636c dscp CS0 ecn NON_ECN
fragment id 0x242d, flags DONT_FRAGMENT
  UDP: 33445 -> 5001
length 1478, checksum 0x2a23
00:08:53:122890: ethernet-input
  frame: flags 0x1, hw-if-index 3, sw-if-index 3
  IP4: fa:16:3f:a9:2c:cc -> fa:16:3f:3e:79:00
00:08:53:122897: ip4-input
  UDP: 192.168.100.20 -> 192.168.200.20
tos 0x00, ttl 64, length 1498, checksum 0x636c dscp CS0 ecn NON_ECN
fragment id 0x242d, flags DONT_FRAGMENT
  UDP: 33445 -> 5001
length 1478, checksum 0x2a23
00:08:53:122900: abf-input-ip4
   next 1 index 14
00:08:53:122904: ip4-midchain
  tx_sw_if_index 4 dpo-idx 14 : ipv4 via 0.0.0.0 ipip0: mtu:9000 next:10 
flags:[fixup-ip4o4 ] 45004004f69dc0a80106c0a80206
  stacked-on entry:30:
[@2]: dpo-load-balance: [proto:ip4 index:13 buckets:1 uRPF:12 to:[0:0] 
via:[10283:15985180]]
  [0] [@5]: ipv4 via 192.168.1.1 tn-eth0: mtu:9000 next:7 flags:[] 
fa163fdd32d9fa163f30992d0800 flow hash: 0x
  : 450005ee4004f0afc0a80106c0a80206450005da242d40003f11646c
  0020: c0a86414c0a8c81482a5138905c62a2361afae3a0008c5f6
00:08:53:122908: esp4-encrypt-tun
  esp: sa-index 0 spi 1427480065 (0x55159e01) seq 9871 sa-seq-hi 0 crypto 
aes-cbc-256 integrity sha1-96
00:08:53:122930: adj-midchain-tx
  adj-midchain:[14]:ipv4 via 0.0.0.0 ipip0: mtu:9000 next:10 flags:[fixup-ip4o4 
] 45004004f69dc0a80106c0a80206
  stacked-on entry:30:
[@2]: dpo-load-balance: [proto:ip4 index:13 buckets:1 uRPF:12 to:[0:0] 
via:[10283:15985180]]
  [0] [@5]: ipv4 via 192.168.1.1 tn-eth0: mtu:9000 next:7 flags:[] 
fa163fdd32d9fa163f30992d0800
00:08:53:122931: ip4-load-balance
  fib 4 dpo-idx 2 flow hash: 0x
  IPSEC_ESP: 192.168.1.6 -> 192.168.2.6
tos 0x00, ttl 64, length 1560, checksum 0xf057 dscp CS0 ecn NON_ECN
fragment id 0x
00:08:53:122934: ip4-rewrite
  tx_sw_if_index 1 dpo-idx 2 : ipv4 via 192.168.1.1 tn-eth0: mtu:9000 next:7 
flags:[] fa163fdd32d9fa163f30992d0800 flow hash: 0x
  : fa163fdd32d9fa163f30992d0800450006183f32f157c0a80106c0a8
  0020: 020655159e01268f055e5436db87ebe6158d2b9a150933432593
00:08:53:122936

Re: [vpp-dev] MPLS: fib table 1 display issue #mpls

[Neale Ranns]

From: vpp-dev@lists.fd.io  on behalf of Sastry Sista via 
lists.fd.io 
Date: Tuesday, 30 November 2021 at 02:35
To: vpp-dev@lists.fd.io 
Subject: Re: [vpp-dev] MPLS: fib table 1 display issue #mpls
Hi Neale,
 Then, mpls table ID we give for mpls commands always 
represents ip table id?

for example: mpls local-label 100 del 10.10.20.0/24 table 3 ==> here table is 
represents ip fib id?

Yes. Label 100 is added to mpls table 0, and is ‘bound to’, i.e. uses the same 
set of paths as, 10.10.20.0/24 in IP table 3.


Also, what is the use of non zero mpls table ID  at all? could you please 
provide one use case?

There are some MPLS multicast scenarios where the label is assigned by an 
upstream peer, so the device needs a table per-upstream peer (since the labels 
from peers can clash).

Second, if I wanted to know prefix for local_label, how do I get it from show 
commands? We wanted to implement show commands where we would like to get label 
and prefix for local_labels.

sh ip fib 10.10.20.0/24

that will display for all VRFs. You can do ‘sh ip fib index X …’ when you know 
the index (not the table id).
Look for the ‘mpls’ source. For example


09:35:26,073 ipv4-VRF:0, fib_index:0, flow hash:[src dst sport dport proto 
flowlabel ] epoch:0 flags:none locks:[adjacency:1, default-route:1, ]

10.0.0.1/32 fib:0 index:78 locks:3

  API refs:1 src-flags:added,contributing,active,

path-list:[102] locks:2 flags:shared, uPRF-list:18 len:1 itfs:[1, ]

  path:[126] pl-index:102 ip4 weight=1 pref=0 attached-nexthop:  
oper-flags:resolved,

172.16.1.2 pg0

  [@0]: ipv4 via 172.16.1.2 pg0: mtu:9000 next:3 flags:[] 
0201ff0202feffb04b720800

Extensions:

 path:126  labels:[[45 pipe ttl:64 exp:0]]

  mpls refs:1 src-flags:added, local-label:44  << HERE

path-list:[103] locks:1 flags:drop, uPRF-list:87 len:0 itfs:[]

  path:[127] pl-index:103 ip4 weight=1 pref=0 special:  cfg-flags:drop,

[@0]: dpo-drop ip4



 forwarding:   unicast-ip4-chain

  [@0]: dpo-load-balance: [proto:ip4 index:81 buckets:1 uRPF:18 flags:[] 
to:[0:0]]

[0] [@13]: mpls-label[@0]:[45:64:0:eos]

[@1]: mpls via 172.16.1.2 pg0: mtu:9000 next:2 flags:[] 
0201ff0202feffb04b728847

There’s:
  Sh mpls fib 44
That will show the forwarding for the local label, but here isn’t a show 
command like:
  Sh mpls bind …
That would show the result of your ‘mpls local-label 100 del 10.10.20.0/24 
table 3’
Please do write one.

/neale


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#20562): https://lists.fd.io/g/vpp-dev/message/20562
Mute This Topic: https://lists.fd.io/mt/87373182/21656
Mute #mpls:https://lists.fd.io/g/vpp-dev/mutehashtag/mpls
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [vpp-dev] MPLS: fib table 1 display issue #mpls

[Neale Ranns]

Hi Sastry,

For IP unicast MPLS VPNs there is only mpls table 0.
Label to vrf mapping is done based on the label allocation scheme (see the doc).

/neale


From: vpp-dev@lists.fd.io  on behalf of Sastry Sista via 
lists.fd.io 
Date: Monday, 29 November 2021 at 13:00
To: vpp-dev@lists.fd.io 
Subject: Re: [vpp-dev] MPLS: fib table 1 display issue #mpls
Hi Neale,
  Thank you for the quick reply. I gone through that link 
and have few queries.

On MPLS VPNs:

Q1. If we do not allow interfaces creation inside VRF of mpls tables, then what 
is the use of mpls table 1 etc?
Q2. Always prefixes are associated with IP FIBs as per my understanding, so, 
how does the incoming packet with label can give us the ip fib index?
Q3. what is the use of mpls table ID (mpls fib index) if we always use ip table 
ID (ip fib index)?
Q4. Is it that "show mpls fib" ? can help only to get local_label? but, how do 
I know that local_label is associated with which ip fib table?

With Regards
Sastry

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#20554): https://lists.fd.io/g/vpp-dev/message/20554
Mute This Topic: https://lists.fd.io/mt/87373182/21656
Mute #mpls:https://lists.fd.io/g/vpp-dev/mutehashtag/mpls
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [vpp-dev] MPLS: fib table 1 display issue #mpls

[Neale Ranns]

Hi Sastry,

I’d suggest you start with the docs here:
  https://wiki.fd.io/view/VPP/MPLS_FIB

/neale

From: vpp-dev@lists.fd.io  on behalf of Sastry Sista via 
lists.fd.io 
Date: Monday, 29 November 2021 at 08:17
To: vpp-dev@lists.fd.io 
Subject: [vpp-dev] MPLS: fib table 1 display issue #mpls
Hi,
 I am trying l3vpn features and following the below steps:

1. mpls table add 0
2. set interface mpls VirtualFuncEthernet0/7/0.1549 enable
3. mpls table add 1
4. ip route add 2.2.2.2/24 via 10.164.4.75 VirtualFuncEthernet0/7/0.1549  
mpls-lookup-in-table 1 out-labels 75

I found 2.2.2.2 in ip fib table 0 but not in "show mpls fib table 1".

Also show mpls fib table shows fib index as "-1".
vpp# show mpls fib table 1
MPLS-VRF:1, fib_index:-1 locks:[CLI:1, ]

Where do I see these mpls routes? is it not captured at show mpls?

With Regards
Sastry



-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#20549): https://lists.fd.io/g/vpp-dev/message/20549
Mute This Topic: https://lists.fd.io/mt/87373182/21656
Mute #mpls:https://lists.fd.io/g/vpp-dev/mutehashtag/mpls
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 Linux-cp plugin with multicast packets

[Neale Ranns]

[Adding the public mailer so we all benefit]

Hi Wei,

You need to add the multicast routes to VPP too.

/neale

From: Wei Huang 
Date: Wednesday, 17 November 2021 at 03:57
To: nra...@cisco.com , Neale Ranns 
Subject: VPP Linux-cp plugin with multicast packets
Hi Neale

I am using the linux-cp plugin you created in VPP (v21.06) and run into issues 
with multicast packet from OSPF.
I try to make FRR work with VPP.  I created a lcp pair to an interface used to 
connect to other router using OSPF.

FRR--VPP (192.168.100.5)--Router (192.168.100.20)
VPP2   ETH2ETH1
When I do tshark on Router ETH1, I can see hello packets from both sides, i.e. 
192.168.100.5->224.0.0.5 and 192.168.100.20->224.0.0.5.
But when do tshark on VPP2, I can only see hello packets from 
192.168.100.5->224.0.0.5. Seems VPP didn't forward multicast packets to VPP2.
When I do packet trace, this is what I got:
01:21:34:796763: dpdk-input
  tn-eth2 rx queue 0
  buffer 0x93b1f: current data 0, length 82, buffer-pool 0, ref-count 1, 
totlen-nifb 0, trace handle 0x0
  ext-hdr-valid
  l4-cksum-computed l4-cksum-correct
  PKT MBUF: port 2, nb_segs 1, pkt_len 82
buf_len 2176, data_len 82, ol_flags 0x0, data_off 128, phys_addr 0xb20ec840
packet_type 0x0 l2_len 0 l3_len 0 outer_l2_len 0 outer_l3_len 0
rss 0x0 fdir.hi 0x0 fdir.lo 0x0
  IP4: fa:16:3f:a9:2c:cc -> 01:00:5e:00:00:05
  OSPF: 192.168.100.20 -> 224.0.0.5
tos 0xc0, ttl 1, length 68, checksum 0xf102 dscp CS6 ecn NON_ECN
fragment id 0xc2dc
01:21:34:796805: ethernet-input
  frame: flags 0x1, hw-if-index 3, sw-if-index 3
  IP4: fa:16:3f:a9:2c:cc -> 01:00:5e:00:00:05
01:21:34:796836: ip4-input
  OSPF: 192.168.100.20 -> 224.0.0.5
tos 0xc0, ttl 1, length 68, checksum 0xf102 dscp CS6 ecn NON_ECN
fragment id 0xc2dc
01:21:34:796842: ip4-mfib-forward-lookup
  fib 0 entry 0
01:21:34:796846: ip4-mfib-forward-rpf
  entry 0 itf -1 flags
01:21:34:796847: ip4-drop
OSPF: 192.168.100.20 -> 224.0.0.5
  tos 0xc0, ttl 1, length 68, checksum 0xf102 dscp CS6 ecn NON_ECN
  fragment id 0xc2dc
01:21:34:796849: error-drop
  rx:tn-eth2
01:21:34:796853: drop
  ip4-input: Multicast RPF check failed

Do I need to do anything special for multicast packets?

Regards,

Wei

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#20504): https://lists.fd.io/g/vpp-dev/message/20504
Mute This Topic: https://lists.fd.io/mt/87116971/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] a free_bitmap may expand while pool_put

[Neale Ranns]

Hi Stanislav,

IMHO the ASSERT is a false negative, even though the load-balance has been put 
in the pool, its memory is still valid and can still be safely retrieved from a 
worker. If the load-balance was re-used before all workers were done with it, 
then we’d have problems, but that doesn’t happen given the speed mismatch of 
the workers and the main thread – to guarantee that case a call to 
vlib_worker_wait_one_loop() in the load-balance code would be sufficient.

If you want to stop the asserts firing in a debug image you can #ifdef 
CLIB_DEBUG conditionally hold the lock on pool_put.

/neale

From: vpp-dev@lists.fd.io  on behalf of Florin Coras via 
lists.fd.io 
Date: Thursday, 4 November 2021 at 22:19
To: Stanislav Zaikin 
Cc: Damjan Marion , vpp-dev 
Subject: Re: [vpp-dev] a free_bitmap may expand while pool_put
Hi Stanislav,

Yes, binary api messages are handled by main thread. If the issue is purely 
binary api related, then yes, checking for pool (vectors or bitmap) realloc 
with single writer should work.

Note that the pool’s free_indices vector can also expand (not only the bitmap), 
so that should be checked as well.

Regards,
Florin


On Nov 4, 2021, at 1:58 PM, Stanislav Zaikin 
mailto:zsta...@gmail.com>> wrote:

Hi Damjan,
Hi Florin,

I may have given the wrong example, even though the IP API's marked as mt-safe 
(VL_API_IP_ROUTE_ADD_DEL/VL_API_IP_ROUTE_ADD_DEL_V2), they'd be called only 
from the main thread, right? So, only one pool_put will be called and it looks 
like the patch actually fixes the problem (I still don't like it).

I liked the idea with a vec of freed elements, but we still need to put a 
worker barrier to perform such an operation. I thought about something more 
lightweight, like CAS for a newly allocated bitmap/vector. But I find myself 
extremely incompetent to write any lock-free solutions.


On Thu, 4 Nov 2021 at 20:01, Florin Coras 
mailto:fcoras.li...@gmail.com>> wrote:
Agreed! Since pools are not thread safe, the whole load balance destroy scheme 
should probably be refactored.

Maybe add, with locks, the indices to be freed to a vector and once enough 
accumulate, or if a new element is needed, grab the worker barrier and actually 
free them all.

Regards,
Florin


On Nov 4, 2021, at 11:50 AM, Damjan Marion via lists.fd.io 
mailto:dmarion=me@lists.fd.io>> wrote:


Dear Stanislav,

It doesn’t look to me as a thread safe solution.

i.e imagine 2 threads call pool_put_will expand  on the same time, and there is 
just one free slot. Both will get negative answer, but 2nd put operation will 
actually expand.

—
Damjan


On 04.11.2021., at 18:24, Stanislav Zaikin 
mailto:zsta...@gmail.com>> wrote:

Hello folks,

In a multi-threaded environment (in my case I have 2 workers) I observed a 
crash, and thanks to Neale, it turned out that free_bitmap may expand while 
doing pool_put.
Let's say one thread is doing pool_put, while another thread is calling 
"pool_elt_at_index". I observed different addresses before and after checking 
"ASSERT (! pool_is_free (p, _e))" in that macro.

I prepared a patch [0], but it's kind of ugly. We don't have asserts in release 
mode, so why should we care about it?

On the other hand, 2 different threads can do 2 pool_puts simultaneously and we 
can lose one free element in the pool (and also additionally allocated bitmap).

For me, it's a place where it would be nice to have an mt-safe vec. What do you 
think?

[0] - https://gerrit.fd.io/r/c/vpp/+/34332

--
Best regards
Stanislav Zaikin







--
Best regards
Stanislav Zaikin


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#20433): https://lists.fd.io/g/vpp-dev/message/20433
Mute This Topic: https://lists.fd.io/mt/86821639/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] assert in pool_elt_at_index

[Neale Ranns]

Hi Stanislav,

I see no smoking guns :(

The only cause I can think of is that when a load-balance is returned to the 
pool, the pool’s bitmap of free indicies may expand, which would confuse 
readers/workers. But I don’t see any of your threads having just pool_put a 
load-balance. Since you have a reliable reproduction environment, could you 
cook your own pool_put_would_expand macro to test this theory?

/neale


From: Stanislav Zaikin 
Date: Friday, 22 October 2021 at 15:06
To: Neale Ranns 
Cc: vpp-dev 
Subject: Re: [vpp-dev] assert in pool_elt_at_index
Hi Neale,

Sure, here it is:
https://gist.github.com/zstas/c2316d4e95a84fa28f0e0be00eb6fb19

Thanks in advance.

On Fri, 22 Oct 2021 at 09:55, Neale Ranns 
mailto:ne...@graphiant.com>> wrote:
Hi Stanislav,

Can you do:
  thread apply all bt
I’d like to see what the other threads are doing.

/neale

From: vpp-dev@lists.fd.io<mailto:vpp-dev@lists.fd.io> 
mailto:vpp-dev@lists.fd.io>> on behalf of Stanislav Zaikin 
via lists.fd.io<http://lists.fd.io> 
mailto:gmail@lists.fd.io>>
Date: Wednesday, 13 October 2021 at 20:30
To: vpp-dev mailto:vpp-dev@lists.fd.io>>
Subject: [vpp-dev] assert in pool_elt_at_index
Hello folks,

I'm facing a strange issue with 2 worker threads. Sometimes I get a crash 
either in "ip6-lookup" or "mpls-lookup" nodes. They happen with assert in the 
pool_elt_at_index macro and always inside the "load_balance_get" function. But 
the load_balance dpo looks perfectly good, I mean it still has a lock and on 
regular deletion (in the case when the load_balance dpo is deleted) it should 
be erased properly (with dpo_reset). It happens usually when the main core is 
executing vlib_worker_thread_barrier_sync_int(), and the other worker is 
executing vlib_worker_thread_barrier_check().
And the strangest thing is, when I run the vpp's gdb helper for checking 
"pool_index_is_free" or pifi, it shows me that the index isn't free (and the 
macro in that case shouldn't fire).

Any thoughts and inputs are appreciated.

Thread 3 "vpp_wk_0" received signal SIGABRT, Aborted.
[Switching to Thread 0x7fb4f2e22700 (LWP 3244)]
__GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:51
51 ../sysdeps/unix/sysv/linux/raise.c: No such file or directory.
(gdb) bt
#0  __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:51
#1  0x7fb5933fa921 in __GI_abort () at abort.c:79
#2  0x7fb594392799 in os_panic () at 
/home/vpp/vpp/src/vppinfra/unix-misc.c:177
#3  0x7fb5942d8f49 in debugger () at /home/vpp/vpp/src/vppinfra/error.c:84
#4  0x7fb5942d8cc7 in _clib_error (how_to_die=2, function_name=0x0, 
line_number=0, fmt=0x7fb5962ec8d0 "%s:%d (%s) assertion `%s' fails") at 
/home/vpp/vpp/src/vppinfra/error.c:143
#5  0x7fb5954bd694 in load_balance_get (lbi=3604) at 
/home/vpp/vpp/src/vnet/dpo/load_balance.h:222
#6  0x7fb5954bc070 in ip6_lookup_inline (vm=0x7fb51ceccd00, 
node=0x7fb520f6b700, frame=0x7fb52128e4c0) at 
/home/vpp/vpp/src/vnet/ip/ip6_forward.h:117
#7  0x7fb5954bbdd5 in ip6_lookup_node_fn_hsw (vm=0x7fb51ceccd00, 
node=0x7fb520f6b700, frame=0x7fb52128e4c0) at 
/home/vpp/vpp/src/vnet/ip/ip6_forward.c:736
#8  0x7fb594ec0076 in dispatch_node (vm=0x7fb51ceccd00, 
node=0x7fb520f6b700, type=VLIB_NODE_TYPE_INTERNAL, 
dispatch_state=VLIB_NODE_STATE_POLLING, frame=0x7fb52128e4c0, 
last_time_stamp=1808528151240447) at /home/vpp/vpp/src/vlib/main.c:1217
#9  0x7fb594ec09e7 in dispatch_pending_node (vm=0x7fb51ceccd00, 
pending_frame_index=5, last_time_stamp=1808528151240447) at 
/home/vpp/vpp/src/vlib/main.c:1376
#10 0x7fb594eba441 in vlib_main_or_worker_loop (vm=0x7fb51ceccd00, 
is_main=0) at /home/vpp/vpp/src/vlib/main.c:1904
#11 0x7fb594eb92e7 in vlib_worker_loop (vm=0x7fb51ceccd00) at 
/home/vpp/vpp/src/vlib/main.c:2038
#12 0x7fb594f1195d in vlib_worker_thread_fn (arg=0x7fb513a48100) at 
/home/vpp/vpp/src/vlib/threads.c:1868
#13 0x7fb5942fd214 in clib_calljmp () at 
/home/vpp/vpp/src/vppinfra/longjmp.S:123
#14 0x7fb4f2e21c90 in ?? ()
#15 0x7fb594f09b83 in vlib_worker_thread_bootstrap_fn (arg=0x7fb513a48100) 
at /home/vpp/vpp/src/vlib/threads.c:585
#16 0x7fb50c218355 in eal_thread_loop (arg=0x0) at 
../src-dpdk/lib/librte_eal/linux/eal_thread.c:127
#17 0x7fb5947dc6db in start_thread (arg=0x7fb4f2e22700) at 
pthread_create.c:463
#18 0x7fb5934db71f in clone () at 
../sysdeps/unix/sysv/linux/x86_64/clone.S:95
(gdb) select 5
(gdb) print _e
$1 = (load_balance_t *) 0x7fb52651e580
(gdb) print load_balance_pool[3604]
$2 = {cacheline0 = 0x7fb52651e580 "\001", lb_n_buckets = 1, 
lb_n_buckets_minus_1 = 0, lb_proto = DPO_PROTO_IP6, lb_flags = 
LOAD_BALANCE_FLAG_NONE, lb_fib_entry_flags = (FIB_ENTRY_FLAG_CONNECTED | 
FIB_ENTRY_FLAG_LOCAL), lb_locks = 1, lb_map = 4294967295, lb_urpf = 4094, 
lb_hash_config = 31, lb_buckets = 0x0,
  lb_buckets_inline = d

Re: [vpp-dev] assert in pool_elt_at_index

[Neale Ranns]

Hi Stanislav,

Can you do:
  thread apply all bt
I’d like to see what the other threads are doing.

/neale

From: vpp-dev@lists.fd.io  on behalf of Stanislav Zaikin 
via lists.fd.io 
Date: Wednesday, 13 October 2021 at 20:30
To: vpp-dev 
Subject: [vpp-dev] assert in pool_elt_at_index
Hello folks,

I'm facing a strange issue with 2 worker threads. Sometimes I get a crash 
either in "ip6-lookup" or "mpls-lookup" nodes. They happen with assert in the 
pool_elt_at_index macro and always inside the "load_balance_get" function. But 
the load_balance dpo looks perfectly good, I mean it still has a lock and on 
regular deletion (in the case when the load_balance dpo is deleted) it should 
be erased properly (with dpo_reset). It happens usually when the main core is 
executing vlib_worker_thread_barrier_sync_int(), and the other worker is 
executing vlib_worker_thread_barrier_check().
And the strangest thing is, when I run the vpp's gdb helper for checking 
"pool_index_is_free" or pifi, it shows me that the index isn't free (and the 
macro in that case shouldn't fire).

Any thoughts and inputs are appreciated.

Thread 3 "vpp_wk_0" received signal SIGABRT, Aborted.
[Switching to Thread 0x7fb4f2e22700 (LWP 3244)]
__GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:51
51 ../sysdeps/unix/sysv/linux/raise.c: No such file or directory.
(gdb) bt
#0  __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:51
#1  0x7fb5933fa921 in __GI_abort () at abort.c:79
#2  0x7fb594392799 in os_panic () at 
/home/vpp/vpp/src/vppinfra/unix-misc.c:177
#3  0x7fb5942d8f49 in debugger () at /home/vpp/vpp/src/vppinfra/error.c:84
#4  0x7fb5942d8cc7 in _clib_error (how_to_die=2, function_name=0x0, 
line_number=0, fmt=0x7fb5962ec8d0 "%s:%d (%s) assertion `%s' fails") at 
/home/vpp/vpp/src/vppinfra/error.c:143
#5  0x7fb5954bd694 in load_balance_get (lbi=3604) at 
/home/vpp/vpp/src/vnet/dpo/load_balance.h:222
#6  0x7fb5954bc070 in ip6_lookup_inline (vm=0x7fb51ceccd00, 
node=0x7fb520f6b700, frame=0x7fb52128e4c0) at 
/home/vpp/vpp/src/vnet/ip/ip6_forward.h:117
#7  0x7fb5954bbdd5 in ip6_lookup_node_fn_hsw (vm=0x7fb51ceccd00, 
node=0x7fb520f6b700, frame=0x7fb52128e4c0) at 
/home/vpp/vpp/src/vnet/ip/ip6_forward.c:736
#8  0x7fb594ec0076 in dispatch_node (vm=0x7fb51ceccd00, 
node=0x7fb520f6b700, type=VLIB_NODE_TYPE_INTERNAL, 
dispatch_state=VLIB_NODE_STATE_POLLING, frame=0x7fb52128e4c0, 
last_time_stamp=1808528151240447) at /home/vpp/vpp/src/vlib/main.c:1217
#9  0x7fb594ec09e7 in dispatch_pending_node (vm=0x7fb51ceccd00, 
pending_frame_index=5, last_time_stamp=1808528151240447) at 
/home/vpp/vpp/src/vlib/main.c:1376
#10 0x7fb594eba441 in vlib_main_or_worker_loop (vm=0x7fb51ceccd00, 
is_main=0) at /home/vpp/vpp/src/vlib/main.c:1904
#11 0x7fb594eb92e7 in vlib_worker_loop (vm=0x7fb51ceccd00) at 
/home/vpp/vpp/src/vlib/main.c:2038
#12 0x7fb594f1195d in vlib_worker_thread_fn (arg=0x7fb513a48100) at 
/home/vpp/vpp/src/vlib/threads.c:1868
#13 0x7fb5942fd214 in clib_calljmp () at 
/home/vpp/vpp/src/vppinfra/longjmp.S:123
#14 0x7fb4f2e21c90 in ?? ()
#15 0x7fb594f09b83 in vlib_worker_thread_bootstrap_fn (arg=0x7fb513a48100) 
at /home/vpp/vpp/src/vlib/threads.c:585
#16 0x7fb50c218355 in eal_thread_loop (arg=0x0) at 
../src-dpdk/lib/librte_eal/linux/eal_thread.c:127
#17 0x7fb5947dc6db in start_thread (arg=0x7fb4f2e22700) at 
pthread_create.c:463
#18 0x7fb5934db71f in clone () at 
../sysdeps/unix/sysv/linux/x86_64/clone.S:95
(gdb) select 5
(gdb) print _e
$1 = (load_balance_t *) 0x7fb52651e580
(gdb) print load_balance_pool[3604]
$2 = {cacheline0 = 0x7fb52651e580 "\001", lb_n_buckets = 1, 
lb_n_buckets_minus_1 = 0, lb_proto = DPO_PROTO_IP6, lb_flags = 
LOAD_BALANCE_FLAG_NONE, lb_fib_entry_flags = (FIB_ENTRY_FLAG_CONNECTED | 
FIB_ENTRY_FLAG_LOCAL), lb_locks = 1, lb_map = 4294967295, lb_urpf = 4094, 
lb_hash_config = 31, lb_buckets = 0x0,
  lb_buckets_inline = dpoi_type = DPO_RECEIVE, dpoi_proto = DPO_PROTO_IP6, 
dpoi_next_node = 2, dpoi_index = 2094}, as_u64 = 8993661649164}}, {{{dpoi_type 
= DPO_FIRST, dpoi_proto = DPO_PROTO_IP4, dpoi_next_node = 0, dpoi_index = 0}, 
as_u64 = 0}}, {{{dpoi_type = DPO_FIRST, dpoi_proto = DPO_PROTO_IP4,
  dpoi_next_node = 0, dpoi_index = 0}, as_u64 = 0}}, {{{dpoi_type = 
DPO_FIRST, dpoi_proto = DPO_PROTO_IP4, dpoi_next_node = 0, dpoi_index = 0}, 
as_u64 = 0
(gdb) print &load_balance_pool[3604]
$3 = (load_balance_t *) 0x7fb52651e580
(gdb) source ~/vpp/extras/gdb/gdbinit
Loading vpp functions...
Load vlLoad pe
Load pifi
Load node_name_from_index
Load vnet_buffer_opaque
Load vnet_buffer_opaque2
Load bitmap_get
Done loading vpp functions...
(gdb) pifi load_balance_pool 3604
pool_is_free_index (load_balance_pool, 3604)$4 = 0
(gdb) info threads
  Id   Target Id Frame
  1Thread 0x7fb596bd2c40 (LWP 727) "vpp_main" 0x7fb594f1439b in 
clib_time_now_internal (c=0x7fb59517ccc0 , 
n=1808528155236639) at /home/vpp/vpp/src/v

Re: [vpp-dev]: SIGSEV in mpls_tunnel_collect_forwarding

[Neale Ranns]

Hi Rajith,

Can you try this:

  https://gerrit.fd.io/r/c/vpp/+/34200

I think Stanislav’s solution would also work, but it would mean a no-op restack 
for the tunnel. Not walking the new child is more efficient.

/neale

From: vpp-dev@lists.fd.io  on behalf of Stanislav Zaikin 
via lists.fd.io 
Date: Thursday, 21 October 2021 at 17:58
To: Rajith PR 
Cc: vpp-dev 
Subject: Re: [vpp-dev]: SIGSEV in mpls_tunnel_collect_forwarding
Hi Rajith,

Looks like each tunnel uses the same path-list (and different path extensions), 
and when the path has more than FIB_PATH_LIST_POPULAR (64) children - it 
updates all the children with that "popular" flag. And at that point there are 
no path extensions yet on the last child. So, I suppose that it should be okay 
to add a check something like
if (NULL == path_ext)
{
return (FIB_PATH_LIST_WALK_CONTINUE);
}

On Thu, 21 Oct 2021 at 08:29, Rajith PR via lists.fd.io 
mailto:rtbrick@lists.fd.io>> wrote:
Hi All,

We are seeing below crash when creating mpls tunnels. The issue is easily 
reproducible just have to create around 100 mpls tunnels. It seems path_ext is 
coming as NULL.

Thread 1 "vpp_main" received signal SIGSEGV, Segmentation fault.
0x7fe017bba268 in mpls_tunnel_collect_forwarding (pl_index=90, 
path_index=144, arg=0x7fdfa84acdd8) at 
/home/supervisor/libvpp/src/vnet/mpls/mpls_tunnel.c:125
125path_ext->fpe_mpls_flags |= FIB_PATH_EXT_MPLS_FLAG_NO_IP_TTL_DECR;

VPP Version : 20.09
Call Stack:

Thread 1 (Thread 0x7fe02606d400 (LWP 436)):
#0  0x7fe017bba268 in mpls_tunnel_collect_forwarding (pl_index=90, 
path_index=144, arg=0x7fdfa84acdd8) at 
/home/supervisor/libvpp/src/vnet/mpls/mpls_tunnel.c:125
#1  0x7fe017f85d6d in fib_path_list_walk (path_list_index=90, 
func=0x7fe017bba210 , ctx=0x7fdfa84acdd8) at 
/home/supervisor/libvpp/src/vnet/fib/fib_path_list.c:1408
#2  0x7fe017bba079 in mpls_tunnel_mk_lb (mt=0x7fdff6701cd8, 
linkt=VNET_LINK_MPLS, fct=FIB_FORW_CHAIN_TYPE_ETHERNET, dpo_lb=0x7fdfa84ace20) 
at /home/supervisor/libvpp/src/vnet/mpls/mpls_tunnel.c:170
#3  0x7fe017bb8b12 in mpls_tunnel_restack (mt=0x7fdff6701cd8) at 
/home/supervisor/libvpp/src/vnet/mpls/mpls_tunnel.c:324
#4  0x7fe017bbb6c1 in mpls_tunnel_back_walk (node=0x7fdff6701cd8, 
ctx=0x7fdfa84acea8) at /home/supervisor/libvpp/src/vnet/mpls/mpls_tunnel.c:1005

#5  0x7fe017f613c2 in fib_node_back_walk_one (ptr=0x7fdfa84acec8, 
ctx=0x7fdfa84acea8) at /home/supervisor/libvpp/src/vnet/fib/fib_node.c:161
#6  0x7fe017f4be6a in fib_walk_advance (fwi=0) at 
/home/supervisor/libvpp/src/vnet/fib/fib_walk.c:368
#7  0x7fe017f4ca00 in fib_walk_sync (parent_type=FIB_NODE_TYPE_PATH_LIST, 
parent_index=90, ctx=0x7fdfa84acf70) at 
/home/supervisor/libvpp/src/vnet/fib/fib_walk.c:792
#8  0x7fe017f85ae3 in fib_path_list_child_add (path_list_index=90, 
child_type=FIB_NODE_TYPE_MPLS_TUNNEL, child_index=46) at 
/home/supervisor/libvpp/src/vnet/fib/fib_path_list.c:1343
#9  0x7fe017bb89b4 in vnet_mpls_tunnel_path_add (sw_if_index=97, 
rpaths=0x7fdff66448d0) at 
/home/supervisor/libvpp/src/vnet/mpls/mpls_tunnel.c:679
#10 0x7fe017bbaa30 in vnet_create_mpls_tunnel_command_fn (vm=0x7fe017088c40 
, input=0x7fdfa84ad820, cmd=0x7fdfe235ed98) at 
/home/supervisor/libvpp/src/vnet/mpls/mpls_tunnel.c:868
#11 0x7fe016d84439 in vlib_cli_dispatch_sub_commands (vm=0x7fe017088c40 
, cm=0x7fe017088e90 , 
input=0x7fdfa84ad820, parent_command_index=818)
at /home/supervisor/libvpp/src/vlib/cli.c:572
#12 0x7fe016d841ad in vlib_cli_dispatch_sub_commands (vm=0x7fe017088c40 
, cm=0x7fe017088e90 , 
input=0x7fdfa84ad820, parent_command_index=0)
at /home/supervisor/libvpp/src/vlib/cli.c:529
#13 0x7fe016d8335f in vlib_cli_input (vm=0x7fe017088c40 , 
input=0x7fdfa84ad820, function=0x0, function_arg=0) at 
/home/supervisor/libvpp/src/vlib/cli.c:674
#14 0x7fe016e4d879 in unix_cli_exec (vm=0x7fe017088c40 , 
input=0x7fdfa84ade40, cmd=0x7fdfe2367888) at 
/home/supervisor/libvpp/src/vlib/unix/cli.c:3399
#15 0x7fe016d84439 in vlib_cli_dispatch_sub_commands (vm=0x7fe017088c40 
, cm=0x7fe017088e90 , 
input=0x7fdfa84ade40, parent_command_index=0)
at /home/supervisor/libvpp/src/vlib/cli.c:572
#16 0x7fe016d8335f in vlib_cli_input (vm=0x7fe017088c40 , 
input=0x7fdfa84ade40, function=0x7fe016e382a0 , 
function_arg=0)
at /home/supervisor/libvpp/src/vlib/cli.c:674
#17 0x7fe016e3a0cd in unix_cli_process_input (cm=0x7fe0170895f8 
, cli_file_index=0) at 
/home/supervisor/libvpp/src/vlib/unix/cli.c:2619

#18 0x7fe016e37251 in unix_cli_process (vm=0x7fe017088c40 
, rt=0x7fdffd17b9c0, f=0x0) at 
/home/supervisor/libvpp/src/vlib/unix/cli.c:2736
#19 0x7fe016dce8ed in vlib_process_bootstrap (_a=140599548735624) at 
/home/supervisor/libvpp/src/vlib/main.c:1464
#20 0x7fe016646c34 in clib_calljmp () at 
/home/supervisor/libvpp/src/vppinfra/longjmp.S:123
#21 0x7fdfe2287080 in ?? ()
#22 0x7fe016dce32f in vlib_process_startup (vm=0x7fdffc336c40, 
p=0x7

Re: [vpp-dev] VPP - GRE tunnel

[Neale Ranns]

Hi Archana,

I might have jumped to conclusions, sorry.
The src,dst address of the GRE tunnel in config are the same addresses that 
will be in the encapsulation, i.e. the address that will be on the wire. These 
address need to be routable through the network between the tunnel endpoints. 
You can use either the addresses on the loopback or the Ethernets – the choice 
is yours.
If you want to use the loopback addresses;
  Set int ip addr loop0 10.100.0.7/32  << always a /32 on a loopback, there are 
never any peers
Set the tunnel from your loop back to the peer’s loopback
  Create gre tunnel src 10.100.0.7 dst 10.100.0.6
Add a route to the peer’s loop back
  Ip route 10.100.0.6/32 via 43.0.0.2 TenGigabitEthernet1/0/1
Bring the tunnel up
  Set int state gro0 up
IP enable the tunnel so that it can accept IP packets; 2 ways either:

  1.  Make it unnumbered to the loopback
  Set int ip unnumbered gre0 ip loop0

  1.  Or give it an IP address; this subnet does not need to be routable.
 Set int ip addr gre0 192.168.1.0/31
Then you can point routes through the tunnel
  Ip route 10.10.10.0/24 via gre0



/neeale


From: Archana Sampath 
Date: Thursday, 30 September 2021 at 15:29
To: Neale Ranns , kusumanjal...@gmail.com 

Cc: vpp-dev@lists.fd.io 
Subject: Re: [vpp-dev] VPP - GRE tunnel
Hi Neale ,

If that is the case , Server1 (TenGigabitEthernet1/0/1 )  and 
server2(TenGigabitEthernet1/0/2) are connected back to back .  If I assign the 
same ip to GRE , will packet go  via GRE  instead of directly connected route?

Note: In my topology ,server1 and server2 are connected via private network and 
not via WAN.


Regards,
Archana

From: Neale Ranns 
Date: Thursday, 30 September 2021 at 5:23 PM
To: kusumanjal...@gmail.com , Archana Sampath 

Cc: vpp-dev@lists.fd.io 
Subject: Re: [vpp-dev] VPP - GRE tunnel

Also the tunnel src,dst addresses should be 43.0.0.x

/neale

From: vpp-dev@lists.fd.io  on behalf of Kusuma DS via 
lists.fd.io 
Date: Thursday, 30 September 2021 at 14:25
To: Archana Sampath 
Cc: vpp-dev@lists.fd.io 
Subject: Re: [vpp-dev] VPP - GRE tunnel
Hi Archana,

Instead of creating loopback, assign the ip address to gre tunnel interface and 
try it out.

If this doesn't work, please send the show ip fib output for more details.

Thank you,
Kusuma

On Thu, 30 Sep, 2021, 4:52 PM Archana Sampath, 
mailto:arch...@ezelink.com>> wrote:
Hi  Team,

I am trying to test GRE tunnel on VPP.

SETUP is

Host 1 Sever1 --server2 
---host2
[20.0.0.x/24]   [43.0.0.x/24]
[10.0.0.x/24]


GRE TUNNEL is configured between Server1 and Server2 .

Router 1:
===
#create namespaces
ip netns add vpp1

# create and configure 1st veth pair
ip link add name veth_vpp1 type veth peer name vpp1
ip link set dev vpp1 up
ip link set dev veth_vpp1 up netns vpp1

ip netns exec vpp1 \
  bash -c "
ip link set dev lo up
ip addr add 20.20.20.100/24<http://20.20.20.100/24> dev veth_vpp1
ip route add 0.0.0.0/0<http://0.0.0.0/0> via 20.20.20.1
"

VPP_SIDE CONFIGS
===
vppctl -s /run/vpp/cli-vpp1.sock create host-interface name vpp1
vppctl -s /run/vpp/cli-vpp1.sock set int state host-vpp1 up
vppctl -s /run/vpp/cli-vpp1.sock set int ip address host-vpp1 
20.20.20.1/24<http://20.20.20.1/24>
vppctl -s /run/vpp/cli-vpp1.sock ping 20.20.20.100
vppctl -s /run/vpp/cli-vpp1.sock show ip neighbors
vppctl -s /run/vpp/cli-vpp1.sock set int state TenGigabitEthernet1/0/1 up
vppctl -s /run/vpp/cli-vpp1.sock set int ip address TenGigabitEthernet1/0/1 
43.0.0.1/24<http://43.0.0.1/24>
vppctl -s /run/vpp/cli-vpp1.sock show interface address
vppctl -s /run/vpp/cli-vpp1.sock loopback create mac 1a:ab:3c:4d:5e:7f
vppctl -s /run/vpp/cli-vpp1.sock set interface ip address loop0 
10.100.0.7/31<http://10.100.0.7/31>
vppctl -s /run/vpp/cli-vpp1.sock set int mtu 1360 loop0
vppctl -s /run/vpp/cli-vpp1.sock create  gre tunnel src 10.100.0.7 dst 
10.100.0.6
vppctl -s /run/vpp/cli-vpp1.sock set int state gre0 up
vppctl -s /run/vpp/cli-vpp1.sock ip route add 
10.10.10.0/24<http://10.10.10.0/24> via 10.100.0.6
vppctl -s /run/vpp/cli-vpp1.sock ip route add 
10.100.0.0/24<http://10.100.0.0/24> via 43.0.0.2


On server 2:
==


ip netns del vpp1
#create namespaces
ip netns add vpp1

# create and configure 1st veth pair
ip link add name veth_vpp1 type veth peer name vpp1
ip link set dev vpp1 up
ip link set dev veth_vpp1 up netns vpp1

ip netns exec vpp1 \
  bash -c "
ip link set dev lo up
ip addr add 10.10.10.100/24<http://10.10.10.100/24> dev veth_vpp1
ip route add 0.0.0.0/0<http://0.0.0.0/0> via 10.10.10.1
"

VPP_SIDE CONFIGS
===
vppctl -s /run/vpp/cli-vpp1.sock create host-interface name vpp1
vppctl -s /run/vpp/cli-vpp1.sock set int state host-vpp1 up
vppctl -s /run/vpp/cli-vpp1.sock set int ip address host-vpp1 
10.10.10.1/24<http://10.1

Re: [vpp-dev] VPP - GRE tunnel

[Neale Ranns]

Also the tunnel src,dst addresses should be 43.0.0.x

/neale

From: vpp-dev@lists.fd.io  on behalf of Kusuma DS via 
lists.fd.io 
Date: Thursday, 30 September 2021 at 14:25
To: Archana Sampath 
Cc: vpp-dev@lists.fd.io 
Subject: Re: [vpp-dev] VPP - GRE tunnel
Hi Archana,

Instead of creating loopback, assign the ip address to gre tunnel interface and 
try it out.

If this doesn't work, please send the show ip fib output for more details.

Thank you,
Kusuma

On Thu, 30 Sep, 2021, 4:52 PM Archana Sampath, 
mailto:arch...@ezelink.com>> wrote:
Hi  Team,

I am trying to test GRE tunnel on VPP.

SETUP is

Host 1 Sever1 --server2 
---host2
[20.0.0.x/24]   [43.0.0.x/24]
[10.0.0.x/24]


GRE TUNNEL is configured between Server1 and Server2 .

Router 1:
===
#create namespaces
ip netns add vpp1

# create and configure 1st veth pair
ip link add name veth_vpp1 type veth peer name vpp1
ip link set dev vpp1 up
ip link set dev veth_vpp1 up netns vpp1

ip netns exec vpp1 \
  bash -c "
ip link set dev lo up
ip addr add 20.20.20.100/24 dev veth_vpp1
ip route add 0.0.0.0/0 via 20.20.20.1
"

VPP_SIDE CONFIGS
===
vppctl -s /run/vpp/cli-vpp1.sock create host-interface name vpp1
vppctl -s /run/vpp/cli-vpp1.sock set int state host-vpp1 up
vppctl -s /run/vpp/cli-vpp1.sock set int ip address host-vpp1 
20.20.20.1/24
vppctl -s /run/vpp/cli-vpp1.sock ping 20.20.20.100
vppctl -s /run/vpp/cli-vpp1.sock show ip neighbors
vppctl -s /run/vpp/cli-vpp1.sock set int state TenGigabitEthernet1/0/1 up
vppctl -s /run/vpp/cli-vpp1.sock set int ip address TenGigabitEthernet1/0/1 
43.0.0.1/24
vppctl -s /run/vpp/cli-vpp1.sock show interface address
vppctl -s /run/vpp/cli-vpp1.sock loopback create mac 1a:ab:3c:4d:5e:7f
vppctl -s /run/vpp/cli-vpp1.sock set interface ip address loop0 
10.100.0.7/31
vppctl -s /run/vpp/cli-vpp1.sock set int mtu 1360 loop0
vppctl -s /run/vpp/cli-vpp1.sock create  gre tunnel src 10.100.0.7 dst 
10.100.0.6
vppctl -s /run/vpp/cli-vpp1.sock set int state gre0 up
vppctl -s /run/vpp/cli-vpp1.sock ip route add 
10.10.10.0/24 via 10.100.0.6
vppctl -s /run/vpp/cli-vpp1.sock ip route add 
10.100.0.0/24 via 43.0.0.2


On server 2:
==


ip netns del vpp1
#create namespaces
ip netns add vpp1

# create and configure 1st veth pair
ip link add name veth_vpp1 type veth peer name vpp1
ip link set dev vpp1 up
ip link set dev veth_vpp1 up netns vpp1

ip netns exec vpp1 \
  bash -c "
ip link set dev lo up
ip addr add 10.10.10.100/24 dev veth_vpp1
ip route add 0.0.0.0/0 via 10.10.10.1
"

VPP_SIDE CONFIGS
===
vppctl -s /run/vpp/cli-vpp1.sock create host-interface name vpp1
vppctl -s /run/vpp/cli-vpp1.sock set int state host-vpp1 up
vppctl -s /run/vpp/cli-vpp1.sock set int ip address host-vpp1 
10.10.10.1/24
vppctl -s /run/vpp/cli-vpp1.sock ping 10.10.10.100
vppctl -s /run/vpp/cli-vpp1.sock show ip neighbors
vppctl -s /run/vpp/cli-vpp1.sock set int state TenGigabitEthernet1/0/1 up
vppctl -s /run/vpp/cli-vpp1.sock set int ip address TenGigabitEthernet1/0/1 
43.0.0.2/24
vppctl -s /run/vpp/cli-vpp1.sock show interface address
vppctl -s /run/vpp/cli-vpp1.sock loopback create mac 1a:2b:3c:4d:5e:7f
vppctl -s /run/vpp/cli-vpp1.sock set interface ip address loop0 
10.100.0.6/31
vppctl -s /run/vpp/cli-vpp1.sock set int mtu 1360 loop0
vppctl -s /run/vpp/cli-vpp1.sock create  gre tunnel src 10.100.0.6 dst 
10.100.0.7
vppctl -s /run/vpp/cli-vpp1.sock set int state gre0 up
vppctl -s /run/vpp/cli-vpp1.sock ip route add 
20.20.20.0/24 via 10.100.0.7
vppctl -s /run/vpp/cli-vpp1.sock ip route add 
10.100.0.0/24 via 43.0.0.1


Kindly let me know if I am doing it correctly.
>From FIB entries in server1 and server2, next hop is not Tunnel .

Regards,
Archana




-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#20241): https://lists.fd.io/g/vpp-dev/message/20241
Mute This Topic: https://lists.fd.io/mt/85971079/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] getting ip6-glean:address overflow drops

[Neale Ranns]

Hi Mark,

If you have a glean pointing out an interface, then you have an ipv6 address on 
that interface. The presence of an address will ipv6 enable the interface, so 
you don’t need that command as well.

Your errors are not necessarily signs of a bad config, but an indication that a 
host on that link is unreachable.

/neale

From: mark antony 
Date: Thursday, 23 September 2021 at 12:12
To: Neale Ranns 
Cc: vpp-dev@lists.fd.io 
Subject: Re: [vpp-dev] getting ip6-glean:address overflow drops
Hi neale,

Thanks for the info, is enabling ipv6 on interface with "enable ip6 interface" 
command is necessary? I saw before without it i could ping in a very simple 
ipv6 scenario but can enabling ipv6 on interfaces help this address overflow 
errors?

Best regards,
Mark

On Thu, Sep 23, 2021, 12:45 Neale Ranns 
mailto:ne...@graphiant.com>> wrote:
Hi Mark,

If traffic matches a ipv6-glean then it is destined to a host on an attached 
subnet that does not yet have an ND entry. Matching the glean will generate an 
ND solicitation to that host, but these are rate limited. An address overflow 
can happen when:

1.  when the rate limiting kicks in.

2.  the egress link is down

3.  some other reasons but I doubt that’s the case here: see 
src/vnet/ip-neoghbor/ip6_neighbor.c:202 for details.

/neale


From: vpp-dev@lists.fd.io<mailto:vpp-dev@lists.fd.io> 
mailto:vpp-dev@lists.fd.io>> on behalf of mark antony via 
lists.fd.io<http://lists.fd.io> 
mailto:gmail@lists.fd.io>>
Date: Wednesday, 22 September 2021 at 18:05
To: vpp-dev@lists.fd.io<mailto:vpp-dev@lists.fd.io> 
mailto:vpp-dev@lists.fd.io>>
Subject: [vpp-dev] getting ip6-glean:address overflow drops
Hi all,
I get about 5 million packet drops due to ip6-glean: address overflow drops. I 
attached my "vppctl sh error" command result. I am sure about my configuration. 
What could be the possible reasons for this error?

thanks,
mark

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#20192): https://lists.fd.io/g/vpp-dev/message/20192
Mute This Topic: https://lists.fd.io/mt/85793501/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] getting ip6-glean:address overflow drops

[Neale Ranns]

Hi Mark,

If traffic matches a ipv6-glean then it is destined to a host on an attached 
subnet that does not yet have an ND entry. Matching the glean will generate an 
ND solicitation to that host, but these are rate limited. An address overflow 
can happen when:

  1.  when the rate limiting kicks in.
  2.  the egress link is down
  3.  some other reasons but I doubt that’s the case here: see 
src/vnet/ip-neoghbor/ip6_neighbor.c:202 for details.

/neale


From: vpp-dev@lists.fd.io  on behalf of mark antony via 
lists.fd.io 
Date: Wednesday, 22 September 2021 at 18:05
To: vpp-dev@lists.fd.io 
Subject: [vpp-dev] getting ip6-glean:address overflow drops
Hi all,
I get about 5 million packet drops due to ip6-glean: address overflow drops. I 
attached my "vppctl sh error" command result. I am sure about my configuration. 
What could be the possible reasons for this error?

thanks,
mark

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#20190): https://lists.fd.io/g/vpp-dev/message/20190
Mute This Topic: https://lists.fd.io/mt/85793501/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 vnet event for route/FIB table update?

[Neale Ranns]

Hi,

No. the expectation is that the entity that added the route would inform other 
entities in the system. VPP is not the system message bus.

/neale


From: vpp-dev@lists.fd.io  on behalf of PRANAB DAS via 
lists.fd.io 
Date: Tuesday, 21 September 2021 at 13:29
To: vpp-dev@lists.fd.io 
Subject: [vpp-dev] VPP vnet event for route/FIB table update?

Hi

We have an application that requires to be notified when a FIB table is updated.
Is there any VPP event API (an equivalent of NETLINK_ROUTE ) to monitor FIB 
table updates?

Thank you very much

- Pranab Das

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#20176): https://lists.fd.io/g/vpp-dev/message/20176
Mute This Topic: https://lists.fd.io/mt/85763142/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] IPv6 unnumbered interface

[Neale Ranns]

Hi Artme,

I’d suggest you replace:
  set int unnumbered memif0/0 use loop0
with
  enable ip6 interface memif0/0

or add something like this:
  https://gerrit.fd.io/r/c/vpp/+/32770/4/src/vnet/interface.c#1701

/neale

From: vpp-dev@lists.fd.io  on behalf of Artem Glazychev 
via lists.fd.io 
Date: Thursday, 16 September 2021 at 13:25
To: vpp-dev@lists.fd.io 
Subject: [vpp-dev] IPv6 unnumbered interface

Hello,

I have a problem - unnumbered IPv6 interface is not working.

Configuration

For example, let's create memifs, one of them will be IPv6 unnumbered.

vpp1:

create interface memif id 0 master
set int ip address memif0/0 fc00::1/120
set int state memif0/0 up

vpp2:

create loopback interface
set int ip address loop0 fc00::2/120
set int state loop0 up

create interface memif id 0 slave
set int unnumbered memif0/0 use loop0
ip route add fc00::1/128 via memif0/0
set int state memif0/0 up
trace add memif-input 10

If we look at the traces:


Packet 1

00:00:15:424691: memif-input
  memif: hw_if_index 2 next-index 4
slot: ring 0
00:00:15:435043: ethernet-input
  IP6: 02:fe:1a:fa:94:43 -> 33:33:ff:00:00:02
00:00:15:435050: ip6-input
  ICMP6: fc00::1 -> ff02::1:ff00:2
tos 0x00, flow label 0x0, hop limit 255, payload length 32
  ICMP neighbor_solicitation checksum 0xcf5c
target address fc00::2
00:00:15:435055: ip6-mfib-forward-lookup
  fib 0 entry 4
00:00:15:435057: ip6-mfib-forward-rpf
  entry 4 itf -1 flags
00:00:15:435063: ip6-drop
fib:0 adj:4 flow:0
  ICMP6: fc00::1 -> ff02::1:ff00:2
tos 0x00, flow label 0x0, hop limit 255, payload length 32
  ICMP neighbor_solicitation checksum 0xcf5c
target address fc00::2
00:00:15:435070: error-drop
  rx:memif0/0
00:00:15:435087: drop
  ip6-input: drops due to concurrent reassemblies limit

IPv6 sends packets to mcast node, but:

DBGvpp# show mfib entry
FIB Entries:
0@(*, 0.0.0.0/0):  flags:Drop,
  Interfaces:
  multicast-ip4-chain
  [@0]: dpo-drop ip4
1@(*, 224.0.0.1/32):
  Interfaces:
  multicast-ip4-chain
  [@1]: dpo-replicate: [index:0 buckets:1 flags:[has-local ] to:[0:0]]
[0] [@1]: dpo-receive
2@(*, 224.0.0.2/32):
  Interfaces:
  multicast-ip4-chain
  [@1]: dpo-replicate: [index:1 buckets:1 flags:[has-local ] to:[0:0]]
[0] [@1]: dpo-receive
3@(*, ::/0):  flags:Drop,
  Interfaces:
  multicast-ip6-chain
  [@0]: dpo-drop ip6
4@(*, ff02::1:ff00:0/104):
  Interfaces:
   loop0: Accept,
  multicast-ip6-chain
  [@1]: dpo-replicate: [index:2 buckets:1 flags:[has-local ] to:[0:0]]
[0] [@1]: dpo-receive
5@(*, ff02::2/128):
  Interfaces:
   loop0: Accept,
  multicast-ip6-chain
  [@1]: dpo-replicate: [index:3 buckets:1 flags:[has-local ] to:[0:0]]
[0] [@1]: dpo-receive
6@(*, ff02::1/128):
  Interfaces:
   loop0: Accept,
  multicast-ip6-chain
  [@1]: dpo-replicate: [index:4 buckets:1 flags:[has-local ] to:[4:288]]
[0] [@1]: dpo-receive
7@(*, ff02::16/128):
  Interfaces:
   loop0: Accept,
  multicast-ip6-chain
  [@1]: dpo-replicate: [index:5 buckets:1 flags:[has-local ] to:[1:136]]
[0] [@1]: dpo-receive

Entry 4 has loop0 interface...

Is there a way to make the configuration correct?



-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#20147): https://lists.fd.io/g/vpp-dev/message/20147
Mute This Topic: https://lists.fd.io/mt/85649127/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]: Assert in vnet_mpls_tunnel_del()

[Neale Ranns]

Hi Rajiyh,

Maybe there’s something that still resolves through the tunnel when it’s 
deleted?

/neale

From: vpp-dev@lists.fd.io  on behalf of Rajith PR via 
lists.fd.io 
Date: Tuesday, 14 September 2021 at 13:17
To: vpp-dev 
Subject: [vpp-dev]: Assert in vnet_mpls_tunnel_del()
Hi All,

We recently started using the VPP's mpls tunnel constructs for our L2 cross 
connect application. In certain test scenarios we are seeing a crash in the 
delete path of the mpls tunnel.
Any pointers to fix the issue would be really helpful.

Version: 20.09
Call Stack:

Thread 1 (Thread 0x7f854cdd3400 (LWP 14261)):

#0  0x7f854c41b492 in __GI___waitpid (pid=21116, 
stat_loc=stat_loc@entry=0x7f84f79abc28, options=options@entry=0) at 
../sysdeps/unix/sysv/linux/waitpid.c:30

#1  0x7f854c386177 in do_system (line=) at 
../sysdeps/posix/system.c:149

#2  0x7f854c96918d in bd_signal_handler_cb () from 
/usr/local/lib/libbd-infra.so

#3  0x7f853db8953f in rtb_bd_signal_handler () from 
/usr/local/lib/libvlib.so.1.0.1

#4  0x7f853db899a2 in unix_signal_handler () from 
/usr/local/lib/libvlib.so.1.0.1

#5  

#6  __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:51

#7  0x7f854c377921 in __GI_abort () at abort.c:79

#8  0x7f853f58a9e3 in os_panic () from /usr/local/lib/librtbvpp.so

#9  0x7f853d35aaa9 in ?? () from /usr/local/lib/libvppinfra.so.1.0.1

#10 0x7f853d35a827 in _clib_error () from 
/usr/local/lib/libvppinfra.so.1.0.1

#11 0x7f853ecb2d75 in ?? () from /usr/local/lib/libvnet.so.1.0.1

#12 0x7f853ecb302d in fib_path_list_get_n_paths () from 
/usr/local/lib/libvnet.so.1.0.1

#13 0x7f853e8f0b5c in ?? () from /usr/local/lib/libvnet.so.1.0.1

#14 0x7f853e8ef942 in ?? () from /usr/local/lib/libvnet.so.1.0.1

#15 0x7f853e8ed51a in ?? () from /usr/local/lib/libvnet.so.1.0.1

#16 0x7f853e2e9e1a in ?? () from /usr/local/lib/libvnet.so.1.0.1

#17 0x7f853e2ea0e8 in vnet_sw_interface_set_flags () from 
/usr/local/lib/libvnet.so.1.0.1

#18 0x7f853e2eb6e4 in vnet_delete_sw_interface () from 
/usr/local/lib/libvnet.so.1.0.1

#19 0x7f853e2eede9 in vnet_delete_hw_interface () from 
/usr/local/lib/libvnet.so.1.0.1

#20 0x7f853e8ee368 in vnet_mpls_tunnel_del () from 
/usr/local/lib/libvnet.so.1.0.1

#21 0x7f853f74535a in rtb_vpp_l2_xconnect_route_del_handle () from 
/usr/local/lib/librtbvpp.so

#22 0x7f853f7453fa in rtb_vpp_l2_xconnect_route_handle () from 
/usr/local/lib/librtbvpp.so

#23 0x7f853f69551b in rtb_vpp_route_mapping_process () from 
/usr/local/lib/librtbvpp.so

#24 0x7f853f696a67 in rtb_vpp_route_adjacency_handle () from 
/usr/local/lib/librtbvpp.so

#25 0x7f853f696d22 in rtb_vpp_route_api_out_process () from 
/usr/local/lib/librtbvpp.so

#26 0x7f85406b3975 in fib_route_api_out_del () from 
/usr/local/lib/libfibd.so

#27 0x7f85406b3a83 in fib_route_api_out_tbl_vpp_wlk () from 
/usr/local/lib/libfibd.so

#28 0x7f85406a550b in fib_job_tmr_cb () from /usr/local/lib/libfibd.so

#29 0x7f854b27e6c2 in bds_qrunner_dispatch () from /usr/local/lib/libbds.so

#30 0x7f854b27f77c in bds_qrunner_dispatch_type () from 
/usr/local/lib/libbds.so

#31 0x7f854b27f9aa in bds_qrunner_dispatch_prepare () from 
/usr/local/lib/libbds.so

#32 0x7f854b27faa8 in bds_qrunner_expire () from /usr/local/lib/libbds.so

#33 0x7f854a67f616 in ?? () from /usr/local/lib/libqb.so

#34 0x7f854a67cfa7 in ?? () from /usr/local/lib/libqb.so

#35 0x7f854a67d797 in qb_loop_run_vpp_wrapper () from 
/usr/local/lib/libqb.so

#36 0x7f854a6890e8 in lib_qb_service_start_event_wrapper_loop () from 
/usr/local/lib/libqb.so

#37 0x7f854c96b262 in bd_event_loop_run_once () from 
/usr/local/lib/libbd-infra.so

#38 0x7f85060444f8 in ?? () from 
/usr/local/lib/vpp_plugins/rtbrick_plugin.so

#39 0x7f853db058dd in ?? () from /usr/local/lib/libvlib.so.1.0.1

#40 0x7f853d37ec34 in clib_calljmp () from 
/usr/local/lib/libvppinfra.so.1.0.1

#41 0x7f85255f7a10 in ?? ()

#42 0x7f853db0531f in ?? () from /usr/local/lib/libvlib.so.1.0.1
Code Snippet for Creating Tunnel (rpath has the out-labels and  nexthop):

  vec_add1(rpaths, rpath);
  tunnel_sw_if_index = vnet_mpls_tunnel_create(1, 0, NULL);
  vnet_mpls_tunnel_path_add(tunnel_sw_if_index, rpaths);
  vnet_sw_interface_admin_up(vnm, tunnel_sw_if_index);

Code Snippet for Deleting Tunnel.


 vec_add1(rpaths, rpath);
 vnet_mpls_tunnel_path_remove(sw_if_index, rpaths);
 vec_free(rpaths);
 vnet_mpls_tunnel_del(sw_if_index);

Thanks,
Rajith


NOTICE TO RECIPIENT This e-mail message and any attachments are confidential 
and may be privileged. If you received this e-mail in error, any review, use, 
dissemination, distribution, or copying of this e-mail is strictly prohibited. 
Please notify us immediately of the error by return e-mail and please delete 
this message from your system. For more information ab

Re: [vpp-dev] IPSec input/output: default action for non-matching traffic

[Neale Ranns]

Hi Zach,

Apologies for the late reply and thank you for the considered analysis.

..snip..

Is there a reason that the input side is setup like this? Unless there is a 
good reason for allowing inbound traffic by default, I would propose to patch 
the ipsec-input node to align with ipsec-output and drop traffic by default.

No reason I know of. Please patch as you suggest.

Regards,
neale

Best,

Zach

[1]: https://datatracker.ietf.org/doc/html/rfc4301
[2]: https://datatracker.ietf.org/doc/html/rfc4301#section-4.4.1
[3]: https://datatracker.ietf.org/doc/html/rfc4301#section-5
[4]: https://datatracker.ietf.org/doc/html/rfc4301#section-5.2


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#20113): https://lists.fd.io/g/vpp-dev/message/20113
Mute This Topic: https://lists.fd.io/mt/84943480/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] Question regarding ip4/ip6 nexthop load balance flexibility #vnet

[Neale Ranns]

Hi Venky,

Which nodes get called depends on the nature of the route. Take this trivial 
example


DBGvpp# set int state loop0 up

DBGvpp# set int ip addr loop0 10.0.0.1/24


This route is non recursive



DBGvpp# ip route 1.1.1.1/32 via 10.0.0.2 loop0


This one is recursive



DBGvpp# ip route 2.2.2.2/32 via 10.0.0.2


You can see the DPO graph built for them is different.



DBGvpp# sh ip fib 1.1.1.1

ipv4-VRF:0, fib_index:0, flow hash:[src dst sport dport proto flowlabel ] 
epoch:0 flags:none locks:[recursive-resolution:1, default-route:1, ]

1.1.1.1/32 fib:0 index:11 locks:2

  CLI refs:1 src-flags:added,contributing,active,

path-list:[16] locks:2 flags:shared, uPRF-list:12 len:1 itfs:[1, ]

  path:[18] pl-index:16 ip4 weight=1 pref=0 attached-nexthop:  
oper-flags:resolved,

10.0.0.2 loop0

  [@0]: arp-ipv4: via 10.0.0.2 loop0



 forwarding:   unicast-ip4-chain

  [@0]: dpo-load-balance: [proto:ip4 index:13 buckets:1 uRPF:12 to:[0:0]]

[0] [@3]: arp-ipv4: via 10.0.0.2 loop0


This recursive prefix has an extra load-balanace object



DBGvpp# sh ip fib 2.2.2.2

ipv4-VRF:0, fib_index:0, flow hash:[src dst sport dport proto flowlabel ] 
epoch:0 flags:none locks:[recursive-resolution:1, default-route:1, ]

2.2.2.2/32 fib:0 index:12 locks:2

  CLI refs:1 src-flags:added,contributing,active,

path-list:[18] locks:2 flags:shared, uPRF-list:15 len:1 itfs:[1, ]

  path:[20] pl-index:18 ip4 weight=1 pref=0 recursive:  oper-flags:resolved,

via 10.0.0.2 in fib:0 via-fib:13 via-dpo:[dpo-load-balance:14]



 forwarding:   unicast-ip4-chain

  [@0]: dpo-load-balance: [proto:ip4 index:15 buckets:1 uRPF:15 to:[0:0]]

[0] [@12]: dpo-load-balance: [proto:ip4 index:14 buckets:1 uRPF:14 
to:[0:0]].  <<<< HERE

  [0] [@3]: arp-ipv4: via 10.0.0.2 loop0




The first LB in the DPO graph will be the one used in ip4-lookup the second 
one, when present, will be used in ip4-load-balance.

The golden rule of forwarding is to do all the heavy lifting in the 
control-plane so you can do the absolute minimum in the DP, because down there 
extra work means worse performance. The load-balance bucket choice is basically 
choice = buckets[flow-hash & n_buckets], which is the minimum we can do. I 
would advise that you try and keep it this way by:
1 – choosing how the flow hash is calculated (see the list of ‘algorithms’ 
available in ip_flow_hash_set)
2 – choosing in the CP how the buckets are populated.

If 2. Is an option we can talk more about how you might go about doing that 😊
Are you looking to change the bucket selection for all prefixes or most, some 
or a few?


/neale



From: Venky Venkatesh 
Date: Tuesday, 7 September 2021 at 20:11
To: Neale Ranns 
Cc: vpp-dev@lists.fd.io 
Subject: Re: [vpp-dev] Question regarding ip4/ip6 nexthop load balance 
flexibility #vnet
Hi Neale,
Thanks for getting back. I thought as much that cloning code (even though I do 
a graph node replacement) wouldn't have been the way it would be done by 
someone knowledgeable in the area.

When I looked again at the code, the area I intended to change seems to be a 
node in itself. Is this code for ECMP? (appears to be like that)
 
VLIB_REGISTER_NODE<https://docs.fd.io/vpp/21.06/d0/da8/vlib_2node_8h.html#a025e3596085258b3bbd8e1a99ab026f4>
 
(ip4_load_balance_node<https://docs.fd.io/vpp/21.06/dc/da9/ip4__forward_8c.html#a90b92667856f47252d614ba214ace26b>)
 =
270 {
271  .name = "ip4-load-balance",
272  .vector_size = sizeof 
(u32<https://docs.fd.io/vpp/21.06/de/deb/vppinfra_2types_8h.html#a162050b1a67fffab30498a67c9ab0f09>),
273  .sibling_of = "ip4-lookup",
274  .format_trace = 
format_ip4_lookup_trace<https://docs.fd.io/vpp/21.06/dc/da9/ip4__forward_8c.html#af59e7cb8282da4ff432f4237f1ab1e4a>,
275 };
For some reason it doesn't show up in 
https://docs.fd.io/vpp/21.06/d9/db0/nodes.html -- which is how I missed it the 
1st time around.

The localized changes that I was intending to do are in 
load_balance_get_bucket_i and load_balance_get_fwd_bucket (i.e. having computed 
the hash, the way I select the next hop could differ). I could also entirely 
outsource the hash computation and nexthop calculation to my code (in which 
case, also gets included in my changes).

The load_balance_* code gets invoked from ip4_lookup_* and also from 
ip4_load_balance_*. Am I right that if I want to change the next hop selection, 
I would replace ip4_load_balance_* with my implementation? However I do not see 
this chained in the graph.

Look forward to your response
Thanks
-Venky






On Sun, Sep 5, 2021 at 6:52 AM Neale Ranns 
mailto:ne...@graphiant.com>> wrote:

Hi Venky,

There are several ways you might go about this but I would council that cloning 
code is a last resort – it would be a mainanence headache if you replace the 
current one or have i’s own set of challenges to use your replace node. if you 
could give me some more detail o

Re: [vpp-dev] Regarding VPP IPSec pipeline

[Neale Ranns]

Hi Prashant,

From: vpp-dev@lists.fd.io  on behalf of Prashant Upadhyaya 
via lists.fd.io 
Date: Monday, 6 September 2021 at 11:05
To: vpp-dev@lists.fd.io 
Subject: [vpp-dev] Regarding VPP IPSec pipeline
Hi,

I am using VPP21.06.
I have successfully created an IPSec tunnel between VPP and a Strong Swan peer.
Packets from VPP are going into ESP towards the peer, the peer is
responding back with ESP as well (inner cleartext packets are ICMP)

Now then, I have a node of my own which is sitting on the ip4-unicast
arc and has a runs before clause like thus --
.runs_before = VNET_FEATURES ("ip4-lookup")

I am expecting that when the ESP packet lands at VPP, it will undergo
decryption and the inner IP packet would go again to ip4-input and
from there hit my node on the ip4-unicast arc. However this does not
happen. It appears that the packet is going to ip4-lookup bypassing my
node.

That does happen. The first time ip4-input is run for the physical interface, 
then after decrypt/decap ip4-input is run for the tunnel interface. So your 
feature should be enabled on the tunnel interface.

If this is what you have configured and it’s not working, please send a packet 
trace and the output of ‘sh int’ and ‘sh int feat YOUR_TUNNEL’

/neale



So the question is how do I get the decrypted inner packet on ESP to my node.

Regards
-Prashant

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#20077): https://lists.fd.io/g/vpp-dev/message/20077
Mute This Topic: https://lists.fd.io/mt/85408250/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] Question regarding ip4/ip6 nexthop load balance flexibility #vnet

[Neale Ranns]

Hi Venky,

There are several ways you might go about this but I would council that cloning 
code is a last resort – it would be a mainanence headache if you replace the 
current one or have i’s own set of challenges to use your replace node. if you 
could give me some more detail on how you want to change the next-hop selection 
I will gladly give you some specific advice.

/neale


From: vpp-dev@lists.fd.io  on behalf of Venky Venkatesh 
via lists.fd.io 
Date: Wednesday, 1 September 2021 at 16:48
To: vpp-dev@lists.fd.io 
Subject: [vpp-dev] Question regarding ip4/ip6 nexthop load balance flexibility 
#vnet
Hi,
I am new to fd.io. So pls pardon my ignorance.
I wanted to experiment with different next hop selection algorithms once the 
destination IP is looked up. I looked at the ip4 code. My changes would be 
localized to how the nexthop is determined after the hash is calculated 
(currently it is going thru load_balance code). To my understanding it appears 
that ip4_lookup graph node has both the lookup and the next hop selection all 
bundled in one.  If that is correct, then is the only way to try out alternate 
next hop selection algorithms be to create a graph node which is practically a 
clone of the ip4_lookup and then change the required portions in the cloned 
node code? If so, is this workflow in line with the way flexibility was 
intended?
Any ideas welcome.
Thanks
-Venky
#vnet

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#20070): https://lists.fd.io/g/vpp-dev/message/20070
Mute This Topic: https://lists.fd.io/mt/85304201/21656
Mute #vnet:https://lists.fd.io/g/vpp-dev/mutehashtag/vnet
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [vpp-dev] Adding new route via ipv6 link-local

[Neale Ranns]

Hi Ed,

When creating an adjacency for the first time we send out a probe packet 
(ARP/ND) to see if the peer will resolve it.

/neale

From: Ed Warnicke 
Date: Friday, 20 August 2021 at 16:54
To: Neale Ranns 
Cc: zsta...@gmail.com , Artem Glazychev 
, vpp-dev 
Subject: Re: [vpp-dev] Adding new route via ipv6 link-local
Neale,

Question... looking at the trace it looks like we are having an issue with 
fib_sas6_get ... could you help me understand why we are calling fib_sas6_get 
in this situation?

Ed

On Fri, Aug 20, 2021 at 9:49 AM Neale Ranns 
mailto:ne...@graphiant.com>> wrote:

Hi Ed,

It does. But in this case the command is adding a route through an interface, 
which is not the same as configuring a prefix on an interface (nor ip6 enabling 
it).

/neale

From: Ed Warnicke mailto:hagb...@gmail.com>>
Date: Friday, 20 August 2021 at 16:40
To: Neale Ranns mailto:ne...@graphiant.com>>
Cc: zsta...@gmail.com<mailto:zsta...@gmail.com> 
mailto:zsta...@gmail.com>>, Artem Glazychev 
mailto:artem.glazyc...@xored.com>>, vpp-dev 
mailto:vpp-dev@lists.fd.io>>
Subject: Re: [vpp-dev] Adding new route via ipv6 link-local
Neale,

I'm a bit confused... I had previously thought that *adding* an IPv6 address to 
a link *did* IPv6 enable it...

Ed

On Fri, Aug 20, 2021 at 9:20 AM Neale Ranns 
mailto:ne...@graphiant.com>> wrote:
Hi Artem, Stanislav,

I agree graceful handling is needed, return false if there is no link local.

If you enabled ip6 on the link first, this wouldn’t be a problem. The link will 
need to be ip6 enabled if you want something to reply.

/neale


From: vpp-dev@lists.fd.io<mailto:vpp-dev@lists.fd.io> 
mailto:vpp-dev@lists.fd.io>> on behalf of Stanislav Zaikin 
via lists.fd.io<http://lists.fd.io> 
mailto:gmail@lists.fd.io>>
Date: Friday, 20 August 2021 at 16:10
To: Artem Glazychev 
mailto:artem.glazyc...@xored.com>>
Cc: vpp-dev mailto:vpp-dev@lists.fd.io>>
Subject: Re: [vpp-dev] Adding new route via ipv6 link-local
Hello Artem,

Looks like we need (at least) to add a check for nullptr.

DBGvpp# create tap
tap0
DBGvpp# set interface state tap0 up
DBGvpp# ip route add fa::1/120 via fe80::1 tap0

Thread 1 "vpp_main" received signal SIGSEGV, Segmentation fault.
0x7774ba90 in ip6_address_copy (dst=0x7fffaf487aa0, src=0x0) at 
/home/zstas/vpp/src/vnet/ip/ip6_packet.h:129
129  dst->as_u64[0] = src->as_u64[0];
(gdb) bt
#0  0x7774ba90 in ip6_address_copy (dst=0x7fffaf487aa0, src=0x0) at 
/home/zstas/vpp/src/vnet/ip/ip6_packet.h:129
#1  0x7774b892 in fib_sas6_get (sw_if_index=1, dst=0x7fffb91b4e50, 
src=0x7fffaf487aa0) at /home/zstas/vpp/src/vnet/fib/fib_sas.c:105

On Fri, 20 Aug 2021 at 15:20, Artem Glazychev 
mailto:artem.glazyc...@xored.com>> wrote:

Hello,

Found a crash: if we add the route via fe80:: after the interface upping - vpp 
crashes.

For example:

DBGvpp# create tap

tap0

DBGvpp# set int state tap0 up

DBGvpp# ip route add fa::1/120 via fe80::1 tap0

make: *** [Makefile:537: run] Aborted



If we swap set ... up and ip route ... - no crashes.

Could you please explain me if such a situation is possible at all?
In any case, I believe that vpp should not crash.

Thanks.



--
Best regards
Stanislav Zaikin



-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#20002): https://lists.fd.io/g/vpp-dev/message/20002
Mute This Topic: https://lists.fd.io/mt/85020362/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] Adding new route via ipv6 link-local

[Neale Ranns]

Hi Ed,

It does. But in this case the command is adding a route through an interface, 
which is not the same as configuring a prefix on an interface (nor ip6 enabling 
it).

/neale

From: Ed Warnicke 
Date: Friday, 20 August 2021 at 16:40
To: Neale Ranns 
Cc: zsta...@gmail.com , Artem Glazychev 
, vpp-dev 
Subject: Re: [vpp-dev] Adding new route via ipv6 link-local
Neale,

I'm a bit confused... I had previously thought that *adding* an IPv6 address to 
a link *did* IPv6 enable it...

Ed

On Fri, Aug 20, 2021 at 9:20 AM Neale Ranns 
mailto:ne...@graphiant.com>> wrote:
Hi Artem, Stanislav,

I agree graceful handling is needed, return false if there is no link local.

If you enabled ip6 on the link first, this wouldn’t be a problem. The link will 
need to be ip6 enabled if you want something to reply.

/neale


From: vpp-dev@lists.fd.io<mailto:vpp-dev@lists.fd.io> 
mailto:vpp-dev@lists.fd.io>> on behalf of Stanislav Zaikin 
via lists.fd.io<http://lists.fd.io> 
mailto:gmail@lists.fd.io>>
Date: Friday, 20 August 2021 at 16:10
To: Artem Glazychev 
mailto:artem.glazyc...@xored.com>>
Cc: vpp-dev mailto:vpp-dev@lists.fd.io>>
Subject: Re: [vpp-dev] Adding new route via ipv6 link-local
Hello Artem,

Looks like we need (at least) to add a check for nullptr.

DBGvpp# create tap
tap0
DBGvpp# set interface state tap0 up
DBGvpp# ip route add fa::1/120 via fe80::1 tap0

Thread 1 "vpp_main" received signal SIGSEGV, Segmentation fault.
0x7774ba90 in ip6_address_copy (dst=0x7fffaf487aa0, src=0x0) at 
/home/zstas/vpp/src/vnet/ip/ip6_packet.h:129
129  dst->as_u64[0] = src->as_u64[0];
(gdb) bt
#0  0x7774ba90 in ip6_address_copy (dst=0x7fffaf487aa0, src=0x0) at 
/home/zstas/vpp/src/vnet/ip/ip6_packet.h:129
#1  0x7774b892 in fib_sas6_get (sw_if_index=1, dst=0x7fffb91b4e50, 
src=0x7fffaf487aa0) at /home/zstas/vpp/src/vnet/fib/fib_sas.c:105

On Fri, 20 Aug 2021 at 15:20, Artem Glazychev 
mailto:artem.glazyc...@xored.com>> wrote:

Hello,

Found a crash: if we add the route via fe80:: after the interface upping - vpp 
crashes.

For example:

DBGvpp# create tap

tap0

DBGvpp# set int state tap0 up

DBGvpp# ip route add fa::1/120 via fe80::1 tap0

make: *** [Makefile:537: run] Aborted



If we swap set ... up and ip route ... - no crashes.

Could you please explain me if such a situation is possible at all?
In any case, I believe that vpp should not crash.

Thanks.



--
Best regards
Stanislav Zaikin



-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#2): https://lists.fd.io/g/vpp-dev/message/2
Mute This Topic: https://lists.fd.io/mt/85020362/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] Adding new route via ipv6 link-local

[Neale Ranns]

Hi Stanislav,

Excellent, thank you!

/neale


From: Stanislav Zaikin 
Date: Friday, 20 August 2021 at 16:38
To: Neale Ranns 
Cc: Artem Glazychev , vpp-dev 
Subject: Re: [vpp-dev] Adding new route via ipv6 link-local
Hi Neale,

If there are no volunteers, there's the patch: 
https://gerrit.fd.io/r/c/vpp/+/33558

On Fri, 20 Aug 2021 at 16:20, Neale Ranns 
mailto:ne...@graphiant.com>> wrote:
Hi Artem, Stanislav,

I agree graceful handling is needed, return false if there is no link local.

If you enabled ip6 on the link first, this wouldn’t be a problem. The link will 
need to be ip6 enabled if you want something to reply.

/neale


From: vpp-dev@lists.fd.io<mailto:vpp-dev@lists.fd.io> 
mailto:vpp-dev@lists.fd.io>> on behalf of Stanislav Zaikin 
via lists.fd.io<http://lists.fd.io> 
mailto:gmail@lists.fd.io>>
Date: Friday, 20 August 2021 at 16:10
To: Artem Glazychev 
mailto:artem.glazyc...@xored.com>>
Cc: vpp-dev mailto:vpp-dev@lists.fd.io>>
Subject: Re: [vpp-dev] Adding new route via ipv6 link-local
Hello Artem,

Looks like we need (at least) to add a check for nullptr.

DBGvpp# create tap
tap0
DBGvpp# set interface state tap0 up
DBGvpp# ip route add fa::1/120 via fe80::1 tap0

Thread 1 "vpp_main" received signal SIGSEGV, Segmentation fault.
0x7774ba90 in ip6_address_copy (dst=0x7fffaf487aa0, src=0x0) at 
/home/zstas/vpp/src/vnet/ip/ip6_packet.h:129
129  dst->as_u64[0] = src->as_u64[0];
(gdb) bt
#0  0x7774ba90 in ip6_address_copy (dst=0x7fffaf487aa0, src=0x0) at 
/home/zstas/vpp/src/vnet/ip/ip6_packet.h:129
#1  0x7774b892 in fib_sas6_get (sw_if_index=1, dst=0x7fffb91b4e50, 
src=0x7fffaf487aa0) at /home/zstas/vpp/src/vnet/fib/fib_sas.c:105

On Fri, 20 Aug 2021 at 15:20, Artem Glazychev 
mailto:artem.glazyc...@xored.com>> wrote:

Hello,

Found a crash: if we add the route via fe80:: after the interface upping - vpp 
crashes.

For example:

DBGvpp# create tap

tap0

DBGvpp# set int state tap0 up

DBGvpp# ip route add fa::1/120 via fe80::1 tap0

make: *** [Makefile:537: run] Aborted



If we swap set ... up and ip route ... - no crashes.

Could you please explain me if such a situation is possible at all?
In any case, I believe that vpp should not crash.

Thanks.



--
Best regards
Stanislav Zaikin


--
Best regards
Stanislav Zaikin

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#19998): https://lists.fd.io/g/vpp-dev/message/19998
Mute This Topic: https://lists.fd.io/mt/85020362/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] Adding new route via ipv6 link-local

[Neale Ranns]

Hi Artem, Stanislav,

I agree graceful handling is needed, return false if there is no link local.

If you enabled ip6 on the link first, this wouldn’t be a problem. The link will 
need to be ip6 enabled if you want something to reply.

/neale


From: vpp-dev@lists.fd.io  on behalf of Stanislav Zaikin 
via lists.fd.io 
Date: Friday, 20 August 2021 at 16:10
To: Artem Glazychev 
Cc: vpp-dev 
Subject: Re: [vpp-dev] Adding new route via ipv6 link-local
Hello Artem,

Looks like we need (at least) to add a check for nullptr.

DBGvpp# create tap
tap0
DBGvpp# set interface state tap0 up
DBGvpp# ip route add fa::1/120 via fe80::1 tap0

Thread 1 "vpp_main" received signal SIGSEGV, Segmentation fault.
0x7774ba90 in ip6_address_copy (dst=0x7fffaf487aa0, src=0x0) at 
/home/zstas/vpp/src/vnet/ip/ip6_packet.h:129
129  dst->as_u64[0] = src->as_u64[0];
(gdb) bt
#0  0x7774ba90 in ip6_address_copy (dst=0x7fffaf487aa0, src=0x0) at 
/home/zstas/vpp/src/vnet/ip/ip6_packet.h:129
#1  0x7774b892 in fib_sas6_get (sw_if_index=1, dst=0x7fffb91b4e50, 
src=0x7fffaf487aa0) at /home/zstas/vpp/src/vnet/fib/fib_sas.c:105

On Fri, 20 Aug 2021 at 15:20, Artem Glazychev 
mailto:artem.glazyc...@xored.com>> wrote:

Hello,

Found a crash: if we add the route via fe80:: after the interface upping - vpp 
crashes.

For example:

DBGvpp# create tap

tap0

DBGvpp# set int state tap0 up

DBGvpp# ip route add fa::1/120 via fe80::1 tap0

make: *** [Makefile:537: run] Aborted



If we swap set ... up and ip route ... - no crashes.

Could you please explain me if such a situation is possible at all?
In any case, I believe that vpp should not crash.

Thanks.




--
Best regards
Stanislav Zaikin

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#19996): https://lists.fd.io/g/vpp-dev/message/19996
Mute This Topic: https://lists.fd.io/mt/85020362/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 dpdk backend with vpp 20.09 using stable/2009

[Neale Ranns]

Hi Venu,

Before adding any IPSec state:

DBGvpp# ipsec select ?
  ipsec select backend ipsec select backend  


/neale

From: vpp-dev@lists.fd.io  on behalf of Venumadhav Josyula 
via lists.fd.io 
Date: Tuesday, 17 August 2021 at 08:30
To: Sweetu Hubby 
Cc: vpp-dev 
Subject: Re: [vpp-dev] using dpdk backend with vpp 20.09 using stable/2009
Hi Sergio,

Any help would be really appreciated.

Thanks,
Regards,
Venu

On Tue, 17 Aug 2021 at 11:21, Venumadhav Josyula via 
lists.fd.io 
mailto:gmail@lists.fd.io>> wrote:
Hi All,
Please note we have build vpp from stable/2009 branch, following is startup.conf
unix {
#  nodaemon
  log /var/log/vpp/vpp.log
  full-coredump
  cli-listen /run/vpp/cli.sock
  gid vpp
  exec /etc/vpp/setup.conf
}
api-trace {
  on
}
api-segment {
  gid vpp
}
socksvr {
  default
}
cpu {
  main-core 18
  corelist-workers 20,22
  no-multi-seg
}
dpdk {
  dev default {
 num-rx-desc 4096
 num-tx-desc 4096
  }

  dev :87:10.0 { ## Port handled by vfio-pci driver in host
name eth0
  }
  dev :87:10.1 { ## Port handled by vfio-pci driver in host
name eth1
  }
  socket-mem 1024,1024
  vdev crypto_aesni_mb0
  vdev crypto_aesni_mb1

}

Commands used to ipsec tunnel
vpp
---
ipsec sa add 10 spi 1001 esp crypto-alg aes-cbc-256 crypto-key 
4a506a794f574265564551694d6537684a506a794f574265564551694d653768 integ-alg 
sha-256-128 integ-key 
2b7e151628aed2a6abf7158809cf4f3d2b7e151628aed2a6abf7158809cf4f3d tunnel-src 
172.17.4.246 tunnel-dst 172.17.4.251
ipsec sa add 11 spi 1002 esp crypto-alg aes-cbc-256 crypto-key 
4a506a794f574265564551694d6537684a506a794f574265564551694d653768 integ-alg 
sha-256-128 integ-key 
2b7e151628aed2a6abf7158809cf4f3d2b7e151628aed2a6abf7158809cf4f3d tunnel-src 
172.17.4.251 tunnel-dst 172.17.4.246
ipsec spd add 1
set interface ipsec spd eth0 1
ipsec policy add spd 1 priority 10 outbound action protect sa 10 local-ip-range 
172.17.4.246 - 172.17.4.246 remote-ip-range 172.17.4.251 - 172.17.4.251
ipsec policy add spd 1 priority 10 inbound action protect sa 11 local-ip-range 
172.17.4.246 - 172.17.4.246 remote-ip-range 172.17.4.251 - 172.17.4.251

ipsec policy add spd 1 priority 100 inbound action bypass protocol 50
ipsec policy add spd 1 priority 100 outbound action bypass protocol 50


Following output

vpp# show ipsec backends
IPsec AH backends available:
   Name Index Active
  crypto engine backend   0 yes
IPsec ESP backends available:
   Name Index Active
  crypto engine backend   0 yes
   dpdk backend   1 no
vpp#
vpp# show version
vpp v20.09.0-65~gdbaff84 built by root on 9315b7360381 at 2021-08-05T08:20:42
vpp# show dp
dpdk  dpo
vpp# show dpdk version
DPDK Version: DPDK 20.08.0
DPDK EAL init args:   -c 54 -n 4 --in-memory --vdev crypto_aesni_mb0 
--vdev crypto_aesni_mb1 --file-prefix vpp -w :87:10.0 -w :87:10.1 
--master-lcore 18
vpp#

How do we make it use dpdk backend ?

Thanks,
Regards,
Venu




-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#19974): https://lists.fd.io/g/vpp-dev/message/19974
Mute This Topic: https://lists.fd.io/mt/84941801/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] some confusions about l2 forward and flood

[Neale Ranns]

Hi Xiaopeng,

If you disable flooding in a BD then it will not forward broadcast nor 
multicast (BM) packets, because there is nothing else to do with such packets 
other than flood. The l2fib is not consulted for BM packets, so if you added a 
static entry for a BM address it won’t be used. The packet in the trace was 
broadcast, hence it was dropped.

/neale

From: vpp-dev@lists.fd.io  on behalf of Xiaopeng Bai via 
lists.fd.io 
Date: Thursday, 12 August 2021 at 06:09
To: vpp-dev@lists.fd.io 
Subject: [vpp-dev] some confusions about l2 forward and flood
Hi everyone!

When I was testing the bridge function，everything worked fine with the 
following configuration：
  BD-ID   Index   BSN  Age(min)   Learn ForwrdUU-FloodFlood
ARP-Term  ARP-ufwd   BVI-Intf
1   1  0 off   offon   floodon   
off   offN/A
But when i disabled bridge-domain flood and add static mac for mac table, the 
bridge-domain didn't forward packets and show errors likes below:
Packet 1

00:02:40:993565: dpdk-input
  GbitEth0/0/2 rx queue 0
  buffer 0x4b4e78: current data 0, length 60, buffer-pool 0, ref-count 1, 
totlen-nifb 0, trace handle 0x100
   ext-hdr-valid
   l4-cksum-computed l4-cksum-correct
  PKT MBUF: port 1, nb_segs 1, pkt_len 60
buf_len 2176, data_len 60, ol_flags 0x180, data_off 128, phys_addr 
0x91f39e80
packet_type 0x0 l2_len 0 l3_len 0 outer_l2_len 0 outer_l3_len 0
rss 0x0 fdir.hi 0x0 fdir.lo 0x0
Packet Offload Flags
  PKT_RX_IP_CKSUM_GOOD (0x0080) IP cksum of RX pkt. is valid
  PKT_RX_L4_CKSUM_GOOD (0x0100) L4 cksum of RX pkt. is valid
  ARP: c8:d3:ff:ba:51:2b -> ff:ff:ff:ff:ff:ff
  request, type ethernet/IP4, address size 6/4
  c8:d3:ff:ba:51:2b/192.168.0.200 -> 00:00:00:00:00:00/192.168.0.111
00:02:40:993578: flowprobe-l2
  FLOWPROBE[IP4]: rx_sw_if_index 0, tx_sw_if_index 0, timestamp 0, size 0
00:02:40:993588: ethernet-input
  ARP: c8:d3:ff:ba:51:2b -> ff:ff:ff:ff:ff:ff
00:02:40:993592: l2-input
  l2-input: sw_if_index 2 dst ff:ff:ff:ff:ff:ff src c8:d3:ff:ba:51:2b
00:02:40:993595: feature-bitmap-drop
  feat_bitmap_drop: feature bitmap 0x0001
00:02:40:993597: error-drop
  rx:GbitEth0/0/2
00:02:40:993599: drop
  feature-bitmap-drop: L2 feature forwarding disabled
Why l2_input dropped packets? I browsed the l2_input.c codes and find some 
codes like this:
/* Disable bridge forwarding (flooding will execute instead if not xconnect) */
  feat_mask &= ~(L2INPUT_FEAT_FWD |
 L2INPUT_FEAT_UU_FLOOD |
 L2INPUT_FEAT_UU_FWD | L2INPUT_FEAT_GBP_FWD);
Some confusions are why Disable bridge forwarding  and instead with flooding?
some suggestions are appreciated！

Best Regeards,
Xiaopeng


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#19964): https://lists.fd.io/g/vpp-dev/message/19964
Mute This Topic: https://lists.fd.io/mt/84833350/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] BVI interface on a Bridge domain

[Neale Ranns]

Hi,

The packet has a multicast destination MAC so it was flooded, including to the 
BVI. The BVI dropped it because it does not have a valid ether type. The trace 
says the ethertype value was 0x162. I don’t know what a gns3 simulation is, nor 
do I want to 😉

/neale


From: vpp-dev@lists.fd.io  on behalf of Mohsen Meamarian 
via lists.fd.io 
Date: Monday, 9 August 2021 at 19:05
To: Mohsen Meamarian 
Cc: vpp-dev@lists.fd.io 
Subject: Re: [vpp-dev] BVI interface on a Bridge domain
Hi ,
What could be the reason for the " l2-flood: BVI packet with unhandled 
ethertype " error? Could gns3 simulation conditions cause it?

On Mon, Aug 9, 2021 at 11:53 AM Mohsen Meamarian via 
lists.fd.io 
mailto:gmail@lists.fd.io>> wrote:
Hi friends ,
I have a problem with ARP delivery to the BVI interface on a BD. I see in trace 
that the ARP packet after l2 flooding goes to the Non-BVI output interface , 
but this doesn't happen for a loopback/BVI interface. thus I can't ping 
100.3.4.4 from 100.3.4.11.

create bridge-domain 2
set int l2 bridge GigabitEthernet2/6/0 2
set int state GigabitEthernet2/6/0 up

create loopback interface
set int l2 bridge loop0 2 bvi
set int state loop0 up
set int ip address loop0 100.3.4.12 / 3.3.3.3/24

Should I configure a route for loop0/BVI or use set ip arp command?
I also use ip route table 0 100.3.4.0/24 via loop0 but the 
problem remains.I use vpp 18.10.



-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#19963): https://lists.fd.io/g/vpp-dev/message/19963
Mute This Topic: https://lists.fd.io/mt/84763705/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] problem with updating incomplete adj nbr entries upon MAC address change

[Neale Ranns]

Dear Ivan,

That’s the best bug report I’ve seen in ages, so thank you!
I’ll take your patch as a starting point, but I’ll think I move the 
responsibility for walking the incomplete adjacencies into the adj code; it 
seems a little unfair for the ip-neighbour module to be responsible for 
updating state it does not own.
Can I add a ‘signed-off’ line with this email in the commit so you get the 
deserved credit?

/neale


From: vpp-dev@lists.fd.io  on behalf of Ivan Shvedunov via 
lists.fd.io 
Date: Wednesday, 11 August 2021 at 15:06
To: vpp-dev 
Subject: [vpp-dev] problem with updating incomplete adj nbr entries upon MAC 
address change
Hi,

I've stumbled upon a problem in the neighbor adj code that handles incomplete 
entries. These entries are pre-created under some circumstances such as 
creation of a VXLAN tunnel and used to make Ethernet headers for outbound ARP 
requests. Problem is, when the MAC address of the interface changes, these 
entries are never updated.
I've posted the detailed description and the patch as a GitHub gist [1].
Sadly, my fd.io Gerrit account is completely broken after what 
turned out to be an unsuccessful login fix by the LF infra (IT-22698, IT-22257) 
so I can't post the patch myself, sorry.

[1] https://gist.github.com/ivan4th/d72d08be0fc53228cd4e7c6f19926c09

--
Ivan Shvedunov mailto:ivan...@gmail.com>>
;; My GPG fingerprint is: 2E61 0748 8E12 BB1A 5AB9  F7D0 613E C0F8 0BC5 2807

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#19957): https://lists.fd.io/g/vpp-dev/message/19957
Mute This Topic: https://lists.fd.io/mt/84815615/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] Regarding Traffic selectors (IP and port range) usage in vnet/ipsec encrypt

[Neale Ranns]

Hi Vijay,

Use the APIs in ipsec_spd.h

/neale

From: Vijay Kumar 
Date: Wednesday, 11 August 2021 at 14:05
To: Neale Ranns 
Cc: vpp-dev 
Subject: Re: [vpp-dev] Regarding Traffic selectors (IP and port range) usage in 
vnet/ipsec encrypt
Hi Neale,

Thanks for the clarification.

We are not using the VPP IKEv2 plugin. In our product, we use a different IKE 
stack but we program the SA keys and create IPSEC SA by calling 
ipsec_sa_add_and_lrock() API of vnet/ipsec.

What is your suggestion If we wanted to implement policy (SPD) based VPN in 
future?

 Can we fill the IPSEC SPD pool and use the ipsec-output-feature 
(ipsec-output-node) graph node which matches the packet with configured SPD 
(policy)?

On Wed, Aug 11, 2021 at 5:08 PM Neale Ranns 
mailto:ne...@graphiant.com>> wrote:

Hi Vijay,

VPP’s IKE implementation only supports route-based VPNs (where a tunnel 
interface is created) and not policy based (where the SPD is used).

/neale


From: vpp-dev@lists.fd.io<mailto:vpp-dev@lists.fd.io> 
mailto:vpp-dev@lists.fd.io>> on behalf of Vijay Kumar via 
lists.fd.io<http://lists.fd.io> 
mailto:gmail@lists.fd.io>>
Date: Wednesday, 11 August 2021 at 13:00
To: vpp-dev mailto:vpp-dev@lists.fd.io>>
Subject: [vpp-dev] Regarding Traffic selectors (IP and port range) usage in 
vnet/ipsec encrypt
Hi Neale,

I was looking at ipsec_sa_add_and_lock() function which is called by ikev2 to 
install IPSEC SA but I was NOT able to find anywhere the IKEv2 negotiated 
traffic selectors: IP addr range (start, stop) and port range (start, stop) 
being programmed to the vnet/ipsec. In such a case, how does the SPD processing 
happen in case esp4-encrypt-tun()?

Only in the case of ipsec4_output_node() function, I was seeing that the 
function  ipsec_output_policy_match() is invoked which will do TS matching with 
the packet addr and port fields. But in the case of esp4-encrypt-tun() I do not 
see this policy (spd) matching happen?



Regards.



-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#19953): https://lists.fd.io/g/vpp-dev/message/19953
Mute This Topic: https://lists.fd.io/mt/84813588/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] Regarding Traffic selectors (IP and port range) usage in vnet/ipsec encrypt

[Neale Ranns]

Hi Vijay,

VPP’s IKE implementation only supports route-based VPNs (where a tunnel 
interface is created) and not policy based (where the SPD is used).

/neale


From: vpp-dev@lists.fd.io  on behalf of Vijay Kumar via 
lists.fd.io 
Date: Wednesday, 11 August 2021 at 13:00
To: vpp-dev 
Subject: [vpp-dev] Regarding Traffic selectors (IP and port range) usage in 
vnet/ipsec encrypt
Hi Neale,

I was looking at ipsec_sa_add_and_lock() function which is called by ikev2 to 
install IPSEC SA but I was NOT able to find anywhere the IKEv2 negotiated 
traffic selectors: IP addr range (start, stop) and port range (start, stop) 
being programmed to the vnet/ipsec. In such a case, how does the SPD processing 
happen in case esp4-encrypt-tun()?

Only in the case of ipsec4_output_node() function, I was seeing that the 
function  ipsec_output_policy_match() is invoked which will do TS matching with 
the packet addr and port fields. But in the case of esp4-encrypt-tun() I do not 
see this policy (spd) matching happen?



Regards.



-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#19951): https://lists.fd.io/g/vpp-dev/message/19951
Mute This Topic: https://lists.fd.io/mt/84813588/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] Delete ACL rules #acl_plugin #acl #abf

[Neale Ranns]

Hi Ravi,

There’s no CLI to remove them. the CLI is for debug use only.
Feel free to contribute a patch to add a CLI if you need one.

/neale

From: vpp-dev@lists.fd.io  on behalf of RaviKiran Veldanda 
via lists.fd.io 
Date: Monday, 9 August 2021 at 22:42
To: vpp-dev@lists.fd.io 
Subject: [vpp-dev] Delete ACL rules #acl_plugin #acl #abf
Hi Team,
I am trying to find a way to delete the ACL rules. From the commands provided 
in acl-plugin, I coudn't find a way to delete the acls after addition.
The only way to delete ACL rules are just restart VPP, I don't want to do that.
How can we dynamically delete the rules? always the rules are getting piled up 
if we don't restart VPP.
Can you please help me to provide a cli to delete the ACL rules.
For example:
set acl-plugin acl permit src 172.25.169.0/24 --> this is one ACL rule,
if I want to delete which command should I use.
//Ravi

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#19943): https://lists.fd.io/g/vpp-dev/message/19943
Mute This Topic: https://lists.fd.io/mt/84778842/21656
Mute #acl_plugin:https://lists.fd.io/g/vpp-dev/mutehashtag/acl_plugin
Mute #acl:https://lists.fd.io/g/vpp-dev/mutehashtag/acl
Mute #abf:https://lists.fd.io/g/vpp-dev/mutehashtag/abf
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [vpp-dev] ping to loopback

[Neale Ranns]

The same way you ping the normal interface. Just make sure the forward and 
reverse routes are present.
Send a packet trace if it doesn’t work.

/neale


From: vpp-dev@lists.fd.io  on behalf of mark antony via 
lists.fd.io 
Date: Monday, 9 August 2021 at 22:24
To: vpp-dev@lists.fd.io 
Subject: [vpp-dev] ping to loopback
Hi friends,
how can I ping a loopback in vpp? I can ping the normal interface from cisco 
but for loopback no.

thanks

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#19939): https://lists.fd.io/g/vpp-dev/message/19939
Mute This Topic: https://lists.fd.io/mt/84778476/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] memif: failed: no source address for egress interface

[Neale Ranns]

From: Ed Warnicke 
Date: Monday, 9 August 2021 at 16:16
To: Neale Ranns 
Cc: otr...@employees.org , artem.glazyc...@xored.com 
, vpp-dev@lists.fd.io 
Subject: Re: [vpp-dev] memif: failed: no source address for egress interface


On Mon, Aug 9, 2021 at 7:40 AM Neale Ranns 
mailto:ne...@graphiant.com>> wrote:

i would argue the contrary, not subnetting (i.e. using /32) is not a valid 
approach to subnetting.

Again: GCP does this.  Calico for K8s (the most used K8s CNI plugin) does this. 
 Its  basically the direction Cloud is going in the generic.

Ah well, that’s different, if all the cool kids are doing it, then it must be 
the right way 😊
But as I said before, this IP-host-interworking, or L2/3, or [insert catchy 
phrase here], wasn’t a use case for VPP’s original IP functionality, so you may 
have more surprises down the track.


The BSD approach where you have to independent /32s on each side and a routing 
entry for the other side. Or a connected route /31 or larger. The act of 
configuring an address with a prefix is really a shortcut for configuring the 
address _and_ the connected prefix of course.

And it’s an expression that there are other hosts attached to this link so you 
don’t need to add /32 routes for any such hosts. IOW it’s a way of say stating 
that there is a sub-network of hosts attached to this router. And my routing 
protocol can advertise this.
If you add only a /32 you make none of those statements, and any routing 
protocol, if it still works over links without a subnet, does not include 
(without rediest static) reachability to those attached hosts. IOW it’s broken 
😊, or at a minimum not standard IP networking.
Of course I may be wrong, I often am, but this was my position when writing IP 
functionality for VPP, so there may be other surprises …

Sounds to me like the SAS algorithm needs a bit of work.

Now on that topic I heartily agree 😊 my SAS implementation is flawed in that it 
uses the glean adjacency to store the link’s receive address. P2p links don’t 
have a glean adj, hence SAS is broken on p2p links. It was an oversight on my 
part, I know I need to fix it.
My goal with the SAS implementation done that way was to be able to do basic 
SAS without needing the interface addresses programmed via ‘set int ip adrr …’, 
but rather completely through the RIB (i.e. ip route add …). This is more like 
what one might expect at the bottom of a router stack. To say that goal is 
imcomplete, is an understatement :(



The p2p fix, using the directly added IP link addresses is easy, it’s here:
  https://gerrit.fd.io/r/c/vpp/+/32801

(I'd like to use it for ICMP error sending too, where it also should handle the 
case of picking a source address from another interface than the outgoing 
interface).

And NBMA interfaces?

You can take the same approach as for p2p.

/neale

Ed


SAS++ 😊

/neale

Cheers,
Ole

> From: vpp-dev@lists.fd.io<mailto:vpp-dev@lists.fd.io> 
> mailto:vpp-dev@lists.fd.io>> on behalf of Artem 
> Glazychev via lists.fd.io<http://lists.fd.io> 
> mailto:artem.glazychev=xored@lists.fd.io>>
> Date: Wednesday, 4 August 2021 at 08:37
> To: vpp-dev@lists.fd.io<mailto:vpp-dev@lists.fd.io> 
> mailto:vpp-dev@lists.fd.io>>
> Subject: [vpp-dev] memif: failed: no source address for egress interface
>
> Hello,
> Found a problem with some types of interfaces.
>
> For example, memif. When I'm creating memif interfaces and run ping I see:
>
> DBGvpp# ping 10.10.2.1
> Failed: no source address for egress interface
> ...
>
> But it is worth mentioning that I am setting /32 mask for IP address
>
> Managed to fix IP mode with these patches: 
> https://gerrit.fd.io/r/c/vpp/+/32801, https://gerrit.fd.io/r/c/vpp/+/33303
>
> But Ethernet mode still doesn't work.
>
> ==
>
> There was already a similar topic: 
> https://lists.fd.io/g/vpp-dev/topic/84038840
>
> Created a jira issue with details: https://jira.fd.io/browse/VPP-1992
>
> Does anyone have any thoughts on this? Thank you.
>
>
>
>
>
>
>
>
>
>
>
>





-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#19938): https://lists.fd.io/g/vpp-dev/message/19938
Mute This Topic: https://lists.fd.io/mt/84656776/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] memif: failed: no source address for egress interface

[Neale Ranns]

On 09/08/2021 10:15, "otr...@employees.org"  wrote:
> I think that is telling you not to use /32 address on interface for which you 
> expect there to be connected peers.
> From an IP networking perspective, if you want two peers to be connected on 
> an interface, they need to be within the same subnet, so use a /31.

For p2p links there are actually two valid approaches to IP subnetting.

i would argue the contrary, not subnetting (i.e. using /32) is not a valid 
approach to subnetting.

The BSD approach where you have to independent /32s on each side and a routing 
entry for the other side. Or a connected route /31 or larger. The act of 
configuring an address with a prefix is really a shortcut for configuring the 
address _and_ the connected prefix of course.

And it’s an expression that there are other hosts attached to this link so you 
don’t need to add /32 routes for any such hosts. IOW it’s a way of say stating 
that there is a sub-network of hosts attached to this router. And my routing 
protocol can advertise this.
If you add only a /32 you make none of those statements, and any routing 
protocol, if it still works over links without a subnet, does not include 
(without rediest static) reachability to those attached hosts. IOW it’s broken 
😊, or at a minimum not standard IP networking.
Of course I may be wrong, I often am, but this was my position when writing IP 
functionality for VPP, so there may be other surprises …

Sounds to me like the SAS algorithm needs a bit of work.

Now on that topic I heartily agree 😊 my SAS implementation is flawed in that it 
uses the glean adjacency to store the link’s receive address. P2p links don’t 
have a glean adj, hence SAS is broken on p2p links. It was an oversight on my 
part, I know I need to fix it.
My goal with the SAS implementation done that way was to be able to do basic 
SAS without needing the interface addresses programmed via ‘set int ip adrr …’, 
but rather completely through the RIB (i.e. ip route add …). This is more like 
what one might expect at the bottom of a router stack. To say that goal is 
imcomplete, is an understatement :(
The p2p fix, using the directly added IP link addresses is easy, it’s here:
  https://gerrit.fd.io/r/c/vpp/+/32801

(I'd like to use it for ICMP error sending too, where it also should handle the 
case of picking a source address from another interface than the outgoing 
interface).

SAS++ 😊

/neale

Cheers,
Ole

> From: vpp-dev@lists.fd.io 
> mailto:vpp-dev@lists.fd.io>> on behalf of Artem 
> Glazychev via lists.fd.io 
> mailto:artem.glazychev=xored@lists.fd.io>>
> Date: Wednesday, 4 August 2021 at 08:37
> To: vpp-dev@lists.fd.io 
> mailto:vpp-dev@lists.fd.io>>
> Subject: [vpp-dev] memif: failed: no source address for egress interface
>
> Hello,
> Found a problem with some types of interfaces.
>
> For example, memif. When I'm creating memif interfaces and run ping I see:
>
> DBGvpp# ping 10.10.2.1
> Failed: no source address for egress interface
> ...
>
> But it is worth mentioning that I am setting /32 mask for IP address
>
> Managed to fix IP mode with these patches: 
> https://gerrit.fd.io/r/c/vpp/+/32801, https://gerrit.fd.io/r/c/vpp/+/33303
>
> But Ethernet mode still doesn't work.
>
> ==
>
> There was already a similar topic: 
> https://lists.fd.io/g/vpp-dev/topic/84038840
>
> Created a jira issue with details: https://jira.fd.io/browse/VPP-1992
>
> Does anyone have any thoughts on this? Thank you.
>
>
>
>
>
>
>
>
>
>
> 
>



-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#19930): https://lists.fd.io/g/vpp-dev/message/19930
Mute This Topic: https://lists.fd.io/mt/84656776/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] memif: failed: no source address for egress interface

[Neale Ranns]

Hi Artem,

I think that is telling you not to use /32 address on interface for which you 
expect there to be connected peers.
>From an IP networking perspective, if you want two peers to be connected on an 
>interface, they need to be within the same subnet, so use a /31.

/neale


From: vpp-dev@lists.fd.io  on behalf of Artem Glazychev 
via lists.fd.io 
Date: Wednesday, 4 August 2021 at 08:37
To: vpp-dev@lists.fd.io 
Subject: [vpp-dev] memif: failed: no source address for egress interface

Hello,
Found a problem with some types of interfaces.

For example, memif. When I'm creating memif interfaces and run ping I see:

DBGvpp# ping 10.10.2.1
Failed: no source address for egress interface
...

But it is worth mentioning that I am setting /32 mask for IP address

Managed to fix IP mode with these patches: 
https://gerrit.fd.io/r/c/vpp/+/32801, https://gerrit.fd.io/r/c/vpp/+/33303

But Ethernet mode still doesn't work.

==

There was already a similar topic: https://lists.fd.io/g/vpp-dev/topic/84038840

Created a jira issue with details: https://jira.fd.io/browse/VPP-1992

Does anyone have any thoughts on this? Thank you.









-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#19928): https://lists.fd.io/g/vpp-dev/message/19928
Mute This Topic: https://lists.fd.io/mt/84656776/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] MAC Learning in vpp

[Neale Ranns]

Hi,

But do you want port-security to work for an l2 interface in a BD, or for an L3 
interface. L2 and L3 interfaces manage the ‘learned’ MAC address very 
differently, therefore it would be a different mechanism to 
monitor/filter/munge/etc.

/neale


From: Mohsen Meamarian 
Date: Thursday, 5 August 2021 at 11:13
To: Neale Ranns 
Cc: vpp-dev@lists.fd.io 
Subject: Re: [vpp-dev] MAC Learning in vpp
Hi ,
we want to write a port security script. In the first router work normally , 
all interfaces have ip addresses . then the user wants to set port security on 
an interface. and here we must enable learning mac features on that interface. 
For this requirement , we searched and found that when an interface is added to 
a bridge , a history of connected device mac addresses is formed that can be 
seen by running "sh l2fib all" command. we can set a limit on the learned mac 
address on that table too . The interface , GigabitEthernet2/6/0 , has its 
previous ip address . cisco can ping it well . but when we added 
GigabitEthernet2/6/0 to a bridge-domain it kept his ip address but Cisco cannot 
ping that.we don't want to create a multi-interface bridge-domain and use 
l2-forwarding.it<http://l2-forwarding.it>'s just a tool for make a memory of 
connected device's mac address .

On Thu, Aug 5, 2021 at 12:46 PM Neale Ranns 
mailto:ne...@graphiant.com>> wrote:

HI Mohsen,

From: Mohsen Meamarian 
mailto:meamarian.moh...@gmail.com>>
Date: Thursday, 5 August 2021 at 08:24
To: Neale Ranns mailto:ne...@graphiant.com>>
Cc: vpp-dev@lists.fd.io<mailto:vpp-dev@lists.fd.io> 
mailto:vpp-dev@lists.fd.io>>
Subject: Re: [vpp-dev] MAC Learning in vpp
Hi Neale,
Thanks , I’m looking for another way because I have a problem with the bridge.

Another way to do what? Do you want to do l2 forwarding or not?

I have made a bridge with 2 interfaces, one as BVI and from loopback type and 
the other is GigabitEthernet2/0/6. I send a ping packet to the 
GigabitEthernet2/6/0 interface of my system via a Cisco router, although the 
destination MAC address that vpp detects in the trace is its own MAC address, 
but it doesn't pick up the packet.

The trace file you sent shows VPP’s address as the source MAC of the received 
packet. The destination MAC is not in the l2fib, hence the drop.
But that aside, you can’t ping an interface that does not have an IP address. 
It’s the BVI that has the IP address – it is the L3 interface here.

/neale

I attached my trace and bridge configuration. Also I got another error when 
uu-flood and flood of bridge-domain is enabled: l2 replication drop.I have 
tried both modes with BVI interface and without BVI interface.

On Wed, Aug 4, 2021 at 4:29 PM Neale Ranns 
mailto:ne...@graphiant.com>> wrote:
Hi Mohsen,

Perhaps I misunderstood your intentions. MAC learning I was talking about is 
what a switch/bridge domain does to populate its forwarding tables to perform 
l2 forwarding. My old and limited experience with port-security was as a 
feature on l2 interface in a BD.
If what you wanted was ARP for L3 interfaces, then we’re talking about IP 
neighbours. The size of the ip-neighbour DB (which is shared between ARP and ND 
entries) has only a global not a per-interface limit.
DBGvpp# set ip neighbor-config ?
  set ip neighbor-config   set ip neighbor-config ip4|ip6 
[limit ] [age ] [recycle|norecycle]
there are no other means to control what IP neighbours are or aren’t learned.

/neale


From: Mohsen Meamarian 
mailto:meamarian.moh...@gmail.com>>
Date: Wednesday, 4 August 2021 at 07:26
To: Neale Ranns mailto:ne...@graphiant.com>>
Cc: vpp-dev@lists.fd.io<mailto:vpp-dev@lists.fd.io> 
mailto:vpp-dev@lists.fd.io>>
Subject: Re: [vpp-dev] MAC Learning in vpp
Hi Neal,
Thanks, Is there a way to view and limit learned MAC addresses for an interface 
without adding an interface to a bridge-domain?

On Tue, Aug 3, 2021 at 12:15 PM Neale Ranns 
mailto:ne...@graphiant.com>> wrote:
HI Mohsen,

Learning in a BD is enabled by default – your trace shows learning on. You can 
turn in on or off through configuration on the BD or on the input interface.
DBGvpp# set bridge-domain ?
  set bridge-domain learn  set bridge-domain learn 
 [disable]
  set bridge-domain learn-limitset bridge-domain learn-limit 
 

or

DBGvpp# set interface l2 ?
  set interface l2 learn   set interface l2 learn  
[disable]

Ping and ARP work with learning on.

Note also in the commands above, there is a mechanism to limit the number of 
MACs that can be learnt in each BD.

/neale


From: Mohsen Meamarian 
mailto:meamarian.moh...@gmail.com>>
Date: Tuesday, 3 August 2021 at 06:37
To: Neale Ranns mailto:ne...@graphiant.com>>
Cc: vpp-dev@lists.fd.io<mailto:vpp-dev@lists.fd.io> 
mailto:vpp-dev@lists.fd.io>>
Subject: Re: [vpp-dev] MAC Learning in vpp
Thanks neale,
What is the

Re: [vpp-dev] MAC Learning in vpp

[Neale Ranns]

HI Mohsen,

From: Mohsen Meamarian 
Date: Thursday, 5 August 2021 at 08:24
To: Neale Ranns 
Cc: vpp-dev@lists.fd.io 
Subject: Re: [vpp-dev] MAC Learning in vpp
Hi Neale,
Thanks , I’m looking for another way because I have a problem with the bridge.

Another way to do what? Do you want to do l2 forwarding or not?

I have made a bridge with 2 interfaces, one as BVI and from loopback type and 
the other is GigabitEthernet2/0/6. I send a ping packet to the 
GigabitEthernet2/6/0 interface of my system via a Cisco router, although the 
destination MAC address that vpp detects in the trace is its own MAC address, 
but it doesn't pick up the packet.

The trace file you sent shows VPP’s address as the source MAC of the received 
packet. The destination MAC is not in the l2fib, hence the drop.
But that aside, you can’t ping an interface that does not have an IP address. 
It’s the BVI that has the IP address – it is the L3 interface here.

/neale

I attached my trace and bridge configuration. Also I got another error when 
uu-flood and flood of bridge-domain is enabled: l2 replication drop.I have 
tried both modes with BVI interface and without BVI interface.

On Wed, Aug 4, 2021 at 4:29 PM Neale Ranns 
mailto:ne...@graphiant.com>> wrote:
Hi Mohsen,

Perhaps I misunderstood your intentions. MAC learning I was talking about is 
what a switch/bridge domain does to populate its forwarding tables to perform 
l2 forwarding. My old and limited experience with port-security was as a 
feature on l2 interface in a BD.
If what you wanted was ARP for L3 interfaces, then we’re talking about IP 
neighbours. The size of the ip-neighbour DB (which is shared between ARP and ND 
entries) has only a global not a per-interface limit.
DBGvpp# set ip neighbor-config ?
  set ip neighbor-config   set ip neighbor-config ip4|ip6 
[limit ] [age ] [recycle|norecycle]
there are no other means to control what IP neighbours are or aren’t learned.

/neale


From: Mohsen Meamarian 
mailto:meamarian.moh...@gmail.com>>
Date: Wednesday, 4 August 2021 at 07:26
To: Neale Ranns mailto:ne...@graphiant.com>>
Cc: vpp-dev@lists.fd.io<mailto:vpp-dev@lists.fd.io> 
mailto:vpp-dev@lists.fd.io>>
Subject: Re: [vpp-dev] MAC Learning in vpp
Hi Neal,
Thanks, Is there a way to view and limit learned MAC addresses for an interface 
without adding an interface to a bridge-domain?

On Tue, Aug 3, 2021 at 12:15 PM Neale Ranns 
mailto:ne...@graphiant.com>> wrote:
HI Mohsen,

Learning in a BD is enabled by default – your trace shows learning on. You can 
turn in on or off through configuration on the BD or on the input interface.
DBGvpp# set bridge-domain ?
  set bridge-domain learn  set bridge-domain learn 
 [disable]
  set bridge-domain learn-limitset bridge-domain learn-limit 
 

or

DBGvpp# set interface l2 ?
  set interface l2 learn   set interface l2 learn  
[disable]

Ping and ARP work with learning on.

Note also in the commands above, there is a mechanism to limit the number of 
MACs that can be learnt in each BD.

/neale


From: Mohsen Meamarian 
mailto:meamarian.moh...@gmail.com>>
Date: Tuesday, 3 August 2021 at 06:37
To: Neale Ranns mailto:ne...@graphiant.com>>
Cc: vpp-dev@lists.fd.io<mailto:vpp-dev@lists.fd.io> 
mailto:vpp-dev@lists.fd.io>>
Subject: Re: [vpp-dev] MAC Learning in vpp
Thanks neale,
What is the easiest way to enable learning on an interface while other 
functionality , including passing the ping and arp packets , work normally?

I want l2_learn_process run for that interface so that I can write a function 
to do something like put a limiting on maximum connected devices with it's help.


On Mon, Aug 2, 2021, 23:38 Neale Ranns 
mailto:ne...@graphiant.com>> wrote:

HI Moshen,

From: vpp-dev@lists.fd.io<mailto:vpp-dev@lists.fd.io> 
mailto:vpp-dev@lists.fd.io>> on behalf of Mohsen Meamarian 
via lists.fd.io<http://lists.fd.io> 
mailto:gmail@lists.fd.io>>
Date: Monday, 2 August 2021 at 18:45
To: vpp-dev@lists.fd.io<mailto:vpp-dev@lists.fd.io> 
mailto:vpp-dev@lists.fd.io>>
Subject: [vpp-dev] MAC Learning in vpp
Hi friends,
I want to implement port security in vpp. I assume that the l2learn_process 
function in l2_learn.c runs periodically when vpp is active and When a device 
is connected to my system , this function helps to learn it's mac. Is this 
assumption true ?

No. l2_learn runs for all packets that are received on a link on which learning 
is enabled. You can see it in the trace you provided. It is learning in this 
VLIB node that will populated the l2fib.

because when I run the sh l2fib command , it returns nothing. but when I set an 
interface as a bridge , the sh l2fib command returns something. my commands :

create bridge-domain 2 arp-term 1
create loopback interface
set int l2 bridge loop0 2 bvi
set interface state loop0 up
set interface l2 bridge GigabitE

Re: [vpp-dev] MAC Learning in vpp

[Neale Ranns]

Hi Mohsen,

Perhaps I misunderstood your intentions. MAC learning I was talking about is 
what a switch/bridge domain does to populate its forwarding tables to perform 
l2 forwarding. My old and limited experience with port-security was as a 
feature on l2 interface in a BD.
If what you wanted was ARP for L3 interfaces, then we’re talking about IP 
neighbours. The size of the ip-neighbour DB (which is shared between ARP and ND 
entries) has only a global not a per-interface limit.
DBGvpp# set ip neighbor-config ?
  set ip neighbor-config   set ip neighbor-config ip4|ip6 
[limit ] [age ] [recycle|norecycle]
there are no other means to control what IP neighbours are or aren’t learned.

/neale


From: Mohsen Meamarian 
Date: Wednesday, 4 August 2021 at 07:26
To: Neale Ranns 
Cc: vpp-dev@lists.fd.io 
Subject: Re: [vpp-dev] MAC Learning in vpp
Hi Neal,
Thanks, Is there a way to view and limit learned MAC addresses for an interface 
without adding an interface to a bridge-domain?

On Tue, Aug 3, 2021 at 12:15 PM Neale Ranns 
mailto:ne...@graphiant.com>> wrote:
HI Mohsen,

Learning in a BD is enabled by default – your trace shows learning on. You can 
turn in on or off through configuration on the BD or on the input interface.
DBGvpp# set bridge-domain ?
  set bridge-domain learn  set bridge-domain learn 
 [disable]
  set bridge-domain learn-limitset bridge-domain learn-limit 
 

or

DBGvpp# set interface l2 ?
  set interface l2 learn   set interface l2 learn  
[disable]

Ping and ARP work with learning on.

Note also in the commands above, there is a mechanism to limit the number of 
MACs that can be learnt in each BD.

/neale


From: Mohsen Meamarian 
mailto:meamarian.moh...@gmail.com>>
Date: Tuesday, 3 August 2021 at 06:37
To: Neale Ranns mailto:ne...@graphiant.com>>
Cc: vpp-dev@lists.fd.io<mailto:vpp-dev@lists.fd.io> 
mailto:vpp-dev@lists.fd.io>>
Subject: Re: [vpp-dev] MAC Learning in vpp
Thanks neale,
What is the easiest way to enable learning on an interface while other 
functionality , including passing the ping and arp packets , work normally?

I want l2_learn_process run for that interface so that I can write a function 
to do something like put a limiting on maximum connected devices with it's help.


On Mon, Aug 2, 2021, 23:38 Neale Ranns 
mailto:ne...@graphiant.com>> wrote:

HI Moshen,

From: vpp-dev@lists.fd.io<mailto:vpp-dev@lists.fd.io> 
mailto:vpp-dev@lists.fd.io>> on behalf of Mohsen Meamarian 
via lists.fd.io<http://lists.fd.io> 
mailto:gmail@lists.fd.io>>
Date: Monday, 2 August 2021 at 18:45
To: vpp-dev@lists.fd.io<mailto:vpp-dev@lists.fd.io> 
mailto:vpp-dev@lists.fd.io>>
Subject: [vpp-dev] MAC Learning in vpp
Hi friends,
I want to implement port security in vpp. I assume that the l2learn_process 
function in l2_learn.c runs periodically when vpp is active and When a device 
is connected to my system , this function helps to learn it's mac. Is this 
assumption true ?

No. l2_learn runs for all packets that are received on a link on which learning 
is enabled. You can see it in the trace you provided. It is learning in this 
VLIB node that will populated the l2fib.

because when I run the sh l2fib command , it returns nothing. but when I set an 
interface as a bridge , the sh l2fib command returns something. my commands :

create bridge-domain 2 arp-term 1
create loopback interface
set int l2 bridge loop0 2 bvi
set interface state loop0 up
set interface l2 bridge GigabitEthernet0/8/0 2

show bridge-domain 2 detail
show l2fib all

but i have a problem here. vpp drop ping packet.Where can the problem come from?

I attached my trace command result to this mail.I get " l2-flood: BVI L3 mac 
mismatch " error.

That shows an ARP packet destined to a unicast MAC. That packet was flooded, 
suggesting an l2fib miss and unknown-unicast flooding is enabled. The dst MAC 
of the packet did not match the MAC of the BVI (the only other interface in the 
BD) so it was dropped.

/neale


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#19912): https://lists.fd.io/g/vpp-dev/message/19912
Mute This Topic: https://lists.fd.io/mt/84615988/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] FIB entry being created on peer VPP node for the localsid

[Neale Ranns]

Hi,

I don’t know how SRv6 works on either platform.
My point is that VPP added the route because there is a neighbour for that 
address, VPP does this always for all neighbours, this happens irrespective of 
SRv6.

Is the presence of the route causing you problems?

/neale


From: vpp-dev@lists.fd.io  on behalf of Chinmaya Aggarwal 
via lists.fd.io 
Date: Tuesday, 3 August 2021 at 17:22
To: vpp-dev@lists.fd.io 
Subject: Re: [vpp-dev] FIB entry being created on peer VPP node for the localsid
Hi Neale,

Thank you.

As mentioned in the post, we see a different behaviour on linux srv6 where it 
adds localsid as neighbor only and does not modify route table. So, why the 
handing for this is different in VPP?

Thanks and Regards,
Chinmaya Agarwal.

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#19907): https://lists.fd.io/g/vpp-dev/message/19907
Mute This Topic: https://lists.fd.io/mt/84637242/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] FIB entry being created on peer VPP node for the localsid

[Neale Ranns]

Hi,

VPP adds FIB entries for all IP neighbours. These are used to forward traffic 
to those neighbours.

if you do:
 show ip6 fib 2001:7a0:10::111/128
you’ll see more detailed output that describes the sources’of the FIB entry, A 
source is the entity that added the route. The adjacency source is the entity 
that adds routes for neighbours.

/neale


From: vpp-dev@lists.fd.io  on behalf of Chinmaya Aggarwal 
via lists.fd.io 
Date: Tuesday, 3 August 2021 at 14:17
To: vpp-dev@lists.fd.io 
Subject: [vpp-dev] FIB entry being created on peer VPP node for the localsid
Hi,

We have two VMs i.e. VM 1 and VM 2 running VPP. We are configuring localsid and 
nd proxy corresponding to that localsid on VM1.

sr localsid address 2001:7a0:10::111 behavior end psp
set ip6 nd proxy GigabitEthernet0/8/0 2001:7a0:10::111

When packet on VM 2 tries tires to reach VM 1's localsid, we see that a 
neighbor entry and a fib entry corresponding to that localsid is generated on 
VM 2

vpp# show ip6 fib
2001:7a0:10::111/128
  unicast-ip6-chain
  [@0]: dpo-load-balance: [proto:ip6 index:15 buckets:1 uRPF:17 to:[4:464]]
[0] [@5]: ipv6 via 2001:7a0:10::111 GigabitEthernet0/8/0: mtu:9000 next:3 
525400ed7f2052540062079586dd
fe80::/10

vpp# show ip6 neighbors
Time   IPFlags  Ethernet
  Interface
242.55602001:7a0:10::111   D52:54:00:ed:7f:20 
GigabitEthernet0/8/0

Whereas, when we tried the same scenario using linux SRv6 we see that only 
neighbor entry is created on VM 2 for the localsid but route table has nothing 
corresponding to it.

root@ubuntu:~# ip -6 route show
::1 dev lo proto kernel metric 256 pref medium
2001:7a0:10::/64 dev ens8 proto kernel metric 256 pref medium
fe80::/64 dev ens8 proto kernel metric 256 pref medium
fe80::/64 dev ens3 proto kernel metric 256 pref medium
root@ubuntu:~# ip -6 neigh
2001:7a0:10::111 dev ens8 lladdr 52:54:00:5a:9f:9c REACHABLE
fe80::5054:ff:fe6f:d8a8 dev ens3 lladdr 52:54:00:6f:d8:a8 STALE
fe80::5054:ff:fe5a:9f9c dev ens8 lladdr 52:54:00:5a:9f:9c router REACHABLE
root@ubuntu:~#

Can anyone please guide us why VPP adds a fib entry for the localsid?


Thanks and Regards,
Chinmaya Agarwal.

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#19902): https://lists.fd.io/g/vpp-dev/message/19902
Mute This Topic: https://lists.fd.io/mt/84637242/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] VLAN+IP based forwarding #acl, #abf #vlan #memif #forwarding #vpp

[Neale Ranns]

Hi Ravi.

as I said in another thread, VLANs are represented by interfaces in VPP, so to 
achieve VALN differentiated forwarding you need to bind different 
tables/polices/etc with the different routes/rules/etc to the different VLAN 
interfaces.

For example, create different ip tables:
  Ip table add X
Add the routes to the different memifs in the different tables.
  Ip route table X 172.172.0.0/24 via 192.168.1.3 memifX/0
And bind the input VLAN interfaces to the different tables
  set int ip table input.30X X


/neale


From: vpp-dev@lists.fd.io  on behalf of RaviKiran Veldanda 
via lists.fd.io 
Date: Monday, 2 August 2021 at 22:53
To: vpp-dev@lists.fd.io 
Subject: [vpp-dev] VLAN+IP based forwarding #acl, #abf #vlan #memif #forwarding 
#vpp
Hi Experts,
We have our application reading packets through memif and does consume them.
We are adding rules in the VPP to reach particualr memif based on dst IP.

"ip route add 172.172.0.0/24 via 192.168.1.3 memif1/0"

However we have a requirement, where the Destination  NETWORK can overlap with 
other VLAN.

So we need forward rules based on the "VLAN + MEMIF"
For example
If VLAN is 301 and DST IP is 172.173.0.0/24 it should reach to memif1/0
If VLAN is 302 and DST IP is 172.173.0.0/24  it should reach to memif2/0
If VLAN is 302 and DST IP is 172.174.0.0/24 it should reach to memif1/0
If VLAN is 301 and DST IP is 172.174.0.0/24 it should reach to memif2/0

We can not use L2 xconnect, which directly  relays L2 packets to corresponding 
memif1/0,
We need DST and VLAN because our application handles multiple clients with same 
overlapping subnets with VLAN+IP based routing.

So we need VLAN+DST IP based routing, any suggestion is a great help.

//Ravi


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#19900): https://lists.fd.io/g/vpp-dev/message/19900
Mute This Topic: https://lists.fd.io/mt/84622474/21656
Mute #vpp:https://lists.fd.io/g/vpp-dev/mutehashtag/vpp
Mute #memif:https://lists.fd.io/g/vpp-dev/mutehashtag/memif
Mute #abf:https://lists.fd.io/g/vpp-dev/mutehashtag/abf
Mute #vlan:https://lists.fd.io/g/vpp-dev/mutehashtag/vlan
Mute #forwarding:https://lists.fd.io/g/vpp-dev/mutehashtag/forwarding
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [vpp-dev] MAC Learning in vpp

[Neale Ranns]

HI Mohsen,

Learning in a BD is enabled by default – your trace shows learning on. You can 
turn in on or off through configuration on the BD or on the input interface.
DBGvpp# set bridge-domain ?
  set bridge-domain learn  set bridge-domain learn 
 [disable]
  set bridge-domain learn-limitset bridge-domain learn-limit 
 

or

DBGvpp# set interface l2 ?
  set interface l2 learn   set interface l2 learn  
[disable]

Ping and ARP work with learning on.

Note also in the commands above, there is a mechanism to limit the number of 
MACs that can be learnt in each BD.

/neale


From: Mohsen Meamarian 
Date: Tuesday, 3 August 2021 at 06:37
To: Neale Ranns 
Cc: vpp-dev@lists.fd.io 
Subject: Re: [vpp-dev] MAC Learning in vpp
Thanks neale,
What is the easiest way to enable learning on an interface while other 
functionality , including passing the ping and arp packets , work normally?

I want l2_learn_process run for that interface so that I can write a function 
to do something like put a limiting on maximum connected devices with it's help.


On Mon, Aug 2, 2021, 23:38 Neale Ranns 
mailto:ne...@graphiant.com>> wrote:

HI Moshen,

From: vpp-dev@lists.fd.io<mailto:vpp-dev@lists.fd.io> 
mailto:vpp-dev@lists.fd.io>> on behalf of Mohsen Meamarian 
via lists.fd.io<http://lists.fd.io> 
mailto:gmail@lists.fd.io>>
Date: Monday, 2 August 2021 at 18:45
To: vpp-dev@lists.fd.io<mailto:vpp-dev@lists.fd.io> 
mailto:vpp-dev@lists.fd.io>>
Subject: [vpp-dev] MAC Learning in vpp
Hi friends,
I want to implement port security in vpp. I assume that the l2learn_process 
function in l2_learn.c runs periodically when vpp is active and When a device 
is connected to my system , this function helps to learn it's mac. Is this 
assumption true ?

No. l2_learn runs for all packets that are received on a link on which learning 
is enabled. You can see it in the trace you provided. It is learning in this 
VLIB node that will populated the l2fib.

because when I run the sh l2fib command , it returns nothing. but when I set an 
interface as a bridge , the sh l2fib command returns something. my commands :

create bridge-domain 2 arp-term 1
create loopback interface
set int l2 bridge loop0 2 bvi
set interface state loop0 up
set interface l2 bridge GigabitEthernet0/8/0 2

show bridge-domain 2 detail
show l2fib all

but i have a problem here. vpp drop ping packet.Where can the problem come from?

I attached my trace command result to this mail.I get " l2-flood: BVI L3 mac 
mismatch " error.

That shows an ARP packet destined to a unicast MAC. That packet was flooded, 
suggesting an l2fib miss and unknown-unicast flooding is enabled. The dst MAC 
of the packet did not match the MAC of the BVI (the only other interface in the 
BD) so it was dropped.

/neale


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#19899): https://lists.fd.io/g/vpp-dev/message/19899
Mute This Topic: https://lists.fd.io/mt/84615988/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] MAC Learning in vpp

[Neale Ranns]

HI Moshen,

From: vpp-dev@lists.fd.io  on behalf of Mohsen Meamarian 
via lists.fd.io 
Date: Monday, 2 August 2021 at 18:45
To: vpp-dev@lists.fd.io 
Subject: [vpp-dev] MAC Learning in vpp
Hi friends,
I want to implement port security in vpp. I assume that the l2learn_process 
function in l2_learn.c runs periodically when vpp is active and When a device 
is connected to my system , this function helps to learn it's mac. Is this 
assumption true ?

No. l2_learn runs for all packets that are received on a link on which learning 
is enabled. You can see it in the trace you provided. It is learning in this 
VLIB node that will populated the l2fib.

because when I run the sh l2fib command , it returns nothing. but when I set an 
interface as a bridge , the sh l2fib command returns something. my commands :

create bridge-domain 2 arp-term 1
create loopback interface
set int l2 bridge loop0 2 bvi
set interface state loop0 up
set interface l2 bridge GigabitEthernet0/8/0 2

show bridge-domain 2 detail
show l2fib all

but i have a problem here. vpp drop ping packet.Where can the problem come from?

I attached my trace command result to this mail.I get " l2-flood: BVI L3 mac 
mismatch " error.

That shows an ARP packet destined to a unicast MAC. That packet was flooded, 
suggesting an l2fib miss and unknown-unicast flooding is enabled. The dst MAC 
of the packet did not match the MAC of the BVI (the only other interface in the 
BD) so it was dropped.

/neale


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#19893): https://lists.fd.io/g/vpp-dev/message/19893
Mute This Topic: https://lists.fd.io/mt/84615988/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] Regarding IPsec errors "Integrity failure" and "Unsupported payload"

[Neale Ranns]

From: Vijay Kumar 
Date: Monday, 2 August 2021 at 11:33
To: Neale Ranns 
Cc: vpp-dev 
Subject: Re: [vpp-dev] Regarding IPsec errors "Integrity failure" and 
"Unsupported payload"
Hi Neale,

My IPSEC rekey is set to high (2 hr). So the issue is not during rekey.

I don’t understand why the former statement leads to your latter conclusion. Is 
it because you see this failure happen soon after the initial session is 
established and before the first rekey?

According to code, during decrypt the esp_process_ops() is called. In this 
function, I had added the below print. Whenever I get integrity check failure, 
I see that print in my application logs.

Once I land into this issue, it always fails. To recover I have to reset ike 
and ipsecsa and establish again.

When can I see the integrity check failure in decrypt??

Do you mean why would an integrity check fail? Lot’s of reasons. But given that 
you see all packets fail, and it is recovered by reset/rekey, I would suggest 
the sender has changed its keys.

/neaele


Code snippet

static_always_inline void
esp_process_ops (vlib_main_t * vm, vlib_node_runtime_t * node,
   vnet_crypto_op_t * ops, vlib_buffer_t * b[], u16 * nexts,
   int e)
{
  vnet_crypto_op_t *op = ops;
  u32 n_fail, n_ops = vec_len (ops);

  if (n_ops == 0)
return;

  n_fail = n_ops - vnet_crypto_process_ops (vm, op, n_ops);

  while (n_fail)
{
  ASSERT (op - ops < n_ops);
  if (op->status != VNET_CRYPTO_OP_STATUS_COMPLETED)
 {
   u32 err, bi = op->user_data;
   if (op->status == VNET_CRYPTO_OP_STATUS_FAIL_BAD_HMAC)
   {
 err = e;
 printf("In esp_process_ops op status = 
VNET_CRYPTO_OP_STATUS_FAIL_BAD_HMAC\n");
 }
   else
   {
 err = ESP_DECRYPT_ERROR_CRYPTO_ENGINE_ERROR;
 printf("In esp_process_ops err = ESP_DECRYPT_ERROR_CRYPTO_ENGINE_ERROR\n");
   }
   b[bi]->error = node->errors[err];
   nexts[bi] = ESP_DECRYPT_NEXT_DROP;
   n_fail--;
 }
  op++;
}
}

On Mon, Aug 2, 2021 at 1:06 PM Neale Ranns 
mailto:ne...@graphiant.com>> wrote:

Hi Vijay,

No I don’t see random failures. Do they occur during a rekeying event?

/neale

From: vpp-dev@lists.fd.io<mailto:vpp-dev@lists.fd.io> 
mailto:vpp-dev@lists.fd.io>> on behalf of Vijay Kumar via 
lists.fd.io<http://lists.fd.io> 
mailto:gmail@lists.fd.io>>
Date: Monday, 2 August 2021 at 08:43
To: vpp-dev mailto:vpp-dev@lists.fd.io>>
Subject: Re: [vpp-dev] Regarding IPsec errors "Integrity failure" and 
"Unsupported payload"
Hi Neale,

Do you have any suggestions for this problem.
Did you face this random issue anytime?




On Sat, Jul 31, 2021 at 7:05 PM Vijay Kumar via lists.fd.io<http://lists.fd.io> 
mailto:gmail@lists.fd.io>> wrote:
Hi Neale,

I am testing data traffic b/w Strongswan and VPP but sometimes data traffic is 
dropped in esp4-decrypt-tun graph node. Sometimes it is dropped with "Integrity 
failure" while sometimes it is "Unsupported payload"

But if I delete the tunnel and re-establish IPSec SA, then it works fine.

I have ensured the configuration w.r.t PSK, Proposals and TS is fine. Also, I 
confirmed that the adjacencies(routes) for the Strongswan are fine on the VPP 
side.

Version I am using is pasted below.

Could I be missing something? These are random issues.


vpp# show version
vpp v20.05.1-2~g44ff05906-dirty built by an-vijay_kumar on 56d1c81f572a at 
2021-07-30T15:54:16



Regards.


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#19890): https://lists.fd.io/g/vpp-dev/message/19890
Mute This Topic: https://lists.fd.io/mt/84569833/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] Regarding IPsec errors "Integrity failure" and "Unsupported payload"

[Neale Ranns]

Hi Vijay,

No I don’t see random failures. Do they occur during a rekeying event?

/neale

From: vpp-dev@lists.fd.io  on behalf of Vijay Kumar via 
lists.fd.io 
Date: Monday, 2 August 2021 at 08:43
To: vpp-dev 
Subject: Re: [vpp-dev] Regarding IPsec errors "Integrity failure" and 
"Unsupported payload"
Hi Neale,

Do you have any suggestions for this problem.
Did you face this random issue anytime?




On Sat, Jul 31, 2021 at 7:05 PM Vijay Kumar via lists.fd.io 
mailto:gmail@lists.fd.io>> wrote:
Hi Neale,

I am testing data traffic b/w Strongswan and VPP but sometimes data traffic is 
dropped in esp4-decrypt-tun graph node. Sometimes it is dropped with "Integrity 
failure" while sometimes it is "Unsupported payload"

But if I delete the tunnel and re-establish IPSec SA, then it works fine.

I have ensured the configuration w.r.t PSK, Proposals and TS is fine. Also, I 
confirmed that the adjacencies(routes) for the Strongswan are fine on the VPP 
side.

Version I am using is pasted below.

Could I be missing something? These are random issues.


vpp# show version
vpp v20.05.1-2~g44ff05906-dirty built by an-vijay_kumar on 56d1c81f572a at 
2021-07-30T15:54:16



Regards.



-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#19888): https://lists.fd.io/g/vpp-dev/message/19888
Mute This Topic: https://lists.fd.io/mt/84569833/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] #ipsec #vnet #vpp #vpp-dev

[Neale Ranns]

There’s not enough information here to diagnose what the problem is. Let’s 
start with a packet trace.

#regards
/neale


From: vpp-dev@lists.fd.io  on behalf of nikhil subhedar 
via lists.fd.io 
Date: Saturday, 31 July 2021 at 19:49
To: vpp-dev@lists.fd.io 
Subject: [vpp-dev] #ipsec #vnet #vpp #vpp-dev
Hi All,

I am facing a problem when IPSEC is enabled on my  box.
1) once the packet comes to my box i am decrypting the packet and i am setting 
the fib index as 1 since my TCP application's listening ip belongs to fib 1.
2)in this scenario  SYN has reached to TCP node and then SYN+ACK is formed and 
it forwarded by TCP node to ip node. where lookup is happening.
3) here at ip layer inside ip4_lookup_inline() it is marking the next node 
based on dpo object.
4) Now, from IP layer it has to reached to esp4-encrypt () but  some times its 
not reaching.
What could be the reason can anyone please shed some light on this?

Below are the steps i am performing .
1) creating the IPSEC tunnel at my StrongSwan.
2) creating ipip0 interface using
set interface state ipip0  up
3)setting this unnumbered ipip0 to vth interface .
set interface unnumbered ipip0 use VirtualFuncEthernet0/6/0.884
4) adding reverse route so that my SYN+ACK can reach to my client.

Thanks,
Nikhil

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#19885): https://lists.fd.io/g/vpp-dev/message/19885
Mute This Topic: https://lists.fd.io/mt/84574890/21656
Mute #vpp:https://lists.fd.io/g/vpp-dev/mutehashtag/vpp
Mute #vnet:https://lists.fd.io/g/vpp-dev/mutehashtag/vnet
Mute #ipsec:https://lists.fd.io/g/vpp-dev/mutehashtag/ipsec
Mute #vpp-dev:https://lists.fd.io/g/vpp-dev/mutehashtag/vpp-dev
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [vpp-dev] VLAN based Forwarding to My application #vlan #memif #forwarding #acl

[Neale Ranns]

Hi Ravi,

So many options 😊 let’s start with the easiest.
VLANs in VPP are a sub-interface. So if you want ALL traffic from Eth0.100 to 
go to memif0.100, and vice-versa, without a MAC rewrite, use an l2-xconnect.

/neale


From: vpp-dev@lists.fd.io  on behalf of RaviKiran Veldanda 
via lists.fd.io 
Date: Thursday, 29 July 2021 at 18:41
To: vpp-dev@lists.fd.io 
Subject: [vpp-dev] VLAN based Forwarding to My application #vlan #memif 
#forwarding #acl

[Edited Message Follows]
Hi Experts,
Our requirement is when VPP receives tcp/udp traffic with VLAN header, it 
should forward to application in Linux
So our requirement is
VLAN 1--> Memif1 --> App1
VLAN 2 --> Memif2 --> App2

How can we achieve this. We don't want to use ip route based or ACL->ABF 
because at least I couldn't able to figure out VLAN based routing is possible.
Any help will be a big help for us.
//Ravi

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#19881): https://lists.fd.io/g/vpp-dev/message/19881
Mute This Topic: https://lists.fd.io/mt/84532112/21656
Mute #acl:https://lists.fd.io/g/vpp-dev/mutehashtag/acl
Mute #memif:https://lists.fd.io/g/vpp-dev/mutehashtag/memif
Mute #vlan:https://lists.fd.io/g/vpp-dev/mutehashtag/vlan
Mute #forwarding:https://lists.fd.io/g/vpp-dev/mutehashtag/forwarding
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [vpp-dev] MPLS protection

[Neale Ranns]

Hi Leela,

Apologies if I was not clear. There is no FRR, no HA (as you describe it).
Along with:
https://github.com/FDio/vpp/blob/master/docs/gettingstarted/developers/fib20/fastconvergence.rst
you might also enjoy:
 
https://github.com/FDio/vpp/blob/master/docs/gettingstarted/developers/fib20/missing.rst

/neale

From: Gudimetla, Leela Sankar 
Date: Monday, 26 July 2021 at 19:42
To: Neale Ranns , vpp-dev@lists.fd.io 
Subject: Re: MPLS protection
Could someone please respond to the specific question that I have described 
below?

Thanks,
Leela sankar

From: vpp-dev@lists.fd.io  on behalf of Gudimetla, Leela 
Sankar via lists.fd.io 
Date: Thursday, July 15, 2021 at 9:42 AM
To: Neale Ranns , vpp-dev@lists.fd.io 
Subject: [**EXTERNAL**] Re: [vpp-dev] MPLS protection
Thanks Neale for responding.
“HA LSP” –  I was referring to primary LSP (Label Switching Path) and backup 
LSP. There can be two or more label encaps configured as a group for each 
label-level in the packet header. In that configuration group, one label will 
refer to primary next-hop and others will refer to backup next-hops. The backup 
label will be used if primary next-hop fails for some reason. And this 
protection-group can be extended to all the label-levels in the label-stack in 
the packet header.

Hope this is clear (on a high-level, it talks about label protection and 
support the protection hierarchically for all the label-levels in the label 
stack in the packet header).

Regards,
Leela sankar

From: Neale Ranns 
Date: Thursday, July 15, 2021 at 1:01 AM
To: Gudimetla, Leela Sankar , vpp-dev@lists.fd.io 

Subject: [**EXTERNAL**] Re: MPLS protection
Hi Leela,

There’s no FRR. I don’t know what a HA LSP would be.
Here’s the docs on what fast convergence support there is:
  
https://github.com/FDio/vpp/blob/master/docs/gettingstarted/developers/fib20/fastconvergence.rst
 
[github.com]<https://urldefense.com/v3/__https:/github.com/FDio/vpp/blob/master/docs/gettingstarted/developers/fib20/fastconvergence.rst__;!!OSsGDw!b_tQQAd3G8uc4uuGWxUD76doCnD_dEmX62U6vRm-ZHAtHvU_SwPLyFBFTX2Pvg$>

/neale


From: vpp-dev@lists.fd.io  on behalf of Gudimetla, Leela 
Sankar via lists.fd.io 
Date: Wednesday, 14 July 2021 at 20:57
To: vpp-dev@lists.fd.io 
Subject: [vpp-dev] MPLS protection
Hello,

I am trying out MPLS configurations to test what all features are supported 
currently on stable 1908.

I don’t see protection for LSP like HA or FRR support explicitly. So I am 
wondering if it is supported yet. Or I may be missing something.

Can someone please share (documentation, code) what all protection mechanism 
supported for MPLS?

Thanks,
Leela sankar

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#19874): https://lists.fd.io/g/vpp-dev/message/19874
Mute This Topic: https://lists.fd.io/mt/84209148/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] ACL-->ABF--> Memif, Seeing arp request for the packets #acl #abf #policy #routing

[Neale Ranns]

Hi Ravi,

If you want the packet to egress with a VLAN, then you can create a VLAN 
sub-interface on the memif and point the policy via that.

/neale

From: vpp-dev@lists.fd.io  on behalf of RaviKiran Veldanda 
via lists.fd.io 
Date: Friday, 16 July 2021 at 19:06
To: vpp-dev@lists.fd.io 
Subject: Re: [vpp-dev] ACL-->ABF--> Memif, Seeing arp request for the packets 
#acl #abf #policy #routing

[Edited Message Follows]

Hi Neale,
Thanks for your time. Yes I got that and I did created a dummy arp to make this 
work.

ip neighbor memif1/0 192.168.1.3 dead.dead.dead

set acl-plugin acl permit dst 172.172.0.0/24

abf policy add id 0 acl 0 via 192.168.1.3 memif1/0

abf attach ip4 policy 0  HundredGigabitEthernet12/0/0.1100

however I have one more question, if we want to get VLAN header also on memif 
how can we get it?
I am seeing the packets with ehternet header but VLAN is getting stripped. How 
can we get VLAN header to memif when we do ABF

Any pointers will be a great help.
//Ravi

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#19820): https://lists.fd.io/g/vpp-dev/message/19820
Mute This Topic: https://lists.fd.io/mt/84250705/21656
Mute #acl:https://lists.fd.io/g/vpp-dev/mutehashtag/acl
Mute #abf:https://lists.fd.io/g/vpp-dev/mutehashtag/abf
Mute #policy:https://lists.fd.io/g/vpp-dev/mutehashtag/policy
Mute #routing:https://lists.fd.io/g/vpp-dev/mutehashtag/routing
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-