date:20190304

Re: [vpp-dev] One question about vpp configuration file

2019-03-04 Thread Damjan Marion via Lists.Fd.Io



> On 5 Mar 2019, at 08:01, Zhang, Yuwei1  wrote:
> 
> Hello All,
>  I noticed there’s a config option in startup.conf file named 
> scheduler-priority, from the comments, it seems related to scheduling policy 
> about main and worker threads, could anybody give me some more detail 
> explanation? Thanks for your kindly help.

It just passes value to “sched_setscheduler" system call.
You can consult “sched_setscheduler” man page for details.

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

View/Reply Online (#12430): https://lists.fd.io/g/vpp-dev/message/12430
Mute This Topic: https://lists.fd.io/mt/30223908/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 the ipsec policy matching

2019-03-04 Thread Damjan Marion via Lists.Fd.Io



> On 5 Mar 2019, at 04:25, Zhang, Yuwei1  wrote:
> 
> Hello All,
>  I’m doing some investigation on ipsec in vpp recently, I noticed 
> that the ipsec policy matching part using a very simple linear search 
> algorithm which works fine in the case only have a few policy entries, but 
> once the policy entries number increase, the performance should be terrible. 
> Do we have any plan or better solution for this kind of scenario? Thanks for 
> your kindly help in advance.

Yes, it is on todo list but AFAIK nobody working on it. Contributions are 
welcome…
Main challenge is to convert address range into address mask(s) as RFC authors 
decided to make it hard for computers.


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

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

2019-03-04 Thread Damjan Marion via Lists.Fd.Io



> On 4 Mar 2019, at 22:52, Thomas F Herbert  wrote:
> 
> Damjan et. al.
> 
> I get build failures when builging from a tarball  outside of git tree on 
> 19.01
> 
> I documented this in https://jira.fd.io/browse/VPP-1577 
> 
> This is not reproduceable when building in git tree.
> 
> Could you please take a look at the cmake output and give me some suggestions.
> 
> —Tom
> 

It is likely fixed in master, please try with master.

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

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

[vpp-dev] One question about vpp configuration file

2019-03-04 Thread Zhang Yuwei

Hello All,
 I noticed there's a config option in startup.conf file named 
scheduler-priority, from the comments, it seems related to scheduling policy 
about main and worker threads, could anybody give me some more detail 
explanation? Thanks for your kindly help.

Regards,
Yuwei

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

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

[vpp-dev] Question about the ipsec policy matching

2019-03-04 Thread Zhang Yuwei

Hello All,
 I'm doing some investigation on ipsec in vpp recently, I noticed that 
the ipsec policy matching part using a very simple linear search algorithm 
which works fine in the case only have a few policy entries, but once the 
policy entries number increase, the performance should be terrible. Do we have 
any plan or better solution for this kind of scenario? Thanks for your kindly 
help in advance.

Regards,
Yuwei

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

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

2019-03-04 Thread Thomas F Herbert




On 03/04/2019 05:12 PM, Paul Vinciguerra wrote:
Is this a “must have” or a “nice to have” feature?  I guess what I’m 
really asking is if this belongs in a CI job.
This breaks the building of downstream RPMs for CentOS. Until the 1807 
release, we have been maintaining this feature.
The downstream RPMs are built from a spec file and tarball created by 
the dist target in the top level Makefile


I am trying to write a patch to fix it. It would be preferable to have 
the patch backported but for now,
I am looking for help from CMake experts to see what is causing this 
side affect.

Paul

On Mar 4, 2019, at 4:52 PM, Thomas F Herbert > wrote:



Damjan et. al.

I get build failures when builging from a tarball  outside of git 
tree on 19.01


I documented this in https://jira.fd.io/browse/VPP-1577

This is not reproduceable when building in git tree.

Could you please take a look at the cmake output and give me some 
suggestions.


--Tom

--
*Thomas F Herbert*
NFV and Fast Data Planes
Networking Group Office of the CTO
*Red Hat*
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#12423): https://lists.fd.io/g/vpp-dev/message/12423
Mute This Topic: https://lists.fd.io/mt/30219549/1594641
Group Owner: vpp-dev+ow...@lists.fd.io 
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub 
 [pvi...@vinciconsulting.com ]

-=-=-=-=-=-=-=-=-=-=-=-


--
*Thomas F Herbert*
NFV and Fast Data Planes
Networking Group Office of the CTO
*Red Hat*
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

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

2019-03-04 Thread Paul Vinciguerra

Is this a “must have” or a “nice to have” feature?  I guess what I’m really 
asking is if this belongs in a CI job. 

Paul

> On Mar 4, 2019, at 4:52 PM, Thomas F Herbert  wrote:
> 
> Damjan et. al.
> 
> I get build failures when builging from a tarball  outside of git tree on 
> 19.01
> 
> I documented this in https://jira.fd.io/browse/VPP-1577
> 
> This is not reproduceable when building in git tree.
> 
> Could you please take a look at the cmake output and give me some suggestions.
> 
> --Tom
> 
> -- 
> Thomas F Herbert 
> NFV and Fast Data Planes 
> Networking Group Office of the CTO 
> Red Hat
> -=-=-=-=-=-=-=-=-=-=-=-
> Links: You receive all messages sent to this group.
> 
> View/Reply Online (#12423): https://lists.fd.io/g/vpp-dev/message/12423
> Mute This Topic: https://lists.fd.io/mt/30219549/1594641
> Group Owner: vpp-dev+ow...@lists.fd.io
> Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub  [pvi...@vinciconsulting.com]
> -=-=-=-=-=-=-=-=-=-=-=-
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

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

[vpp-dev] Build failure question

2019-03-04 Thread Thomas F Herbert


Damjan et. al.

I get build failures when builging from a tarball  outside of git tree 
on 19.01


I documented this in https://jira.fd.io/browse/VPP-1577

This is not reproduceable when building in git tree.

Could you please take a look at the cmake output and give me some 
suggestions.


--Tom

--
*Thomas F Herbert*
NFV and Fast Data Planes
Networking Group Office of the CTO
*Red Hat*
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#12423): https://lists.fd.io/g/vpp-dev/message/12423
Mute This Topic: https://lists.fd.io/mt/30219549/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 node on a feature arc

2019-03-04 Thread Dave Barach via Lists.Fd.Io

Check out boilerplate examples of the form:

  vlib_buffer_t *bufs[VLIB_FRAME_SIZE], **b;
  u16 nexts[VLIB_FRAME_SIZE], *next;
  
  from = vlib_frame_vector_args (frame);
  n_left_from = frame->n_vectors;

  vlib_get_buffers (vm, from, bufs, n_left_from);
  b = bufs;
  next = nexts;

  while (n_left_from > 0)
{
  

  b += 1 | 2 | 4;
  next += 1 | 2 | 4;
  n_left_from -= 1 | 2 | 4;
}

  vlib_buffer_enqueue_to_next (vm, node, from, nexts, frame->n_vectors);

  return frame->n_vectors;

Damjan optimized the heck out of the buffer / frame / next handling code used 
in the example. 

The emacs-lisp boilerplate generator will cough up a working plugin skeleton of 
this form, if you answer "qs" when asked to pick a dispatch style. 

You'll probably be much happier using this pattern than trying to roll your own.

HTH... Dave

-Original Message-
From: Prashant Upadhyaya  
Sent: Monday, March 4, 2019 1:21 PM
To: Neale Ranns (nranns) 
Cc: Dave Barach (dbarach) ; vpp-dev@lists.fd.io
Subject: Re: [vpp-dev] Regarding node on a feature arc

Hi Neale,

In one of the usecases I deviated from the normal boilerplate and started 
getting frames to target nodes with vlib_get_frame_to_node and doing put's to 
those, the advantage was that I could iterate through the entire input vector 
and queue up elements on frames of relevant nodes and then finally do a put of 
those frames when I returned from the node. It could be debated whether this 
should be done at all, but then the strategy was dependent on the index of 
vlib_node_t of the target node. Hence the question for the usecase when I don't 
have the next node index in terms of the vlib_node_t's index of the target node.

Regards
-Prashant




On Mon, Mar 4, 2019 at 9:31 PM Neale Ranns (nranns)  wrote:
>
>
> I'll bite __ why would you want to do that?
>
> /neale
>
> -Message d'origine-
> De :  au nom de Prashant Upadhyaya 
>  Date : lundi 4 mars 2019 à 16:06 À : "Dave 
> Barach (dbarach)"  Cc : "vpp-dev@lists.fd.io" 
>  Objet : Re: [vpp-dev] Regarding node on a 
> feature arc
>
> Thanks Dave, this is cool !
>
> Regards
> -Prashant
>
>
> On Mon, Mar 4, 2019 at 8:29 PM Dave Barach (dbarach)  
> wrote:
> >
> > You have: vlib_node_runtime_t *node. Use n = vlib_get_node(vm, 
> node->node_index) to recover the vlib_node_t.
> >
> > Index n->next_nodes to recover the node index corresponding to the next 
> index you have in mind: nNext = vlib_get_node (vm, n->next_nodes[i])
> >
> > HTH... Dave
> >
> > -Original Message-
> > From: vpp-dev@lists.fd.io  On Behalf Of Prashant 
> Upadhyaya
> > Sent: Monday, March 4, 2019 9:29 AM
> > To: vpp-dev@lists.fd.io
> > Subject: [vpp-dev] Regarding node on a feature arc
> >
> > Hi,
> >
> > When a node is on a feature arc, a good practice for that node is to 
> inspect the next feature with vnet_feature_next, obtain the next0 from that 
> and send the packets to the next0. All this works properly.
> >
> > My question -- how can I obtain the true vlib_node_t pointer 
> corresponding to the next0 as obtained from vnet_feature_next ?
> >
> > Regards
> > -Prashant
>
>
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#12422): https://lists.fd.io/g/vpp-dev/message/12422
Mute This Topic: https://lists.fd.io/mt/30213927/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] NAT: no free reassembly slot

2019-03-04 Thread carlito nueno

Hi Ole,

-l option worked. I set it to 16 rather than the default 8 KB.

I actually came to this problem while trying to figure out another
issue (I don't know if it's related).
I had a chance to test my VPP setup using an ixia box.
For some reason, ixia test was working only in one direction (sending
packets from 10.155.6.x to 10.155.3.x)
But while sending in the opposite direction, both TCP and UDP tests
failed. Packets are being dropped by VPP.

Packet capture showed these two outputs:
error-drop ip4-input: ip4 length > l2 length
error-drop, null-node: blackholed packets

Here is my vpp.conf and packet capture:
https://gist.github.com/ironpillow/9b1c5dd0905135ff09eba6067db179ae

- Do you think the issues are related?
- Also, how can I reproduce this with iperf?

Thanks for taking the time.

On Mon, Mar 4, 2019 at 12:00 PM Ole Troan  wrote:
>
> > Got it.
> >
> > Since I wanted to test both upstream and downstream with iperf3, I was
> > using -R option.
> > Even with disabling virtual-reassembly, packets are being dropped (see 
> > below).
> >
> > Switching server to 10.155.6.x  and client on 10.155.3.x works.
> > So, for this kind of test, do you recommend switching client and
> > server subnets instead of running iperf3 with -R.
>
> I’m recommending not triggering fragmentation.
> Fragments are NAT unfriendly.
> iperf with -l being sensible, as in not 8KB for TCP. Unless you have an 8KB+ 
> MTU.
>
> The iperf authors have clearly not read our draft in intarea. ;-)
>
> Cheers,
> Ole
>
>
> >
> > here are the dropped packets:
> >
> > Packet 49
> >
> > 00:19:41:823757: dpdk-input
> >  GigabitEthernet5/0/0 rx queue 0
> >  buffer 0x2dd18: current data 0, length 834, free-list 0, clone-count
> > 0, totlen-nifb 0, trace 0x30
> >  ext-hdr-valid
> >  l4-cksum-computed l4-cksum-correct l2-hdr-offset 0
> >  PKT MBUF: port 3, nb_segs 1, pkt_len 834
> >buf_len 2176, data_len 834, ol_flags 0x180, data_off 128,
> > phys_addr 0xe8b74680
> >packet_type 0x11 l2_len 0 l3_len 0 outer_l2_len 0 outer_l3_len 0
> >rss 0x0 fdir.hi 0x0 fdir.lo 0x0
> >Packet Offload Flags
> >  PKT_RX_IP_CKSUM_GOOD (0x0080) IP cksum of RX pkt. is valid
> >  PKT_RX_L4_CKSUM_GOOD (0x0100) L4 cksum of RX pkt. is valid
> >Packet Types
> >  RTE_PTYPE_L2_ETHER (0x0001) Ethernet packet
> >  RTE_PTYPE_L3_IPV4 (0x0010) IPv4 packet without extension headers
> >  IP4: c0:56:27:11:f2:ac -> de:ad:00:00:00:05
> >  UDP: 10.155.6.111 -> 10.155.3.201
> >tos 0x00, ttl 64, length 820, checksum 0x843f
> >fragment id 0xd06f offset 7400, flags
> >  UDP: 23507 -> 4311
> >length 43450, checksum 0x6383
> > 00:19:41:823759: ethernet-input
> >  IP4: c0:56:27:11:f2:ac -> de:ad:00:00:00:05
> > 00:19:41:823760: l2-input
> >  l2-input: sw_if_index 4 dst de:ad:00:00:00:05 src c0:56:27:11:f2:ac
> > 00:19:41:823760: l2-learn
> >  l2-learn: sw_if_index 4 dst de:ad:00:00:00:05 src c0:56:27:11:f2:ac 
> > bd_index 5
> > 00:19:41:823760: l2-fwd
> >  l2-fwd:   sw_if_index 4 dst de:ad:00:00:00:05 src c0:56:27:11:f2:ac 
> > bd_index 5
> > 00:19:41:823761: ip4-input
> >  UDP: 10.155.6.111 -> 10.155.3.201
> >tos 0x00, ttl 64, length 820, checksum 0x843f
> >fragment id 0xd06f offset 7400, flags
> >  UDP: 23507 -> 4311
> >length 43450, checksum 0x6383
> > 00:19:41:823761: nat44-in2out
> >  NAT44_IN2OUT_FAST_PATH: sw_if_index 19, next index 4, session -1
> > 00:19:41:823761: nat44-in2out-reass
> >  NAT44_REASS: sw_if_index 19, next index 1, status translated
> > 00:19:41:823762: error-drop
> >  nat44-in2out-reass: Drop fragment
> >
> > Packet 50
> >
> > 00:19:41:824581: dpdk-input
> >  GigabitEthernet5/0/0 rx queue 0
> >  buffer 0x1b3a8: current data 0, length 1514, free-list 0,
> > clone-count 0, totlen-nifb 0, trace 0x31
> >  ext-hdr-valid
> >  l4-cksum-computed l4-cksum-correct l2-hdr-offset 0
> >  PKT MBUF: port 3, nb_segs 1, pkt_len 1514
> >buf_len 2176, data_len 1514, ol_flags 0x180, data_off 128,
> > phys_addr 0xe86cea80
> >packet_type 0x11 l2_len 0 l3_len 0 outer_l2_len 0 outer_l3_len 0
> >rss 0x0 fdir.hi 0x0 fdir.lo 0x0
> >Packet Offload Flags
> >  PKT_RX_IP_CKSUM_GOOD (0x0080) IP cksum of RX pkt. is valid
> >  PKT_RX_L4_CKSUM_GOOD (0x0100) L4 cksum of RX pkt. is valid
> >Packet Types
> >  RTE_PTYPE_L2_ETHER (0x0001) Ethernet packet
> >  RTE_PTYPE_L3_IPV4 (0x0010) IPv4 packet without extension headers
> >  IP4: c0:56:27:11:f2:ac -> de:ad:00:00:00:05
> >  UDP: 10.155.6.111 -> 10.155.3.201
> >tos 0x00, ttl 64, length 1500, checksum 0x8700
> >fragment id 0xaea3, flags MORE_FRAGMENTS
> >  UDP: 5201 -> 47346
> >length 8200, checksum 0x5570
> > 00:19:41:824582: ethernet-input
> >  IP4: c0:56:27:11:f2:ac -> de:ad:00:00:00:05
> > 00:19:41:824583: l2-input
> >  l2-input: sw_if_index 4 dst de:ad:00:00:00:05 src c0:56:27:11:f2:ac
> > 00:19:41:824583: l2-learn
> >  l2-learn: sw_if_index 4 dst de:ad:00:00:00:05 src

Re: [vpp-dev] NAT: no free reassembly slot

2019-03-04 Thread Ole Troan

> Got it.
> 
> Since I wanted to test both upstream and downstream with iperf3, I was
> using -R option.
> Even with disabling virtual-reassembly, packets are being dropped (see below).
> 
> Switching server to 10.155.6.x  and client on 10.155.3.x works.
> So, for this kind of test, do you recommend switching client and
> server subnets instead of running iperf3 with -R.

I’m recommending not triggering fragmentation.
Fragments are NAT unfriendly.
iperf with -l being sensible, as in not 8KB for TCP. Unless you have an 8KB+ 
MTU.

The iperf authors have clearly not read our draft in intarea. ;-)

