Re: [vpp-dev] QinQ and dot1ad any

[Raj]

Thanks a lot for the clarification!

Raj

On Tue, Dec 17, 2019 at 7:43 PM John Lo (loj)  wrote:
>
> Hi Raj,
>
> A sub-interface with "dot1q inner any" can only work with L2 forwarding via 
> cross-connect or bridging where packets are forwarded using MAC header 
> without any changes to MAC header nor VLAN IDs in VLAN tags.
>
> For L3 IP forwarding, any VLAN tags on a packet must be exact match to a 
> sub-interface which means both outer and inner VLAN tag IDs must be 
> exact-matched to specific values defined of that sub-interface.  Without 
> exact match on a L3 sub-interface, VPP has no mechanism to know what VLAN 
> tags to use for packet output, such as ARP request packets or IP packets, on 
> that sub-interface. Thus, sub-interface with "inner-dot1q any" is not an 
> exact match sub-interface by definition since no match is present on inner 
> tag.
>
> I suppose the CLI:
> >> create sub-interfaces GigabitEthernet3/0/3 50 dot1ad 50 inner-dot1q any 
> >> exact-match
> should have been rejected as exact match cannot be supported on the 
> sub-interface.  This is something we should ideally fix in the CLI to avoid 
> any confusion with the meaning of exact match.
>
> Regards,
> John
>
> -Original Message-
> From: vpp-dev@lists.fd.io  On Behalf Of Raj
> Sent: Tuesday, December 17, 2019 4:39 AM
> To: vpp-dev 
> Subject: [vpp-dev] QinQ and dot1ad any
>
> Hello all,
>
> When an interface is created using a command like:
>
> create sub-interfaces GigabitEthernet3/0/3 50 dot1ad 50 inner-dot1q any 
> exact-match
>
> I can see that dual tagged packets with outer vlan 50 will be accepted by 
> that interface.
>
> But how does a packet goes out from this interface? Is there a means by which 
> I can say that a given IP is with a specific S_VLAN:C_VLAN?
>
> During testing VPP could receive an ARP packet, but when it sends it out, 
> entire Ethernet header was missing. I guess there must be some means to add 
> adjacency information so that correct headers can be added.
>
> The trace is as follows:
>
>
> 00:01:04:749110: dpdk-input
>   GigabitEthernet3/0/3 rx queue 0
>   buffer 0x4c7d: current data 0, length 60, free-list 0, clone-count 0, 
> totlen-nifb 0, trace 0x1
>  ext-hdr-valid
>  l4-cksum-computed l4-cksum-correct
>   PKT MBUF: port 0, nb_segs 1, pkt_len 60
> buf_len 2176, data_len 60, ol_flags 0x180, data_off 128, phys_addr
> 0x26b31fc0
> packet_type 0x0 l2_len 0 l3_len 0 outer_l2_len 0 outer_l3_len 0
> rss 0x0 fdir.hi 0x0 fdir.lo 0x0
> 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
>   ARP: 40:7b:1b:00:11:aa -> ff:ff:ff:ff:ff:ff 802.1ad vlan 50 802.1ad vlan 51
>   request, type ethernet/IP4, address size 6/4
>   40:7b:1b:00:11:aa/192.168.25.1 -> 00:00:00:00:00:00/192.168.25.2
> 00:01:04:749112: ethernet-input
>   frame: flags 0x3, hw-if-index 1, sw-if-index 1
>   ARP: 40:7b:1b:00:11:aa -> ff:ff:ff:ff:ff:ff 802.1ad vlan 50 802.1ad vlan 51
> 00:01:04:749113: arp-input
>   request, type ethernet/IP4, address size 6/4
>   40:7b:1b:00:11:aa/192.168.25.1 -> 00:00:00:00:00:00/192.168.25.2
> 00:01:04:749116: GigabitEthernet3/0/3-output
>   GigabitEthernet3/0/3.50
>   0x1235: 00:02:40:7b:1b:00 -> 00:01:08:00:06:04
> 00:01:04:749116: GigabitEthernet3/0/3-tx
>   GigabitEthernet3/0/3 tx queue 0
>   buffer 0x4c7d: current data 22, length 38, free-list 0, clone-count 0, 
> totlen-nifb 0, trace 0x1
>  ext-hdr-valid
>  l4-cksum-computed l4-cksum-correct vlan-2-deep l2-hdr-offset 
> 0 l3-hdr-offset 22
>   PKT MBUF: port 0, nb_segs 1, pkt_len 38
> buf_len 2176, data_len 38, ol_flags 0x180, data_off 150, phys_addr
> 0x26b31fc0
> packet_type 0x0 l2_len 0 l3_len 0 outer_l2_len 0 outer_l3_len 0
> rss 0x0 fdir.hi 0x0 fdir.lo 0x0
> 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
>   0x1235: 00:02:40:7b:1b:00 -> 00:01:08:00:06:04
>
> btw, if inner VLAN is specified, everything works fine.
>
>
> Thanks and Regards,
>
> Raj
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#14917): https://lists.fd.io/g/vpp-dev/message/14917
Mute This Topic: https://lists.fd.io/mt/68757125/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] merge jobs failing..

