Re: [vpp-dev] Problem in forwarding multicast traffic

[Neale Ranns (nranns)]

Hi Juan,

When setting multicast routes one must specify the accepting (or RPF) interface 
for the prefix. So, additionally, you need;
   ip mroute add 224.0.0.5 via GigabitEthernet0/7/0 Accept

note though that while an interface can be configured to be both and accepting 
and forwarding interface (i.e. PIM BiDir) packets will not be replicated back 
out of the interface they came in on.

Regards,
Neale


From:  on behalf of Juan Salmon 

Date: Wednesday, 7 February 2018 at 06:59
To: "vpp-dev@lists.fd.io" 
Subject: [vpp-dev] Problem in forwarding multicast traffic

Hi,
I want to forward multicast traffic with vpp, but after following commands, the 
multicast packet drop with ip4-drop.

ip mroute add 224.0.0.5 via GigabitEthernet0/7/0 Forward
ip mroute add 224.0.0.5 via GigabitEthernet0/8/0 Forward

The sample trace is:

00:27:52:305546: dpdk-input
  GigabitEthernet0/7/0 rx queue 0
  buffer 0x3492: current data 14, length 64, free-list 0, clone-count 0, 
totlen-nifb 0, trace 0x2
  PKT MBUF: port 0, nb_segs 1, pkt_len 78
buf_len 2176, data_len 78, ol_flags 0x0, data_off 128, phys_addr 0x7c3d24c0
packet_type 0x0
  IP4: 52:54:00:42:80:c8 -> 01:00:5e:00:00:05
  OSPF: 192.168.20.151 -> 224.0.0.5
tos 0xc0, ttl 1, length 64, checksum 0x6bc3
fragment id 0x979d
00:27:52:305566: ip4-input
  OSPF: 192.168.20.151 -> 224.0.0.5
tos 0xc0, ttl 1, length 64, checksum 0x6bc3
fragment id 0x979d
00:27:52:305570: ip4-mfib-forward-lookup
  fib 0 entry 6
00:27:52:305572: ip4-mfib-forward-rpf
  entry 6 1 Forward,
00:27:52:305572: ip4-drop
OSPF: 192.168.20.151 -> 224.0.0.5
  tos 0xc0, ttl 1, length 64, checksum 0x6bc3
  fragment id 0x979d
00:27:52:305574: error-drop
  ip4-input: ip4 adjacency drop


Best Regards,
Juan Salmon.
___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev

Re: [vpp-dev] VXLAN Tunnel IF Names

[Neale Ranns (nranns)]

Hi Jon,

I feel I must ask ☺
“That  has to match a VPP interface by name.  But what name?”
why does it need to match a VPP interface name? shouldn’t  = MyVxlan23. Your 
control plane maintains mappings between MyVxlan23 and VPP’s sw_if_index.

/neale


From:  on behalf of Jon Loeliger 
Date: Friday, 2 February 2018 at 22:08
To: "John Lo (loj)" 
Cc: vpp-dev 
Subject: Re: [vpp-dev] VXLAN Tunnel IF Names

On Wed, Jan 31, 2018 at 6:41 PM, John Lo (loj) 
mailto:l...@cisco.com>> wrote:
Hi Jon,

Hi John,

Thanks for taking the time to get back to me on this!

All VPP tunnel creation uses the mechanism of returning a sw_if_index of the 
created tunnel.

I know.  I get that.  It works.

The name of the tunnel is then followed by a number being the instance or index 
to the tunnel struct vector. Thus, the first VXLAN tunnel created is called 
vxlan_tunnel0 followed by vxlan_tunnel1, etc. The number is incrementing unless 
tunnels are deleted and created again where a newly created tunnel will reuse 
the last deleted tunnel, hence its name. If all previously deleted tunnels are 
used up, then the tunnel name number will start incrementing again.

Right.

I am not sure if it is feasible to follow this behavior to “predict” tunnel 
name.

It is not.

The problem is not just "predict it", but the user has to be
able to know the associated SW IF name at the time that
the (vxlan tunnel) create API call happens.