Cheers,
Ole


> 
> here are the dropped packets:
> 
> Packet 49
> 
> 00:19:41:823757: dpdk-input
>  GigabitEthernet5/0/0 rx queue 0
>  buffer 0x2dd18: current data 0, length 834, free-list 0, clone-count
> 0, totlen-nifb 0, trace 0x30
>  ext-hdr-valid
>  l4-cksum-computed l4-cksum-correct l2-hdr-offset 0
>  PKT MBUF: port 3, nb_segs 1, pkt_len 834
>buf_len 2176, data_len 834, ol_flags 0x180, data_off 128,
> phys_addr 0xe8b74680
>packet_type 0x11 l2_len 0 l3_len 0 outer_l2_len 0 outer_l3_len 0
>rss 0x0 fdir.hi 0x0 fdir.lo 0x0
>Packet Offload Flags
>  PKT_RX_IP_CKSUM_GOOD (0x0080) IP cksum of RX pkt. is valid
>  PKT_RX_L4_CKSUM_GOOD (0x0100) L4 cksum of RX pkt. is valid
>Packet Types
>  RTE_PTYPE_L2_ETHER (0x0001) Ethernet packet
>  RTE_PTYPE_L3_IPV4 (0x0010) IPv4 packet without extension headers
>  IP4: c0:56:27:11:f2:ac -> de:ad:00:00:00:05
>  UDP: 10.155.6.111 -> 10.155.3.201
>tos 0x00, ttl 64, length 820, checksum 0x843f
>fragment id 0xd06f offset 7400, flags
>  UDP: 23507 -> 4311
>length 43450, checksum 0x6383
> 00:19:41:823759: ethernet-input
>  IP4: c0:56:27:11:f2:ac -> de:ad:00:00:00:05
> 00:19:41:823760: l2-input
>  l2-input: sw_if_index 4 dst de:ad:00:00:00:05 src c0:56:27:11:f2:ac
> 00:19:41:823760: l2-learn
>  l2-learn: sw_if_index 4 dst de:ad:00:00:00:05 src c0:56:27:11:f2:ac bd_index 
> 5
> 00:19:41:823760: l2-fwd
>  l2-fwd:   sw_if_index 4 dst de:ad:00:00:00:05 src c0:56:27:11:f2:ac bd_index 
> 5
> 00:19:41:823761: ip4-input
>  UDP: 10.155.6.111 -> 10.155.3.201
>tos 0x00, ttl 64, length 820, checksum 0x843f
>fragment id 0xd06f offset 7400, flags
>  UDP: 23507 -> 4311
>length 43450, checksum 0x6383
> 00:19:41:823761: nat44-in2out
>  NAT44_IN2OUT_FAST_PATH: sw_if_index 19, next index 4, session -1
> 00:19:41:823761: nat44-in2out-reass
>  NAT44_REASS: sw_if_index 19, next index 1, status translated
> 00:19:41:823762: error-drop
>  nat44-in2out-reass: Drop fragment
> 
> Packet 50
> 
> 00:19:41:824581: dpdk-input
>  GigabitEthernet5/0/0 rx queue 0
>  buffer 0x1b3a8: current data 0, length 1514, free-list 0,
> clone-count 0, totlen-nifb 0, trace 0x31
>  ext-hdr-valid
>  l4-cksum-computed l4-cksum-correct l2-hdr-offset 0
>  PKT MBUF: port 3, nb_segs 1, pkt_len 1514
>buf_len 2176, data_len 1514, ol_flags 0x180, data_off 128,
> phys_addr 0xe86cea80
>packet_type 0x11 l2_len 0 l3_len 0 outer_l2_len 0 outer_l3_len 0
>rss 0x0 fdir.hi 0x0 fdir.lo 0x0
>Packet Offload Flags
>  PKT_RX_IP_CKSUM_GOOD (0x0080) IP cksum of RX pkt. is valid
>  PKT_RX_L4_CKSUM_GOOD (0x0100) L4 cksum of RX pkt. is valid
>Packet Types
>  RTE_PTYPE_L2_ETHER (0x0001) Ethernet packet
>  RTE_PTYPE_L3_IPV4 (0x0010) IPv4 packet without extension headers
>  IP4: c0:56:27:11:f2:ac -> de:ad:00:00:00:05
>  UDP: 10.155.6.111 -> 10.155.3.201
>tos 0x00, ttl 64, length 1500, checksum 0x8700
>fragment id 0xaea3, flags MORE_FRAGMENTS
>  UDP: 5201 -> 47346
>length 8200, checksum 0x5570
> 00:19:41:824582: ethernet-input
>  IP4: c0:56:27:11:f2:ac -> de:ad:00:00:00:05
> 00:19:41:824583: l2-input
>  l2-input: sw_if_index 4 dst de:ad:00:00:00:05 src c0:56:27:11:f2:ac
> 00:19:41:824583: l2-learn
>  l2-learn: sw_if_index 4 dst de:ad:00:00:00:05 src c0:56:27:11:f2:ac bd_index 
> 5
> 00:19:41:824584: l2-fwd
>  l2-fwd:   sw_if_index 4 dst de:ad:00:00:00:05 src c0:56:27:11:f2:ac bd_index 
> 5
> 00:19:41:824584: ip4-input
>  UDP: 10.155.6.111 -> 10.155.3.201
>tos 0x00, ttl 64, length 1500, checksum 0x8700
>fragment id 0xaea3, flags MORE_FRAGMENTS
>  UDP: 5201 -> 47346
>length 8200, checksum 0x5570
> 00:19:41:824584: nat44-in2out
>  NAT44_IN2OUT_FAST_PATH: sw_if_index 19, next index 4, session -1
> 00:19:41:824585: nat44-in2out-reass
>  NAT44_REASS: sw_if_index 19, next index 1, status translated
> 00:19:41:824585: error-drop
>  nat44-in2out-reass: Drop fragment
> 
> Thanks
> 
> On Sun, Mar 3, 2019 at 11:35 PM Ole Troan  wrote:
>> 
>> Hi Carlito,
>> 
>> Seems like you are sending IP fragments.
>> Those need to be (virtually) reassembled before NATted. Reassembly is to a 
>> large extent an attack vector, and it’s rate limited.
>> 
>> cheers,
>> Ole
>> 
>>> On 3 Mar 2019, at 22:46, carlito nueno  wrote:
>>> 
>>> Hi all,
>>> 
>>> While running more iperf3 udp tests, I noticed vpp status

