Re: [vpp-dev] creat mpls tunnel

[Neale Ranns via Lists.Fd.Io]

You can’t with the current API. Nor can you with any other type of tunnel.

/neale

From:  on behalf of "omid via Lists.Fd.Io" 

Reply-To: "zeinalpouro...@yahoo.com" 
Date: Tuesday, 12 June 2018 at 18:46
To: "vpp-dev@lists.fd.io" 
Cc: "vpp-dev@lists.fd.io" 
Subject: [vpp-dev] creat mpls tunnel

Hi,
how mpls tunnel add with an arbitrary name?
thanks.


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

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

[Neale Ranns via Lists.Fd.Io]

Hi,

This:
  XXX via via 1.1.1.1 ip4-lookup-in-table 0 out-labels 33
is not a valid path.

If you want packets to follow the same path as for 1.1.1.1 (i.e. the path is 
recursive via 1.1.1.1, and you’ll need a route in the fib for 1.1.1.1) and have 
label 33 imposed, do:
  XXX via via 1.1.1.1 out-labels 33
If the 1.1.1.1 you want to recurse via is not in the default table, then do:
XXX via via 1.1.1.1 next-hop-table Y out-labels 33

If (e.g. post a label pop) you want to use the exposed IP4 header to do a IP4 
lookup then do:
  XXX via via ip4-lookup-in-table 0

This:
  XXX via 1.1.1.1 GigabitEthernet13/0/0 out-labels 33
Is not a recursive path. It will resolve via the adjacency for 1.1.1.1 on 
GigE13/0/0 and thus will attempt to ARP for 1.1.1.1 out of that interface. 
Since 1.1.1.1 is not an address on that interface’s configured subnet, this 
won’t work, unless the peer is running proxy ARP, which we all know is evil.

/neale

From:  on behalf of Gulakh 
Date: Wednesday, 20 June 2018 at 22:32
To: "vpp-dev@lists.fd.io" 
Subject: [vpp-dev] mpls tunnel

Hi,
My topology is:

  R1 (192.168.1.1/24) 
<--> R2 (192.168.1.2/24)

and R1 loopback interface has IP address of 1.1.1.1/32

==
I have configured VPP's mpls tunnel as follow:
set interface ip address GigabitEthernet13/0/0 
192.168.1.2/24
mpls tunnel l2-only via 1.1.1.1 ip4-lookup-in-table 0 out-labels 33

To make it possible to find 1.1.1.1, I inserted a route in ip fib as follow:
   ip route add 1.1.1.1/32 via 192.168.1.1 
GigabitEthernet13/0/0

What I see in "show mpls tunnel" is as follow:

[@0] mpls_tunnel0: sw_if_index:4 hw_if_index:4
 flags:L2,
 via:
path-list:[22] locks:1 flags:shared, uPRF-list:20 len:1 itfs:[2, ]
  path:[22] pl-index:22 ip4 weight=1 pref=0 recursive:
via 192.168.1.1 in fib:0 via-fib:17 via-dpo:[dpo-load-balance:20]
Extensions:
 path:22 mpls-flags:[no-ip-tll-decr] labels:[[33 pipe ttl:0 exp:0]]
 forwarding: ethernet
 [@1]: dpo-load-balance: [proto:ethernet index:22 buckets:1 uRPF:-1 to:[0:0]]
[0] [@0]: dpo-drop ethernet

==
In another scenario, I have used following configurations:
set interface ip address GigabitEthernet13/0/0 
192.168.1.2/24
mpls tunnel l2-only via 1.1.1.1 GigabitEthernet13/0/0 out-labels 33

What I see in "show mpls tunnel" is as follow:

[@0] mpls_tunnel0: sw_if_index:4 hw_if_index:4
 flags:L2,
 via:
path-list:[23] locks:1 flags:shared, uPRF-list:19 len:1 itfs:[2, ]
  path:[23] pl-index:23 ip4 weight=1 pref=0 attached-nexthop:  
oper-flags:resolved,
1.1.1.1 GigabitEthernet13/0/0
  [@0]: arp-ipv4: via 1.1.1.1 GigabitEthernet13/0/0
Extensions:
 path:23 mpls-flags:[no-ip-tll-decr] labels:[[33 pipe ttl:0 exp:0]]
 forwarding: ethernet
 [@1]: dpo-load-balance: [proto:ethernet index:23 buckets:1 uRPF:-1 to:[0:0]]
[0] [@2]: mpls-label[0]:[33:64:0:eos]
[@1]: arp-mpls: via 1.1.1.1 GigabitEthernet13/0/0


==
My Question:
Q: Why does not VPP resolve IP address of 1.1.1.1 in the first configuration 
(As the "show mpls tunnel" in first scenario shows, It has not been resolved)?? 
I expect to do so since I have added a route for 1.1.1.1 in IP fib.

Thanks


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

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

[Neale Ranns via Lists.Fd.Io]

If you want to resolve a recursive path that has outgoing labels, ie.
  via 1.1.1.1 out-labels 33

then the resolving route in the FIB MUST also have out-labels. This is because 
you are in effect layering LSPs (the tunnel is the upper/inner layer and the 
route the lower/outer layer). The out-label for the tunnel, provided by the 
tunnel egress device, is not necessarily directly connected to the tunnel 
ingress device. Hence, if the route did not have an out label then a device in 
between the two (that is in the lower layer) would see the label for the 
tunnel/upper layer and mis-forward.
If your two devices are directly connected and so the problem above cannot 
occur, you still need an out-label for the route, but one describes such 
directly connectivity by giving the route an implicit-null out-label, i.e.
   ip route 1.1.1.1/32  via 192.168.1.1 GigabitEthernet13/0/0 out-label imp-null

/neale


From: Holoo Gulakh 
Date: Thursday, 21 June 2018 at 17:26
To: "Neale Ranns (nranns)" , "vpp-dev@lists.fd.io" 

Subject: Re: [vpp-dev] mpls tunnel

Hi,
It is not a valid solution.(at least "show mpls tunnel" says that)

Here is the new configuration and result:
   mpls tunnel l2-only via 1.1.1.1 out-labels 33
   ip route add 1.1.1.1/32 via 192.168.1.1 
GigabitEthernet13/0/0

result:
I expect to see something like the result of second scenario above:
===
[@0] mpls_tunnel0: sw_if_index:4 hw_if_index:4
 flags:L2,
 via:
path-list:[23] locks:1 flags:shared, uPRF-list:19 len:1 itfs:[2, ]
  path:[23] pl-index:23 ip4 weight=1 pref=0 attached-nexthop:  
oper-flags:resolved,
1.1.1.1 GigabitEthernet13/0/0
  [@0]: arp-ipv4: via 1.1.1.1 GigabitEthernet13/0/0
Extensions:
 path:23 mpls-flags:[no-ip-tll-decr] labels:[[33 pipe ttl:0 exp:0]]
 forwarding: ethernet
 [@1]: dpo-load-balance: [proto:ethernet index:23 buckets:1 uRPF:-1 to:[0:0]]
[0] [@2]: mpls-label[0]:[33:64:0:eos]
[@1]: arp-mpls: via 1.1.1.1 GigabitEthernet13/0/0


But the result is as follow:
===
[@0] mpls_tunnel0: sw_if_index:4 hw_if_index:4
 flags:L2,
 via:
path-list:[23] locks:1 flags:shared, uPRF-list:19 len:1 itfs:[2, ]
  path:[23] pl-index:23 ip4 weight=1 pref=0 recursive:
via 1.1.1.1 in fib:0 via-fib:17 via-dpo:[dpo-load-balance:20]
Extensions:
 path:23 mpls-flags:[no-ip-tll-decr] labels:[[33 pipe ttl:0 exp:0]]
 forwarding: ethernet
 [@1]: dpo-load-balance: [proto:ethernet index:23 buckets:1 uRPF:-1 to:[0:0]]
[0] [@0]: dpo-drop ethernet


If I use the following command for the route to 1.1.1.1:
 ip route add 1.1.1.1/32 via 192.168.1.1 
GigabitEthernet13/0/0  out-labels 50

the result is:
===
[@0] mpls_tunnel0: sw_if_index:4 hw_if_index:4
 flags:L2,
 via:
path-list:[23] locks:1 flags:shared, uPRF-list:19 len:1 itfs:[2, ]
  path:[23] pl-index:23 ip4 weight=1 pref=0 recursive:  oper-flags:resolved,
via 1.1.1.1 in fib:0 via-fib:17 via-dpo:[dpo-load-balance:20]
Extensions:
 path:23 mpls-flags:[no-ip-tll-decr] labels:[[33 pipe ttl:0 exp:0]]
 forwarding: ethernet
 [@1]: dpo-load-balance: [proto:ethernet index:23 buckets:1 uRPF:-1 to:[0:0]]
[0] [@2]: mpls-label[0]:[33:64:0:eos]
[@1]: dpo-load-balance: [proto:mpls index:21 buckets:1 uRPF:22 to:[0:0] 
 via:[1:64]]
[0] [@6]: mpls-label[1]:[50:64:0:neos]
[@2]: mpls via 192.168.1.1 GigabitEthernet13/0/0: mtu:9000 
000c293a39d7000c29d693938847
Which is correct in my scenario.

How can I use the defined route for 1.1.1.1 in IP fib as the route for mpls 
tunnel to get to 1.1.1.1 (in both case with mpls label--which I provided-- and 
without mpls label)??

Thanks.

On Thu, Jun 21, 2018 at 4:46 AM, Neale Ranns (nranns) 
mailto:nra...@cisco.com>> wrote:
Hi,

This:
  XXX via via 1.1.1.1 ip4-lookup-in-table 0 out-labels 33
is not a valid path.

If you want packets to follow the same path as for 1.1.1.1 (i.e. the path is 
recursive via 1.1.1.1, and you’ll need a route in the fib for 1.1.1.1) and have 
label 33 imposed, do:
  XXX via via 1.1.1.1 out-labels 33
If the 1.1.1.1 you want to recurse via is not in the default table, then do:
XXX via via 1.1.1.1 next-hop-table Y out-labels 33

If (e.g. post a label pop) you want to use the exposed IP4 header to do a IP4 
lookup then do:
  XXX via via ip4-lookup-in-table 0

This:
  XXX via 1.1.1.1 GigabitEthernet13/0/0 out-labels 33
Is not a recursive path. It will resolve via the adjacency for 1.1.1.1 on 
GigE13/0/0 and thus will attempt to ARP for 1.1.1.1 out of that interface. 
Since 1.1.1.1 is not an address on that interface’s configured subnet, this 
won’t work, unless the peer is running proxy ARP, which we all know is evil.

/neale

From: mailto:vpp-dev@lists.fd.io>> on behalf of Gulakh 
mailto:holoogul...@gmail.com>>
Date: Wednesday, 20 June 2018 at 22:32
To: "vpp-dev@lists.fd.io" 
mail

Re: [vpp-dev] twamp

[Neale Ranns via Lists.Fd.Io]

Hi Avi,

None that I am aware of, but its inclusion would be welcome. 

/neale

-Original Message-
From:  on behalf of "Avi Cohen (A)" 
Date: Thursday, 28 June 2018 at 15:04
To: "vpp-dev@lists.fd.io" 
Subject: [vpp-dev] twamp

Hi,
Is there any plan to implement/integrate TWAMP into VPP ?
Regards
Avi



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

View/Reply Online (#9757): https://lists.fd.io/g/vpp-dev/message/9757
Mute This Topic: https://lists.fd.io/mt/22866386/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] Does VPP support source base route?

[Neale Ranns via Lists.Fd.Io]

Hi David,

Yes and no.

No, because there is [today] no way to change *the* IP lookup to use the 
packet’s source address.

Yes, because VPP does support a source based lookup, but this would happen 
after *the* destination based lookup. So, the trick would be to configure a 
second IP table with routes for your source addresses, i.e:
  ip table add 1
  ip route add table 1 10.0.0.0/8 via 192.168.1.1 GigEthernet0/0/0/0
and then configure *the* destination based lookup to use this table for a 
second source based lookup
  ip route 0.0.0.0/0 via ip4-lookup-in-table 1 src-lookup
using the default route points all packets to the second lookup.

I just did:
  https://gerrit.fd.io/r/#/c/13337/
To accept the ‘src-lookup’ keyword for ip route configuration (which is today 
only available via the API).

Hth,
/neale


From:  on behalf of david zhang 

Date: Tuesday, 3 July 2018 at 15:39
To: "vpp-dev@lists.fd.io" 
Subject: [vpp-dev] Does VPP support source base route?


Hi,



My application situation needs to route packet based on source ip address, but 
can it be implemented through some simple commands in VPP? such as "ip route".

I have try to read the related source code and find it really difficult.

I really hope I can get some advice.



Thanks in advance!



Regards,

David

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

View/Reply Online (#9773): https://lists.fd.io/g/vpp-dev/message/9773
Mute This Topic: https://lists.fd.io/mt/23024219/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] [pw] [vpp] VXLAN arp response packet is dropped

[Neale Ranns via Lists.Fd.Io]

Hi Satomi

Debugging packet loss is much easier with a VPP packet trace…

Regards,
neale

-Original Message-
From:  on behalf of 井上里美 
Date: Friday, 6 July 2018 at 12:38
To: "vpp-dev@lists.fd.io" 
Cc: "Norimasa Asai (noasai)" , エッジ仮想化hcoML 
, 小柳達也様 , 
N転P_西岡孟朗様 
Subject: [vpp-dev] [pw] [vpp] VXLAN arp response packet is dropped

The password is here.
1j^?iKvC]C;%

On 2018/07/06 19:37, 井上里美 wrote:
> Hi VPP Team,
>
> I'm Satomi Inoue and I belong to NTT laboratories.
> Could you tell me why ARP response packet is dropped?
>
> We set up vxlan while looking at 
> ”Using_VPP_as_a_VXLAN_Tunnel_Terminator”manual.
> The procedure is as follows.
>
> [The result]
> ・ARP request packet : IXIA(port2)→VPP→IXIA(port1):OK
> ・ARP response packet : IXIA(port1)→VPP→IXIA(port2):NG
> 　→We checked it by trace command. Loopback interface in VPP drop the 
> ARP response packet.
>
> [set up vxlan]
> 1. Create sub-interface
> vpp# create sub-interfaces VirtualFunctionEthernet0/9/0 1
> vpp# set interface state VirtualFunctionEthernet0/9/0.1 up
>
> 2. Create bridge-domain
> create bridge-domain 10001 learn 1 forward 1 uu-flood 1 arp-term 0
>
> 3. Create Loopback interface
> vpp# loopback create mac 1a:2b:3c:4d:5e:6f
> vpp# set interface state loop0 up
> vpp# set interface ip address loop0 1.1.1.1/32
> vpp# set interface ip table loop0 7
>
> 4. Apply loopback interface to bride-domain
> vpp# set interface l2 bridge loop0 10001 bvi
>
> 5.Apply sub-interface to bride-domain
> vpp# set interface l2 bridge VirtualFunctionEthernet0/9/0.1 10001 0
>
> 6.Create VXLAN tunnel
> vpp# create vxlan tunnel src 1.1.1.1 dst 20.10.0.1 vni 10001 
> encap-vrf-id 7 decap-next l2
> vpp# set interface l2 bridge vxlan_tunnel0 10001 1
>
> Regards,
> Satomi

-- 
-
日本電信電話株式会社 情報ネットワーク総合研究所
ネットワークサービスシステム研究所 転送サービス基盤プロジェクト
井上里美(Satomi Inoue)
〒180-8585 東京都武蔵野市緑町3-9-11
PHONE:0422-59-4151
E-MAIL:inoue.sat...@lab.ntt.co.jp




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

View/Reply Online (#9795): https://lists.fd.io/g/vpp-dev/message/9795
Mute This Topic: https://lists.fd.io/mt/23172883/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] VXLAN arp response packet is dropped

[Neale Ranns via Lists.Fd.Io]

Can I see the packet trace?

/neale

-Original Message-
From: 井上里美 
Date: Wednesday, 18 July 2018 at 09:54
To: "Neale Ranns (nranns)" , "vpp-dev@lists.fd.io" 

Cc: "Norimasa Asai (noasai)" , エッジ仮想化hcoML 
, 小柳達也様 , 
N転P_西岡孟朗様 
Subject: [vpp] VXLAN arp response packet is dropped

Hi neale san,

Thank you for your reply.
We used a vpp packet trace.
show trace is no error but on the caputure device,ARP request packet is 
droped.
It happend the same event even L2.

Could you give me some advice?

【Architecture】
　 ＿＿
｜　　  ｜→caputure device→IXIA(port 2)
｜VPP｜
｜　　　｜←IXIA(port 1)
｜＿＿｜

On 2018/07/06 21:39, Neale Ranns (nranns) wrote:
> Hi Satomi
>
> Debugging packet loss is much easier with a VPP packet trace…
>
> Regards,
> neale
>
> -Original Message-
> From:  on behalf of 井上里美 
> Date: Friday, 6 July 2018 at 12:38
> To: "vpp-dev@lists.fd.io" 
> Cc: "Norimasa Asai (noasai)" , エッジ仮想化hcoML 
, 小柳達也様 , 
N転P_西岡孟朗様 
> Subject: [vpp-dev] [pw] [vpp] VXLAN arp response packet is dropped
>
>  The password is here.
>  1j^?iKvC]C;%
>  
>  On 2018/07/06 19:37, 井上里美 wrote:
>  > Hi VPP Team,
>  >
>  > I'm Satomi Inoue and I belong to NTT laboratories.
>  > Could you tell me why ARP response packet is dropped?
>  >
>  > We set up vxlan while looking at
>  > ”Using_VPP_as_a_VXLAN_Tunnel_Terminator”manual.
>  > The procedure is as follows.
>  >
>  > [The result]
>  > ・ARP request packet : IXIA(port2)→VPP→IXIA(port1):OK
>  > ・ARP response packet : IXIA(port1)→VPP→IXIA(port2):NG
>  > 　→We checked it by trace command. Loopback interface in VPP drop 
the
>  > ARP response packet.
>  >
>  > [set up vxlan]
>  > 1. Create sub-interface
>  > vpp# create sub-interfaces VirtualFunctionEthernet0/9/0 1
>  > vpp# set interface state VirtualFunctionEthernet0/9/0.1 up
>  >
>  > 2. Create bridge-domain
>  > create bridge-domain 10001 learn 1 forward 1 uu-flood 1 
arp-term 0
>  >
>  > 3. Create Loopback interface
>  > vpp# loopback create mac 1a:2b:3c:4d:5e:6f
>  > vpp# set interface state loop0 up
>  > vpp# set interface ip address loop0 1.1.1.1/32
>  > vpp# set interface ip table loop0 7
>  >
>  > 4. Apply loopback interface to bride-domain
>  > vpp# set interface l2 bridge loop0 10001 bvi
>  >
>  > 5.Apply sub-interface to bride-domain
>  > vpp# set interface l2 bridge VirtualFunctionEthernet0/9/0.1 
10001 0
>  >
>  > 6.Create VXLAN tunnel
>  > vpp# create vxlan tunnel src 1.1.1.1 dst 20.10.0.1 vni 10001
>  > encap-vrf-id 7 decap-next l2
>  > vpp# set interface l2 bridge vxlan_tunnel0 10001 1
>  >
>  > Regards,
>  > Satomi
>  
>  --
>  
>  
>  
>  
>

-- 
-

井上里美(Satomi Inoue)
〒180-8585 東京都武蔵野市緑町3-9-11
PHONE:0422-59-4151
E-MAIL:inoue.sat...@lab.ntt.co.jp




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

View/Reply Online (#9862): https://lists.fd.io/g/vpp-dev/message/9862
Mute This Topic: https://lists.fd.io/mt/23669118/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] [WARNING : MESSAGE ENCRYPTED] Re: [vpp] VXLAN arp response packet is dropped

[Neale Ranns via Lists.Fd.Io]

Hi Satomi,

That’s a big trace. Can you point to an example of a packet drop that is 
causing you problems.

Thanks
neale  



-Original Message-
From: 井上里美 
Date: Wednesday, 18 July 2018 at 10:58
To: "Neale Ranns (nranns)" , "vpp-dev@lists.fd.io" 

Cc: "Norimasa Asai (noasai)" , エッジ仮想化hcoML 
, 小柳達也様 , 
N転P_西岡孟朗様 
Subject: [WARNING :  MESSAGE ENCRYPTED] Re: [vpp] VXLAN arp response packet is 
dropped

Hi, neale san,

Thank you for your reply.
Sure!

Satomi

On 2018/07/18 17:27, Neale Ranns (nranns) wrote:
> Can I see the packet trace?
>
> /neale
>
> -Original Message-
> From: 井上里美 
> Date: Wednesday, 18 July 2018 at 09:54
> To: "Neale Ranns (nranns)" , "vpp-dev@lists.fd.io" 

> Cc: "Norimasa Asai (noasai)" , エッジ仮想化hcoML 
, 小柳達也様 , 
N転P_西岡孟朗様 
> Subject: [vpp] VXLAN arp response packet is dropped
>
>  Hi neale san,
>  
>  Thank you for your reply.
>  We used a vpp packet trace.
>  show trace is no error but on the caputure device,ARP request packet 
is
>  droped.
>  It happend the same event even L2.
>  
>  Could you give me some advice?
>  
>  【Architecture】
>  　 ＿＿
>  ｜　　  ｜→caputure device→IXIA(port 2)
>  ｜VPP｜
>  ｜　　　｜←IXIA(port 1)
>  ｜＿＿｜
>  
>  On 2018/07/06 21:39, Neale Ranns (nranns) wrote:
>  > Hi Satomi
>  >
>  > Debugging packet loss is much easier with a VPP packet trace…
>  >
>  > Regards,
>  > neale
>  >
>  > -Original Message-
>  > From:  on behalf of 井上里美 

>  > Date: Friday, 6 July 2018 at 12:38
>  > To: "vpp-dev@lists.fd.io" 
>  > Cc: "Norimasa Asai (noasai)" , エッジ仮想化hcoML 
, 小柳達也様 , 
N転P_西岡孟朗様 
>  > Subject: [vpp-dev] [pw] [vpp] VXLAN arp response packet is dropped
>  >
>  >  The password is here.
>  >  1j^?iKvC]C;%
>  >
>  >  On 2018/07/06 19:37, 井上里美 wrote:
>  >  > Hi VPP Team,
>  >  >
>  >  > I'm Satomi Inoue and I belong to NTT laboratories.
>  >  > Could you tell me why ARP response packet is dropped?
>  >  >
>  >  > We set up vxlan while looking at
>  >  > ”Using_VPP_as_a_VXLAN_Tunnel_Terminator”manual.
>  >  > The procedure is as follows.
>  >  >
>  >  > [The result]
>  >  > ・ARP request packet : IXIA(port2)→VPP→IXIA(port1):OK
>  >  > ・ARP response packet : IXIA(port1)→VPP→IXIA(port2):NG
>  >  > 　→We checked it by trace command. Loopback interface in VPP 
drop the
>  >  > ARP response packet.
>  >  >
>  >  > [set up vxlan]
>  >  > 1. Create sub-interface
>  >  > vpp# create sub-interfaces VirtualFunctionEthernet0/9/0 
1
>  >  > vpp# set interface state VirtualFunctionEthernet0/9/0.1 
up
>  >  >
>  >  > 2. Create bridge-domain
>  >  > create bridge-domain 10001 learn 1 forward 1 uu-flood 1 
arp-term 0
>  >  >
>  >  > 3. Create Loopback interface
>  >  > vpp# loopback create mac 1a:2b:3c:4d:5e:6f
>  >  > vpp# set interface state loop0 up
>  >  > vpp# set interface ip address loop0 1.1.1.1/32
>  >  > vpp# set interface ip table loop0 7
>  >  >
>  >  > 4. Apply loopback interface to bride-domain
>  >  > vpp# set interface l2 bridge loop0 10001 bvi
>  >  >
>  >  > 5.Apply sub-interface to bride-domain
>  >  > vpp# set interface l2 bridge 
VirtualFunctionEthernet0/9/0.1 10001 0
>  >  >
>  >  > 6.Create VXLAN tunnel
>  >  > vpp# create vxlan tunnel src 1.1.1.1 dst 20.10.0.1 vni 
10001
>  >  > encap-vrf-id 7 decap-next l2
>  >  > vpp# set interface l2 bridge vxlan_tunnel0 10001 1
>  >  >
>  >  > Regards,
>  >  > Satomi
>  >
>  >  --
>  >
>  >
>  >
>  >
>  >
>  
>  --
>  -
>  
>  井上里美(Satomi Inoue)
>  〒180-8585 東京都武蔵野市緑町3-9-11
>  PHONE:0422-59-4151
>  E-MAIL:inoue.sat...@lab.ntt.co.jp
>  
>  
>  
>

-- 
-
日本電信電話株式会社 情報ネットワーク総合研究所
ネットワークサービスシステム研究所 転送サービス基盤プロジェクト
井上里美(Satomi Inoue)
〒180-8585 東京都武蔵野市緑町3-9-11
PHONE:0422-59-4151
E-MAIL:inoue.sat...@lab.ntt.co.jp



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

View/Reply Online (#98

Re: [vpp-dev] VPP_STABLE_1710 Crash during IP Address Addition #vnet

[Neale Ranns via Lists.Fd.Io]

Hi,

I expected it was ‘fixed’ when we explicitly disallowed overlapping subnets:
  https://gerrit.fd.io/r/#/c/8057/

/neale


From:  on behalf of "sainijite...@gmail.com" 

Date: Monday, 23 July 2018 at 12:42
To: "vpp-dev@lists.fd.io" 
Subject: [vpp-dev] VPP_STABLE_1710 Crash during IP Address Addition #vnet


[Edited Message Follows]
Hello,

We are using vpp stable release 1710 and encountered vpp crash in the following 
scenario (IP Address addition) -
1. configure ip
2. configure network / broadcast ip  explicitly on same interface
Same crash behavior is observed with VPP release 1801 but issue is not seen in 
release 1804.
 Since issue was fixed between release 1801 & 1804, I wanted to find out which 
code change exactly fixes this issue.
Could someone please help to get some starting pointers here.
In summary -
If we have an issue which is fixed in some latest version of the vpp build, how 
do we track the changes which fixed the issues?

Crash scenario example  and backtrace -

-
create sub EthernetSwitch2/0/0 8
set interface ip address EthernetSwitch2/0/0.8 10.10.10.128/24 <--- valid 
address
set interface ip address EthernetSwitch2/0/0 10.10.10.0/24 <--- network 
address <<< crash

-
-
create sub EthernetSwitch2/0/0 8
set interface ip address EthernetSwitch2/0/0.8 10.10.10.128/24 <--- valid 
address
set interface ip address EthernetSwitch2/0/0 10.10.10.255/24 <--- broadcast 
address <<< crash

-
-
create sub EthernetSwitch2/0/0 8
set interface ip address EthernetSwitch2/0/0.8 10.10.10.0/24 <--- network 
address
set interface ip address EthernetSwitch2/0/0 10.10.10.255/24 <--- broadcast 
address <<< crash

-

DBGvpp# set interface ip address VirtualFunctionEthernet0/5/0 10.10.10.128/24
DBGvpp# create sub VirtualFunctionEthernet0/5/0 8
VirtualFunctionEthernet0/5/0.8
DBGvpp# set interface ip address VirtualFunctionEthernet0/5/0.8 10.10.10.0/24
0: /home/vagrant/jisaini/fdio/vpp/build-data/../src/vnet/fib/fib_path.c:2085 
(fib_path_get_adj) assertion `dpo_is_adj(&path->fp_dpo)' fails

Thread 1 "vpp_main" received signal SIGABRT, Aborted.
0x7601b428 in __GI_raise (sig=sig@entry=6) at 
../sysdeps/unix/sysv/linux/raise.c:54
54 ../sysdeps/unix/sysv/linux/raise.c: No such file or directory.
(gdb) bt
#0  0x7601b428 in __GI_raise (sig=sig@entry=6) at 
../sysdeps/unix/sysv/linux/raise.c:54
#1  0x7601d02a in __GI_abort () at abort.c:89
#2  0x00406a34 in os_panic () at 
/home/vagrant/jisaini/fdio/vpp/build-data/../src/vpp/vnet/main.c:268
#3  0x768018ff in debugger () at 
/home/vagrant/jisaini/fdio/vpp/build-data/../src/vppinfra/error.c:84
#4  0x76801d07 in _clib_error (how_to_die=2, function_name=0x0, 
line_number=0, fmt=0x7754d770 "%s:%d (%s) assertion `%s' fails") at 
/home/vagrant/jisaini/fdio/vpp/build-data/../src/vppinfra/error.c:143
#5  0x773b18ba in fib_path_get_adj (path_index=12) at 
/home/vagrant/jisaini/fdio/vpp/build-data/../src/vnet/fib/fib_path.c:2085
#6  0x773ac75a in fib_path_list_get_adj (path_list_index=12, 
type=FIB_FORW_CHAIN_TYPE_UNICAST_IP4) at 
/home/vagrant/jisaini/fdio/vpp/build-data/../src/vnet/fib/fib_path_list.c:1178
#7  0x7739edfe in fib_entry_src_interface_path_swap 
(src=0x7fffb6393cc4, entry=0x7fffb6aa6e64, pl_flags=FIB_PATH_LIST_FLAG_LOCAL, 
paths=0x7fffb62db94c) at 
/home/vagrant/jisaini/fdio/vpp/build-data/../src/vnet/fib/fib_entry_src_interface.c:69
#8  0x7739d0cd in fib_entry_src_action_path_swap 
(fib_entry=0x7fffb6aa6e64, source=FIB_SOURCE_INTERFACE, 
flags=(FIB_ENTRY_FLAG_CONNECTED | FIB_ENTRY_FLAG_LOCAL), rpaths=0x7fffb62db94c)
at 
/home/vagrant/jisaini/fdio/vpp/build-data/../src/vnet/fib/fib_entry_src.c:1205
#9  0x77399203 in fib_entry_update (fib_entry_index=8, 
source=FIB_SOURCE_INTERFACE, flags=(FIB_ENTRY_FLAG_CONNECTED | 
FIB_ENTRY_FLAG_LOCAL), paths=0x7fffb62db94c) at 
/home/vagrant/jisaini/fdio/vpp/build-data/../src/vnet/fib/fib_entry.c:1113
#10 0x7738491c in fib_table_entry_update (fib_index=0, 
prefix=0x7fffb62fe770, source=FIB_SOURCE_INTERFACE, 
flags=(FIB_ENTRY_FLAG_CONNECTED | FIB_ENTRY_FLAG_LOCAL), paths=0x7fffb62db94c)
at /home/vagrant/jisaini/fdio/vpp/build-data/../src/vnet/fib/fib_table.c:743
#11 0x77384b14 in fib_table_entry_update_one_path (fib_index=0, 
prefix=0x7fffb62fe770, source=FIB_SOURCE_INTERFACE, 
flags=(FIB_ENTRY_FLAG_CONNECTED | FIB_ENTRY_FLAG_LOCAL), 
next_hop_proto=DPO_PROTO_IP4, next_hop=0x7fffb62fe774, next_hop_sw_if_index=3,
next_hop_fib_index=4294967295, next_hop_weight=1,

Re: [vpp-dev] VPP_STABLE_1710 Crash during IP Address Addition #vnet

[Neale Ranns via Lists.Fd.Io]

Hi Jitendra,

Addresses in overlapping subnets is not supported by VPP. The configuration you 
give below is not valid.

/neale

From:  on behalf of "sainijite...@gmail.com" 

Date: Tuesday, 24 July 2018 at 07:57
To: "vpp-dev@lists.fd.io" 
Subject: Re: [vpp-dev] VPP_STABLE_1710 Crash during IP Address Addition #vnet

Hi Neale,

Thank you for the reply. I tried this patch but it blocks valid configuration 
as well.
For example -
set interface ip address EthernetSwitch2/0/0 10.10.10.33/24  <--- valid 
address
create sub EthernetSwitch2/0/0 8
set interface ip address EthernetSwitch2/0/0.8 10.10.10.66/24   <--- valid 
address but not allowed since in same subnet

Also, when i compare file "ip4_forward.c" from this patch against one in 
release 1804, the changes from this patch are not found in 1804.
release 1804 does not block overlapping subnets and crash is fixed as well. 
Unable to pin down the exact changes that went in for this.

Thanks
Jitendra



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

View/Reply Online (#9925): https://lists.fd.io/g/vpp-dev/message/9925
Mute This Topic: https://lists.fd.io/mt/23791651/21656
Mute #vnet: https://lists.fd.io/mk?hashtag=vnet&subid=1480452
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [vpp-dev] L3VPN in VPP

[Neale Ranns via Lists.Fd.Io]

Hi,

Answers inline marked [nr]

/neale

From:  on behalf of Gulakh 
Date: Saturday, 28 July 2018 at 13:45
To: "vpp-dev@lists.fd.io" 
Subject: [vpp-dev] L3VPN in VPP

Hi,
I have setup a VPLS scenario successfully and now I want to setup a L3VPN 
scenario in VPP (L3VPN topology is in attachment).

My configuration for VPLS is some how like this 
link.

As far as I searched Internet, L3VPN has a VPN Label that I think is somehow 
like PW Label in VPLS with difference that VPN Label is used to select VRF and 
PW Label is used to select mpls tunnel (hence bridge).

[nr] other label allocation schemes are available ☺

===
Part1:
I guess I should configure the source PE as follow:

 In VPLS: mpls tunnel add l2-only via  out-labels 
   ip route add  via  out-labels 


 In L3VPN: CMD1 ??? (insert in customer VRF)
 ip route add  via  out-labels 
 (insert in GLOBAL VRF)

I don't know what command I should use for CMD1 ... This command must add 
VPN-LABEL which is selected base on the customer's VRF to the packet and then 
lookup the GLOBAL VRF to push the MPLS Label. just like VPLS that the mpls 
tunnel first adds a PW Label and then in the destination IP resolution, MPLS 
Label is added to packet.

Question1: Am I right about the configurations in the source PE?


[nr] ip route table   via  out-labels 


you could use PREFIX=0.0.0.0/0 or many more specifics

and your route to the PE-TARGET would be better as a non-recursive route (i.e. 
if it is learned via e.g. OSPF and this is not an inter-AS option C) otherwise 
you’ll need another labelled route for the next-hop

non-recursive means specify the next-hop and interface.



Part2:
I guess I should configure the target PE as follow:

 In VPLS: mpls local-label add eos  via l2-input-on 

 In L3VPN: mpls local-label add eos  via ip4-lookup-in-table 
  (insert in GLOBAL VRF)

Question2: Am I right about the configurations in the target PE?

[nr] Yes. The mpls label is added to the MPLS global table, i.e. there’s no 
‘insert in global-VRF’, since the instruction associated with the label is to 
lookup the exposed IP destination address in the customer’s VRF/

=
Part3:
In order to fill customer's VRF, I should use control plane's RouteTarget (RT) 
to select the VRF ID and then use below command to fill the VRF:

  ip route add  via   table 

Question3: Am I right?

[nr] yes.

thanks in advance


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

View/Reply Online (#9970): https://lists.fd.io/g/vpp-dev/message/9970
Mute This Topic: https://lists.fd.io/mt/23840657/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] L3VPN in VPP

[Neale Ranns via Lists.Fd.Io]

Hi,

You are correct on all points.

regards
/neale

From: Holoo Gulakh 
Date: Tuesday, 31 July 2018 at 12:19
To: "Neale Ranns (nranns)" , "vpp-dev@lists.fd.io" 

Subject: Re: [vpp-dev] L3VPN in VPP

Hi,
In order to have both VPLS and L3VPN works concurrently in a PE router, I guess 
that I should do the following things:

1- Regardless of the type of service that whether it's VPLS ,L3VPN or none(e.g. 
a simple connectivity) , the core of the network works the same, that is I 
should Insert everything about the core of the network in the Global VRF i.e. 
IP FIB 0 and MPLS FIB 0 in VPP.

The above step is done before even providing any services.

2- For the PW-Label of VPLS, the task is delivered to the mpls tunnel to put 
the PW-Label on the Packet (i.e. mpls tunnel add l2-only  
out-labels) then to resolve the PE-TARGET IP address the resolution 
is done by checking the Global VRF which contains information about the core 
and at that stage the MPLS label is added to packet.

   For the VPN-Label of the L3VPN the task of putting it on the packet is 
delivered to the VRF associated with the incoming Interface (i.e. # ip route 
add   table  via  out-labels ) 
and then to resolve the NEXT-HOP IP address, Global VRF must be checked since 
the routing information about the core is stored in the Global VRF (i.e. IP FIB 
0 and MPLS FIB 0 in VPP)
but the problem is that the route store in the customer's VRF must use Global 
VRF in order to resolve its NEXT-HOP.
Searching VPP Doc, I confronted with a parameter that I can use to select which 
VRF to use to resolve the next hop.
so the # command must be modified by (ip route add  table 
 via   next-hop-table  out-labels 
) and then during the resolution of the PE-TARGET IP address the 
MPLS Labels is added to the packet.

Question: Am I right??

Excuse me for my questions ... most of the materials found in Internet are 
about Cisco commands to run the service and they give my little insights on 
what to do with lower level configurations.
Thanks in advance

On Mon, Jul 30, 2018 at 1:31 PM, Neale Ranns (nranns) 
mailto:nra...@cisco.com>> wrote:
Hi,

Answers inline marked [nr]

/neale

From: mailto:vpp-dev@lists.fd.io>> on behalf of Gulakh 
mailto:holoogul...@gmail.com>>
Date: Saturday, 28 July 2018 at 13:45
To: "vpp-dev@lists.fd.io" 
mailto:vpp-dev@lists.fd.io>>
Subject: [vpp-dev] L3VPN in VPP

Hi,
I have setup a VPLS scenario successfully and now I want to setup a L3VPN 
scenario in VPP (L3VPN topology is in attachment).

My configuration for VPLS is some how like this 
link.

As far as I searched Internet, L3VPN has a VPN Label that I think is somehow 
like PW Label in VPLS with difference that VPN Label is used to select VRF and 
PW Label is used to select mpls tunnel (hence bridge).

[nr] other label allocation schemes are available ☺

===
Part1:
I guess I should configure the source PE as follow:

 In VPLS: mpls tunnel add l2-only via  out-labels 
   ip route add  via  out-labels 


 In L3VPN: CMD1 ??? (insert in customer VRF)
 ip route add  via  out-labels 
 (insert in GLOBAL VRF)

I don't know what command I should use for CMD1 ... This command must add 
VPN-LABEL which is selected base on the customer's VRF to the packet and then 
lookup the GLOBAL VRF to push the MPLS Label. just like VPLS that the mpls 
tunnel first adds a PW Label and then in the destination IP resolution, MPLS 
Label is added to packet.

Question1: Am I right about the configurations in the source PE?


[nr] ip route table   via  out-labels 


you could use PREFIX=0.0.0.0/0 or many more specifics

and your route to the PE-TARGET would be better as a non-recursive route (i.e. 
if it is learned via e.g. OSPF and this is not an inter-AS option C) otherwise 
you’ll need another labelled route for the next-hop

non-recursive means specify the next-hop and interface.



