[vpp-dev] Python API fails to connect to vpp #vapi #vpp_papi #vpp

2021-08-09 Thread hyongsop
Hi,

I have a python script that uses 'vpp_papi' to try to connect to the 'vpp' 
running on the local host.  It's based on my reading of the source code in 
'src/vpp-api/python/vpp_papi'.  One problem I'm running into is that the client 
fails to connect to the vpp with the error message:

> 
> 
> 
> python3.8: .../src/vpp-api/client/client.c:560: vac_set_error_handler:
> Assertion `clib_mem_get_heap ()' failed
> 
> 

This error occurs as part of 'connect()':

> 
> 
> 
> vpp = VPP(self.api_json_files, read_timeout=60)
> ret = vpp.connect(app_name)
> 
> 
> 
> 

FWIW, the vpp itself seems to have enough heap space (it's run with 2 workers):

> 
> DBGvpp# show memory main-heap
> Thread 0 vpp_main
> base 0x7f8d15fd5000, size 1g, locked, unmap-on-destroy, name 'main heap'
> page stats: page-size 4K, total 262144, mapped 26485, not-mapped 235659
> numa 0: 24 pages, 96k bytes
> numa 1: 26461 pages, 103.36m bytes
> total: 1023.99M, used: 99.86M, free: 924.14M, trimmable: 923.55M
> 
> Thread 1 vpp_wk_0
> base 0x7f8d15fd5000, size 1g, locked, unmap-on-destroy, name 'main heap'
> page stats: page-size 4K, total 262144, mapped 27253, not-mapped 234891
> numa 0: 24 pages, 96k bytes
> numa 1: 27229 pages, 106.36m bytes
> total: 1023.99M, used: 102.86M, free: 921.14M, trimmable: 920.55M
> 
> Thread 2 vpp_wk_1
> base 0x7f8d15fd5000, size 1g, locked, unmap-on-destroy, name 'main heap'
> page stats: page-size 4K, total 262144, mapped 28021, not-mapped 234123
> numa 0: 24 pages, 96k bytes
> numa 1: 27997 pages, 109.36m bytes
> total: 1023.99M, used: 105.86M, free: 918.14M, trimmable: 917.55M
> 

On the other hand, the system doesn't seem to have many "huge pages" as shown 
by 'hugeadm --pool-list':

> 
> 
> 
> Size  Minimum  Current  Maximum  Default
> 
> 
> 
> 2097152     1024     1024     1024        *
> 
> 
> 
> 1073741824        0        0        0
> 
> 

However, I haven't been able to figure out if the error is related to the above 
and couldn't get much info on the error from googling for and looking at the 
`clib_mem_get_heap()` implementation.

Any info on the cause of this error and path forward would be greatly 
appreciated.

The vpp is 'stable/2101' and is running on a Ubuntu system (20.04, 
5.4.0-26-generic).

Thanks,
--Hyong

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#19937): https://lists.fd.io/g/vpp-dev/message/19937
Mute This Topic: https://lists.fd.io/mt/84779165/21656
Mute #vapi:https://lists.fd.io/g/vpp-dev/mutehashtag/vapi
Mute #vpp_papi:https://lists.fd.io/g/vpp-dev/mutehashtag/vpp_papi
Mute #vpp:https://lists.fd.io/g/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]
-=-=-=-=-=-=-=-=-=-=-=-



[vpp-dev] Delete ACL rules #acl_plugin #acl #abf

2021-08-09 Thread RaviKiran Veldanda
Hi Team,
I am trying to find a way to delete the ACL rules. From the commands provided 
in acl-plugin, I coudn't find a way to delete the acls after addition.
The only way to delete ACL rules are just restart VPP, I don't want to do that.
How can we dynamically delete the rules? always the rules are getting piled up 
if we don't restart VPP.
Can you please help me to provide a cli to delete the ACL rules.
For example:
set acl-plugin acl permit src 172.25.169.0/24 --> this is one ACL rule,
if I want to delete which command should I use.
//Ravi

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



[vpp-dev] ping to loopback

2021-08-09 Thread mark antony
Hi friends,
how can I ping a loopback in vpp? I can ping the normal interface from
cisco but for loopback no.

thanks

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



Re: [vpp-dev] BVI interface on a Bridge domain

2021-08-09 Thread Mohsen Meamarian
Hi ,
What could be the reason for the " l2-flood: BVI packet with unhandled
ethertype " error? Could gns3 simulation conditions cause it?

On Mon, Aug 9, 2021 at 11:53 AM Mohsen Meamarian via lists.fd.io
 wrote:

> Hi friends ,
> I have a problem with ARP delivery to the BVI interface on a BD. I see in
> trace that the ARP packet after l2 flooding goes to the Non-BVI output
> interface , but this doesn't happen for a loopback/BVI interface. thus I
> can't ping 100.3.4.4 from 100.3.4.11.
>
> create bridge-domain 2
> set int l2 bridge GigabitEthernet2/6/0 2
> set int state GigabitEthernet2/6/0 up
>
> create loopback interface
> set int l2 bridge loop0 2 bvi
> set int state loop0 up
> set int ip address loop0 100.3.4.12 / 3.3.3.3/24
>
> Should I configure a route for loop0/BVI or use set ip arp command?
> I also use ip route table 0 100.3.4.0/24 via loop0 but the problem
> remains.I use vpp 18.10.
>
> 
>
>

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



Re: [vpp-dev] memif: failed: no source address for egress interface

2021-08-09 Thread Edward Warnicke
On Mon, Aug 9, 2021 at 7:40 AM Neale Ranns  wrote:

>
>
> i would argue the contrary, not subnetting (i.e. using /32) is not a valid
> approach to subnetting.
>

Again: GCP does this.  Calico for K8s (the most used K8s CNI plugin) does
this.  Its  basically the direction Cloud is going in the generic.


>
>
> The BSD approach where you have to independent /32s on each side and a
> routing entry for the other side. Or a connected route /31 or larger. The
> act of configuring an address with a prefix is really a shortcut for
> configuring the address _and_ the connected prefix of course.
>
>
>
> And it’s an expression that there are other hosts attached to this link so
> you don’t need to add /32 routes for any such hosts. IOW it’s a way of say
> stating that there is a sub-network of hosts attached to this router. And
> my routing protocol can advertise this.
>
> If you add only a /32 you make none of those statements, and any routing
> protocol, if it still works over links without a subnet, does not include
> (without rediest static) reachability to those attached hosts. IOW it’s
> broken , or at a minimum not standard IP networking.
>
> Of course I may be wrong, I often am, but this was my position when
> writing IP functionality for VPP, so there may be other surprises …
>
>
>
> Sounds to me like the SAS algorithm needs a bit of work.
>
>
>
> Now on that topic I heartily agree  my SAS implementation is flawed in
> that it uses the glean adjacency to store the link’s receive address. P2p
> links don’t have a glean adj, hence SAS is broken on p2p links. It was an
> oversight on my part, I know I need to fix it.
>
> My goal with the SAS implementation done that way was to be able to do
> basic SAS without needing the interface addresses programmed via ‘set int
> ip adrr …’, but rather completely through the RIB (i.e. ip route add …).
> This is more like what one might expect at the bottom of a router stack. To
> say that goal is imcomplete, is an understatement :(
>




> The p2p fix, using the directly added IP link addresses is easy, it’s here:
>
>   https://gerrit.fd.io/r/c/vpp/+/32801
>
>
>
> (I'd like to use it for ICMP error sending too, where it also should
> handle the case of picking a source address from another interface than the
> outgoing interface).
>

And NBMA interfaces?

Ed


>
>
> SAS++ 
>
>
>
> /neale
>
>
>
> Cheers,
>
> Ole
>
>
>
> > From: vpp-dev@lists.fd.io  on behalf of Artem
> Glazychev via lists.fd.io 
>
> > Date: Wednesday, 4 August 2021 at 08:37
>
> > To: vpp-dev@lists.fd.io 
>
> > Subject: [vpp-dev] memif: failed: no source address for egress interface
>
> >
>
> > Hello,
>
> > Found a problem with some types of interfaces.
>
> >
>
> > For example, memif. When I'm creating memif interfaces and run ping I
> see:
>
> >
>
> > DBGvpp# ping 10.10.2.1
>
> > Failed: no source address for egress interface
>
> > ...
>
> >
>
> > But it is worth mentioning that I am setting /32 mask for IP address
>
> >
>
> > Managed to fix IP mode with these patches:
> https://gerrit.fd.io/r/c/vpp/+/32801, https://gerrit.fd.io/r/c/vpp/+/33303
>
> >
>
> > But Ethernet mode still doesn't work.
>
> >
>
> > ==
>
> >
>
> > There was already a similar topic:
> https://lists.fd.io/g/vpp-dev/topic/84038840
>
> >
>
> > Created a jira issue with details: https://jira.fd.io/browse/VPP-1992
>
> >
>
> > Does anyone have any thoughts on this? Thank you.
>
> >
>
> >
>
> >
>
> >
>
> >
>
> >
>
> >
>
> >
>
> >
>
> >
>
> >
>
> >
>
>
>
>
>
> 
>
>

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



Re: [vpp-dev] memif: failed: no source address for egress interface

2021-08-09 Thread Edward Warnicke
Neale,

/32s on interfaces that talk to other things are actually getting to be the
standard in Cloud.  GCP uses /32s in their VMs exclusively.  Calico uses
/32s on on Pod interfaces.  Its a common use case.

Ed

On Mon, Aug 9, 2021 at 3:03 AM Neale Ranns  wrote:

>
>
> Hi Artem,
>
>
>
> I think that is telling you not to use /32 address on interface for which
> you expect there to be connected peers.
>
> From an IP networking perspective, if you want two peers to be connected
> on an interface, they need to be within the same subnet, so use a /31.
>
>
>
> /neale
>
>
>
>
>
> *From: *vpp-dev@lists.fd.io  on behalf of Artem
> Glazychev via lists.fd.io 
> *Date: *Wednesday, 4 August 2021 at 08:37
> *To: *vpp-dev@lists.fd.io 
> *Subject: *[vpp-dev] memif: failed: no source address for egress interface
>
> Hello,
> Found a problem with some types of interfaces.
>
> For example, memif. When I'm creating memif interfaces and run ping I see:
>
> DBGvpp# ping 10.10.2.1
> Failed: no source address for egress interface
> ...
>
> But it is worth mentioning that I am setting /32 mask for IP address
>
> Managed to fix IP mode with these patches:
> https://gerrit.fd.io/r/c/vpp/+/32801, https://gerrit.fd.io/r/c/vpp/+/33303
>
> But Ethernet mode still doesn't work.
>
> ==
>
> There was already a similar topic:
> https://lists.fd.io/g/vpp-dev/topic/84038840
>
> Created a jira issue with details: https://jira.fd.io/browse/VPP-1992
>
> Does anyone have any thoughts on this? Thank you.
>
>
>
>
>
>
>
>
>
> 
>
>

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



Re: [vpp-dev] FIB entry being created on peer VPP node for the localsid

2021-08-09 Thread Chinmaya Aggarwal
Hi,

We have a use case where we have two VPP nodes i.e. VN1 and VN2 , in a local 
redundancy testing setup, VN1 is acting as primary node and VN2 is acting as 
secondary node. VN1 has localsid configuration on it. VN2 has a neighbor and 
fib entry corresponding to the localsid of VN1. Now when we bring down VN1, we 
want VN2 to have exact same localsid configuration that VN1 had. But, when we 
try to configure localsid on it using command "sr localsid address" command, we 
get below error

vpp# sr localsid address 2001:7a0:10::111 behavior end psp
sr localsid: There is already one FIB entry for therequested localsid non 
segment routing related

And we suppose this error is due to the fib entry for 2001:7a0:10::111.

How can we achieve our use case using default vpp beviour?

Thanks and Regards,
Chinmaya Agarwal.

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



Re: [vpp-dev] memif: failed: no source address for egress interface

2021-08-09 Thread Neale Ranns


On 09/08/2021 10:15, "otr...@employees.org"  wrote:
> I think that is telling you not to use /32 address on interface for which you 
> expect there to be connected peers.
> From an IP networking perspective, if you want two peers to be connected on 
> an interface, they need to be within the same subnet, so use a /31.

For p2p links there are actually two valid approaches to IP subnetting.

i would argue the contrary, not subnetting (i.e. using /32) is not a valid 
approach to subnetting.

The BSD approach where you have to independent /32s on each side and a routing 
entry for the other side. Or a connected route /31 or larger. The act of 
configuring an address with a prefix is really a shortcut for configuring the 
address _and_ the connected prefix of course.

And it’s an expression that there are other hosts attached to this link so you 
don’t need to add /32 routes for any such hosts. IOW it’s a way of say stating 
that there is a sub-network of hosts attached to this router. And my routing 
protocol can advertise this.
If you add only a /32 you make none of those statements, and any routing 
protocol, if it still works over links without a subnet, does not include 
(without rediest static) reachability to those attached hosts. IOW it’s broken 
, or at a minimum not standard IP networking.
Of course I may be wrong, I often am, but this was my position when writing IP 
functionality for VPP, so there may be other surprises …

Sounds to me like the SAS algorithm needs a bit of work.

Now on that topic I heartily agree  my SAS implementation is flawed in that it 
uses the glean adjacency to store the link’s receive address. P2p links don’t 
have a glean adj, hence SAS is broken on p2p links. It was an oversight on my 
part, I know I need to fix it.
My goal with the SAS implementation done that way was to be able to do basic 
SAS without needing the interface addresses programmed via ‘set int ip adrr …’, 
but rather completely through the RIB (i.e. ip route add …). This is more like 
what one might expect at the bottom of a router stack. To say that goal is 
imcomplete, is an understatement :(
The p2p fix, using the directly added IP link addresses is easy, it’s here:
  https://gerrit.fd.io/r/c/vpp/+/32801

(I'd like to use it for ICMP error sending too, where it also should handle the 
case of picking a source address from another interface than the outgoing 
interface).

SAS++ 

/neale

Cheers,
Ole

> From: vpp-dev@lists.fd.io 
> mailto:vpp-dev@lists.fd.io>> on behalf of Artem 
> Glazychev via lists.fd.io 
> mailto:artem.glazychev=xored@lists.fd.io>>
> Date: Wednesday, 4 August 2021 at 08:37
> To: vpp-dev@lists.fd.io 
> mailto:vpp-dev@lists.fd.io>>
> Subject: [vpp-dev] memif: failed: no source address for egress interface
>
> Hello,
> Found a problem with some types of interfaces.
>
> For example, memif. When I'm creating memif interfaces and run ping I see:
>
> DBGvpp# ping 10.10.2.1
> Failed: no source address for egress interface
> ...
>
> But it is worth mentioning that I am setting /32 mask for IP address
>
> Managed to fix IP mode with these patches: 
> https://gerrit.fd.io/r/c/vpp/+/32801, https://gerrit.fd.io/r/c/vpp/+/33303
>
> But Ethernet mode still doesn't work.
>
> ==
>
> There was already a similar topic: 
> https://lists.fd.io/g/vpp-dev/topic/84038840
>
> Created a jira issue with details: https://jira.fd.io/browse/VPP-1992
>
> Does anyone have any thoughts on this? Thank you.
>
>
>
>
>
>
>
>
>
>
> 
>



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



Re: [vpp-dev] memif: failed: no source address for egress interface

2021-08-09 Thread Ole Troan
> I think that is telling you not to use /32 address on interface for which you 
> expect there to be connected peers.
> From an IP networking perspective, if you want two peers to be connected on 
> an interface, they need to be within the same subnet, so use a /31.

For p2p links there are actually two valid approaches to IP subnetting.
The BSD approach where you have to independent /32s on each side and a routing 
entry for the other side. Or a connected route /31 or larger. The act of 
configuring an address with a prefix is really a shortcut for configuring the 
address _and_ the connected prefix of course.

Sounds to me like the SAS algorithm needs a bit of work.
(I'd like to use it for ICMP error sending too, where it also should handle the 
case of picking a source address from another interface than the outgoing 
interface).

Cheers,
Ole

> From: vpp-dev@lists.fd.io  on behalf of Artem Glazychev 
> via lists.fd.io 
> Date: Wednesday, 4 August 2021 at 08:37
> To: vpp-dev@lists.fd.io 
> Subject: [vpp-dev] memif: failed: no source address for egress interface
> 
> Hello,
> Found a problem with some types of interfaces.
> 
> For example, memif. When I'm creating memif interfaces and run ping I see:
> 
> DBGvpp# ping 10.10.2.1
> Failed: no source address for egress interface
> ...
> 
> But it is worth mentioning that I am setting /32 mask for IP address
> 
> Managed to fix IP mode with these patches: 
> https://gerrit.fd.io/r/c/vpp/+/32801, https://gerrit.fd.io/r/c/vpp/+/33303
> 
> But Ethernet mode still doesn't work.
> 
> ==
> 
> There was already a similar topic: 
> https://lists.fd.io/g/vpp-dev/topic/84038840
> 
> Created a jira issue with details: https://jira.fd.io/browse/VPP-1992
> 
> Does anyone have any thoughts on this? Thank you.
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 



signature.asc
Description: Message signed with OpenPGP

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



Re: [vpp-dev] memif: failed: no source address for egress interface

2021-08-09 Thread Neale Ranns

Hi Artem,

I think that is telling you not to use /32 address on interface for which you 
expect there to be connected peers.
>From an IP networking perspective, if you want two peers to be connected on an 
>interface, they need to be within the same subnet, so use a /31.

/neale


From: vpp-dev@lists.fd.io  on behalf of Artem Glazychev 
via lists.fd.io 
Date: Wednesday, 4 August 2021 at 08:37
To: vpp-dev@lists.fd.io 
Subject: [vpp-dev] memif: failed: no source address for egress interface

Hello,
Found a problem with some types of interfaces.

For example, memif. When I'm creating memif interfaces and run ping I see:

DBGvpp# ping 10.10.2.1
Failed: no source address for egress interface
...

But it is worth mentioning that I am setting /32 mask for IP address

Managed to fix IP mode with these patches: 
https://gerrit.fd.io/r/c/vpp/+/32801, https://gerrit.fd.io/r/c/vpp/+/33303

But Ethernet mode still doesn't work.

==

There was already a similar topic: https://lists.fd.io/g/vpp-dev/topic/84038840

Created a jira issue with details: https://jira.fd.io/browse/VPP-1992

Does anyone have any thoughts on this? Thank you.









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



[vpp-dev] BVI interface on a Bridge domain

2021-08-09 Thread Mohsen Meamarian
Hi friends ,
I have a problem with ARP delivery to the BVI interface on a BD. I see in
trace that the ARP packet after l2 flooding goes to the Non-BVI output
interface , but this doesn't happen for a loopback/BVI interface. thus I
can't ping 100.3.4.4 from 100.3.4.11.

create bridge-domain 2
set int l2 bridge GigabitEthernet2/6/0 2
set int state GigabitEthernet2/6/0 up

create loopback interface
set int l2 bridge loop0 2 bvi
set int state loop0 up
set int ip address loop0 100.3.4.12 / 3.3.3.3/24

Should I configure a route for loop0/BVI or use set ip arp command?
I also use ip route table 0 100.3.4.0/24 via loop0 but the problem
remains.I use vpp 18.10.

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