Re: [vpp-dev] NAT: no free reassembly slot

2019-03-04 Thread carlito nueno

Hi Ole,

Got it.

Since I wanted to test both upstream and downstream with iperf3, I was
using -R option.
Even with disabling virtual-reassembly, packets are being dropped (see below).

Switching server to 10.155.6.x  and client on 10.155.3.x works.
So, for this kind of test, do you recommend switching client and
server subnets instead of running iperf3 with -R.

here are the dropped packets:

Packet 49

00:19:41:823757: dpdk-input
  GigabitEthernet5/0/0 rx queue 0
  buffer 0x2dd18: current data 0, length 834, free-list 0, clone-count
0, totlen-nifb 0, trace 0x30
  ext-hdr-valid
  l4-cksum-computed l4-cksum-correct l2-hdr-offset 0
  PKT MBUF: port 3, nb_segs 1, pkt_len 834
buf_len 2176, data_len 834, ol_flags 0x180, data_off 128,
phys_addr 0xe8b74680
packet_type 0x11 l2_len 0 l3_len 0 outer_l2_len 0 outer_l3_len 0
rss 0x0 fdir.hi 0x0 fdir.lo 0x0
Packet Offload Flags
  PKT_RX_IP_CKSUM_GOOD (0x0080) IP cksum of RX pkt. is valid
  PKT_RX_L4_CKSUM_GOOD (0x0100) L4 cksum of RX pkt. is valid