Part2:
I guess I should configure the target PE as follow:

 In VPLS: mpls local-label add eos  via l2-input-on 

 In L3VPN: mpls local-label add eos  via ip4-lookup-in-table 
  (insert in GLOBAL VRF)

Question2: Am I right about the configurations in the target PE?

[nr] Yes. The mpls label is added to the MPLS global table, i.e. there’s no 
‘insert in global-VRF’, since the instruction associated with the label is to 
lookup the exposed IP destination address in the customer’s VRF/

=
Part3:
In order to fill customer's VRF, I should use control plane's RouteTarget (RT) 
to select the VRF ID and then use below command to fill the VRF:

  ip route add  via   table 

Question3: Am I right?

[nr] yes.

thanks in advance



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

View/R

Re: [SUSPICIOUS] [vpp-dev] L3VPN in VPP

[Neale Ranns via Lists.Fd.Io]

Hi,

Please show me:
  sh ip fib index 1 5.5.5.5/32
and
  sh ip fib index 0 192.168.23.3/32

I suspect you are missing an out-label on the latter.

/neale

From:  on behalf of Gulakh 
Date: Tuesday, 31 July 2018 at 14:53
To: "vpp-dev@lists.fd.io" 
Subject: [SUSPICIOUS] [vpp-dev] L3VPN in VPP

It seems that the Next hop IP resolution does not work correctly:
Here is my Configuration:

# set interface state GigabitEthernet4/0/0 up
# set interface state GigabitEthernet4/0/1 up

# ip table add 1   (create Customer VRF)

# set interface ip table GigabitEthernet 4/0/0 1  (Customer VRF)

# set interface ip address GigabitEthernet4/0/0 
192.168.12.2/24
  (Toward Customer)
# set interface ip address GigabitEthernet4/0/1 
192.168.23.2/24
  (Toward Core)

*** Now I want to add one of Customer's route into its VRF:
# ip route add 
5.5.5.5/32
 table 1 via 192.168.23.3 next-hop-table 0 out-labels 40

in which : 
5.5.5.5/32
 is the Customer's another site in somewhere else
   table 1 is the customer's VRF
   192.168.23.3 is the next hop which is in the core -> be resolved 
by Global VRF
   next-hop-table 0 is the Global VRF to resolve 192.168.23.3
   out-labels 40 is the VPN Label


Now When I see the VRF 1 ("show ip fib table 1"), here is the output for 
5.5.5.5/32

ipv4-VRF:1, fib_index:1, flow hash:[src dst sport dport proto ] 
locks:[src:CLI:2, ]
..
...

192.168.12.0/24
  unicast-ip4-chain
  [@0]: dpo-load-balance: [proto:ip4 index:14 buckets:1 uRPF:13 to:[0:0]]
[0] [@4]: ipv4-glean: GigabitEthernet4/0/0: mtu:9000 
a0369f23aa780806
5.5.5.5/32
  unicast-ip4-chain
  [@0]: dpo-load-balance: [proto:ip4 index:24 buckets:1 uRPF:25 to:[0:0]]
[0] [@0]: dpo-drop ip4


Here is the VRF 0:

ipv4-VRF:0, fib_index:0, flow hash:[src dst sport dport proto ] 
locks:[src:plugin-hi:2, src:default-route:1, ]
..
...

192.168.23.0/24

Re: [SUSPICIOUS] Re: [SUSPICIOUS] [vpp-dev] L3VPN in VPP

[Neale Ranns via Lists.Fd.Io]

Hi,

You probably want:
ip route add 
192.168.23.3/32
 via TenGigabitEthernet4/0/1 out-labels imp-null

given that 192.168.23.2 is directly connected. We talked before about why 
labels for resolving routes are needed. Here it is again ;)

“
If you want to resolve a recursive path that has outgoing labels, ie.
  via 1.1.1.1 out-labels 33

then the resolving route in the FIB MUST also have out-labels. This is because 
you are in effect layering LSPs (the tunnel is the upper/inner layer and the 
route the lower/outer layer). The out-label for the tunnel, provided by the 
tunnel egress device, is not necessarily directly connected to the tunnel 
ingress device. Hence, if the route did not have an out label then a device in 
between the two (that is in the lower layer) would see the label for the 
tunnel/upper layer and mis-forward.
If your two devices are directly connected and so the problem above cannot 
occur, you still need an out-label for the route, but one describes such 
directly connectivity by giving the route an implicit-null out-label, i.e.
   ip route 1.1.1.1/32  via 192.168.1.1 GigabitEthernet13/0/0 out-label imp-null

“

where you replace ‘tunnel’ with ‘recursive route’.

Regards,
nelae


From:  on behalf of Gulakh 
Date: Wednesday, 1 August 2018 at 14:03
To: "Neale Ranns (nranns)" , "vpp-dev@lists.fd.io" 

Subject: [SUSPICIOUS] Re: [SUSPICIOUS] [vpp-dev] L3VPN in VPP

Yes, that's right, the problem fixed. I should have inserted this rule : "ip 
route add 
192.168.23.3/32
 via TenGigabitEthernet4/0/1 out-labels 50"

But why doesn't work if I don't have a MPLS label for 
192.168.23.3/32
 ? suppose that the Core of the network is pure IP, no MPLS. I know that in 
L3VPN we need a MPLS enabled core but for the sake of IP resolution in another 
FIB, why does it need a second label i.e. MPLS label??

On Tue, Jul 31, 2018 at 5:54 PM, Neale Ranns (nranns) 
mailto:nra...@cisco.com>> wrote:
Hi,

Please show me:
  sh ip fib index 1 
5.5.5.5/32
and
  sh ip fib index 0 
192.168.23.3/32

I suspect you are missing an out-label on the latter.

/neale

From: mailto:vpp-dev@lists.fd.io>> on behalf of Gulakh 
mailto:holoogul...@gmail.com>>
Date: Tuesday, 31 July 2018 at 14:53
To: "vpp-dev@lists.fd.io" 
mailto:vpp-dev@lists.fd.io>>
Subject: [SUSPICIOUS] [vpp-dev] L3VPN in VPP

It seems that the Next hop IP resolution does not work correctly:
Here is my Configuration:

# set interface state GigabitEthernet4/0/0 up
# set interface state GigabitEthernet4/0/1 up

# ip table add 1   (create Customer VRF)

# set interface ip table GigabitEthernet 4/0/0 1  (Customer VRF)

# set interface ip address GigabitEthernet4/0/0 
192.168.12.2/24
   

Re: [vpp-dev] Large memory spike during make verify on ARM machine ThunderX

[Neale Ranns via Lists.Fd.Io]

Hi Juraj,

How many parallel compiles do you have? What’s the j factor

/neale



From:  on behalf of Juraj Linkeš 

Date: Wednesday, 1 August 2018 at 16:59
To: "vpp-dev@lists.fd.io" 
Subject: [vpp-dev] Large memory spike during make verify on ARM machine ThunderX

Hi vpp-devs,

I noticed that during a specific portion of make verify build on an ARM 
ThunderX machine the build consumes a lot of memory - around 25GB. I can 
identify the spot in the logs:
Jul 31 03:12:48   CXX  gbp_contract.lo

25GB memory hog

Jul 31 03:16:13   CXXLDlibvom.la

but not much else. I created a ticket which 
contains some more information. I didn't see this memory spike when trying to 
reproducing the behavior on my x86 laptop. Does anyone has any idea what could 
be the cause or how to debug this?

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

