Re: [vpp-dev] VPP 19.04 centos7 RPM package dependency errors

[Thomas F Herbert]

On 04/11/2019 06:48 PM, Paul Vinciguerra wrote:
I looked at this a while back. The spec file doesn’t pick up the 
packages from the makefile.  I can look at it in a few hours if you 
like. Let me know.
I had intended to import the new packages from epel into Centos. Epel 
dependency causes problems for downstream packaging.
Since this is a slow process,  I can submit a patch to vpp to add the 
epel dependencies to the spec file since I won't  be able to get rid of 
the epel dependency before the 19.04 release.


On Apr 11, 2019, at 6:25 PM, Thomas F Herbert > wrote:



Dave and Ed,

The Makefile has dependencies that work. However, you will need epel. 
The packages required are:


yum install epel-release

yum install mbedtls

yum install python36

--Tom


On 04/11/2019 05:11 PM, Florin Coras wrote:
We do have it as a dependency because we want to make sure the 
plugin still builds. However, given that most of those who use tls 
use the openssl engine, we might consider not having mbedtls as a 
dependency for the packages that we push to packagecloud ...


On a separate note, what centos do we run in the container? It seems 
that even python3 has some dependency errors. I guess that once we 
align the vagrant version with it, things should just work.
Probably the vagrant image doesn't have some of these packages that are 
only in epel.


Florin

On Apr 11, 2019, at 1:55 PM, Ed Kern (ejk) > wrote:




On Apr 11, 2019, at 2:22 PM, Florin Coras > wrote:


Are we building rpms on a host that has mbedtls installed?


Yes the centos container has mbedtls installed….has for quite some 
time since it is a listed

prerequisite straight out of the Makefile.

Ed




Just uninstalling it should disable the tlsmbedtls plugin, which 
is what we pretty much want.


Florin

On Apr 11, 2019, at 1:00 PM, Dave Wallace > wrote:


Tom/Billy,

Do you know what the current status is with the VPP rpm's on 
master/19.04?


I'm trying to install the VPP 19.04 packages frompackagecloud.io 
on a centos7 Vagrant/virtualbox VM 
(using .../vpp/extras/vagrant/Vagrantfile) to verify that the 
packages are correct.  The 19.01 packages install fine, but the 
19.04 and master packages fail with the following dependency errors:


--> Finished Dependency Resolution
Error: Package: vpp-plugins-19.04-rc1~b4.x86_64 (fdio_1904)
   Requires: libmbedtls.so.10()(64bit)
Error: Package: vpp-devel-19.04-rc1~b4.x86_64 (fdio_1904)
   Requires: /usr/bin/python3
Error: Package: vpp-19.04-rc1~b4.x86_64 (fdio_1904)
   Requires: /usr/bin/python3
Error: Package: vpp-plugins-19.04-rc1~b4.x86_64 (fdio_1904)
   Requires: libmbedx509.so.0()(64bit)
Error: Package: vpp-plugins-19.04-rc1~b4.x86_64 (fdio_1904)
   Requires: libmbedcrypto.so.2()(64bit)
 You could try using --skip-broken to work around the problem
 You could try running: rpm -Va --nofiles --nodigest

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

View/Reply Online 
(#12768):https://lists.fd.io/g/vpp-dev/message/12768

Mute This Topic:https://lists.fd.io/mt/31034762/675152
Group Owner:vpp-dev+ow...@lists.fd.io 

Unsubscribe:https://lists.fd.io/g/vpp-dev/unsub [fcoras.li...@gmail.com 
]

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


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