Packet Types
  RTE_PTYPE_L2_ETHER (0x0001) Ethernet packet
  RTE_PTYPE_L3_IPV4 (0x0010) IPv4 packet without extension headers
  IP4: c0:56:27:11:f2:ac -> de:ad:00:00:00:05
  UDP: 10.155.6.111 -> 10.155.3.201
tos 0x00, ttl 64, length 820, checksum 0x843f
fragment id 0xd06f offset 7400, flags
  UDP: 23507 -> 4311
length 43450, checksum 0x6383
00:19:41:823759: ethernet-input
  IP4: c0:56:27:11:f2:ac -> de:ad:00:00:00:05
00:19:41:823760: l2-input
  l2-input: sw_if_index 4 dst de:ad:00:00:00:05 src c0:56:27:11:f2:ac
00:19:41:823760: l2-learn
  l2-learn: sw_if_index 4 dst de:ad:00:00:00:05 src c0:56:27:11:f2:ac bd_index 5
00:19:41:823760: l2-fwd
  l2-fwd:   sw_if_index 4 dst de:ad:00:00:00:05 src c0:56:27:11:f2:ac bd_index 5
00:19:41:823761: ip4-input
  UDP: 10.155.6.111 -> 10.155.3.201
tos 0x00, ttl 64, length 820, checksum 0x843f
fragment id 0xd06f offset 7400, flags
  UDP: 23507 -> 4311
