date:20170111

Re: [vpp-dev] pkg-config

2017-01-11 Thread Damjan Marion (damarion)


Hi Patrick,

Thanks for stepping out. Here is one example:

git://libvirt.org/libvirt.git

There are 3 *.pc.in files int the toplevel dir.

Thanks,

Damjan

> On 11 Jan 2017, at 17:59, Lu, Patrick  wrote:
> 
> Hi Damjan,
> 
> I will take a look. I was trying out developing a new plugin and wish to have 
> this exact feature. 
> 
> Do you have some good example to start?
> 
> Thanks,
> 
> Patrick
> 
> Sent from my iPhone
> 
>> On Jan 11, 2017, at 09:49, Damjan Marion (damarion)  
>> wrote:
>> 
>> 
>> I think it will be nice to have pkg-config (vpp.pc) file in vpp-dev repo, so 
>> external plugin developer 
>> can use it for passing proper parameters to configure/make, same like other 
>> proper development packages do.
>> 
>> Does anybody have few free cycles and interest to crank it up?
>> 
>> Thanks,
>> 
>> Damjan
>> ___
>> vpp-dev mailing list
>> vpp-dev@lists.fd.io
>> https://lists.fd.io/mailman/listinfo/vpp-dev

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

Re: [vpp-dev] VPP Build Bombing Out on libsvm.la?

2017-01-11 Thread Burt Silverman

I don't have a great answer, but this is something I would try.

