Juniper Openstack

lbaas: R2.20 build 34, not able to connect to VIP ip

Bug #1460767 reported by Shweta Naik
16
This bug affects 3 people
Affects Status Importance Assigned to Milestone
Juniper Openstack
Status tracked in Trunk
R2.1
Fix Committed
Critical
Divakar Dharanalakota
Juniper Openstack r2.11 "r2.11"
R2.20
Fix Committed
Critical
Divakar Dharanalakota
Juniper Openstack r2.20-fcs
Trunk
Fix Committed
Critical
Divakar Dharanalakota
Juniper Openstack r3.0-fcs

Bug Description

R2.20 build 34 ubuntu14.04/icehouse

I have a 4 node setup with 2 computes.

root@a5s193:~/contrail-test# neutron lb-vip-list
+--------------------------------------+-------+----------+----------+----------------+--------+
| id | name | address | protocol | admin_state_up | status |
+--------------------------------------+-------+----------+----------+----------------+--------+
| 84a891c0-add6-4fda-995a-b3a2e06232a7 | myvip | 20.1.1.3 | HTTP | True | ACTIVE |
+--------------------------------------+-------+----------+----------+----------------+————+

root@a5s193:~/contrail-test# neutron lb-vip-show myvip
+---------------------+--------------------------------------+
| Field | Value |
+---------------------+--------------------------------------+
| address | 20.1.1.3 |
| admin_state_up | True |
| connection_limit | -1 |
| description | |
| id | 84a891c0-add6-4fda-995a-b3a2e06232a7 |
| name | myvip |
| pool_id | a800b06e-765d-4c44-b1ab-f15de3cff32c |
| port_id | 9f0de510-09b0-4201-9c28-0c60a8efcd68 |
| protocol | HTTP |
| protocol_port | 80 |
| session_persistence | |
| status | ACTIVE |
| subnet_id | 33a57586-7bc2-4649-ab3c-77c52a52768a |
| tenant_id | 2be3bbed185d47719cd99adb3f59183b |
+---------------------+———————————————————+

root@a5s193:~/contrail-test# neutron lb-pool-show mypool
+------------------------+--------------------------------------+
| Field | Value |
+------------------------+--------------------------------------+
| admin_state_up | True |
| description | |
| health_monitors | |
| health_monitors_status | |
| id | a800b06e-765d-4c44-b1ab-f15de3cff32c |
| lb_method | ROUND_ROBIN |
| members | 9f13ecdd-a999-4435-a1a0-d9b30d9f9f73 |
| name | mypool |
| protocol | HTTP |
| provider | opencontrail |
| status | ACTIVE |
| subnet_id | a79a609b-0635-46d5-8772-b824171b29b5 |
| tenant_id | 2be3bbed185d47719cd99adb3f59183b |
| vip_id | 84a891c0-add6-4fda-995a-b3a2e06232a7 |
+------------------------+--------------------------------------+

root@a5s193:~/contrail-test# nova list
+--------------------------------------+------+--------+------------+-------------+---------------+
| ID | Name | Status | Task State | Power State | Networks |
+--------------------------------------+------+--------+------------+-------------+---------------+
| bb3a79ba-685d-4669-8a8b-dafdb1162ed3 | c1 | ACTIVE | - | Running | vip=20.1.1.4 |
| 34303a5e-c0f4-4cef-95de-72e951912a9c | c2 | ACTIVE | - | Running | vip=20.1.1.5 |
| 52fbce99-705d-4280-b81f-28d202675a5f | s1 | ACTIVE | - | Running | pool=10.1.1.3 ———> only this is the pool member
| 558a599f-6507-41de-8e08-d20de7705aa6 | s2 | ACTIVE | - | Running | pool=10.1.1.5 |
+--------------------------------------+------+--------+------------+-------------+---------------+

But from the client VM which has the ip 20.1.1.4, I am not able to connect to vip.

ubuntu@c1:~$ wget -O - http://20.1.1.3
--2015-05-30 00:23:54-- http://20.1.1.3/
Connecting to 20.1.1.3:80... failed: Connection timed out.
Retrying.