length 43450, checksum 0x6383
00:19:41:823761: nat44-in2out
  NAT44_IN2OUT_FAST_PATH: sw_if_index 19, next index 4, session -1
00:19:41:823761: nat44-in2out-reass
  NAT44_REASS: sw_if_index 19, next index 1, status translated
00:19:41:823762: error-drop
  nat44-in2out-reass: Drop fragment

Packet 50

00:19:41:824581: dpdk-input
  GigabitEthernet5/0/0 rx queue 0
  buffer 0x1b3a8: current data 0, length 1514, free-list 0,
clone-count 0, totlen-nifb 0, trace 0x31
  ext-hdr-valid
  l4-cksum-computed l4-cksum-correct l2-hdr-offset 0
  PKT MBUF: port 3, nb_segs 1, pkt_len 1514
buf_len 2176, data_len 1514, ol_flags 0x180, data_off 128,
phys_addr 0xe86cea80
packet_type 0x11 l2_len 0 l3_len 0 outer_l2_len 0 outer_l3_len 0
rss 0x0 fdir.hi 0x0 fdir.lo 0x0
Packet Offload Flags
  PKT_RX_IP_CKSUM_GOOD (0x0080) IP cksum of RX pkt. is valid
  PKT_RX_L4_CKSUM_GOOD (0x0100) L4 cksum of RX pkt. is valid