View/Reply Online (#10009): https://lists.fd.io/g/vpp-dev/message/10009
Mute This Topic: https://lists.fd.io/mt/24005970/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] Large memory spike during make verify on ARM machine ThunderX

[Neale Ranns via Lists.Fd.Io]

Hi Juraj,

I couldn’t say how much each compile ‘should’ use, but it has been noted in the 
past that these template heavy C++ files do require a lot of memory to compile. 
With the many cores you have, then that’s a lot in total.
‘make wipe’ does not clear the ccache, so any subsequent builds will require 
less memory because the compile is skipped.

/neale

From:  on behalf of Juraj Linkeš 

Date: Thursday, 2 August 2018 at 10:10
To: "Neale Ranns (nranns)" , "vpp-dev@lists.fd.io" 

Subject: Re: [vpp-dev] Large memory spike during make verify on ARM machine 
ThunderX

Hi Neale,

I'm not specifying -j, but I see a lot of processes running in parallel when 
the spike is happening. The processes are attached. They utilized most of 96 
available cores and most of them used more than 400MB - is that how much they 
should be using?

Also, here's the gcc version on the box:
gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/aarch64-linux-gnu/5/lto-wrapper
Target: aarch64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu/Linaro 
5.4.0-6ubuntu1~16.04.4' --with-bugurl=file:///usr/share/doc/gcc-5/README.Bugs 
--enable-languages=c,ada,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr 
--program-suffix=-5 --enable-shared --enable-linker-build-id 
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix 
--libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu 
--enable-libstdcxx-debug --enable-libstdcxx-time=yes 
--with-default-libstdcxx-abi=new --enable-gnu-unique-object 
--disable-libquadmath --enable-plugin --with-system-zlib 
--disable-browser-plugin --enable-java-awt=gtk --enable-gtk-cairo 
--with-java-home=/usr/lib/jvm/java-1.5.0-gcj-5-arm64/jre --enable-java-home 
--with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-5-arm64 
--with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-5-arm64 
--with-arch-directory=aarch64 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar 
--enable-multiarch --enable-fix-cortex-a53-843419 --disable-werror 
--enable-checking=release --build=aarch64-linux-gnu --host=aarch64-linux-gnu 
--target=aarch64-linux-gnu
Thread model: posix
gcc version 5.4.0 20160609 (Ubuntu/Linaro 5.4.0-6ubuntu1~16.04.4)

Thanks,
Juraj

From: Neale Ranns (nranns) [mailto:nra...@cisco.com]
Sent: Wednesday, August 1, 2018 5:09 PM
To: Juraj Linkeš ; vpp-dev@lists.fd.io
Subject: Re: [vpp-dev] Large memory spike during make verify on ARM machine 
ThunderX

Hi Juraj,

How many parallel compiles do you have? What’s the j factor

/neale



From: mailto:vpp-dev@lists.fd.io>> on behalf of Juraj 
Linkeš mailto:juraj.lin...@pantheon.tech>>
Date: Wednesday, 1 August 2018 at 16:59
To: "vpp-dev@lists.fd.io" 
mailto:vpp-dev@lists.fd.io>>
Subject: [vpp-dev] Large memory spike during make verify on ARM machine ThunderX

Hi vpp-devs,

I noticed that during a specific portion of make verify build on an ARM 
ThunderX machine the build consumes a lot of memory - around 25GB. I can 
identify the spot in the logs:
Jul 31 03:12:48   CXX  gbp_contract.lo

25GB memory hog

Jul 31 03:16:13   CXXLDlibvom.la

but not much else. I created a ticket which 
contains some more information. I didn't see this memory spike when trying to 
reproducing the behavior on my x86 laptop. Does anyone has any idea what could 
be the cause or how to debug this?

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

View/Reply Online (#10021): https://lists.fd.io/g/vpp-dev/message/10021
Mute This Topic: https://lists.fd.io/mt/24005970/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] Large memory spike during make verify on ARM machine ThunderX

[Neale Ranns via Lists.Fd.Io]

Hi Juraj,

Answers/comments inline with [nr]

Regards,
neale

From: Juraj Linkeš 
Date: Friday, 3 August 2018 at 12:45
To: "Neale Ranns (nranns)" , "vpp-dev@lists.fd.io" 

Subject: RE: [vpp-dev] Large memory spike during make verify on ARM machine 
ThunderX

Hi Neale,

Yea they do require a lot of memory - the same is true for x86. Is there a way 
to specify the max number of these? Or is that done with -j?

[nr] The j factor for a build is determined based on the number of cores your 
box has.
From build-root/Makefile

# /proc/cpuinfo does not exist on platforms without a /proc and on some
# platforms, notably inside containers, it has no content. In those cases
# we assume there's 1 processor; we use 2*ncpu for the -j option.
# NB: GNU Make 4.2 will let us use '$(file mailto:nra...@cisco.com]
Sent: Thursday, August 2, 2018 11:11 AM
To: Juraj Linkeš ; vpp-dev@lists.fd.io
Subject: Re: [vpp-dev] Large memory spike during make verify on ARM machine 
ThunderX

Hi Juraj,

I couldn’t say how much each compile ‘should’ use, but it has been noted in the 
past that these template heavy C++ files do require a lot of memory to compile. 
With the many cores you have, then that’s a lot in total.
‘make wipe’ does not clear the ccache, so any subsequent builds will require 
less memory because the compile is skipped.

/neale

From: mailto:vpp-dev@lists.fd.io>> on behalf of Juraj 
Linkeš mailto:juraj.lin...@pantheon.tech>>
Date: Thursday, 2 August 2018 at 10:10
To: "Neale Ranns (nranns)" mailto:nra...@cisco.com>>, 
"vpp-dev@lists.fd.io" 
mailto:vpp-dev@lists.fd.io>>
Subject: Re: [vpp-dev] Large memory spike during make verify on ARM machine 
ThunderX

Hi Neale,

I'm not specifying -j, but I see a lot of processes running in parallel when 
the spike is happening. The processes are attached. They utilized most of 96 
available cores and most of them used more than 400MB - is that how much they 
should be using?

Also, here's the gcc version on the box:
gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/aarch64-linux-gnu/5/lto-wrapper
Target: aarch64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu/Linaro 
5.4.0-6ubuntu1~16.04.4' --with-bugurl=file:///usr/share/doc/gcc-5/README.Bugs 
--enable-languages=c,ada,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr 
--program-suffix=-5 --enable-shared --enable-linker-build-id 
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix 
--libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu 
--enable-libstdcxx-debug --enable-libstdcxx-time=yes 
--with-default-libstdcxx-abi=new --enable-gnu-unique-object 
--disable-libquadmath --enable-plugin --with-system-zlib 
--disable-browser-plugin --enable-java-awt=gtk --enable-gtk-cairo 
--with-java-home=/usr/lib/jvm/java-1.5.0-gcj-5-arm64/jre --enable-java-home 
--with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-5-arm64 
--with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-5-arm64 
--with-arch-directory=aarch64 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar 
--enable-multiarch --enable-fix-cortex-a53-843419 --disable-werror 
--enable-checking=release --build=aarch64-linux-gnu --host=aarch64-linux-gnu 
--target=aarch64-linux-gnu
Thread model: posix
gcc version 5.4.0 20160609 (Ubuntu/Linaro 5.4.0-6ubuntu1~16.04.4)

Thanks,
Juraj

From: Neale Ranns (nranns) [mailto:nra...@cisco.com]
Sent: Wednesday, August 1, 2018 5:09 PM
To: Juraj Linkeš 
mailto:juraj.lin...@pantheon.tech>>; 
vpp-dev@lists.fd.io
Subject: Re: [vpp-dev] Large memory spike during make verify on ARM machine 
ThunderX

Hi Juraj,

How many parallel compiles do you have? What’s the j factor

/neale



From: mailto:vpp-dev@lists.fd.io>> on behalf of Juraj 
Linkeš mailto:juraj.lin...@pantheon.tech>>
Date: Wednesday, 1 August 2018 at 16:59
To: "vpp-dev@lists.fd.io" 
mailto:vpp-dev@lists.fd.io>>
Subject: [vpp-dev] Large memory spike during make verify on ARM machine ThunderX

Hi vpp-devs,

I noticed that during a specific portion of make verify build on an ARM 
ThunderX machine the build consumes a lot of memory - around 25GB. I can 
identify the spot in the logs:
Jul 31 03:12:48   CXX  gbp_contract.lo

25GB memory hog

Jul 31 03:16:13   CXXLDlibvom.la

but not much else. I created a ticket which 
contains some more information. I didn't see this memory spike when trying to 
reproducing the behavior on my x86 laptop. Does anyone has any idea what could 
be the cause or how to debug this?

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

View/Reply Online (#10031): https://lists.fd.io/g/vpp-dev/message/10031
Mute This Topic: https://lists.fd.io/mt/24005970/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] Large memory spike during make verify on ARM machine ThunderX

[Neale Ranns via Lists.Fd.Io]

The C++ language bindings are all templates. It’s the VOM compilation (that 
uses those templates) that consumes the memory. VOM is already in extras and 
these days only compiled if you do ‘make test-ext’ or ‘make ’

/neale


From: Ole Troan 
Date: Friday, 3 August 2018 at 12:51
To: Juraj Linkeš 
Cc: "Neale Ranns (nranns)" , "vpp-dev@lists.fd.io" 

Subject: Re: [vpp-dev] Large memory spike during make verify on ARM machine 
ThunderX

Move the C++ language binding to extras?

Ole

On 3 Aug 2018, at 12:45, Juraj Linkeš 
mailto:juraj.lin...@pantheon.tech>> wrote:
Hi Neale,

Yea they do require a lot of memory - the same is true for x86. Is there a way 
to specify the max number of these? Or is that done with -j?

Would it be worthwhile to investigate if it's possible to reduce the memory 
requirements of these?

Is there a way to clear the cache so that I could run make verify back to back 
without deleting and recloning the vpp repo? ccache -C didn't work for me.

Thanks,
Juraj

From: Neale Ranns (nranns) [mailto:nra...@cisco.com]
Sent: Thursday, August 2, 2018 11:11 AM
To: Juraj Linkeš 
mailto:juraj.lin...@pantheon.tech>>; 
vpp-dev@lists.fd.io
Subject: Re: [vpp-dev] Large memory spike during make verify on ARM machine 
ThunderX

Hi Juraj,

I couldn’t say how much each compile ‘should’ use, but it has been noted in the 
past that these template heavy C++ files do require a lot of memory to compile. 
With the many cores you have, then that’s a lot in total.
‘make wipe’ does not clear the ccache, so any subsequent builds will require 
less memory because the compile is skipped.

/neale

From: mailto:vpp-dev@lists.fd.io>> on behalf of Juraj 
Linkeš mailto:juraj.lin...@pantheon.tech>>
Date: Thursday, 2 August 2018 at 10:10
To: "Neale Ranns (nranns)" mailto:nra...@cisco.com>>, 
"vpp-dev@lists.fd.io" 
mailto:vpp-dev@lists.fd.io>>
Subject: Re: [vpp-dev] Large memory spike during make verify on ARM machine 
ThunderX

Hi Neale,

I'm not specifying -j, but I see a lot of processes running in parallel when 
the spike is happening. The processes are attached. They utilized most of 96 
available cores and most of them used more than 400MB - is that how much they 
should be using?

Also, here's the gcc version on the box:
gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/aarch64-linux-gnu/5/lto-wrapper
Target: aarch64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu/Linaro 
5.4.0-6ubuntu1~16.04.4' --with-bugurl=file:///usr/share/doc/gcc-5/README.Bugs 
--enable-languages=c,ada,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr 
--program-suffix=-5 --enable-shared --enable-linker-build-id 
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix 
--libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu 
--enable-libstdcxx-debug --enable-libstdcxx-time=yes 
--with-default-libstdcxx-abi=new --enable-gnu-unique-object 
--disable-libquadmath --enable-plugin --with-system-zlib 
--disable-browser-plugin --enable-java-awt=gtk --enable-gtk-cairo 
--with-java-home=/usr/lib/jvm/java-1.5.0-gcj-5-arm64/jre --enable-java-home 
--with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-5-arm64 
--with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-5-arm64 
--with-arch-directory=aarch64 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar 
--enable-multiarch --enable-fix-cortex-a53-843419 --disable-werror 
--enable-checking=release --build=aarch64-linux-gnu --host=aarch64-linux-gnu 
--target=aarch64-linux-gnu
Thread model: posix
gcc version 5.4.0 20160609 (Ubuntu/Linaro 5.4.0-6ubuntu1~16.04.4)

Thanks,
Juraj

From: Neale Ranns (nranns) [mailto:nra...@cisco.com]
Sent: Wednesday, August 1, 2018 5:09 PM
To: Juraj Linkeš 
mailto:juraj.lin...@pantheon.tech>>; 
vpp-dev@lists.fd.io
Subject: Re: [vpp-dev] Large memory spike during make verify on ARM machine 
ThunderX

Hi Juraj,

How many parallel compiles do you have? What’s the j factor

/neale



From: mailto:vpp-dev@lists.fd.io>> on behalf of Juraj 
Linkeš mailto:juraj.lin...@pantheon.tech>>
Date: Wednesday, 1 August 2018 at 16:59
To: "vpp-dev@lists.fd.io" 
mailto:vpp-dev@lists.fd.io>>
Subject: [vpp-dev] Large memory spike during make verify on ARM machine ThunderX

Hi vpp-devs,

I noticed that during a specific portion of make verify build on an ARM 
ThunderX machine the build consumes a lot of memory - around 25GB. I can 
identify the spot in the logs:
Jul 31 03:12:48   CXX  gbp_contract.lo

25GB memory hog

Jul 31 03:16:13   CXXLDlibvom.la

but not much else. I created a ticket which 
contains some more information. I didn't see this memory spike when trying to 
reproducing the behavior on my x86 laptop. Does anyone has any idea what could 
be the cause or how to debug this?

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

Re: [vpp-dev] Build: MacOS with Vagrant compiler crash in "vom"

[Neale Ranns via Lists.Fd.Io]

Hi Justin,

Not enough memory for the number of CPUs/parallel jobs.

Here’s my vagrant VM on OSx:

vagrant@ ~/vpp (master) $ free
  totalusedfree  shared  buff/cache   available
Mem:4146932 2320260  947376   16732  879296 1765252
Swap:524284   60656  463628
vagrant@ ~/vpp (master) $ cat /proc/cpuinfo | grep "model name"
model name  : Intel(R) Core(TM) i7-4770HQ CPU @ 2.20GHz
model name  : Intel(R) Core(TM) i7-4770HQ CPU @ 2.20GHz
model name  : Intel(R) Core(TM) i7-4770HQ CPU @ 2.20GHz


/neale

-Original Message-
From:  on behalf of "justin pecqueur via Lists.Fd.Io" 

Reply-To: "Justin Pecqueur (jpecqueu)" 
Date: Thursday, 9 August 2018 at 03:07
To: "vpp-dev@lists.fd.io" 
Cc: "vpp-dev@lists.fd.io" 
Subject: [vpp-dev] Build: MacOS with Vagrant compiler crash in "vom"

Hi,

I'm trying to bring up VPP on OSX using Vagrant and I keep hitting the 
following crash:

> default:  Building vom in /vpp/build-root/build-vpp-native/vom 

> default: make[3]: Entering directory 
'/vpp/build-root/build-vpp-native/vom'
> default: Making all in vom
> default: make[4]: Entering directory 
'/vpp/build-root/build-vpp-native/vom/vom'
> default:   CXX  types.lo
> default:   CXX  arp_proxy_binding_cmds.lo
> default:   CXX  arp_proxy_binding.lo
> default:   CXX  arp_proxy_config_cmds.lo
> default:   CXX  arp_proxy_config.lo
> default:   CXX  bond_group_binding_cmds.lo
> default:   CXX  bond_group_binding.lo
> default:   CXX  bond_interface_cmds.lo
> default:   CXX  bond_interface.lo
> default:   CXX  bond_member.lo
> default:   CXX  bridge_domain_cmds.lo
> default:   CXX  bridge_domain.lo
> default:   CXX  bridge_domain_arp_entry.lo
> default:   CXX  bridge_domain_arp_entry_cmds.lo
> default:   CXX  bridge_domain_entry_cmds.lo
> default:   CXX  bridge_domain_entry.lo
> default:   CXX  client_db.lo
> default:   CXX  cmd.lo
> default:   CXX  connection.lo
> default:   CXX  dhcp_client_cmds.lo
> default:   CXX  dhcp_client.lo
> default:   CXX  hw_cmds.lo
> default:   CXX  hw.lo
> default:   CXX  inspect.lo
> default:   CXX  interface_cmds.lo
> default:   CXX  interface.lo
> default:   CXX  interface_factory.lo
> default:   CXX  interface_ip6_nd_cmds.lo
> default: g++: internal compiler error: Killed (program cc1plus)
> default: Please submit a full bug report,
> default: with preprocessed source if appropriate.
> default: See  for 
instructions.
> default: Makefile:877: recipe for target 'interface.lo' failed
> default: make[4]: *** [interface.lo] Error 1
> default: make[4]: *** Waiting for unfinished jobs
> default: make[4]: Leaving directory 
'/vpp/build-root/build-vpp-native/vom/vom'
> default: Makefile:386: recipe for target 'all-recursive' failed
> default: make[3]: *** [all-recursive] Error 1
> default: make[3]: Leaving directory 
'/vpp/build-root/build-vpp-native/vom'
> default: Makefile:691: recipe for target 'vom-build' failed
> default: make[2]: *** [vom-build] Error 2
> default: make[2]: Leaving directory '/vpp/build-root'
> default: /vpp/build-data/platforms.mk:20: recipe for target 
'install-deb' failed
> default: make[1]: *** [install-deb] Error 1
> default: make[1]: Leaving directory '/vpp/build-root'
> default: Makefile:473: recipe for target 'pkg-deb' failed
> default: make: *** [pkg-deb] Error 2
> The SSH command responded with a non-zero exit status. Vagrant
> assumes that this means the command failed. The output for this command
> should be in the log above. Please read the output to determine what
> went wrong.
Any thoughts?

thanks,

--justin




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

View/Reply Online (#10081): https://lists.fd.io/g/vpp-dev/message/10081
Mute This Topic: https://lists.fd.io/mt/24235467/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] Build: MacOS with Vagrant compiler crash in "vom"

[Neale Ranns via Lists.Fd.Io]

Hi Justin,

In the master branch VOM is only built when building packages and doing ‘make 
test-ext’, i.e. for release and for its own testing. There’s no finer avoidance 
control.

/neale


-Original Message-
From: "Justin Pecqueur (jpecqueu)" 
Date: Thursday, 9 August 2018 at 15:07
To: "Neale Ranns (nranns)" , "vpp-dev@lists.fd.io" 

Subject: Re: [vpp-dev] Build: MacOS with Vagrant compiler crash in "vom"

Hi Neale,

I suspected as much seeing as how it was occurring with some C++ code which 
can be very expensive to 
compile.
Is there a way to avoid building this "vom" component?

thanks,

--justin

On 8/9/18 5:07 AM, Neale Ranns (nranns) wrote:
> Hi Justin,
>
> Not enough memory for the number of CPUs/parallel jobs.
>
> Here’s my vagrant VM on OSx:
>
> vagrant@ ~/vpp (master) $ free
>totalusedfree  shared  buff/cache   
available
> Mem:4146932 2320260  947376   16732  879296 
1765252
> Swap:524284   60656  463628
> vagrant@ ~/vpp (master) $ cat /proc/cpuinfo | grep "model name"
> model name: Intel(R) Core(TM) i7-4770HQ CPU @ 2.20GHz
> model name: Intel(R) Core(TM) i7-4770HQ CPU @ 2.20GHz
> model name: Intel(R) Core(TM) i7-4770HQ CPU @ 2.20GHz
>
>
> /neale
>
> -Original Message-
> From:  on behalf of "justin pecqueur via 
Lists.Fd.Io" 
> Reply-To: "Justin Pecqueur (jpecqueu)" 
> Date: Thursday, 9 August 2018 at 03:07
> To: "vpp-dev@lists.fd.io" 
> Cc: "vpp-dev@lists.fd.io" 
> Subject: [vpp-dev] Build: MacOS with Vagrant compiler crash in "vom"
>
>  Hi,
>  
>  I'm trying to bring up VPP on OSX using Vagrant and I keep hitting 
the following crash:
>  
>  > default:  Building vom in 
/vpp/build-root/build-vpp-native/vom 
>  > default: make[3]: Entering directory 
'/vpp/build-root/build-vpp-native/vom'
>  > default: Making all in vom
>  > default: make[4]: Entering directory 
'/vpp/build-root/build-vpp-native/vom/vom'
>  > default:   CXX  types.lo
>  > default:   CXX  arp_proxy_binding_cmds.lo
>  > default:   CXX  arp_proxy_binding.lo
>  > default:   CXX  arp_proxy_config_cmds.lo
>  > default:   CXX  arp_proxy_config.lo
>  > default:   CXX  bond_group_binding_cmds.lo
>  > default:   CXX  bond_group_binding.lo
>  > default:   CXX  bond_interface_cmds.lo
>  > default:   CXX  bond_interface.lo
>  > default:   CXX  bond_member.lo
>  > default:   CXX  bridge_domain_cmds.lo
>  > default:   CXX  bridge_domain.lo
>  > default:   CXX  bridge_domain_arp_entry.lo
>  > default:   CXX  bridge_domain_arp_entry_cmds.lo
>  > default:   CXX  bridge_domain_entry_cmds.lo
>  > default:   CXX  bridge_domain_entry.lo
>  > default:   CXX  client_db.lo
>  > default:   CXX  cmd.lo
>  > default:   CXX  connection.lo
>  > default:   CXX  dhcp_client_cmds.lo
>  > default:   CXX  dhcp_client.lo
>  > default:   CXX  hw_cmds.lo
>  > default:   CXX  hw.lo
>  > default:   CXX  inspect.lo
>  > default:   CXX  interface_cmds.lo
>  > default:   CXX  interface.lo
>  > default:   CXX  interface_factory.lo
>  > default:   CXX  interface_ip6_nd_cmds.lo
>  > default: g++: internal compiler error: Killed (program cc1plus)
>  > default: Please submit a full bug report,
>  > default: with preprocessed source if appropriate.
>  > default: See  for 
instructions.
>  > default: Makefile:877: recipe for target 'interface.lo' failed
>  > default: make[4]: *** [interface.lo] Error 1
>  > default: make[4]: *** Waiting for unfinished jobs
>  > default: make[4]: Leaving directory 
'/vpp/build-root/build-vpp-native/vom/vom'
>  > default: Makefile:386: recipe for target 'all-recursive' failed
>  > default: make[3]: *** [all-recursive] Error 1
>  > default: make[3]: Leaving directory 
'/vpp/build-root/build-vpp-native/vom'
>  > default: Makefile:691: recipe for target 'vom-build' failed
>  > default: make[2]: *** [vom-build] Error 2
>  > default: make[2]: Leaving directory '/vpp/build-root'
>  > default: /vpp/build-data/platforms.mk:20: recipe for target 
'install-deb' failed
>  > default: make[1]: *** [install-deb] Error 1
>  > default: make[1]: Leaving directory '/v

Re: [vpp-dev] Build: MacOS with Vagrant compiler crash in "vom"

[Neale Ranns via Lists.Fd.Io]

Hi Justin,

Note also you can control the number of paralle builds with:

# /proc/cpuinfo does not exist on platforms without a /proc and on some
# platforms, notably inside containers, it has no content. In those cases
# we assume there's 1 processor; we use 2*ncpu for the -j option.
# NB: GNU Make 4.2 will let us use '$(file 
Date: Thursday, 9 August 2018 at 15:07
To: "Neale Ranns (nranns)" , "vpp-dev@lists.fd.io" 

Subject: Re: [vpp-dev] Build: MacOS with Vagrant compiler crash in "vom"

Hi Neale,

I suspected as much seeing as how it was occurring with some C++ code which 
can be very expensive to 
compile.
Is there a way to avoid building this "vom" component?

thanks,

--justin

On 8/9/18 5:07 AM, Neale Ranns (nranns) wrote:
> Hi Justin,
>
> Not enough memory for the number of CPUs/parallel jobs.
>
> Here’s my vagrant VM on OSx:
>
> vagrant@ ~/vpp (master) $ free
>totalusedfree  shared  buff/cache   
available
> Mem:4146932 2320260  947376   16732  879296 
1765252
> Swap:524284   60656  463628
> vagrant@ ~/vpp (master) $ cat /proc/cpuinfo | grep "model name"
> model name: Intel(R) Core(TM) i7-4770HQ CPU @ 2.20GHz
> model name: Intel(R) Core(TM) i7-4770HQ CPU @ 2.20GHz
> model name: Intel(R) Core(TM) i7-4770HQ CPU @ 2.20GHz
>
>
> /neale
>
> -Original Message-
> From:  on behalf of "justin pecqueur via 
Lists.Fd.Io" 
> Reply-To: "Justin Pecqueur (jpecqueu)" 
> Date: Thursday, 9 August 2018 at 03:07
> To: "vpp-dev@lists.fd.io" 
> Cc: "vpp-dev@lists.fd.io" 
> Subject: [vpp-dev] Build: MacOS with Vagrant compiler crash in "vom"
>
>  Hi,
>  
>  I'm trying to bring up VPP on OSX using Vagrant and I keep hitting 
the following crash:
>  
>  > default:  Building vom in 
/vpp/build-root/build-vpp-native/vom 
>  > default: make[3]: Entering directory 
'/vpp/build-root/build-vpp-native/vom'
>  > default: Making all in vom
>  > default: make[4]: Entering directory 
'/vpp/build-root/build-vpp-native/vom/vom'
>  > default:   CXX  types.lo
>  > default:   CXX  arp_proxy_binding_cmds.lo
>  > default:   CXX  arp_proxy_binding.lo
>  > default:   CXX  arp_proxy_config_cmds.lo
>  > default:   CXX  arp_proxy_config.lo
>  > default:   CXX  bond_group_binding_cmds.lo
>  > default:   CXX  bond_group_binding.lo
>  > default:   CXX  bond_interface_cmds.lo
>  > default:   CXX  bond_interface.lo
>  > default:   CXX  bond_member.lo
>  > default:   CXX  bridge_domain_cmds.lo
>  > default:   CXX  bridge_domain.lo
>  > default:   CXX  bridge_domain_arp_entry.lo
>  > default:   CXX  bridge_domain_arp_entry_cmds.lo
>  > default:   CXX  bridge_domain_entry_cmds.lo
>  > default:   CXX  bridge_domain_entry.lo
>  > default:   CXX  client_db.lo
>  > default:   CXX  cmd.lo
>  > default:   CXX  connection.lo
>  > default:   CXX  dhcp_client_cmds.lo
>  > default:   CXX  dhcp_client.lo
>  > default:   CXX  hw_cmds.lo
>  > default:   CXX  hw.lo
>  > default:   CXX  inspect.lo
>  > default:   CXX  interface_cmds.lo
>  > default:   CXX  interface.lo
>  > default:   CXX  interface_factory.lo
>  > default:   CXX  interface_ip6_nd_cmds.lo
>  > default: g++: internal compiler error: Killed (program cc1plus)
>  > default: Please submit a full bug report,
>  > default: with preprocessed source if appropriate.
>  > default: See  for 
instructions.
>  > default: Makefile:877: recipe for target 'interface.lo' failed
>  > default: make[4]: *** [interface.lo] Error 1
>  > default: make[4]: *** Waiting for unfinished jobs
>  > default: make[4]: Leaving directory 
'/vpp/build-root/build-vpp-native/vom/vom'
>  > default: Makefile:386: recipe for target 'all-recursive' failed
>  > default: make[3]: *** [all-recursive] Error 1
>  > default: make[3]: Leaving directory 
'/vpp/build-root/build-vpp-native/vom'
>  > default: Makefile:691: recipe for target 'vom-build' failed
>  > default: make[2]: *** [vom-build] Error 2
>  > default: make[2]: Leaving directory '/vpp/build-root'
>  > default: /vpp/build-data/platforms.mk:20: recipe for target 
'install-deb' failed
>  > default: make[1]: *** [i

Re: [vpp-dev] Build: MacOS with Vagrant compiler crash in "vom"

[Neale Ranns via Lists.Fd.Io]

Hi Justin,

It’s building packages. I imagine you can still ‘vagrant ssh’ despite that 
failure and do non VOM related things. If you want to build VOM then either, 
increase the memory or decrease the number of cores of your machine, or lower 
the number of parallel jobs.

/neale

-Original Message-
From: "Justin Pecqueur (jpecqueu)" 
Date: Thursday, 9 August 2018 at 16:10
To: "Neale Ranns (nranns)" , "vpp-dev@lists.fd.io" 

Subject: Re: [vpp-dev] Build: MacOS with Vagrant compiler crash in "vom"

Hi Neale,

Here are the steps I took:
> git clone https://gerrit.fd.io/r/vpp
> cd vpp/build-root/vagrant
> source ./env.sh
> vagrant up
I assume this includes building all the packages and doing a 'make 
test-ext'?  Are there other steps 
that will allow me to build vpp, but skip building VOM, or do I have to 
start throwing more 
resources at the env?

thanks,

--justin


On 8/9/18 9:17 AM, Neale Ranns (nranns) wrote:
> Hi Justin,
>
> In the master branch VOM is only built when building packages and doing 
‘make test-ext’, i.e. for release and for its own testing. There’s no finer 
avoidance control.
>
> /neale
>
>
> -Original Message-
> From: "Justin Pecqueur (jpecqueu)" 
> Date: Thursday, 9 August 2018 at 15:07
> To: "Neale Ranns (nranns)" , "vpp-dev@lists.fd.io" 

> Subject: Re: [vpp-dev] Build: MacOS with Vagrant compiler crash in "vom"
>
>  Hi Neale,
>  
>  I suspected as much seeing as how it was occurring with some C++ 
code which can be very expensive to
>  compile.
>  Is there a way to avoid building this "vom" component?
>  
>  thanks,
>  
>  --justin
>  
>  On 8/9/18 5:07 AM, Neale Ranns (nranns) wrote:
>  > Hi Justin,
>  >
>  > Not enough memory for the number of CPUs/parallel jobs.
>  >
>  > Here’s my vagrant VM on OSx:
>  >
>  > vagrant@ ~/vpp (master) $ free
>  >totalusedfree  shared  
buff/cache   available
>  > Mem:4146932 2320260  947376   16732  
879296 1765252
>  > Swap:524284   60656  463628
>  > vagrant@ ~/vpp (master) $ cat /proc/cpuinfo | grep "model name"
>  > model name : Intel(R) Core(TM) i7-4770HQ CPU @ 2.20GHz
>  > model name : Intel(R) Core(TM) i7-4770HQ CPU @ 2.20GHz
>  > model name : Intel(R) Core(TM) i7-4770HQ CPU @ 2.20GHz
>  >
>  >
>  > /neale
>  >
>  > -Original Message-
>  > From:  on behalf of "justin pecqueur via 
Lists.Fd.Io" 
>  > Reply-To: "Justin Pecqueur (jpecqueu)" 
>  > Date: Thursday, 9 August 2018 at 03:07
>  > To: "vpp-dev@lists.fd.io" 
>  > Cc: "vpp-dev@lists.fd.io" 
>  > Subject: [vpp-dev] Build: MacOS with Vagrant compiler crash in 
"vom"
>  >
>  >  Hi,
>  >
>  >  I'm trying to bring up VPP on OSX using Vagrant and I keep 
hitting the following crash:
>  >
>  >  > default:  Building vom in 
/vpp/build-root/build-vpp-native/vom 
>  >  > default: make[3]: Entering directory 
'/vpp/build-root/build-vpp-native/vom'
>  >  > default: Making all in vom
>  >  > default: make[4]: Entering directory 
'/vpp/build-root/build-vpp-native/vom/vom'
>  >  > default:   CXX  types.lo
>  >  > default:   CXX  arp_proxy_binding_cmds.lo
>  >  > default:   CXX  arp_proxy_binding.lo
>  >  > default:   CXX  arp_proxy_config_cmds.lo
>  >  > default:   CXX  arp_proxy_config.lo
>  >  > default:   CXX  bond_group_binding_cmds.lo
>  >  > default:   CXX  bond_group_binding.lo
>  >  > default:   CXX  bond_interface_cmds.lo
>  >  > default:   CXX  bond_interface.lo
>  >  > default:   CXX  bond_member.lo
>  >  > default:   CXX  bridge_domain_cmds.lo
>  >  > default:   CXX  bridge_domain.lo
>  >  > default:   CXX  bridge_domain_arp_entry.lo
>  >  > default:   CXX  bridge_domain_arp_entry_cmds.lo
>  >  > default:   CXX  bridge_domain_entry_cmds.lo
>  >  > default:   CXX  bridge_domain_entry.lo
>  >  > default:   CXX  client_db.lo
>  >  > default:   CXX  cmd.lo
>  >  > default:   CXX  connection.lo
>  >  > default:   CXX  dhcp_client_cmds.lo
>  >  > default:   CXX  dhcp_client.lo
>  >  > default:   CXX  hw_cmds.lo
>  >  > default

Re: [vpp-dev] Cavium ThunderX (ARM64) - Crash in VPP (Kubernetes + Contiv-VPP network plugin)

[Neale Ranns via Lists.Fd.Io]

Hi Stan,

What route were you adding at the time? Can you give me the post-mortem API 
dump [1]

/neale

[1] see https://wiki.fd.io/view/VPP/BugReports


From:  on behalf of Stanislav Chlebec 

Date: Tuesday, 21 August 2018 at 16:41
To: Nitin Saxena , "vpp-dev@lists.fd.io" 

Subject: [vpp-dev] Cavium ThunderX (ARM64) - Crash in VPP (Kubernetes + 
Contiv-VPP network plugin)

Hello all

Could you please help mi with this issue:
https://jira.fd.io/browse/VPP-1394

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

View/Reply Online (#10236): https://lists.fd.io/g/vpp-dev/message/10236
Mute This Topic: https://lists.fd.io/mt/24876710/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] Source Based Routing #vpp

[Neale Ranns via Lists.Fd.Io]

Hi Georgi,

Are you asking for this:
  https://www.cisco.com/c/en/us/td/docs/ios/12_0s/feature/guide/vrfselec.html

we don’t support this feature specifically (i.e. a simple IP source based 
lookup as an input feature, though it would be easy to add) but we do support 
the more general case of ACL/policy based routing – which is similar to linux’s 
ip rule.
  https://wiki.fd.io/view/VPP/ABF

hth
/neale


From:  on behalf of "georgi.mel...@gmail.com" 

Date: Monday, 27 August 2018 at 07:28
To: "vpp-dev@lists.fd.io" 
Subject: [vpp-dev] Source Based Routing #vpp

Hi VPP experts,

I would like to shed light on a particular scenario/usecase that I'm trying to 
implement in VPP.

The scenario demands egress packet routing to be done based on the source IP of 
the packet rather than the destination IP. I found a similar discussion in the 
VPP mail 
archive(https://www.mail-archive.com/vpp-dev@lists.fd.io/msg06886.html), but 
the solution discussed there would not be applicable for routing multiple 
source IP packets having different routes.

I understand that we can configure multiple routing table in VPP with unique 
routes in them, but would I be able to make the FIB lookup towards a particular 
table based on source IP?

If I take an analogy from Linux kernel, does VPP support functionality similar 
to 'ip rule' command, wherein we can specify a routing table to be used for a 
particular source IP.

Looking forward to your advice and support in finding a solution to this.

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

View/Reply Online (#10290): https://lists.fd.io/g/vpp-dev/message/10290
Mute This Topic: https://lists.fd.io/mt/24970841/21656
Mute #vpp: https://lists.fd.io/mk?hashtag=vpp&subid=1480452
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [vpp-dev] IGMP enable issue

[Neale Ranns via Lists.Fd.Io]

Hi Aleksander,

To you want VPP to act like a host or a router?

/neale


From:  on behalf of Aleksander Djuric 

Date: Monday, 27 August 2018 at 10:39
To: "vpp-dev@lists.fd.io" 
Subject: [vpp-dev] IGMP enable issue

Hello,

I am trying to configure VPP for IGMP, but with this configuration it seems 
doesn't work:

vpp# igmp listen enable int GigabitEthernet0/3/0
vpp# sh igmp config
vpp# trace add dpdk-input 10
vpp# sh trace
16:38:35:357591: dpdk-input
  GigabitEthernet0/3/0 rx queue 0
  buffer 0x3666: current data 14, length 46, free-list 0, clone-count 0, 
totlen-nifb 0, trace 0x0
 ext-hdr-valid
 l4-cksum-computed l4-cksum-correct l2-hdr-offset 0
  PKT MBUF: port 1, nb_segs 1, pkt_len 60
buf_len 2176, data_len 60, ol_flags 0x0, data_off 128, phys_addr 0x928d9a00
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: 00:50:06:00:03:00 -> 01:00:5e:00:00:16
  IGMP: 172.16.1.1 -> 224.0.0.22
version 4, header length 24
tos 0xc0, ttl 1, length 40, checksum 0x57e2
fragment id 0x, flags DONT_FRAGMENT
16:38:35:357630: ip4-input
  IGMP: 172.16.1.1 -> 224.0.0.22
version 4, header length 24
tos 0xc0, ttl 1, length 40, checksum 0x57e2
fragment id 0x, flags DONT_FRAGMENT
16:38:35:357648: ip4-options
option:[0x94,0x4,0x0,0x0]
16:38:35:357649: ip4-local
IGMP: 172.16.1.1 -> 224.0.0.22
  version 4, header length 24
  tos 0xc0, ttl 1, length 40, checksum 0x57e2
  fragment id 0x, flags DONT_FRAGMENT
16:38:35:357657: igmp-input
  sw_if_index 2 next-index 0
  membership_report_v3: code 0, checksum 0xeaec
16:38:35:357660: error-drop
  igmp-input: IGMP not enabled on this interface

Source host: Linux a 4.9.0-6-amd64 #1 SMP Debian 4.9.88-1+deb9u1 (2018-05-07) 
x86_64 GNU/Linux, IP 172.16.1.1
Target: VPP v18.10-rc0~248-g4553c95a on VM, compiled with GCC 6.3.0 20170516, 
IP 172.16.1.2
Multicast group address: 224.0.0.22

As you can see, the command "sh igmp config" shows nothing, and trace is 
reported error: IGMP not enabled on this interface.

Could you help me with this?  Thanks a lot.

Regards,
Aleksander


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

View/Reply Online (#10291): https://lists.fd.io/g/vpp-dev/message/10291
Mute This Topic: https://lists.fd.io/mt/24971765/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 hangs on GRE interface going up

[Neale Ranns via Lists.Fd.Io]

Hi Fedor,

You have exposed a bug. Thanks.
Please re-test including:
   https://gerrit.fd.io/r/#/c/14504/

/neale


From:  on behalf of Fedor Kazmin 
Date: Monday, 27 August 2018 at 13:25
To: "vpp-dev@lists.fd.io" 
Subject: [vpp-dev] VPP hangs on GRE interface going up


Hello, all

I have got an issue with MPLS-o-GRE encapsulation, need some help.
VPP hangs on GRE interface going up.
Both stable/1804 and master, Ubuntu Xenial, gcc 5.4.0

Steps to reproduce:
1. Create and configure veth pair
ip link add name veth0 type veth peer name vpp0
ip link set dev vpp0 up
ip link set dev veth0 up
ip addr add 172.16.0.1/24 dev veth0

2. Run VPP and configure a tunnel
DBGvpp# sh ver
vpp v18.10-rc0~248-g4553c95 built by kahzeemin on kahzeemin-nix at Mon Aug 27 
12:57:07 MSK 2018

DBGvpp# create host name vpp0
host-vpp0

DBGvpp# set int state host-vpp0 up
DBGvpp# set int ip addr host-vpp0 172.16.0.2/24
DBGvpp# create gre tun src 172.16.0.2 dst 172.16.0.1
gre0

DBGvpp# ip route add 10.0.0.1/32 via gre0 out-labels 100
DBGvpp# sh ip fib 10.0.0.1
ipv4-VRF:0, fib_index:0, flow hash:[src dst sport dport proto ] 
locks:[src:plugin-hi:2, src:adjacency:1, src:default-route:1, ]
10.0.0.1/32 fib:0 index:12 locks:2
  src:CLI refs:1 entry-flags:attached, src-flags:added,contributing,active,
path-list:[14] locks:2 flags:shared, uPRF-list:12 len:1 itfs:[2, ]
  path:[14] pl-index:14 ip4 weight=1 pref=0 attached-nexthop: 
cfg-flags:attached,
10.0.0.1 gre0 (p2p)
  [@0]: ipv4 via 0.0.0.0 gre0: mtu:9000 
4500fe2f64abac12ac110800
 stacked-on:
   [@0]: dpo-drop ip4
Extensions:
 path:14  labels:[[100 pipe ttl:0 exp:0]]
 forwarding:   unicast-ip4-chain
  [@0]: dpo-load-balance: [proto:ip4 index:14 buckets:1 uRPF:12 to:[0:0]]
[0] [@0]: dpo-drop ip4

DBGvpp# set int state gre0 up
/*VPP becomes unresponive*/


Thank you in advance,
Fedor
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#10297): https://lists.fd.io/g/vpp-dev/message/10297
Mute This Topic: https://lists.fd.io/mt/24972486/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] IGMP enable issue

[Neale Ranns via Lists.Fd.Io]

Hi Aleksander,

The API required to enable router mode did not have a CLI equivalent. I have 
added it in :
  https://gerrit.fd.io/r/#/c/14507/

now do:
  igmp enable router 
when done
  igmp disable router 

/neale


From:  on behalf of Aleksander Djuric 

Date: Monday, 27 August 2018 at 12:28
To: "vpp-dev@lists.fd.io" 
Subject: Re: [vpp-dev] IGMP enable issue


[Edited Message Follows]
Hi Neale,

Thank you for quick answer.
I want to configure VPP like a router.

Maybe it can help:
The function igmp_listen always returns VNET_API_ERROR_INVALID_INTERFACE error, 
because igmp_config_lookup returns null.
The code comments says that the reason is that the interface is not IGMP 
enabled.
If it's true - how I can to configure IGMP enabled interface?

Thanks in advance for any help,
Aleksander

On Mon, Aug 27, 2018 at 12:59 PM, Neale Ranns wrote:

Hi Aleksander,



To you want VPP to act like a host or a router?



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

View/Reply Online (#10298): https://lists.fd.io/g/vpp-dev/message/10298
Mute This Topic: https://lists.fd.io/mt/24971765/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] discarding label in ipv4 FIB.

[Neale Ranns via Lists.Fd.Io]

Hi,

Label value is, incorrectly IMO, not a valid out-put label.

See:
  https://gerrit.fd.io/r/#/c/14508/
for a fix.

Thanks,
Neale


From:  on behalf of "abbas ali chezgi via Lists.Fd.Io" 

Reply-To: "che...@yahoo.com" 
Date: Monday, 27 August 2018 at 13:05
To: "vpp-dev@lists.fd.io" 
Cc: "vpp-dev@lists.fd.io" 
Subject: [vpp-dev] discarding label in ipv4 FIB.

i used  fib_table_entry_path_add2 function for adding entry to ipv4 fib but in 
some nodes it discards mpls labels.

discard sample:
---

ipv4-VRF:0, fib_index:0, flow hash:[src dst sport dport proto ] 
locks:[src:plugin-hi:2, src:adjacency:1, src:default-route:1, ]
1.1.1.0/24 fib:0 index:32 locks:2
  src:API refs:1 src-flags:added,contributing,active,
path-list:[50] locks:20 flags:shared, uPRF-list:49 len:1 itfs:[2, ]
  path:[54] pl-index:50 ip4 weight=1 pref=0 attached-nexthop:  
oper-flags:resolved,
200.2.3.2 host-eth1
  [@0]: ipv4 via 200.2.3.2 host-eth1: mtu:9000 02feaa73323f02fe77a26dec0800
Extensions:
 path:54  labels:[[16 pipe ttl:0 exp:0]]
 forwarding:   unicast-ip4-chain
  [@0]: dpo-load-balance: [proto:ip4 index:35 buckets:1 uRPF:49 to:[0:0]]
[0] [@5]: ipv4 via 200.2.3.2 host-eth1: mtu:9000 
02feaa73323f02fe77a26dec0800


working sample:
---
ipv4-VRF:0, fib_index:0, flow hash:[src dst sport dport proto ] 
locks:[src:plugin-hi:2, src:adjacency:1, src:default-route:1, ]
3.1.1.0/24 fib:0 index:35 locks:2
  src:API refs:1 src-flags:added,contributing,active,
path-list:[50] locks:20 flags:shared, uPRF-list:49 len:1 itfs:[1, ]
  path:[54] pl-index:50 ip4 weight=1 pref=0 attached-nexthop:  
oper-flags:resolved,
200.1.2.2 host-eth0
  [@0]: ipv4 via 200.1.2.2 host-eth0: mtu:9000 02fe7f1fa8d902feb93db6450800
Extensions:
 path:54  labels:[[19 pipe ttl:0 exp:0]]


 forwarding:   unicast-ip4-chain
  [@0]: dpo-load-balance: [proto:ip4 index:38 buckets:1 uRPF:49 to:[0:0]]
[0] [@11]: mpls-label[2]:[19:64:0:eos]
[@1]: mpls via 200.1.2.2 host-eth0: mtu:9000 
02fe7f1fa8d902feb93db6458847



when this happens? how can i correct this?

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

View/Reply Online (#10300): https://lists.fd.io/g/vpp-dev/message/10300
Mute This Topic: https://lists.fd.io/mt/24972400/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] discarding label in ipv4 FIB.

[Neale Ranns via Lists.Fd.Io]

[fix missing information]

Hi,

Label value 16 is, incorrectly IMO, not a valid out-put label.

See:
  https://gerrit.fd.io/r/#/c/14508/
for a fix.

Thanks,
/neale

From:  on behalf of "Neale Ranns via Lists.Fd.Io" 

Reply-To: "Neale Ranns (nranns)" 
Date: Monday, 27 August 2018 at 16:58
To: "che...@yahoo.com" , "vpp-dev@lists.fd.io" 

Cc: "vpp-dev@lists.fd.io" 
Subject: Re: [vpp-dev] discarding label in ipv4 FIB.

Hi,

Label value is, incorrectly IMO, not a valid out-put label.

See:
  https://gerrit.fd.io/r/#/c/14508/
for a fix.

Thanks,
Neale


From:  on behalf of "abbas ali chezgi via Lists.Fd.Io" 

Reply-To: "che...@yahoo.com" 
Date: Monday, 27 August 2018 at 13:05
To: "vpp-dev@lists.fd.io" 
Cc: "vpp-dev@lists.fd.io" 
Subject: [vpp-dev] discarding label in ipv4 FIB.

i used  fib_table_entry_path_add2 function for adding entry to ipv4 fib but in 
some nodes it discards mpls labels.

discard sample:
---

ipv4-VRF:0, fib_index:0, flow hash:[src dst sport dport proto ] 
locks:[src:plugin-hi:2, src:adjacency:1, src:default-route:1, ]
1.1.1.0/24 fib:0 index:32 locks:2
  src:API refs:1 src-flags:added,contributing,active,
path-list:[50] locks:20 flags:shared, uPRF-list:49 len:1 itfs:[2, ]
  path:[54] pl-index:50 ip4 weight=1 pref=0 attached-nexthop:  
oper-flags:resolved,
200.2.3.2 host-eth1
  [@0]: ipv4 via 200.2.3.2 host-eth1: mtu:9000 02feaa73323f02fe77a26dec0800
Extensions:
 path:54  labels:[[16 pipe ttl:0 exp:0]]
 forwarding:   unicast-ip4-chain
  [@0]: dpo-load-balance: [proto:ip4 index:35 buckets:1 uRPF:49 to:[0:0]]
[0] [@5]: ipv4 via 200.2.3.2 host-eth1: mtu:9000 
02feaa73323f02fe77a26dec0800


working sample:
---
ipv4-VRF:0, fib_index:0, flow hash:[src dst sport dport proto ] 
locks:[src:plugin-hi:2, src:adjacency:1, src:default-route:1, ]
3.1.1.0/24 fib:0 index:35 locks:2
  src:API refs:1 src-flags:added,contributing,active,
path-list:[50] locks:20 flags:shared, uPRF-list:49 len:1 itfs:[1, ]
  path:[54] pl-index:50 ip4 weight=1 pref=0 attached-nexthop:  
oper-flags:resolved,
200.1.2.2 host-eth0
  [@0]: ipv4 via 200.1.2.2 host-eth0: mtu:9000 02fe7f1fa8d902feb93db6450800
Extensions:
 path:54  labels:[[19 pipe ttl:0 exp:0]]


 forwarding:   unicast-ip4-chain
  [@0]: dpo-load-balance: [proto:ip4 index:38 buckets:1 uRPF:49 to:[0:0]]
[0] [@11]: mpls-label[2]:[19:64:0:eos]
[@1]: mpls via 200.1.2.2 host-eth0: mtu:9000 
02fe7f1fa8d902feb93db6458847



when this happens? how can i correct this?

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

View/Reply Online (#10301): https://lists.fd.io/g/vpp-dev/message/10301
Mute This Topic: https://lists.fd.io/mt/24972400/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] IGMP enable issue

[Neale Ranns via Lists.Fd.Io]

Hi Aleksander,

It’s not top of my TODO list right now. Your additions would be most welcome.

/neale


From:  on behalf of Aleksander Djuric 

Date: Tuesday, 28 August 2018 at 14:41
To: "vpp-dev@lists.fd.io" 
Subject: Re: [vpp-dev] IGMP enable issue

In addition to my previous message...

Unfortunatelly it's not work for me (
I need IGMPv2 support.. and I have found this comment:

/* TODO: IGMPv2 and IGMPv1 */

Is it in your nearest plans?

Certainly I also will try to do something by myself..
Regards,
Aleksander
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#10318): https://lists.fd.io/g/vpp-dev/message/10318
Mute This Topic: https://lists.fd.io/mt/24971765/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] vlib_buffer_t clone operation

[Neale Ranns via Lists.Fd.Io]

Hi Eason,

There’s
  vlib_buffer_clone()

it’s use in IP multicast can be found here:
  replicate_inline (…)
and in L2 multicast here:
   l2flood_node_fn(…)

/neale


-Original Message-
From:  on behalf of Eason Chen 

Reply-To: Eason Chen 
Date: Monday, 3 September 2018 at 04:12
To: vpp-dev 
Subject: [vpp-dev] vlib_buffer_t clone operation

Hi VPP Gurus,

I am trying to deep dive vlib_buffer_t operations but cannot find a clone 
operation,
could anyone elaborate this the reason why clone is not supported or I 
missed anything obvious?
My assumption is that there should be some use cases for a packet clone, 
e.g. multicast...

Thanks,
Eason

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

View/Reply Online (#10343): https://lists.fd.io/g/vpp-dev/message/10343
Mute This Topic: https://lists.fd.io/mt/25161404/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] Cavium ThunderX (ARM64) - Crash in VPP (Kubernetes + Contiv-VPP network plugin)

[Neale Ranns via Lists.Fd.Io]

Hi Stan,

Unfortunately I don’t have an ARM machine on to decode the post-mortem data. 
Could you do this?

Thanks,
Neale


From: Stanislav Chlebec 
Date: Tuesday, 4 September 2018 at 11:06
To: Stanislav Chlebec , "Neale Ranns (nranns)" 
, "vpp-dev@lists.fd.io" 
Subject: RE: [vpp-dev] Cavium ThunderX (ARM64) - Crash in VPP (Kubernetes + 
Contiv-VPP network plugin)

Hi Neale
Have you had the occasion to look at that api_post_mortem data?
Have you found the reason of crash?
Thanks
Stan


From: Stanislav Chlebec [mailto:stanislav.chle...@pantheon.tech]
Sent: Wednesday, August 22, 2018 3:39 PM
To: Neale Ranns (nranns) ; vpp-dev@lists.fd.io
Subject: Re: [vpp-dev] Cavium ThunderX (ARM64) - Crash in VPP (Kubernetes + 
Contiv-VPP network plugin)

Hi Neale
I attached the file api_post_mortem.43407
to the  issue https://jira.fd.io/browse/VPP-1394
Thanks
Stan

From: Neale Ranns (nranns) [mailto:nra...@cisco.com]
Sent: Tuesday, August 21, 2018 5:02 PM
To: Stanislav Chlebec 
mailto:stanislav.chle...@pantheon.tech>>; 
Nitin Saxena mailto:nitin.sax...@cavium.com>>; 
vpp-dev@lists.fd.io
Subject: Re: [vpp-dev] Cavium ThunderX (ARM64) - Crash in VPP (Kubernetes + 
Contiv-VPP network plugin)

Hi Stan,

What route were you adding at the time? Can you give me the post-mortem API 
dump [1]

/neale

[1] see https://wiki.fd.io/view/VPP/BugReports


From: mailto:vpp-dev@lists.fd.io>> on behalf of Stanislav 
Chlebec 
mailto:stanislav.chle...@pantheon.tech>>
Date: Tuesday, 21 August 2018 at 16:41
To: Nitin Saxena mailto:nitin.sax...@cavium.com>>, 
"vpp-dev@lists.fd.io" 
mailto:vpp-dev@lists.fd.io>>
Subject: [vpp-dev] Cavium ThunderX (ARM64) - Crash in VPP (Kubernetes + 
Contiv-VPP network plugin)

Hello all

Could you please help mi with this issue:
https://jira.fd.io/browse/VPP-1394

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

View/Reply Online (#10349): https://lists.fd.io/g/vpp-dev/message/10349
Mute This Topic: https://lists.fd.io/mt/24876710/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] Cavium ThunderX (ARM64) - Crash in VPP (Kubernetes + Contiv-VPP network plugin)

[Neale Ranns via Lists.Fd.Io]

On the exact same version of VPP that produced the crash do:
  api trace custom-dump /path/to/trace/flie.txt

/neale


From: Stanislav Chlebec 
Date: Wednesday, 5 September 2018 at 13:24
To: "Neale Ranns (nranns)" , "vpp-dev@lists.fd.io" 

Subject: RE: [vpp-dev] Cavium ThunderX (ARM64) - Crash in VPP (Kubernetes + 
Contiv-VPP network plugin)

Hi Neale
Could you please describe, how to do it?
Thanks
Stan

From: Neale Ranns (nranns) [mailto:nra...@cisco.com]
Sent: Tuesday, September 4, 2018 3:27 PM
To: Stanislav Chlebec ; vpp-dev@lists.fd.io
Subject: Re: [vpp-dev] Cavium ThunderX (ARM64) - Crash in VPP (Kubernetes + 
Contiv-VPP network plugin)

Hi Stan,

Unfortunately I don’t have an ARM machine on to decode the post-mortem data. 
Could you do this?

Thanks,
Neale


From: Stanislav Chlebec 
mailto:stanislav.chle...@pantheon.tech>>
Date: Tuesday, 4 September 2018 at 11:06
To: Stanislav Chlebec 
mailto:stanislav.chle...@pantheon.tech>>, 
"Neale Ranns (nranns)" mailto:nra...@cisco.com>>, 
"vpp-dev@lists.fd.io" 
mailto:vpp-dev@lists.fd.io>>
Subject: RE: [vpp-dev] Cavium ThunderX (ARM64) - Crash in VPP (Kubernetes + 
Contiv-VPP network plugin)

Hi Neale
Have you had the occasion to look at that api_post_mortem data?
Have you found the reason of crash?
Thanks
Stan


From: Stanislav Chlebec [mailto:stanislav.chle...@pantheon.tech]
Sent: Wednesday, August 22, 2018 3:39 PM
To: Neale Ranns (nranns) mailto:nra...@cisco.com>>; 
vpp-dev@lists.fd.io
Subject: Re: [vpp-dev] Cavium ThunderX (ARM64) - Crash in VPP (Kubernetes + 
Contiv-VPP network plugin)

Hi Neale
I attached the file api_post_mortem.43407
to the  issue https://jira.fd.io/browse/VPP-1394
Thanks
Stan

From: Neale Ranns (nranns) [mailto:nra...@cisco.com]
Sent: Tuesday, August 21, 2018 5:02 PM
To: Stanislav Chlebec 
mailto:stanislav.chle...@pantheon.tech>>; 
Nitin Saxena mailto:nitin.sax...@cavium.com>>; 
vpp-dev@lists.fd.io
Subject: Re: [vpp-dev] Cavium ThunderX (ARM64) - Crash in VPP (Kubernetes + 
Contiv-VPP network plugin)

Hi Stan,

What route were you adding at the time? Can you give me the post-mortem API 
dump [1]

/neale

[1] see https://wiki.fd.io/view/VPP/BugReports


From: mailto:vpp-dev@lists.fd.io>> on behalf of Stanislav 
Chlebec 
mailto:stanislav.chle...@pantheon.tech>>
Date: Tuesday, 21 August 2018 at 16:41
To: Nitin Saxena mailto:nitin.sax...@cavium.com>>, 
"vpp-dev@lists.fd.io" 
mailto:vpp-dev@lists.fd.io>>
Subject: [vpp-dev] Cavium ThunderX (ARM64) - Crash in VPP (Kubernetes + 
Contiv-VPP network plugin)

Hello all

Could you please help mi with this issue:
https://jira.fd.io/browse/VPP-1394

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

View/Reply Online (#10369): https://lists.fd.io/g/vpp-dev/message/10369
Mute This Topic: https://lists.fd.io/mt/24876710/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] Cavium ThunderX (ARM64) - Crash in VPP (Kubernetes + Contiv-VPP network plugin)

[Neale Ranns via Lists.Fd.Io]

Hi Stan,

Thanks for the decode.

Given that I cannot analyse your core, I cannot be sure why the crash occurred. 
But I do notice when using the route type we see in the trace in a new unit 
test that it doesn’t produce the correct result. Here is the patch:
  https://gerrit.fd.io/r/#/c/14714/
maybe it will fix your crash too.

Regards
Neale


From: Stanislav Chlebec 
Date: Thursday, 6 September 2018 at 11:00
To: "Neale Ranns (nranns)" , "vpp-dev@lists.fd.io" 

Subject: RE: [vpp-dev] Cavium ThunderX (ARM64) - Crash in VPP (Kubernetes + 
Contiv-VPP network plugin)

Thans for advice.
Here is the result:
https://gist.github.com/stanislav-chlebec/7466935c41b60eb23ea711f6a4fcafeb

Stan
From: Neale Ranns (nranns) [mailto:nra...@cisco.com]
Sent: Wednesday, September 5, 2018 1:58 PM
To: Stanislav Chlebec ; vpp-dev@lists.fd.io
Subject: Re: [vpp-dev] Cavium ThunderX (ARM64) - Crash in VPP (Kubernetes + 
Contiv-VPP network plugin)

On the exact same version of VPP that produced the crash do:
  api trace custom-dump /path/to/trace/flie.txt

/neale


From: Stanislav Chlebec 
mailto:stanislav.chle...@pantheon.tech>>
Date: Wednesday, 5 September 2018 at 13:24
To: "Neale Ranns (nranns)" mailto:nra...@cisco.com>>, 
"vpp-dev@lists.fd.io" 
mailto:vpp-dev@lists.fd.io>>
Subject: RE: [vpp-dev] Cavium ThunderX (ARM64) - Crash in VPP (Kubernetes + 
Contiv-VPP network plugin)

Hi Neale
Could you please describe, how to do it?
Thanks
Stan

From: Neale Ranns (nranns) [mailto:nra...@cisco.com]
Sent: Tuesday, September 4, 2018 3:27 PM
To: Stanislav Chlebec 
mailto:stanislav.chle...@pantheon.tech>>; 
vpp-dev@lists.fd.io
Subject: Re: [vpp-dev] Cavium ThunderX (ARM64) - Crash in VPP (Kubernetes + 
Contiv-VPP network plugin)

Hi Stan,

Unfortunately I don’t have an ARM machine on to decode the post-mortem data. 
Could you do this?

Thanks,
Neale


From: Stanislav Chlebec 
mailto:stanislav.chle...@pantheon.tech>>
Date: Tuesday, 4 September 2018 at 11:06
To: Stanislav Chlebec 
mailto:stanislav.chle...@pantheon.tech>>, 
"Neale Ranns (nranns)" mailto:nra...@cisco.com>>, 
"vpp-dev@lists.fd.io" 
mailto:vpp-dev@lists.fd.io>>
Subject: RE: [vpp-dev] Cavium ThunderX (ARM64) - Crash in VPP (Kubernetes + 
Contiv-VPP network plugin)

Hi Neale
Have you had the occasion to look at that api_post_mortem data?
Have you found the reason of crash?
Thanks
Stan


From: Stanislav Chlebec [mailto:stanislav.chle...@pantheon.tech]
Sent: Wednesday, August 22, 2018 3:39 PM
To: Neale Ranns (nranns) mailto:nra...@cisco.com>>; 
vpp-dev@lists.fd.io
Subject: Re: [vpp-dev] Cavium ThunderX (ARM64) - Crash in VPP (Kubernetes + 
Contiv-VPP network plugin)

Hi Neale
I attached the file api_post_mortem.43407
to the  issue https://jira.fd.io/browse/VPP-1394
Thanks
Stan

From: Neale Ranns (nranns) [mailto:nra...@cisco.com]
Sent: Tuesday, August 21, 2018 5:02 PM
To: Stanislav Chlebec 
mailto:stanislav.chle...@pantheon.tech>>; 
Nitin Saxena mailto:nitin.sax...@cavium.com>>; 
vpp-dev@lists.fd.io
Subject: Re: [vpp-dev] Cavium ThunderX (ARM64) - Crash in VPP (Kubernetes + 
Contiv-VPP network plugin)

Hi Stan,

What route were you adding at the time? Can you give me the post-mortem API 
dump [1]

/neale

[1] see https://wiki.fd.io/view/VPP/BugReports


From: mailto:vpp-dev@lists.fd.io>> on behalf of Stanislav 
Chlebec 
mailto:stanislav.chle...@pantheon.tech>>
Date: Tuesday, 21 August 2018 at 16:41
To: Nitin Saxena mailto:nitin.sax...@cavium.com>>, 
"vpp-dev@lists.fd.io" 
mailto:vpp-dev@lists.fd.io>>
Subject: [vpp-dev] Cavium ThunderX (ARM64) - Crash in VPP (Kubernetes + 
Contiv-VPP network plugin)

Hello all

Could you please help mi with this issue:
https://jira.fd.io/browse/VPP-1394

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

View/Reply Online (#10425): https://lists.fd.io/g/vpp-dev/message/10425
Mute This Topic: https://lists.fd.io/mt/24876710/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] broken GRE tunnel

[Neale Ranns via Lists.Fd.Io]

Hi Fedro,

Thanks for the bug report. Fixed in:
  https://gerrit.fd.io/r/#/c/14891/

/neale


-Original Message-
From:  on behalf of Fedor Kazmin 
Date: Wednesday, 19 September 2018 at 10:46
To: "vpp-dev@lists.fd.io" 
Subject: [vpp-dev] broken GRE tunnel

Hello all,
I have got an issue with GRE encapsulation, need some help.
VPP creates broken tunnel, no actial connectivity.
Both stable/1804 and master, Ubuntu Xenial, gcc 5.4.0

Steps to reproduce:
1. Create and configure veth pair
 ip link add name veth0 type veth peer name vpp0
 ip link set dev vpp0 up
 ip link set dev veth0 up
 ip addr add 172.16.0.1/24 dev veth0

2. Run VPP and configure a tunnel
DBGvpp# sh ver
vpp v18.10-rc0~434-gb4603a7 built by kahzeemin on kahzeemin-nix at Wed 
Sep 19 10:50:56 MSK 2018

DBGvpp# create host name vpp0
host-vpp0

DBGvpp# set int state host-vpp0 up
DBGvpp# set int ip addr host-vpp0 172.16.0.2/24
DBGvpp# create gre tun src 172.16.0.2 dst 172.16.0.1
gre0

DBGvpp# ip route add 2001:db8::1/128 via gre0
DBGvpp# set int state gre0 up
DBGvpp# enable ip6 int gre0
DBGvpp#  sh ip6 fib 2001:db8::1/128
ipv6-VRF:0, fib_index:0, flow hash:[src dst sport dport proto ] 
locks:[src:plugin-hi:1, src:default-route:1, ]
2001:db8::1/128 fib:0 index:12 locks:2
   src:CLI refs:1 entry-flags:attached, src-flags:added,contributing,active,
 path-list:[14] locks:2 flags:shared, uPRF-list:15 len:1 itfs:[2, ]
   path:[14] pl-index:14 ip6 weight=1 pref=0 attached-nexthop: 
oper-flags:resolved, cfg-flags:attached,
 2001:db8::1 gre0 (p2p)
   [@0]: ipv6 via :: gre0: mtu:9000 
4500fe2f64abac12ac1186dd
  stacked-on:
[@3]: ipv6 via 172.16.0.1 host-vpp0: mtu:9000 
aae5c055aecc02fe6575de3586dd

  forwarding:   unicast-ip6-chain
   [@0]: dpo-load-balance: [proto:ip6 index:14 buckets:1 uRPF:15 to:[0:0]]
 [0] [@6]: ipv6 via :: gre0: mtu:9000 
4500fe2f64abac12ac1186dd
 stacked-on:
   [@3]: ipv6 via 172.16.0.1 host-vpp0: mtu:9000 
aae5c055aecc02fe6575de3586dd


Please note this 'stacked-on: ipv6 via 172.16.0.1' leading to icmp6 
neighbor discovery and no actual connectivity through the tunnel.

It looks like the problem is hardcoded next_hop_proto = DPO_PROTO_IP6 in 
add_del_route_t_handler invocation from ip6_add_del_route_t_handler 
(src/vnet/ip/ip_api.c:1091) and similar which is not necesseraly true 
about gre tunnels.



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

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

Re: [**EXTERNAL**] Fwd: [vpp-dev] Failing to create untagged sub-interface

[Neale Ranns via Lists.Fd.Io]

Hi Mike,

Perhaps you could tell us why you want to create an untagged sub-interface.

Regards,
Neale


De :  au nom de "Bly, Mike" 
Date : vendredi 21 septembre 2018 à 17:06
À : "John Lo (loj)" , Edward Warnicke , 
"vpp-dev@lists.fd.io" 
Objet : Re: [**EXTERNAL**] Fwd: [vpp-dev] Failing to create untagged 
sub-interface

John,

Any advise on this is appreciated. We can certainly dig into this, but we first 
wanted to sanity check with the community in case there was something obvious 
as to why it is working the way it is currently. I am hopeful that between you 
efforts and ours we can run this to ground in short order.

-Mike

From: vpp-dev@lists.fd.io  On Behalf Of John Lo (loj) via 
Lists.Fd.Io
Sent: Thursday, September 20, 2018 4:02 PM
To: Edward Warnicke ; vpp-dev@lists.fd.io; Bly, Mike 

Cc: vpp-dev@lists.fd.io
Subject: Re: [**EXTERNAL**] Fwd: [vpp-dev] Failing to create untagged 
sub-interface

When a sub-interface is created, matching of tags on the packet to the 
sub-interface can be specified as “exact-match”.  With exact-match, packet must 
have the same number of tags with values matching that specified for the 
sub-interface.  Otherwise, packets will belong to the best matched 
sub-interface.  A sub-interface to be used for L3 must be created with 
exact-match.  Otherwise, IP forwarding cannot get a proper L2 header rewrite 
for output on the sub-interface.

As for a main interface,  I suppose when it is in L2 mode, packets received 
with no tags or with tags without any specific sub-interface match is 
considered as on the main interface.  When the main interface is in L3 mode, it 
will only get untagged packets because of the exact match requirement.  I think 
this is why the default sub-interface starts to get non-matching tagged packets 
when main interface is in L3 mode, as observed.  Packets received on the main 
interface in L3 mode can be IP forwarded or be dropped.

It is a good question – what is the expected sub-interface classification 
behavior with untagged or default sub-interface?  I think this is the area of 
VPP that has not been used much and thus we have little knowledge of how it 
behaves without studying the code (hence lack of response to this thread of 
questions so far).  When I get a chance, I can take look into this issue – how 
VLAN match should work for default/untagged sub-interface and why untagged 
sub-interface creation fails.  I don’t know how soon I will get to it.  So, if 
anyone is willing to contribute and submit a patch to fix the issue, I will be 
happy to review and/or merge the patch as appropriate.

Regards,
John

From: vpp-dev@lists.fd.io 
mailto:vpp-dev@lists.fd.io>> On Behalf Of Edward Warnicke
Sent: Thursday, September 20, 2018 1:25 PM
To: vpp-dev@lists.fd.io; Bly, Mike 
mailto:m...@ciena.com>>
Subject: Re: [**EXTERNAL**] Fwd: [vpp-dev] Failing to create untagged 
sub-interface

Guys,
  Anyone have any thoughts on this?

Ed



On September 20, 2018 at 12:01:05 PM, Bly, Mike 
(m...@ciena.com) wrote:
Ed/Keith, et al,

What Vijay is digging into is trying to understand how to provide the following 
sub-interface setup on a common/single physical NIC. I am hoping you can shed 
some light on the feasibility of this, given the current code to date.

Our goal is to provide proper separation of untagged vs. explicit-vlan (EVPL) 
vs. default (all remaining vlans) vs. EPL as needed on a given NIC, independent 
of any choice of forwarding mode (L2 vs L3).

GigabitEthernet5/0/0 --> “not used to forward traffic” (see next three 
sub-if’s), calling it sub_if_0 for reference below (seen as possible EPL path, 
but not covered here, since already “working”)
GigabitEthernet5/0/0.untagged --> all untagged traffic on this port goes to 
sub_if_1
GigabitEthernet5/0/0.vid1 --> all traffic arriving with outer tag == 1 goes to 
sub_if_2
GigabitEthernet5/0/0.default --> all other tagged traffic goes to sub_if_3

The only way we seem to be able to get sub_if_3 to process traffic is to 
disable sub_if_0 (set mode to l3).

Additionally, the current configuration checking in src/vnet/ethernet/node.c 
does not seem amenable to allowing the actual configuration and support of 
untagged vs default as two distinct sub-if’s processing traffic at the same 
time (my sub_if_1 and sub_if_3 above). Are we missing something here in how 
this is supposed to work? We would be fine with letting “sub_if_0” carry the 
untagged traffic (in place of sub_if_1), but we have yet to figure out how to 
do that while still having sub_if_3 processing “all other tagged frames”. We 
can say in all of our testing that we in fact do correctly see sub_if_2 working 
as expected.

Here is a simple configuration showing our current efforts in this area:

create bridge-domain 1
create bridge-domain 2
create bridge-domain 3

set interface l2 bridge GigabitEthernet5/0/0 1
set interface l2 bridge GigabitEthernet5/0/1 1

c

Re: [vpp-dev] Master branch l2bd test perf dop

[Neale Ranns via Lists.Fd.Io]

Hi Yuwei,

There was a change to the l2flood node recently:
  https://gerrit.fd.io/r/#/c/13578/
where we use the buffer clone mechanism rather than free-recycle. I would 
expect the CPU cycles per invocation of the l2-flood node to increase, but the 
number of invocations of l2flood to decrease (w.r.t. the interface-tx node).
How many replications does your test perform and is there a trend for perf 
change versus number of replications?

Thanks,
Neale


De :  au nom de Zhang Yuwei 
Date : jeudi 27 septembre 2018 à 05:02
À : "vpp-dev@lists.fd.io" 
Objet : [vpp-dev] Master branch l2bd test perf dop

Hi All,
 In our recent test, I found a performance drop in master branch. I 
execute the l2bd test case in a 2.5GHZ CPU and found almost 35% drop compared 
to 18.07 release. My test is set two NIC ports to a same bridge domain and send 
traffic to test the l2 forward performance. I found in the master branch, 
l2flood function consume much more CPU cycles than 18.07 which means any test 
use the l2flood function will also have a performance drop. Can anybody kindly 
help to check this issue? Thanks a lot.

Regards,
Yuwei

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

View/Reply Online (#10691): https://lists.fd.io/g/vpp-dev/message/10691
Mute This Topic: https://lists.fd.io/mt/26289209/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] Make test failures on ARM - IP4, L2, ECMP, Multicast, GRE, SCTP, SPAN, ACL

[Neale Ranns via Lists.Fd.Io]

De :  au nom de Juraj Linkeš 
Date : jeudi 27 septembre 2018 à 09:21
À : "Neale Ranns (nranns)" 
Cc : vpp-dev 
Objet : Re: [vpp-dev] Make test failures on ARM - IP4, L2, ECMP, Multicast, 
GRE, SCTP, SPAN, ACL

Hi Neale,

I had a debugging session with Andrew about failing ACL testcases and he 
uncovered that the root cause is in l2 and ip4:

1) the timeout and big files

for some reason in the bridged setup done by a testcase, the VPP reinjects the 
packet being sent onto one of the interfaces of the bridge, in a loop.

The following crude diff eliminates the problem and the tests pass: 
https://paste.ubuntu.com/p/CSMYjXsZyX/

[nr] Can we please see the packet trace with that patch in place?

2) there is a failure of a mac acl testcase in the routed scenario, where the 
ip lookup picks up incorrect next index:

The following shows the problem for the properly and improperly routed packet:

https://paste.ubuntu.com/p/wTWWNhwSKY/

that’s bizarre. I’m not sure where to start debugging that other than attaching 
GDB and having a poke around.

/neale


Could you advise on the first issue (Andrew wasn't sure the diff is a proper 
fix) and help debug the other issue (or, most likely related, issues 
https://jira.fd.io/browse/VPP-1432 and https://jira.fd.io/browse/VPP-1433?) If 
not, could you suggest someone so I can ask them?

Thanks,
Juraj

From: Juraj Linkeš
Sent: Tuesday, September 25, 2018 10:07 AM
To: 'Juraj Linkeš' ; vpp-dev 
Cc: csit-dev 
Subject: RE: Make test failures on ARM - IP4, L2, ECMP, Multicast, GRE, SCTP, 
SPAN, ACL

I created the new tickets under CSIT, which is an oversight, but I fixed it and 
now the tickets are under VPP:

· GRE crash

· SCTP failure/crash

oMe and Marco resolved a similar issue in the past, but this could be 
something different

· SPAN crash

· IP4 failures

oThese are multiple failures and I'm not sure that grouping them together 
is correct

· L2 failures/crash

oAs in IP4, these are multiple failures and I'm not sure that grouping them 
together is correct

· ECMP failure

· Multicast failure

· ACL failure

oI'm already working with Andrew on fixing this

There seem to be a lot of people who touched the code. I would like to ask the 
authors to tell me who to turn to (at least for IP and L2).

Regards,
Juraj

From: Juraj Linkeš [mailto:juraj.lin...@pantheon.tech]
Sent: Monday, September 24, 2018 6:26 PM
To: vpp-dev mailto:vpp-dev@lists.fd.io>>
Cc: csit-dev mailto:csit-...@lists.fd.io>>
Subject: [vpp-dev] Make test failures on ARM

Hi vpp-devs,

Especially ARM vpp devs ☺

We're experiencing a number of failures on Cavium ThunderX and we'd like to fix 
the issues. I've created a number of Jira tickets:

· GRE crash

· SCTP failure/crash

oMe and Marco resolved a similar issue in the past, but this could be 
something different

· SPAN crash

· IP4 failures

oThese are multiple failures and I'm not sure that grouping them together 
is correct

· L2 failures/crash

oAs in IP4, these are multiple failures and I'm not sure that grouping them 
together is correct

· ECMP failure

· Multicast failure

· ACL failure

oI'm already working with Andrew on fixing this

The reason I didn't reach out to all authors individually is that I wanted 
someone to look at the issues and assess whether there's an overlap (or I 
grouped the failures improperly), since some of the failures look similar.

Then there's the issue of hardware availability - if anyone willing to help has 
access to fd.io lab, I can setup access to a Cavium ThunderX, otherwise we 
could set up a call if further debugging is needed.

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

View/Reply Online (#10692): https://lists.fd.io/g/vpp-dev/message/10692
Mute This Topic: https://lists.fd.io/mt/26218436/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] Master branch l2bd test perf dop

[Neale Ranns via Lists.Fd.Io]

Hi Yuwei,

Can you test this, please:
https://gerrit.fd.io/r/#/c/15100/

thanks,
neale

De : "Zhang, Yuwei1" 
Date : vendredi 28 septembre 2018 à 03:08
À : "Neale Ranns (nranns)" , "vpp-dev@lists.fd.io" 

Objet : RE: [vpp-dev] Master branch l2bd test perf dop

Hi Neale,
 I assume the replications should related to the interfaces in the 
bridge, right? I just have 2 interfaces in the bridge which means one of the 
interface receive traffic and another send out. In the 64K size packet test 
case, the performance have almost 35% drop. I didn’t do other case yet.

Regards,
Yuwei
From: Neale Ranns (nranns) [mailto:nra...@cisco.com]
Sent: Thursday, September 27, 2018 8:31 PM
To: Zhang, Yuwei1 ; vpp-dev@lists.fd.io
Subject: Re: [vpp-dev] Master branch l2bd test perf dop


Hi Yuwei,

There was a change to the l2flood node recently:
  https://gerrit.fd.io/r/#/c/13578/
where we use the buffer clone mechanism rather than free-recycle. I would 
expect the CPU cycles per invocation of the l2-flood node to increase, but the 
number of invocations of l2flood to decrease (w.r.t. the interface-tx node).
How many replications does your test perform and is there a trend for perf 
change versus number of replications?

Thanks,
Neale


De : mailto:vpp-dev@lists.fd.io>> au nom de Zhang Yuwei 
mailto:yuwei1.zh...@intel.com>>
Date : jeudi 27 septembre 2018 à 05:02
À : "vpp-dev@lists.fd.io" 
mailto:vpp-dev@lists.fd.io>>
Objet : [vpp-dev] Master branch l2bd test perf dop

Hi All,
 In our recent test, I found a performance drop in master branch. I 
execute the l2bd test case in a 2.5GHZ CPU and found almost 35% drop compared 
to 18.07 release. My test is set two NIC ports to a same bridge domain and send 
traffic to test the l2 forward performance. I found in the master branch, 
l2flood function consume much more CPU cycles than 18.07 which means any test 
use the l2flood function will also have a performance drop. Can anybody kindly 
help to check this issue? Thanks a lot.

Regards,
Yuwei

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

View/Reply Online (#10756): https://lists.fd.io/g/vpp-dev/message/10756
Mute This Topic: https://lists.fd.io/mt/26289209/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 abot FRR

[Neale Ranns via Lists.Fd.Io]

Hi Xue,

which FRR ;)
This one:
  https://tools.ietf.org/html/rfc5286
we don’t support

For this one:
  https://frrouting.org/
I’ll leave it to the community to comment.

/neale


De :  au nom de xyxue 
Date : mercredi 10 octobre 2018 à 08:35
À : vpp-dev 
Objet : [vpp-dev] question abot FRR


Hi guys,

If the vpp support FRR? What's the configuration about FRR?

Thanks,
Xue

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

View/Reply Online (#10785): https://lists.fd.io/g/vpp-dev/message/10785
Mute This Topic: https://lists.fd.io/mt/27154774/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 IPv6 VXLAN fails

[Neale Ranns via Lists.Fd.Io]

+Eyal

I expect it was broken by efd9cf302.

/neale


De :  au nom de "Michal Cmarada via Lists.Fd.Io" 

Répondre à : "Michal Cmarada -X (mcmarada - PANTHEON TECHNOLOGIES at Cisco)" 

Date : jeudi 11 octobre 2018 à 15:30
À : "vpp-dev@lists.fd.io" 
Cc : "vpp-dev@lists.fd.io" 
Objet : [vpp-dev] Delete IPv6 VXLAN fails

Hi,

I was trying to setup and delete IPV6 vxlan tunel using vpp_api_test:
vat# vxlan_tunnel_dump
sw_if_index   instance src_address dst_address  
encap_vrf_id  decap_next_index  vni  mcast_sw_if_index
vat# vxlan_add_del_tunnel src 10::10 dst 10::11 vni 88 encap-vrf-id 0 
decap-next l2
vat# vxlan_tunnel_dump
sw_if_index   instance src_address dst_address  
encap_vrf_id  decap_next_index  vni  mcast_sw_if_index
  2  0  10::11  10::10  
   0 1   88 -1
vat# vxlan_add_del_tunnel src 10::10 dst 10::11 vni 88 encap-vrf-id 0 
decap-next l2 del
vxlan_add_del_tunnel error: Misc
vat# vxlan_tunnel_dump
sw_if_index   instance src_address dst_address  
encap_vrf_id  decap_next_index  vni  mcast_sw_if_index
vxlan_tunnel_dump error: Misc

The reason is that we have simmilar test in CSIT for honeycomb and it is 
failing, so I wanted to test it manually using vat. I tried to add tunnel which 
was successful, but the delete afterwards failed.
I tested this using 19.01-rc0~8-g642829d~b5417 build, but the tests are failing 
for few days so it is probably present in 18.10 too.
I have HC dumps from vppAPI call too which behaves the same. Add is succesfull 
and Delete fails.
ADD:
VxlanAddDelTunnel{isAdd=1, isIpv6=1, instance=0, srcAddress=[0, 16, 0, 0, 0, 0, 
0, 0, 0, 0, 0, 0, 0, 0, 0, 16], dstAddress=[0, 16, 0, 0, 0, 0, 0, 0, 0, 0, 0, 
0, 0, 0, 0, 17], mcastSwIfIndex=0, encapVrfId=0, decapNextIndex=1, vni=88}
DELETE:
VxlanAddDelTunnel{isAdd=0, isIpv6=1, instance=0, srcAddress=[0, 16, 0, 0, 0, 0, 
0, 0, 0, 0, 0, 0, 0, 0, 0, 16], dstAddress=[0, 16, 0, 0, 0, 0, 0, 0, 0, 0, 0, 
0, 0, 0, 0, 17], mcastSwIfIndex=0, encapVrfId=0, decapNextIndex=1, vni=88}

Seems there might be a bug in VPP. Can somebody check it?

Thanks

Michal

[ttps://www.cisco.com/c/dam/m/en_us/signaturetool/images/banners/standard/06_standard_graphic.png]




Michal Cmarada
Engineer - Software
mcmar...@cisco.com
Tel:










Cisco Systems, Inc.



Slovakia
cisco.com



[ttp://www.cisco.com/assets/swa/img/thinkbeforeyouprint.gif]

Think before you print.

This email may contain confidential and privileged material for the sole use of 
the intended recipient. Any review, use, distribution or disclosure by others 
is strictly prohibited. If you are not the intended recipient (or authorized to 
receive for the recipient), please contact the sender by reply email and delete 
all copies of this message.
Please click 
here
 for Company Registration Information.







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

View/Reply Online (#10798): https://lists.fd.io/g/vpp-dev/message/10798
Mute This Topic: https://lists.fd.io/mt/27241657/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 crash when handling IGMP with router alert

[Neale Ranns via Lists.Fd.Io]

Hi Jeff,

Thank you for the bug report.

As you mention the graph node path taken by these packets does not go thru 
ip4-lookup and so does not have the fib-index set. Since ip4-lookup is replaced 
by ip4-options, IMO ip4-options would be the place to add the code you have 
identified, so that we don’t do unnecessary work on packets that are for-us and 
were subject to the lookup. Please submit a patch with the change.

We have some unit tests in test/test_igmp.py (test_igmp_router()) where we send 
IGMP packets to an interface that is not IGMP enabled and so they take the same 
graph node paths as your packet. This tests passes. Is your input interface 
bound to a non-default VRF? If so would you be able to add a new test to that 
file where the input interface is bound to another table?

Thanks,
neale

De :  au nom de Jeff 
Date : mardi 16 octobre 2018 à 22:27
À : "vpp-dev@lists.fd.io" 
Objet : [vpp-dev] vpp crash when handling IGMP with router alert

Hello,

I have a tap interface connected to a noisy LAN and I found that a certain type 
of IGMP packet will sometimes cause a crash (backtrace at the end) in 
ip4_fib_mtrie_lookup_step_one().  More specifically its an IGMP packet with the 
router alert IP option.  Here's a packet trace:

00:02:41:522429: virtio-input
  virtio: hw_if_index 6 next-index 4 vring 0 len 54
hdr: flags 0x00 gso_type 0x00 hdr_len 0 gso_size 0 csum_start 0 csum_offset 
0 num_buffers 1
00:02:41:522430: ethernet-input
  IP4: 00:0c:29:1f:43:a4 -> 01:00:5e:00:00:16
00:02:41:522430: ip4-input
  IGMP: 172.20.2.194 -> 224.0.0.22
version 4, header length 24
tos 0xc0, ttl 1, length 40, checksum 0x5523
fragment id 0x, flags DONT_FRAGMENT
00:02:41:522431: ip4-options
option:[0x94,0x4,0x0,0x0]
00:02:41:522431: ip4-local
IGMP: 172.20.2.194 -> 224.0.0.22
  version 4, header length 24
  tos 0xc0, ttl 1, length 40, checksum 0x5523
  fragment id 0x, flags DONT_FRAGMENT
00:02:41:522434: igmp-input
  sw_if_index 6 next-index 0
  membership_report_v3: code 0, checksum 0xfbf4
00:02:41:522435: error-drop
  igmp-input: IGMP not enabled on this interface


I found that when the crash occurs vnet_buffer(b)->ip.fib_index is ~0 in 
ip4_local_check_src().  Here's an example debug print just added just after "if 
(PREDICT_FALSE (last_check->src.as_u32 != ip0->src_address.as_u32))" in 
ip4_local_check_src()

Usual case:
ip4_local_check_src: ( != 0101A8C0), buf 0x7f6b6301b900, vlib_tx 
4294967295 fib index 0

When crash happens:
ip4_local_check_src: ( != 0100A8C0), buf 0x7f6b63a0, vlib_tx 
4294967295 fib index 4294967295

I think the problem is that vnet_buffer(b)->ip.fib_index isn't set anywhere in 
this processing chain (ip4-input -> ip4-options -> ip4-local).  This can cause 
an invalid pointer to be used when looking up the mtrie in 
ip4_local_check_src().  Normally the fib_index metadata is assigned by 
ip4-lookup via ip_lookup_set_buffer_fib_index().  But since the packet doesn't 
traverse that node the metadata is unset.  I'm guessing that due to luck and/or 
initialization the fib_index metadata is usually zero, so the crash won't 
happen until the metadata is modified elsewhere and then the buffer is reused 
for this IGMP packet with router alert.  I hope this is what's happening and 
it's not something more nefarious like memory corruption.

I made the following change at the top of ip4_local_check_src (taken from 
ip_lookup_set_buffer_fib_index())

   const dpo_id_t *dpo0;
   load_balance_t *lb0;
   u32 lbi0;
+  ip4_main_t *im = &ip4_main;

   vnet_buffer (b)->ip.fib_index =
+vec_elt (im->fib_index_by_sw_if_index, vnet_buffer 
(b)->sw_if_index[VLIB_RX]);
+  vnet_buffer (b)->ip.fib_index =
 vnet_buffer (b)->sw_if_index[VLIB_TX] != ~0 ?
 vnet_buffer (b)->sw_if_index[VLIB_TX] : vnet_buffer (b)->ip.fib_index;

With this change I was unable to trigger the crash.  Don't know if this is a 
proper fix though.

Here's the backtrace (some of the line numbers might be offset due to my 
debugging):

Thread 1 "vpp_main" received signal SIGSEGV, Segmentation fault.
0x7f73861c2748 in ip4_fib_mtrie_lookup_step_one 
(dst_address=0x7f717de38e1a, m=) at 
/home/jeff/vpp/src/vnet/ip/ip4_mtrie.h:229
229 /home/jeff/vpp/src/vnet/ip/ip4_mtrie.h: No such file or directory.
(gdb) bt
#0  0x7f73861c2748 in ip4_fib_mtrie_lookup_step_one 
(dst_address=0x7f717de38e1a, m=) at 
/home/jeff/vpp/src/vnet/ip/ip4_mtrie.h:229
#1  ip4_local_check_src (error0=, last_check=, ip0=0x7f717de38e0e, b=)
at /home/jeff/vpp/src/vnet/ip/ip4_forward.c:1352
#2  ip4_local_inline (vm=, node=, 
frame=, head_of_feature_arc=)
at /home/jeff/vpp/src/vnet/ip/ip4_forward.c:1586
#3  0x7f7385c70014 in dispatch_node (last_time_stamp=17304359695215669, 
frame=0x7f718dcaf300, dispatch_state=VLIB_NODE_STATE_POLLING,
type=VLIB_NODE_TYPE_INTERNAL, node=0x7f7184ed2ec0, vm=0x7f7385ec9980 
) at /home/jeff/vpp/src/vlib/main.c:989
#4  dispatch_pending_node (vm=vm@entry=

Re: [vpp-dev]ping local address

[Neale Ranns via Lists.Fd.Io]

It’s a known limitation. Contributions to fix it would be welcome.

/neale


De :  au nom de "saint_sun 孙 via Lists.Fd.Io" 

Répondre à : "saint_...@aliyun.com" 
Date : jeudi 25 octobre 2018 à 09:40
À : vpp-dev 
Cc : "vpp-dev@lists.fd.io" 
Objet : [vpp-dev]ping local address

Hello all:
An basic features: ping myself. when I configure an IP address for an 
interface, then I ping the address from VPP, it's failed, why?should I do other 
more settings?

DBGvpp# ping 10.0.0.1
Aborted due to a keypress.

Statistics: 1 sent, 0 received, 100% packet loss


DBGvpp# show ip fib
ipv4-VRF:0, fib_index:0, flow hash:[src dst sport dport proto ] 
locks:[src:default-route:1, ]
0.0.0.0/0
  unicast-ip4-chain
  [@0]: dpo-load-balance: [proto:ip4 index:1 buckets:1 uRPF:0 to:[0:0]]
[0] [@0]: dpo-drop ip4
0.0.0.0/32
  unicast-ip4-chain
  [@0]: dpo-load-balance: [proto:ip4 index:2 buckets:1 uRPF:1 to:[0:0]]
[0] [@0]: dpo-drop ip4
10.0.0.0/32
  unicast-ip4-chain
  [@0]: dpo-load-balance: [proto:ip4 index:17 buckets:1 uRPF:21 to:[0:0]]
[0] [@0]: dpo-drop ip4
10.0.0.0/24
  unicast-ip4-chain
  [@0]: dpo-load-balance: [proto:ip4 index:16 buckets:1 uRPF:27 to:[0:0]]
[0] [@4]: ipv4-glean: line1: mtu:9000 000e5e513c380806
10.0.0.1/32
  unicast-ip4-chain
  [@0]: dpo-load-balance: [proto:ip4 index:19 buckets:1 uRPF:25 to:[0:0]]
[0] [@2]: dpo-receive: 10.0.0.1 on line1
10.0.0.255/32
  unicast-ip4-chain
  [@0]: dpo-load-balance: [proto:ip4 index:18 buckets:1 uRPF:23 to:[0:0]]
[0] [@0]: dpo-drop ip4
224.0.0.0/4
  unicast-ip4-chain
  [@0]: dpo-load-balance: [proto:ip4 index:4 buckets:1 uRPF:3 to:[0:0]]
[0] [@0]: dpo-drop ip4
240.0.0.0/4
  unicast-ip4-chain
  [@0]: dpo-load-balance: [proto:ip4 index:3 buckets:1 uRPF:2 to:[0:0]]
[0] [@0]: dpo-drop ip4
255.255.255.255/32
  unicast-ip4-chain
  [@0]: dpo-load-balance: [proto:ip4 index:5 buckets:1 uRPF:4 to:[0:0]]
[0] [@0]: dpo-drop ip4




saint_...@aliyun.com

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

View/Reply Online (#10982): https://lists.fd.io/g/vpp-dev/message/10982
Mute This Topic: https://lists.fd.io/mt/27630267/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]ping local address

[Neale Ranns via Lists.Fd.Io]

Hi Saint,

With this change an attacker could send a packet with both the source and 
destination both set to one of VPP’s own addresses. If you include in this new 
sub-condition to only accept locally generated packets, then we should be good 
(b->flags & VNET_BUFFER_F_LOCALLY_ORIGINATED).

Regards,
neale

De : "saint_...@aliyun.com" 
Date : mercredi 31 octobre 2018 à 08:49
À : "Neale Ranns (nranns)" 
Cc : vpp-dev 
Objet : Re: Re: [vpp-dev]ping local address

hello neale,
I found and modified a piece of code in the ip4_forward.c, and now it is 
able to ping local address, as follows:

I think the source- check should only discard the packet which comes from the 
attacker(forged a source address) and wants to attack another host, so I 
changed the judgement conditions.
can you help me to check it right or wrong?


The attachment is the modified file.

saint_...@aliyun.com

From: Neale Ranns (nranns)
Date: 2018-10-25 15:55
To: saint_...@aliyun.com; 
vpp-dev
Subject: Re: [vpp-dev]ping local address

It’s a known limitation. Contributions to fix it would be welcome.

/neale


De :  au nom de "saint_sun 孙 via Lists.Fd.Io" 

Répondre à : "saint_...@aliyun.com" 
Date : jeudi 25 octobre 2018 à 09:40
À : vpp-dev 
Cc : "vpp-dev@lists.fd.io" 
Objet : [vpp-dev]ping local address

Hello all:
An basic features: ping myself. when I configure an IP address for an 
interface, then I ping the address from VPP, it's failed, why?should I do other 
more settings?

DBGvpp# ping 10.0.0.1
Aborted due to a keypress.

Statistics: 1 sent, 0 received, 100% packet loss


DBGvpp# show ip fib
ipv4-VRF:0, fib_index:0, flow hash:[src dst sport dport proto ] 
locks:[src:default-route:1, ]
0.0.0.0/0
  unicast-ip4-chain
  [@0]: dpo-load-balance: [proto:ip4 index:1 buckets:1 uRPF:0 to:[0:0]]
[0] [@0]: dpo-drop ip4
0.0.0.0/32
  unicast-ip4-chain
  [@0]: dpo-load-balance: [proto:ip4 index:2 buckets:1 uRPF:1 to:[0:0]]
[0] [@0]: dpo-drop ip4
10.0.0.0/32
  unicast-ip4-chain
  [@0]: dpo-load-balance: [proto:ip4 index:17 buckets:1 uRPF:21 to:[0:0]]
[0] [@0]: dpo-drop ip4
10.0.0.0/24
  unicast-ip4-chain
  [@0]: dpo-load-balance: [proto:ip4 index:16 buckets:1 uRPF:27 to:[0:0]]
[0] [@4]: ipv4-glean: line1: mtu:9000 000e5e513c380806
10.0.0.1/32
  unicast-ip4-chain
  [@0]: dpo-load-balance: [proto:ip4 index:19 buckets:1 uRPF:25 to:[0:0]]
[0] [@2]: dpo-receive: 10.0.0.1 on line1
10.0.0.255/32
  unicast-ip4-chain
  [@0]: dpo-load-balance: [proto:ip4 index:18 buckets:1 uRPF:23 to:[0:0]]
[0] [@0]: dpo-drop ip4
224.0.0.0/4
  unicast-ip4-chain
  [@0]: dpo-load-balance: [proto:ip4 index:4 buckets:1 uRPF:3 to:[0:0]]
[0] [@0]: dpo-drop ip4
240.0.0.0/4
  unicast-ip4-chain
  [@0]: dpo-load-balance: [proto:ip4 index:3 buckets:1 uRPF:2 to:[0:0]]
[0] [@0]: dpo-drop ip4
255.255.255.255/32
  unicast-ip4-chain
  [@0]: dpo-load-balance: [proto:ip4 index:5 buckets:1 uRPF:4 to:[0:0]]
[0] [@0]: dpo-drop ip4




saint_...@aliyun.com

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

View/Reply Online (#11050): https://lists.fd.io/g/vpp-dev/message/11050
Mute This Topic: https://lists.fd.io/mt/27630267/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 on VxLAN multicast mode

[Neale Ranns via Lists.Fd.Io]

Hi Eyal, John,

I missed the fact that the tunnel classification is based only on the senders 
IP. Now it makes sense.

Thanks,
Neale


-Message d'origine-
De :  au nom de "John Lo (loj) via Lists.Fd.Io" 

Répondre à : "John Lo (loj)" 
Date : lundi 5 novembre 2018 à 16:17
À : Xuekun , "Eyal Bari (ebari)" , 
"vpp-dev@lists.fd.io" 
Cc : "vpp-dev@lists.fd.io" 
Objet : Re: [vpp-dev] Problem on VxLAN multicast mode

VPP does not support receiving of VXLAN packets from an unknown VTEP.  
Thus, any packet received in a BD from a VXLAN multicast tunnel must have its 
source IP match of the remote VTEP of an existing VXLAN unicast tunnel in the 
same BD.  If no such unicast tunnel is found, packets are dropped.  If it is 
found and MAC learning is enabled, the MAC will be learned with its output 
associated with the matching unicast VXLAN tunnel.  VPP does not learn unknown 
remote VTEPs and create a unicast tunnel automatically for better security.   

Regards,
John

-Original Message-
From: vpp-dev@lists.fd.io  On Behalf Of Xuekun
Sent: Monday, November 05, 2018 8:07 AM
To: Eyal Bari (ebari) ; vpp-dev@lists.fd.io
Subject: Re: [vpp-dev] Problem on VxLAN multicast mode

Hi, Eyal

If need to create a unicast tunnel also, it means need to know the remote 
vtep address first. However the purpose of using mcast tunnel is to build 
tunnels across multiple vtep addresses which don't be known in advance.  For 
example, if there is a third server (server3: 192.168.1.3) in my env, what 
should I do? Still add a unicast tunnel ("create vxlan tunnel src 172.168.1.1 
dst 172.168.1.3 vni 100"), if so, just to setup the point-to-point vxlan tunnel 
and put all the tunnels in the same BD, then all servers are connected, and 
don't need to create the mcast tunnel. 

Is my understanding about mcast tunnel not correct? 
Thanks. 

Thx, Xuekun  

-Original Message-
From: Eyal Bari (ebari)  
Sent: Monday, November 05, 2018 7:58 PM
To: Hu, Xuekun ; vpp-dev@lists.fd.io
Subject: Re: [vpp-dev] Problem on VxLAN multicast mode

Just to clarify, the mcast tunnel does not need to be under the bridge for 
receiving traffic, however for sending flooded traffic through the mcast tunnel 
it needs to be under the bridge...

eyal 

On 05/11/2018, 13:47, "vpp-dev@lists.fd.io on behalf of eyal bari via 
Lists.Fd.Io"  
wrote:

Hi, Xuekun,

Packets are only received on unicast tunnels.
So in your case you would need to create one and put it under the 
bridge-domain (the multicast tunnel does not need to be under the 
bridge-domain):
create vxlan tunnel src 172.168.1.1 dst 172.168.1.2 vni 100
set interface l2 bridge vxlan_tunnel0 1000
create vxlan tunnel src 172.168.1.1 group 239.1.1.1 
TenGigabitEthernet3d/0/1 vni 100


eyal

On 05/11/2018, 9:18, "vpp-dev@lists.fd.io on behalf of Xuekun" 
 wrote:

Hi, All

I'm configuring VPP as VxLAN multicast mode over multiple servers. 
To simplify the topology, I only used two servers: server1 as VPP; server2 
using vxlan kernel mode.

Server1:
set interface state TenGigabitEthernet3d/0/1 up
set interface ip address TenGigabitEthernet3d/0/1 172.168.1.1/24
create bridge-domain 1000 learn 1 forward 1 uu-flood 1 flood 1 
arp-term 0
create vxlan tunnel src 172.168.1.1 group 239.1.1.1 
TenGigabitEthernet3d/0/1 vni 100
set interface l2 bridge vxlan_tunnel0 1000  
loopback create 
set interface l2 bridge loop0 1000 bvi
set interface state loop0 up
set interface ip address loop0 192.168.1.1/24

Server2:
ifconfig enp11s0f1 172.168.1.2/24 up
ip link add vxlan0 type vxlan id 100 dstport 4789 group 239.1.1.1 
dev enp11s0f1
ifconfig vxlan0 192.168.1.2/24 up

Now, server1 and server2 are connected with VxLAN VNI 100 through 
multicast group 239.1.1.1.  
However, 192.168.1.1 and 192.168.1.2 could NOT be pingable each 
other. 

Trace log: 
Packet 1

00:01:02:563831: dpdk-input
  TenGigabitEthernet3d/0/1 rx queue 0
  buffer 0x4b93: current data 14, length 78, free-list 0, 
clone-count 0, totlen-nifb 0, trace 0x0
 ext-hdr-valid
 l4-cksum-computed l4-cksum-correct l2-hdr-offset 0
  PKT MBUF: port 0, nb_segs 1, pkt_len 92
buf_len 2176, data_len 92, ol_flags 0x180, data_off 128, 
phys_addr 0x4012e540
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
 

Re: [vpp-dev] New Committer Nomination: Andrew Yourtchenko

[Neale Ranns via Lists.Fd.Io]

+1

-Message d'origine-
De :  au nom de "Dave Barach via Lists.Fd.Io" 

Répondre à : "Dave Barach (dbarach)" 
Date : jeudi 8 novembre 2018 à 13:13
À : "vpp-dev@lists.fd.io" 
Cc : "vpp-dev@lists.fd.io" 
Objet : [vpp-dev] New Committer Nomination: Andrew Yourtchenko

In view of significant code contributions to the vpp project - see below - 
I'm pleased to nominate Andrew Yourtchenko as a vpp project committer. I have 
high confidence that he'll be a major asset to the project in a committer role. 
 

Andrew has contributed 181 merged patches, including significant new 
feature work in the ACL plugin. Example: https://gerrit.fd.io/r/#/c/13162
 
Committers, please vote (+1, 0, -1) on vpp-dev@ We'll need a recorded 
vote so that the TSC will approve Andrew's nomination.

Thanks... Dave



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

View/Reply Online (#11164): https://lists.fd.io/g/vpp-dev/message/11164
Mute This Topic: https://lists.fd.io/mt/28035544/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] ip4-load-balance

[Neale Ranns via Lists.Fd.Io]

Hi Ray,

By way of explanation.. without the interface the route is recursive, i.e. 
20.20.20.20/24 is sent via 1.1.1.2. So the forwarding can be thought of as 
happening in two stages, firstly the lookup for the packet’s destination that 
matches 20.20.20.20/24 then the ‘lookup’ on the result of 1.1.1.2. One of the 
prime functions of the FIB is to resolve and cache that second lookup during 
route programming, so the data-plane can simply follow the result. The 
ip4-load-balance node is where this occurs.

/neale


-Message d'origine-
De : Ray Kinsella 
Date : mardi 13 novembre 2018 à 19:09
À : "vpp-dev@lists.fd.io" , "Neale Ranns (nranns)" 

Objet : Re: [vpp-dev] ip4-load-balance

Mystery solved,

I was missing the interface on the IP Route.

ip route add count 1 20.20.20.0/24 via 1.1.1.2 TenGigabitEthernet83/0/1

Ray K

On 13/11/2018 15:39, Ray Kinsella wrote:
> Folks,
> 
> I have configuring my system to get something comparable to CSIT 
> performance and I am a few mpps off at the moment, using FD.io VPP 18.07.
> 
> I duplicated the IPv4 Base and Scale Test Cases (and environment) 
> locally and I end up with extra graph node 'ip4-load-balance' in my 
> pipeline?
> 
> CSIT records the following pipeline in Test Operation Data.
> https://docs.fd.io/csit/rls1807/report/test_operational_data
> 
> Thread 1 vpp_wk_0 (lcore 2)
>   Time 5.7, average vectors/node 245.79, last 128 main loops 13.03 per 
> node 151.64
> vector rates in 1.2082e7, out 1.2082e7, drop 0.e0, punt 0.e0
>Name State Calls  Vectors 
> Suspends Clocks   Vectors/Call
>   TenGigabitEtherneta/0/0-output   active 140125 
> 34429184   0  8.41e0  245.70
>   TenGigabitEtherneta/0/0-tx   active 140125 
> 34429184   0  4.09e1  245.70
>   TenGigabitEtherneta/0/1-output   active 140071 
> 34428928   0  8.58e0  245.79
>   TenGigabitEtherneta/0/1-tx   active 140071 
> 34428928   0  3.93e1  245.79
>   dpdk-input   polling140580 
> 68858112   0  6.07e1  489.81
>   ip4-input-no-checksumactive 280127 
> 68858112   0  2.05e1  245.81
>   ip4-lookup   active 280127 
> 68858112   0  3.03e1  245.81
>   ip4-rewrite  active 280127 
> 68858112   0  2.92e1  245.81
> 
> 
> I get the following pipeline, with the additional graph node - 
> ip4-load-balance.
> 
> Thread 2 vpp_wk_1 (lcore 20)
> Time 188.9, average vectors/node 256.00, last 128 main loops 14.00 per 
> node 256.00
>vector rates in 9.3287e6, out 9.3287e6, drop 0.e0, punt 0.e0
>   Name State Calls  Vectors 
>Suspends Clocks   Vectors/Call
> TenGigabitEthernet83/0/1-outpu   active6881842 
> 1761751552   0  8.46e0  256.00
> TenGigabitEthernet83/0/1-tx  active6881842 
> 1761751552   0  5.53e1  256.00
> dpdk-input   polling   6881842 
> 1761751552   0  8.58e1  256.00
> ip4-input-no-checksumactive6881842 
> 1761751552   0  2.19e1  256.00
> ip4-load-balance active6881842 
> 1761751552   0  1.68e1  25
> 6.00
> ip4-lookup   active6881842 
> 1761751552   0  2.80e1  256.00
> ip4-rewrite  active6881842 
> 1761751552   0  2.89e1  256.00
> 
> Any idea where ip4-load-balance is coming from?
> 
> Ray K
> 
> -=-=-=-=-=-=-=-=-=-=-=-
> Links: You receive all messages sent to this group.
> 
> View/Reply Online (#11223): https://lists.fd.io/g/vpp-dev/message/11223
> Mute This Topic: https://lists.fd.io/mt/28123777/675355
> Group Owner: vpp-dev+ow...@lists.fd.io
> Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub  [m...@ashroe.eu]
> -=-=-=-=-=-=-=-=-=-=-=-
> 


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

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

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

[Neale Ranns via Lists.Fd.Io]

Hi,

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

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

/neale

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

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

I am looking forward for your answers.
Thank you.

--







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

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

Re: [vpp-dev] Getting crash while running load on VPP18.01 for 6 hours

[Neale Ranns via Lists.Fd.Io]

Hi Chetan,

The null-node should not be encountered under normal operation. The null-node 
always has an index/value of 0, therefore if the previous node has not been 
properly configured, or the arc taken from that node was wrong, then the packet 
can likely end up at the null-node.
To debug this I would suggest you run a debug image and enable the packet 
trajectory tracer (grep VLIB_BUFFER_TRACE_TRAJECTORY) so you can see where 
these packets originate from.

Regards,
Neale

De :  au nom de chetan bhasin 
Date : mercredi 21 novembre 2018 à 06:16
À : "Dave Barach (dbarach)" 
Cc : "vpp-dev@lists.fd.io" 
Objet : Re: [vpp-dev] Getting crash while running load on VPP18.01 for 6 hours

Hi Dave,

Thanks a lot.

one more query ,what is the purpose of null_node ? and when this scenario will 
be provoked that null_node is hit?

Thanks,
Chetan Bhasin

On Tue, Nov 20, 2018 at 10:57 PM Dave Barach (dbarach) 
mailto:dbar...@cisco.com>> wrote:
See 
https://wiki.fd.io/view/VPP/Pulling,_Building,_Running,_Hacking_and_Pushing_VPP_Code#Pushing_Code_with_git_review

From: chetan bhasin 
mailto:chetan.bhasin...@gmail.com>>
Sent: Tuesday, November 20, 2018 11:43 AM
To: Dave Barach (dbarach) mailto:dbar...@cisco.com>>
Subject: Re: [vpp-dev] Getting crash while running load on VPP18.01 for 6 hours

Thanks Dave!

I will try with DEBUG too.

Just want to understand the procedure to check in the patches,  actually we 
have done several fixes in VPP,  so we are planning to Check-in all patches.

Thanks,
Chetan Bhasin

On Tue, Nov 20, 2018, 18:02 Dave Barach (dbarach) 
mailto:dbar...@cisco.com> wrote:
Several suggestions:

· Try a debug image (PLATFORM=vpp TAG=vpp_debug) so the crash will be 
more enlightening
· Switch to 18.10. 18.01 is no longer supported. We don’t use the 
mheap.c memory allocator anymore, and so on and so forth.
· See https://wiki.fd.io/view/VPP/BugReports


From: vpp-dev@lists.fd.io 
mailto:vpp-dev@lists.fd.io>> On Behalf Of chetan bhasin
Sent: Tuesday, November 20, 2018 5:31 AM
To: vpp-dev@lists.fd.io
Subject: [vpp-dev] Getting crash while running load on VPP18.01 for 6 hours

Hi Vpp-dev,

We are facing issues while running load for ~6 hours . getting below crash.

Your Suggestion is really appreciated.


#1  0x2b00b990e8f8 in __GI_abort () at abort.c:90
#2  0x00405f23 in os_panic () at 
/bfs-build/build-area.49/builds/LinuxNBngp_7.X_RH7/2018-11-16-0505/third-party/vpp/vpp_1801/build-data/../src/vpp/vnet/main.c:268
#3  0x2b00b8d60710 in mheap_put (v=0x2b00ba3d8000, uoffset=2382207096) at 
/bfs-build/build-area.49/builds/LinuxNBngp_7.X_RH7/2018-11-16-0505/third-party/vpp/vpp_1801/build-data/../src/vppinfra/mheap.c:798
#4  0x2b00b8d8959e in clib_mem_free (p=0x2b00c8ba84a0) at 
/bfs-build/build-area.49/builds/LinuxNBngp_7.X_RH7/2018-11-16-0505/third-party/vpp/vpp_1801/build-data/../src/vppinfra/mem.h:213
#5  vec_resize_allocate_memory (v=, 
length_increment=length_increment@entry=1, data_bytes=, 
header_bytes=, header_bytes@entry=0, 
data_align=data_align@entry=4) at 
/bfs-build/build-area.49/builds/LinuxNBngp_7.X_RH7/2018-11-16-0505/third-party/vpp/vpp_1801/build-data/../src/vppinfra/vec.c:96
#6  0x2b00b79e899d in _vec_resize (data_align=, 
header_bytes=, data_bytes=, 
length_increment=, v=) at 
/nfs-bfs/workspace/build-data/../src/vppinfra/vec.h:142
#7  get_frame_size_info (n_scalar_bytes=, 
n_vector_bytes=, nm=0x2b00c87a3160, nm=0x2b00c87a3160) at 
/nfs-bfs/workspace//build-data/../src/vlib/main.c:107
#8  0x2b00b79e8d79 in vlib_frame_free (vm=vm@entry=0x2b00c87a3050, 
r=r@entry=0x2b00c86ca368, f=f@entry=0x2b014b2ecb80) at 
/nfs-bfs//vpp_1801/build-data/../src/vlib/main.c:221
#9  0x2b00b79fe6e6 in null_node_fn (vm=0x2b00c87a3050, node=0x2b00c86ca368, 
frame=0x2b014b2ecb80) at /nfs-bfs/workspace/build-data/../src/vlib/node.c:512

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

View/Reply Online (#11349): https://lists.fd.io/g/vpp-dev/message/11349
Mute This Topic: https://lists.fd.io/mt/28266210/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] How to get source node of a buffer

[Neale Ranns via Lists.Fd.Io]

Hi Murthy,

There is no way to get the source node.
However, if you are debugging and you want to see the full history of the graph 
through which a packet has passed, you can turn on trajectory tracing.
#define VLIB_BUFFER_TRACE_TRAJECTORY 1
In vlib/buffer.h

/neale

From:  on behalf of Satya Murthy 

Date: Tuesday 24 March 2020 at 06:44
To: "vpp-dev@lists.fd.io" 
Subject: [vpp-dev] How to get source node of a buffer

Hi ,

Is there any way to find the source node of a buffer. Basically, I want to know 
from which node this buffer came.
I understand that each graph node shall have a design which is independant of 
the source node.
However, the source node information may be useful in case of debugging some 
crashes while processing a buffer.

Any inputs on this pls.

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

View/Reply Online (#15848): https://lists.fd.io/g/vpp-dev/message/15848
Mute This Topic: https://lists.fd.io/mt/72511630/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] ECMP seems to have issue if path is more than 2 #ecmp #vpp

[Neale Ranns via Lists.Fd.Io]

Hi Sontu,

Please let me refer you to a previous answer to this question:
  
https://www.mail-archive.com/search?l=vpp-dev@lists.fd.io&q=subject:%22%5C%5Bvpp%5C-dev%5C%5D+multipath+dpo+buckets+is+wrong.%22&o=newest&f=1


/neale

From:  on behalf of sontu mazumdar 
Date: Friday 27 March 2020 at 15:47
To: "vpp-dev@lists.fd.io" 
Subject: [vpp-dev] ECMP seems to have issue if path is more than 2 #ecmp #vpp

Hi,

I am using fdio 1810 version.
I observed that why I try to configure route with more than 2 paths, in show ip 
fib output it displays many duplicates entries.
This is what I am trying, I have 3 interfaces as below
vpp# show interface address
VirtualFunctionEthernet0/6/0 (up):
VirtualFunctionEthernet0/6/0.1 (up):
  L3 10.10.10.1/24 ip4 table-id 1 fib-idx 1
VirtualFunctionEthernet0/6/0.2 (up):
  L3 20.20.20.1/24 ip4 table-id 1 fib-idx 1
VirtualFunctionEthernet0/6/0.3 (up):
  L3 30.30.30.1/24 ip4 table-id 1 fib-idx 1

I am adding route as below:

1st path:
vpp# ip route add 2.2.2.2/32 table 1 via 10.10.10.2 
VirtualFunctionEthernet0/6/0.1
vpp# show ip fib table 1 2.2.2.2/32
nc1, fib_index:1, flow hash:[src dst sport dport proto ] locks:[src:API:4, ]
2.2.2.2/32 fib:1 index:44 locks:2
  src:CLI refs:1 src-flags:added,contributing,active,
path-list:[51] locks:2 flags:shared, uPRF-list:53 len:1 itfs:[5, ]
  path:[59] pl-index:51 ip4 weight=1 pref=0 attached-nexthop:  
oper-flags:resolved,
10.10.10.2 VirtualFunctionEthernet0/6/0.1
  [@0]: arp-ipv4: via 10.10.10.2 VirtualFunctionEthernet0/6/0.1

 forwarding:   unicast-ip4-chain
  [@0]: dpo-load-balance: [proto:ip4 index:46 buckets:1 uRPF:53 to:[0:0]]
[0] [@3]: arp-ipv4: via 10.10.10.2 VirtualFunctionEthernet0/6/0.1
vpp#

2nd path:
vpp# ip route add 2.2.2.2/32 table 1 via 20.20.20.2 
VirtualFunctionEthernet0/6/0.2
vpp# show ip fib table 1 2.2.2.2/32
nc1, fib_index:1, flow hash:[src dst sport dport proto ] locks:[src:API:4, ]
2.2.2.2/32 fib:1 index:44 locks:2
  src:CLI refs:1 src-flags:added,contributing,active,
path-list:[53] locks:2 flags:shared, uPRF-list:55 len:2 itfs:[5, 6, ]
  path:[62] pl-index:53 ip4 weight=1 pref=0 attached-nexthop:  
oper-flags:resolved,
10.10.10.2 VirtualFunctionEthernet0/6/0.1
  [@0]: arp-ipv4: via 10.10.10.2 VirtualFunctionEthernet0/6/0.1
  path:[61] pl-index:53 ip4 weight=1 pref=0 attached-nexthop:  
oper-flags:resolved,
20.20.20.2 VirtualFunctionEthernet0/6/0.2
  [@0]: arp-ipv4: via 20.20.20.2 VirtualFunctionEthernet0/6/0.2

 forwarding:   unicast-ip4-chain
  [@0]: dpo-load-balance: [proto:ip4 index:46 buckets:2 uRPF:55 to:[0:0]]
[0] [@3]: arp-ipv4: via 10.10.10.2 VirtualFunctionEthernet0/6/0.1
[1] [@3]: arp-ipv4: via 20.20.20.2 VirtualFunctionEthernet0/6/0.2
vpp#

3rd path:
vpp# ip route add 2.2.2.2/32 table 1 via 30.30.30.2 
VirtualFunctionEthernet0/6/0.3

vpp# show ip fib table 1 2.2.2.2/32
nc1, fib_index:1, flow hash:[src dst sport dport proto ] locks:[src:API:4, ]
2.2.2.2/32 fib:1 index:44 locks:2
  src:CLI refs:1 src-flags:added,contributing,active,
path-list:[51] locks:2 flags:shared, uPRF-list:53 len:3 itfs:[5, 6, 7, ]
  path:[63] pl-index:51 ip4 weight=1 pref=0 attached-nexthop:  
oper-flags:resolved,
10.10.10.2 VirtualFunctionEthernet0/6/0.1
  [@0]: arp-ipv4: via 10.10.10.2 VirtualFunctionEthernet0/6/0.1
  path:[64] pl-index:51 ip4 weight=1 pref=0 attached-nexthop:  
oper-flags:resolved,
20.20.20.2 VirtualFunctionEthernet0/6/0.2
  [@0]: arp-ipv4: via 20.20.20.2 VirtualFunctionEthernet0/6/0.2
  path:[59] pl-index:51 ip4 weight=1 pref=0 attached-nexthop:  
oper-flags:resolved,
30.30.30.2 VirtualFunctionEthernet0/6/0.3
  [@0]: arp-ipv4: via 30.30.30.2 VirtualFunctionEthernet0/6/0.3

 forwarding:   unicast-ip4-chain
  [@0]: dpo-load-balance: [proto:ip4 index:46 buckets:16 uRPF:53 to:[0:0]]
[0] [@3]: arp-ipv4: via 10.10.10.2 VirtualFunctionEthernet0/6/0.1
[1] [@3]: arp-ipv4: via 10.10.10.2 VirtualFunctionEthernet0/6/0.1
[2] [@3]: arp-ipv4: via 10.10.10.2 VirtualFunctionEthernet0/6/0.1
[3] [@3]: arp-ipv4: via 10.10.10.2 VirtualFunctionEthernet0/6/0.1
[4] [@3]: arp-ipv4: via 10.10.10.2 VirtualFunctionEthernet0/6/0.1
[5] [@3]: arp-ipv4: via 10.10.10.2 VirtualFunctionEthernet0/6/0.1
[6] [@3]: arp-ipv4: via 20.20.20.2 VirtualFunctionEthernet0/6/0.2
[7] [@3]: arp-ipv4: via 20.20.20.2 VirtualFunctionEthernet0/6/0.2
[8] [@3]: arp-ipv4: via 20.20.20.2 VirtualFunctionEthernet0/6/0.2
[9] [@3]: arp-ipv4: via 20.20.20.2 VirtualFunctionEthernet0/6/0.2
[10] [@3]: arp-ipv4: via 20.20.20.2 VirtualFunctionEthernet0/6/0.2
[11] [@3]: arp-ipv4: via 30.30.30.2 VirtualFunctionEthernet0/6/0.3
[12] [@3]: arp-ipv4: via 30.30.30.2 VirtualFunctionEthernet0/6/0.3
[13] [@3]: arp-ipv4: via 30.30.30.2 VirtualFunctionEthernet0/6/0.3
[14] [@3]: arp-ipv4: via 30.30.30.2 VirtualFunctionEthernet0/6/0.3
[15] [@3]: arp-ipv4: via 30.30.30.2 VirtualFunctionEthernet0/6/0.3
vpp#

Once I 

Re: 答复: [E] [vpp-dev] Build a telecom-class Security gateway device with VPP

[Neale Ranns via Lists.Fd.Io]

No.

From:  on behalf of Gencli Liu <18600640...@163.com>
Date: Monday 30 March 2020 at 03:57
To: "vpp-dev@lists.fd.io" 
Subject: Re: 答复: [E] [vpp-dev] Build a telecom-class Security gateway device 
with VPP

On Wed, Sep 19, 2018 at 06:26 PM, "tianye@sina"  wrote:
he SeGW checks the correctness of the AUTH
Do VPP support EAP ?
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

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

Re: 答复: [E] [vpp-dev] Build a telecom-class Security gateway device with VPP

[Neale Ranns via Lists.Fd.Io]

Hi,

To my knowledge there is neither an EAP implementation for VPP nor has support 
for it has not been discussed in the public forum.

/neale


From:  on behalf of Gencli Liu <18600640...@163.com>
Date: Monday 30 March 2020 at 13:47
To: "vpp-dev@lists.fd.io" 
Subject: Re: 答复: [E] [vpp-dev] Build a telecom-class Security gateway device 
with VPP

 Hi, Neale Ranns !

Thank you for your nice reply.
I just want to ask that did anybody modify VPP to implement "EAP Authentication 
Method"?
My current job is related to 4G/5G. I found that the IKE authentication methods 
mentioned in the relevant documents are all EAP(EAP-AKA).

Does anyone have a good idea for this application scenario?

Or does anyone know that if VPP has a similar development plan? (after all, 5G 
is very hot now)



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

View/Reply Online (#15935): https://lists.fd.io/g/vpp-dev/message/15935
Mute This Topic: https://lists.fd.io/mt/25745520/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 nat ipfix logging problem, need to use thread-specific vlib_main_t?

[Neale Ranns via lists.fd.io]

In the test harness you can inject onto a given worker, e.g. see 
IpsecTun6HandoffTests.

/neale

From:  on behalf of Paul Vinciguerra 

Date: Sunday 5 April 2020 at 17:24
To: "Dave Barach (dbarach)" 
Cc: Elias Rudberg , "vpp-dev@lists.fd.io" 

Subject: Re: [vpp-dev] VPP nat ipfix logging problem, need to use 
thread-specific vlib_main_t?

How can we test scenarios like this?
'set interface rx-placement' doesn't support pg interfaces.
DBGvpp# set interface rx-placement TenGigabitEthernet5/0/0 worker 2
DBGvpp# set interface rx-placement pg0 worker 2
set interface rx-placement: not found
DBGvpp#
Is there another command to bind a pg interface to a worker thread?

On Sun, Apr 5, 2020 at 8:08 AM Dave Barach via lists.fd.io 
mailto:cisco@lists.fd.io>> wrote:
If you have the thread index handy, that's OK. Otherwise, use vlib_get_main() 
which grabs the thread index from thread local storage.

-Original Message-
From: vpp-dev@lists.fd.io 
mailto:vpp-dev@lists.fd.io>> On Behalf Of Elias Rudberg
Sent: Sunday, April 5, 2020 4:58 AM
To: vpp-dev@lists.fd.io
Subject: [vpp-dev] VPP nat ipfix logging problem, need to use thread-specific 
vlib_main_t?

Hello VPP experts,

We have been using VPP for NAT44 for a while and it has been working fine, but 
a few days ago when we tried turing on nat ipfix logging, vpp crashed. It 
turned out that the problem went away if we used only a single thread, so it 
seemed related to how threading was handled in the ipfix logging code. The 
crash happened in different ways on different runs but often seemed related to 
the snat_ipfix_send() function in plugins/nat/nat_ipfix_logging.c.

Having looked at the code in nat_ipfix_logging.c I have the following theory 
about what goes wrong (I might have misunderstood something, if so please 
correct me):

In the the snat_ipfix_send() function, a vlib_main_t data structure is used, a 
pointer to it is fetched in the following way:

   vlib_main_t *vm = frm->vlib_main;

So the frm->vlib_main pointer comes from "frm" which has been set to 
flow_report_main which is a global data structure from vnet/ipfix- 
export/flow_report.c that as far as I can tell only exists once in memory (not 
once per thread). This means that different threads calling the 
snat_ipfix_send() function are using the same vlib_main_t data structure. That 
is not how it should be, I think, instead each thread should be using its own 
thread-specific vlib_main_t data structure.

A suggestion for how to fix this is to replace the line

   vlib_main_t *vm = frm->vlib_main;

with the following line

   vlib_main_t *vm = vlib_mains[thread_index];

in all places where worker threads are using such a vlib_main_t pointer. Using 
vlib_mains[thread_index] means that we are picking the thread-specific 
vlib_main_t data structure for the current thread, instead of all threads using 
the same vlib_main_t. I pushed such a change to gerrit, here: 
https://gerrit.fd.io/r/c/vpp/+/26359

That fix seems to solve the issue in my tests, vpp does not crash anymore after 
the change. Please have a look at it and let me know if this seems reasonable 
or if I have misunderstood something.

Best regards,
Elias

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

View/Reply Online (#15997): https://lists.fd.io/g/vpp-dev/message/15997
Mute This Topic: https://lists.fd.io/mt/72786912/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 about l2 multicast #vpp

[Neale Ranns via lists.fd.io]

Hi Yan,

I’m not quite sure I understand the question. However, if you are asking 
whether VPP supports IGMP snooping in a bridge-domain to provide more efficient 
L2 multicast, the answer is no. L2 multicast is flooded within the BD.

/neale


From:  on behalf of "comeon...@outlook.com" 

Date: Wednesday 8 April 2020 at 08:58
To: "vpp-dev@lists.fd.io" 
Subject: [vpp-dev] question about l2 multicast #vpp


Hi guys,



I found "igmp" in the mpls plugins. Is the vpp support L2 multicast now ?



Thank you very much for your reply.



Thanks,

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

View/Reply Online (#16031): https://lists.fd.io/g/vpp-dev/message/16031
Mute This Topic: https://lists.fd.io/mt/72869222/21656
Mute #vpp: https://lists.fd.io/mk?hashtag=vpp&subid=1480452
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 not learning the MAC from RA (Router Advertisement)

[Neale Ranns via lists.fd.io]

Hi Vyshakh,

A well placed call to:
  ip_neighbor_learn_dp()
would do the job. Then some tests in test_ip6.py TestIPv6RD.

/neale

On 09/04/2020 07:42, "vpp-dev@lists.fd.io on behalf of Ole Troan" 
 wrote:

Vyshakh,

That’s certainly what the RFC says. 
Care to submit a patch?

Cheers 
Ole

> On 9 Apr 2020, at 06:10, vyshakh krishnan via lists.fd.io 
 wrote:
> 
> 
> Hi,
> 
> VPP is not learning the MAC address on receiving an RA. Even after 
receiving  multiple RAs from a neighbor, ping to the link local address of that 
neighbor results in a NS/NA resulting in the drop of 1st ping packet. Is this 
expected?
> Just like learning the MAC from NA/NS, why can't learning be triggered 
for an RA?
> 
> Packet 3
> 
> 00:30:08:261191: memif-input
>   memif: hw_if_index 1 next-index 4
> slot: ring 0
> 00:30:08:261208: ethernet-input
>   frame: flags 0x1, hw-if-index 1, sw-if-index 1
>   IP6: 7a:55:92:76:00:01 -> 33:33:00:00:00:01
> 00:30:08:261217: ip6-input
>   ICMP6: fe80::7855:92ff:fe76:1 -> ff02::1
> tos 0x00, flow label 0x0, hop limit 255, payload length 32
>   ICMP router_advertisement checksum 0xfc3d
> 00:30:08:261236: ip6-mfib-forward-lookup
>   fib 0 entry 4
> 00:30:08:261246: ip6-mfib-forward-rpf
>   entry 4 itf 1 flags Accept,
> 00:30:08:261250: ip6-replicate
>   replicate: 2 via [@1]: dpo-receive
> 00:30:08:261255: ip6-local
> ICMP6: fe80::7855:92ff:fe76:1 -> ff02::1
>   tos 0x00, flow label 0x0, hop limit 255, payload length 32
> ICMP router_advertisement checksum 0xfc3d
> 00:30:08:261279: ip6-icmp-input
>   ICMP6: fe80::7855:92ff:fe76:1 -> ff02::1
> tos 0x00, flow label 0x0, hop limit 255, payload length 32
>   ICMP router_advertisement checksum 0xfc3d
> 00:30:08:261288: icmp6-router-advertisement
>   ICMP6: fe80::7855:92ff:fe76:1 -> ff02::1
> tos 0x00, flow label 0x0, hop limit 255, payload length 32
>   ICMP router_advertisement checksum 0xfc3d
> 00:30:08:261299: ip6-drop
> ICMP6: fe80::7855:92ff:fe76:1 -> ff02::1
>   tos 0x00, flow label 0x0, hop limit 255, payload length 32
> ICMP router_advertisement checksum 0xfc3d
> 00:30:08:261302: error-drop
>   rx:memif11/11
> 00:30:08:261303: drop
>   ip6-icmp-input: valid packets
> 
> Packet 4
> 
> 00:30:17:270341: memif-input
>   memif: hw_if_index 1 next-index 4
> slot: ring 0
> 00:30:17:286366: ethernet-input
>   frame: flags 0x1, hw-if-index 1, sw-if-index 1
>   IP6: 7a:55:92:76:00:01 -> 33:33:00:00:00:01
> 00:30:17:286375: ip6-input
>   ICMP6: fe80::7855:92ff:fe76:1 -> ff02::1
> tos 0x00, flow label 0x0, hop limit 255, payload length 32
>   ICMP router_advertisement checksum 0xfc3d
> 00:30:17:286381: ip6-mfib-forward-lookup
>   fib 0 entry 4
> 00:30:17:286388: ip6-mfib-forward-rpf
>   entry 4 itf 1 flags Accept,
> 00:30:17:286392: ip6-replicate
>   replicate: 2 via [@1]: dpo-receive
> 00:30:17:286396: ip6-local
> ICMP6: fe80::7855:92ff:fe76:1 -> ff02::1
>   tos 0x00, flow label 0x0, hop limit 255, payload length 32
> ICMP router_advertisement checksum 0xfc3d
> 00:30:17:286404: ip6-icmp-input
>   ICMP6: fe80::7855:92ff:fe76:1 -> ff02::1
> tos 0x00, flow label 0x0, hop limit 255, payload length 32
>   ICMP router_advertisement checksum 0xfc3d
> 00:30:17:286407: icmp6-router-advertisement
>   ICMP6: fe80::7855:92ff:fe76:1 -> ff02::1
> tos 0x00, flow label 0x0, hop limit 255, payload length 32
>   ICMP router_advertisement checksum 0xfc3d
> 00:30:17:286415: ip6-drop
> ICMP6: fe80::7855:92ff:fe76:1 -> ff02::1
>   tos 0x00, flow label 0x0, hop limit 255, payload length 32
> ICMP router_advertisement checksum 0xfc3d
> 00:30:17:286417: error-drop
>   rx:memif11/11
> 00:30:17:286422: drop
>   ip6-icmp-input: valid packets
> 
> DBGvpp# ping fe80::7855:92ff:fe76:1 source memif-0/0/0/10
> 76 bytes from fe80::7855:92ff:fe76:1: icmp_seq=2 ttl=63 time=28.0089 ms
> 76 bytes from fe80::7855:92ff:fe76:1: icmp_seq=3 ttl=63 time=28.0221 ms
> 76 bytes from fe80::7855:92ff:fe76:1: icmp_seq=4 ttl=63 time=24.0218 ms
> 76 bytes from fe80::7855:92ff:fe76:1: icmp_seq=5 ttl=63 time=32.0252 ms
> 
> Statistics: 5 sent, 4 received, 20% packet loss
> DBGvpp# 
> 
> Thanks
> Vyshakh
> 


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

View/Reply Online (#16039): https://lists.fd.io/g/vpp-dev/message/16039
Mute This Topic: https://lists.fd.io/mt/72890243/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] worker barrier state

[Neale Ranns via lists.fd.io]

Hi Chris,

Firstly, apologies for the lengthy delay. 

When I say 'state' in the following I'm referring to some object[s] that are 
used to forward packets. 

I'd classify the possible solution space as:
1) maintain per-packet counters for the state to indicate how many packets 
currently refer to that state.
 Pros; we know exactly when the state is no longer required and can be 
safely removed.
 Cons; significant per-packet cost, similar to maintaining counters. For 
reference, on my [aging] system enabling adjacency counters takes ip4-rewrite 
from 2.52e1 to 3.49e1 clocks. The wait times could be large (equivalent to 
flushing queues). 
2) flush queues; ensure that there are no packets in flight, anywhere, when the 
workers stop at the barrier.
Pros; It's certainly safe to delete state under these conditions.
Cons; for handoff this could be known, though the wait time would be long. 
For async crypto HW this may not be knowable and if it is the wait times would 
be large. Either way we may end up waiting for a worst-case scenario, which is 
way longer that actually needed.
3) epochs; maintain a global epoch; each time an API is called, the epoch is 
bumped. Packets entering the system get stamped with the current epoch. If a 
node sees a packet whose epoch does not match the global one, it is dropped.
Pros: simple scheme, low/negligible DP cost.
Cons: all inflight packets would be dropped on all API calls, not just the 
packets that would use the state that is being deleted.
4) MP safe: remove the state with the workers unblocked. This is a multi-stage 
process. Firstly, unlink the state from the lookup data-structures so no more 
packets can find it. Secondly, 'atomically' update the state so that packets 
using it still perform a consistent action (probably drop). Thirdly, don't 
reuse that state (i.e. recycle its pool index) until all the inflight packets 
pass through the system (mis-forwarding must be avoided). Make-before-break, if 
that term means anything to you __
Pros; MP safe is always good, since there's less packet drops. Zero 
per-packet DP cost. 
Cons; it's not easy to get right nor test.

IMHO the drawbacks of options 1, 2 & 3 rule them out, which leaves us only 4.

For option 4, the first and second steps are very much dependent on the type of 
state we're talking about. For SAs for example, unlinking the SA from the 
lookup data-structure is accomplished using a separate API from the SA delete*. 
The final step we can easily accomplish with a new version of the pool 
allocator whose free-list prevents reuse for say 5 seconds (an age in DP terms).

Thoughts?

/neale

* I note that a SA delete is already (optimistically) marked MP safe, which 
assumes the system flushes inbetween these API calls.




On 26/03/2020 16:09, "Christian Hopps"  wrote:



> On Mar 25, 2020, at 1:39 PM, Dave Barach via Lists.Fd.Io 
 wrote:
> 
> Vlib_main_t *vm->main_loop_count.
> 
> One trip around the main loop accounts for all per-worker local graph 
edges / acyclic graph behaviors. 
> 
> As to the magic number E (not to be confused with e): repeatedly handing 
off packets from thread to thread seems like a bad implementation strategy. The 
packet tracer will tell you how many handoffs are involved in a certain path, 
as will a bit of code inspection.

No, it would not be a good implementation strategy. :)

However, I was looking at trying to code this in an upstreamable way, and I 
didn't think I got to make assumptions about how others might wire things 
together. I suppose we could just define a maximum number of handoffs and then 
if users violated that number they would need to increase it?

> Neale has some experience with this scenario, maybe he can share some 
thoughts...

Hoping so. :)

I noticed that crypto engine handoffs were added to the non-dpdk ipsec 
encrypt/decrypt in master, which seems somewhat relevant.

Thanks,
Chris.

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

View/Reply Online (#16081): https://lists.fd.io/g/vpp-dev/message/16081
Mute This Topic: https://lists.fd.io/mt/72542383/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] frp_preference and frp_weight size #vnet

[Neale Ranns via lists.fd.io]

Hi Dimitar,

In VPP’s FIB weight and preference are attributes of a path not of a route. The 
weight controls [un]equal cost load-balancing across the paths and preference 
controls which paths to use when they are [un]available (i.e. BFD down), a kind 
of poor man’s fast re-route.

It’s my understanding that Linux preference/metric applies to the route and is 
set based on the admin distance of the route’s originator (e.g. static, OSPF, 
etc). The route with the best metric/AD is the one used for forwarding, this is 
route arbitration performed by a RIB, only the route with the best metric/AD 
should be programmed into a forwarding table and hence programmed into VPP’s 
FIB.

/neale

From:  on behalf of Dimitar Ivanov 
Date: Wednesday 15 April 2020 at 14:52
To: "vpp-dev@lists.fd.io" 
Subject: [vpp-dev] frp_preference and frp_weight size #vnet

Hi,
 I'm working with vers.19.08 and see something that cannot understand. 
Currently in FIB route path definition preference and weight are u8. In same 
time preference(metric) in Linux kernel is 32 bit value. My target is to inject 
routes in VPP and to keep same parameters like in Linux kernel. So here i face 
the conflict. And this is most visible when examine IPv6 routing table in 
Linux, where default metric/preference of default route is 1024. Question is 
how to overcome this problem where is possible Linux kernel to have routes with 
metric bigger than 255 and in same time VPP Fib do not allow this ? I saw that 
with this patch https://gerrit.fd.io/r/c/vpp/+/7586 is introduced preference 
and weight become from u32 to u16. Now weight and preference are u8. Is there 
some plans VPP Fib to accepts preference bigger than u8 ? Is there some 
workaround for this problem ?
Regards,
 Dimitar
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#16086): https://lists.fd.io/g/vpp-dev/message/16086
Mute This Topic: https://lists.fd.io/mt/73031162/21656
Mute #vnet: https://lists.fd.io/mk?hashtag=vnet&subid=1480452
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [vpp-dev] worker barrier state

[Neale Ranns via lists.fd.io]

Hi Chris,

Comments inline...

On 15/04/2020 15:14, "Christian Hopps"  wrote:

Hi Neale,

I agree that something like 4, is probably the correct approach. I had a 
side-meeting with some of the ARM folks (Govind and Honnappa), and we thought 
using a generation number for the state rather than just waiting "long-enough" 
to recycle it could work. The generation number would be the atomic value 
associated with the state. So consider this API:

 - MP-safe pools store generation numbers alongside each object.
 - When you allocate a new object from the pool you get an index and 
generation number.
 - When storing the object index you also save the generation number.
 - When getting a pointer to the object you pass the API the index and 
generation number and it will return NULL if the generation number did not 
match the one stored with the object in the pool.
 - When you delete a pool object its generation number is incremented (with 
barrier).

The size of the generation number needs to be large enough to guarantee 
there is no wrap with objects still in the system that have stored the 
generation number. Technically this is a "long-enough" aspect of the scheme. :) 
One could imagine using less than 64 bits for the combination of index and 
generation, if that was important.

It's a good scheme, I like it.
I assume the pool indices would be 64 bit and the separation between vector 
index and generation would be hidden from the user. Maybe a 32 bit value would 
suffice in most cases, but why skimp...

The advantage over just waiting N seconds to recycle the index is that the 
system scales better, i.e., if you just wait N seconds to reuse, and are 
creating and deleting objects at a significant rate, your pool can blow up in 
the N seconds of time. With the generation number this is not a problem as you 
can re-use the object immediately. Another advantage is that you don't have to 
have the timer logic (looping per pool or processing all pools) to free up old 
indices.

Yes, for my time based scheme, the size of the pool will become dependent on 
some integration over a rate of change, which is not deterministic, which is 
not great, but I don't suppose all APIs are subject to large churn.
With the generation scheme the pool always requires more memory, since you're 
storing a generation value for each index, but being a deterministic size (even 
though probably bigger), I'd probably take that.
I wouldn't use timer logic in my scheme. I'd make the pool's free-list a fifo 
(as opposed to the stack it is today) and each entry in the list has the index 
and the time it was added. If t_now - t_head < t_wrap I can pull from the 
free-list, else the pool needs to grow.

The generation number scheme will still need the thread barrier to 
increment the generation number to make sure no-one is using the object in 
parallel. But this is a common problem with deleting non-reference-counted 
shared state I believe.

I don't think you strictly need the barrier, you can still use a 
make-before-break update. One downside of the generation approach is that nodes 
that try and fetch the state using the index will get NULL, so the only option 
is to drop, as opposed to what the make-before-break change determined. Mind 
you, this is probably fine for most practical purposes. Again if we're talking 
SAs, then at this point the SA is decoupled from the graph (i.e. it's no longer 
protecting the tunnel or it's not linked to a policy in the SPD), so drop is 
all we can do anyway.

When you mentioned packet counters, that's really a reference count I 
guess. The trade-off here seems to me to be 2 cache-line-invalidates per packet 
(once on ingress once on egress) for the counter vs a barrier hit (all packet 
processing stops) per delete of the state. For your setup that you measured the 
packet counter solution how long does it spend from the barrier sync request to 
release (i.e., how long is the system not processing packets)?

As an example in the basic test setup I had that measured the increase in clock 
cycles for adj counters, here's the time taken for the CLI to execute the 
addition of two ipsec tunnels:
   3.786220665: cli-cmd: create ipsec tunnel
   3.786540648: cli-cmd: create ipsec tunnel OK
   3.786544389: cli-cmd: create ipsec tunnel
   3.786577392: cli-cmd: create ipsec tunnel OK

(collected with 'elog trace cli' and 'sh event-logger')

I see it as a trade-off between a cost for every packet forwarded versus how 
many may be dropped during API calls. I wouldn't want the scheme employed to 
ensure safe delete to affect the overall packet through put - most of the time 
I'm not changing the state...

Now we have a few potential schemes in mind, IIRC you focus was on the deletion 
of SAs. Can you remind me again what additional state you had associated with 
the SA that you needed to deal with.


/neale


Thanks,
Chris.

> On Apr 15, 2020, at 

Re: [vpp-dev] vpp project committer nomination: Benoit Ganne

[Neale Ranns via lists.fd.io]

+1

/neale

On 21/04/2020 13:40, "vpp-dev@lists.fd.io on behalf of Dave Barach via 
lists.fd.io"  
wrote:

Vpp project committers: please vote +1, 0, -1 on the 
mailto:vpp-dev@lists.fd.io mailer as to whether we should add Benoit Ganne as a 
vpp project committer. 

Ben has about 150 merged patches, see 
https://gerrit.fd.io/r/q/status:merged+owner:bganne%2540cisco.com. He has 
expressed interest in the role, and I believe that he will make a fine 
committer.

Thanks... Dave

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

View/Reply Online (#16131): https://lists.fd.io/g/vpp-dev/message/16131
Mute This Topic: https://lists.fd.io/mt/73170252/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] DPO leak in various tunnel types (gtpu, geneve, vxlan, ...)

[Neale Ranns via lists.fd.io]

Hi Nick,

A +1 from me for the VPP change, thank you.
I’m all for UT too, but I’ll let some others review the UT first before I merge.

/neale

From:  on behalf of Nick Zavaritsky 

Date: Tuesday 21 April 2020 at 14:57
To: "vpp-dev@lists.fd.io" 
Subject: [vpp-dev] DPO leak in various tunnel types (gtpu, geneve, vxlan, ...)

Dear VPP hackers,

We are spawning and destroying GTPU tunnels at a high rate. Only 10K tunnels 
ever exist simultaneously in our test.

With default settings, we observe out of memory error in load_balance_create 
after approximately .5M tunnel create commands. Apparently, load balancers are 
leaking.

As far as my understanding goes, a load_balancer is first created in 
fib_entry_track, to get notifications about the route changes. This is only 
created once for a unique DIP and the refcount is correctly decremented once 
the last subscription ceases.

The refcount is also bumped in gtpu_tunnel_restack_dpo, when next_dpo is 
updated. Since the later is never reset, the refcount never drops to zero.

This is straightforward to exercise in CLI: create and immediately destroy 
several GTPU tunnels. Compare `show dpo memory` output before and after.

It looks like other tunnel types, namely geneve, vxlan, vxlan-gpe and vxlan-gbp 
are also susceptible.

My take was to add a call to dpo_reset in add_del_tunnel delete path. Please 
take a look at the patch: https://gerrit.fd.io/r/c/vpp/+/26617

Note: was unable to make a test case for vxlan and vxlan-gbp since they don't 
point next_dpo at a load balancer but rather at a dpo picked up from a bucket 
in the load balancer.

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

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

[Neale Ranns via lists.fd.io]

Or in the latest version you can create ACLs on the CLI:
  set acl-plugin acl ?
  set acl-plugin interface ?

/neale

From:  on behalf of Andrew Yourtchenko 
Date: Wednesday 29 April 2020 at 10:59
To: Govindarajan Mohandoss 
Cc: "John Lo (loj)" , Paul Vinciguerra 
, "vpp-dev@lists.fd.io" , nd 
, Lijian Zhang , Jieqiang Wang 

Subject: Re: [vpp-dev] ACL question

Hi Govind,

1) make an api trace and inspect the message there - whether it contains the 
entries you are expecting.

1a) If it does, then you can trivially recreate the same message using the 
python api just by hacking an existing testcase.

1b) if it doesn’t - run the vat itself under gdb and trace how the api message 
is built before it’s sent. I suspect what you are seeing is some issue between 
the command line that you are putting in and the api message being formed.

Also, it may give more clues if you do the above side by side on x86 and arm 
and compare the behaviors.

--a


On 29 Apr 2020, at 06:27, Govindarajan Mohandoss 
 wrote:
Hi Andrew,
   I have to work on make test test case. Before that, I would like to confirm 
whether this is a problem (or) misconfiguration.
   I added 50 rules using acl_add_replace in VAT CLI.  In the ACL dump (show 
acl-plugin acl 0), only 48 rules are present. 2 rules are missing and a default 
rule of “permit all” is also getting added.
   I have put the ACL config and ACL dump info in the attached file.


Thanks
Govind

From: John Lo (loj) 
Sent: Tuesday, April 28, 2020 10:38 PM
To: Govindarajan Mohandoss ; Paul Vinciguerra 

Cc: Andrew 👽 Yourtchenko ; vpp-dev@lists.fd.io; nd 
; Lijian Zhang ; Jieqiang Wang 
; nd 
Subject: RE: [vpp-dev] ACL question

Try “make test TEST=acl_plugin”.   -John

From: vpp-dev@lists.fd.io 
mailto:vpp-dev@lists.fd.io>> On Behalf Of Govindarajan 
Mohandoss
Sent: Tuesday, April 28, 2020 11:22 PM
To: Paul Vinciguerra 
mailto:pvi...@vinciconsulting.com>>
Cc: Andrew 👽 Yourtchenko mailto:ayour...@gmail.com>>; 
vpp-dev@lists.fd.io; nd 
mailto:n...@arm.com>>; Lijian Zhang 
mailto:lijian.zh...@arm.com>>; Jieqiang Wang 
mailto:jieqiang.w...@arm.com>>; nd 
mailto:n...@arm.com>>
Subject: Re: [vpp-dev] ACL question

Hi Paul,
  How can I selectively run only the test_acl_plugin.py instead of running make 
test ?

Thanks
Govind

From: Paul Vinciguerra 
mailto:pvi...@vinciconsulting.com>>
Sent: Tuesday, April 28, 2020 9:22 PM
To: Govindarajan Mohandoss 
mailto:govindarajan.mohand...@arm.com>>
Cc: Andrew 👽 Yourtchenko mailto:ayour...@gmail.com>>; 
vpp-dev@lists.fd.io; nd 
mailto:n...@arm.com>>; Lijian Zhang 
mailto:lijian.zh...@arm.com>>; Jieqiang Wang 
mailto:jieqiang.w...@arm.com>>
Subject: Re: [vpp-dev] ACL question

See: src/plugins/acl/test/test_acl_plugin.py

On Tue, Apr 28, 2020 at 7:19 PM Govindarajan Mohandoss 
mailto:govindarajan.mohand...@arm.com>> wrote:
Sure Andrew. Is there a unit test case for ACL plugin ?

From: Andrew 👽 Yourtchenko mailto:ayour...@gmail.com>>
Sent: Tuesday, April 28, 2020 4:57 PM
To: Govindarajan Mohandoss 
mailto:govindarajan.mohand...@arm.com>>
Cc: vpp-dev@lists.fd.io; nd 
mailto:n...@arm.com>>; Lijian Zhang 
mailto:lijian.zh...@arm.com>>; Jieqiang Wang 
mailto:jieqiang.w...@arm.com>>
Subject: Re: [vpp-dev] ACL question

1-3: no.
4: please make a “make test” test case illustrating the problem and share it.
--a

On 28 Apr 2020, at 22:37, Govindarajan Mohandoss 
mailto:govindarajan.mohand...@arm.com>> wrote:

Hi Andrew,

  I am working on ACL plugin SF+SL optimization on ARM servers.

  I am finding prefetches in ACL node is becoming bottle neck. I see 
performance improvements on both SL & SF mode, when SF mode bihash table 
related prefetching is disabled.

  I need some help with right ACL config to verify my patch.



 I did the testing with Ingress ACL -- 1 Rule and 50 Rules (Rule:  - DPORT is incremented). The Traffic match all the 50 rules.



  When I tried to add 100 rules on the same rule set in SF mode:

  "acl_add_replace -1 ipv4 permit+reflect src 
192.81.1.1/32 dst 192.82.1.1/32 
proto 17 sport 100 dport 1,

   ... ,

   ipv4 permit+reflect src 192.81.1.1/32 dst 
192.82.1.1/32 proto 17 sport 100 dport 100",



   I see only 48 rules in show tables and 48th rule is added as “permit” all 
and not “permit + reflect”. Does it mean <0 – 47> rules will be SF and the rest 
will be in SL mode ?



"

vpp# show acl-plugin acl

acl-index 0 count 49 tag {}

   0: ipv4 permit+reflect src 192.81.1.1/32 dst 
192.82.1.1/32 proto 17 sport 100 dport 1

   

  47: ipv4 permit+reflect src 192.81.1.1/32 dst 
192.82.1.1/32 proto 17 sport 100 dport 48

  48: ipv4 permit src 0.0.0.0/0 dst 
0.0.0.0/0 proto 0 sport 0-65535 dport 0-655

Re: [vpp-dev] ACL question

[Neale Ranns via lists.fd.io]

From: Govindarajan Mohandoss 
Date: Friday 1 May 2020 at 21:15
To: "Neale Ranns (nranns)" , Andrew Yourtchenko 

Cc: "John Lo (loj)" , Paul Vinciguerra 
, "vpp-dev@lists.fd.io" , nd 
, Lijian Zhang , Jieqiang Wang 
, nd 
Subject: RE: [vpp-dev] ACL question

Hi Neale,
  I tried to use the CLI for ACL in master. But the following command is not 
associating the ACL to ingress interface.
 Show command is not listing anything and “show run time” doesn’t show the ACL 
node.
  Am I missing any config ?

vpp# set acl-plugin acl permit+reflect src 192.81.1.1/32 dst 192.82.1.1/32 
proto 17 sport 100 dport 1
ACL index:0
vpp# show acl-plugin acl
acl-index 0 count 1 tag {cli}
  0: ipv4 permit+reflect src 192.81.1.1/32 dst 192.82.1.1/32 proto 17 
sport 100 dport 1
vpp# set acl-plugin ?
  set acl-plugin acl   set acl-plugin acl  src 
 dst  proto X sport X-Y dport X-Y [tag FOO] {use comma 
separated list for multiple rules}
  set acl-plugin interface set acl-plugin interface  
  [del]
  set acl-plugin   set acl-plugin session timeout {{udp 
idle}|tcp {idle|transient}} 
vpp# set acl-plugin interface TenGigabitEthernet7/0/0 input 0

you have to specify which ACL you want to bind to the interface:
 set acl-plugin interface TenGigabitEthernet7/0/0 input 0 acl 0

/neale

vpp# show acl-plugin interface   <<< No output.

Thanks
Govind

From: Neale Ranns (nranns) 
Sent: Wednesday, April 29, 2020 4:24 AM
To: Andrew Yourtchenko ; Govindarajan Mohandoss 

Cc: John Lo (loj) ; Paul Vinciguerra 
; vpp-dev@lists.fd.io; nd ; Lijian 
Zhang ; Jieqiang Wang 
Subject: Re: [vpp-dev] ACL question


Or in the latest version you can create ACLs on the CLI:
  set acl-plugin acl ?
  set acl-plugin interface ?

/neale

From: mailto:vpp-dev@lists.fd.io>> on behalf of Andrew 
Yourtchenko mailto:ayour...@gmail.com>>
Date: Wednesday 29 April 2020 at 10:59
To: Govindarajan Mohandoss 
mailto:govindarajan.mohand...@arm.com>>
Cc: "John Lo (loj)" mailto:l...@cisco.com>>, Paul Vinciguerra 
mailto:pvi...@vinciconsulting.com>>, 
"vpp-dev@lists.fd.io" 
mailto:vpp-dev@lists.fd.io>>, nd 
mailto:n...@arm.com>>, Lijian Zhang 
mailto:lijian.zh...@arm.com>>, Jieqiang Wang 
mailto:jieqiang.w...@arm.com>>
Subject: Re: [vpp-dev] ACL question

Hi Govind,

1) make an api trace and inspect the message there - whether it contains the 
entries you are expecting.

1a) If it does, then you can trivially recreate the same message using the 
python api just by hacking an existing testcase.

1b) if it doesn’t - run the vat itself under gdb and trace how the api message 
is built before it’s sent. I suspect what you are seeing is some issue between 
the command line that you are putting in and the api message being formed.

Also, it may give more clues if you do the above side by side on x86 and arm 
and compare the behaviors.

--a

On 29 Apr 2020, at 06:27, Govindarajan Mohandoss 
mailto:govindarajan.mohand...@arm.com>> wrote:
Hi Andrew,
   I have to work on make test test case. Before that, I would like to confirm 
whether this is a problem (or) misconfiguration.
   I added 50 rules using acl_add_replace in VAT CLI.  In the ACL dump (show 
acl-plugin acl 0), only 48 rules are present. 2 rules are missing and a default 
rule of “permit all” is also getting added.
   I have put the ACL config and ACL dump info in the attached file.


Thanks
Govind

From: John Lo (loj) mailto:l...@cisco.com>>
Sent: Tuesday, April 28, 2020 10:38 PM
To: Govindarajan Mohandoss 
mailto:govindarajan.mohand...@arm.com>>; Paul 
Vinciguerra mailto:pvi...@vinciconsulting.com>>
Cc: Andrew 👽 Yourtchenko mailto:ayour...@gmail.com>>; 
vpp-dev@lists.fd.io; nd 
mailto:n...@arm.com>>; Lijian Zhang 
mailto:lijian.zh...@arm.com>>; Jieqiang Wang 
mailto:jieqiang.w...@arm.com>>; nd 
mailto:n...@arm.com>>
Subject: RE: [vpp-dev] ACL question

Try “make test TEST=acl_plugin”.   -John

From: vpp-dev@lists.fd.io 
mailto:vpp-dev@lists.fd.io>> On Behalf Of Govindarajan 
Mohandoss
Sent: Tuesday, April 28, 2020 11:22 PM
To: Paul Vinciguerra 
mailto:pvi...@vinciconsulting.com>>
Cc: Andrew 👽 Yourtchenko mailto:ayour...@gmail.com>>; 
vpp-dev@lists.fd.io; nd 
mailto:n...@arm.com>>; Lijian Zhang 
mailto:lijian.zh...@arm.com>>; Jieqiang Wang 
mailto:jieqiang.w...@arm.com>>; nd 
mailto:n...@arm.com>>
Subject: Re: [vpp-dev] ACL question

Hi Paul,
  How can I selectively run only the test_acl_plugin.py instead of running make 
test ?

Thanks
Govind

From: Paul Vinciguerra 
mailto:pvi...@vinciconsulting.com>>
Sent: Tuesday, April 28, 2020 9:22 PM
To: Govindarajan Mohandoss 
mailto:govindarajan.mohand...@arm.com>>
Cc: Andrew 👽 Yourtchenko mailto:ayour...@gmail.com>>; 
vpp-dev@lists.fd.io; nd 
mailto:n...@arm.com>>; Lijian Zhang 
mailto:lijian.zh...@arm.com>>; Jieqiang Wang 
mailto:jieqiang.w...@arm.com>>
Subject: Re: [vpp-dev] ACL

Re: [vpp-dev] worker barrier state

[Neale Ranns via lists.fd.io]

Hi Chris,

With SAs there are two scenarios to consider for inflight packets
 1) the SA is unlinked
 2) the SA is deleted.

We've talked at length about how to deal with 2).
By 'unlinked' I mean that whatever config dictated that an SA be used has now 
gone (like tunnel protection or SPD policy). An inflight packet that is 
processed by an IPSec node would (by either scheme we discussed for 1)) 
retrieve the SA do encrypt/decrypt and then attempt to send the packet on its 
merry way; this is the point at which it could fail. I say 'could' because it 
depends on how the unlink affected the vlib graph. In today's tunnel protection 
esp_encrpyt does vnet_feature_next(), this is not going to end well once 
esp_encrypt is no longer a feature on the arc. In tomorrow's tunnel protection 
we'll change that:
   https://gerrit.fd.io/r/c/vpp/+/26265
and it should be safe. But, what if the next API removes the tunnel whilst 
there are still inflight packets? Is it still safe? Is it still correct to send 
encrypted tunnelled packets?

I think I'm coming round to the opinion that the safest way to approach this is 
to ensure that if the SA can be found, whatever state it is in (created, 
unlinked or deleted) then it needs to have a flag that states whether it should 
be used or the packet dropped. We'd update this state when the SA is 
[un]linked, with the barrier held.

On a somewhat related topic, you probably saw:
  https://gerrit.fd.io/r/c/vpp/+/26811
as an example of getting MP safe APIs wrong.

/neale

On 24/04/2020 16:34, "Christian Hopps"  wrote:


Hi Neale,

Comments also inline...

Neale Ranns (nranns)  writes:

> Hi Chris,
>
> Comments inline...
>
> On 15/04/2020 15:14, "Christian Hopps"  wrote:
>
> Hi Neale,
>
> I agree that something like 4, is probably the correct approach. I 
had a side-meeting with some of the ARM folks (Govind and Honnappa), and we 
thought using a generation number for the state rather than just waiting 
"long-enough" to recycle it could work. The generation number would be the 
atomic value associated with the state. So consider this API:
>
>  - MP-safe pools store generation numbers alongside each object.
>  - When you allocate a new object from the pool you get an index and 
generation number.
>  - When storing the object index you also save the generation number.
>  - When getting a pointer to the object you pass the API the index 
and generation number and it will return NULL if the generation number did not 
match the one stored with the object in the pool.
>  - When you delete a pool object its generation number is incremented 
(with barrier).
>
> The size of the generation number needs to be large enough to 
guarantee there is no wrap with objects still in the system that have stored 
the generation number. Technically this is a "long-enough" aspect of the 
scheme. :) One could imagine using less than 64 bits for the combination of 
index and generation, if that was important.
>
> It's a good scheme, I like it.
> I assume the pool indices would be 64 bit and the separation between 
vector index and generation would be hidden from the user. Maybe a 32 bit value 
would suffice in most cases, but why skimp...

I was thinking to keep the index and generation number separate at the most 
basic API, to allow for selecting the size of the each independently and for 
efficient storage. I'm thinking for some applications one might want to do 
something like

cacheline_packed_struct {
...
u32 foo_index;
u32 bar_index;
u16 foo_gen;
u16 bar_gen;
...
};

a set of general purpose macros could be created for combining the 2 values 
into a single integer value though.

> The advantage over just waiting N seconds to recycle the index is 
that the system scales better, i.e., if you just wait N seconds to reuse, and 
are creating and deleting objects at a significant rate, your pool can blow up 
in the N seconds of time. With the generation number this is not a problem as 
you can re-use the object immediately. Another advantage is that you don't have 
to have the timer logic (looping per pool or processing all pools) to free up 
old indices.
>
> Yes, for my time based scheme, the size of the pool will become dependent 
on some integration over a rate of change, which is not deterministic, which is 
not great, but I don't suppose all APIs are subject to large churn.
> With the generation scheme the pool always requires more memory, since 
you're storing a generation value for each index, but being a deterministic 
size (even though probably bigger), I'd probably take that.
> I wouldn't use timer logic in my scheme. I'd make the pool's free-list a 
fifo (as opposed to the stack it is today) and each entry in the list has the 
index and the time it was added. If t_now - t_head < t_wrap I

Re: [vpp-dev] DPO leak in various tunnel types (gtpu, geneve, vxlan, ...)

[Neale Ranns via lists.fd.io]

Hi Andrew,

They’re the first UT I’ve seen that screen scrape show output. I wasn’t sure 
this was acceptable practice. But if I had a better alternative I’d have 
suggested it already…

/neale

From: Andrew 👽 Yourtchenko 
Date: Wednesday 6 May 2020 at 15:45
To: Nick Zavaritsky 
Cc: "vpp-dev@lists.fd.io" , "Neale Ranns (nranns)" 

Subject: Re: [vpp-dev] DPO leak in various tunnel types (gtpu, geneve, vxlan, 
...)

Nick,

Fixes are always good, and especially with the UTs, so thanks a lot !

I took a glance at the UTs...

one question and the bigger remark:

1) The UT stuff looks fairly straightforward except the tests are IPv4-only - 
is it enough test only one address family ? If yes - a comment inside the UT 
would be cool..

2) the deletion of ipv6 parameter in vpp_papi_provider.py seems like some stray 
unrelated change which sneaked in ? (That’s actually what made me to -1).

That’s the only two things I could see, the UTs seem fairly straightforward.

--a


On 6 May 2020, at 13:55, Nick Zavaritsky  wrote:
Dear VPP hackers,

May I kindly ask to do a code review of the proposed fix?

Thanks,
N



On 21. Apr 2020, at 15:15, Neale Ranns (nranns) 
mailto:nra...@cisco.com>> wrote:

Hi Nick,

A +1 from me for the VPP change, thank you.
I’m all for UT too, but I’ll let some others review the UT first before I merge.

/neale

From: mailto:vpp-dev@lists.fd.io>> on behalf of Nick 
Zavaritsky mailto:nick.zavarit...@emnify.com>>
Date: Tuesday 21 April 2020 at 14:57
To: "vpp-dev@lists.fd.io" 
mailto:vpp-dev@lists.fd.io>>
Subject: [vpp-dev] DPO leak in various tunnel types (gtpu, geneve, vxlan, ...)

Dear VPP hackers,

We are spawning and destroying GTPU tunnels at a high rate. Only 10K tunnels 
ever exist simultaneously in our test.

With default settings, we observe out of memory error in load_balance_create 
after approximately .5M tunnel create commands. Apparently, load balancers are 
leaking.

As far as my understanding goes, a load_balancer is first created in 
fib_entry_track, to get notifications about the route changes. This is only 
created once for a unique DIP and the refcount is correctly decremented once 
the last subscription ceases.

The refcount is also bumped in gtpu_tunnel_restack_dpo, when next_dpo is 
updated. Since the later is never reset, the refcount never drops to zero.

This is straightforward to exercise in CLI: create and immediately destroy 
several GTPU tunnels. Compare `show dpo memory` output before and after.

It looks like other tunnel types, namely geneve, vxlan, vxlan-gpe and vxlan-gbp 
are also susceptible.

My take was to add a call to dpo_reset in add_del_tunnel delete path. Please 
take a look at the patch: https://gerrit.fd.io/r/c/vpp/+/26617

Note: was unable to make a test case for vxlan and vxlan-gbp since they don't 
point next_dpo at a load balancer but rather at a dpo picked up from a bucket 
in the load balancer.

Best,
N


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

View/Reply Online (#16264): https://lists.fd.io/g/vpp-dev/message/16264
Mute This Topic: https://lists.fd.io/mt/73171448/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 tunnel interfaces?

[Neale Ranns via lists.fd.io]

Hi Chris,

They were replaced by ipip interfaces protected by SAs:
  https://wiki.fd.io/view/VPP/IPSec#Tunnel_Mode

the tunnel always adds encap. You can configure your SA to add additional encap 
if you want.

/neale


From:  on behalf of Christian Hopps 
Date: Wednesday 6 May 2020 at 14:32
To: vpp-dev 
Cc: Christian Hopps 
Subject: [vpp-dev] IPsec tunnel interfaces?

Hi, vpp-dev,

Post 19.08 seems to have removed IPsec logical interfaces.

One cannot always use transport mode IPsec.

How can I get the efficiency of route based (FIB) IPsec w/o transport mode? 
Adding superfluous encapsulations (wasting bandwidth) to replace this 
(seemingly lost, hope not) functionality is not an option.

Thanks,
Chris.

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

View/Reply Online (#16265): https://lists.fd.io/g/vpp-dev/message/16265
Mute This Topic: https://lists.fd.io/mt/74027328/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 tunnel interfaces?

[Neale Ranns via lists.fd.io]

Hi Chris,

On 07/05/2020 16:55, "Christian Hopps"  wrote:



> On May 7, 2020, at 8:15 AM, Neale Ranns (nranns)  wrote:
> 
>  
> Hi Chris,
>  
> They were replaced by ipip interfaces protected by SAs:
>   https://wiki.fd.io/view/VPP/IPSec#Tunnel_Mode
>  
> the tunnel always adds encap. You can configure your SA to add additional 
encap if you want.

Ok, but that's not a replacement for the old functionality, right? The old 
functionality had the SA tunnel represented as an unnumbered interface that 
could be routed onto efficiently using the FIB. The unnumbered interface used 
the SA tunnel endpoint addresses.

It is intended to be a replacement. If it's not then there's a problem and I'll 
address it.

Both old an new have one critical thing in common, there's an interface and an 
inbound and outbound SA.
The old functionality had a ip-in-ip interface tightly coupled to two SAs, so 
tight that there was a dedicated interface type, ipsecX, and the interface and 
SAs were configured at the same time. In the new model that coupling is loose; 
there's a ipip interface and its associated SAs, they are configured 
independently and bound together.
If you made the ipsecX unnumbered you now make the ipipX unnumbered. If you had 
routes through ipsecX, now you route through IpipX.

The wiki shows the that SA tunnel mode is re-encapsulating the already 
encapsulated IP-IP tunnel traffic. So now I have 3 IP headers instead of the 2 
IP headers as before?

If an SA is in transport mode it does not add headers, if it's in tunnel mode 
it does. When a packet egresses the tunnel it is encapped by that tunnel, if 
you don't want another set of IP headers then configure the SA that protects 
the tunnel to be in transport mode. 

Putting aside the wasted IP header bandwidth for the moment though, I don't 
understand what's actually supposed to be happening here. What does the 
configuration look like? I have an SA with endpoints (Local-IP,Remote-IP) and I 
have user traffic with (User-SIP,User-DIP). Previously I had an unnumbered 
interface that used the SAs (Local-IP,Remote-IP) for it's IP header. I then 
routed traffic for (User-DIP) over that unnumbered interface. How does one 
configure that with this ipip tunnel replacement?

create ipip src Local-IP dst remote-IP
set int unnum ipip0 use Eth0
ipsec sa add id 5 [crypto .. ] [integ ..] mode=transport
ipsec sa add id 6 [crypto .. ] [integ ..] mode=transport
ipsec tun protect ipip0 in 5 out 6
set int state ipip0 up

ip route User-DIP/32 via ipip0

does that get you what you need?

I did read through the Wiki and it seems that this change was motivated by 
wanting to cleanup the IPsec API, but that hardly seems like justification to 
eliminate the efficient use of an entire variant of commonly used IPsec 
functionality.

Cleaning up the API was one motivation. It was a pain that each time we added 
new attributes to SA creation (like ESN, UDP, algo=foo) (for use with the SPD) 
we had to make similar changes to both the ipsec and ipsec_gre create APIs. The 
other motivation was removing 2 interface types that did exactly the same as 
the existing ipip and gre tunnels (and the same goes for their APIs too, like 
how do I configure what DCSP, ECN, DF to copy on encap/decap).

/neale



Could we bring back the functionality using more "acceptable to the 
project" APIs or something?

Thanks,
Chris.

>  
> /neale
>  
>  
> From:  on behalf of Christian Hopps 

> Date: Wednesday 6 May 2020 at 14:32
> To: vpp-dev 
> Cc: Christian Hopps 
> Subject: [vpp-dev] IPsec tunnel interfaces?
>  
> Hi, vpp-dev,
> 
> Post 19.08 seems to have removed IPsec logical interfaces.
> 
> One cannot always use transport mode IPsec.
> 
> How can I get the efficiency of route based (FIB) IPsec w/o transport 
mode? Adding superfluous encapsulations (wasting bandwidth) to replace this 
(seemingly lost, hope not) functionality is not an option.
> 
> Thanks,
> Chris.
> 


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

View/Reply Online (#16275): https://lists.fd.io/g/vpp-dev/message/16275
Mute This Topic: https://lists.fd.io/mt/74027328/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 tunnel interfaces?

[Neale Ranns via lists.fd.io]

From:  on behalf of Christian Hopps 
Date: Thursday 7 May 2020 at 23:27
To: "Neale Ranns (nranns)" 
Cc: Christian Hopps , vpp-dev 
Subject: Re: [vpp-dev] IPsec tunnel interfaces?



> On May 7, 2020, at 1:41 PM, Neale Ranns (nranns)  wrote:
>
>
> Hi Chris,
>
> On 07/05/2020 16:55, "Christian Hopps"  wrote:
>
>
>
>> On May 7, 2020, at 8:15 AM, Neale Ranns (nranns)  wrote:
>>
>>
>> Hi Chris,
>>
>> They were replaced by ipip interfaces protected by SAs:
>>  https://wiki.fd.io/view/VPP/IPSec#Tunnel_Mode
>>
>> the tunnel always adds encap. You can configure your SA to add additional 
>> encap if you want.
>
>Ok, but that's not a replacement for the old functionality, right? The old 
> functionality had the SA tunnel represented as an unnumbered interface that 
> could be routed onto efficiently using the FIB. The unnumbered interface used 
> the SA tunnel endpoint addresses.
>
> It is intended to be a replacement. If it's not then there's a problem and 
> I'll address it.

Great. :)

>
> Both old an new have one critical thing in common, there's an interface and 
> an inbound and outbound SA.
> The old functionality had a ip-in-ip interface tightly coupled to two SAs, so 
> tight that there was a dedicated interface type, ipsecX, and the interface 
> and SAs were configured at the same time. In the new model that coupling is 
> loose; there's a ipip interface and its associated SAs, they are configured 
> independently and bound together.
> If you made the ipsecX unnumbered you now make the ipipX unnumbered. If you 
> had routes through ipsecX, now you route through IpipX.
>
>The wiki shows the that SA tunnel mode is re-encapsulating the already 
> encapsulated IP-IP tunnel traffic. So now I have 3 IP headers instead of the 
> 2 IP headers as before?
>
> If an SA is in transport mode it does not add headers, if it's in tunnel mode 
> it does. When a packet egresses the tunnel it is encapped by that tunnel, if 
> you don't want another set of IP headers then configure the SA that protects 
> the tunnel to be in transport mode.

So with the old functionality the interface was unnumbered, and used the SA 
endpoint IPs for the it's encapsulating IP header. Using it with SA in tunnel 
mode did not produce 3 IP headers. That's what we need to fix I guess, it 
should only produce 2 IP headers, the user's and the SA tunnel IP header.
You still have the choice to make the ipip interface unnumbered, or you can 
assign it a subnet. Or if it’s an L2 interface (like the old ipsec-gre was and 
the new protected GRE interface can be) you can add it to a BD. The end points 
of the tunnel are your choice.


>Putting aside the wasted IP header bandwidth for the moment though, I 
> don't understand what's actually supposed to be happening here. What does the 
> configuration look like? I have an SA with endpoints (Local-IP,Remote-IP) and 
> I have user traffic with (User-SIP,User-DIP). Previously I had an unnumbered 
> interface that used the SAs (Local-IP,Remote-IP) for it's IP header. I then 
> routed traffic for (User-DIP) over that unnumbered interface. How does one 
> configure that with this ipip tunnel replacement?
>
> create ipip src Local-IP dst remote-IP
> set int unnum ipip0 use Eth0
> ipsec sa add id 5 [crypto .. ] [integ ..] mode=transport
> ipsec sa add id 6 [crypto .. ] [integ ..] mode=transport
> ipsec tun protect ipip0 in 5 out 6
> set int state ipip0 up
>
> ip route User-DIP/32 via ipip0
>
> does that get you what you need?

No, using transport mode IPsec is not an option. It must be an SA in standard 
tunnel mode. And it can't have 3 IP headers. :)
if your original packet that is routed into the tunnel was:
  [ IP (user-DIP, user-SIP) | TCP | Payload ]
Then the above configuration will give you:
 [ MAC | [ IP (tun-DIP, tun-SIP ) | ESP | IP (User-DIP, User-SIP) | TCP | 
Payload ]
If you didn’t have protection on the tunnel interface, you’d get
 [ MAC | [ IP (tun-DIP, tun-SIP ) | IP (User-DIP, User-SIP) | TCP | Payload ]
So the SA acts like transport mode, i.e. it’s inserting the ESP header between 
the tunnel IP headers and the payload. This is what other uses are using as a 
replacement for the old config.
If your SA was in tunnel mode, then you’d get:
  [ MAC | [ IP (tun-DIP, tun-SIP ) | IP (SA-DIP, SA-SIP) | ESP | IP (User-DIP, 
User-SIP) | TCP | Payload ]
Which I think is the 3 headers you don’t want.
Are there other properties of a tunnel mode SA that you need that are lost with 
this approach?
/neale



Thanks,
Chris.


>
>I did read through the Wiki and it seems that this change was motivated by 
> wanting to cleanup the IPsec API, but that hardly seems like justification to 
> eliminate the efficient use of an entire variant of commonly used IPsec 
> functionality.
>
> Cleaning up the API was one motivation. It was a pain that each time we added 
> new attributes to SA creation (like ESN, UDP, algo=foo) (for use with the 
> SPD) we had to make similar changes to both the ipsec and ipsec

Re: [vpp-dev] IPsec tunnel interfaces?

[Neale Ranns via lists.fd.io]

Hi Chris,

> Are there other properties of a tunnel mode SA that you need that are lost 
> with this approach?

I need to use tunnel mode SAs provided by IKEv2. Transport mode is an optional 
(normally on-the-wire IKEv2 negotiated) feature of IPsec. These tunnel mode SAs 
will have IPTFS enabled on them, and that functionality is only defined for 
IPsec tunnel mode SAs.

The only difference in VPP between a transport and tunnel mode SA is the 
presence of the encap. So I think it’s fair to say that what you need is an 
interface to interact with the L[23] system, ‘encap’ to describe how to 
encap/decap packets (i.e. what to copy from overlay/underlay (DSCP, ECN, etc) 
and an SA (for the algo set);
  Interface + encap + SA
VPP doesn’t model encap separately. So it’s a question of where you add the 
parenthesis.
  (interface + encap) + SA = ipip tunnel + transport mode SA
Or
  Interface + (encap + SA) = ipsec dedicated interface + tunnel mode SA
In both cases the same information is available, it’s just modelled 
differently. The first model is used since it reuses the types/functionality 
that VPP already has to support other use case, without the need for a 
dedicated interface type. Is it not possible for you to work with the first 
model, or is it less convenient?
/neale


There will be future work in IETF/ipsecme to enable a form of transport mode 
support in IPTFS to handle the Cisco-preferred GRE with transport mode IPsec 
configuration, but that is not available today, and obviously won't be the only 
option standardized.

Thanks,
Chris.


> /neale
>
>
>
>
>
>
> Thanks,
> Chris.
>
>
> >
> >I did read through the Wiki and it seems that this change was motivated 
> > by wanting to cleanup the IPsec API, but that hardly seems like 
> > justification to eliminate the efficient use of an entire variant of 
> > commonly used IPsec functionality.
> >
> > Cleaning up the API was one motivation. It was a pain that each time we 
> > added new attributes to SA creation (like ESN, UDP, algo=foo) (for use with 
> > the SPD) we had to make similar changes to both the ipsec and ipsec_gre 
> > create APIs. The other motivation was removing 2 interface types that did 
> > exactly the same as the existing ipip and gre tunnels (and the same goes 
> > for their APIs too, like how do I configure what DCSP, ECN, DF to copy on 
> > encap/decap).
> >
> > /neale
> >
> >
> >
> >Could we bring back the functionality using more "acceptable to the 
> > project" APIs or something?
> >
> >Thanks,
> >Chris.
> >
> >>
> >> /neale
> >>
> >>
> >> From:  on behalf of Christian Hopps 
> >> 
> >> Date: Wednesday 6 May 2020 at 14:32
> >> To: vpp-dev 
> >> Cc: Christian Hopps 
> >> Subject: [vpp-dev] IPsec tunnel interfaces?
> >>
> >> Hi, vpp-dev,
> >>
> >> Post 19.08 seems to have removed IPsec logical interfaces.
> >>
> >> One cannot always use transport mode IPsec.
> >>
> >> How can I get the efficiency of route based (FIB) IPsec w/o transport 
> >> mode? Adding superfluous encapsulations (wasting bandwidth) to replace 
> >> this (seemingly lost, hope not) functionality is not an option.
> >>
> >> Thanks,
> >> Chris.
> >>
>
>

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

View/Reply Online (#16291): https://lists.fd.io/g/vpp-dev/message/16291
Mute This Topic: https://lists.fd.io/mt/74027328/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 tunnel interfaces?

[Neale Ranns via lists.fd.io]

From:  on behalf of Christian Hopps 
Date: Sunday 10 May 2020 at 14:33
To: "Neale Ranns (nranns)" 
Cc: Christian Hopps , vpp-dev 
Subject: Re: [vpp-dev] IPsec tunnel interfaces?

> On May 9, 2020, at 7:23 AM, Neale Ranns via lists.fd.io 
>  wrote:
>
>
>
> Hi Chris,
>
>
> > Are there other properties of a tunnel mode SA that you need that are lost 
> > with this approach?
>
> I need to use tunnel mode SAs provided by IKEv2. Transport mode is an 
> optional (normally on-the-wire IKEv2 negotiated) feature of IPsec. These 
> tunnel mode SAs will have IPTFS enabled on them, and that functionality is 
> only defined for IPsec tunnel mode SAs.
>
>
> The only difference in VPP between a transport and tunnel mode SA is the 
> presence of the encap. So I think it’s fair to say that what you need is an 
> interface to interact with the L[23] system, ‘encap’ to describe how to 
> encap/decap packets (i.e. what to copy from overlay/underlay (DSCP, ECN, etc) 
> and an SA (for the algo set);
>
>   Interface + encap + SA
>
> VPP doesn’t model encap separately. So it’s a question of where you add the 
> parenthesis.
>
>   (interface + encap) + SA = ipip tunnel + transport mode SA
>
> Or
>
>   Interface + (encap + SA) = ipsec dedicated interface + tunnel mode SA
>
> In both cases the same information is available, it’s just modelled 
> differently. The first model is used since it reuses the types/functionality 
> that VPP already has to support other use case, without the need for a 
> dedicated interface type. Is it not possible for you to work with the first 
> model, or is it less convenient?

SO, I have implemented https://tools.ietf.org/html/draft-ietf-ipsecme-iptfs-01 
in VPP 19.08. The functionality is working as specified in the draft using 
tunnel mode SAs.

Conceptually what happens (commonly) is this:


Pkt   Pkt Single IPsec 
Tunnel Pkt
---   --- 
--
[UA]..[Un] ---> user-intf [ VPP ] sa-tunnel-intf ---> [IP(SATunnel) + ESP + 
[UA]..[Un][Pad]]


The encpasulation *has* to occur at the SA tunnel point, not pre-encapsulated 
by a generic IP-IP interface with a transport mode SA attached to it downstream.

This is the condition I don’t fully understand….


The key here is that there is not a 1-1 mapping of user IP packets to IPsec 
packets. FWIW, this isn't just a problem for this particular IPTFS technology, 
there are other simple cases (e.g., sending only pad IPsec packets for limited 
traffic flow confidentiality) where there is not a 1-1 mapping between user IP 
packets and SA tunnel mode packets.

Now, re-architecting IPTFS to exist outside of IPsec so that it could be a new 
generic IP tunnel technology is certainly a fun idea (topic for another 
thread), it's just not an option, or relevant to the functionality that appears 
to have been lost in VPP.

Here's a packet trace for how this works (incoming ping):

USER-SIDE:

00:00:08:845351: dpdk-input
  ...
  ICMP echo_request checksum 0xaea9
00:00:08:845366: ethernet-input
00:00:08:845382: ip4-input-no-checksum
  ICMP: 11.11.11.253 -> 12.12.12.12
  ICMP echo_request checksum 0xaea9
00:00:08:845389: ip4-lookup
  ICMP: 11.11.11.253 -> 12.12.12.12
  ICMP echo_request checksum 0xaea9
00:00:08:845396: ip4-midchain
ICMP: 11.11.11.253 -> 12.12.12.12
ICMP echo_request checksum 0xaea9
00:00:08:845402: iptfs-encap4-tun
  sa_index: 1

At this point in old code, the packet does not have the tunnel encap added, it 
new code it does.



AGGREGATING AND QUEUEING OCCURS - The packet is encapsulated (along with any 
others currently waiting) into the next-to-be-sent IPTFS packet, which is 
queued to be sent on a timer from another thread, that output thread follows:


SEUCRE-SIDE:

Packet 1

This is the next IPTFS packet to send (in this case it just has the 1 ping 
packet inside but usually has multiple when there's real traffic):

 00:00:08:851581: handoff_trace
   HANDED-OFF: from thread 1 trace index 0
 00:00:08:851581: iptfs-output
 IPTFS Basic Header: flags: 0 resv 0 offset 0:[output gen: 526 pkt 0 of 1]:
 datablock  0: type: IPv4 offset:4 pktlen:   84
 datablock  1: type: Pad  offset:   88 pktlen: 1382

In old code here you present the next crypto node with your IPTFS ‘frame’, i.e. 
payload. In new code you need to present this frame with the tunnel encap 
prepended and correct (IIUC your draft correctly your not playing tricks with 
the outer IP header’s length, so you don’t need control over how the ESP 
header/footer is crafted – it’s the ‘normal’ way). You can either do this by 
preserving and updating the encap that was on one of the original buffers, or 
slap on a new one. You can query the tunnel’s encap similarly to the way 
ipsec_tun_pr

Re: [vpp-dev] IPsec tunnel interfaces?

[Neale Ranns via lists.fd.io]

On 11/05/2020 14:28, "Christian Hopps"  wrote:



> On May 11, 2020, at 7:50 AM, Neale Ranns (nranns)  
wrote:
> 
>  
>  
> From:  on behalf of Christian Hopps 

> Date: Sunday 10 May 2020 at 14:33
> To: "Neale Ranns (nranns)" 
> Cc: Christian Hopps , vpp-dev 
> Subject: Re: [vpp-dev] IPsec tunnel interfaces?
    >  
    > > On May 9, 2020, at 7:23 AM, Neale Ranns via lists.fd.io 
 wrote:
> > 
> >  
> > 
> > Hi Chris,
> > 
> > 
> > > Are there other properties of a tunnel mode SA that you need that are 
lost with this approach?
> > 
> > I need to use tunnel mode SAs provided by IKEv2. Transport mode is an 
optional (normally on-the-wire IKEv2 negotiated) feature of IPsec. These tunnel 
mode SAs will have IPTFS enabled on them, and that functionality is only 
defined for IPsec tunnel mode SAs.
> > 
> > 
> > The only difference in VPP between a transport and tunnel mode SA is 
the presence of the encap. So I think it’s fair to say that what you need is an 
interface to interact with the L[23] system, ‘encap’ to describe how to 
encap/decap packets (i.e. what to copy from overlay/underlay (DSCP, ECN, etc) 
and an SA (for the algo set);
> > 
> >   Interface + encap + SA
> > 
> > VPP doesn’t model encap separately. So it’s a question of where you add 
the parenthesis.
> > 
> >   (interface + encap) + SA = ipip tunnel + transport mode SA
> > 
> > Or
> > 
> >   Interface + (encap + SA) = ipsec dedicated interface + tunnel mode SA
> > 
> > In both cases the same information is available, it’s just modelled 
differently. The first model is used since it reuses the types/functionality 
that VPP already has to support other use case, without the need for a 
dedicated interface type. Is it not possible for you to work with the first 
model, or is it less convenient?
> 
> SO, I have implemented 
https://tools.ietf.org/html/draft-ietf-ipsecme-iptfs-01 in VPP 19.08. The 
functionality is working as specified in the draft using tunnel mode SAs.
> 
> Conceptually what happens (commonly) is this:
> 
>   
> Pkt   Pkt Single 
IPsec Tunnel Pkt
> ---   --- 
--
> [UA]..[Un] ---> user-intf [ VPP ] sa-tunnel-intf ---> [IP(SATunnel) + ESP 
+ [UA]..[Un][Pad]]
> 
> 
> The encpasulation *has* to occur at the SA tunnel point, not 
pre-encapsulated by a generic IP-IP interface with a transport mode SA attached 
to it downstream.
> 
> This is the condition I don’t fully understand….
> 
> 
> The key here is that there is not a 1-1 mapping of user IP packets to 
IPsec packets. FWIW, this isn't just a problem for this particular IPTFS 
technology, there are other simple cases (e.g., sending only pad IPsec packets 
for limited traffic flow confidentiality) where there is not a 1-1 mapping 
between user IP packets and SA tunnel mode packets.
> 
> Now, re-architecting IPTFS to exist outside of IPsec so that it could be 
a new generic IP tunnel technology is certainly a fun idea (topic for another 
thread), it's just not an option, or relevant to the functionality that appears 
to have been lost in VPP.
> 
> Here's a packet trace for how this works (incoming ping):
> 
> USER-SIDE:
> 
> 00:00:08:845351: dpdk-input
>   ...
>   ICMP echo_request checksum 0xaea9
> 00:00:08:845366: ethernet-input
> 00:00:08:845382: ip4-input-no-checksum
>   ICMP: 11.11.11.253 -> 12.12.12.12
>   ICMP echo_request checksum 0xaea9
> 00:00:08:845389: ip4-lookup
>   ICMP: 11.11.11.253 -> 12.12.12.12
>   ICMP echo_request checksum 0xaea9
> 00:00:08:845396: ip4-midchain
> ICMP: 11.11.11.253 -> 12.12.12.12
> ICMP echo_request checksum 0xaea9
> 00:00:08:845402: iptfs-encap4-tun
>   sa_index: 1
> 
> At this point in old code, the packet does not have the tunnel encap 
added, it new code it does.

Right, so this is the problem, at this point -- pre-ipsec encapsulation -- 
in the arc I am collecting (aggregating multiple user IP packets) into a single 
payload to send over the IPsec SA tunnel. I can't have IP-IP packets here.

It's not OK to have to strip off superfluous IP headers (thus having paid a 
price to have them added, only to be immediately removed in the next node in 
the graph) from all the user packets just so I can get back to the 
functionality I had before 20

Re: [vpp-dev] "set ip6 neighbor" not working on VPP v20.01

[Neale Ranns via lists.fd.io]

“set ip neighbor …”

/neale

From:  on behalf of Chinmaya Aggarwal 

Date: Tuesday 12 May 2020 at 14:43
To: "vpp-dev@lists.fd.io" 
Subject: [vpp-dev] "set ip6 neighbor" not working on VPP v20.01

Hi,
We have installed VPP v20.01 on a Centos machine, on executing command: -
vpp# set ip6 neighbor GigabitEthernet0/a/0 2001:5b0:abcd::121 52:54:00:98:29:e0
set ip6: unknown input `neighbor GigabitEthernet0/a/0 ...'
Error is  encountered. On checking the possible commands with "set ip6", we 
found: -
vpp# set ip6 ?
  set ip6 address  set ip6 address  [prefix 
group ]  [del]
  set ip6 classify set ip6 classify intfc  
table-index 
  set ip6 flow-hashset ip6 flow-hash table  
[src] [dst] [sport] [dport] [proto] [reverse]
  set ip6 nd proxy set ip6 nd proxy  
Neighbor is not present. Whereas, executing same on VPP v19.08 gives : -
vpp# set ip6 ?
  set ip6 address  set ip6 address  [prefix 
group ]  [del]
  set ip6 classify set ip6 classify intfc  
table-index 
  set ip6 flow-hashset ip6 flow-hash table  
[src] [dst] [sport] [dport] [proto] [reverse]
  set ip6 nd proxy set ip6 nd proxy  
  set ip6 neighbor set ip6 neighbor [del]  
  [static]
Neighbor option is present.

Does VPP v20.01 does not support "set ip6 neighbor"? If yes, what is the 
alternative for this?
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#16339): https://lists.fd.io/g/vpp-dev/message/16339
Mute This Topic: https://lists.fd.io/mt/74157335/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 when set ip addr at an interface and delete it at another interface

[Neale Ranns via lists.fd.io]

Hi Ye,

Thanks for the report and fix. Could you please push that patch to gerrit?

Regards,
neale

From:  on behalf of 叶东岗 
Date: Wednesday 13 May 2020 at 16:11
To: "vpp-dev@lists.fd.io" 
Subject: [vpp-dev] assert when set ip addr at an interface and delete it at 
another interface

root@ac15b50ac370:/# /usr/local/vpp20/bin/vppctl
_____   _  ___
 __/ __/ _ \  (_)__| | / / _ \/ _ \
 _/ _// // / / / _ \   | |/ / ___/ ___/
 /_/ /(_)_/\___/   |___/_/  /_/


DBGvpp# create tap
tap0
DBGvpp# create tap
tap1
DBGvpp# set interface ip addr tap0 1.1.1.1/24
DBGvpp# set interface ip addr del tap1 1.1.1.1/24


/usr/local/vpp20/bin/vpp[17762]: /work/vpp/src/vnet/ip/ip4_forward.c:656 
(ip4_sw_interface_enable_disable) assertion 
`im->ip_enabled_by_sw_if_index[sw_if_index] > 0' fails
/usr/local/vpp20/bin/vpp[17762]: received signal SIGWINCH, PC 0x7f9c3421899d
/usr/local/vpp20/bin/vpp[17762]: #0  0x7f9c34ad7ca8 unix_signal_handler + 
0x26f
/usr/local/vpp20/bin/vpp[17762]: #1  0x7f9c347fd890 0x7f9c347fd890
/usr/local/vpp20/bin/vpp[17762]: #2  0x7f9c34135e97 gsignal + 0xc7
/usr/local/vpp20/bin/vpp[17762]: #3  0x7f9c34137801 abort + 0x141
/usr/local/vpp20/bin/vpp[17762]: #4  0x556ba0b8641a 0x556ba0b8641a
/usr/local/vpp20/bin/vpp[17762]: #5  0x7f9c3451ae02 debugger + 0x9
/usr/local/vpp20/bin/vpp[17762]: #6  0x7f9c3451b1e5 _clib_error + 0x2d4
/usr/local/vpp20/bin/vpp[17762]: #7  0x7f9c3526bf3b 
ip4_sw_interface_enable_disable + 0x1ad
/usr/local/vpp20/bin/vpp[17762]: #8  0x7f9c3526cda7 
ip4_add_del_interface_address_internal + 0xd6c
/usr/local/vpp20/bin/vpp[17762]: #9  0x7f9c3526d077 
ip4_add_del_interface_address + 0x36
/usr/local/vpp20/bin/vpp[17762]: #10 0x7f9c352555ba add_del_ip_address + 
0x157
/usr/local/vpp20/bin/vpp[17762]: #11 0x7f9c34a2ad2e 
vlib_cli_dispatch_sub_commands + 0xc41
/usr/local/vpp20/bin/vpp[17762]: #12 0x7f9c34a2abac 
vlib_cli_dispatch_sub_commands + 0xabf
/usr/local/vpp20/bin/vpp[17762]: #13 0x7f9c34a2abac 
vlib_cli_dispatch_sub_commands + 0xabf
/usr/local/vpp20/bin/vpp[17762]: #14 0x7f9c34a2abac 
vlib_cli_dispatch_sub_commands + 0xabf

git  diff 1d61c2
diff --git a/src/vnet/ip/ip4_forward.c b/src/vnet/ip/ip4_forward.c
index ea78d5507..5d8be3621 100644
--- a/src/vnet/ip/ip4_forward.c
+++ b/src/vnet/ip/ip4_forward.c
@@ -779,7 +779,10 @@ ip4_add_del_interface_address_internal (vlib_main_t * vm,
  goto done;
}

-  ip_interface_address_del (lm, if_address_index, addr_fib);
+  error = ip_interface_address_del (lm, if_address_index, addr_fib,
+address_length, sw_if_index);
+  if (error)
+  goto done;
 }
   else
 {
diff --git a/src/vnet/ip/ip6_forward.c b/src/vnet/ip/ip6_forward.c
index 1d6c1b7f1..6b596dc69 100644
--- a/src/vnet/ip/ip6_forward.c
+++ b/src/vnet/ip/ip6_forward.c
@@ -428,7 +428,10 @@ ip6_add_del_interface_address (vlib_main_t * vm,
  goto done;
}

-  ip_interface_address_del (lm, if_address_index, addr_fib);
+  error = ip_interface_address_del (lm, if_address_index, addr_fib,
+address_length, sw_if_index);
+  if (error)
+goto done;
 }
   else
 {
diff --git a/src/vnet/ip/ip_interface.c b/src/vnet/ip/ip_interface.c
index 23c3df816..c6181ec68 100644
--- a/src/vnet/ip/ip_interface.c
+++ b/src/vnet/ip/ip_interface.c
@@ -90,14 +90,22 @@ ip_interface_address_add (ip_lookup_main_t * lm,
   return (NULL);
 }

-void
+clib_error_t *
 ip_interface_address_del (ip_lookup_main_t * lm,
- u32 address_index, void *addr_fib)
+ u32 address_index, void *addr_fib, u32 address_length,
+ u32 sw_if_index)
 {
   ip_interface_address_t *a, *prev, *next;

   a = pool_elt_at_index (lm->if_address_pool, address_index);

+  if (a->sw_if_index != sw_if_index) {
+  return clib_error_create ("%U not found for interface %U",
+ lm->format_address_and_length,
+ addr_fib, address_length,
+ format_vnet_sw_if_index_name,
+ vnet_get_main (), sw_if_index);
+  }
   if (a->prev_this_sw_interface != ~0)
 {
   prev = pool_elt_at_index (lm->if_address_pool,
@@ -121,6 +129,7 @@ ip_interface_address_del (ip_lookup_main_t * lm,
   mhash_unset (&lm->address_to_if_address_index, addr_fib,
   /* old_value */ 0);
   pool_put (lm->if_address_pool, a);
+  return NULL;
 }

 u8
diff --git a/src/vnet/ip/ip_interface.h b/src/vnet/ip/ip_interface.h
index f95b8deb0..95393381c 100644
--- a/src/vnet/ip/ip_interface.h
+++ b/src/vnet/ip/ip_interface.h
@@ -28,8 +28,9 @@ clib_error_t *ip_interface_address_add (ip_lookup_main_t * lm,
void *address,
u32 address_length,
u32 * result_index);
-void ip_interfac

Re: [vpp-dev] VPP - DPDK - No ARP learning on VPP and no ARP reply sent.

[Neale Ranns via lists.fd.io]

Hi Laurent,

ARP is enabled on an interface once it is assigned an IP address or is made 
unnumbered to another. You can check that ARP is enabled with:
  sh int feat VirtualFunctionEthernet0/5/0.101
and you won’t see ‘arp-disabled’ as a feature on the arp arc.

I suspect you are not receiving packets with tags and thus they hit your parent 
interface, which doesn’t have an address and is this ARP disabled. The packet 
traces will tell you if you RX packets with vlan tags.

/neale

From:  on behalf of Laurent Dumont 

Date: Friday 15 May 2020 at 13:57
To: Mrityunjay Kumar 
Cc: vpp-dev 
Subject: Re: [vpp-dev] VPP - DPDK - No ARP learning on VPP and no ARP reply 
sent.

Hi everyone!

Thank you for the tips

The VF is created with the Trust On and spoofcheck disabled during the instance 
creation.

vf 18 MAC fa:16:3e:92:30:f1, spoof checking off, link-state auto, trust on

I had a change to test this a bit more. It looks like the issue is specifically 
with passing tagged traffic between the TOR and VPP.

I've added the VLAN101 on the TOR and the following on the VPP side.

set interface state VirtualFunctionEthernet0/5/0 up
create sub-interfaces VirtualFunctionEthernet0/5/0 101
set interface state VirtualFunctionEthernet0/5/0.101 up
set interface ip address VirtualFunctionEthernet0/5/0.101 
100.100.101.2/24

vpp# show int address
VirtualFunctionEthernet0/5/0 (up):
VirtualFunctionEthernet0/5/0.101 (up):
  L3 100.100.101.2/24
local0 (dn):

But now, if I look at the packets in error.

vpp# show error
   CountNode  Reason
 5   dpdk-input   no error
   451  arp-disabled  ARP Disabled on this interface

Is there a way to "enable" ARP on the l3 interface?


On Fri, May 15, 2020 at 1:59 AM Mrityunjay Kumar 
mailto:kumarn...@gmail.com>> wrote:

This issue, we have seen on centos as well. Just for work around,

ip link set promisc on eth0   #[eth0 ---  PF interface]
ip link set eth00 vf 0 spoofchk off   #[give your vf id ]
ip link set eth0 vf 0 trust on,

, But you will see other packet on vpp VF interface as well.

Can you try with IPv6, you will see more surprises. :)
//MJ

Regards,
Mrityunjay Kumar.
Mobile: +91 - 9731528504


On Fri, May 15, 2020 at 7:55 AM Laurent Dumont 
mailto:laurentfdum...@gmail.com>> wrote:
Hi!

I was doing some initial experimentation with VPP/SRIOV/DPDK and I just wanted 
to see if some of the things I was experiencing we're expected. I was looking 
at understanding the baseline behavior for something like VPP + DPDK.

I have a small test POC with the following topology.

VM Ubuntu 18.04( with the "linux-image-extra-virtual" package) --->  (VPP + 
DPDK + IP address on the VPP interface) ---> VF ---> PF (compute with SRIOV on 
X710 cards) ---> TOR interface - untagged.

What I am seeing :
1.   VPP is telling me I have both RX and TX packets.
2.   That said, no ARP entry for the TOR is seen on VPP
3.   The interface on the TOR is also not seeing any ARP entry for the VPP 
interface. The TOR is also indicating that RX and TX packets are present.
Are there any inherent limitations to the ARP with VPP/DPDK?

One weird thing is that trying to show the ARP from VPP doesn't seem to be a 
valid command :
vpp# sh ip arp
show ip: unknown input `arp'

Here are some more debugging output.

vpp# show version
vpp v20.01-release built by root on 980ae64453f3 at 2020-01-29T22:13:47

vpp# show int address
VirtualFunctionEthernet0/5/0 (up):
  L3 1.2.3.4/31


vpp# show hardware-interfaces
  NameIdx   Link  Hardware
VirtualFunctionEthernet0/5/0   1 up   VirtualFunctionEthernet0/5/0
  Link speed: 10 Gbps
  Ethernet address fa:16:3e:92:30:f1
  Intel X710/XL710 Family VF
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 16), desc 1024 (min 64 max 4096 align 32)
tx: queues 1 (max 16), desc 1024 (min 64 max 4096 align 32)
pci: device 8086:154c subsystem 103c: address :00:05.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 jumbo-frame scatter
rx offload active: ipv4-cksum jumbo-frame scatter
tx offload avail:  vlan-insert ipv4-cksum udp-cksum tcp-cksum sctp-cksum
   tcp-tso outer-ipv4-cksum qinq-insert vxlan-tnl-tso
   gre-tnl-tso ipip-tnl-tso geneve-tnl-tso multi-segs
tx offload active: udp-cksum tcp-cksum multi-segs
rss avail: ipv4-frag ipv4-tcp ipv4-udp ipv4-sctp ipv4-other 
ipv6-frag
   ipv6-tcp ipv6-udp ipv6-sctp ipv6-other l2-payload
rss active:none
tx b

Re: [vpp-dev] IPSec - new bug

[Neale Ranns via lists.fd.io]

Hi Jan,

I’ll have a patch for you shortly.

/neale

From:  on behalf of "Jan Gelety via lists.fd.io" 

Reply to: "Jan Gelety -X (jgelety - PANTHEON TECH SRO at Cisco)" 

Date: Friday 22 May 2020 at 15:02
To: "vpp-dev@lists.fd.io" 
Cc: "csit-...@lists.fd.io" 
Subject: [vpp-dev] IPSec - new bug

Hello,

During CSIT tests we observed new bug in vpp related to ipsec on haswell – 
please, see Jira ticket VPP-1877:
https://jira.fd.io/browse/VPP-1877

Any chance to have it fixed till 20.05 release?

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

View/Reply Online (#16476): https://lists.fd.io/g/vpp-dev/message/16476
Mute This Topic: https://lists.fd.io/mt/74398375/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 - new bug

[Neale Ranns via lists.fd.io]

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

/neale

From:  on behalf of "Neale Ranns via lists.fd.io" 

Reply to: "Neale Ranns (nranns)" 
Date: Monday 25 May 2020 at 08:46
To: "Jan Gelety -X (jgelety - PANTHEON TECH SRO at Cisco)" , 
"vpp-dev@lists.fd.io" 
Cc: "csit-...@lists.fd.io" 
Subject: Re: [vpp-dev] IPSec - new bug


Hi Jan,

I’ll have a patch for you shortly.

/neale

From:  on behalf of "Jan Gelety via lists.fd.io" 

Reply to: "Jan Gelety -X (jgelety - PANTHEON TECH SRO at Cisco)" 

Date: Friday 22 May 2020 at 15:02
To: "vpp-dev@lists.fd.io" 
Cc: "csit-...@lists.fd.io" 
Subject: [vpp-dev] IPSec - new bug

Hello,

During CSIT tests we observed new bug in vpp related to ipsec on haswell – 
please, see Jira ticket VPP-1877:
https://jira.fd.io/browse/VPP-1877

Any chance to have it fixed till 20.05 release?

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

View/Reply Online (#16477): https://lists.fd.io/g/vpp-dev/message/16477
Mute This Topic: https://lists.fd.io/mt/74398375/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 crashes on configuring ip6 route

[Neale Ranns via lists.fd.io]

HI,

Thanks for the bug report. Here’s the patch:
  https://gerrit.fd.io/r/c/vpp/+/27270

/neale

From:  on behalf of "chu.penghong" 
Date: Monday 25 May 2020 at 05:06
To: "vpp-dev@lists.fd.io" 
Subject: [vpp-dev] vpp crashes on configuring ip6 route

Hello Everyone!
   When I add/delete ip6 route through cli when ipv6 packets are 
forwarding， the crash below may occur：

(gdb) bt
#0  __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:51
#1  0x7fdfe0b16801 in __GI_abort () at abort.c:79
#2  0x564c45de83ee in os_panic () at 
/home/pml/vpp/vpp_new/src/vpp/vnet/main.c:366
#3  0x7fdfe0ef9940 in debugger () at 
/home/pml/vpp/vpp_new/src/vppinfra/error.c:84
#4  0x7fdfe0ef9d15 in _clib_error (how_to_die=2, function_name=0x0, 
line_number=0, fmt=0x7fdfe26a6740 "%s:%d (%s) assertion `%s' fails") at 
/home/pml/vpp/vpp_new/src/vppinfra/error.c:143
#5  0x7fdfe1a81ba6 in ip6_fib_table_fwding_lookup (fib_index=0, 
dst=0x1002725d66) at /home/pml/vpp/vpp_new/src/vnet/fib/ip6_fib.h:100
#6  0x7fdfe1a82751 in ip6_lookup_inline (vm=0x7fdfa2bbf680, 
node=0x7fdfa3c07e40, frame=0x7fdfa39b3e00) at 
/home/pml/vpp/vpp_new/src/vnet/ip/ip6_forward.h:238
#7  0x7fdfe1a8502b in ip6_lookup_node_fn_avx2 (vm=0x7fdfa2bbf680, 
node=0x7fdfa3c07e40, frame=0x7fdfa39b3e00) at 
/home/pml/vpp/vpp_new/src/vnet/ip/ip6_forward.c:725
#8  0x7fdfe145abbb in dispatch_node (vm=0x7fdfa2bbf680, 
node=0x7fdfa3c07e40, type=VLIB_NODE_TYPE_INTERNAL, 
dispatch_state=VLIB_NODE_STATE_POLLING, frame=0x7fdfa39b3e00, 
last_time_stamp=2587675900683492)
at /home/pml/vpp/vpp_new/src/vlib/main.c:1238
#9  0x7fdfe145b37c in dispatch_pending_node (vm=0x7fdfa2bbf680, 
pending_frame_index=2, last_time_stamp=2587675900683492) at 
/home/pml/vpp/vpp_new/src/vlib/main.c:1406
#10 0x7fdfe145d01a in vlib_main_or_worker_loop (vm=0x7fdfa2bbf680, 
is_main=0) at /home/pml/vpp/vpp_new/src/vlib/main.c:1865
#11 0x7fdfe145da71 in vlib_worker_loop (vm=0x7fdfa2bbf680) at 
/home/pml/vpp/vpp_new/src/vlib/main.c:1999
#12 0x7fdfe149d13b in vlib_worker_thread_fn (arg=0x7fdf9fdec800) at 
/home/pml/vpp/vpp_new/src/vlib/threads.c:1799
#13 0x7fdfe0f18334 in clib_calljmp () at 
/home/pml/vpp/vpp_new/src/vppinfra/longjmp.S:123
#14 0x7fde27ffece0 in ?? ()
#15 0x7fdfe1497363 in vlib_worker_thread_bootstrap_fn (arg=0x7fdf9fdec800) 
at /home/pml/vpp/vpp_new/src/vlib/threads.c:588
Backtrace stopped: previous frame inner to this frame (corrupt stack?)

I read  the  code and found that the vector 'prefix_lengths_in_search_order' is 
modified  in funtion ip6_fib_table_fwding_dpo_update  when ip6 route is 
configured in main thread but accessed by function ip6_fib_table_fwding_lookup 
when ip6 packets are forwarding in worker thread without lock to proctect it . 
It may be the reason to the crash.
Thanks









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

View/Reply Online (#16498): https://lists.fd.io/g/vpp-dev/message/16498
Mute This Topic: https://lists.fd.io/mt/74450068/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 plugin optimization

[Neale Ranns via lists.fd.io]

Hi Govind,

As well as removing the prefetches, you've also removed the per packet call to 
acl_fa_find_session_with_hash(). So IIUC you've removed the per-packet session 
lookup and instead re-use the lookup of packet 0 each time. that'll make things 
quicker but it's not functionally correct.

/neale

On 27/05/2020 23:51, "vpp-dev@lists.fd.io on behalf of Andrew Yourtchenko" 
 wrote:

Hi Govind,

1) According to Jenkins, this patch permits some of the packets that
should be denied, hence JJB voted "-1".

2) If you suspect merely the prefetches are the issue, just commenting
out the body of prefetch_session_entry() in the original code should
turn it into a no-op that doesn't break anything.

Hard to say anything else given the functionality is not correct.

In general - ensure you run "EXTENDED_TESTS=y TEST=acl* make test" as
a sanity check before extensive perf-tests. It's not a 100% guarantee
but it does catch a few naughty cases.

Also - take a look at f1cd92d8d9, which got about 30% improvement back
in the day, and is the source of much of the trickiness in that node.

--a


On 5/27/20, Govindarajan Mohandoss  wrote:
> Hi Andrew,
>
>   While profiling the ACL plugin node using perf tool in ARM Neoverse
> platform, Bihash related prefetches were shown as bottleneck.
>
> Performance improvement is seen in ARM N1, TX2 and Intel Skylake servers
> after removing those prefetches. Testing is done with Ingress ACL/IPv4
> forwarding in both SF and SL modes.
>
> As the code change is common for Ingress/Egress ACL for both IPv4 and 
IPv6,
> performance improvement is expected for those cases also.
>
> Following are the test results for Ingress ACL / IPv4 / 1 core / 64B @ MRR
> in ARM N1, TX2 and Intel Skylake servers:
>
>
>
> Legend:
>
> ===
>
> N1 - ARM Neoverse
>
> TX2 - ARM Thunder X2
>
> SKX - Intel Skylake
>
> SL: % imp - Performance improvement in stateless mode
>
> SF: % imp - Performance improvement in stateful mode
>
>
>
>
>
>
> SKX
> N1
> TX2
> Num Rules
> Matching Rules
> SL: Avg % imp
> SF: Avg % imp
> SL: % imp
> SF: % imp
> SL: % imp
> SF: % imp
> 1
> 1
> 0.99
> 12.09
> 8.38
> 10.41
> 4.48
> 4.63
> 50
> 1 (50th)
> 0.79
> 9.63
> 8.76
> 10.06
> 5.32
> 4.63
> 100
> 1 (100th)
> 4.34
> 10.75
> 8.60
> 10.06
> 6.98
> 4.63
> 1000
> 1(1000th)
> 4.18
> 13.06
> 8.61
> 11.14
> 6.17
> 5.58
> 100
> 100
> 3.70
> 11.70
> 6.65
> 14
> 2.82
> 6.53
> 1000
> 1000
> 1.84
> 15.96
> 5.52
> 27.72
> 4.72
> 8.69
>
>
>
>
>
> Please find the patch here: https://gerrit.fd.io/r/c/vpp/+/27167
>
>
>
> I ran per patch regression on ARM Taishan server in CSIT lab. Following 
are
> the results for Stateless and Stateful modes:
>
> 1.  perftest-3n-tsh acl_statelessAND1cAND64b:
>
>
> 
https://jenkins.fd.io/job/vpp-csit-verify-perf-master-3n-tsh/23/consoleFull
>
>  In the log, I can see the comparative numbers between parent and
> current (my patch) for 45 test cases.
>
>  I searched for "Difference of averages relative to parent" in the 
log -
>  41/45 test cases have shown around 4% improvement with the patch. Rest of
> the 4 test cases stayed neutral.
>
>
>
> 2. perftest-3n-tsh acl_statefulAND1cAND64b:
>
> https://jenkins.fd.io/job/vpp-csit-verify-perf-master-3n-tsh/25/
>
> Performance improvement is seen in all 36 test cases.
>
>
>
> Please provide your comments.
>
>
>
> Thanks
>
> Govind
>
>
>

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

View/Reply Online (#16545): https://lists.fd.io/g/vpp-dev/message/16545
Mute This Topic: https://lists.fd.io/mt/74507621/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 API CRC compatibility check process in checkstyle merged and active

[Neale Ranns via lists.fd.io]

Hi Andrew,

A couple of questions?

Firstly, about unit testing aka make test. This is the salient passage in your 
guide:
  "foo_message_v2 is tested in "make test" to the same extent as the 
foo_message"
IMHO "to the same extent" implies everywhere v1 is used v2 should now be used 
in its place. One would hope that in most cases a simple find and replace 
through all test cases would do the job. However, once one has created such a 
fork and verified (presumably through some objective measure like lcov) that it 
is the same extent of coverage, what becomes of it? V1 and V2 APIs must 
co-exist for some time, so how do we continue to run the v1 original tests and 
the v2 fork? Given that between any two releases multi APIs may go through a 
version upgrade, there will be many such forks to manage.
Additionally, are we also going to test all combinations of messages and their 
versions, e.g. foo_v2 with bar_v2.

Secondly, what's the process for determining the initial categorization of 
existing APIs?

/neale

tpyed by my fat tumhbs

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

View/Reply Online (#16752): https://lists.fd.io/g/vpp-dev/message/16752
Mute This Topic: https://lists.fd.io/mt/74956323/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 interface revisted.

[Neale Ranns via lists.fd.io]

From:  on behalf of Christian Hopps 
Date: Thursday 18 June 2020 at 18:20
To: vpp-dev 
Cc: Christian Hopps 
Subject: [vpp-dev] ipsec interface revisted.

Hi,

So to revisit this topic from a different angle. I believe VPP needs something 
like the xfrm linux interface [1]. If I understand things correctly this 
actually provides what was useful (but more-so) with old ipsec interface 
functionality that has been lost. It is also a much cleaner/more powerful 
abstraction than the current "ipip tunnel with transport mode SA" trick that 
replaced the old ipsec interface functionality.

As you say, replaced by ipip/gre tunnel interface, which shows the 
functionality has not been lost. Route based VPNs are still supported.


The idea is to have an interface that one can use as a result of a FIB lookup. 
SAs can be attached to this interface. The replacement for the old ipsec 
interface functionality that was removed after 19.08, is that you attach a 
simple *tunnel mode* SA with "accept all" policy to the xfrm interface. You can 
also attach more complex policies if you care to, but the common and highly 
efficient case will be "accept all".

The win here is that:

 - FIB Fast: You get an interface that can be the result of the forwarding 
lookup
  . highly efficient especially with common zero cost match all policy
  . compare to adding complex ip policy directly to all your ingress interfaces 
(expensive).
 - You have one interface for both IPv4 and IPv6

All of which are available with the ipip/gre tunnel model.

 - It operates directly with the IPsec tunnel mode and transport mode SAs 
without needing to mangle the internal definition of SA tunnel into transport 
mode.
 - CRITICAL: Its use does not impose any encapsulation on the traffic itself.

Critical implies that without this some use cases are impossible. What is it 
that cannot be done with the tunnel model?

/neale


Thoughts?

Thanks,
Chris.

[1] - 
https://wiki.strongswan.org/projects/strongswan/wiki/RouteBasedVPN#XFRM-Interfaces-on-Linux

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

View/Reply Online (#16778): https://lists.fd.io/g/vpp-dev/message/16778
Mute This Topic: https://lists.fd.io/mt/74962223/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 API CRC compatibility check process in checkstyle merged and active

[Neale Ranns via lists.fd.io]

From:  on behalf of Andrew Yourtchenko 
Date: Thursday 18 June 2020 at 17:58
To: "Neale Ranns (nranns)" 
Cc: vpp-dev 
Subject: Re: [vpp-dev] VPP API CRC compatibility check process in checkstyle 
merged and active

Hi Neale,


On 18 Jun 2020, at 17:11, Neale Ranns (nranns)  wrote:
Hi Andrew,
A couple of questions?

Absolutely! That’s how we improve it! Thanks a lot for the questions ! Replies 
inline:



Firstly, about unit testing aka make test. This is the salient passage in your 
guide:
  "foo_message_v2 is tested in "make test" to the same extent as the 
foo_message"
IMHO "to the same extent" implies everywhere v1 is used v2 should now be used 
in its place. One would hope that in most cases a simple find and replace 
through all test cases would do the job. However, once one has created such a 
fork and verified (presumably through some objective measure like lcov) that it 
is the same extent of coverage, what becomes of it? V1 and V2 APIs must 
co-exist for some time, so how do we continue to run the v1 original tests and 
the v2 fork?

For most of most of the practical use cases the _v2 will be a trivial change 
compared to _v1 (eg. field change, etc), and that it would be implemented by v1 
handler calling v2 handler,
one can start with adding the tests for v2 that touch just the new/changed 
functionality, and in that case the tests calling v1 will “count” against the 
v2 coverage without the test duplication.

Doing only new functionality that the point of introducing the new API is good 
because it ensures no-harm-done to all tested functionality of the v1 API. 
However, users of the new API will [likely?] use the v2 API for old and new 
functions, but they’ll be using it untested for old/existing functions.


https://gerrit.fd.io/r/c/vpp/+/27586 Is the fresh example of just this approach.

I discussed with Ole and I tried to make a stricter and more concise 
description here for an API change:

https://wiki.fd.io/view/VPP/ApiChangeProcess#Tooling

So I would say we can explicitly say “the tests need to be converted to use the 
new API” either at the moment of “productizing” the new API or deletion of the 
old API. And yeah the idea is that we could eventually do automatic code 
coverage tests specifically for those points to ensure it doesn’t drop (or that 
it monotonically increases :)

This second stage then demonstrates no-harm-done to old functionality via the 
v2. From this point on both v1 and v2 should both continue to work, however, we 
no longer have test coverage for v1; it could rot. Do we mandate the v1 must be 
written in terms of v2 to limit the potential for errors? How do we continue to 
guarantee v1 and v2?

I am not sure there is a good way to test the “code coverage for an API” per 
se, since none of the tests have only one API - the before/after overall 
comparison should be good enough ?

Given that between any two releases multi APIs may go through a version 
upgrade, there will be many such forks to manage.

I think it should be just one per message at most ? (If one uses the 
“in-progress” transition phase for new messages - in fact we are pondering that 
it might be a good idea to also enforce that via the tool, so that would add an 
explicit “yes this is ready” phase, and avoid “accidental production status”.


Additionally, are we also going to test all combinations of messages and their 
versions, e.g. foo_v2 with bar_v2.

I think the best judgement still applies. If you have foo_v1 and bar_v1 which 
are related and replaced by foo_v2 and bar_v2, which means their deprecations  
would be probably synced, and the same would apply for the use by consumers. So 
either “v1 and v1” or “v2 and v2”.

If foo and bar are related, then can we/do we force users to use v1 or v2 for 
both but not a mixture?

Again - the logic behind all of this is to allow the user sitting on release X 
not using any deprecated APIs to painlessly upgrade a pre-X+1 master branch or 
the X+1 release, so they can keep their wheels turning *and* have time to fix 
the now-deprecated APIs that they use.

Having a commitment to “any version with any version” functionality - I think 
we can hold off with that commitment after we see how well the weaker promise 
works in practice.

What do you think ?



Secondly, what's the process for determining the initial categorization of 
existing APIs?

Basically, we shipped all of the APIs in the releases - so anything is a fair 
game to be a production.

Given some of the APIs are actually not used by anyone yet and need some more 
work (like IKEv2), the plan is to have a one-month grace period to 
“deproductize” the APIs:

https://wiki.fd.io/view/VPP/ApiChangeProcess#An_in-progress_API_accidentally_marked_as_.22production.22

This comes with a little bit of overhead but it gives a good visibility for the 
consumers, if there are any, to react.

We will keep this “noisy deproductize” process as well for the future to handle 
the one-off accidents (which we sho

Re: [vpp-dev] ipsec interface revisted.

[Neale Ranns via lists.fd.io]

Hi Chris,

On 22/06/2020 13:09, "Christian Hopps"  wrote:

> 
>  - It operates directly with the IPsec tunnel mode and transport mode SAs 
without needing to mangle the internal definition of SA tunnel into transport 
mode.

Do you have any comments on this point? This is what I was talking about 
when I said a "cleaner abstraction".

'cleaner' is a subjective term and subjective analysis is subject to bias; my 
biases are clear. That's why I tried to frame this discussion with an objective 
comparison of use case. First in what we can't do with ipip/gre then in what we 
'can't' do with xfrms.  More later..

>  - CRITICAL: Its use does not impose any encapsulation on the traffic 
itself.
>  
> Critical implies that without this some use cases are impossible. What is 
it that cannot be done with the tunnel model?

- You can't tunnel non-singular IP traffic with IPIP (my use case requires 
this) IOW "ipip-only" model assumes the ESP payload is a single IP packet that 
will be wrapped with an outer IP packet.

More on this below...

- You can't do route based transport mode IPsec using ipip (my use case 
doesn't require this).

That's true, but is that a use case? Route based VPNs apply to transit traffic, 
as well as locally generated, and one shouldn't send transit traffic using a 
transport mode SA, i.e. without encap that ensures it returns.

Both of these speak to the "more powerful abstraction" point.

- The xfrm interface allows for route-based selection, but also allows for 
additional policy restrictions. This might be possible with IPIP model, but 
again it doesn't seem as clean/obvious.

VPP supports policy based VPNs using an SPD attached to an interface. Any 
interface type could be used.

There's a reason that linux went with this approach as their improvement on 
the VTI interface, rather than just re-using IPIP tunnel after re-interpreting 
tunnel mode SAs into transport mode SAs like the new VPP code does. The latter 
makes assumptions about the IPsec tunnel mode payload and generally feels like 
a restricted "works for me/good enough" solution, rather than a clean 
abstraction one can build new use cases on (as I am trying to do).

I'm sure that had compelling reasons, but do they translate to VPP? Were they 
for architectural reasons that don't apply. For example, was the choice of a 
new interface type required to support HW offload? I'll try and find more info. 
Perhaps you have good source you can share.

In my case I want to insert myself into a place in the graph that appears 
to no longer exist. IPTFS is a tunnel that carriers multiple or fractional 
inner IP packets per outer IP packet -- this simply does not map to an IPIP 
interface, where it would easily map to an XFRM style interface. So it 
definitely is a loss of functionality.

... I don't follow your reasoning. Your feature runs in the ip4-output path of 
an interface. It will therefore, per-buffer, get;
1) an ip4 packet, because that's what the 'contract' of the ip4-output feature 
guarantees.
2) they will all be destined to the [single] peer that is reachable through the 
interface, because that's what routing has decided is the fate of these 
packets. Of course you are free to over-ride the routing decision if you wish, 
but at the end of the feature arc the tunnel's adjacency will ship the packet 
out the phy thru which the peer is reachable.
Now this applies regardless of the interface type. For example, if, and I'm not 
suggesting you do this, but if, you were to protect the tunnel with a tunnel 
mode SA, and in your feature vnet_buffer_advance'd away the first 20 bytes of 
buffer data, then, what you receive, would be functionally equivalent to the 
xfrm model, and what you transmit also the same; a packet to the peer. The 
difference being that in the ipip/gre model your feature is expected to produce 
a packet for the next node with those 20 bytes on the front. But in either case 
the next feature on the arc is expecting an ipv4 packet, because it expects the 
same guarantees your feature benefitted from. Which leads me to think that you 
are not using the existing esp4-encrypt node unmodified? In your current 
implementation, how do you communicate the change in packet type to the next 
node?

You say 'IPTFS is a tunnel', perhaps this is where our view point differs. I 
have a strong routing bias, and we're talking route based VPNs here __ the 
tunnel is used for routing, it is through the tunnel that the routes are 
advertised, and so the FIB chooses these tunnels to [load-balance] the traffic 
to. The fact that they are secured, or have IPTFS, or ACLs, or NAT or whatever 
else enabled on them is value add. The tunnel exists for routing, it is not 
created by one those features.

Additionally I'm worried there may be even newer changes being made in VPP 
that are making further assumptions (restrictions) based on the new "ipip-only" 
model (something to do with 

Re: [vpp-dev] ipsec interface revisted.

[Neale Ranns via lists.fd.io]

Hi Chris,

As far as I'm concerned, it's your plugin, you can add whatever functionality 
you need. If you separate the new interface type out into another plugin, so it 
can be used without your feature, then the community will benefit twice.  Let's 
just make sure we document the whys and hows of each model.

My preferred outcome though would be to try and find a way for your feature to 
work with the existing model. If you'd like to explore those possibilities 
perhaps we could discuss code specifics.

/neale

tpyed by my fat tumhbs

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

View/Reply Online (#16820): https://lists.fd.io/g/vpp-dev/message/16820
Mute This Topic: https://lists.fd.io/mt/74962223/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 interface revisted.

[Neale Ranns via lists.fd.io]

From: Christian Hopps 
Date: Friday 26 June 2020 at 12:13
To: "Neale Ranns (nranns)" 
Cc: Christian Hopps , vpp-dev 
Subject: Re: [vpp-dev] ipsec interface revisted.




On Jun 26, 2020, at 4:22 AM, Neale Ranns (nranns) 
mailto:nra...@cisco.com>> wrote:

Hi Chris,

As far as I'm concerned, it's your plugin, you can add whatever functionality 
you need. If you separate the new interface type out into another plugin, so it 
can be used without your feature, then the community will benefit twice.  Let's 
just make sure we document the whys and hows of each model.

My preferred outcome though would be to try and find a way for your feature to 
work with the existing model. If you'd like to explore those possibilities 
perhaps we could discuss code specifics.

Hi Neale,

I can try some code specifics.

A major part of IPTFS is the constructing of the inner ESP payload, and 
emitting this with specific timing disassociated with the carried user traffic 
as described previously (and documented in 
https://tools.ietf.org/html/draft-ietf-ipsecme-iptfs-01).

I'm going to leave out optimizations that may re-use buffers etc.. to keep 
things simple..

This IPTFS machinery receives and terminates the user (protected) packet buffer 
through the graph. IPTFS encapsulates this user packet into 1 or more IPTFS 
payloads along with other user traffic to the same SA. It then paces the output 
of these IPTFS payloads on a disconnected output worker. These IPTFS payloads 
are passed on to the esp_encrypt for adding ESP and the outer tunnel encap.

So: e.g.,

No IPTFS, SA tunnel mode.
 [IP-A]   [IP-A] 
[IPsec-IP|ESP|IP-A]
  worker A: [IP-A] -> ipsec-output -> esp-encrypt [outer-encap added] -> 
ip-lookup ... -> "if-tx"

 [IP-B]   [IP-B] 
[IPsec-IP|ESP|IP-B]
  worker A: [IP-A] -> ipsec-output -> esp-encrypt [outer-encap added] -> 
ip-lookup ... -> "if-tx"

 [IP-C]   [IP-C] 
[IPsec-IP|ESP|IP-C]
  worker A: [IP-A] -> ipsec-output -> esp-encrypt [outer-encap added] -> 
ip-lookup ... -> "if-tx"

IPTFS:

  [IP-A]   [IP-A] [TFS|IP-A]
  worker A: ipsec-output -> iptfs-encap-enq -> encapsualte with other user 
traffic construct in PACEQ
  [IP-B]   [IP-B] [TFS|IP-A|IP-B]
  worker A: ipsec-output -> iptfs-encap-enq -> encapsualte with other user 
traffic construct in PACEQ
  [IP-C]   [IP-C] 
[TFS|IP-A|IP-B|IP-C]
  worker A: ipsec-output -> iptfs-encap-enq -> encapsualte with other user 
traffic construct in PACEQ
 [TFS|IP-A|IP-B|IP-C]
  worker A: PACEQ -> iptfs-pacer (timed) enqueue to OUTQ


   [TFS|IP-A|IP-B|IP-C]   [TFS|IP-A|IP-B|IP-C]  
[IPsec-IP|ESP|TFS|IP-A|IP-B|IP-C]
  worker B: OUTQ -> iptfs_output (timed) -> esp-encrypt [outer-encap added] ->  
ip-lookup ... -> "if-tx"

Code Details (where does IPTFS hook):

SA Policy Directed

in ipsec_output_inline

  if (p0->policy == IPSEC_POLICY_ACTION_PROTECT)
{ ...
  if (sa->protocol == IPSEC_PROTOCOL_ESP)
{
  if (ipsec_sa_is_IPTFS (sa))
next_node_index = im->tfs_encap_node_index;
  else if (is_ipv6)
next_node_index = im->esp6_encrypt_node_index;
  else
next_node_index = im->esp4_encrypt_node_index;

Interface Directed

  [iptfs init code]

  ipsec_add_feature ("ip4-output", "iptfs-encap4-tun",
 &tfsm->encap4_tun_feature_index);

  [tunnel create code]

  In ipsec_tunnel_feature_set

  Instead of:

  arc = vnet_get_feature_arc_index ("ip4-output");
  vnet_feature_enable_disable_with_index (arc, esp4_feature_index,
  t->sw_if_index, enable,
  &t->output_sa_index,
  sizeof (t->output_sa_index));
  A callback is made to the TFS code which does:
  arc = vnet_get_feature_arc_index ("ip4-output");
  vnet_feature_enable_disable_with_index (
  arc, tfsm->encap4_tun_feature_index, t->sw_if_index, enable,
  &t->output_sa_index, sizeof (t->output_sa_index));
This latter Interface Directed code is what has been removed from VPP. The 
packets I receive on this path were not not (and should not) be already 
pre-encapsulated with any outer tunnel IP header, or I'm going to have to 
immediately remove this encap before placing the user traffic in the the TFS 
payload (see above). Having the overhead of adding an IP header, then 
immediately removing it simply to get traffic directed to my IPTFS encap 
routine is not a reasonable replacement.

Reasonable or otherwise, that’s what the model would expect. All output 
features get packets with encap already applied, since the output feature arc 
is invoked post encap. You’ll notice that when running in the SPD context, you 
need to strip the ethernet encap too.
You can ‘pre-compile’ the ip-header encap you will need to add post doing your 
magic, then set the length and update the

Re: [vpp-dev] Observing a crash in vpp-20.05

[Neale Ranns via lists.fd.io]

Hi Amit,

In addition to what Dave said.

You say you are only running ipv4 traffic. Please check the core to see if the 
packet that causes the assert is indeed v4.
Also run a node trace so we can see how the packet got to this node. If it's v4 
it shouldn't be there and if the interface is not ip6 enabled it should have 
been dropped earlier.

/neale

tpyed by my fat tumhbs


From: Dave Barach (dbarach) 
Sent: Monday, July 6, 2020 2:01:49 PM
To: Amit Mehra ; vpp-dev@lists.fd.io ; 
Neale Ranns (nranns) 
Subject: RE: [vpp-dev] Observing a crash in vpp-20.05


The backtrace appears to indicate that ipv6 link-level traffic is involved. 
It’s likely that the interface corresponding to sw_if_index 2 isn’t 
ipv6-enabled.



Begs the question why the code wipe out – copying Neale but he is on leave at 
the moment – please enable ipv6 on the interface.



It would be useful to run a debug image, since it would almost certainly ASSERT 
here rather than dereferencing a NULL pointer which causes signal 11 (SIGSEGV):



u32

ip6_ll_fib_get (u32 sw_if_index)

{

  ASSERT (vec_len (ip6_ll_table.ilt_fibs) > sw_if_index);



  return (ip6_ll_table.ilt_fibs[sw_if_index]);

}



In future, please try to format backtraces so we can read them without undue 
head-scratching.



HTH... Dave



From: vpp-dev@lists.fd.io  On Behalf Of Amit Mehra
Sent: Monday, July 6, 2020 5:58 AM
To: vpp-dev@lists.fd.io
Subject: [vpp-dev] Observing a crash in vpp-20.05



Hi,

I am running some light ipv4 traffic around 5K pps and observing a core with 
the following bt

Program terminated with signal 6, Aborted. #0 0x2b838f53f387 in raise () 
from /lib64/libc.so.6 Missing separate debuginfos, use: debuginfo-install 
OPWVs11-8.1-el7.x86_64 (gdb) bt #0 0x2b838f53f387 in raise () from 
/lib64/libc.so.6 #1 0x2b838f540a78 in abort () from /lib64/libc.so.6 #2 
0x55deea85617e in os_exit (code=code@entry=1) at 
/bfs-build/build-area.42/builds/LinuxNBngp_8.X_RH7/2020-07-02-1702/third-party/vpp_2005/vpp_2005/src/vpp/vnet/main.c:390
 #3 0x2b838de26716 in unix_signal_handler (signum=11, si=, 
uc=) at 
/bfs-build/build-area.42/builds/LinuxNBngp_8.X_RH7/2020-07-02-1702/third-party/vpp_2005/vpp_2005/src/vlib/unix/main.c:187
 #4  #5 0x2b838d434479 in ip6_ll_fib_get 
(sw_if_index=2) at 
/bfs-build/build-area.42/builds/LinuxNBngp_8.X_RH7/2020-07-02-1702/third-party/vpp_2005/vpp_2005/src/vnet/ip/ip6_ll_table.c:32
 #6 0x2b838d7c4904 in ip6_ll_dpo_inline (frame=0x2b8397edf880, 
node=0x2b83988669c0, vm=0x2b8397ca9040) at 
/bfs-build/build-area.42/builds/LinuxNBngp_8.X_RH7/2020-07-02-1702/third-party/vpp_2005/vpp_2005/src/vnet/dpo/ip6_ll_dpo.c:132
 #7 ip6_ll_dpo_switch (vm=0x2b8397ca9040, node=0x2b83988669c0, 
frame=0x2b8397edf880) at 
/bfs-build/build-area.42/builds/LinuxNBngp_8.X_RH7/2020-07-02-1702/third-party/vpp_2005/vpp_2005/src/vnet/dpo/ip6_ll_dpo.c:170
 #8 0x2b838dddeec7 in dispatch_node (last_time_stamp=, 
frame=0x2b8397edf880, dispatch_state=VLIB_NODE_STATE_POLLING, 
type=VLIB_NODE_TYPE_INTERNAL, node=0x2b83988669c0, vm=0x2b8397ca9040) at 
/bfs-build/build-area.42/builds/LinuxNBngp_8.X_RH7/2020-07-02-1702/third-party/vpp_2005/vpp_2005/src/vlib/main.c:1235
 #9 dispatch_pending_node (vm=vm@entry=0x2b8397ca9040, 
pending_frame_index=pending_frame_index@entry=4, last_time_stamp=) at 
/bfs-build/build-area.42/builds/LinuxNBngp_8.X_RH7/2020-07-02-1702/third-party/vpp_2005/vpp_2005/src/vlib/main.c:1403
 #10 0x2b838dde00bf in vlib_main_or_worker_loop (is_main=0, 
vm=0x2b8397ca9040) at 
/bfs-build/build-area.42/builds/LinuxNBngp_8.X_RH7/2020-07-02-1702/third-party/vpp_2005/vpp_2005/src/vlib/main.c:1862
 #11 vlib_worker_loop (vm=0x2b8397ca9040) at 
/bfs-build/build-area.42/builds/LinuxNBngp_8.X_RH7/2020-07-02-1702/third-party/vpp_2005/vpp_2005/src/vlib/main.c:1996
 #12 0x2b838e8c5cac in clib_calljmp () from 
/opt/opwv/S11/8.1/tools/vpp/lib/libvppinfra.so.20.05 #13 0x2b85ca3b3c40 in 
?? () #14 0x2b8411e3107a in eal_thread_loop (arg=) at 
/bfs-build/build-area.42/builds/LinuxNBngp_8.X_RH7/2020-07-02-1702/third-party/vpp_2005/vpp_2005/build-root/build-vpp-native/external/dpdk-20.02/lib/librte_eal/linux/eal/eal_thread.c:153
 #15 0x00010d0c in ?? ()

Is this a known issue in vpp-20.05?

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

View/Reply Online (#16889): https://lists.fd.io/g/vpp-dev/message/16889
Mute This Topic: https://lists.fd.io/mt/75329694/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 new ipsec interface patch

[Neale Ranns via lists.fd.io]

Removed.
I'm glad it works for you.
Could I ask for a quid pro quo? Mark the existing ipsec interface APIs as 
deprecated in the new scheme.

/neale

tpyed by my fat tumhbs


From: Dave Barach (dbarach) 
Sent: Monday, July 20, 2020 2:50:09 PM
To: Christian Hopps ; vpp-dev 
Cc: Neale Ranns (nranns) 
Subject: RE: [vpp-dev] Regarding new ipsec interface patch

We can merge the patch as soon as Neale removes his -2 from it... D.

-Original Message-
From: vpp-dev@lists.fd.io  On Behalf Of Christian Hopps
Sent: Monday, July 20, 2020 7:50 AM
To: vpp-dev 
Cc: Christian Hopps ; Neale Ranns (nranns) 
Subject: [vpp-dev] Regarding new ipsec interface patch

Hi vpp-dev,

In the interest of expressing the community support that Neale asked for

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

Looks good to me.

It may need some minor additional development to polish some rough edges, but I 
have been able to use it with a few IPTFS specific modifications to implement 
the same route-based functionality that I had in 1908.

As was asked in the last VPP dev meeting, the risk of collateral damage is 
extremely low, and it would be good to get it merged to master now to expose 
this in any case (the changes are minimal outside the new ipsec_itf.[ch] files).

So my recommendation is to merge now to get good soak time prior to 2009 (LTS) 
being cut.

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

View/Reply Online (#17016): https://lists.fd.io/g/vpp-dev/message/17016
Mute This Topic: https://lists.fd.io/mt/75679898/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 2005 crash with ip6 link local packets #vpp

[Neale Ranns via lists.fd.io]

Please give me a packet trace of an ip6 packet that

tpyed by my fat tumhbs


From: vpp-dev@lists.fd.io  on behalf of 
vipul.agra...@enea.com 
Sent: Monday, July 27, 2020 6:26:39 AM
To: vpp-dev@lists.fd.io 
Subject: Re: [vpp-dev] VPP 2005 crash with ip6 link local packets #vpp

I was able to get away with core by enabling ip6 on all the interfaces with 
VPP. Is this a must requirement for Vpp-2005. Any help here is appreciated.
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#17089): https://lists.fd.io/g/vpp-dev/message/17089
Mute This Topic: https://lists.fd.io/mt/75740846/21656
Mute #vpp: https://lists.fd.io/g/fdio+vpp-dev/mutehashtag/vpp
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 2005 crash with ip6 link local packets #vpp

[Neale Ranns via lists.fd.io]

I don't see an ip6 packet with a link local destination. I can't do anything 
with a trace without the offending packet.

Do I infer correctly you have some tunnel decap nodes? As a guess to the cause 
of the problem, you should ensure all decapped packets go to ip6-local before 
ip6-lookup (and the same for ip4).

/neale

tpyed by my fat tumhbs


From: Vipul Agrawal 
Sent: Tuesday, July 28, 2020 11:04:32 AM
To: Neale Ranns (nranns) ; vpp-dev@lists.fd.io 

Subject: RE: [vpp-dev] VPP 2005 crash with ip6 link local packets #vpp


Please find attached packet trace. I am not sure if the packet causing crash 
earlier is captured here.



Thanks,

Vipul



From: Neale Ranns (nranns) 
Sent: 27 July 2020 11:09
To: vpp-dev@lists.fd.io; Vipul Agrawal 
Subject: Re: [vpp-dev] VPP 2005 crash with ip6 link local packets #vpp



[EXTERNAL EMAIL]

Please give me a packet trace of an ip6 packet that

tpyed by my fat tumhbs





From: vpp-dev@lists.fd.io 
mailto:vpp-dev@lists.fd.io>> on behalf of 
vipul.agra...@enea.com 
mailto:vipul.agra...@enea.com>>
Sent: Monday, July 27, 2020 6:26:39 AM
To: vpp-dev@lists.fd.io 
mailto:vpp-dev@lists.fd.io>>
Subject: Re: [vpp-dev] VPP 2005 crash with ip6 link local packets #vpp



I was able to get away with core by enabling ip6 on all the interfaces with 
VPP. Is this a must requirement for Vpp-2005. Any help here is appreciated.

This message, including attachments, is CONFIDENTIAL. It may also be privileged 
or otherwise protected by law. If you received this email by mistake please let 
us know by reply and then delete it from your system; you should not copy it or 
disclose its contents to anyone. All messages sent to and from Enea may be 
monitored to ensure compliance with internal policies and to protect our 
business. Emails are not secure and cannot be guaranteed to be error free as 
they can be intercepted, a mended, lost or destroyed, or contain viruses. The 
sender therefore does not accept liability for any errors or omissions in the 
contents of this message, which arise as a result of email transmission. Anyone 
who communicates with us by email accepts these risks.
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

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

Re: [vpp-dev] ABF and ACL co-existence on an Interface

[Neale Ranns via lists.fd.io]

IMO it's reasonable to use ACL and ABF on the same interface as they provide 
independent functions, especially when they are matching against different 
criteria.

Re the debug CLI, it's often not robust to garbage input. If the API has the 
same problem though, I'll fix it.

Neale

tpyed by my fat tumhbs


From: vpp-dev@lists.fd.io  on behalf of Balaji Venkatraman 
via lists.fd.io 
Sent: Tuesday, August 11, 2020 4:08:56 PM
To: Venkat ; Andrew 👽 Yourtchenko 
Cc: vpp-dev@lists.fd.io 
Subject: Re: [vpp-dev] ABF and ACL co-existence on an Interface

Hi Venkat,
Ideally, we should not let ABF be configured if the interface is already tied 
to an ACL. Conversely, an ACL should be honored when the interface is tied to 
an ABF. Right?
You might want to confirm how we handle the behavior from experts here.
BTW, the second scenario you seeing the crash..
Issue 2: Delete ABF Policy that doesn’t have forwarding Path

That is an interesting scenario. Shouldn’t ABF mandatorily have an underlying 
ACL with a forwarding path?


Thanks!
—
Regards,
Balaji.

Get Outlook for iOS

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

Sent: Monday, August 10, 2020 11:52:46 PM
To: Andrew 👽 Yourtchenko 
Cc: Balaji Venkatraman (balajiv) ; vpp-dev@lists.fd.io 

Subject: Re: [vpp-dev] ABF and ACL co-existence on an Interface

Hi Andrew,

Here are a couple of test scenarios where I observed vpp crash while 
experimenting with ABF configuration.
I will find time to translate them to make test cases soon.
Meanwhile here are the steps to reproduce the issues.


Issues 1: ABF and ACL attached to the same interface


  *   In vpp VAT shell and configure bunch of ACL rules in a group


vat# acl_add_replace  ipv4 permit src 30.30.30.1/32 dst 
40.40.40.1/32 sport 1000 dport 1000, ipv4 permit+reflect 
src 10.10.10.0/24, ipv4 permit+reflect src 
20.20.20.0/24

vl_api_acl_add_replace_reply_t_handler:109: ACL index: 0


  *   Attach ACL Group create above to lan interface


vat# acl_interface_set_acl_list sw_if_index 1 input 0


  *   Following will be the state in vpp


DBGvpp# show version

vpp v19.08.1-282~ga6a98b546 built by root on 525c154d7fe6 at Tue Aug  4 
21:10:49 UTC 2020

DBGvpp#


DBGvpp# show hardware-interfaces brief

  NameIdx   Link  Hardware

lan1 up   lan

  Link speed: 10 Gbps

local0 0down  local0

  Link speed: unknown

loop0  3 up   loop0

  Link speed: unknown

loop1  5 up   loop1

  Link speed: unknown

tap0   4 up   tap0

  Link speed: unknown

wan2 up   wan

  Link speed: 1 Gbps


DBGvpp# show acl-plugin acl

acl-index 0 count 3 tag {}

  0: ipv4 permit src 30.30.30.1/32 dst 
40.40.40.1/32 proto 0 sport 1000 dport 1000

  1: ipv4 permit+reflect src 10.10.10.0/24 dst 
0.0.0.0/0 proto 0 sport 0-65535 dport 0-65535

  2: ipv4 permit+reflect src 20.20.20.0/24 dst 
0.0.0.0/0 proto 0 sport 0-65535 dport 0-65535

  applied inbound on sw_if_index: 1

  used in lookup context index: 0


DBGvpp# show acl-plugin interface

sw_if_index 0:

sw_if_index 1:

  input acl(s): 0

DBGvpp#


  *   Create another ACL for ABF configuration


vat# acl_add_replace  ipv4 permit src 11.11.11.0/24 proto 
17

vl_api_acl_add_replace_reply_t_handler:109: ACL index: 1


DBGvpp# show acl-plugin acl

acl-index 0 count 3 tag {}

  0: ipv4 permit src 30.30.30.1/32 dst 
40.40.40.1/32 proto 0 sport 1000 dport 1000

  1: ipv4 permit+reflect src 10.10.10.0/24 dst 
0.0.0.0/0 proto 0 sport 0-65535 dport 0-65535

  2: ipv4 permit+reflect src 20.20.20.0/24 dst 
0.0.0.0/0 proto 0 sport 0-65535 dport 0-65535

  applied inbound on sw_if_index: 1

  used in lookup context index: 0

acl-index 1 count 1 tag {}

  0: ipv4 permit src 11.11.11.0/24 dst 
0.0.0.0/0 proto 17 sport 0-65535 dport 0-65535

DBGvpp#


  *   Configure ABF Policy referring to the above created ACL


DBGvpp# abf policy add id 100 acl 1 via 10.39.27.227 wan


DBGvpp# show abf policy

abf:[0]: policy:100 acl:1

 path-list:[47] locks:1 flags:shared,no-uRPF, uRPF-list: None

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

10.39.27.227 wan

  [@0]: ipv4 via 10.39.27.227 wan: mtu:9000 b496915808e1b49691591f610800

DBGvpp# show abf attach lan

DBGvpp#


  *   Attach ABF Policy to the same interfac

Re: [vpp-dev] ABF and ACL co-existence on an Interface

[Neale Ranns via lists.fd.io]

Hi Balaji,

Access control happens before forwarding, so the ABF plugin specifies a 
runs-after dependency on the ACL plugin

So if the same tuple is specified in the access lists used by the two features, 
then that flow is first subject to access control, then, if it is permitted, to 
forwarding.

/neale

tpyed by my fat tumhbs


From: Balaji Venkatraman (balajiv) 
Sent: Wednesday, August 12, 2020 5:08:51 PM
To: Neale Ranns (nranns) 
Cc: vpp-dev@lists.fd.io ; Venkat 
; Andrew 👽 Yourtchenko 
Subject: Re: [vpp-dev] ABF and ACL co-existence on an Interface


Hi Neale,



Just wondering what the behavior ought to be if we had a ACL policy to drop on 
an IP address and ABF has one to fwd it.. Which one prevails?



Thanks!



--

Regards,

Balaji.





--

Regards,

Balaji.





From: "Neale Ranns (nranns)" 
Date: Tuesday, August 11, 2020 at 8:30 AM
To: Venkat , Andrew 👽 Yourtchenko 
, "Balaji Venkatraman (balajiv)" 
Cc: "vpp-dev@lists.fd.io" 
Subject: Re: [vpp-dev] ABF and ACL co-existence on an Interface





IMO it's reasonable to use ACL and ABF on the same interface as they provide 
independent functions, especially when they are matching against different 
criteria.

Re the debug CLI, it's often not robust to garbage input. If the API has the 
same problem though, I'll fix it.

Neale

tpyed by my fat tumhbs





From: vpp-dev@lists.fd.io  on behalf of Balaji Venkatraman 
via lists.fd.io 
Sent: Tuesday, August 11, 2020 4:08:56 PM
To: Venkat ; Andrew 👽 Yourtchenko 
Cc: vpp-dev@lists.fd.io 
Subject: Re: [vpp-dev] ABF and ACL co-existence on an Interface



Hi Venkat,

Ideally, we should not let ABF be configured if the interface is already tied 
to an ACL. Conversely, an ACL should be honored when the interface is tied to 
an ABF. Right?

You might want to confirm how we handle the behavior from experts here.

BTW, the second scenario you seeing the crash..

Issue 2: Delete ABF Policy that doesn’t have forwarding Path



That is an interesting scenario. Shouldn’t ABF mandatorily have an underlying 
ACL with a forwarding path?





Thanks!

—

Regards,

Balaji.



Get Outlook for iOS



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

Sent: Monday, August 10, 2020 11:52:46 PM
To: Andrew 👽 Yourtchenko 
Cc: Balaji Venkatraman (balajiv) ; vpp-dev@lists.fd.io 

Subject: Re: [vpp-dev] ABF and ACL co-existence on an Interface



Hi Andrew,



Here are a couple of test scenarios where I observed vpp crash while 
experimenting with ABF configuration.

I will find time to translate them to make test cases soon.

Meanwhile here are the steps to reproduce the issues.



Issues 1: ABF and ACL attached to the same interface



· In vpp VAT shell and configure bunch of ACL rules in a group



vat# acl_add_replace  ipv4 permit src 30.30.30.1/32 dst 
40.40.40.1/32 sport 1000 dport 1000, ipv4 permit+reflect 
src 10.10.10.0/24, ipv4 permit+reflect src 
20.20.20.0/24

vl_api_acl_add_replace_reply_t_handler:109: ACL index: 0



· Attach ACL Group create above to lan interface



vat# acl_interface_set_acl_list sw_if_index 1 input 0



· Following will be the state in vpp



DBGvpp# show version

vpp v19.08.1-282~ga6a98b546 built by root on 525c154d7fe6 at Tue Aug  4 
21:10:49 UTC 2020

DBGvpp#



DBGvpp# show hardware-interfaces brief

  NameIdx   Link  Hardware

lan1 up   lan

  Link speed: 10 Gbps

local0 0down  local0

  Link speed: unknown

loop0  3 up   loop0

  Link speed: unknown

loop1  5 up   loop1

  Link speed: unknown

tap0   4 up   tap0

  Link speed: unknown

wan2 up   wan

  Link speed: 1 Gbps



DBGvpp# show acl-plugin acl

acl-index 0 count 3 tag {}

  0: ipv4 permit src 30.30.30.1/32 dst 
40.40.40.1/32 proto 0 sport 1000 dport 1000

  1: ipv4 permit+reflect src 10.10.10.0/24 dst 
0.0.0.0/0 proto 0 sport 0-65535 dport 0-65535

  2: ipv4 permit+reflect src 20.20.20.0/24 dst 
0.0.0.0/0 proto 0 sport 0-65535 dport 0-65535

  applied inbound on sw_if_index: 1

  used in lookup context index: 0



DBGvpp# show acl-plugin interface

sw_if_index 0:

sw_if_index 1:

  input acl(s): 0

DBGvpp#



· Create another ACL for ABF configuration



vat# acl_add_replace  ipv4 permit src 11.11.11.0/24 proto 
17

vl_api_acl_add_replace_reply_t_handler:109: ACL index: 1



DBGvpp# show acl-plugin acl

acl-index 0 count 3 tag {}

  0: ipv4 permit src 30.30.30.1/32 dst 
40.40.

Re: [vpp-dev] #vpp-memif Send packets out on physical interface controlled by vpp(DPDK) once they are received through memif

[Neale Ranns via lists.fd.io]

You can't use the same address as a nexthop in a route and as an address 
applied to one of your own interfaces: you can't route to yourself.

You might also want to read:
  
https://fd.io/docs/vpp/master/gettingstarted/developers/fib20/attachedexport.html

/neale

tpyed by my fat tumhbs


From: vpp-dev@lists.fd.io  on behalf of techi...@gmail.com 

Sent: Wednesday, August 12, 2020 8:05:56 PM
To: vpp-dev@lists.fd.io 
Subject: Re: [vpp-dev] #vpp-memif Send packets out on physical interface 
controlled by vpp(DPDK) once they are received through memif

Hello Ben,

vppctl create interface memif id 0 master
vppctl set int state memif0/0 up
vppctl ip table add 1
vppctl set interface table memif0/0 1
vppctl set int ip address memif0/0 192.168.1.1/24
vppctl set interface state GigabitEthernet3/0/0 up
vppctl set interface state GigabitEthernet4/0/0 up
vppctl set interface ip address GigabitEthernet4/0/0 172.16.16.18/24
vppctl set interface ip address GigabitEthernet3/0/0 172.16.82.247/24
vppctl ip route add 172.16.82.4/32 via 192.168.1.1 memif0/0
vppctl ip route add 172.16.82.4/32 table 1 via GigabitEthernet3/0/0


I did above config. It shows blackholed packet error in trace. What am I doing 
wrong ?
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

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

Re: [vpp-dev] ARP resolution from non-connected IP

[Neale Ranns via lists.fd.io]

There's no way to disable the check. VPP expects the ARP request to have only 
address that belong to the link on which the ARP packet is sent. IMHO the 
sender's behaviour is wrong.

/neale

tpyed by my fat tumhbs


From: vpp-dev@lists.fd.io  on behalf of Satya Murthy 

Sent: Wednesday, August 19, 2020 3:03:49 PM
To: vpp-dev@lists.fd.io 
Subject: [vpp-dev] ARP resolution from non-connected IP


Hi,



Have a query on the ARP resolution.



We have a Router and VPP-box connected.



We are trying to do some peering from router’s loopback IP. This loopback IP is 
not in the connected subnet-range.

Due to this, router is initiating an ARP request with src as non-connected-IP 
in the payload.



VPP is dropping this ARP request saying “IP4 source address not local to 
subnet”.



In linux and in cisco routers, we have options to allow ARP requests from 
non-connected subnets.

Is there any workaround in VPP to allow this ARP request.



Please let us know.

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

View/Reply Online (#17267): https://lists.fd.io/g/vpp-dev/message/17267
Mute This Topic: https://lists.fd.io/mt/76285682/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] ARP resolution from non-connected IP

[Neale Ranns via lists.fd.io]

That would probably cause the check to pass, but that route will cause VPP to 
ARP for the loopback address out of  so the peer would also need to 
enable proxy ARP.
However, If a-priori knowledge of what is connecting to what is allowed in the 
workaround, then add a static ARP entry on the peer.

/neale

On 20/08/2020 09:01, "Benoit Ganne (bganne)"  wrote:

Maybe a workaround would be to add the host prefix of the router loopback 
in the fib?
Eg. 'ip route add /32 '?

Best
ben

> -Original Message-
> From: vpp-dev@lists.fd.io  On Behalf Of Neale Ranns
> via lists.fd.io
> Sent: jeudi 20 août 2020 08:07
> To: vpp-dev@lists.fd.io; Satya Murthy 
> Subject: Re: [vpp-dev] ARP resolution from non-connected IP
> 
> 
> There's no way to disable the check. VPP expects the ARP request to have
> only address that belong to the link on which the ARP packet is sent. IMHO
> the sender's behaviour is wrong.
> 
> 
> /neale
> 
> 
> tpyed by my fat tumhbs
> 
> 
> 
> From: vpp-dev@lists.fd.io  on behalf of Satya Murthy
> 
> Sent: Wednesday, August 19, 2020 3:03:49 PM
> To: vpp-dev@lists.fd.io 
> Subject: [vpp-dev] ARP resolution from non-connected IP
> 
> 
> Hi,
> 
> 
> 
> Have a query on the ARP resolution.
> 
> 
> 
> We have a Router and VPP-box connected.
> 
> 
> 
> We are trying to do some peering from router’s loopback IP. This loopback
> IP is not in the connected subnet-range.
> 
> Due to this, router is initiating an ARP request with src as non-
> connected-IP in the payload.
> 
> 
> 
> VPP is dropping this ARP request saying “IP4 source address not local to
> subnet”.
> 
> 
> 
> In linux and in cisco routers, we have options to allow ARP requests from
> non-connected subnets.
> 
> Is there any workaround in VPP to allow this ARP request.
> 
> 
> 
> Please let us know.
> 
> --
> Thanks & Regards,
> Murthy

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

View/Reply Online (#17271): https://lists.fd.io/g/vpp-dev/message/17271
Mute This Topic: https://lists.fd.io/mt/76285682/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] ARP resolution from non-connected IP

[Neale Ranns via lists.fd.io]

Hi Murty,

ARP works the same way even when using MH-BGP :)

Your peer is not directly connected, therefore you ARP for the nexthop, that's 
the target address. The source address comes from the interface on which the 
nexthop is attached, I.e the one on which the ARP is sent. this is not the 
loopback (no peers are ever attached to a loopback). The source address is 
therefore the one applied to the physical interface through which the nexthop 
is attached, hence to the receiving peer it is always an address within the 
interface's connected subnet.

I would suggest you experiment with how you are adding the static route to see 
if it changes the way the ARPs are generated.


/neale

tpyed by my fat tumhbs


From: vpp-dev@lists.fd.io  on behalf of Satya Murthy 

Sent: Friday, August 21, 2020 7:52:28 AM
To: vpp-dev@lists.fd.io 
Subject: Re: [vpp-dev] ARP resolution from non-connected IP

Neale /Ben,

We already have a static route to reach the peer. Even after that, we are 
getting this error.
And this error is as per the VPP's ARP code. It's not allowing the ARP-REQUEST 
from a non-connected source IP.

If we dont know allow this, I am not 100% sure how multihop-BGP peering kind of 
scenarios really work.
In MH-BGP, the peer will be running on a loopback address and will try to reach 
a peer loopback.
In this scenario, the ARP request can have the BGP-loopback address as the 
source address.

How will it really work ?
Any inputs pls.

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

View/Reply Online (#17279): https://lists.fd.io/g/vpp-dev/message/17279
Mute This Topic: https://lists.fd.io/mt/76285682/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] The gratuitous ARP issue

[Neale Ranns via lists.fd.io]

Hi Jinlei,

Could you please send me a pcap capture of the grat-arp that VPP receives. Then 
I can duplicate the case in the UT.

Thanks,
neale

From:  on behalf of Jinlei Li 
Date: Saturday 19 September 2020 at 11:56
To: "vpp-dev@lists.fd.io" 
Subject: [vpp-dev] The gratuitous ARP issue

Hi guys,
During my test environment, I have two physical interfaces in the same 
broadcast domain, and they are configured with IPs of different subnet.
[cid:image001.png@01D69035.D064C620]
I tried to ping 10.161.26.23 first, and I can see its’s mac address by “show ip 
neighbor”
 [cid:image002.png@01D69035.D064C620]
But if 10.161.26.23 send a gratuitous ARP broadcast, the other interface can 
also see this item(like the following picture).
I think this is not expected, and I tried same scenario on linux, this arp item 
will not be seen on another interface.
[cid:image003.png@01D69035.D064C620]
I find This problem occurs on both v20.01 and v20.05. Can any one help to check 
this issue?
Regards
Jinlei






-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#17475): https://lists.fd.io/g/vpp-dev/message/17475
Mute This Topic: https://lists.fd.io/mt/76951004/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] The gratuitous ARP issue

[Neale Ranns via lists.fd.io]

Hi Jinlei,

I created this UT case:

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

which IIUC re-creates your setup. But, as I would expect, the GARPs are dropped 
because the IP subnet is not on link. Please verify if it matches your setup.

/neale

From: Jerry Li 
Date: Tuesday 22 September 2020 at 04:02
To: "Neale Ranns (nranns)" 
Cc: "vpp-dev@lists.fd.io" 
Subject: Re:Re: [vpp-dev] The gratuitous ARP issue

Hi neale,

Thanks for your reply.

Attached the pcaps file for my test.
I tried to set the Opcode of arp packet as request(1) or reply(2), both the 
same occurs on vpp.

Regards
Jinlei.

At 2020-09-21 22:39:46, "Neale Ranns via lists.fd.io" 
 wrote:
Hi Jinlei,

Could you please send me a pcap capture of the grat-arp that VPP receives. Then 
I can duplicate the case in the UT.

Thanks,
neale

From:  on behalf of Jinlei Li 
Date: Saturday 19 September 2020 at 11:56
To: "vpp-dev@lists.fd.io" 
Subject: [vpp-dev] The gratuitous ARP issue

Hi guys,
During my test environment, I have two physical interfaces in the same 
broadcast domain, and they are configured with IPs of different subnet.
[cid:image001.png@01D691AD.706DC4A0]
I tried to ping 10.161.26.23 first, and I can see its’s mac address by “show ip 
neighbor”
 [cid:image002.png@01D691AD.706DC4A0]
But if 10.161.26.23 send a gratuitous ARP broadcast, the other interface can 
also see this item(like the following picture).
I think this is not expected, and I tried same scenario on linux, this arp item 
will not be seen on another interface.
[cid:image003.png@01D691AD.706DC4A0]
I find This problem occurs on both v20.01 and v20.05. Can any one help to check 
this issue?
Regards
Jinlei












-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#17491): https://lists.fd.io/g/vpp-dev/message/17491
Mute This Topic: https://lists.fd.io/mt/76951004/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] The gratuitous ARP issue

[Neale Ranns via lists.fd.io]

Hi Jinlei,

Thank you for the info. I have updated the UT to reflect this and the problem 
was seen. I have fixed the issue and updated the patch.

/neale

From: Jerry Li 
Date: Wednesday 23 September 2020 at 17:42
To: "Neale Ranns (nranns)" 
Cc: "vpp-dev@lists.fd.io" 
Subject: Re:Re: [vpp-dev] The gratuitous ARP issue



Hi neale,

I think you should first add the ip neigbor entry to pg2 first, and then send 
garp to pg1 with mac of pg2 remote host.
Otherwise I think the enty will not be generated by garp it self.

Regards
Jinlei



At 2020-09-23 19:28:36, "Neale Ranns via lists.fd.io" 
 wrote:

Hi Jinlei,

I created this UT case:

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

which IIUC re-creates your setup. But, as I would expect, the GARPs are dropped 
because the IP subnet is not on link. Please verify if it matches your setup.

/neale

From: Jerry Li 
Date: Tuesday 22 September 2020 at 04:02
To: "Neale Ranns (nranns)" 
Cc: "vpp-dev@lists.fd.io" 
Subject: Re:Re: [vpp-dev] The gratuitous ARP issue

Hi neale,

Thanks for your reply.

Attached the pcaps file for my test.
I tried to set the Opcode of arp packet as request(1) or reply(2), both the 
same occurs on vpp.

Regards
Jinlei.

At 2020-09-21 22:39:46, "Neale Ranns via lists.fd.io" 
 wrote:
Hi Jinlei,

Could you please send me a pcap capture of the grat-arp that VPP receives. Then 
I can duplicate the case in the UT.

Thanks,
neale

From:  on behalf of Jinlei Li 
Date: Saturday 19 September 2020 at 11:56
To: "vpp-dev@lists.fd.io" 
Subject: [vpp-dev] The gratuitous ARP issue

Hi guys,
During my test environment, I have two physical interfaces in the same 
broadcast domain, and they are configured with IPs of different subnet.
[cid:image001.png@01D69294.4EB10F10]
I tried to ping 10.161.26.23 first, and I can see its’s mac address by “show ip 
neighbor”
 [cid:image002.png@01D69294.4EB10F10]
But if 10.161.26.23 send a gratuitous ARP broadcast, the other interface can 
also see this item(like the following picture).
I think this is not expected, and I tried same scenario on linux, this arp item 
will not be seen on another interface.
[cid:image003.png@01D69294.4EB10F10]
I find This problem occurs on both v20.01 and v20.05. Can any one help to check 
this issue?
Regards
Jinlei



















-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#17501): https://lists.fd.io/g/vpp-dev/message/17501
Mute This Topic: https://lists.fd.io/mt/76951004/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-committers] VPP committers: VPP PTL vote

[Neale Ranns via lists.fd.io]

+1. If I had more pluses to give, I would.

/neale


From:  on behalf of "Dave Barach via lists.fd.io" 

Reply to: "Dave Barach (dbarach)" 
Date: Friday 25 September 2020 at 21:14
To: "vpp-committ...@lists.fd.io" 
Cc: "vpp-dev@lists.fd.io" 
Subject: [vpp-committers] VPP committers: VPP PTL vote

Folks,

The self-nomination period closed yesterday. We had one self-nomination, from 
Damjan Marion. At this point, we can proceed with a vote.

I’m sure that Damjan will do a great job, so let me start:

Damjan Marion as VPP PTL: +1

Please vote +1, 0, -1. For once, the “reply-all” button is everyone’s friend.

Thanks... Dave



-Original Message-
From: d...@barachs.net 
Sent: Thursday, September 17, 2020 10:32 AM
To: 'vpp-dev@lists.fd.io' ; 't...@lists.fd.io' 

Subject: Happy Trails to Me...



Folks,



I’m departing the employment rolls towards the end of next month. Although I 
intend to remain active in the fd.io vpp community as a coder, committer, and 
resident greybeard, it’s time for the community to pick a new PTL.



According to the project governance document, 
https://fd.io/docs/tsc/FD.IO-Technical-Community-Document-12-12-2017.pdf:



3.2.3.1 Project Technical Leader Candidates Candidates for the project’s PTL 
will be derived from the Committers of the Project. Candidates must 
self-nominate.



I'd like to invite any interested vpp project committer to self-nominate for 
the PTL role. Please email vpp-dev@lists.fd.io.



Let's close the self-nomination period in one week: more specifically, by 5pm 
EDT on Thursday, September 24, 2020; committer vote to follow thereafter.



I'll be glad to answer unicast questions about the PTL role from eligible 
committers.



Thanks... Dave












-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#17537): https://lists.fd.io/g/vpp-dev/message/17537
Mute This Topic: https://lists.fd.io/mt/77153108/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] Facing issue in IPSEC data traffic after SA is setup successfully

[Neale Ranns via lists.fd.io]

Hi Vijay,

From: vpp-dev@lists.fd.io 
Date: Thursday, 5 November 2020 at 16:54
To: vpp-dev@lists.fd.io 
Subject: [vpp-dev] Facing issue in IPSEC data traffic after SA is setup 
successfully
Hi,

I have set up IPSEC SA successfully b/w the Strongswan (initiator) and the VPP 
IPSec (responder).

After SA is established, at VPP I am seeing a new virtual interface "ipip0" 
being created.

The fd.io wiki page says we need to add a route to the initiator 
network and bind this virtual interface to the physical interface in order to 
send out the packet. When I do the below, the VPP process crashes (version and 
route commands pasted below)

Does anyone know this issue? Any suggestions about how to get the data traffic 
running successfully


vpp# show version
vpp v21.01-rc0~324-g62877029a built by root on ubuntu-10-37-3-75 at 
2020-10-30T11:10:45
before executing these commands please collect:
  sh ip fib 10.75.1.20/32
  sh ipip tunnel 0

vpp#  set interface state ipip0 up
vpp#  ip route add 10.75.1.20/32 via ipip0
vpp#  set interface unnumbered ipip0 use GigabitEthernetb/0/0


and from the crash please collect the backtrace.

/neale


Regards,
Vijay

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#17968): https://lists.fd.io/g/vpp-dev/message/17968
Mute This Topic: https://lists.fd.io/mt/78054018/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] Facing issue Ipv6 routing (Vpp 1908)

[Neale Ranns via lists.fd.io]

Hi Chetan,

I think you’ll have to expand a bit on ‘sometimes’ for us to help. Under what 
conditions does this happen?

/neale


From: vpp-dev@lists.fd.io 
Date: Tuesday, 17 November 2020 at 07:40
To: vpp-dev 
Subject: [vpp-dev] Facing issue Ipv6 routing (Vpp 1908)
Hello Everyone,

We are facing an issue with respect to ipv6 fib lookup (Vpp-1908).
Sometimes a packet comes out of the wrong interface , looks like due to wrong 
fib lookup.

I have found one change which is not part of our code
https://gerrit.fd.io/r/c/vpp/+/27255

Can anybody please suggest , is that change could cause such a problem ?

Thanks,
Chetan Bhasin



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