root@a5s197:/var/log/contrail# tcpdump -nei veth5ea85132-7 tcp
17:23:52.822716 02:5e:a8:51:32:78 > 02:a7:9b:6a:bf:bf, ethertype IPv4 (0x0800), length 74: 20.1.1.3.80 > 20.1.1.4.51401: Flags [S.], seq 865140033, ack 3126895280, win 28960, options [mss 1460,sackOK,TS val 1256571 ecr 788130,nop,wscale 7], length 0
17:23:54.613446 02:a7:9b:6a:bf:bf > 02:5e:a8:51:32:78, ethertype IPv4 (0x0800), length 74: 20.1.1.4.51402 > 20.1.1.3.80: Flags [S], seq 3563304849, win 29200, options [mss 1398,sackOK,TS val 790827 ecr 0,nop,wscale 7], length 0
17:23:54.613494 02:5e:a8:51:32:78 > 02:a7:9b:6a:bf:bf, ethertype IPv4 (0x0800), length 74: 20.1.1.3.80 > 20.1.1.4.51402: Flags [S.], seq 865992132, ack 3563304850, win 28960, options [mss 1460,sackOK,TS val 1257018 ecr 790827,nop,wscale 7], length 0
17:23:55.609320 02:a7:9b:6a:bf:bf > 02:5e:a8:51:32:78, ethertype IPv4 (0x0800), length 74: 20.1.1.4.51402 > 20.1.1.3.80: Flags [S], seq 3563304849, win 29200, options [mss 1398,sackOK,TS val 791077 ecr 0,nop,wscale 7], length 0
17:23:55.609356 02:5e:a8:51:32:78 > 02:a7:9b:6a:bf:bf, ethertype IPv4 (0x0800), length 74: 20.1.1.3.80 > 20.1.1.4.51402: Flags [S.], seq 865992132, ack 3563304850, win 28960, options [mss 1460,sackOK,TS val 1257267 ecr 790827,nop,wscale 7], length 0
17:23:57.022715 02:5e:a8:51:32:78 > 02:a7:9b:6a:bf:bf, ethertype IPv4 (0x0800), length 74: 20.1.1.3.80 > 20.1.1.4.51402: Flags [S.], seq 865992132, ack 3563304850, win 28960, options [mss 1460,sackOK,TS val 1257621 ecr 790827,nop,wscale 7], length 0
17:23:57.613331 02:a7:9b:6a:bf:bf > 02:5e:a8:51:32:78, ethertype IPv4 (0x0800), length 74: 20.1.1.4.51402 > 20.1.1.3.80: Flags [S], seq 3563304849, win 29200, options [mss 1398,sackOK,TS val 791578 ecr 0,nop,wscale 7], length 0
17:23:57.613367 02:5e:a8:51:32:78 > 02:a7:9b:6a:bf:bf, ethertype IPv4 (0x0800), length 74: 20.1.1.3.80 > 20.1.1.4.51402: Flags [S.], seq 865992132, ack 3563304850, win 28960, options [mss 1460,sackOK,TS val 1257768 ecr 790827,nop,wscale 7], length 0
17:24:00.022719 02:5e:a8:51:32:78 > 02:a7:9b:6a:bf:bf, ethertype IPv4 (0x0800), length 74: 20.1.1.3.80 > 20.1.1.4.51402: Flags [S.], seq 865992132, ack 3563304850, win 28960, options [mss 1460,sackOK,TS val 1258371 ecr 790827,nop,wscale 7], length 0
17:24:01.022719 02:5e:a8:51:32:78 > 02:a7:9b:6a:bf:bf, ethertype IPv4 (0x0800), length 74: 20.1.1.3.80 > 20.1.1.4.51401: Flags [S.], seq 865140033, ack 3126895280, win 28960, options [mss 1460,sackOK,TS val 1258621 ecr 788130,nop,wscale 7], length 0
17:24:01.621318 02:a7:9b:6a:bf:bf > 02:5e:a8:51:32:78, ethertype IPv4 (0x0800), length 74: 20.1.1.4.51402 > 20.1.1.3.80: Flags [S], seq 3563304849, win 29200, options [mss 1398,sackOK,TS val 792580 ecr 0,nop,wscale 7], length 0
17:24:01.621356 02:5e:a8:51:32:78 > 02:a7:9b:6a:bf:bf, ethertype IPv4 (0x0800), length 74: 20.1.1.3.80 > 20.1.1.4.51402: Flags [S.], seq 865992132, ack 3563304850, win 28960, options [mss 1460,sackOK,TS val 1258770 ecr 790827,nop,wscale 7], length 0