Packet Types
  RTE_PTYPE_L2_ETHER (0x0001) Ethernet packet
  RTE_PTYPE_L3_IPV4 (0x0010) IPv4 packet without extension headers
  IP4: c0:56:27:11:f2:ac -> de:ad:00:00:00:05
  UDP: 10.155.6.111 -> 10.155.3.201
tos 0x00, ttl 64, length 1500, checksum 0x8700
fragment id 0xaea3, flags MORE_FRAGMENTS
  UDP: 5201 -> 47346
length 8200, checksum 0x5570
00:19:41:824582: ethernet-input
  IP4: c0:56:27:11:f2:ac -> de:ad:00:00:00:05
00:19:41:824583: l2-input
  l2-input: sw_if_index 4 dst de:ad:00:00:00:05 src c0:56:27:11:f2:ac
00:19:41:824583: l2-learn
  l2-learn: sw_if_index 4 dst de:ad:00:00:00:05 src c0:56:27:11:f2:ac bd_index 5
00:19:41:824584: l2-fwd
  l2-fwd:   sw_if_index 4 dst de:ad:00:00:00:05 src c0:56:27:11:f2:ac bd_index 5
00:19:41:824584: ip4-input
  UDP: 10.155.6.111 -> 10.155.3.201
tos 0x00, ttl 64, length 1500, checksum 0x8700
fragment id 0xaea3, flags MORE_FRAGMENTS
  UDP: 5201 -> 47346