[Paul Vinciguerra]

Fixed: https://gerrit.fd.io/r/c/vpp/+/24041

On Tue, Dec 17, 2019 at 7:00 PM Ed Kern via Lists.Fd.Io  wrote:

>
> Hey benoit,
>
> Happened to notice (because I was watching the queue anyway since santa
> damjan did a bunch of merges) that ubuntu test/merges started failing
> after
> https://gerrit.fd.io/r/c/vpp/+/23913
>
> No its not clear to me why it verified…
> it looks like a simple typo where you meant to do
> from scapy.contrib.geneve import GENEVE
> but did
> from scapy.layers.geneve import GENEVE
>
> in test/test_trace_filter.py
>
> anyway..all ubuntu merge jobs are failing after that point so if this ISNT
> the error feel
> free to flame me and/or the real root cause.
>
> Ed
> -=-=-=-=-=-=-=-=-=-=-=-
> Links: You receive all messages sent to this group.
>
> View/Reply Online (#14915): https://lists.fd.io/g/vpp-dev/message/14915
> Mute This Topic: https://lists.fd.io/mt/68776336/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 (#14916): https://lists.fd.io/g/vpp-dev/message/14916
Mute This Topic: https://lists.fd.io/mt/68776336/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[vpp-dev] merge jobs failing..

[Ed Kern via Lists.Fd.Io]

Hey benoit,

Happened to notice (because I was watching the queue anyway since santa damjan 
did a bunch of merges) that ubuntu test/merges started failing
after
https://gerrit.fd.io/r/c/vpp/+/23913

No its not clear to me why it verified…
it looks like a simple typo where you meant to do
from scapy.contrib.geneve import GENEVE
but did
from scapy.layers.geneve import GENEVE

in test/test_trace_filter.py

anyway..all ubuntu merge jobs are failing after that point so if this ISNT the 
error feel
free to flame me and/or the real root cause.

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

View/Reply Online (#14915): https://lists.fd.io/g/vpp-dev/message/14915
Mute This Topic: https://lists.fd.io/mt/68776336/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] QinQ and dot1ad any

[John Lo (loj) via Lists.Fd.Io]

Hi Raj,

A sub-interface with "dot1q inner any" can only work with L2 forwarding via 
cross-connect or bridging where packets are forwarded using MAC header without 
any changes to MAC header nor VLAN IDs in VLAN tags.

For L3 IP forwarding, any VLAN tags on a packet must be exact match to a 
sub-interface which means both outer and inner VLAN tag IDs must be 
exact-matched to specific values defined of that sub-interface.  Without exact 
match on a L3 sub-interface, VPP has no mechanism to know what VLAN tags to use 
for packet output, such as ARP request packets or IP packets, on that 
sub-interface. Thus, sub-interface with "inner-dot1q any" is not an exact match 
sub-interface by definition since no match is present on inner tag.

I suppose the CLI:
>> create sub-interfaces GigabitEthernet3/0/3 50 dot1ad 50 inner-dot1q any 
>> exact-match
should have been rejected as exact match cannot be supported on the 
sub-interface.  This is something we should ideally fix in the CLI to avoid any 
confusion with the meaning of exact match.

Regards,
John

-Original Message-
From: vpp-dev@lists.fd.io  On Behalf Of Raj
Sent: Tuesday, December 17, 2019 4:39 AM
To: vpp-dev 
Subject: [vpp-dev] QinQ and dot1ad any

Hello all,

When an interface is created using a command like:

create sub-interfaces GigabitEthernet3/0/3 50 dot1ad 50 inner-dot1q any 
exact-match

I can see that dual tagged packets with outer vlan 50 will be accepted by that 
interface.

But how does a packet goes out from this interface? Is there a means by which I 
can say that a given IP is with a specific S_VLAN:C_VLAN?

During testing VPP could receive an ARP packet, but when it sends it out, 
entire Ethernet header was missing. I guess there must be some means to add 
adjacency information so that correct headers can be added.

The trace is as follows:


00:01:04:749110: dpdk-input
  GigabitEthernet3/0/3 rx queue 0
  buffer 0x4c7d: current data 0, length 60, free-list 0, clone-count 0, 
totlen-nifb 0, trace 0x1
 ext-hdr-valid
 l4-cksum-computed l4-cksum-correct
  PKT MBUF: port 0, nb_segs 1, pkt_len 60
buf_len 2176, data_len 60, ol_flags 0x180, data_off 128, phys_addr
0x26b31fc0
packet_type 0x0 l2_len 0 l3_len 0 outer_l2_len 0 outer_l3_len 0
rss 0x0 fdir.hi 0x0 fdir.lo 0x0
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
  ARP: 40:7b:1b:00:11:aa -> ff:ff:ff:ff:ff:ff 802.1ad vlan 50 802.1ad vlan 51
  request, type ethernet/IP4, address size 6/4
  40:7b:1b:00:11:aa/192.168.25.1 -> 00:00:00:00:00:00/192.168.25.2
00:01:04:749112: ethernet-input
  frame: flags 0x3, hw-if-index 1, sw-if-index 1
  ARP: 40:7b:1b:00:11:aa -> ff:ff:ff:ff:ff:ff 802.1ad vlan 50 802.1ad vlan 51
00:01:04:749113: arp-input
  request, type ethernet/IP4, address size 6/4
  40:7b:1b:00:11:aa/192.168.25.1 -> 00:00:00:00:00:00/192.168.25.2
00:01:04:749116: GigabitEthernet3/0/3-output
  GigabitEthernet3/0/3.50
  0x1235: 00:02:40:7b:1b:00 -> 00:01:08:00:06:04
00:01:04:749116: GigabitEthernet3/0/3-tx
  GigabitEthernet3/0/3 tx queue 0
  buffer 0x4c7d: current data 22, length 38, free-list 0, clone-count 0, 
totlen-nifb 0, trace 0x1
 ext-hdr-valid
 l4-cksum-computed l4-cksum-correct vlan-2-deep l2-hdr-offset 0 
l3-hdr-offset 22
  PKT MBUF: port 0, nb_segs 1, pkt_len 38
buf_len 2176, data_len 38, ol_flags 0x180, data_off 150, phys_addr
0x26b31fc0
packet_type 0x0 l2_len 0 l3_len 0 outer_l2_len 0 outer_l3_len 0
rss 0x0 fdir.hi 0x0 fdir.lo 0x0
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
  0x1235: 00:02:40:7b:1b:00 -> 00:01:08:00:06:04

btw, if inner VLAN is specified, everything works fine.


Thanks and Regards,

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

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

[vpp-dev] Coverity run FAILED as of 2019-12-17 14:04:31 UTC

[Noreply Jenkins]

Coverity run failed today.

Current number of outstanding issues are 2
Newly detected: 0
Eliminated: 0
More details can be found at  
https://scan.coverity.com/projects/fd-io-vpp/view_defects
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

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

[vpp-dev] QinQ and dot1ad any

[Raj]

Hello all,

When an interface is created using a command like:

create sub-interfaces GigabitEthernet3/0/3 50 dot1ad 50 inner-dot1q
any exact-match

I can see that dual tagged packets with outer vlan 50 will be accepted
by that interface.

But how does a packet goes out from this interface? Is there a means
by which I can say that a given IP is with a specific S_VLAN:C_VLAN?

During testing VPP could receive an ARP packet, but when it sends it
out, entire Ethernet header was missing. I guess there must be some
means to add adjacency information so that correct headers can be
added.

The trace is as follows:


00:01:04:749110: dpdk-input
  GigabitEthernet3/0/3 rx queue 0
  buffer 0x4c7d: current data 0, length 60, free-list 0, clone-count
0, totlen-nifb 0, trace 0x1
 ext-hdr-valid
 l4-cksum-computed l4-cksum-correct
  PKT MBUF: port 0, nb_segs 1, pkt_len 60
buf_len 2176, data_len 60, ol_flags 0x180, data_off 128, phys_addr
0x26b31fc0
packet_type 0x0 l2_len 0 l3_len 0 outer_l2_len 0 outer_l3_len 0
rss 0x0 fdir.hi 0x0 fdir.lo 0x0
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
  ARP: 40:7b:1b:00:11:aa -> ff:ff:ff:ff:ff:ff 802.1ad vlan 50 802.1ad vlan 51
  request, type ethernet/IP4, address size 6/4
  40:7b:1b:00:11:aa/192.168.25.1 -> 00:00:00:00:00:00/192.168.25.2
00:01:04:749112: ethernet-input
  frame: flags 0x3, hw-if-index 1, sw-if-index 1
  ARP: 40:7b:1b:00:11:aa -> ff:ff:ff:ff:ff:ff 802.1ad vlan 50 802.1ad vlan 51
00:01:04:749113: arp-input
  request, type ethernet/IP4, address size 6/4
  40:7b:1b:00:11:aa/192.168.25.1 -> 00:00:00:00:00:00/192.168.25.2
00:01:04:749116: GigabitEthernet3/0/3-output
  GigabitEthernet3/0/3.50
  0x1235: 00:02:40:7b:1b:00 -> 00:01:08:00:06:04
00:01:04:749116: GigabitEthernet3/0/3-tx
  GigabitEthernet3/0/3 tx queue 0
  buffer 0x4c7d: current data 22, length 38, free-list 0, clone-count
0, totlen-nifb 0, trace 0x1
 ext-hdr-valid
 l4-cksum-computed l4-cksum-correct vlan-2-deep
l2-hdr-offset 0 l3-hdr-offset 22
  PKT MBUF: port 0, nb_segs 1, pkt_len 38
buf_len 2176, data_len 38, ol_flags 0x180, data_off 150, phys_addr
0x26b31fc0
packet_type 0x0 l2_len 0 l3_len 0 outer_l2_len 0 outer_l3_len 0
rss 0x0 fdir.hi 0x0 fdir.lo 0x0
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
  0x1235: 00:02:40:7b:1b:00 -> 00:01:08:00:06:04

btw, if inner VLAN is specified, everything works fine.


Thanks and Regards,

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

View/Reply Online (#14912): https://lists.fd.io/g/vpp-dev/message/14912
Mute This Topic: https://lists.fd.io/mt/68757125/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 VSZ shoots to 200GB because of DPDK plugin

[Benoit Ganne (bganne) via Lists.Fd.Io]

Hi Siddarth,

> The issue here is that huge core files are generated, which take up a lot
> of space and the system down time is huge too.
> Even if I compress it, I will have to de-compress wherever I try to debug
> it and the disk space requirement will be huge.

I know this will not fix your issue, however that might help:
 - when the core file is generated, if the VA is not in use it should not take 
space on the disk because it should be stored as a sparse file. Here is an 
example I have locally (note the 117M allocated on disk vs the 2.6G "virtual" 
size):
bganne@ubuntu1804:~$ ls -lsh core
117M -rw-rw-r-- 1 bganne bganne 2.6G Nov 12 15:34 core
Also, if you do not compress it at generation time (via 
/proc/sys/kernel/core_pattern or similar) it should not impact the downtime as 
it is simply not written nor processed
 - if you compress/decompress it with gzip, it will not produce a sparse file 
but you can 're-sparse' it using eg. dd:
bganne@ubuntu1804:~$ zcat core.gz | dd conv=sparse of=core

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

View/Reply Online (#14911): https://lists.fd.io/g/vpp-dev/message/14911
Mute This Topic: https://lists.fd.io/mt/68143971/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] Change in vpp[master]: ebuild: Cross compilation aarch64 Ubuntu support

[Juraj Linkeš]

I tried a more basic thing in my previous patch: 
https://gerrit.fd.io/r/c/vpp/+/21035

The patch has one file with all cross-compile arguments/parameters: 
build-data/platforms/aarch64-generic.mk.

It also modifies the ebuild system to propagate those into both VPP and 
external (dpdk, rdma and such) builds. If we don't want to modify the the 
ebuild system in this way, I can create separate make targets like Damjan did 
here: https://gerrit.fd.io/r/c/vpp/+/23153

If anyone's interested in trying it out, there's a script that builds aarch64 
dpdk and other external libs along with VPP libraries: 
build-root/scripts/aarch64-crossbuild.sh. The binaries should be in the same 
repository.

What do you think about this approach? That is, splitting the cross compilation 
from the environment setup. It seems like a good first step if we're not going 
to do the emulation builds (see my previous e-mail for reasons why I think it's 
inadequate).

Thanks,
Juraj

From: Juraj Linkeš 
Sent: Wednesday, December 4, 2019 3:36 PM
To: dmar...@me.com; Benoit Ganne (bganne) 
Cc: vpp-dev@lists.fd.io
Subject: Re: [vpp-dev] Change in vpp[master]: ebuild: Cross compilation aarch64 
Ubuntu support

I looked into this and there are some problems.

The first problem is the inability to fine tune any parameters we might want to 
for target cpu/microarchitecture (for arm, that would be building packages with 
specifics for ThunderX, McBin, Raspberry PI etc.). I'm not sure how Qemu does 
the emulation, but I doubt there's extensive support for a myriad of cpus. And 
on top of that, it's slow.

The other thing is with using the x86 version of aarch64-linux-gnu-gcc. In that 
case it's just regular cross-compilation (x86 version of aarch64-linux-gnu-gcc 
is the cross-compiler) and what we gain from these target platform containers 
is having the proper libraries that VPP build depends on. For Ubuntu I've found 
that it's actually not worth it - it's easier to have an x86 container and 
install arm dependency packages that to install x86 cross compiler inside an 
aarch64 container. Another thing I've observed (in htop) is that even when 
using the x86 version of aarch64-linux-gnu-gcc inside the aarch64 container, it 
was still going through the emulator, but maybe I did something wrong.

Damjan, you mentioned that my current patch doesn't solve anything. It 
certainly isn't a comprehensive solution, but it does one thing and that is it 
allows users to specify platform specific config args (well, at least some of 
the supported ones in build-data/platforms/.mk) which then get 
propagated to all parts of the build and it's possible to do cross compilation 
given that the environemnt has been already set up. It modifies the current 
ebuild system, but that might not be the appropriate place to do that. However, 
I don't how else would we do this.

I'm not sure what all of this means, but the docker solution is certainly 
incomplete, if not outright unsuitable. Maybe we could use containers for just 
environment setup (e.g. for Ubuntu, installing both host and target packages) 
and then could run cross-compilation in them with a solution that would do 
something like my patch (i.e. cross-compile DPDK and VPP with config args 
defined in one file).

Thoughts?
Juraj

From: Damjan Marion via Lists.Fd.Io 
mailto:dmarion=me@lists.fd.io>>
Sent: Thursday, October 31, 2019 1:49 PM
To: Benoit Ganne (bganne) mailto:bga...@cisco.com>>
Cc: vpp-dev@lists.fd.io
Subject: Re: [vpp-dev] Change in vpp[master]: ebuild: Cross compilation aarch64 
Ubuntu support



> On 31 Oct 2019, at 13:18, Benoit Ganne (bganne) 
> mailto:bga...@cisco.com>> wrote:
>
>> I was going to remain silent, but since there's now multiple people saying
>> this sounds good -- I think this sounds horrible. :)
>> To wit, it seems too complex and too much setup/overhead. I'll try and
>> look closer at this soon to see if I can feed back our local changes that
>> seem to be working.
>
> It is not that bad in my opinion [1] :
> 1) add support for multiarch (must be done once after reboot)
> ~# docker run --rm --privileged multiarch/qemu-user-static --reset 
> --persistent yes --credential yes
> 2) create your chroot (must be done once - I am sharing my homedir with my 
> chroot and same UID/GID)
> ~# docker run --name aarch64_u1804 --privileged --net host -v $HOME:$HOME -v 
> /dev:/dev -v/lib/modules:/lib/modules/host:ro -td arm64v8/ubuntu:18.04 
> /bin/bash
> ~# docker container exec aarch64_u1804 sh -c "apt -qy update && apt 
> dist-upgrade -qy && apt install -qy vim sudo make git && groupadd -g $(id 
> -rg) $USER && useradd -u $(id -ru) -g $(id -rg) -M -d $HOME -s /bin/bash 
> $USER && echo '$USER ALL=(ALL) NOPASSWD:ALL' >> /etc/sudoers && echo 
> aarch64_u1804 > /etc/debian_chroot"
> 3) compile vpp (I already checked out VPP in $HOME/src/vpp but you can 
> checkout it there too if you prefer)
> ~# docker container exec aarch64_u1804 su "$USER" -l -c 