Tags: blocker lbaas
Revision history for this message
Shweta Naik (stnaik) wrote :

From: Divakar Dharanalakota <email address hidden>
Date: Monday, June 1, 2015 at 4:03 AM
To: Rudra Rugge <email address hidden>, Shweta Naik <email address hidden>
Subject: Re: lbaas: R2.20 build 34, not able to connect to VIP ip

I meant, only Active compute node needs to do the Mac stitching for VIP address.
-Divakar

From: Divakar Dharanalakota <email address hidden>
Date: Monday, June 1, 2015 at 3:36 PM
To: Rudra Rugge <email address hidden>, Shweta Naik <email address hidden>
Subject: Re: lbaas: R2.20 build 34, not able to connect to VIP ip

It is an issue. Can you please log a bug. IRB Mac stitching has broken this. We need to ensure that only compute node provides the Mac stitching.
-Divakar

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

Review in progress for https://review.opencontrail.org/11148
Submitter: Rudra Rugge (<email address hidden>)

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

Review in progress for https://review.opencontrail.org/11149
Submitter: Rudra Rugge (<email address hidden>)

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

Review in progress for https://review.opencontrail.org/11148
Submitter: Rudra Rugge (<email address hidden>)

Revision history for this message
OpenContrail Admin (ci-admin-f) wrote : A change has been merged

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

commit 8f29f768d8cfb70d71e314269e7cecebd21ebafa
Author: Rudra Rugge <email address hidden>
Date: Mon Jun 1 13:54:10 2015 -0700

Allocate mac address for service instance ports

Service instance VM, netns do not request mac-addresses for its ports.
In cases of active-standby, active-active instances there is an issue
which can cause the standby mac-address to be picked up. This change
ensures that the same mac-address is used for all VMs using a particular
virtual network. This is achieved by allocating the mac-address extracted
from the virtual-network the port is attached to.

Change-Id: Ie96bd757f75f78b4aaa1c2a87a0e0ed2f902af01
Closes-Bug: #1460767

Changed in juniperopenstack:
status: New → Fix Committed
Revision history for this message
OpenContrail Admin (ci-admin-f) wrote :

Reviewed: https://review.opencontrail.org/11149
Committed: http://github.org/Juniper/contrail-controller/commit/8783bbd649f3dc5e54eac82c01a7ec1af05183be
Submitter: Zuul
Branch: R2.20

commit 8783bbd649f3dc5e54eac82c01a7ec1af05183be
Author: Rudra Rugge <email address hidden>
Date: Mon Jun 1 13:54:10 2015 -0700

Allocate mac address for service instance ports

Service instance VM, netns do not request mac-addresses for its ports.
In cases of active-standby, active-active instances there is an issue
which can cause the standby mac-address to be picked up. This change
ensures that the same mac-address is used for all VMs using a particular
virtual network. This is achieved by allocating the mac-address extracted
from the virtual-network the port is attached to.

Change-Id: Ie96bd757f75f78b4aaa1c2a87a0e0ed2f902af01
Closes-Bug: #1460767

Ashish Ranjan (aranjan-n)
information type: Proprietary → Public
Revision history for this message
Jakub Pavlik (pavlk-jakub) wrote :

Please, can you provide fix for R2.1.

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

Review in progress for https://review.opencontrail.org/12595
Submitter: Rudra Rugge (<email address hidden>)

Revision history for this message
OpenContrail Admin (ci-admin-f) wrote : A change has been merged

Reviewed: https://review.opencontrail.org/12595
Committed: http://github.org/Juniper/contrail-controller/commit/800968668ffaf0aa6bc484af212e834dd79d4e1c
Submitter: Zuul
Branch: R2.1

commit 800968668ffaf0aa6bc484af212e834dd79d4e1c
Author: Rudra Rugge <email address hidden>
Date: Thu Jul 23 15:14:11 2015 -0700

Generate mac from instance ip for service VMs

Service instance VM, netns do not request mac-addresses for its ports.
In cases of active-standby, active-active instances there is an issue
which can cause the standby mac-address to be picked up. This change
ensures that the same mac-address is used for all interfaces that share
the same instance ip address.

Change-Id: I409eae920216841656c18e947b7f8d49ef14ab04
Closes-Bug: #1460767

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.