date:20210702

Re: [vpp-dev] VRRP issue when using interface in a table

2021-07-02 Thread Matthew Smith via lists.fd.io

Hi Mechthild,

Here is a patch you can try - https://gerrit.fd.io/r/c/vpp/+/32999.

Let me know if it works for you. I don't have an i40e readily available to
test it on and my local build is still using DPDK 21.01 while the
current gerrit master branch uses DPDK 21.05 by default. So I could not
test it against the current gerrit master branch. The exact same patch
works against DPDK 21.01 and the function it modifies was not changed
between 21.01 and 21.05 so I expect it ought to work, but. YMMV.

I'll set the review score to -2 until I receive confirmation from you that
it is working.

-Matt


On Fri, Jul 2, 2021 at 11:48 AM Mechthild Buescher <
mechthild.buesc...@ericsson.com> wrote:

> Hi Matt,
>
>
>
> Thanks for your fast reply. Yes, it seems to be the “source pruning” issue
> on X710/XL710.
>
>
>
> When both VRs are in the master state, I can’t see any VRRP messages in
> the dpdk-input trace. Furthermore, I tried VRRP with Intel e1000 NICs where
> it behaves correctly: When the interface of the VRRP master goes down, the
> VRRP backup changes to state master and when the VRRP master recovers (ie.
> Interface is up), the peer node changes back to state backup.
>
>
>
> It would be nice if you can tell me how to disable source pruning with
> DPDK PMD.
>
>
>
> Thank you,
>
>
>
> BR/Mechthild
>
>
>
> *From:* Matthew Smith 
> *Sent:* Friday, 2 July 2021 16:06
> *To:* Neale Ranns 
> *Cc:* Mechthild Buescher ;
> vpp-dev@lists.fd.io
> *Subject:* Re: [vpp-dev] VRRP issue when using interface in a table
>
>
>
>
>
> There could be an issue with the NIC:
>
>
>
> vpp# show hardware-interfaces
>   NameIdx   Link  Hardware
> Ext-0  1 up   Ext-0
>   Link speed: 10 Gbps
>   Ethernet address e4:43:4b:ed:59:10
>   Intel X710/XL710 Family
>
>
>
> With certain versions of firmware, these interfaces have a feature called
> "source pruning" enabled by default. When a MAC address is added on a
> X710/XL710 interface, packets which arrive with that address as their
> source MAC address are filtered by the NIC. Since VRRP uses a virtual MAC
> address as the source address of advertisements sent to peers, source
> pruning causes problems for it. A VRRP VR entering the master state will
> add the virtual MAC address to the NIC and henceforth the NIC will filter
> any higher priority advertisements that a peer might send because they are
> sourced from the virtual MAC address. I reported a bug to DPDK about it
> which has more details - https://bugs.dpdk.org/show_bug.cgi?id=648
> 
> .
>
>
>
> Mechthild, you can check whether this is the issue you're experiencing by
> taking a packet trace on node 1 when both VRs are in the master state. If
> source pruning is causing the problem, you will not see any received
> advertisements from the peer in the trace because they will have been
> filtered by the hardware and never reach VPP. There is no supported way to
> disable source pruning when using the DPDK PMD, but if your packet trace
> indicates that this appears to be the issue I can give you a patch to try
> which should disable it. If not, please send the output from the packet
> trace anyway so I can try to diagnose what else might be going on.
>
>
>
> Thanks,
>
> -Matt
>
>
>
>
>
>
>
> On Fri, Jul 2, 2021 at 4:04 AM Neale Ranns  wrote:
>
>
>
> Hi Mechthild,
>
>
>
> Core VRRP issues I can’t help with, I no next to nothing about VRRP. I’ll
> hand over to those who do.
>
>
>
> /neale
>
>
>
>
>
> *From: *vpp-dev@lists.fd.io  on behalf of Mechthild
> Buescher via lists.fd.io
> 
> 
> *Date: *Thursday, 1 July 2021 at 22:55
> *To: *vpp-dev@lists.fd.io 
> *Subject: *Re: [vpp-dev] VRRP issue when using interface in a table
>
> Hi Neale,
>
>
>
> I did some deeper investigations on the vrrp issue. What I observed is as
> follows:
>
>
>
> On one node1 the VRRP config is:
> set interface state Ext-0 up
>
> set interface ip address Ext-0 192.168.61.52/25
> 
>
> vrrp vr add Ext-0 vr_id 61 priority 200 no_preempt accept_mode
> 192.168.61.50
>
>
>
> On the other node2 the VRRP config is:
>
> set interface state Ext-0 up
>
> set interface ip address Ext-0 192.168.61.51/25
> 
>
> vrrp vr add Ext-0 vr_id 61 priority 100 no_preempt accept_mode
> 192.168.61.50
>
>
>
> When I start vpp and vrrp (vppctl vrrp proto

Re: [vpp-dev] VRRP issue when using interface in a table

2021-07-02 Thread Mechthild Buescher via lists.fd.io

Hi Matt,

Thanks for your fast reply. Yes, it seems to be the “source pruning” issue on 
X710/XL710.

When both VRs are in the master state, I can’t see any VRRP messages in the 
dpdk-input trace. Furthermore, I tried VRRP with Intel e1000 NICs where it 
behaves correctly: When the interface of the VRRP master goes down, the VRRP 
backup changes to state master and when the VRRP master recovers (ie. Interface 
is up), the peer node changes back to state backup.

It would be nice if you can tell me how to disable source pruning with DPDK PMD.

Thank you,

BR/Mechthild

From: Matthew Smith 
Sent: Friday, 2 July 2021 16:06
To: Neale Ranns 
Cc: Mechthild Buescher ; vpp-dev@lists.fd.io
Subject: Re: [vpp-dev] VRRP issue when using interface in a table


There could be an issue with the NIC:

vpp# show hardware-interfaces
  NameIdx   Link  Hardware
Ext-0  1 up   Ext-0
  Link speed: 10 Gbps
  Ethernet address e4:43:4b:ed:59:10
  Intel X710/XL710 Family

With certain versions of firmware, these interfaces have a feature called 
"source pruning" enabled by default. When a MAC address is added on a 
X710/XL710 interface, packets which arrive with that address as their source 
MAC address are filtered by the NIC. Since VRRP uses a virtual MAC address as 
the source address of advertisements sent to peers, source pruning causes 
problems for it. A VRRP VR entering the master state will add the virtual MAC 
address to the NIC and henceforth the NIC will filter any higher priority 
advertisements that a peer might send because they are sourced from the virtual 
MAC address. I reported a bug to DPDK about it which has more details - 
https://bugs.dpdk.org/show_bug.cgi?id=648.

Mechthild, you can check whether this is the issue you're experiencing by 
taking a packet trace on node 1 when both VRs are in the master state. If 
source pruning is causing the problem, you will not see any received 
advertisements from the peer in the trace because they will have been filtered 
by the hardware and never reach VPP. There is no supported way to disable 
source pruning when using the DPDK PMD, but if your packet trace indicates that 
this appears to be the issue I can give you a patch to try which should disable 
it. If not, please send the output from the packet trace anyway so I can try to 
diagnose what else might be going on.

Thanks,
-Matt



On Fri, Jul 2, 2021 at 4:04 AM Neale Ranns 
mailto:ne...@graphiant.com>> wrote:

Hi Mechthild,

Core VRRP issues I can’t help with, I no next to nothing about VRRP. I’ll hand 
over to those who do.

/neale


From: vpp-dev@lists.fd.io 
mailto:vpp-dev@lists.fd.io>> on behalf of Mechthild 
Buescher via 
lists.fd.io
 mailto:ericsson@lists.fd.io>>
Date: Thursday, 1 July 2021 at 22:55
To: vpp-dev@lists.fd.io 
mailto:vpp-dev@lists.fd.io>>
Subject: Re: [vpp-dev] VRRP issue when using interface in a table
Hi Neale,

I did some deeper investigations on the vrrp issue. What I observed is as 
follows:

On one node1 the VRRP config is:
set interface state Ext-0 up
set interface ip address Ext-0 
192.168.61.52/25
vrrp vr add Ext-0 vr_id 61 priority 200 no_preempt accept_mode 192.168.61.50

On the other node2 the VRRP config is:
set interface state Ext-0 up
set interface ip address Ext-0 
192.168.61.51/25
vrrp vr add Ext-0 vr_id 61 priority 100 no_preempt accept_mode 192.168.61.50

When I start vpp and vrrp (vppctl vrrp proto start Ext-0 vr_id 61) on both 
nodes, everything looks fine:
The node1 is master and has VIP:
vppctl show int addr
Ext-0 (up):
  L3 
192.168.61.52/25
  L3 
192.168.61.50/25

The node2 is backup:
vppctl show int addr
Ext-0 (up):
  L3 
192.168.61.51/25

I can also swap the roles (master/backup) of the

Re: [vpp-dev] VRRP issue when using interface in a table

2021-07-02 Thread Matthew Smith via lists.fd.io

There could be an issue with the NIC:

vpp# show hardware-interfaces
>   NameIdx   Link  Hardware
> Ext-0  1 up   Ext-0
>   Link speed: 10 Gbps
>   Ethernet address e4:43:4b:ed:59:10
>   Intel X710/XL710 Family

With certain versions of firmware, these interfaces have a feature called
"source pruning" enabled by default. When a MAC address is added on a
X710/XL710 interface, packets which arrive with that address as their
source MAC address are filtered by the NIC. Since VRRP uses a virtual MAC
address as the source address of advertisements sent to peers, source
pruning causes problems for it. A VRRP VR entering the master state will
add the virtual MAC address to the NIC and henceforth the NIC will filter
any higher priority advertisements that a peer might send because they are
sourced from the virtual MAC address. I reported a bug to DPDK about it
which has more details - https://bugs.dpdk.org/show_bug.cgi?id=648.

Mechthild, you can check whether this is the issue you're experiencing by
taking a packet trace on node 1 when both VRs are in the master state. If
source pruning is causing the problem, you will not see any received
advertisements from the peer in the trace because they will have been
filtered by the hardware and never reach VPP. There is no supported way to
disable source pruning when using the DPDK PMD, but if your packet trace
indicates that this appears to be the issue I can give you a patch to try
which should disable it. If not, please send the output from the packet
trace anyway so I can try to diagnose what else might be going on.

Thanks,

-Matt

On Fri, Jul 2, 2021 at 4:04 AM Neale Ranns  wrote:

>
>
> Hi Mechthild,
>
>
>
> Core VRRP issues I can’t help with, I no next to nothing about VRRP. I’ll
> hand over to those who do.
>
>
>
> /neale
>
>
>
>
>
> *From: *vpp-dev@lists.fd.io  on behalf of Mechthild
> Buescher via lists.fd.io 
> *Date: *Thursday, 1 July 2021 at 22:55
> *To: *vpp-dev@lists.fd.io 
> *Subject: *Re: [vpp-dev] VRRP issue when using interface in a table
>
> Hi Neale,
>
>
>
> I did some deeper investigations on the vrrp issue. What I observed is as
> follows:
>
>
>
> On one node1 the VRRP config is:
> set interface state Ext-0 up
>
> set interface ip address Ext-0 192.168.61.52/25
>
> vrrp vr add Ext-0 vr_id 61 priority 200 no_preempt accept_mode
> 192.168.61.50
>
>
>
> On the other node2 the VRRP config is:
>
> set interface state Ext-0 up
>
> set interface ip address Ext-0 192.168.61.51/25
>
> vrrp vr add Ext-0 vr_id 61 priority 100 no_preempt accept_mode
> 192.168.61.50
>
>
>
> When I start vpp and vrrp (vppctl vrrp proto start Ext-0 vr_id 61) on both
> nodes, everything looks fine:
>
> The node1 is master and has VIP:
> vppctl show int addr
>
> Ext-0 (up):
>
>   L3 192.168.61.52/25
>
>   L3 192.168.61.50/25
>
>
>
> The node2 is backup:
>
> vppctl show int addr
>
> Ext-0 (up):
>
>   L3 192.168.61.51/25
>
>
>
> I can also swap the roles (master/backup) of the nodes by stopping and
> starting vrrp on the node1:
>
> vppctl vrrp proto stop Ext-0 vr_id 61
>
> vppctl vrrp proto start Ext-0 vr_id 61
>
>
>
> But if node1 (master) goes down because the interface is flapping,
> simulated with:
>
> vppctl set int state Ext-0 down; vppctl set int state Ext-0 up
>
>
>
> then node2 is getting master as expected but node1 is changing from state
> ‘Interface Down’ to ‘Backup’ and then to ‘Master’.
>
> Now both nodes are master and both have the VIP.
>
>
>
> Is this another bug in VRRP?
>
>
>
> Your help is really appreciated.
>
>
>
> Thanks, BR/Mechthild
>
>
>
>
>
> *From:* Mechthild Buescher
> *Sent:* Wednesday, 30 June 2021 17:40
> *To:* vpp-dev@lists.fd.io
> *Subject:* RE: VRRP issue when using interface in a table
>
>
>
> Hi Neale,
>
>
>
> Thanks for your reply. The bugfix partly solved the issue – VRRP goes into
> master/backup and keeps stable for a while. Unfortunately, it changes back
> to master/master after some time (15 minutes – 1 hour). We are currently
> trying to get more details and will come back to you.
>
> But thanks for your support so far,
>
>
>
> BR/Mechthild
>
>
>
> *From:* Neale Ranns 
> *Sent:* Thursday, 24 June 2021 12:33
> *To:* Mechthild Buescher ;
> vpp-dev@lists.fd.io
> *Subject:* Re: VRRP issue when using interface in a table
>
>
>
> Hi Mechthild,
>
>
>
> You’ll need to include:
>
>   https://gerrit.fd.io/r/c/vpp/+/32298
> 
>
>
>
> /neale
>
>
>
> *From: *vpp-dev@lists.fd.io  on behalf of Mechthild
> Buescher via lists.fd.io 
> *Date: *Thursday, 24 June 2021 at 10:49
> *To: *vpp-dev@lists.fd.io 
> *Subject: *[vpp-dev] VRRP issue when using interface in a table
>
> Hi all,
>
>
>
> we are using VPP on two nodes where we would like to run VRRP. This works
> fine if the VRRP VR interface is in fib 0 but

Re: [vpp-dev] VPP on a Bluefield-2 smartNIC

2021-07-02 Thread Pierre Louis Aublin

I do not have a dedicated Bluefield-2 at my disposal; instead, I am 
using one in a shared cluster, chosen at random by the cluster job 
scheduler. Anyway, today I tried on a different one which has the 
Mellanox OFED driver installed. I first had to apply this patch so that 
VPP compiles: https://gerrit.fd.io/r/c/vpp/+/30842 .


My startup.conf is:
```
unix { interactive cli-listen /run/vpp/cli.sock gid 0 }
dpdk { dev :03:00.0 }
plugins { plugin dpdk_plugin.so { enable }
```

This time I could see and configure the network interface, but VPP 
crashed when launching the echo server:

```
$ sudo -E make run
dpdk [warn  ]: not enough DPDK crypto resources
dpdk/cryptodev   [warn  ]: dpdk_cryptodev_init: Not enough cryptodevs
vat-plug/load    [error ]: vat_plugin_register: oddbuf plugin not loaded...
    ___    _    _   _  ___
 __/ __/ _ \  (_)__    | | / / _ \/ _ \
 _/ _// // / / / _ \   | |/ / ___/ ___/
 /_/ /(_)_/\___/   |___/_/  /_/

DBGvpp# sh int
  Name   Idx    State  MTU 
(L3/IP4/IP6/MPLS) Counter  Count

HundredGigabitEthernet3/0/0   1 down 9000/0/0/0
local0    0 down  0/0/0/0
DBGvpp# set interface ip address HundredGigabitEthernet3/0/0 192.168.10.1/24
DBGvpp# set interface state HundredGigabitEthernet3/0/0 up
DBGvpp# sh int addr
HundredGigabitEthernet3/0/0 (up):
  L3 192.168.10.1/24
local0 (dn):
DBGvpp# test echo server
ssvm_server_init_memfd:258: memfd map (fd 27): File exists (errno 17)
session_vpp_event_queues_allocate:1528: failed to initialize queue segment
echo_server_create_command_fn:532: No uri provided! Using default: 
tcp://0.0.0.0/1234

DBGvpp# Aborted
make: *** [Makefile:519: run] Error 134
```

Please find attached the output of `sh log`.

Best
Pierre Louis

On 2021/07/01 18:38, Benoit Ganne (bganne) wrote:

What is your VPP dpdk config looks like in startup.conf? Esp. did you whitelist 
the device? See 
https://fd.io/docs/vpp/master/gettingstarted/users/configuring/startup.html#the-dpdk-section
Also, please share the output of 'show logs'.

Best
ben


-Original Message-
From: Pierre Louis Aublin 
Sent: jeudi 1 juillet 2021 11:08
To: Benoit Ganne (bganne) ; vpp-dev@lists.fd.io
Subject: Re: [vpp-dev] VPP on a Bluefield-2 smartNIC

The"Unsupported PCI device 0x15b3:0xa2d6 found at PCI address
:03:00.0" message disappears; however the network interface still
doesn't show up. Interestingly, vpp on the host also prints this
message, yet the interface can be used.

By any chance, would you have any clue on what I could try to further
debug this issue?

Best
Pierre Louis

On 2021/07/01 17:50, Benoit Ganne (bganne) via lists.fd.io wrote:

Please try https://gerrit.fd.io/r/c/vpp/+/32965 and reports if it works.

Best
ben


-Original Message-
From: vpp-dev@lists.fd.io  On Behalf Of Pierre

Louis

Aublin
Sent: jeudi 1 juillet 2021 07:36
To: vpp-dev@lists.fd.io
Subject: [vpp-dev] VPP on a Bluefield-2 smartNIC

Dear VPP developers

I would like to run VPP on the Bluefield-2 smartNIC, but even though I
managed to compile it the interface doesn't show up inside the CLI. By
any chance, would you know how to compile and configure vpp for this
device?

I am using VPP v21.06-rc2 and did the following modifications so that

it

can compile:
```
diff --git a/build/external/packages/dpdk.mk
b/build/external/packages/dpdk.mk
index c7eb0fc3f..31a5c764e 100644
--- a/build/external/packages/dpdk.mk
+++ b/build/external/packages/dpdk.mk
@@ -15,8 +15,8 @@ DPDK_PKTMBUF_HEADROOM    ?= 128
    DPDK_USE_LIBBSD  ?= n
    DPDK_DEBUG   ?= n
    DPDK_MLX4_PMD    ?= n
-DPDK_MLX5_PMD    ?= n
-DPDK_MLX5_COMMON_PMD ?= n
+DPDK_MLX5_PMD    ?= y
+DPDK_MLX5_COMMON_PMD ?= y
    DPDK_TAP_PMD ?= n
    DPDK_FAILSAFE_PMD    ?= n
    DPDK_MACHINE ?= default
diff --git a/build/external/packages/ipsec-mb.mk
b/build/external/packages/ipsec-mb.mk
index d0bd2af19..119eb5219 100644
--- a/build/external/packages/ipsec-mb.mk
+++ b/build/external/packages/ipsec-mb.mk
@@ -34,7 +34,7 @@ define  ipsec-mb_build_cmds
     SAFE_DATA=n \
     PREFIX=$(ipsec-mb_install_dir) \
     NASM=$(ipsec-mb_install_dir)/bin/nasm \
- EXTRA_CFLAGS="-g -msse4.2" > $(ipsec-mb_build_log)
+ EXTRA_CFLAGS="-g" > $(ipsec-mb_build_log)
    endef

    define  ipsec-mb_install_cmds
```


However, when running the VPP CLI, the network interface does not show

up:

```
$ sudo -E make run
clib_sysfs_prealloc_hugepages:261: pre-allocating 6 additional 2048K
hugepages on numa node 0
dpdk   [warn  ]: Unsupported PCI device 0x15b3:0xa2d6 found
at PCI address :03:00.0

dpdk/cryptodev [warn  ]: dpdk_cryptodev_init: Failed to configure
cryptodev
vat-plug/load  [error ]: vat_plugin_register: oddbuf plugin not
loaded...
       ___    _    _   _  ___

Re: [vpp-dev] VPP on a Bluefield-2 smartNIC

2021-07-02 Thread Pierre Louis Aublin


Indeed, it is not needed.
I previously removed it to compile on an old Intel CPU without sse4.2 
and kept it for the Bluefield.


Thank you

On 2021/07/01 20:45, Damjan Marion wrote:



On 01.07.2021., at 07:35, Pierre Louis Aublin  wrote:

diff --git a/build/external/packages/ipsec-mb.mk 
b/build/external/packages/ipsec-mb.mk
index d0bd2af19..119eb5219 100644
--- a/build/external/packages/ipsec-mb.mk
+++ b/build/external/packages/ipsec-mb.mk
@@ -34,7 +34,7 @@ define  ipsec-mb_build_cmds
   SAFE_DATA=n \
   PREFIX=$(ipsec-mb_install_dir) \
   NASM=$(ipsec-mb_install_dir)/bin/nasm \
- EXTRA_CFLAGS="-g -msse4.2" > $(ipsec-mb_build_log)
+ EXTRA_CFLAGS="-g" > $(ipsec-mb_build_log)

Why do you need this change?

If i get it right bluefield uses ARM cpus and we don’t compile intel ipsecmb 
lib on arm.

$ git grep ARCH_X86_64 build/external/Makefile
build/external/Makefile:ARCH_X86_64=$(filter x86_64,$(shell uname -m))
build/external/Makefile:install: $(if $(ARCH_X86_64), nasm-install 
ipsec-mb-install) dpdk-install rdma-core-install quicly-install libbpf-install
build/external/Makefile:config: $(if $(ARCH_X86_64), nasm-config 
ipsec-mb-config) dpdk-config rdma-core-config quicly-build

—
Damjan



-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#19692): https://lists.fd.io/g/vpp-dev/message/19692
Mute This Topic: https://lists.fd.io/mt/83910198/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] next-hop-table between two FIB tables results in punt and 'unknown ip protocol'

2021-07-02 Thread Neale Ranns



From: Mechthild Buescher 
Date: Thursday, 1 July 2021 at 14:51
To: Neale Ranns , Benoit Ganne (bganne) 
, vpp-dev@lists.fd.io 
Subject: RE: [vpp-dev] next-hop-table between two FIB tables results in punt 
and 'unknown ip protocol'
Hi all,

I still don’t have success. This is the configuration I tried:
set interface state NCIC-1-v1 up

create host-interface name Vpp2Host
set interface state host-Vpp2Host up


ip table add 4093
create sub-interfaces host-Vpp2Host 4093
set interface state host-Vpp2Host.4093 up
set interface ip table host-Vpp2Host.4093 4093
set interface ip address host-Vpp2Host.4093 198.19.255.249/29

ip table add 1
create sub-interfaces NCIC-1-v1 1
set interface state NCIC-1-v1.1 up
set interface ip table NCIC-1-v1.1 1

did you miss giving the interface an address here…

ip route add 198.19.255.248/29 table 1 via 0.0.0.0 next-hop-table 4093

this …

ip table add 2
create sub-interfaces NCIC-1-v1 2
set interface state NCIC-1-v1.2 up
set interface ip table NCIC-1-v1.2 2
set interface ip address NCIC-1-v1.2 10.10.203.19/29
ip route add 198.19.255.248/29 table 2 via 198.19.255.249 next-hop-table 4093

this …

ip table add 3
create sub-interfaces NCIC-1-v1 3
set interface state NCIC-1-v1.3 up
set interface ip table NCIC-1-v1.3 3
set interface ip address NCIC-1-v1.3 10.10.203.19/29
ip route add 198.19.255.248/29 table 3 via 198.19.255.249 ip4-look-in-table 4093

and this are all different. Are you hedging your bets 

This is how I tried the config:
vppctl ping 198.19.255.253 table-id 4093
116 bytes from 198.19.255.253: icmp_seq=2 ttl=64 time=9.2805 ms
vppctl ping 198.19.255.253 table-id 1
Failed: no egress interface
vppctl ping vppctl sh int addr
Ext-0 (dn):
NCIC-1-v1 (up):
NCIC-1-v1.1 (up):
NCIC-1-v1.2 (up):
  L3 10.10.203.19/29 ip4 table-id 2 fib-idx 3
NCIC-1-v1.3 (up):
  L3 10.10.203.19/29 ip4 table-id 3 fib-idx 4
NCIC-1-v2 (dn):
Radio-0 (dn):
host-Vpp2Host (up):
host-Vpp2Host.4093 (up):
  L3 198.19.255.249/29 ip4 table-id 4093 fib-idx 1
local0 (dn):table-id 2
Statistics: 5 sent, 0 received, 100% packet loss
vppctl ping 198.19.255.253 table-id 3
Failed: no egress interface

The ping code uses the FIB to find egress interface. To do this it does a 
lookup on the destination address and then asks of the resulting FIB entry to 
get a resolving interface. A FIB entry that requires a second lookup cannot 
return a resolving interface. Two options, try ‘ping X source ’ to give 
ping the interface you want used, or add the routes the right way.
  ip route add 198.19.255.248/29 table 3 via host-Vpp2Host.4093

/neale


This is what I see in vpp:
vppctl sh int addr
Ext-0 (dn):
NCIC-1-v1 (up):
NCIC-1-v1.1 (up):
NCIC-1-v1.2 (up):
  L3 10.10.203.19/29 ip4 table-id 2 fib-idx 3
NCIC-1-v1.3 (up):
  L3 10.10.203.19/29 ip4 table-id 3 fib-idx 4
NCIC-1-v2 (dn):
Radio-0 (dn):
host-Vpp2Host (up):
host-Vpp2Host.4093 (up):
  L3 198.19.255.249/29 ip4 table-id 4093 fib-idx 1
local0 (dn):

vppctl sh ip fib 198.19.255.253
ipv4-VRF:0, fib_index:0, flow hash:[src dst sport dport proto flowlabel ] 
epoch:0 flags:none locks:[default-route:1, ]
0.0.0.0/0 fib:0 index:0 locks:2
  default-route refs:1 entry-flags:drop, src-flags:added,contributing,active,
path-list:[0] locks:2 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:0 to:[0:0]]
[0] [@0]: dpo-drop ip4
ipv4-VRF:4093, fib_index:1, flow hash:[src dst sport dport proto flowlabel ] 
epoch:0 flags:none locks:[CLI:2, adjacency:1, recursive-resolution:2, ]
198.19.255.253/32 fib:1 index:41 locks:2
  adjacency refs:1 entry-flags:attached, src-flags:added,contributing,active, 
cover:12
path-list:[54] locks:2 uPRF-list:46 len:1 itfs:[6, ]
  path:[60] pl-index:54 ip4 weight=1 pref=0 attached-nexthop:  
oper-flags:resolved,
198.19.255.253 host-Vpp2Host.4093
  [@0]: ipv4 via 198.19.255.253 host-Vpp2Host.4093: mtu:9000 next:3 
flags:[] a215f39524f302fe349f8c8a81000ffd0800
Extensions:
 path:60 adj-flags:[refines-cover]
forwarding:   unicast-ip4-chain
  [@0]: dpo-load-balance: [proto:ip4 index:42 buckets:1 uRPF:46 to:[6:576]]
[0] [@5]: ipv4 via 198.19.255.253 host-Vpp2Host.4093: mtu:9000 next:3 
flags:[] a215f39524f302fe349f8c8a81000ffd0800
ipv4-VRF:1, fib_index:2, flow hash:[src dst sport dport proto flowlabel ] 
epoch:0 flags:none locks:[CLI:2, ]
198.19.255.248/29 fib:2 index:21 locks:2
  CLI refs:1 src-flags:added,contributing,active,
path-list:[31] locks:2 flags:shared, uPRF-list:23 len:0 itfs:[]
  path:[33] pl-index:31 ip4 weight=1 pref=0 deag:  oper-flags:resolved,
 fib-index:1

forwarding:   unicast-ip4-chain
  [@0]: dpo-load-balance: [proto:ip4 index:22 buckets:1 uRPF:23 to:[0:0]]
[0] [@11]: dst-address,unicast lookup in ipv4-VRF:4093
ipv4-VRF:2, fib_index:3, flow hash:[src dst sport dport proto flowlabel ] 
epoch:0 flags:none locks:[CLI:2,

Re: [vpp-dev] VRRP issue when using interface in a table

2021-07-02 Thread Neale Ranns


Hi Mechthild,

Core VRRP issues I can’t help with, I no next to nothing about VRRP. I’ll hand 
over to those who do.

/neale


From: vpp-dev@lists.fd.io  on behalf of Mechthild Buescher 
via lists.fd.io 
Date: Thursday, 1 July 2021 at 22:55
To: vpp-dev@lists.fd.io 
Subject: Re: [vpp-dev] VRRP issue when using interface in a table
Hi Neale,

I did some deeper investigations on the vrrp issue. What I observed is as 
follows:

On one node1 the VRRP config is:
set interface state Ext-0 up
set interface ip address Ext-0 192.168.61.52/25
vrrp vr add Ext-0 vr_id 61 priority 200 no_preempt accept_mode 192.168.61.50

On the other node2 the VRRP config is:
set interface state Ext-0 up
set interface ip address Ext-0 192.168.61.51/25
vrrp vr add Ext-0 vr_id 61 priority 100 no_preempt accept_mode 192.168.61.50

When I start vpp and vrrp (vppctl vrrp proto start Ext-0 vr_id 61) on both 
nodes, everything looks fine:
The node1 is master and has VIP:
vppctl show int addr
Ext-0 (up):
  L3 192.168.61.52/25
  L3 192.168.61.50/25

The node2 is backup:
vppctl show int addr
Ext-0 (up):
  L3 192.168.61.51/25

I can also swap the roles (master/backup) of the nodes by stopping and starting 
vrrp on the node1:
vppctl vrrp proto stop Ext-0 vr_id 61
vppctl vrrp proto start Ext-0 vr_id 61

But if node1 (master) goes down because the interface is flapping, simulated 
with:
vppctl set int state Ext-0 down; vppctl set int state Ext-0 up

then node2 is getting master as expected but node1 is changing from state 
‘Interface Down’ to ‘Backup’ and then to ‘Master’.
Now both nodes are master and both have the VIP.

Is this another bug in VRRP?

Your help is really appreciated.

Thanks, BR/Mechthild


From: Mechthild Buescher
Sent: Wednesday, 30 June 2021 17:40
To: vpp-dev@lists.fd.io
Subject: RE: VRRP issue when using interface in a table

Hi Neale,

Thanks for your reply. The bugfix partly solved the issue – VRRP goes into 
master/backup and keeps stable for a while. Unfortunately, it changes back to 
master/master after some time (15 minutes – 1 hour). We are currently trying to 
get more details and will come back to you.

But thanks for your support so far,

BR/Mechthild

From: Neale Ranns mailto:ne...@graphiant.com>>
Sent: Thursday, 24 June 2021 12:33
To: Mechthild Buescher 
mailto:mechthild.buesc...@ericsson.com>>; 
vpp-dev@lists.fd.io
Subject: Re: VRRP issue when using interface in a table

Hi Mechthild,

You’ll need to include:
  
https://gerrit.fd.io/r/c/vpp/+/32298

/neale

From: vpp-dev@lists.fd.io 
mailto:vpp-dev@lists.fd.io>> on behalf of Mechthild 
Buescher via lists.fd.io 
mailto:mechthild.buescher=ericsson@lists.fd.io>>
Date: Thursday, 24 June 2021 at 10:49
To: vpp-dev@lists.fd.io 
mailto:vpp-dev@lists.fd.io>>
Subject: [vpp-dev] VRRP issue when using interface in a table
Hi all,

we are using VPP on two nodes where we would like to run VRRP. This works fine 
if the VRRP VR interface is in fib 0 but if we but the interface into FIB table 
1 instead, VRRP is not working correctly anymore. Can you please help?

Our setup:

· 2 nodes with VPP on each node and one DPDK interface (we reduced the 
config to isolate the issue) connected to each VPP

· a switch between the nodes which just forwards the traffic, so that 
it’s like a peer-2-peer connection

The VPP version is (both nodes):

vpp# show version
vpp v21.01.0-6~gf70123b2c built by suse on SUSE at 2021-05-06T12:18:31
vpp# show version verbose
Version:  v21.01.0-6~gf70123b2c
Compiled by:  suse
Compile host: SUSE
Compile date: 2021-05-06T12:18:31
Compile location: /root/vpp-sp/vpp
Compiler: GCC 7.5.0
Current PID:  6677

The VPP config uses the DPDK interface (both nodes):

vpp# show hardware-interfaces
  NameIdx   Link  Hardware
Ext-0  1 up   Ext-0
  Link speed: 10 Gbps
  Ethernet address e4:43:4b:ed:59:10
  Intel X710/XL710 Family
carrier up full duplex mtu 9206
flags: admin-up pmd maybe-multiseg tx-offload intel-phdr-cksum rx-ip4-cksum
Devargs:
rx: queues 1 (max 192), desc 1024 (min 64 max 4096 align 32)
tx: queues 3 (max 192), desc 1024 (min 64 max 4096 align 32)
pci: device 8086:1572 subsystem 1028:1f9c address :17:00.00 numa 0
max rx packet len: 9728
promiscuous: unicast off all-multicast on
vlan offload: strip off filter off qinq off
rx offload avail:  vlan-strip ipv4-cksum udp-cksum tcp-cksum qinq-strip
   outer-ipv4-cksum vlan-filter vlan-extend jumbo-frame
   scatter keep-crc rss-hash
rx offload active: ipv4-cksum jumbo-frame scatter
tx offload

Re: [vpp-dev] VRRP issue when using interface in a table

Re: [vpp-dev] VRRP issue when using interface in a table

Re: [vpp-dev] VRRP issue when using interface in a table

Re: [vpp-dev] VPP on a Bluefield-2 smartNIC

Re: [vpp-dev] VPP on a Bluefield-2 smartNIC

Re: [vpp-dev] next-hop-table between two FIB tables results in punt and 'unknown ip protocol'

Re: [vpp-dev] VRRP issue when using interface in a table

7 matches

Site Navigation

Mail list logo

Footer information