Re: [vpp-dev] Doubts about NAT #nat44 #nat

[baixiaopeng]

Hi, Thank you for your help!
I'm using the latest release for my testing.
1)The output of `show version` command as follow:
vpp# show version
vpp v20.01-rc0~694-g11e9e35 built by root on kean at Fri Nov 22 16:12:07 HKT 
2019
2)The configurations of NAT testing as follows:
ip netns add ns1
ip link add vpp1 type veth peer name vethns1
ip link set vethns1 netns ns1
ip netns exec ns1 ip link set lo up
ip netns exec ns1 ip link set vethns1 up
ip netns exec ns1 ip addr add 10.10.0.2/24 dev vethns1
ip netns exec ns1 ethtool -K vethns1 rx off tx off
ip link set vpp1 up

ip netns add ns2
ip link add vpp2 type veth peer name vethns2
ip link set vethns2 netns ns2
ip netns exec ns2 ip link set lo up
ip netns exec ns2 ip link set vethns2 up
ip netns exec ns2 ip addr add 10.10.1.1/24 dev vethns2
ip netns exec ns2 ethtool -K vethns2 rx off tx off
ip link set vpp2 up

ip netns exec ns0 ip route add default via 10.10.0.10
ip netns exec ns1 ip route add default via 10.10.0.10
ip netns exec ns2 ip route add default via 10.10.1.10

