Re: [vpp-dev] abf problem with arp

[brayan ortega]

Dear Neale,
Thanks for taking time and answer in details.
Answer comments inline.

On Thu, Jul 25, 2019 at 12:38 PM Neale Ranns (nranns) 
wrote:

>
>
> Hi Brayan,
>
>
>
> First let’s discuss a bit your config and your objectives:
>
>
>
>   acl ID 0 permit { any }
>
>   set int ip addr GigabitEthernetb/0/0 30.30.30.1/24
>
>   set int ip addr GigabitEthernet3/0/0 20.20.20.1/24
>
>
>
>   abf policy add id 9001 acl 0  via 0.0.0.0 GigabitEthernetb/0/0
>
>   abf attach ip4 policy 9001 priority 1 GigabitEthernet3/0/0
>
>
>
> I’m sure you know that you can achieve the same by replacing the ABF route
> with a default route, so no doubt this is a test for you and you intend to
> make the ACL more expressive.
>

Exactly. as well as that you said, my approach is check of abf flexibility
and its integrity and compatibility with some other features, especially
static routing and nat.


> So let’s consider some more scenarios. First we’ll correct policy rule to
> include the nexthop, since any packets not going to 30.30.30.0/24 need to
> be sent to a next-hop on the LAN (we’ll discount proxy ARP as a solution
> because it does scale to add an ARP entry for every host on the internet).
>
>
>
>   Acl ID 0 permit (tcp port 80 }
>
>   abf policy add id 9001 acl 0  via 30.30.30.2 GigabitEthernetb/0/0
>
>
>
> so if a packet now arrives for 30.30.30.3 to TCP port 80, where wold you
> like it to go? Do you want it to follow a routing decision and go to
> 30.30.30.3, or follow the abf decision to 30.30.30.2?
>

I would like to follow a routing decision for 30.30.30.0/24.


>
>
> now let’s add another connected subnet.
>
>
>
>   set int ip addr GigabitEthernet9/0/0 40.40.40.1/24
>
>
>
> packets destined to this subnet will also match the ABF rule. Again
> consider a packet to 40.40.40.2 do you want these packets to follow a
> routing decision and be forwarded to 40.40.40.2 on GigabitEthernet9/0/0 or
> to 30.30.30.2 on GigabitEthernetb/0/0?
>

same as former, it is needed to follow a routing decision.

>
>
> In general, when does a routing decision override the ABF result?
>
> In VPP’s ABF implementation the answer is never. The ABF feature runs
> first and it is the only decision that is made. If you want to change this
> behaviour you can ‘insert’ a routing decision by using it as the result of
> ABF. For example:
>
>
>
>   # create a table in which the post ABF routing decision will be made
>
>   ip table add 42
>
>   # add routes for prefixes that we want to override the ABF decision
>
>   # these routes will then perform a lookup in default table
>
>   ip route add table 42 30.30.30.0/24 via ip4-lookup-in-table 0
>
>   ip route add table 42 40.40.40.0/24 via ip4-lookup-in-table 0
>
>   # all the rest of the packets do the same as the ABF policy
>
>   ip route add table 42 0.0.0.0/24 via 30.30.30.2 GigabitEthernetb/0/0
>
>
>
>   # the ABF policy result in a lookup in our override table
>
>   abf policy add id 9001 acl 0  via ip4-lookup-in-table 42
>
>
>

Ok.Good job!. It seems resolve all of the Proposed Scenarios here. Thanks
for your example and sample configuration. I will check the abf plugin more
and share with you if I find other anomaly or ambiguity. Thanks in advance.

Best Regards,