View/Reply Online (#12769):https://lists.fd.io/g/vpp-dev/message/12769
Mute This Topic:https://lists.fd.io/mt/31034762/675649
Group Owner:vpp-dev+ow...@lists.fd.io 

Unsubscribe:https://lists.fd.io/g/vpp-dev/unsub [e...@cisco.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 (#12773): https://lists.fd.io/g/vpp-dev/message/12773
Mute This Topic: https://lists.fd.io/mt/31034762/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 (#12775): https://lists.fd.io/g/vpp-dev/message/12775
Mute This Topic: https://lists.fd.io/mt/31034762/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 19.04 centos7 RPM package dependency errors

[Paul Vinciguerra]

I looked at this a while back. The spec file doesn’t pick up the packages from 
the makefile.  I can look at it in a few hours if you like. Let me know. 

> On Apr 11, 2019, at 6:25 PM, Thomas F Herbert  wrote:
> 
> Dave and Ed,
> 
> The Makefile has dependencies that work. However, you will need epel. The 
> packages required are:
> 
> yum install epel-release
> 
> yum install mbedtls
> 
> yum install python36
> 
> --Tom
> 
> 
>> On 04/11/2019 05:11 PM, Florin Coras wrote:
>> We do have it as a dependency because we want to make sure the plugin still 
>> builds. However, given that most of those who use tls use the openssl 
>> engine, we might consider not having mbedtls as a dependency for the 
>> packages that we push to packagecloud ...
>> 
>> On a separate note, what centos do we run in the container? It seems that 
>> even python3 has some dependency errors. I guess that once we align the 
>> vagrant version with it, things should just work.
>> 
>> Florin
>> 
>>> On Apr 11, 2019, at 1:55 PM, Ed Kern (ejk)  wrote:
>>> 
>>> 
>>> 
 On Apr 11, 2019, at 2:22 PM, Florin Coras  wrote:
 
 Are we building rpms on a host that has mbedtls installed? 
>>> 
>>> Yes the centos container has mbedtls installed….has for quite some time 
>>> since it is a listed
>>> prerequisite straight out of the Makefile.
>>> 
>>> Ed
>>> 
>>> 
>>> 
>>> 
 Just uninstalling it should disable the tlsmbedtls plugin, which is what 
 we pretty much want. 
 
 Florin 
 
> On Apr 11, 2019, at 1:00 PM, Dave Wallace  wrote:
> 
> Tom/Billy,
> 
> Do you know what the current status is with the VPP rpm's on master/19.04?
> 
> I'm trying to install the VPP 19.04 packages from packagecloud.io on a 
> centos7 Vagrant/virtualbox VM (using .../vpp/extras/vagrant/Vagrantfile) 
> to verify that the packages are correct.  The 19.01 packages install 
> fine, but the 19.04 and master packages fail with the following 
> dependency errors:
> 
> --> Finished Dependency Resolution
> Error: Package: vpp-plugins-19.04-rc1~b4.x86_64   
>   (fdio_1904)
>Requires: libmbedtls.so.10()(64bit)
> Error: Package: vpp-devel-19.04-rc1~b4.x86_64 (fdio_1904)
>Requires: /usr/bin/python3
> Error: Package: vpp-19.04-rc1~b4.x86_64 (fdio_1904)
>Requires: /usr/bin/python3
> Error: Package: vpp-plugins-19.04-rc1~b4.x86_64   
>   (fdio_1904)
>Requires: libmbedx509.so.0()(64bit)
> Error: Package: vpp-plugins-19.04-rc1~b4.x86_64   
>   (fdio_1904)
>Requires: libmbedcrypto.so.2()(64bit)
>  You could try using --skip-broken to work around the problem
>  You could try running: rpm -Va --nofiles --nodigest
> 
> Thanks,
> -daw-
> -=-=-=-=-=-=-=-=-=-=-=-
> Links: You receive all messages sent to this group.
> 
> View/Reply Online (#12768): https://lists.fd.io/g/vpp-dev/message/12768
> Mute This Topic: https://lists.fd.io/mt/31034762/675152
> Group Owner: vpp-dev+ow...@lists.fd.io
> Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub  [fcoras.li...@gmail.com]
> -=-=-=-=-=-=-=-=-=-=-=-
 
 -=-=-=-=-=-=-=-=-=-=-=-
 Links: You receive all messages sent to this group.
 
 View/Reply Online (#12769): https://lists.fd.io/g/vpp-dev/message/12769
 Mute This Topic: https://lists.fd.io/mt/31034762/675649
 Group Owner: vpp-dev+ow...@lists.fd.io
 Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub  [e...@cisco.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 (#12773): https://lists.fd.io/g/vpp-dev/message/12773
> Mute This Topic: https://lists.fd.io/mt/31034762/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 (#12774): https://lists.fd.io/g/vpp-dev/message/12774
Mute This Topic: https://lists.fd.io/mt/31034762/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 19.04 centos7 RPM package dependency errors

[Thomas F Herbert]

Dave and Ed,

The Makefile has dependencies that work. However, you will need epel. 
The packages required are:


yum install epel-release

yum install mbedtls

yum install python36

--Tom


On 04/11/2019 05:11 PM, Florin Coras wrote:
We do have it as a dependency because we want to make sure the plugin 
still builds. However, given that most of those who use tls use the 
openssl engine, we might consider not having mbedtls as a dependency 
for the packages that we push to packagecloud ...


On a separate note, what centos do we run in the container? It seems 
that even python3 has some dependency errors. I guess that once we 
align the vagrant version with it, things should just work.


Florin

On Apr 11, 2019, at 1:55 PM, Ed Kern (ejk) > wrote:




On Apr 11, 2019, at 2:22 PM, Florin Coras > wrote:


Are we building rpms on a host that has mbedtls installed?


Yes the centos container has mbedtls installed….has for quite some 
time since it is a listed

prerequisite straight out of the Makefile.

Ed




Just uninstalling it should disable the tlsmbedtls plugin, which is 
what we pretty much want.


Florin

On Apr 11, 2019, at 1:00 PM, Dave Wallace > wrote:


Tom/Billy,

Do you know what the current status is with the VPP rpm's on 
master/19.04?


I'm trying to install the VPP 19.04 packages frompackagecloud.io 
on a centos7 Vagrant/virtualbox VM (using 
.../vpp/extras/vagrant/Vagrantfile) to verify that the packages are 
correct. The 19.01 packages install fine, but the 19.04 and master 
packages fail with the following dependency errors:


--> Finished Dependency Resolution
Error: Package: vpp-plugins-19.04-rc1~b4.x86_64 (fdio_1904)
   Requires: libmbedtls.so.10()(64bit)
Error: Package: vpp-devel-19.04-rc1~b4.x86_64 (fdio_1904)
   Requires: /usr/bin/python3
Error: Package: vpp-19.04-rc1~b4.x86_64 (fdio_1904)
   Requires: /usr/bin/python3
Error: Package: vpp-plugins-19.04-rc1~b4.x86_64 (fdio_1904)
   Requires: libmbedx509.so.0()(64bit)
Error: Package: vpp-plugins-19.04-rc1~b4.x86_64 (fdio_1904)
   Requires: libmbedcrypto.so.2()(64bit)
 You could try using --skip-broken to work around the problem
 You could try running: rpm -Va --nofiles --nodigest

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

View/Reply Online (#12768):https://lists.fd.io/g/vpp-dev/message/12768
Mute This Topic:https://lists.fd.io/mt/31034762/675152
Group Owner:vpp-dev+ow...@lists.fd.io 

Unsubscribe:https://lists.fd.io/g/vpp-dev/unsub [fcoras.li...@gmail.com 
]

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


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

View/Reply Online (#12769):https://lists.fd.io/g/vpp-dev/message/12769
Mute This Topic:https://lists.fd.io/mt/31034762/675649
Group Owner:vpp-dev+ow...@lists.fd.io 
Unsubscribe:https://lists.fd.io/g/vpp-dev/unsub [e...@cisco.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 (#12773): https://lists.fd.io/g/vpp-dev/message/12773
Mute This Topic: https://lists.fd.io/mt/31034762/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 19.04 centos7 RPM package dependency errors

[Florin Coras]

We do have it as a dependency because we want to make sure the plugin still 
builds. However, given that most of those who use tls use the openssl engine, 
we might consider not having mbedtls as a dependency for the packages that we 
push to packagecloud ...

On a separate note, what centos do we run in the container? It seems that even 
python3 has some dependency errors. I guess that once we align the vagrant 
version with it, things should just work.

Florin

> On Apr 11, 2019, at 1:55 PM, Ed Kern (ejk)  wrote:
> 
> 
> 
>> On Apr 11, 2019, at 2:22 PM, Florin Coras > > wrote:
>> 
>> Are we building rpms on a host that has mbedtls installed? 
> 
> Yes the centos container has mbedtls installed….has for quite some time since 
> it is a listed
> prerequisite straight out of the Makefile.
> 
> Ed
> 
> 
> 
> 
>> Just uninstalling it should disable the tlsmbedtls plugin, which is what we 
>> pretty much want. 
>> 
>> Florin 
>> 
>>> On Apr 11, 2019, at 1:00 PM, Dave Wallace >> > wrote:
>>> 
>>> Tom/Billy,
>>> 
>>> Do you know what the current status is with the VPP rpm's on master/19.04?
>>> 
>>> I'm trying to install the VPP 19.04 packages from packagecloud.io 
>>>  on a centos7 Vagrant/virtualbox VM (using 
>>> .../vpp/extras/vagrant/Vagrantfile) to verify that the packages are 
>>> correct.  The 19.01 packages install fine, but the 19.04 and master 
>>> packages fail with the following dependency errors:
>>> 
>>> --> Finished Dependency Resolution
>>> Error: Package: vpp-plugins-19.04-rc1~b4.x86_64 (fdio_1904)
>>>Requires: libmbedtls.so.10()(64bit)
>>> Error: Package: vpp-devel-19.04-rc1~b4.x86_64 (fdio_1904)
>>>Requires: /usr/bin/python3
>>> Error: Package: vpp-19.04-rc1~b4.x86_64 (fdio_1904)
>>>Requires: /usr/bin/python3
>>> Error: Package: vpp-plugins-19.04-rc1~b4.x86_64 (fdio_1904)
>>>Requires: libmbedx509.so.0()(64bit)
>>> Error: Package: vpp-plugins-19.04-rc1~b4.x86_64 (fdio_1904)
>>>Requires: libmbedcrypto.so.2()(64bit)
>>>  You could try using --skip-broken to work around the problem
>>>  You could try running: rpm -Va --nofiles --nodigest
>>> 
>>> Thanks,
>>> -daw-
>>> -=-=-=-=-=-=-=-=-=-=-=-
>>> Links: You receive all messages sent to this group.
>>> 
>>> View/Reply Online (#12768): https://lists.fd.io/g/vpp-dev/message/12768 
>>> 
>>> Mute This Topic: https://lists.fd.io/mt/31034762/675152 
>>> 
>>> Group Owner: vpp-dev+ow...@lists.fd.io 
>>> Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub 
>>>   [fcoras.li...@gmail.com 
>>> ]
>>> -=-=-=-=-=-=-=-=-=-=-=-
>> 
>> -=-=-=-=-=-=-=-=-=-=-=-
>> Links: You receive all messages sent to this group.
>> 
>> View/Reply Online (#12769): https://lists.fd.io/g/vpp-dev/message/12769 
>> 
>> Mute This Topic: https://lists.fd.io/mt/31034762/675649 
>> 
>> Group Owner: vpp-dev+ow...@lists.fd.io 
>> Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub 
>>   [e...@cisco.com 
>> ]
>> -=-=-=-=-=-=-=-=-=-=-=-

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

View/Reply Online (#12772): https://lists.fd.io/g/vpp-dev/message/12772
Mute This Topic: https://lists.fd.io/mt/31034762/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 19.04 centos7 RPM package dependency errors

[Ed Kern via Lists.Fd.Io]

On Apr 11, 2019, at 2:22 PM, Florin Coras 
mailto:fcoras.li...@gmail.com>> wrote:

Are we building rpms on a host that has mbedtls installed?

Yes the centos container has mbedtls installed….has for quite some time since 
it is a listed
prerequisite straight out of the Makefile.

Ed




Just uninstalling it should disable the tlsmbedtls plugin, which is what we 
pretty much want.

Florin

On Apr 11, 2019, at 1:00 PM, Dave Wallace 
mailto:dwallac...@gmail.com>> wrote:

Tom/Billy,

Do you know what the current status is with the VPP rpm's on master/19.04?

I'm trying to install the VPP 19.04 packages from 
packagecloud.io on a centos7 Vagrant/virtualbox VM 
(using .../vpp/extras/vagrant/Vagrantfile) to verify that the packages are 
correct.  The 19.01 packages install fine, but the 19.04 and master packages 
fail with the following dependency errors:

--> Finished Dependency Resolution
Error: Package: vpp-plugins-19.04-rc1~b4.x86_64 (fdio_1904)
   Requires: libmbedtls.so.10()(64bit)
Error: Package: vpp-devel-19.04-rc1~b4.x86_64 (fdio_1904)
   Requires: /usr/bin/python3
Error: Package: vpp-19.04-rc1~b4.x86_64 (fdio_1904)
   Requires: /usr/bin/python3
Error: Package: vpp-plugins-19.04-rc1~b4.x86_64 (fdio_1904)
   Requires: libmbedx509.so.0()(64bit)
Error: Package: vpp-plugins-19.04-rc1~b4.x86_64 (fdio_1904)
   Requires: libmbedcrypto.so.2()(64bit)
 You could try using --skip-broken to work around the problem
 You could try running: rpm -Va --nofiles --nodigest

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

View/Reply Online (#12768): https://lists.fd.io/g/vpp-dev/message/12768
Mute This Topic: https://lists.fd.io/mt/31034762/675152
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub  
[fcoras.li...@gmail.com]
-=-=-=-=-=-=-=-=-=-=-=-

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

View/Reply Online (#12769): https://lists.fd.io/g/vpp-dev/message/12769
Mute This Topic: https://lists.fd.io/mt/31034762/675649
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub  
[e...@cisco.com]
-=-=-=-=-=-=-=-=-=-=-=-

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

View/Reply Online (#12771): https://lists.fd.io/g/vpp-dev/message/12771
Mute This Topic: https://lists.fd.io/mt/31034762/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] Mellanox dependency changes

[Stephen Hemminger]

On Thu, 11 Apr 2019 10:24:45 -0700
"Stephen Hemminger via Lists.Fd.Io"  
wrote:

> On Thu, 11 Apr 2019 09:30:12 +
> "Benoit Ganne (bganne)"  wrote:
> 
> > Hi Stephen,
> >   
> > > The rdma-core stuff is likely to be a problem on Azure. The Mellanox
> > > device is always hidden as a secondary device behind a synthetic virtual
> > > device based on VMBus. There are two DPDK different ways this is used. One
> > > is with vdev_netvsc/failsafe/tap and the other is with netvsc PMD.
> > > In either case, the virtual device expects to see the MLX device show up
> > > as a VF if enabled.
> > > So unless you want to write native VPP drivers for VMBus as well, I don't
> > > see how having native rdma-core driver will help. It will only get
> > > confused.
> > 
> > I'd be interested to better understand how it works. My current 
> > understanding:
> >  - the Mellanox device shows up as a PCI SR-IOV VF in the Linux VM ("the 
> > VF")
> >  - the VF is associated with a VMBUS (not PCI) netvsc virtual device
> >  - the netvsc and the VF shares the same MAC. The netvsc is guaranteed to 
> > be always there whereas the VF can disappear between migrations etc.
> >  - control plane traffic (multicast eg. ARP, other?) always go through the 
> > netvsc
> >  - if the VF is present is gets all the traffic minus control plane. If it 
> > is not present, all traffic gets rerouted through netvsc as a fallback
> > 
> > Am I correct? Could you elaborate a little bit more about what is the 
> > control plane traffic (basically what we should miss on the VF)?
> > If so, I see at least 2 problems we need to tackle:
> >  - we need to receive control plane traffic from netvsc because of eg. ARP. 
> > However, being control-plane/fallback, it could be slow and use eg. TAP or 
> > even AF_PACKET. We will also need to use it to populate the neighbor 
> > entries of the VF
> >  - the VF can appear/disappear w/o notice in case of migration etc. That 
> > could be handled in different ways, eg. by the control plane agent 
> > (removing the rdma iface from VPP prior to migration, adding it after post 
> > migration) or by leveraging bonding or...
> > 
> > Thanks for your help,
> > Ben  
> 
> Very close.
>   - In Azure the first packet of every flow arrives on the netvsc (slow path).
> Packets arrive to FPGA, anything with non-matching flow goes to Azure 
> host flow control (VFP) which evaluates
> it against rules. On success, it programs FPGA and forwards packet over 
> netvsc path.
>   - The presence of VF is reported as an event on VMBus
>   - VF is not enabled until netvsc sends message to host, acts as ack that VF 
> is ok.
>   - VF removal is reported to netvsc, and it switches datapath back
>   - the VF should not be manipulated directly, it is hidden in DPDK; in 
> Linux/FreeBSD it is marked as slave

Additionally, Windows and recent versions of Linux associate netvsc with VF 
from the VMBus serial number.
This is simpler and more reliable than the MAC address.

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

View/Reply Online (#12770): https://lists.fd.io/g/vpp-dev/message/12770
Mute This Topic: https://lists.fd.io/mt/30795618/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 19.04 centos7 RPM package dependency errors

[Florin Coras]

Are we building rpms on a host that has mbedtls installed? Just uninstalling it 
should disable the tlsmbedtls plugin, which is what we pretty much want. 

Florin 

> On Apr 11, 2019, at 1:00 PM, Dave Wallace  wrote:
> 
> Tom/Billy,
> 
> Do you know what the current status is with the VPP rpm's on master/19.04?
> 
> I'm trying to install the VPP 19.04 packages from packagecloud.io on a 
> centos7 Vagrant/virtualbox VM (using .../vpp/extras/vagrant/Vagrantfile) to 
> verify that the packages are correct.  The 19.01 packages install fine, but 
> the 19.04 and master packages fail with the following dependency errors:
> 
> --> Finished Dependency Resolution
> Error: Package: vpp-plugins-19.04-rc1~b4.x86_64 (fdio_1904)
>Requires: libmbedtls.so.10()(64bit)
> Error: Package: vpp-devel-19.04-rc1~b4.x86_64 (fdio_1904)
>Requires: /usr/bin/python3
> Error: Package: vpp-19.04-rc1~b4.x86_64 (fdio_1904)
>Requires: /usr/bin/python3
> Error: Package: vpp-plugins-19.04-rc1~b4.x86_64 (fdio_1904)
>Requires: libmbedx509.so.0()(64bit)
> Error: Package: vpp-plugins-19.04-rc1~b4.x86_64 (fdio_1904)
>Requires: libmbedcrypto.so.2()(64bit)
>  You could try using --skip-broken to work around the problem
>  You could try running: rpm -Va --nofiles --nodigest
> 
> Thanks,
> -daw-
> -=-=-=-=-=-=-=-=-=-=-=-
> Links: You receive all messages sent to this group.
> 
> View/Reply Online (#12768): https://lists.fd.io/g/vpp-dev/message/12768
> Mute This Topic: https://lists.fd.io/mt/31034762/675152
> Group Owner: vpp-dev+ow...@lists.fd.io
> Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub  [fcoras.li...@gmail.com]
> -=-=-=-=-=-=-=-=-=-=-=-

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

View/Reply Online (#12769): https://lists.fd.io/g/vpp-dev/message/12769
Mute This Topic: https://lists.fd.io/mt/31034762/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 19.04 centos7 RPM package dependency errors

[Dave Wallace]

Tom/Billy,

Do you know what the current status is with the VPP rpm's on master/19.04?

I'm trying to install the VPP 19.04 packages from packagecloud.io on a 
centos7 Vagrant/virtualbox VM (using .../vpp/extras/vagrant/Vagrantfile) 
to verify that the packages are correct.  The 19.01 packages install 
fine, but the 19.04 and master packages fail with the following 
dependency errors:


--> Finished Dependency Resolution
Error: Package: vpp-plugins-19.04-rc1~b4.x86_64 (fdio_1904)
   Requires: libmbedtls.so.10()(64bit)
Error: Package: vpp-devel-19.04-rc1~b4.x86_64 (fdio_1904)
   Requires: /usr/bin/python3
Error: Package: vpp-19.04-rc1~b4.x86_64 (fdio_1904)
   Requires: /usr/bin/python3
Error: Package: vpp-plugins-19.04-rc1~b4.x86_64 (fdio_1904)
   Requires: libmbedx509.so.0()(64bit)
Error: Package: vpp-plugins-19.04-rc1~b4.x86_64 (fdio_1904)
   Requires: libmbedcrypto.so.2()(64bit)
 You could try using --skip-broken to work around the problem
 You could try running: rpm -Va --nofiles --nodigest

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

View/Reply Online (#12768): https://lists.fd.io/g/vpp-dev/message/12768
Mute This Topic: https://lists.fd.io/mt/31034762/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] Mellanox dependency changes

[Stephen Hemminger]

On Thu, 11 Apr 2019 09:30:12 +
"Benoit Ganne (bganne)"  wrote:

> Hi Stephen,
> 
> > The rdma-core stuff is likely to be a problem on Azure. The Mellanox
> > device is always hidden as a secondary device behind a synthetic virtual
> > device based on VMBus. There are two DPDK different ways this is used. One
> > is with vdev_netvsc/failsafe/tap and the other is with netvsc PMD.
> > In either case, the virtual device expects to see the MLX device show up
> > as a VF if enabled.
> > So unless you want to write native VPP drivers for VMBus as well, I don't
> > see how having native rdma-core driver will help. It will only get
> > confused.  
> 
> I'd be interested to better understand how it works. My current understanding:
>  - the Mellanox device shows up as a PCI SR-IOV VF in the Linux VM ("the VF")
>  - the VF is associated with a VMBUS (not PCI) netvsc virtual device
>  - the netvsc and the VF shares the same MAC. The netvsc is guaranteed to be 
> always there whereas the VF can disappear between migrations etc.
>  - control plane traffic (multicast eg. ARP, other?) always go through the 
> netvsc
>  - if the VF is present is gets all the traffic minus control plane. If it is 
> not present, all traffic gets rerouted through netvsc as a fallback
> 
> Am I correct? Could you elaborate a little bit more about what is the control 
> plane traffic (basically what we should miss on the VF)?
> If so, I see at least 2 problems we need to tackle:
>  - we need to receive control plane traffic from netvsc because of eg. ARP. 
> However, being control-plane/fallback, it could be slow and use eg. TAP or 
> even AF_PACKET. We will also need to use it to populate the neighbor entries 
> of the VF
>  - the VF can appear/disappear w/o notice in case of migration etc. That 
> could be handled in different ways, eg. by the control plane agent (removing 
> the rdma iface from VPP prior to migration, adding it after post migration) 
> or by leveraging bonding or...
> 
> Thanks for your help,
> Ben

Very close.
  - In Azure the first packet of every flow arrives on the netvsc (slow path).
Packets arrive to FPGA, anything with non-matching flow goes to Azure host 
flow control (VFP) which evaluates
it against rules. On success, it programs FPGA and forwards packet over 
netvsc path.
  - The presence of VF is reported as an event on VMBus
  - VF is not enabled until netvsc sends message to host, acts as ack that VF 
is ok.
  - VF removal is reported to netvsc, and it switches datapath back
  - the VF should not be manipulated directly, it is hidden in DPDK; in 
Linux/FreeBSD it is marked as slave
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#12767): https://lists.fd.io/g/vpp-dev/message/12767
Mute This Topic: https://lists.fd.io/mt/30795618/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] Packet with custom ip-proto value drops in ip4-local node

[Florin Coras]

Hi Satish, 

From the error counters lower, it seems that ip local is not the one to drop 
the packets. Also, if the packet is not tcp or udp, checksum should not 
computed, as per ip4_local_check_l4_csum [1]. Also, packets that fail the 
source ip check should be dropped with IP4_ERROR_SPOOFED_LOCAL_PACKETS or 
IP4_ERROR_SRC_LOOKUP_MISS. 

So, to clear this up, could you attach gdb to your vpp (preferably compiled 
with debug symbols), breakpoint ip4_local_set_next_and_error and figure out if 
next for your packets is set correctly?

Hope this helps,
Florin

[1] Note that I’m using master code as a reference not 18.10 code


> On Apr 11, 2019, at 8:04 AM, satish.gu...@gmail.com wrote:
> 
> Hi VPP-Dev,
>  
> We recently moved to 1810 from 1801 and found the following issue.
> Is this a known issue (or) any help on whats happening here ?
>  
> 1. We are using memif in IP mode.
> 2. Some Control plane process sends message over MEMIF to VPP process ( memif 
> mode = IP )
> 3. We are using a custom ip-proto value of 222 and tapping these packets in a 
> separate graph node on VPP side.
> 4. This has been working fine till 1801.
> 5. When we moved to 1810, the packet is getting dropped in ip4-local with 
> reason as "blackholed packets"
> 6. When we looked at the code, this drop can happen in the following reasons
>  - SRC-IP invalid
>  - TCP/UDP checksum wrong
>  
> 7. The FIB contains the SRC-IP subnet. Hence, SRC-IP error might not be the 
> reason
> 8. We are suspecting that this drop is due to TCP/UDP csum.
>  
> But, when the ip-proto is non-UDP-TCP, ideally this packet should have gone 
> to the next layer bypassing all these checks.
>  
> Following is the packet trace / show output and fib details
>  
> ===
> ##) 
> vpp# show node counters
>CountNode  Reason
>  2null-node   blackholed packets
>  
> ##)
> vpp# show trace
>  
> Packet 1
>  
> 00:48:08:119264: memif-input
>   memif: hw_if_index 3 next-index 0
> slot: ring 0
> 00:48:08:119354: ip4-input-no-checksum
>   unknown 222: 192.168.1.2 -> 192.168.1.1
> tos 0x00, ttl 64, length 10020, checksum 0xcfbe
> fragment id 0x
> 00:48:08:120320: ip4-lookup
>   fib 0 dpo-idx 5 flow hash: 0x
>   unknown 222: 192.168.1.2 -> 192.168.1.1
> tos 0x00, ttl 64, length 10020, checksum 0xcfbe
> fragment id 0x
> 00:48:08:120331: ip4-local
> unknown 222: 192.168.1.2 -> 192.168.1.1
>   tos 0x00, ttl 64, length 10020, checksum 0xcfbe
>   fragment id 0x
>  
> ##)
>  
> vpp# show ip fib
> ipv4-VRF:0, fib_index:0, flow hash:[src dst sport dport proto ] 
> locks:[src:plugin-hi:2, src:default-route:1, ]
> 192.168.1.0/32
>   unicast-ip4-chain
>   [@0]: dpo-load-balance: [proto:ip4 index:10 buckets:1 uRPF:9 to:[0:0]]
> [0] [@0]: dpo-drop ip4
> 192.168.1.0/24
>   unicast-ip4-chain
>   [@0]: dpo-load-balance: [proto:ip4 index:9 buckets:1 uRPF:12 to:[0:0]]
> [0] [@5]: ipv4 via 0.0.0.0 memif0/0: mtu:9000
> 192.168.1.1/32
>   unicast-ip4-chain
>   [@0]: dpo-load-balance: [proto:ip4 index:12 buckets:1 uRPF:13 to:[1:10020]]
> [0] [@2]: dpo-receive: 192.168.1.1 on memif0/0
> 192.168.1.255/32
>   unicast-ip4-chain
>   [@0]: dpo-load-balance: [proto:ip4 index:11 buckets:1 uRPF:11 to:[0:0]]
> [0] [@0]: dpo-drop ip4
>  
> 
>  
> Also, is there anyway to get the exact sub-error-code which indicates that 
> this is due to TCP/UDP checksum error etc ?
> Appreciate any inputs in this regard.
>  
> Thanks & Regards,
> Satish
>  
>  
> -=-=-=-=-=-=-=-=-=-=-=-
> Links: You receive all messages sent to this group.
> 
> View/Reply Online (#12765): https://lists.fd.io/g/vpp-dev/message/12765
> Mute This Topic: https://lists.fd.io/mt/31031696/675152
> Group Owner: vpp-dev+ow...@lists.fd.io
> Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub  [fcoras.li...@gmail.com]
> -=-=-=-=-=-=-=-=-=-=-=-

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

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

[vpp-dev] Packet with custom ip-proto value drops in ip4-local node

[satish . gundu]

Hi VPP-Dev,
 
We recently moved to 1810 from 1801 and found the following issue.
Is this a known issue (or) any help on whats happening here ?
 
1. We are using memif in IP mode.
2. Some Control plane process sends message over MEMIF to VPP process ( memif 
mode = IP )
3. We are using a custom ip-proto value of 222 and tapping these packets in a 
separate graph node on VPP side.
4. This has been working fine till 1801.
5. When we moved to 1810, the packet is getting dropped in ip4-local with 
reason as "blackholed packets"
6. When we looked at the code, this drop can happen in the following reasons
 - SRC-IP invalid
 - TCP/UDP checksum wrong
 
7. The FIB contains the SRC-IP subnet. Hence, SRC-IP error might not be the 
reason
8. We are suspecting that this drop is due to TCP/UDP csum.
 
But, when the ip-proto is non-UDP-TCP, ideally this packet should have gone to 
the next layer bypassing all these checks.
 
Following is the packet trace / show output and fib details
 
===
##) 
vpp# show node counters
   Count                    Node                  Reason
         2                null-node               blackholed packets
 
##)
vpp# show trace
 
Packet 1
 
00:48:08:119264: memif-input
  memif: hw_if_index 3 next-index 0
    slot: ring 0
00:48:08:119354: ip4-input-no-checksum
  unknown 222: 192.168.1.2 -> 192.168.1.1
    tos 0x00, ttl 64, length 10020, checksum 0xcfbe
    fragment id 0x
00:48:08:120320: ip4-lookup
  fib 0 dpo-idx 5 flow hash: 0x
  unknown 222: 192.168.1.2 -> 192.168.1.1
    tos 0x00, ttl 64, length 10020, checksum 0xcfbe
    fragment id 0x
00:48:08:120331: ip4-local
    unknown 222: 192.168.1.2 -> 192.168.1.1
      tos 0x00, ttl 64, length 10020, checksum 0xcfbe
      fragment id 0x
 
##)
 
vpp# show ip fib
ipv4-VRF:0, fib_index:0, flow hash:[src dst sport dport proto ] 
locks:[src:plugin-hi:2, src:default-route:1, ]
192.168.1.0/32
  unicast-ip4-chain
  [@0]: dpo-load-balance: [proto:ip4 index:10 buckets:1 uRPF:9 to:[0:0]]
    [0] [@0]: dpo-drop ip4
192.168.1.0/24
  unicast-ip4-chain
  [@0]: dpo-load-balance: [proto:ip4 index:9 buckets:1 uRPF:12 to:[0:0]]
    [0] [@5]: ipv4 via 0.0.0.0 memif0/0: mtu:9000
192.168.1.1/32
  unicast-ip4-chain
  [@0]: dpo-load-balance: [proto:ip4 index:12 buckets:1 uRPF:13 to:[1:10020]]
    [0] [@2]: dpo-receive: 192.168.1.1 on memif0/0
192.168.1.255/32
  unicast-ip4-chain
  [@0]: dpo-load-balance: [proto:ip4 index:11 buckets:1 uRPF:11 to:[0:0]]
    [0] [@0]: dpo-drop ip4
 

 
Also, is there anyway to get the exact sub-error-code which indicates that this 
is due to TCP/UDP checksum error etc ?
Appreciate any inputs in this regard.
 
Thanks & Regards,
Satish
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#12765): https://lists.fd.io/g/vpp-dev/message/12765
Mute This Topic: https://lists.fd.io/mt/31031696/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 interfaces names

[Damjan Marion via Lists.Fd.Io]

> On 11 Apr 2019, at 13:57, Mohamed Mohamed via Lists.Fd.Io 
>  wrote:
> 
> Hi All:
> 
>  Today DPDK bind script will name the interfaces based on their PCI address 
> so for example if I have the following 2 interfaces
> 00:08.0 Ethernet controller: Intel Corporation 82540EM Gigabit Ethernet 
> Controller (rev 02)
> 00:09.0 Ethernet controller: Intel Corporation 82540EM Gigabit Ethernet 
> Controller (rev 02)
> 
> I will end up with :- 
> 
> GigabitEthernet0/8/0  1  up  1500/0/0/0 
> GigabitEthernet0/9/0  2  up  1500/0/0/0
> 
> 
> is there a mechanism today decouple the interface's name from its PCI address 
> ?  Ideally I like to have G0/0/0 and G0/0/1 for the above example.
> so regardless to where I deploy vpp I can use the same configs ?

You can assign whatever name you want, under some resonable constraints by 
using “name” option in startup.conf.

ie.

dpdk {
  dev :3b:0a.0 {
name eth0
  }
}

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

View/Reply Online (#12764): https://lists.fd.io/g/vpp-dev/message/12764
Mute This Topic: https://lists.fd.io/mt/31029751/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 interfaces names

[Mohamed Mohamed via Lists.Fd.Io]

Hi All:
 Today DPDK bind script will name the interfaces based on their PCI address so 
for example if I have the following 2 interfaces
00:08.0 Ethernet controller: Intel Corporation 82540EM Gigabit Ethernet 
Controller (rev 02)
00:09.0 Ethernet controller: Intel Corporation 82540EM Gigabit Ethernet 
Controller (rev 02)
I will end up with :- 

GigabitEthernet0/8/0              1      up          1500/0/0/0     
GigabitEthernet0/9/0              2      up          1500/0/0/0

is there a mechanism today decouple the interface's name from its PCI address ? 
 Ideally I like to have G0/0/0 and G0/0/1 for the above example.so regardless 
to where I deploy vpp I can use the same configs ?
Thanks,Mohamed
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#12763): https://lists.fd.io/g/vpp-dev/message/12763
Mute This Topic: https://lists.fd.io/mt/31029751/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 and Non-VPP Communication #vpp

[koolvivekvroy]

Can VPP and non-VPP Linux process share a single database (say shared memory)?
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#12762): https://lists.fd.io/g/vpp-dev/message/12762
Mute This Topic: https://lists.fd.io/mt/31029666/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] Non TCP-UDP packet drop in ip4-local node in 1810

[satish . gundu]

[Edited Message Follows]

Hi VPP-Dev,

We recently moved to 1810 from 1801 and found the following issue.
Is this a known issue (or) any help on whats happening here ?

1. We are using memif in IP mode.
2. Some Control plane process sends message over MEMIF to VPP process ( memif 
mode = IP )
3. We are using a custom ip-proto value of 222 and tapping these packets in a 
separate graph node on VPP side.
4. This has been working fine till 1801.
5. When we moved to 1810, the packet is getting dropped in ip4-local with 
reason as "blackholed packets"
6. When we looked at the code, this drop can happen in the following reasons
 - SRC-IP invalid
 - TCP/UDP checksum wrong

7. The FIB contains the SRC-IP subnet. Hence, SRC-IP error might not be the 
reason
8. We are suspecting that this drop is due to TCP/UDP csum.

But, when the ip-proto is non-UDP-TCP, ideally this packet should have gone to 
the next layer bypassing all these checks.

Following is the packet trace / show output and fib details

===
##) 
vpp# show node counters
   Count                    Node                  Reason
         2                null-node               blackholed packets

##)
vpp# show trace

Packet 1
 
00:48:08:119264: memif-input
  memif: hw_if_index 3 next-index 0
    slot: ring 0
00:48:08:119354: ip4-input-no-checksum
  unknown 222: 192.168.1.2 -> 192.168.1.1
    tos 0x00, ttl 64, length 10020, checksum 0xcfbe
    fragment id 0x
00:48:08:120320: ip4-lookup
  fib 0 dpo-idx 5 flow hash: 0x
  unknown 222: 192.168.1.2 -> 192.168.1.1
    tos 0x00, ttl 64, length 10020, checksum 0xcfbe
    fragment id 0x
00:48:08:120331: ip4-local
    unknown 222: 192.168.1.2 -> 192.168.1.1
      tos 0x00, ttl 64, length 10020, checksum 0xcfbe
      fragment id 0x

##)

vpp# show ip fib
ipv4-VRF:0, fib_index:0, flow hash:[src dst sport dport proto ] 
locks:[src:plugin-hi:2, src:default-route:1, ]
192.168.1.0/32
  unicast-ip4-chain
  [@0]: dpo-load-balance: [proto:ip4 index:10 buckets:1 uRPF:9 to:[0:0]]
    [0] [@0]: dpo-drop ip4
192.168.1.0/24
  unicast-ip4-chain
  [@0]: dpo-load-balance: [proto:ip4 index:9 buckets:1 uRPF:12 to:[0:0]]
    [0] [@5]: ipv4 via 0.0.0.0 memif0/0: mtu:9000
192.168.1.1/32
  unicast-ip4-chain
  [@0]: dpo-load-balance: [proto:ip4 index:12 buckets:1 uRPF:13 to:[1:10020]]
    [0] [@2]: dpo-receive: 192.168.1.1 on memif0/0
192.168.1.255/32
  unicast-ip4-chain
  [@0]: dpo-load-balance: [proto:ip4 index:11 buckets:1 uRPF:11 to:[0:0]]
    [0] [@0]: dpo-drop ip4



Also, is there anyway to get the exact sub-error-code which indicates that this 
is due to TCP/UDP checksum error etc ?
Appreciate any inputs in this regard.

Thanks & Regards,
Satish
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#12760): https://lists.fd.io/g/vpp-dev/message/12760
Mute This Topic: https://lists.fd.io/mt/31028559/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] Mellanox dependency changes

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

Hi Stephen,

> The rdma-core stuff is likely to be a problem on Azure. The Mellanox
> device is always hidden as a secondary device behind a synthetic virtual
> device based on VMBus. There are two DPDK different ways this is used. One
> is with vdev_netvsc/failsafe/tap and the other is with netvsc PMD.
> In either case, the virtual device expects to see the MLX device show up
> as a VF if enabled.
> So unless you want to write native VPP drivers for VMBus as well, I don't
> see how having native rdma-core driver will help. It will only get
> confused.

I'd be interested to better understand how it works. My current understanding:
 - the Mellanox device shows up as a PCI SR-IOV VF in the Linux VM ("the VF")
 - the VF is associated with a VMBUS (not PCI) netvsc virtual device
 - the netvsc and the VF shares the same MAC. The netvsc is guaranteed to be 
always there whereas the VF can disappear between migrations etc.
 - control plane traffic (multicast eg. ARP, other?) always go through the 
netvsc
 - if the VF is present is gets all the traffic minus control plane. If it is 
not present, all traffic gets rerouted through netvsc as a fallback

Am I correct? Could you elaborate a little bit more about what is the control 
plane traffic (basically what we should miss on the VF)?
If so, I see at least 2 problems we need to tackle:
 - we need to receive control plane traffic from netvsc because of eg. ARP. 
However, being control-plane/fallback, it could be slow and use eg. TAP or even 
AF_PACKET. We will also need to use it to populate the neighbor entries of the 
VF
 - the VF can appear/disappear w/o notice in case of migration etc. That could 
be handled in different ways, eg. by the control plane agent (removing the rdma 
iface from VPP prior to migration, adding it after post migration) or by 
leveraging bonding or...

Thanks for your help,
Ben
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

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

[vpp-dev] Non TCP-UDP packet drop in ip4-local node in 1810

[satish . gundu]

Hi VPP-Dev,

We recently moved to 1810 from 1801 and found the following issue.
Is this a known issue (or) any help on whats happening here ?

1. We are using memif in IP mode.
2. Some Control plane process sends message over MEMIF to VPP process ( memif 
mode = IP )
3. We are using a custom ip-proto value of 222 and tapping these packets in a 
separate graph node on VPP side.
4. This has been working fine till 1801.
5. When we moved to 1810, the packet is getting dropped in ip4-local with 
reason as "blackholed packets"
6. When we looked at the code, this drop can happen in the following reasons
 - SRC-IP invalid
 - TCP/UDP checksum wrong

7. The FIB contains the SRC-IP subnet. Hence, SRC-IP error might not be the 
reason
8. We are suspecting that this drop is due to TCP/UDP csum.

But, when the ip-proto is non-UDP-TCP, why we should see this drop ?

Following is the packet trace / show output and fib details

===
##) 
vpp# show node counters
   Count                    Node                  Reason
         2                null-node               blackholed packets

##)
vpp# show trace

Packet 1
 
00:48:08:119264: memif-input
  memif: hw_if_index 3 next-index 0
    slot: ring 0
00:48:08:119354: ip4-input-no-checksum
  unknown 222: 192.168.1.2 -> 192.168.1.1
    tos 0x00, ttl 64, length 10020, checksum 0xcfbe
    fragment id 0x
00:48:08:120320: ip4-lookup
  fib 0 dpo-idx 5 flow hash: 0x
  unknown 222: 192.168.1.2 -> 192.168.1.1
    tos 0x00, ttl 64, length 10020, checksum 0xcfbe
    fragment id 0x
00:48:08:120331: ip4-local
    unknown 222: 192.168.1.2 -> 192.168.1.1
      tos 0x00, ttl 64, length 10020, checksum 0xcfbe
      fragment id 0x

##)

vpp# show ip fib
ipv4-VRF:0, fib_index:0, flow hash:[src dst sport dport proto ] 
locks:[src:plugin-hi:2, src:default-route:1, ]
192.168.1.0/32
  unicast-ip4-chain
  [@0]: dpo-load-balance: [proto:ip4 index:10 buckets:1 uRPF:9 to:[0:0]]
    [0] [@0]: dpo-drop ip4
192.168.1.0/24
  unicast-ip4-chain
  [@0]: dpo-load-balance: [proto:ip4 index:9 buckets:1 uRPF:12 to:[0:0]]
    [0] [@5]: ipv4 via 0.0.0.0 memif0/0: mtu:9000
192.168.1.1/32
  unicast-ip4-chain
  [@0]: dpo-load-balance: [proto:ip4 index:12 buckets:1 uRPF:13 to:[1:10020]]
    [0] [@2]: dpo-receive: 192.168.1.1 on memif0/0
192.168.1.255/32
  unicast-ip4-chain
  [@0]: dpo-load-balance: [proto:ip4 index:11 buckets:1 uRPF:11 to:[0:0]]
    [0] [@0]: dpo-drop ip4



Also, is there anyway to get the exact sub-error-code which indicates that this 
is due to TCP/UDP checksum error etc ?
Appreciate any inputs in this regard.

Thanks & Regards,
Satish
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#12760): https://lists.fd.io/g/vpp-dev/message/12760
Mute This Topic: https://lists.fd.io/mt/31028559/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] do not SNAT if forwarding enabled

[Shahid Khan]

There is another physical port bridged to loop1 which is on 192.168.15.0/24
network.
.the packets coming inside GRE tunnel are for 192.168.15.0/24  network.

also just want to understand  why SNAT is blocked when forwarding is
enabled ?
someone might have a requirement to SNAT first and then do forward.

when i comment the code as below, SNAT and GRE both works. but i don't know
how it will impact rest of code/functionality.

static inline int
snat_not_translate (snat_main_t * sm, vlib_node_runtime_t * node,
u32 sw_if_index0, ip4_header_t * ip0, u32 proto0,
u32 rx_fib_index0, u32 thread_index)
{
  udp_header_t *udp0 = ip4_next_header (ip0);
  snat_session_key_t key0, sm0;
  clib_bihash_kv_8_8_t kv0, value0;

  key0.addr = ip0->dst_address;
  key0.port = udp0->dst_port;
  key0.protocol = proto0;
  key0.fib_index = sm->outside_fib_index;
  kv0.key = key0.as_u64;

  /* NAT packet aimed at external address if */
  /* has active sessions */
  if (clib_bihash_search_8_8 (&sm->per_thread_data[thread_index].out2in,
&kv0,
  &value0))
{
  /* or is static mappings */
  if (!snat_static_mapping_match (sm, key0, &sm0, 1, 0, 0, 0, 0, 0))
return 0;
}
  else
return 0;

/*
  if (sm->forwarding_enabled)
return 1;
*/

  return snat_not_translate_fast (sm, node, sw_if_index0, ip0, proto0,
  rx_fib_index0);
}



-Shahid.




On Thu, Apr 11, 2019 at 12:44 PM Ole Troan  wrote:

> Shahid,
>
> Right, so the GRE packets shouldn’t go through the NAT at all.
> Are the GRE tunnel itself marked as inside?
>
> I should have thoguht this was supported with
> https://jira.fd.io/browse/VPP-447
> Let me see if I can reproduce.,
>
> Best regards,
> Ole
>
> > On 10 Apr 2019, at 12:55, Shahid Khan  wrote:
> >
> > Hi Ole,
> >
> > we have a bridge(loop0) with a private ip say 192.168.100.2/24.
> > a TAP is also connected to this bridge and other end of TAP is on host
> side.
> >
> > we have one physical interface connected to another bridge (loop1) with
> outside network ip of say 192.168.10.1/24
> > and a GRE tunnel is created having source as 192.168.10.1.
> >
> > Host has requirement to initiate sessions(tcp/udp) to outside network.
> so we have applied NAT as below.
> >
> > nat44 add interface address loop1
> > set interface nat44 in loop0 out loop1
> >
> > with this host can initiate session with outside network and SNAT works
> fine.
> >
> > But GRE does not work. we looked into traces and found that packet
> comming to GRE tunnels are getting dropped with  trace showing "unknown
> protocol".
> >
> > if we enable forwarding then GRE packets are getting forwarded to
> destination but now host is not able to initiate session to outside network
> because SNAT stops
> >
> > -Shahid.
> >
> >
> >
> >
> >
> >
> > On Wed, Apr 10, 2019 at 2:33 PM Ole Troan  wrote:
> > Hi Shahid,
> >
> > What are you trying to achieve?
> > https://wiki.fd.io/view/VPP/NAT#Enable_or_disable_forwarding
> >
> > You do not typically enable the “forwarding” feature.
> >
> > Cheers,
> > Ole
> >
> > > On 8 Apr 2019, at 07:52, Shahid Khan 
> wrote:
> > >
> > > can someone look into below query ?
> > >
> > > -Shahid.
> > >
> > > On Wed, Apr 3, 2019 at 12:56 PM Shahid Khan via Lists.Fd.Io
>  wrote:
> > > Hi,
> > >
> > > can someone help us on below query ?
> > >
> > > -Shahid.
> > >
> > > On Mon, Apr 1, 2019 at 11:45 AM Shahid Khan via Lists.Fd.Io
>  wrote:
> > >
> > > I have following query related to SNAT on VPP Release 19.0.1.02
> > >
> > > following is the code from vpp/src/plugins/nat/in2out.c
> > >
> > > static inline int
> > > snat_not_translate (snat_main_t * sm, vlib_node_runtime_t * node,
> > > u32 sw_if_index0, ip4_header_t * ip0, u32 proto0,
> > > u32 rx_fib_index0, u32 thread_index)
> > > {
> > >   udp_header_t *udp0 = ip4_next_header (ip0);
> > >   snat_session_key_t key0, sm0;
> > >   clib_bihash_kv_8_8_t kv0, value0;
> > >
> > >   key0.addr = ip0->dst_address;
> > >   key0.port = udp0->dst_port;
> > >   key0.protocol = proto0;
> > >   key0.fib_index = sm->outside_fib_index;
> > >   kv0.key = key0.as_u64;
> > >
> > >   /* NAT packet aimed at external address if */
> > >   /* has active sessions */
> > >   if (clib_bihash_search_8_8
> (&sm->per_thread_data[thread_index].out2in, &kv0,
> > >   &value0))
> > > {
> > >   /* or is static mappings */
> > >   if (!snat_static_mapping_match (sm, key0, &sm0, 1, 0, 0, 0, 0,
> 0))
> > > return 0;
> > > }
> > >   else
> > > return 0;
> > >
> > >   if (sm->forwarding_enabled)
> > > return 1;
> > >
> > >
> > >   return snat_not_translate_fast (sm, node, sw_if_index0, ip0, proto0,
> > >   rx_fib_index0);
> > > }
> > >
> > > want to understand why above highlighted condition is there in code ?
> > >
> > > this  is causing SNAT to stop working the moment we enable fo

Re: [vpp-dev] do not SNAT if forwarding enabled

[Ole Troan]

Shahid,

Right, so the GRE packets shouldn’t go through the NAT at all.
Are the GRE tunnel itself marked as inside?

I should have thoguht this was supported with https://jira.fd.io/browse/VPP-447
Let me see if I can reproduce.,

Best regards,
Ole

> On 10 Apr 2019, at 12:55, Shahid Khan  wrote:
> 
> Hi Ole,
> 
> we have a bridge(loop0) with a private ip say 192.168.100.2/24. 
> a TAP is also connected to this bridge and other end of TAP is on host side.
> 
> we have one physical interface connected to another bridge (loop1) with 
> outside network ip of say 192.168.10.1/24
> and a GRE tunnel is created having source as 192.168.10.1.
> 
> Host has requirement to initiate sessions(tcp/udp) to outside network. so we 
> have applied NAT as below.
> 
> nat44 add interface address loop1
> set interface nat44 in loop0 out loop1
> 
> with this host can initiate session with outside network and SNAT works fine.
> 
> But GRE does not work. we looked into traces and found that packet comming to 
> GRE tunnels are getting dropped with  trace showing "unknown protocol".
> 
> if we enable forwarding then GRE packets are getting forwarded to destination 
> but now host is not able to initiate session to outside network because SNAT 
> stops
> 
> -Shahid.
> 
> 
> 
> 
> 
> 
> On Wed, Apr 10, 2019 at 2:33 PM Ole Troan  wrote:
> Hi Shahid,
> 
> What are you trying to achieve?
> https://wiki.fd.io/view/VPP/NAT#Enable_or_disable_forwarding
> 
> You do not typically enable the “forwarding” feature.
> 
> Cheers,
> Ole
> 
> > On 8 Apr 2019, at 07:52, Shahid Khan  wrote:
> > 
> > can someone look into below query ?
> > 
> > -Shahid.
> > 
> > On Wed, Apr 3, 2019 at 12:56 PM Shahid Khan via Lists.Fd.Io 
> >  wrote:
> > Hi,
> > 
> > can someone help us on below query ?
> > 
> > -Shahid.
> > 
> > On Mon, Apr 1, 2019 at 11:45 AM Shahid Khan via Lists.Fd.Io 
> >  wrote:
> > 
> > I have following query related to SNAT on VPP Release 19.0.1.02
> > 
> > following is the code from vpp/src/plugins/nat/in2out.c
> > 
> > static inline int
> > snat_not_translate (snat_main_t * sm, vlib_node_runtime_t * node,
> > u32 sw_if_index0, ip4_header_t * ip0, u32 proto0,
> > u32 rx_fib_index0, u32 thread_index)
> > {
> >   udp_header_t *udp0 = ip4_next_header (ip0);
> >   snat_session_key_t key0, sm0;
> >   clib_bihash_kv_8_8_t kv0, value0;
> > 
> >   key0.addr = ip0->dst_address;
> >   key0.port = udp0->dst_port;
> >   key0.protocol = proto0;
> >   key0.fib_index = sm->outside_fib_index;
> >   kv0.key = key0.as_u64;
> > 
> >   /* NAT packet aimed at external address if */
> >   /* has active sessions */
> >   if (clib_bihash_search_8_8 (&sm->per_thread_data[thread_index].out2in, 
> > &kv0,
> >   &value0))
> > {
> >   /* or is static mappings */
> >   if (!snat_static_mapping_match (sm, key0, &sm0, 1, 0, 0, 0, 0, 0))
> > return 0;
> > }
> >   else
> > return 0;
> > 
> >   if (sm->forwarding_enabled)
> > return 1;
> > 
> > 
> >   return snat_not_translate_fast (sm, node, sw_if_index0, ip0, proto0,
> >   rx_fib_index0);
> > }
> > 
> > want to understand why above highlighted condition is there in code ?
> > 
> > this  is causing SNAT to stop working the moment we enable forwarding.
> > what will be impact we comment this condition ?
> > 
> > -Shahid.
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > -=-=-=-=-=-=-=-=-=-=-=-
> > Links: You receive all messages sent to this group.
> > 
> > View/Reply Online (#12680): https://lists.fd.io/g/vpp-dev/message/12680
> > Mute This Topic: https://lists.fd.io/mt/30851776/1713129
> > Group Owner: vpp-dev+ow...@lists.fd.io
> > Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub  
> > [shahidnasimk...@gmail.com]
> > -=-=-=-=-=-=-=-=-=-=-=-
> > -=-=-=-=-=-=-=-=-=-=-=-
> > Links: You receive all messages sent to this group.
> > 
> > View/Reply Online (#12691): https://lists.fd.io/g/vpp-dev/message/12691
> > Mute This Topic: https://lists.fd.io/mt/30851776/1713129
> > Group Owner: vpp-dev+ow...@lists.fd.io
> > Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub  
> > [shahidnasimk...@gmail.com]
> > -=-=-=-=-=-=-=-=-=-=-=-
> > -=-=-=-=-=-=-=-=-=-=-=-
> > Links: You receive all messages sent to this group.
> > 
> > View/Reply Online (#12723): https://lists.fd.io/g/vpp-dev/message/12723
> > Mute This Topic: https://lists.fd.io/mt/30851776/675193
> > Group Owner: vpp-dev+ow...@lists.fd.io
> > Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub  [otr...@employees.org]
> > -=-=-=-=-=-=-=-=-=-=-=-
> 
> -=-=-=-=-=-=-=-=-=-=-=-
> Links: You receive all messages sent to this group.
> 
> View/Reply Online (#12743): https://lists.fd.io/g/vpp-dev/message/12743
> Mute This Topic: https://lists.fd.io/mt/30851776/675193
> Group Owner: vpp-dev+ow...@lists.fd.io
> Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub  [otr...@employees.org]
> -=-=-=-=-=-=-=-=-=-=-=-

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