create host-interface name vpp0
create host-interface name vpp1
create host-interface name vpp2
set interface state host-vpp0 up
set interface state host-vpp1 up
set interface state host-vpp2 up

set interface l2 bridge host-vpp0 3
set interface l2 bridge host-vpp1 3
set interface ip address host-vpp2 10.10.1.10/24
create loopback interface
set interface l2 bridge loop0 3 bvi
set interface state loop0 up
set interface ip address loop0 10.10.0.10/24

nat44 add interface address host-vpp2
set interface nat44 in loop0 out host-vpp2

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

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

Re: [vpp-dev] Doubts about NAT #nat44 #nat

[Filip Varga via Lists.Fd.Io]

Hi,

Could you please send me output of `show version` command and your NAT 
configuration. There is a use case when this behavior is expected.

Best regards,
Filip

[https://www.cisco.com/c/dam/m/en_us/signaturetool/images/logo/Cisco_Logo_no_TM_Cisco_Blue-RGB_43px.png]
Filip Varga
Engineer - Software
fiva...@cisco.com
Tel:




Cisco Systems, Inc.



Slovakia
cisco.com
[http://www.cisco.com/assets/swa/img/thinkbeforeyouprint.gif]
Think before you print.
This email may contain confidential and privileged material for the sole use of 
the intended recipient. Any review, use, distribution or disclosure by others 
is strictly prohibited. If you are not the intended recipient (or authorized to 
receive for the recipient), please contact the sender by reply email and delete 
all copies of this message.
Please click 
here
 for Company Registration Information.


From: vpp-dev@lists.fd.io  On Behalf Of 
baixiaop...@ekean.cn
Sent: Tuesday, December 17, 2019 8:25 AM
To: vpp-dev@lists.fd.io
Subject: [vpp-dev] Doubts about NAT #nat44 #nat

I'm testing the NAT feature, and after configuring the NAT, the trace 
information is as follows below，
Why is the nat44-in2out-worker-handoff node followed by the nat44-out2in node 
instead of the nat44-in2out node?

P.S: trace information
Packet 1

02:23:07:173961: af-packet-input
  af_packet: hw_if_index 7 next-index 4
tpacket2_hdr:
  status 0x2001 len 98 snaplen 98 mac 66 net 80
  sec 0x5df85360 nsec 0x2e9e94c8 vlan 0 vlan_tpid 0
02:23:07:173970: ethernet-input
  IP4: 42:64:0a:23:df:a3 -> de:ad:00:00:00:00
02:23:07:173975: l2-input
  l2-input: sw_if_index 7 dst de:ad:00:00:00:00 src 42:64:0a:23:df:a3
02:23:07:173979: l2-learn
  l2-learn: sw_if_index 7 dst de:ad:00:00:00:00 src 42:64:0a:23:df:a3 bd_index 3
02:23:07:173983: l2-fwd
  l2-fwd:   sw_if_index 7 dst de:ad:00:00:00:00 src 42:64:0a:23:df:a3 bd_index 
3result [0x7000a, 10] static age-not bvi
02:23:07:173987: ip4-input
  ICMP: 10.10.0.1 -> 10.10.1.1
tos 0x00, ttl 64, length 84, checksum 0xcdaa
fragment id 0x57e9, flags DONT_FRAGMENT
  ICMP echo_request checksum 0x5686
02:23:07:173991: nat44-in2out-worker-handoff
  NAT44_IN2OUT_WORKER_HANDOFF : next-worker 1 trace index 0
02:23:07:173999: nat44-out2in
  NAT44_OUT2IN: sw_if_index 10, next index 0, session index -1
02:23:07:174005: error-drop
  rx:loop0
02:23:07:174008: drop
  nat44-out2in: no translation


Best Regards!!!

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

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