length 8200, checksum 0x5570
00:19:41:824584: nat44-in2out
  NAT44_IN2OUT_FAST_PATH: sw_if_index 19, next index 4, session -1
00:19:41:824585: nat44-in2out-reass
  NAT44_REASS: sw_if_index 19, next index 1, status translated
00:19:41:824585: error-drop
  nat44-in2out-reass: Drop fragment

Thanks

On Sun, Mar 3, 2019 at 11:35 PM Ole Troan  wrote:
>
> Hi Carlito,
>
> Seems like you are sending IP fragments.
> Those need to be (virtually) reassembled before NATted. Reassembly is to a 
> large extent an attack vector, and it’s rate limited.
>
> cheers,
> Ole
>
> > On 3 Mar 2019, at 22:46, carlito nueno  wrote:
> >
> > Hi all,
> >
> > While running more iperf3 udp tests, I noticed vpp status showing this:
> >
> > My current vpp conf:
> > https://gist.github.com/ironpillow/4b119b57e21b31a7ff6985bcb20f952b
> >
> > Setup to reproduce:
> > 1. iperf3 server on 10.155.3.2 (iperf3 -s -B 10.155.3.2)
> > 2. iperf3 client on 10.155.6.2 but with -R flag (iperf3 -B 10.155.6.2
> > -c 10.155.3.2 -u -b0 -R)
> >
> > So basically, server on one subnet and client on another subnet and
> > run it with -R flag
> >
> >

Re: [vpp-dev] Regarding node on a feature arc

2019-03-04 Thread Prashant Upadhyaya

Hi Neale,

In one of the usecases I deviated from the normal boilerplate and
started getting frames to target nodes with vlib_get_frame_to_node and
doing put's to those, the advantage was that I could iterate through
the entire input vector and queue up elements on frames of relevant
nodes and then finally do a put of those frames when I returned from
the node. It could be debated whether this should be done at all, but
then the strategy was dependent on the index of vlib_node_t of the
target node. Hence the question for the usecase when I don't have the
next node index in terms of the vlib_node_t's index of the target
node.

Regards
-Prashant




On Mon, Mar 4, 2019 at 9:31 PM Neale Ranns (nranns)  wrote:
>
>
> I'll bite __ why would you want to do that?
>
> /neale
>
> -Message d'origine-
> De :  au nom de Prashant Upadhyaya 
> 
> Date : lundi 4 mars 2019 à 16:06
> À : "Dave Barach (dbarach)" 
> Cc : "vpp-dev@lists.fd.io" 
> Objet : Re: [vpp-dev] Regarding node on a feature arc
>
> Thanks Dave, this is cool !
>
> Regards
> -Prashant
>
>
> On Mon, Mar 4, 2019 at 8:29 PM Dave Barach (dbarach)  
> wrote:
> >
> > You have: vlib_node_runtime_t *node. Use n = vlib_get_node(vm, 
> node->node_index) to recover the vlib_node_t.
> >
> > Index n->next_nodes to recover the node index corresponding to the next 
> index you have in mind: nNext = vlib_get_node (vm, n->next_nodes[i])
> >
> > HTH... Dave
> >
> > -Original Message-
> > From: vpp-dev@lists.fd.io  On Behalf Of Prashant 
> Upadhyaya
> > Sent: Monday, March 4, 2019 9:29 AM
> > To: vpp-dev@lists.fd.io
> > Subject: [vpp-dev] Regarding node on a feature arc
> >
> > Hi,
> >
> > When a node is on a feature arc, a good practice for that node is to 
> inspect the next feature with vnet_feature_next, obtain the next0 from that 
> and send the packets to the next0. All this works properly.
> >
> > My question -- how can I obtain the true vlib_node_t pointer 
> corresponding to the next0 as obtained from vnet_feature_next ?
> >
> > Regards
> > -Prashant
>
>
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#12418): https://lists.fd.io/g/vpp-dev/message/12418
Mute This Topic: https://lists.fd.io/mt/30213927/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 node on a feature arc

2019-03-04 Thread Neale Ranns via Lists.Fd.Io


I'll bite __ why would you want to do that? 

/neale

-Message d'origine-
De :  au nom de Prashant Upadhyaya 
Date : lundi 4 mars 2019 à 16:06
À : "Dave Barach (dbarach)" 
Cc : "vpp-dev@lists.fd.io" 
Objet : Re: [vpp-dev] Regarding node on a feature arc

Thanks Dave, this is cool !

Regards
-Prashant