The reason for that is because the very next thing the
API call user is going to want to do is configure that interface.
Short of interrogating the system, there is no way to know
the IF name.  (I understand that the name can be obtained
from the sw_if_index.  That's not what I mean.)

Consider this series of PEUDO API calls that are being
issued by some client front-end.  Think of this as a batch
of CLI commands:

vxlan MyVxlan23
source 1.2.3.4
destination 10.11.12.13
vni 19
exit

interface 
do stuff to interface like apply an ACL or whatever
exit

There is no way to batch-run those as there is a step
needed to determine what  is.  It could be "vxlan_tunnel..."
anything.

That  has to match a VPP interface by name.  But what name?
The entire transactional  history of VXLANs must be known in
order to guess the next name.

BTW, GRE tunnels are created and named the same way. You added TEB (transparent 
ethernet bridging) support to GRE. Have you not been using it and bothered by 
how to predict name of created GRE tunnels?

I've not touched GRE yet.  However, it is next on my list to fix!
My current plan is to submit essentially the same patch there too.

It is not a good idea to tie tunnel name to VNI as it is not a unique ID to 
identify VXLAN tunnels. It is quite common for existence of multiple VXLAN 
tunnels with the same VNI with different remote end point IP addresses. A 
bridge domain (BD) may have multiple VXLAN tunnels with the same VNI to several 
remote servers where the same overlay network exist. It is quite common to use 
the ID for BD or VLAN as the VNI for all its VXLAN tunnels to make it easier to 
track their usage.

Excellent!  Thank you for this insight!  That makes total sense now!

I suppose it is feasible to provide another set of VXLAN tunnel create/delete 
API to allow caller to specify instance or number of the tunnel, similar to 
what you did for loopback interface.

This is the route I was headed:  Just like loopback interface naming!

In this case, the above example would be, perhaps, something like this:

vxlan MyVxlan23
instance 101
source 1.2.3.4
destination 10.11.12.13
vni 19
exit

interface vxlan_tunnel101
do stuff to interface like apply an ACL or whatever
exit

  One complication for the new API is that, upon VXLAN tunnel deletion, the 
interface created for the tunnel is not really deleted by the current code but 
put into a reuse pool.

I solved that by making a trivial  vxlan_name_renumber()  function,
and then calling vnet_interface_name_remumber(sw_if_index, instance)
to update the previously captured "vxlan_tunnel" name and rename
it using the new instance number.

When more tunnels are created, any interface from reuse pool with its existing 
interface name will be used for the new tunnel, before new interfaces are 
created. If a interface is reused upon tunnel creation, its interface name may 
not match the specified tunnel instance/number of the new tunnel creation API.  
One way to overcome this may be to not keep interface in reused pool on tunnel 
deletion. Thus, tunnel creation would always create new interface.  For 
backward compatibility, I suppose we can keep the tunnel create/delete API as 
is so interfaces of deleted tunnels are kept for reuse. The new API will then 
always create/delete interface on tunnel create/delete.  This would put a 
restriction that user should not mix the usage of new or old APIs.

To me, that sounds like a whole bunch of really unn

[vpp-dev] Questions about ACL behavior of VPP

[kaneko]

Hello, my name is Hitoshi Kaneko.

I belong to NTT Laboratories.

I evaluate VPP and there have been questions.

(1)Question 1

I have wanted to evaluate Access Control List of VPP.

About this feature, I have used acl_add_replace and 
acl_interface_set_acl_list commands and I have seen packets stop, i. e. ,

I have input the commands bellow .

"acl_add_replace ipv4 deny src 192.168.10.15/32"

"acl_interface_set_acl_list sw_if_index 1 input 0 output"

But, at the same time, all the packets, i. e. , whose source IP 
addresses are not 192.168.10.15/32 ,  also have stopped.


Please teach me how to stop the only packets whose source IP addresses 
are 192.168.10.15/32 .


(Of course, all the packets have passed through the VPP if that ACL rule 
has been deleted . )



(2)Question 2

Ultimately, I want the only packets whose source IP addresses are 
192.168.10.15/32 to  pass through the VPP, for example , bellow .


"acl_add_replace ipv4 deny"

"acl_add_replace ipv4 permit src 192.168.10.15/32"

"acl_interface_set_acl_list sw_if_index 1 input 0 1 output"


But, when I have input the commands bellow ,

"acl_add_replace ipv4 permit src 192.168.10.15/32"

"acl_interface_set_acl_list sw_if_index 1 input 0  output"

all the packets have stopped like the events of the question 1 .


Regards,

Hitoshi Kaneko

E-mail: kaneko.hito...@lab.ntt.co.jp 

Phone: +81 422 59 4946

___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev

Re: [vpp-dev] VXLAN Tunnel IF Names

[John Lo (loj)]

I guess Jon’s point was the control plane need to know exactly what X would be 
and not rely on VPP to provide the sw_if_index or query VPP for the name after 
the VXLAN create request.  This makes the control plane CLI script/template 
support more straight forward.  In the case of mixed usage where a requested 
instance is not available, I wonder how control plane should handle the error 
condition if it does not check the result of the VXLAN create request…   -John

From: Neale Ranns (nranns)
Sent: Wednesday, February 07, 2018 5:55 AM
To: Jon Loeliger ; John Lo (loj) 
Cc: vpp-dev 
Subject: Re: [vpp-dev] VXLAN Tunnel IF Names

Hi Jon,

I feel I must ask ☺
“That  has to match a VPP interface by name.  But what name?”
why does it need to match a VPP interface name? shouldn’t  = MyVxlan23. Your 
control plane maintains mappings between MyVxlan23 and VPP’s sw_if_index.

/neale


From: mailto:vpp-dev-boun...@lists.fd.io>> on 
behalf of Jon Loeliger mailto:j...@netgate.com>>
Date: Friday, 2 February 2018 at 22:08
To: "John Lo (loj)" mailto:l...@cisco.com>>
Cc: vpp-dev mailto:vpp-dev@lists.fd.io>>
Subject: Re: [vpp-dev] VXLAN Tunnel IF Names

On Wed, Jan 31, 2018 at 6:41 PM, John Lo (loj) 
mailto:l...@cisco.com>> wrote:
Hi Jon,

Hi John,

Thanks for taking the time to get back to me on this!

All VPP tunnel creation uses the mechanism of returning a sw_if_index of the 
created tunnel.

I know.  I get that.  It works.

The name of the tunnel is then followed by a number being the instance or index 
to the tunnel struct vector. Thus, the first VXLAN tunnel created is called 
vxlan_tunnel0 followed by vxlan_tunnel1, etc. The number is incrementing unless 
tunnels are deleted and created again where a newly created tunnel will reuse 
the last deleted tunnel, hence its name. If all previously deleted tunnels are 
used up, then the tunnel name number will start incrementing again.

Right.

I am not sure if it is feasible to follow this behavior to “predict” tunnel 
name.

It is not.

The problem is not just "predict it", but the user has to be
able to know the associated SW IF name at the time that
the (vxlan tunnel) create API call happens.

The reason for that is because the very next thing the
API call user is going to want to do is configure that interface.
Short of interrogating the system, there is no way to know
the IF name.  (I understand that the name can be obtained
from the sw_if_index.  That's not what I mean.)

Consider this series of PEUDO API calls that are being
issued by some client front-end.  Think of this as a batch
of CLI commands:

vxlan MyVxlan23
source 1.2.3.4
destination 10.11.12.13
vni 19
exit

interface 
do stuff to interface like apply an ACL or whatever
exit

There is no way to batch-run those as there is a step
needed to determine what  is.  It could be "vxlan_tunnel..."
anything.

That  has to match a VPP interface by name.  But what name?
The entire transactional  history of VXLANs must be known in
order to guess the next name.

BTW, GRE tunnels are created and named the same way. You added TEB (transparent 
ethernet bridging) support to GRE. Have you not been using it and bothered by 
how to predict name of created GRE tunnels?

I've not touched GRE yet.  However, it is next on my list to fix!
My current plan is to submit essentially the same patch there too.

It is not a good idea to tie tunnel name to VNI as it is not a unique ID to 
identify VXLAN tunnels. It is quite common for existence of multiple VXLAN 
tunnels with the same VNI with different remote end point IP addresses. A 
bridge domain (BD) may have multiple VXLAN tunnels with the same VNI to several 
remote servers where the same overlay network exist. It is quite common to use 
the ID for BD or VLAN as the VNI for all its VXLAN tunnels to make it easier to 
track their usage.

Excellent!  Thank you for this insight!  That makes total sense now!

I suppose it is feasible to provide another set of VXLAN tunnel create/delete 
API to allow caller to specify instance or number of the tunnel, similar to 
what you did for loopback interface.

This is the route I was headed:  Just like loopback interface naming!

In this case, the above example would be, perhaps, something like this:

vxlan MyVxlan23
instance 101
source 1.2.3.4
destination 10.11.12.13
vni 19
exit

interface vxlan_tunnel101
do stuff to interface like apply an ACL or whatever
exit

  One complication for the new API is that, upon VXLAN tunnel deletion, the 
interface created for the tunnel is not really deleted by the current code but 
put into a reuse pool.

I solved that by making a trivial  vxlan_name_renumber()  function,
and then calling vnet_interface_name_remumber(sw_if_index, instance)
to update the previously captured "vxlan_tunnel" name and rename
it using the new instance number.

When more tunnels are created, any interface from reuse pool with its e

Re: [vpp-dev] Questions about ACL behavior of VPP

[Andrew Yourtchenko]

Kaneko-San,

My replies inline below... hope they help you.


> On 7 Feb 2018, at 12:43, kaneko  wrote:
> 
> Hello, my name is Hitoshi Kaneko.
> 
> I belong to NTT Laboratories.
> 
> I evaluate VPP and there have been questions.
> 
>  
> 
> (1)Question 1
> 
> I have wanted to evaluate Access Control List of VPP.
> 
> About this feature, I have used acl_add_replace and 
> acl_interface_set_acl_list commands and I have seen packets stop, i. e. ,
> I have input the commands bellow .
> 
> "acl_add_replace ipv4 deny src 192.168.10.15/32"
> 
> "acl_interface_set_acl_list sw_if_index 1 input 0 output"
> 
> But, at the same time, all the packets, i. e. , whose source IP addresses are 
> not 192.168.10.15/32 ,  also have stopped.
> 
> Please teach me how to stop the only packets whose source IP addresses are 
> 192.168.10.15/32 .
> 

There is an implicit “deny all” after acl evaluation. So this configuration 
drops all traffic. You need to add “permit any any” to the end of the acl to 
permit the packets which did not match yet.

> (Of course, all the packets have passed through the VPP if that ACL rule has 
> been deleted . )
> 
> 
> 
> (2)Question 2
> 
> Ultimately, I want the only  packets whose source IP addresses are 
> 192.168.10.15/32 to  pass through the VPP, for example , bellow .
> 
> "acl_add_replace ipv4 deny"
> 
> "acl_add_replace ipv4 permit src 192.168.10.15/32"
> 
> "acl_interface_set_acl_list sw_if_index 1 input 0 1 output"
> 
> 
> 
> 
> But, when I have input the commands bellow ,
> 
> "acl_add_replace ipv4 permit src 192.168.10.15/32"
> 
> "acl_interface_set_acl_list sw_if_index 1 input 0  output"
> 
> all the packets have stopped like the events of the question 1 .
> 
You can use the “show acl-plugin acl”, “show acl-plugin interface” debug CLI to 
verify that the ACLs are correct and are applied to the correct interfaces, as 
well as the packet tracer (“trace add dpdk-input 50” and “show trace”) to 
verify what is happening with the packets..

I am assuming sw_if_index 1 is the interface which is connecting to the 
192.168.10.15, since the acl is applied ingress.

—a


> 
> Regards,
> 
> Hitoshi Kaneko
> 
>  
> 
> E-mail: kaneko.hito...@lab.ntt.co.jp
> 
> Phone: +81 422 59 4946
> 
> ___
> vpp-dev mailing list
> vpp-dev@lists.fd.io
> https://lists.fd.io/mailman/listinfo/vpp-dev
___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev

Re: [vpp-dev] VXLAN Tunnel IF Names

[Neale Ranns (nranns)]

But all control planes need to know the sw_if_index provided by VPP as it is 
this value (and not the interface name) that one needs to subsequently 
configure the interface. So why the reliance of VPP’s given name? AFIAK VPP’s 
given name is only important when interpreting CLI output.
All control planes are free to choose whatever naming schemes they like, but 
they must maintain a control-plane-name to sw_if_index mapping. And to make VPP 
CLI output more useful, also maintain a control-plane-name to VPP-name mapping. 
In other words, X, is always the control-plane-name.

/neale


From: "John Lo (loj)" 
Date: Wednesday, 7 February 2018 at 15:34
To: "Neale Ranns (nranns)" , Jon Loeliger 
Cc: vpp-dev 
Subject: RE: [vpp-dev] VXLAN Tunnel IF Names

I guess Jon’s point was the control plane need to know exactly what X would be 
and not rely on VPP to provide the sw_if_index or query VPP for the name after 
the VXLAN create request.  This makes the control plane CLI script/template 
support more straight forward.  In the case of mixed usage where a requested 
instance is not available, I wonder how control plane should handle the error 
condition if it does not check the result of the VXLAN create request…   -John

From: Neale Ranns (nranns)
Sent: Wednesday, February 07, 2018 5:55 AM
To: Jon Loeliger ; John Lo (loj) 
Cc: vpp-dev 
Subject: Re: [vpp-dev] VXLAN Tunnel IF Names

Hi Jon,

I feel I must ask ☺
“That  has to match a VPP interface by name.  But what name?”
why does it need to match a VPP interface name? shouldn’t  = MyVxlan23. Your 
control plane maintains mappings between MyVxlan23 and VPP’s sw_if_index.

/neale


From: mailto:vpp-dev-boun...@lists.fd.io>> on 
behalf of Jon Loeliger mailto:j...@netgate.com>>
Date: Friday, 2 February 2018 at 22:08
To: "John Lo (loj)" mailto:l...@cisco.com>>
Cc: vpp-dev mailto:vpp-dev@lists.fd.io>>
Subject: Re: [vpp-dev] VXLAN Tunnel IF Names

On Wed, Jan 31, 2018 at 6:41 PM, John Lo (loj) 
mailto:l...@cisco.com>> wrote:
Hi Jon,

Hi John,

Thanks for taking the time to get back to me on this!

All VPP tunnel creation uses the mechanism of returning a sw_if_index of the 
created tunnel.

I know.  I get that.  It works.

The name of the tunnel is then followed by a number being the instance or index 
to the tunnel struct vector. Thus, the first VXLAN tunnel created is called 
vxlan_tunnel0 followed by vxlan_tunnel1, etc. The number is incrementing unless 
tunnels are deleted and created again where a newly created tunnel will reuse 
the last deleted tunnel, hence its name. If all previously deleted tunnels are 
used up, then the tunnel name number will start incrementing again.

Right.

I am not sure if it is feasible to follow this behavior to “predict” tunnel 
name.

It is not.

The problem is not just "predict it", but the user has to be
able to know the associated SW IF name at the time that
the (vxlan tunnel) create API call happens.

The reason for that is because the very next thing the
API call user is going to want to do is configure that interface.
Short of interrogating the system, there is no way to know
the IF name.  (I understand that the name can be obtained
from the sw_if_index.  That's not what I mean.)

Consider this series of PEUDO API calls that are being
issued by some client front-end.  Think of this as a batch
of CLI commands:

vxlan MyVxlan23
source 1.2.3.4
destination 10.11.12.13
vni 19
exit

interface 
do stuff to interface like apply an ACL or whatever
exit

There is no way to batch-run those as there is a step
needed to determine what  is.  It could be "vxlan_tunnel..."
anything.

That  has to match a VPP interface by name.  But what name?
The entire transactional  history of VXLANs must be known in
order to guess the next name.

BTW, GRE tunnels are created and named the same way. You added TEB (transparent 
ethernet bridging) support to GRE. Have you not been using it and bothered by 
how to predict name of created GRE tunnels?

I've not touched GRE yet.  However, it is next on my list to fix!
My current plan is to submit essentially the same patch there too.

It is not a good idea to tie tunnel name to VNI as it is not a unique ID to 
identify VXLAN tunnels. It is quite common for existence of multiple VXLAN 
tunnels with the same VNI with different remote end point IP addresses. A 
bridge domain (BD) may have multiple VXLAN tunnels with the same VNI to several 
remote servers where the same overlay network exist. It is quite common to use 
the ID for BD or VLAN as the VNI for all its VXLAN tunnels to make it easier to 
track their usage.

Excellent!  Thank you for this insight!  That makes total sense now!

I suppose it is feasible to provide another set of VXLAN tunnel create/delete 
API to allow caller to specify instance or number of the tunnel, similar to 
what you did for loopback interface.

This is the route I was headed:  Just like loopback interface naming!

In this case, the above 

[vpp-dev] Migration to Groups.io tomorrow morning 2/08

[Brendan OSullivan]

Greetings FD.io community!

We apologize for the relatively late notice, as this normally would have
been communicated earlier.

The Linux Foundation has connected with a new vendor called Groups.io,
which provides mailing list services in a simple but modern interface.
Groups.io offers all of the capabilities of our existing Mailman mailing
service plus additional community tools that make it an exceptional service
solution.

We are planning to set your project up with Groups.io service and migrate
your existing mailing list archives and user lists, including preferences,
tomorrow morning February 8th.

During the migration window you will still be able to access the archives,
however the delivery of messages sent to the mailing lists during this
window will be delayed until after the migration of the archives and list
members are complete. We will turn off new list signups during the
migration window, then this functionality will be restored once it is
complete.

FAQsWhat are the key differences between Mailman and Groups.io?

   -

   Groups.io has a modern interface, robust user security model, and
   interactive, searchable archives
   -

   Groups.io provides advanced features including muting threads and
   integrations with modern tools like GitHub, Slack, and Trello
   -

   Groups.io also has optional extras like a shared calendar, polling,
   chat, a wiki, and more
   -

   Groups.io uses a concept of subgroups, where members first join the
   project “group” (a master list), then they choose the specific “subgroup”
   lists they want to subscribe to


How do the costs compare?

   -

   The Linux Foundation can provide project-branded Groups.io accounts to
   projects for less cost than managing our in-house Mailman systems.


How is the experience different for me as a list moderator or participant?

In many ways, it is very much the same. You will still find the main group
at your existing URL and sub-groups equate to the more focused mailing
lists based on the community’s needs.

Here is an example of main group and sub-group URL patterns, and their
respective emails:

https://lists.projectname.org/g/main

https://lists.projectname.org/g/devs

https://lists.projectname.org/g/ci

m...@lists.projectname.org

d...@lists.projectname.org

c...@lists.projectname.org

One of the nice features of Groups.io is that you log in once, and can use
the My Groups dropdown in the top menu and easily move between the lists
that you are participating in without logging in to each of them separately.

Groups.io’s simple but highly functional UI that will make the experience
of moderating or participating in the community discussions more enjoyable.

If you’d like to learn more about using Groups.io , please reference their
help documentation . If you need assistance
with Groups.io, please email helpd...@rt.linuxfoundation.org for The Linux
Foundation’s helpdesk.

Cheers!
Brendan OSullivan

Helpdesk Analyst
The Linux Foundation 
___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev

[vpp-dev] Does VPP support flow control (pause frame)?

[Li, Charlie]

Hi All,

Does VPP support flow control?

If yes, how to turn on/off flow control?

Regards,
Charlie Li


___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev

Re: [vpp-dev] Does VPP support flow control (pause frame)?

[Damjan Marion (damarion)]

> On 7 Feb 2018, at 19:12, Li, Charlie  wrote:
> 
> Hi All,
> 
> Does VPP support flow control?
> 
> If yes, how to turn on/off flow control?

Not supported today but can be it shouldn't be too hard to add.


___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev

Re: [vpp-dev] VXLAN Tunnel IF Names

[Ed Warnicke]

Neale,

I think this really really fundamentally comes down to the ability to
configure in batch.  If I know I want to send something to vpp that creates
an interface and configures it in a *batch*, I can't know when I send that
batch configuration what sw_index will be.  So I either have to break up
the batch or have a way of getting a deterministic handle (name) to
configure the interface being created.When you are writing a local
control plane, you often just say "fuck it, I'm not going to be able to
batch.   But if you are writing a remote control plane (high latency per
message) or have a user copy pasting over configs via a CLI (not our CLI,
but another CLI you write) etc... batching is crucially important.

Ed




On Wed, Feb 7, 2018 at 7:18 AM Neale Ranns (nranns) 
wrote:

>
>
> But all control planes need to know the sw_if_index provided by VPP as it
> is this value (and not the interface name) that one needs to subsequently
> configure the interface. So why the reliance of VPP’s given name? AFIAK
> VPP’s given name is only important when interpreting CLI output.
>
> All control planes are free to choose whatever naming schemes they like,
> but they must maintain a control-plane-name to sw_if_index mapping. And to
> make VPP CLI output more useful, also maintain a control-plane-name to
> VPP-name mapping. In other words, X, is always the control-plane-name.
>
>
>
> /neale
>
>
>
>
>
> *From: *"John Lo (loj)" 
> *Date: *Wednesday, 7 February 2018 at 15:34
> *To: *"Neale Ranns (nranns)" , Jon Loeliger <
> j...@netgate.com>
> *Cc: *vpp-dev 
> *Subject: *RE: [vpp-dev] VXLAN Tunnel IF Names
>
>
>
> I guess Jon’s point was the control plane need to know exactly what X
> would be and not rely on VPP to provide the sw_if_index or query VPP for
> the name after the VXLAN create request.  This makes the control plane CLI
> script/template support more straight forward.  In the case of mixed usage
> where a requested instance is not available, I wonder how control plane
> should handle the error condition if it does not check the result of the
> VXLAN create request…   -John
>
>
>
> *From:* Neale Ranns (nranns)
> *Sent:* Wednesday, February 07, 2018 5:55 AM
> *To:* Jon Loeliger ; John Lo (loj) 
> *Cc:* vpp-dev 
> *Subject:* Re: [vpp-dev] VXLAN Tunnel IF Names
>
>
>
> Hi Jon,
>
>
>
> I feel I must ask J
>
> “That  has to match a VPP interface by name.  But what name?”
>
> why does it need to match a VPP interface name? shouldn’t  = MyVxlan23.
> Your control plane maintains mappings between MyVxlan23 and VPP’s
> sw_if_index.
>
>
>
> /neale
>
>
>
>
>
> *From: * on behalf of Jon Loeliger <
> j...@netgate.com>
> *Date: *Friday, 2 February 2018 at 22:08
> *To: *"John Lo (loj)" 
> *Cc: *vpp-dev 
> *Subject: *Re: [vpp-dev] VXLAN Tunnel IF Names
>
>
>
> On Wed, Jan 31, 2018 at 6:41 PM, John Lo (loj)  wrote:
>
> Hi Jon,
>
>
>
> Hi John,
>
>
>
> Thanks for taking the time to get back to me on this!
>
>
>
> All VPP tunnel creation uses the mechanism of returning a sw_if_index of
> the created tunnel.
>
>
>
> I know.  I get that.  It works.
>
>
>
> The name of the tunnel is then followed by a number being the instance or
> index to the tunnel struct vector. Thus, the first VXLAN tunnel created is
> called vxlan_tunnel0 followed by vxlan_tunnel1, etc. The number is
> incrementing unless tunnels are deleted and created again where a newly
> created tunnel will reuse the last deleted tunnel, hence its name. If all
> previously deleted tunnels are used up, then the tunnel name number will
> start incrementing again.
>
>
>
> Right.
>
>
>
> I am not sure if it is feasible to follow this behavior to “predict”
> tunnel name.
>
>
>
> It is not.
>
>
>
> The problem is not just "predict it", but the user has to be
>
> able to know the associated SW IF name at the time that
>
> the (vxlan tunnel) create API call happens.
>
>
>
> The reason for that is because the very next thing the
>
> API call user is going to want to do is configure that interface.
>
> Short of interrogating the system, there is no way to know
>
> the IF name.  (I understand that the name can be obtained
>
> from the sw_if_index.  That's not what I mean.)
>
>
>
> Consider this series of PEUDO API calls that are being
>
> issued by some client front-end.  Think of this as a batch
>
> of CLI commands:
>
>
>
> vxlan MyVxlan23
>
> source 1.2.3.4
>
> destination 10.11.12.13
>
> vni 19
>
> exit
>
>
>
> interface 
>
> do stuff to interface like apply an ACL or whatever
>
> exit
>
>
>
> There is no way to batch-run those as there is a step
>
> needed to determine what  is.  It could be "vxlan_tunnel..."
>
> anything.
>
>
>
> That  has to match a VPP interface by name.  But what name?
>
> The entire transactional  history of VXLANs must be known in
>
> order to guess the next name.
>
>
>
> BTW, GRE tunnels are created and named the same way. You added TEB
> (transparent ethernet bridging) support to GRE. Have you not been

Re: [vpp-dev] VXLAN Tunnel IF Names

[Florin Coras]

.. aand then one of the calls in the batch fails. Why not use a shim layer that 
on the one hand fits what Neale was saying and on the other it accepts batches 
and handles failures. Say .. netconf? :-)

Florin

> On Feb 7, 2018, at 2:10 PM, Ed Warnicke  wrote:
> 
> Neale,
> 
> I think this really really fundamentally comes down to the ability to 
> configure in batch.  If I know I want to send something to vpp that creates 
> an interface and configures it in a *batch*, I can't know when I send that 
> batch configuration what sw_index will be.  So I either have to break up the 
> batch or have a way of getting a deterministic handle (name) to configure the 
> interface being created.When you are writing a local control plane, you 
> often just say "fuck it, I'm not going to be able to batch.   But if you are 
> writing a remote control plane (high latency per message) or have a user copy 
> pasting over configs via a CLI (not our CLI, but another CLI you write) 
> etc... batching is crucially important.
> 
> Ed
> 
> 
> 
> 
> On Wed, Feb 7, 2018 at 7:18 AM Neale Ranns (nranns)  > wrote:
>  
> 
> But all control planes need to know the sw_if_index provided by VPP as it is 
> this value (and not the interface name) that one needs to subsequently 
> configure the interface. So why the reliance of VPP’s given name? AFIAK VPP’s 
> given name is only important when interpreting CLI output.
> 
> All control planes are free to choose whatever naming schemes they like, but 
> they must maintain a control-plane-name to sw_if_index mapping. And to make 
> VPP CLI output more useful, also maintain a control-plane-name to VPP-name 
> mapping. In other words, X, is always the control-plane-name.
> 
>  
> 
> /neale
> 
>  
> 
>  
> 
> From: "John Lo (loj)" mailto:l...@cisco.com>>
> Date: Wednesday, 7 February 2018 at 15:34
> To: "Neale Ranns (nranns)" mailto:nra...@cisco.com>>, Jon 
> Loeliger mailto:j...@netgate.com>>
> Cc: vpp-dev mailto:vpp-dev@lists.fd.io>>
> Subject: RE: [vpp-dev] VXLAN Tunnel IF Names
> 
>  
> 
> I guess Jon’s point was the control plane need to know exactly what X would 
> be and not rely on VPP to provide the sw_if_index or query VPP for the name 
> after the VXLAN create request.  This makes the control plane CLI 
> script/template support more straight forward.  In the case of mixed usage 
> where a requested instance is not available, I wonder how control plane 
> should handle the error condition if it does not check the result of the 
> VXLAN create request…   -John
> 
>  
> 
> From: Neale Ranns (nranns) 
> Sent: Wednesday, February 07, 2018 5:55 AM
> To: Jon Loeliger mailto:j...@netgate.com>>; John Lo (loj) 
> mailto:l...@cisco.com>>
> Cc: vpp-dev mailto:vpp-dev@lists.fd.io>>
> Subject: Re: [vpp-dev] VXLAN Tunnel IF Names
> 
>  
> 
> Hi Jon,
> 
>  
> 
> I feel I must ask J
> 
> “That  has to match a VPP interface by name.  But what name?”
> 
> why does it need to match a VPP interface name? shouldn’t  = MyVxlan23. 
> Your control plane maintains mappings between MyVxlan23 and VPP’s sw_if_index.
> 
>  
> 
> /neale
> 
>  
> 
>  
> 
> From: mailto:vpp-dev-boun...@lists.fd.io>> on 
> behalf of Jon Loeliger mailto:j...@netgate.com>>
> Date: Friday, 2 February 2018 at 22:08
> To: "John Lo (loj)" mailto:l...@cisco.com>>
> Cc: vpp-dev mailto:vpp-dev@lists.fd.io>>
> Subject: Re: [vpp-dev] VXLAN Tunnel IF Names
> 
>  
> 
> On Wed, Jan 31, 2018 at 6:41 PM, John Lo (loj)  > wrote:
> 
> Hi Jon,
> 
>  
> 
> Hi John, 
> 
>  
> 
> Thanks for taking the time to get back to me on this!
> 
>  
> 
> All VPP tunnel creation uses the mechanism of returning a sw_if_index of the 
> created tunnel.
> 
>  
> 
> I know.  I get that.  It works.
> 
>  
> 
> The name of the tunnel is then followed by a number being the instance or 
> index to the tunnel struct vector. Thus, the first VXLAN tunnel created is 
> called vxlan_tunnel0 followed by vxlan_tunnel1, etc. The number is 
> incrementing unless tunnels are deleted and created again where a newly 
> created tunnel will reuse the last deleted tunnel, hence its name. If all 
> previously deleted tunnels are used up, then the tunnel name number will 
> start incrementing again.
> 
>  
> 
> Right.
> 
>  
> 
> I am not sure if it is feasible to follow this behavior to “predict” tunnel 
> name.
> 
>  
> 
> It is not.
> 
>  
> 
> The problem is not just "predict it", but the user has to be
> 
> able to know the associated SW IF name at the time that
> 
> the (vxlan tunnel) create API call happens.
> 
>  
> 
> The reason for that is because the very next thing the
> 
> API call user is going to want to do is configure that interface.
> 
> Short of interrogating the system, there is no way to know
> 
> the IF name.  (I understand that the name can be obtained
> 
> from the sw_if_index.  That's not what I mean.)
> 
>  
> 
> Consider this series of PEUDO API calls that are being
> 
> issued by some client front-end.  Think of