Juniper Openstack

[3.0.1.0-24~liberty] Route to the dest VM not seen in the intermediate VRF of a Multi-inline Service Chain with 3 transparent SIs

Bug #1565730 reported by Ganesha HV
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Juniper Openstack
Status tracked in Trunk
R3.0
Fix Committed
High
Ignatious Johnson Christopher
Juniper Openstack r3.0.2.0
Trunk
Fix Committed
High
Ignatious Johnson Christopher
Juniper Openstack r3.1.0.0-fcs

Bug Description

Setup
=====
Config Nodes : [u'nodec21', u'nodec20']
Control Nodes : [u'nodec21', u'nodec20']
Compute Nodes : [u'nodec61', u'nodec60', u'nodec18']
Openstack Node : nodec19
WebUI Node : nodec20
Analytics Nodes : [u'nodec21', u'nodec20']
Physical Devices : [u"'blr-mx2'"]

1]. Created a Multi-Inline Service Chain with 3 Transparent SIs between vn1 and vn2.

vm1(79.34.192.3)<----si1---><----s2---><---s3--->vm2(203.254.110.3)

2]. Ping to vm2 from vn1 is failing as the route to vm2 is not found in the intermediate vrf(right-vn_si2)

The setup is as is

To repro
========
Run the following sanity script:

root@nodec21:~/contrail-test# python -m testtools.run scripts.svc_firewall.test_svc_fw.TestSvcRegr.test_svc_transparent_with_3_instance

Ganesha HV (ganeshahv)
Changed in juniperopenstack:
milestone: r3.0.1.0 → none
Revision history for this message
OpenContrail Admin (ci-admin-f) wrote : [Review update] master

Review in progress for https://review.opencontrail.org/19078
Submitter: Ignatious Johnson Christopher (<email address hidden>)

Revision history for this message
OpenContrail Admin (ci-admin-f) wrote : [Review update] R3.0

Review in progress for https://review.opencontrail.org/19083
Submitter: Ignatious Johnson Christopher (<email address hidden>)

Nischal Sheth (nsheth)
information type: Proprietary → Public
Revision history for this message
OpenContrail Admin (ci-admin-f) wrote : A change has been merged

Reviewed: https://review.opencontrail.org/19083
Committed: http://github.org/Juniper/contrail-controller/commit/779421e48147442a97e9e51d76c803f52834dd88
Submitter: Zuul
Branch: R3.0

commit 779421e48147442a97e9e51d76c803f52834dd88
Author: Ignatious Johnson Christopher <email address hidden>
Date: Tue Apr 5 22:21:01 2016 +0000

When ip_alloc request lands in different api servers the bitarray local to the
api-server wont have marked the ip is used, However the other api-server might
have allocated the ip and locked it in zookeeper with id "user-opaque-alloc".
So this api-server assumes that the ip is not allocated and try to create a lock
with same id "user-opaque-alloc", zookeeper respoonds with the last allocated ip
as the id(user-opaque-alloc) is same.

Fix is to use unique id for every ip allocation.

Change-Id: I2afdca95a1f8f46e584c8497c806d75a14acfe86
Closes-bug: 1565730

Revision history for this message
OpenContrail Admin (ci-admin-f) wrote :

Reviewed: https://review.opencontrail.org/19078
Committed: http://github.org/Juniper/contrail-controller/commit/bdead2d55e79e1c333ff9c823946e2673d1e2988
Submitter: Zuul
Branch: master

commit bdead2d55e79e1c333ff9c823946e2673d1e2988
Author: Ignatious Johnson Christopher <email address hidden>
Date: Tue Apr 5 04:36:39 2016 +0000

When ip_alloc request lands in different api servers the bitarray local to the
api-server wont have marked the ip is used, However the other api-server might
have allocated the ip and locked it in zookeeper with id "user-opaque-alloc".
So this api-server assumes that the ip is not allocated and try to create a lock
with same id "user-opaque-alloc" to get the last allocated ip as response from
zookeeper as the id(user-opaque-alloc) is same.

Fix is to use unique id for every ip allocation.

Change-Id: I08c368e88e136e9e52db135f9ca76e000497c22c
Closes-bug: 1565730

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.
Subscribing...

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.