On Mon, Mar 4, 2019 at 8:29 PM Dave Barach (dbarach)  
wrote:
>
> You have: vlib_node_runtime_t *node. Use n = vlib_get_node(vm, 
node->node_index) to recover the vlib_node_t.
>
> Index n->next_nodes to recover the node index corresponding to the next 
index you have in mind: nNext = vlib_get_node (vm, n->next_nodes[i])
>
> HTH... Dave
>
> -Original Message-
> From: vpp-dev@lists.fd.io  On Behalf Of Prashant 
Upadhyaya
> Sent: Monday, March 4, 2019 9:29 AM
> To: vpp-dev@lists.fd.io
> Subject: [vpp-dev] Regarding node on a feature arc
>
> Hi,
>
> When a node is on a feature arc, a good practice for that node is to 
inspect the next feature with vnet_feature_next, obtain the next0 from that and 
send the packets to the next0. All this works properly.
>
> My question -- how can I obtain the true vlib_node_t pointer 
corresponding to the next0 as obtained from vnet_feature_next ?
>
> Regards
> -Prashant


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

View/Reply Online (#12417): https://lists.fd.io/g/vpp-dev/message/12417
Mute This Topic: https://lists.fd.io/mt/30213927/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 node on a feature arc

2019-03-04 Thread Prashant Upadhyaya

Thanks Dave, this is cool !

Regards
-Prashant


On Mon, Mar 4, 2019 at 8:29 PM Dave Barach (dbarach)  wrote:
>
> You have: vlib_node_runtime_t *node. Use n = vlib_get_node(vm, 
> node->node_index) to recover the vlib_node_t.
>
> Index n->next_nodes to recover the node index corresponding to the next index 
> you have in mind: nNext = vlib_get_node (vm, n->next_nodes[i])
>
> HTH... Dave
>
> -Original Message-
> From: vpp-dev@lists.fd.io  On Behalf Of Prashant 
> Upadhyaya
> Sent: Monday, March 4, 2019 9:29 AM
> To: vpp-dev@lists.fd.io
> Subject: [vpp-dev] Regarding node on a feature arc
>
> Hi,
>
> When a node is on a feature arc, a good practice for that node is to inspect 
> the next feature with vnet_feature_next, obtain the next0 from that and send 
> the packets to the next0. All this works properly.
>
> My question -- how can I obtain the true vlib_node_t pointer corresponding to 
> the next0 as obtained from vnet_feature_next ?
>
> Regards
> -Prashant
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#12416): https://lists.fd.io/g/vpp-dev/message/12416
Mute This Topic: https://lists.fd.io/mt/30213927/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 node on a feature arc

2019-03-04 Thread Dave Barach via Lists.Fd.Io

You have: vlib_node_runtime_t *node. Use n = vlib_get_node(vm, 
node->node_index) to recover the vlib_node_t. 

Index n->next_nodes to recover the node index corresponding to the next index 
you have in mind: nNext = vlib_get_node (vm, n->next_nodes[i])  

HTH... Dave

-Original Message-
From: vpp-dev@lists.fd.io  On Behalf Of Prashant Upadhyaya
Sent: Monday, March 4, 2019 9:29 AM
To: vpp-dev@lists.fd.io
Subject: [vpp-dev] Regarding node on a feature arc

Hi,

When a node is on a feature arc, a good practice for that node is to inspect 
the next feature with vnet_feature_next, obtain the next0 from that and send 
the packets to the next0. All this works properly.

My question -- how can I obtain the true vlib_node_t pointer corresponding to 
the next0 as obtained from vnet_feature_next ?

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

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

[vpp-dev] Regarding node on a feature arc

2019-03-04 Thread Prashant Upadhyaya

Hi,

When a node is on a feature arc, a good practice for that node is to
inspect the next feature with vnet_feature_next, obtain the next0 from
that and send the packets to the next0. All this works properly.

My question -- how can I obtain the true vlib_node_t pointer
corresponding to the next0 as obtained from vnet_feature_next ?

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

View/Reply Online (#12414): https://lists.fd.io/g/vpp-dev/message/12414
Mute This Topic: https://lists.fd.io/mt/30213927/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] One question about vpp configuration file

Re: [vpp-dev] Question about the ipsec policy matching

Re: [vpp-dev] Build failure question

[vpp-dev] One question about vpp configuration file

[vpp-dev] Question about the ipsec policy matching

Re: [vpp-dev] Build failure question

Re: [vpp-dev] Build failure question

[vpp-dev] Build failure question

Re: [vpp-dev] Regarding node on a feature arc

Re: [vpp-dev] NAT: no free reassembly slot

Re: [vpp-dev] NAT: no free reassembly slot

Re: [vpp-dev] NAT: no free reassembly slot

Re: [vpp-dev] Regarding node on a feature arc

Re: [vpp-dev] Regarding node on a feature arc

Re: [vpp-dev] Regarding node on a feature arc

Re: [vpp-dev] Regarding node on a feature arc

[vpp-dev] Regarding node on a feature arc

17 matches

Site Navigation

Mail list logo

Footer information