If you have a clean git repository, with no local uncommitted modifications
(if you have any, then stash them so they won't be lost), I would try from
the top of the tree:

$ rm -rf *  #make sure you do not use .*

$ git checkout .

Now try your entire build sequence again.

The reasoning is: if you checkout an older level AND build AND then switch
to master, sometimes some crud is left around. Although one would expect
that crud to be harmless, it cannot hurt for you to do an extra check. More
sophisticated debugging can be done if the problem does not get solved this
simple(ton) way.

Burt

On Wed, Jan 11, 2017 at 4:59 PM, Jon Loeliger  wrote:

> Folks,
>
> I'm staring at some VPP builds on a fresh CentOS system.
> I've installed all the "install-deps", and get pretty far into the
> build before it wedges.  I see warnings like this:
>
>  /bin/sh ./libtool   --mode=install /usr/bin/install -c   libsvm.la
> libsvmdb.la libvlib.la libvlibapi.la libvlibmemory.la
> libvlibmemoryclient.la libvlibsocket.la libvatplugin.la
> '/home/jdl/ngr-rpms/build_root/BUILD/vpp/build-root/
> install-vpp-native/vpp/lib64'
> PLUGIN CFG vpp_plugin_configure
> libtool: install: warning: relinking `libsvm.la'
>
> I don't know if that is important misbehavior or normal behavior.
>
> Ultimately, most of the builds quit grousing about a missing libvppinfra:
>
> /usr/bin/ld: cannot find -lvppinfra
> collect2: error: ld returned 1 exit status
> libtool: install: error: relink `libsvm.la' with the above command before
> installing it
> make[6]: *** [install-libLTLIBRARIES] Error 1
> make[6]: *** Waiting for unfinished jobs
>
> Not sure which real target issued that loveliness due to some "make -j"
> parallelism in the mix.  Might be the relinking of libvnet.la.
>
> I am able to build VPP on an entirely different system though.
> So it seems like there is some variability in its success rate.
>
> Is it possible that there is a missing dependency and the "-j" is
> effectively causing it to want libvppinfra before it is available?
>
> Ideas or suggestions?
>
> Thanks,
> jdl
>
>
> ___
> vpp-dev mailing list
> vpp-dev@lists.fd.io
> https://lists.fd.io/mailman/listinfo/vpp-dev
>
___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev

Re: [vpp-dev] VPP-556 - vpp crashing in an openstack odl stack

2017-01-11 Thread Dave Barach (dbarach)

+1... Hey John, thanks a lot for the detailed analysis...

Dave

From: John Lo (loj)
Sent: Wednesday, January 11, 2017 5:40 PM
To: Dave Barach (dbarach) ; Juraj Linkes -X (jlinkes - 
PANTHEON TECHNOLOGIES at Cisco) ; vpp-dev@lists.fd.io
Subject: RE: VPP-556 - vpp crashing in an openstack odl stack

Hi Juraj,

I looked at the custom-dump of the API trace and noticed this "interesting" 
sequence:
SCRIPT: vxlan_add_del_tunnel src 192.168.11.22 dst 192.168.11.20 decap-next -1 
vni 1
SCRIPT: sw_interface_set_flags sw_if_index 4 admin-up link-up
SCRIPT: sw_interface_set_l2_bridge sw_if_index 4 bd_id 1 shg 1  enable
SCRIPT: sw_interface_set_l2_bridge sw_if_index 2 disable
SCRIPT: bridge_domain_add_del bd_id 1 del

Any idea why BD1 is deleted while the VXLAN tunnel with sw_if_index still in 
the BD? May be this is what is  causing the crash. From your vppctl output 
capture for "compute_that_crashed.txt", I do see BD 1 presen with vxlan_tunnel0 
on it:
[root@overcloud-novacompute-1 ~]# vppctl show bridge-domain
  ID   Index   Learning   U-Forwrd   UU-Flood   Flooding   ARP-Term BVI-Intf
  0  0offoffoffoffofflocal0
  1  1on on on on off  N/A
[root@overcloud-novacompute-1 ~]# vppctl show bridge-domain 1 detail
  ID   Index   Learning   U-Forwrd   UU-Flood   Flooding   ARP-Term BVI-Intf
  1  1on on on on off  N/A

   Interface   Index  SHG  BVI  TxFloodVLAN-Tag-Rewrite
 vxlan_tunnel0   3 1-  * none

I did install a vpp 1701 image on my server and performed an api trace replay 
of your api_post_mortem. Thereafter, I do not see BD 1 present while 
vxlan_tunnel1 is still configured as in BD 1:
DBGvpp# show bridge
  ID   Index   Learning   U-Forwrd   UU-Flood   Flooding   ARP-Term BVI-Intf
  0  0offoffoffoffofflocal0
DBGvpp# sho vxlan tunnel
[1] src 192.168.11.22 dst 192.168.11.20 vni 1 sw_if_index 4 encap_fib_index 0 
fib_entry_index 12 decap_next l2
DBGvpp# sho int addr
GigabitEthernet2/3/0 (dn):
VirtualEthernet0/0/0 (up):
local0 (dn):
vxlan_tunnel0 (dn):
vxlan_tunnel1 (up):
  l2 bridge bd_id 1 shg 1
DBGvpp# show int
  Name   Idx   State  Counter  Count
GigabitEthernet2/3/0  1down
VirtualEthernet0/0/0  2 up
local00down
vxlan_tunnel0 3down
vxlan_tunnel1 4 up
DBGvpp#

With system in this state, I can easily imaging a packet received by 
vxlan_tunnel1 and forwarded in a non-existing BD causes VPP crash. I will look 
into VPP code from this angle. In general, however, there is really no need to 
create and delete BDs on VPP. Adding an interface/tunnel to a BD will cause it 
to be created. Deleting a BD without removing all the ports in it can cause 
problems which may well be the cause here. If a BD is to be not used, all the 
ports on it should be removed. If a BD is to be reused, just add ports to it.

As mentioned by Dave, please test using a known good image like 1701 and 
preferably built with debug enabled (with TAG-vpp_debug) so it is easier to 
find any issues.

Regards,
John

From: Dave Barach (dbarach)
Sent: Wednesday, January 11, 2017 9:01 AM
To: Juraj Linkes -X (jlinkes - PANTHEON TECHNOLOGIES at Cisco) 
>; 
vpp-dev@lists.fd.io; John Lo (loj) 
>
Subject: RE: VPP-556 - vpp crashing in an openstack odl stack

Dear Juraj,

I took a look. It appears that the last operation in the post-mortem API trace 
was to kill a vxlan tunnel. Is there a reasonable chance that other interfaces 
in the bridge group containing the tunnel were still admin-up? Was the tunnel 
interface removed from the bridge group prior to killing it?

The image involved is not stable/1701/LATEST. It's missing at least 20 fixes 
considered critical enough to justify merging them into the release throttle:

[root@overcloud-novacompute-1 ~]# vppctl show version verbose
Version:  v17.01-rc0~242-gabd98b2~b1576
Compiled by:  jenkins
Compile host: centos-7-a8b
Compile date: Mon Dec 12 18:55:56 UTC 2016

Please re-test with stable/1701/LATEST. Please use a TAG=vpp_debug image. If 
the problem is reproducible, we'll need a core file to make further progress.

Copying John Lo ("Dr. Vxlan") for any further thoughts he might have...

Thanks... Dave

From: vpp-dev-boun...@lists.fd.io 
[mailto:vpp-dev-boun...@lists.fd.io] On Behalf Of Juraj Linkes -X (jlinkes - 
PANTHEON TECHNOLOGIES at Cisco)
Sent: Wednesday, January 11, 2017 3:47 AM
To:

Re: [vpp-dev] VPP-556 - vpp crashing in an openstack odl stack

2017-01-11 Thread John Lo (loj)

Hi Juraj,

I looked at the custom-dump of the API trace and noticed this "interesting" 
sequence:
SCRIPT: vxlan_add_del_tunnel src 192.168.11.22 dst 192.168.11.20 decap-next -1 
vni 1
SCRIPT: sw_interface_set_flags sw_if_index 4 admin-up link-up
SCRIPT: sw_interface_set_l2_bridge sw_if_index 4 bd_id 1 shg 1  enable
SCRIPT: sw_interface_set_l2_bridge sw_if_index 2 disable
SCRIPT: bridge_domain_add_del bd_id 1 del

Any idea why BD1 is deleted while the VXLAN tunnel with sw_if_index still in 
the BD? May be this is what is  causing the crash. From your vppctl output 
capture for "compute_that_crashed.txt", I do see BD 1 presen with vxlan_tunnel0 
on it:
[root@overcloud-novacompute-1 ~]# vppctl show bridge-domain
  ID   Index   Learning   U-Forwrd   UU-Flood   Flooding   ARP-Term BVI-Intf
  0  0offoffoffoffofflocal0
  1  1on on on on off  N/A
[root@overcloud-novacompute-1 ~]# vppctl show bridge-domain 1 detail
  ID   Index   Learning   U-Forwrd   UU-Flood   Flooding   ARP-Term BVI-Intf
  1  1on on on on off  N/A

   Interface   Index  SHG  BVI  TxFloodVLAN-Tag-Rewrite
 vxlan_tunnel0   3 1-  * none

I did install a vpp 1701 image on my server and performed an api trace replay 
of your api_post_mortem. Thereafter, I do not see BD 1 present while 
vxlan_tunnel1 is still configured as in BD 1:
DBGvpp# show bridge
  ID   Index   Learning   U-Forwrd   UU-Flood   Flooding   ARP-Term BVI-Intf
  0  0offoffoffoffofflocal0
DBGvpp# sho vxlan tunnel
[1] src 192.168.11.22 dst 192.168.11.20 vni 1 sw_if_index 4 encap_fib_index 0 
fib_entry_index 12 decap_next l2
DBGvpp# sho int addr
GigabitEthernet2/3/0 (dn):
VirtualEthernet0/0/0 (up):
local0 (dn):
vxlan_tunnel0 (dn):
vxlan_tunnel1 (up):
  l2 bridge bd_id 1 shg 1
DBGvpp# show int
  Name   Idx   State  Counter  Count
GigabitEthernet2/3/0  1down
VirtualEthernet0/0/0  2 up
local00down
vxlan_tunnel0 3down
vxlan_tunnel1 4 up
DBGvpp#

With system in this state, I can easily imaging a packet received by 
vxlan_tunnel1 and forwarded in a non-existing BD causes VPP crash. I will look 
into VPP code from this angle. In general, however, there is really no need to 
create and delete BDs on VPP. Adding an interface/tunnel to a BD will cause it 
to be created. Deleting a BD without removing all the ports in it can cause 
problems which may well be the cause here. If a BD is to be not used, all the 
ports on it should be removed. If a BD is to be reused, just add ports to it.

As mentioned by Dave, please test using a known good image like 1701 and 
preferably built with debug enabled (with TAG-vpp_debug) so it is easier to 
find any issues.

Regards,
John

From: Dave Barach (dbarach)
Sent: Wednesday, January 11, 2017 9:01 AM
To: Juraj Linkes -X (jlinkes - PANTHEON TECHNOLOGIES at Cisco) 
; vpp-dev@lists.fd.io; John Lo (loj) 
Subject: RE: VPP-556 - vpp crashing in an openstack odl stack

Dear Juraj,

I took a look. It appears that the last operation in the post-mortem API trace 
was to kill a vxlan tunnel. Is there a reasonable chance that other interfaces 
in the bridge group containing the tunnel were still admin-up? Was the tunnel 
interface removed from the bridge group prior to killing it?

The image involved is not stable/1701/LATEST. It's missing at least 20 fixes 
considered critical enough to justify merging them into the release throttle:

[root@overcloud-novacompute-1 ~]# vppctl show version verbose
Version:  v17.01-rc0~242-gabd98b2~b1576
Compiled by:  jenkins
Compile host: centos-7-a8b
Compile date: Mon Dec 12 18:55:56 UTC 2016

Please re-test with stable/1701/LATEST. Please use a TAG=vpp_debug image. If 
the problem is reproducible, we'll need a core file to make further progress.

Copying John Lo ("Dr. Vxlan") for any further thoughts he might have...

Thanks... Dave

From: vpp-dev-boun...@lists.fd.io 
[mailto:vpp-dev-boun...@lists.fd.io] On Behalf Of Juraj Linkes -X (jlinkes - 
PANTHEON TECHNOLOGIES at Cisco)
Sent: Wednesday, January 11, 2017 3:47 AM
To: vpp-dev@lists.fd.io
Subject: [vpp-dev] VPP-556 - vpp crashing in an openstack odl stack

Hi vpp-dev,

I just wanted to ask whether anyone has taken a look at 
VPP-556? There might not be enough logs, I 
collected just backtrace from gdb - if we need anything more, please give me a 
little bit of a guidance on what could help/how to get it.

This is one the last few issues we're facing

[vpp-dev] VPP Build Bombing Out on libsvm.la?

2017-01-11 Thread Jon Loeliger

Folks,

I'm staring at some VPP builds on a fresh CentOS system.
I've installed all the "install-deps", and get pretty far into the
build before it wedges.  I see warnings like this:

 /bin/sh ./libtool   --mode=install /usr/bin/install -c   libsvm.la
libsvmdb.la libvlib.la libvlibapi.la libvlibmemory.la libvlibmemoryclient.la
libvlibsocket.la libvatplugin.la
'/home/jdl/ngr-rpms/build_root/BUILD/vpp/build-root/install-vpp-native/vpp/lib64'
PLUGIN CFG vpp_plugin_configure
libtool: install: warning: relinking `libsvm.la'

I don't know if that is important misbehavior or normal behavior.

Ultimately, most of the builds quit grousing about a missing libvppinfra:

/usr/bin/ld: cannot find -lvppinfra
collect2: error: ld returned 1 exit status
libtool: install: error: relink `libsvm.la' with the above command before
installing it
make[6]: *** [install-libLTLIBRARIES] Error 1
make[6]: *** Waiting for unfinished jobs

Not sure which real target issued that loveliness due to some "make -j"
parallelism in the mix.  Might be the relinking of libvnet.la.

I am able to build VPP on an entirely different system though.
So it seems like there is some variability in its success rate.

Is it possible that there is a missing dependency and the "-j" is
effectively causing it to want libvppinfra before it is available?

Ideas or suggestions?

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

Re: [vpp-dev] pkg-config

2017-01-11 Thread Lu, Patrick

Hi Damjan,

I will take a look. I was trying out developing a new plugin and wish to have 
this exact feature. 

Do you have some good example to start?

Thanks,

Patrick

Sent from my iPhone

> On Jan 11, 2017, at 09:49, Damjan Marion (damarion)  
> wrote:
> 
> 
> I think it will be nice to have pkg-config (vpp.pc) file in vpp-dev repo, so 
> external plugin developer 
> can use it for passing proper parameters to configure/make, same like other 
> proper development packages do.
> 
> Does anybody have few free cycles and interest to crank it up?
> 
> Thanks,
> 
> Damjan
> ___
> vpp-dev mailing list
> vpp-dev@lists.fd.io
> https://lists.fd.io/mailman/listinfo/vpp-dev
___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev

[vpp-dev] pkg-config

2017-01-11 Thread Damjan Marion (damarion)


I think it will be nice to have pkg-config (vpp.pc) file in vpp-dev repo, so 
external plugin developer 
can use it for passing proper parameters to configure/make, same like other 
proper development packages do.

Does anybody have few free cycles and interest to crank it up?

Thanks,

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

Re: [vpp-dev] Get IPv6 neighbors MACs

2017-01-11 Thread Neale Ranns (nranns)


Hi Dmitry,

Please try this with 17.01 as the behaviour has changed for cross VRF scenarios 
like this.
Also a diagram, even if it’s just a photo of a white board, will help 
significantly.

Thanks,
neale

From: Dmitry Bufistov 
Date: Wednesday, 11 January 2017 at 15:10
To: "Neale Ranns (nranns)" 
Cc: vpp-dev 
Subject: Re: [vpp-dev] Get IPv6 neighbors MACs

Hi Neale,

Your understanding is correct. However I don't see any collision here.
There is following route in VRF1:

vpp# ip route table 1 add ::/64 via 2001::2 Q

when packet hits this rule it will be sent via device Q, right?
The problem is that first the MAC address of 2001::2 should be obtained and VPP 
sends neighbour discovery request. When the response arrives VPP assumes it is 
for device P, since it has the same MAC address.

If I add MAC address of the next hop for device Q:

vpp# set ip6 neighbor Q 2001::2 76:5c:87:1a:09:eb

egress packets are correctly sent via interface Q. Remember, that interface Q 
cannot receive any ingress packet from external world. So my problem is to 
obtain the MAC address for set ip6 neighbour command.
Thank you very much for your help!

Dmitry

On Tue, Jan 10, 2017 at 5:56 PM, Neale Ranns (nranns) 
> wrote:

Hi Dmitry,

IIUC you have two devices with identical IPv6 addresses, which we’ll call P and 
Q, connected on two different interfaces. These interfaces are in different 
VRFs so the addresses do not collide.

Now if we succeed in importing the discovered neighbours from VRF 0 to VRF 1, 
these addresses will now collide. Put another way, if a packet arrives in VRF 1 
destined to 2001::2 which device, P or Q, do you want to send it to?

Regards,
neale

From: > on 
behalf of Dmitry Bufistov >
Date: Tuesday, 10 January 2017 at 15:39
To: vpp-dev >
Subject: [vpp-dev] Get IPv6 neighbors MACs

Hi list,

I ended up with a weired VPP configuration:

there are two host interfaces in VPP: A and B. They both have identical MAC and 
IP addresses. The IP address of B is on VRF 1.
Only interface A can get traffic from "real world", and it have one valid entry 
in its neighbour table:
DBGvpp# sh ip6 neighbors
Time   Address   Flags Link layer 
Interface
 40.7989   2001::2 G00:00:00:00:00:00   B
106.3092   2001::2  76:5c:87:1a:09:ebA

Now, from external application I would like to figure out the MACs of 
neighbours of interface A  and add corresponding neighbours for interface B. 
Basically: copy neighbours table of A to the neighbours table of B. It should 
be preferably done via java binding VPP API (JVPP).

VPP is good ad discovering neighbours so I believe there should be simple 
solution for my problem. There is JVPP ipNeighborAddDel() call that adds 
neighbour for given interface, but there is nothing I can find to query 
neighbours.

Could please somebody point out if there is a simple way to achieve what I want?

Thank you a lot in advance for any help,

Dmitry


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

Re: [vpp-dev] Get IPv6 neighbors MACs

2017-01-11 Thread Dmitry Bufistov

Hi Neale,

Your understanding is correct. However I don't see any collision here.
There is following route in VRF1:

vpp# ip route table 1 add ::/64 via 2001::2 Q

when packet hits this rule it will be sent via device Q, right?
The problem is that first the MAC address of 2001::2 should be obtained and
VPP sends neighbour discovery request. When the response arrives VPP
assumes it is for device P, since it has the same MAC address.

If I add MAC address of the next hop for device Q:

vpp# set ip6 neighbor Q 2001::2 76:5c:87:1a:09:eb

egress packets are correctly sent via interface Q. Remember, that
interface Q cannot receive any ingress packet from external world. So
my problem is to obtain the MAC address for set ip6 neighbour command.

Thank you very much for your help!

Dmitry

On Tue, Jan 10, 2017 at 5:56 PM, Neale Ranns (nranns) 
wrote:

>
>
> Hi Dmitry,
>
>
>
> IIUC you have two devices with identical IPv6 addresses, which we’ll call
> P and Q, connected on two different interfaces. These interfaces are in
> different VRFs so the addresses do not collide.
>
>
>
> Now if we succeed in importing the discovered neighbours from VRF 0 to VRF
> 1, these addresses will now collide. Put another way, if a packet arrives
> in VRF 1 destined to 2001::2 which device, P or Q, do you want to send it
> to?
>
>
>
> Regards,
>
> neale
>
>
>
> *From: * on behalf of Dmitry Bufistov <
> dmi...@midokura.com>
> *Date: *Tuesday, 10 January 2017 at 15:39
> *To: *vpp-dev 
> *Subject: *[vpp-dev] Get IPv6 neighbors MACs
>
>
>
> Hi list,
>
>
>
> I ended up with a weired VPP configuration:
>
>
>
> there are two host interfaces in VPP: A and B. They both have identical
> MAC and IP addresses. The IP address of B is on VRF 1.
>
> Only interface A can get traffic from "real world", and it have one valid
> entry in its neighbour table:
>
> DBGvpp# sh ip6 neighbors
>
> Time   Address   Flags Link layer
> Interface
>
>  40.7989   2001::2 G00:00:00:00:00:00   B
>
> 106.3092   2001::2  76:5c:87:1a:09:ebA
>
>
>
> Now, from external application I would like to figure out the MACs of
> neighbours of interface A  and add corresponding neighbours for interface
> B. Basically: copy neighbours table of A to the neighbours table of B. It
> should be preferably done via java binding VPP API (JVPP).
>
>
>
> VPP is good ad discovering neighbours so I believe there should be simple
> solution for my problem. There is JVPP ipNeighborAddDel() call that adds 
> neighbour
> for given interface, but there is nothing I can find to query neighbours.
>
>
>
> Could please somebody point out if there is a simple way to achieve what I
> want?
>
>
>
> Thank you a lot in advance for any help,
>
>
>
> Dmitry
>
>
>
>
___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev

Re: [vpp-dev] VPP-556 - vpp crashing in an openstack odl stack

2017-01-11 Thread Dave Barach (dbarach)

Dear Juraj,

I took a look. It appears that the last operation in the post-mortem API trace 
was to kill a vxlan tunnel. Is there a reasonable chance that other interfaces 
in the bridge group containing the tunnel were still admin-up? Was the tunnel 
interface removed from the bridge group prior to killing it?

The image involved is not stable/1701/LATEST. It's missing at least 20 fixes 
considered critical enough to justify merging them into the release throttle:

[root@overcloud-novacompute-1 ~]# vppctl show version verbose
Version:  v17.01-rc0~242-gabd98b2~b1576
Compiled by:  jenkins
Compile host: centos-7-a8b
Compile date: Mon Dec 12 18:55:56 UTC 2016

Please re-test with stable/1701/LATEST. Please use a TAG=vpp_debug image. If 
the problem is reproducible, we'll need a core file to make further progress.

Copying John Lo ("Dr. Vxlan") for any further thoughts he might have...

Thanks... Dave

From: vpp-dev-boun...@lists.fd.io [mailto:vpp-dev-boun...@lists.fd.io] On 
Behalf Of Juraj Linkes -X (jlinkes - PANTHEON TECHNOLOGIES at Cisco)
Sent: Wednesday, January 11, 2017 3:47 AM
To: vpp-dev@lists.fd.io
Subject: [vpp-dev] VPP-556 - vpp crashing in an openstack odl stack

Hi vpp-dev,

I just wanted to ask whether anyone has taken a look at 
VPP-556? There might not be enough logs, I 
collected just backtrace from gdb - if we need anything more, please give me a 
little bit of a guidance on what could help/how to get it.

This is one the last few issues we're facing with the openstack odl scenario 
where we use vpp jsut for l2 and it's been there for a while.

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

Re: [vpp-dev] how to setup topology to test lb plugin?

2017-01-11 Thread Pierre Pfister (ppfister)



Le 11 janv. 2017 à 14:42, 黄登辉 
> a écrit :

Yes, I read the doc and maglev, one question , do we need to create two 
interfaces? One is for VIP , the other is for communicating as?

No. It's all encap/decap. So it should work with a single interface.

- Pierre



发自网易邮箱手机版


在2017年01月11日 20:16 ，Pierre Pfister (ppfister)写道：

Hello,

Are you familiar with MagLev ?
Did you take a look at 
https://git.fd.io/vpp/tree/src/plugins/lb/lb_plugin_doc.md ?

Cheers,

- Pierre

Le 11 janv. 2017 à 12:52, 黄登辉 
> a écrit :

Hi  all
 There is lb plugin available in vpp. I want to test it, could you please 
to tell me how to setup topology for testing?


发自网易邮箱手机版
___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev


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

[vpp-dev] 回复: Re: how to setup topology to test lb plugin?

2017-01-11 Thread 黄登辉

Yes, I read the doc and maglev, one question , do we need to create two 
interfaces? One is for VIP , the other is for communicating as?


发自网易邮箱手机版



在2017年01月11日 20:16 ，Pierre Pfister (ppfister)写道：


Hello,


Are you familiar with MagLev ?
Did you take a look at 
https://git.fd.io/vpp/tree/src/plugins/lb/lb_plugin_doc.md ?


Cheers,


- Pierre


Le 11 janv. 2017 à 12:52, 黄登辉  a écrit :


Hi  all
 There is lb plugin available in vpp. I want to test it, could you please 
to tell me how to setup topology for testing?


发自网易邮箱手机版
___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev

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

[vpp-dev] VPP-556 - vpp crashing in an openstack odl stack

2017-01-11 Thread Juraj Linkes -X (jlinkes - PANTHEON TECHNOLOGIES at Cisco)

Hi vpp-dev,

I just wanted to ask whether anyone has taken a look at 
VPP-556? There might not be enough logs, I 
collected just backtrace from gdb - if we need anything more, please give me a 
little bit of a guidance on what could help/how to get it.

This is one the last few issues we're facing with the openstack odl scenario 
where we use vpp jsut for l2 and it's been there for a while.

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

Re: [vpp-dev] how to setup topology to test lb plugin?

2017-01-11 Thread Pierre Pfister (ppfister)

Hello,

Are you familiar with MagLev ?
Did you take a look at 
https://git.fd.io/vpp/tree/src/plugins/lb/lb_plugin_doc.md ?

Cheers,

- Pierre

Le 11 janv. 2017 à 12:52, 黄登辉 
> a écrit :

Hi  all
 There is lb plugin available in vpp. I want to test it, could you please 
to tell me how to setup topology for testing?


发自网易邮箱手机版
___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev

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

[vpp-dev] how to setup topology to test lb plugin?

2017-01-11 Thread 黄登辉

Hi  all
 There is lb plugin available in vpp. I want to test it, could you please 
to tell me how to setup topology for testing?


发自网易邮箱手机版___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev

Re: [vpp-dev] pkg-config

Re: [vpp-dev] VPP Build Bombing Out on libsvm.la?

Re: [vpp-dev] VPP-556 - vpp crashing in an openstack odl stack

Re: [vpp-dev] VPP-556 - vpp crashing in an openstack odl stack

[vpp-dev] VPP Build Bombing Out on libsvm.la?

Re: [vpp-dev] pkg-config

[vpp-dev] pkg-config

Re: [vpp-dev] Get IPv6 neighbors MACs

Re: [vpp-dev] Get IPv6 neighbors MACs

Re: [vpp-dev] VPP-556 - vpp crashing in an openstack odl stack

Re: [vpp-dev] how to setup topology to test lb plugin?

[vpp-dev] 回复: Re: how to setup topology to test lb plugin?

[vpp-dev] VPP-556 - vpp crashing in an openstack odl stack

Re: [vpp-dev] how to setup topology to test lb plugin?

[vpp-dev] how to setup topology to test lb plugin?

15 matches

Site Navigation

Mail list logo

Footer information