>
>
> hope this helps,
>
> neale
>
>
>
>
>
>
>
> *De : *brayan ortega 
> *Date : *mercredi 24 juillet 2019 à 16:13
> *À : *"Neale Ranns (nranns)" 
> *Cc : *"vpp-dev@lists.fd.io" 
> *Objet : *Re: [vpp-dev] abf problem with arp
>
>
>
> Dear Neale,
>
> Thanks for your prompt response.
> Answer comments inline.
>
>
>
> On Wed, Jul 24, 2019 at 5:16 PM Neale Ranns (nranns) 
> wrote:
>
>
>
> Dear Brayan,
>
>
>
> You should always add a next-hop to a path when IP routing.
>
> Answers comments inline.
>
>
>
> /neale
>
>
>
> *De : * au nom de brayan ortega <
> brayan.ortega6...@gmail.com>
> *Date : *mercredi 24 juillet 2019 à 11:25
> *À : *"vpp-dev@lists.fd.io" 
> *Objet : *[vpp-dev] abf problem with arp
>
>
>
> Dear VPP Folks,
>
> I'm using vpp v19.08-rc0~698-g1f50bf8fc (master branch) and It seems there
> is a bug when the abf plugin is enabled and configured in my scenario.
>
> abf policy is defined as follows:
> 1- permit packets
> 2- route to output interface without gateway definition ( via 0.0.0.0 )
> 3- attaching it to input interfaces
> When the abf policy is defined as described, the connected networks to
> output interfaces will be unreachable. I checked the trace of packets and
> saw the following. First, an icmp packet is received on input interface.
> Then arp packet is sent and arp reply is received. But in next icmp packet
> again this scenario happens while we have an entry for destination ip in
> arp table. however, arp reply is dropped and  "arp-disabled: ARP Disabled
> on this interface" log is seen in trace output. My vppctl trace output is
> available here: https://paste.ubuntu.com/p/pB2sh3GxrD/
>
> The following is the ping result from my client:
>
> Client 1: ping 30.30.30.2 ( 30.30.30.30 is my router ip address) isn't
> esta

Re: [vpp-dev] abf problem with arp

[brayan ortega]

Dear Neale,
I have tried to config vpp based on your proposed configuration and after
apply this command "abf policy add id 9001 acl 0  via ip4-lookup-in-table
42", a Segfault is happened.
I'm using vpp v19.08-rc0~698-g1f50bf8fc (master branch). also, I checked it
on vpp 19.04 and the result was same.


log:
2019 Jul 28 10:30:08  received signal SIGSEGV, PC 0x7fc588126c6c, faulting
address 0x
2019 Jul 28 10:30:08 #0  0x7fc5875b604b 0x7fc5875b604b
2019 Jul 28 10:30:08 #1  0x7fc586edc890 0x7fc586edc890
2019 Jul 28 10:30:08 #2  0x7fc588126c6c unformat_fib_route_path + 0x3ec
2019 Jul 28 10:30:08 #3  0x7fc586a9e5bb va_unformat + 0x6bb
2019 Jul 28 10:30:08 #4  0x7fc586a9ec67 unformat + 0x87
2019 Jul 28 10:30:08 #5  0x7fc545aa1114 0x7fc545aa1114
2019 Jul 28 10:30:08 #6  0x7fc58754d859 0x7fc58754d859
2019 Jul 28 10:30:08 #7  0x7fc58754db95 0x7fc58754db95
2019 Jul 28 10:30:08 #8  0x7fc58754df44 vlib_cli_input + 0xa4
2019 Jul 28 10:30:08 #9  0x7fc5875afbea 0x7fc5875afbea
2019 Jul 28 10:30:08 #10 0x7fc5875b3998 0x7fc5875b3998
2019 Jul 28 10:30:08 #11 0x7fc58756ae36 0x7fc58756ae36
2019 Jul 28 10:30:08 #12 0x7fc586a597fc 0x7fc586a597fc

Best regards, Brayan

On Thu, Jul 25, 2019 at 12:38 PM Neale Ranns (nranns) 
wrote:

>
>
> Hi Brayan,
>
>
>
> First let’s discuss a bit your config and your objectives:
>
>
>
>   acl ID 0 permit { any }
>
>   set int ip addr GigabitEthernetb/0/0 30.30.30.1/24
>
>   set int ip addr GigabitEthernet3/0/0 20.20.20.1/24
>
>
>
>   abf policy add id 9001 acl 0  via 0.0.0.0 GigabitEthernetb/0/0
>
>   abf attach ip4 policy 9001 priority 1 GigabitEthernet3/0/0
>
>
>
> I’m sure you know that you can achieve the same by replacing the ABF route
> with a default route, so no doubt this is a test for you and you intend to
> make the ACL more expressive. So let’s consider some more scenarios. First
> we’ll correct policy rule to include the nexthop, since any packets not
> going to 30.30.30.0/24 need to be sent to a next-hop on the LAN (we’ll
> discount proxy ARP as a solution because it does scale to add an ARP entry
> for every host on the internet).
>
>
>
>   Acl ID 0 permit (tcp port 80 }
>
>   abf policy add id 9001 acl 0  via 30.30.30.2 GigabitEthernetb/0/0
>
>
>
> so if a packet now arrives for 30.30.30.3 to TCP port 80, where wold you
> like it to go? Do you want it to follow a routing decision and go to
> 30.30.30.3, or follow the abf decision to 30.30.30.2?
>
>
>
> now let’s add another connected subnet.
>
>
>
>   set int ip addr GigabitEthernet9/0/0 40.40.40.1/24
>
>
>
> packets destined to this subnet will also match the ABF rule. Again
> consider a packet to 40.40.40.2 do you want these packets to follow a
> routing decision and be forwarded to 40.40.40.2 on GigabitEthernet9/0/0 or
> to 30.30.30.2 on GigabitEthernetb/0/0?
>
>
>
> In general, when does a routing decision override the ABF result?
>
> In VPP’s ABF implementation the answer is never. The ABF feature runs
> first and it is the only decision that is made. If you want to change this
> behaviour you can ‘insert’ a routing decision by using it as the result of
> ABF. For example:
>
>
>
>   # create a table in which the post ABF routing decision will be made
>
>   ip table add 42
>
>   # add routes for prefixes that we want to override the ABF decision
>
>   # these routes will then perform a lookup in default table
>
>   ip route add table 42 30.30.30.0/24 via ip4-lookup-in-table 0
>
>   ip route add table 42 40.40.40.0/24 via ip4-lookup-in-table 0
>
>   # all the rest of the packets do the same as the ABF policy
>
>   ip route add table 42 0.0.0.0/24 via 30.30.30.2 GigabitEthernetb/0/0
>
>
>
>   # the ABF policy result in a lookup in our override table
>
>   abf policy add id 9001 acl 0  via ip4-lookup-in-table 42
>
>
>
>
>
> hope this helps,
>
> neale
>
>
>
>
>
>
>
> *De : *brayan ortega 
> *Date : *mercredi 24 juillet 2019 à 16:13
> *À : *"Neale Ranns (nranns)" 
> *Cc : *"vpp-dev@lists.fd.io" 
> *Objet : *Re: [vpp-dev] abf problem with arp
>
>
>
> Dear Neale,
>
> Thanks for your prompt response.
> Answer comments inline.
>
>
>
> On Wed, Jul 24, 2019 at 5:16 PM Neale Ranns (nranns) 
> wrote:
>
>
>
> Dear Brayan,
>
>
>
> You should always add a next-hop to a path when IP routing.
>
> Answers comments inline.
>
>
>
> /neale
>
>
>
> *De : * au nom de brayan ortega <
> brayan.ortega6...@gmail.com>
> *Date : *mercredi 24 juillet 2019 à 11:25
> *À : *"vpp-dev@lists.fd.io" 
> *Objet : *[vpp-dev] abf problem with arp
>
>
>
> Dear VPP Folks,
>
> I'm using vpp v19.08-rc0~698-g1f50bf8fc (master branch) and It seems there
> is a bug when the abf plugin is enabled and configured in my scenario.
>
> abf policy is defined as follows:
> 1- permit packets
> 2- route to output interface without gateway definition ( via 0.0.0.0 )
> 3- attaching it to input interfaces
> When the abf policy is defined as described, the connected networks to
> output interfaces will be unreachable. I 

Re: [vpp-dev] TCP host stack & small size fifo

[Max A. via Lists.Fd.Io]

Hi Florin,

I simplified the application. It sends the request and reads all the data from 
the server using the 8 KB buffer. The fifo size is set to 8 KB. In the attached 
dump [1] you can see that in packet number 14 there will be an overflow of the 
size of the tcp window. My application reports the size of the received block. 
If the tcp window size is full, the application receives 7240 bytes from vpp. 
Next, the application receives data no larger than 6 KB, and the problem does 
not occur. At what point in time does vpp decide that the buffer is full, 
before I get the data from the read function?
There is also a slightly different question. Is the fifo allocated for the all 
lifetime of the session?

Thanks.

[1]  https://drive.google.com/open?id=1Q__5UgnBAKoRGfaGaqIxAVNWqoSCzIPZ  

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

View/Reply Online (#13597): https://lists.fd.io/g/vpp-dev/message/13597
Mute This Topic: https://lists.fd.io/mt/32582078/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] TCP host stack & small size fifo

[Florin Coras]

Hi Max,

Inline.

> On Jul 28, 2019, at 10:47 AM, Max A.  wrote:
> 
> Hi Florin,
> 
> I simplified the application. It sends the request and reads all the data 
> from the server using the 8 KB buffer. The fifo size is set to 8 KB. In the 
> attached dump [1] you can see that in packet number 14 there will be an 
> overflow of the size of the tcp window.

Looks much better. I suspect that the issue with packet 14 is the fact that vpp 
accepts the session and notifies vcl of it, but vcl needs a bit of time to 
initialize its state and therefore won’t manage to read any data prior to the 
fifo being filled. 

> My application reports the size of the received block. If the tcp window size 
> is full, the application receives 7240 bytes from vpp. Next, the application 
> receives data no larger than 6 KB, and the problem does not occur. At what 
> point in time does vpp decide that the buffer is full, before I get the data 
> from the read function?

TCP in vpp processes bursts of packets (up to 256). If a packet in a burst is 
accepted, tcp enqueues its data in the associated session's rx fifo, shared 
with the app, and it sends a notification for that session at the end of the 
burst only if the fifo does not already have one. From what you’re seeing, not 
all 7240B come in a burst, so vcl gets a notification before the rx fifo fills.
 
> There is also a slightly different question. Is the fifo allocated for the 
> all lifetime of the session?

Short answer yes. It’s just a chunk of memory shared by the session layer with 
vcl.

Longer answer is that the fifo's data portion (where connection data is stored) 
can be grown, so more data could be enqueued. But fifo growth is not managed 
transparently by the session layer (i.e., no auto tuning), and at this time, 
external applications (like vcl) can’t control the fifo size. 

Florin

> 
> Thanks.
> 
> [1] https://drive.google.com/open?id=1Q__5UgnBAKoRGfaGaqIxAVNWqoSCzIPZ 
>  
> 
> -- 
> Max A.

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

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

[vpp-dev] #vpp Connecting a VPP inside a container to a VPP inside host using vhost-virtio-user interfaces

[mojtaba.eshghi]

Hi Guys,

I'm trying to connect a vpp inside a host to a vpp which is running inside a 
lxc container on a linux machine. I am going to do that via vhost-virtio-user.
The problem is that after I create the vhost and virtio-user, the output of the 
"show vhost-user interfaces" command on the host vpp is as below:

(it seems that a handshake is not done in the right way, the "memory regions 
(total 0)" part...).
* VPP 19.x does not support "debug vhost on" cli command.
I will put my configuration files one by one here.

Here is my startup.conf for host vpp:

This one is startup.conf of the container VPP:

These are the commands issued in the host vpp:
create vhost-user socket /etc/vpp/sock3.sock server
set int state VirtualEthernet0/0/0 up

Both virtio-user0 interface in container vpp and the virtualethernet0/0/0 
inside the host are created successfully. When I check the "htop" utility, it 
seems that after creation of these interfaces both of vpps begin to poll (CPU 
usage 100% on two cores).
ANY HELP WOULD BE APPRECIATED

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

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

[vpp-dev] The correct usage of "classify table" and "classify session" for IOAM traffic

[mojtaba . eshghi]

[Edited Message Follows]

Hi,

I'm trying to extend the usage of the following configuration to use iperf:

https://github.com/CiscoDevNet/iOAM/tree/master/scripts/vpp_sandbox/example/simple-ip6

The current problem is with the acls. Which are defined this way:

set ioam-trace profile trace-type 0x9 trace-elts 3 trace-tsp 2 node-id 0x3
classify table miss-next ip6-node ip6-lookup mask l3 ip6 dst
classify session acl-hit-next ip6-node ip6-lookup table-index 0 match l3 ip6 
dst db03::02 ioam-decap flow1
set int input acl intfc host-l_c2 ip6-table 0
set int input acl intfc host-l_c1 ip6-table 0

The end-to-end ping6 works fine, but iperf doesn't work. When I don't use the 
mentioned acls and classifications, both iperf and ping work properly (but of 
course the ioam in this case does not work).
Does anyone know how can I properly classify the traffic to apply the ioam?
There are examples in https://docs.fd.io/vpp/18.04/ioam_plugin_doc.html. 
However, as I said they just work for the ping and not for any type of L4 
traffic (the current config files are similar to what is prescribed in these 
docs).

I'm using the stable release 18.01

Best Regards,

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

View/Reply Online (#13405): https://lists.fd.io/g/vpp-dev/message/13405
Mute This Topic: https://lists.fd.io/mt/32270029/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 Connecting a VPP inside a container to a VPP inside host using vhost-virtio-user interfaces

[steven luong via Lists.Fd.Io]

The debug CLI was replaced by
set logging class vhost-user level debug
Use show log to view the messages.

Did you configure 1GB huge on the container? It used to be that dpdk virtio 
requires 1GB huge page. Not sure if it is still the case nowadays. If you use 
VPP 19.04 or later, you could try VPP native virtio instead.

Steven

From:  on behalf of "mojtaba.eshghi" 

Date: Sunday, July 28, 2019 at 1:56 PM
To: "vpp-dev@lists.fd.io" 
Subject: [vpp-dev] #vpp Connecting a VPP inside a container to a VPP inside 
host using vhost-virtio-user interfaces


Hi Guys,

I'm trying to connect a vpp inside a host to a vpp which is running inside a 
lxc container on a linux machine. I am going to do that via vhost-virtio-user.
The problem is that after I create the vhost and virtio-user, the output of the 
"show vhost-user interfaces" command on the host vpp is as below:

[cid:attach_0_15B5ADA3A865928D_10559@lists.fd.io]

(it seems that a handshake is not done in the right way, the "memory regions 
(total 0)" part...).
* VPP 19.x does not support "debug vhost on" cli command.
I will put my configuration files one by one here.

Here is my startup.conf for host vpp:

[cid:attach_1_15B5ADA3A86981DB_10559@lists.fd.io]


This one is startup.conf of the container VPP:
[cid:attach_2_15B5ADA3A86B4E72_10559@lists.fd.io]

These are the commands issued in the host vpp:
create vhost-user socket /etc/vpp/sock3.sock server
set int state VirtualEthernet0/0/0 up

Both virtio-user0 interface in container vpp and the virtualethernet0/0/0 
inside the host are created successfully. When I check the "htop" utility, it 
seems that after creation of these interfaces both of vpps begin to poll (CPU 
usage 100% on two cores).
ANY HELP WOULD BE APPRECIATED

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

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

[vpp-dev] SIGSEGV when adding route and abf with the same gateway

[fdr . kozlov]

Hi vpp-dev
When I add an abf policy and then add a route to the same gateway, a SIGSEGV 
will appear.
These are the steps to generate the problem:
First setup interfaces:
vppctl set int state GigabitEthernet3/0/0 up
vppctl set int state GigabitEthernet4/0/0 up
vppctl set int ip address GigabitEthernet3/0/0 200.200.200.2/24
vppctl set int ip address GigabitEthernet4/0/0 100.100.100.1/24
Now create an acl using vpp_api_test
acl_add_replace permit dst 1.1.1.1
And then add abf policy and route which cause crash
vppctl abf policy add id 9001 acl 0 via 100.100.100.2 GigabitEthernet4/0/0
vppctl abf attach ip4 policy 9001 priority 1 GigabitEthernet3/0/0
vppctl ip route add 8.8.8.0/24 via 100.100.100.2 GigabitEthernet4/0/0

I see this SIGSEGV on both master and stable/1904 branches:

received signal SIGSEGV, PC 0x7f51a1b60160, faulting address 0x7f61608d8814
#0  0x7f51a0fde0db 0x7f51a0fde0db
#1  0x7f51a0904890 0x7f51a0904890
#2  0x7f51a1b60160 fib_urpf_list_lock + 0x10
#3  0x7f51a1b5408f fib_entry_src_mk_lb + 0x1bf
#4  0x7f51a1b54391 fib_entry_src_action_install + 0x131
#5  0x7f51a1b51691 fib_entry_create + 0x71
#6  0x7f51a1b486b8 fib_table_entry_update + 0x1c8
#7  0x7f51a1b6398e fib_api_route_add_del + 0x7e
#8  0x7f51a1879e3f vl_api_ip_route_add_del_t_handler + 0x21f
#9  0x7f51a1f26d8c vl_msg_api_handler_with_vm_node + 0x8c
#10 0x7f51a1f0b815 vl_mem_api_handle_msg_main + 0x45
#11 0x7f51a1f1b38d 0x7f51a1f1b38d
#12 0x7f51a0f92ea6 0x7f51a0f92ea6
#13 0x7f51a04818bc 0x7f51a04818bc

What should I do to solve this problem?
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

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