Juniper Openstack

contrail-control route replication loop

Bug #1597687 reported by Prakash Bailkeri
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Juniper Openstack
Status tracked in Trunk
R3.0
Fix Committed
High
Prakash Bailkeri
Juniper Openstack r3.0.3.0
R3.0.2.x
Fix Committed
High
Prakash Bailkeri
Juniper Openstack r3.0.2.1
Trunk
Fix Committed
High
Prakash Bailkeri
Juniper Openstack r3.1.0.0-fcs

Bug Description

On single Contrail Cluster, configure following:
- 2 VNs (left and right)
     CUST-POL-JLH02-LEFT-VN (External Route target configured)
     CUST-POL-JLH02-RIGHT-VN (External Route target configured)
- 2 Routing Policies applied to each SI:
     CUST-POL-JLH02-INTERNET-N: from prefix [0.0.0.0/0 exact] then add communities [4567:200] local-preference 200 action accept from any then action reject
     CUST-POL-JLH02-INTERNET-B: from prefix [0.0.0.0/0 exact] then add communities [4567:200] local-preference 50 action accept from any then action reject
- 2 SI (in-network-NAT) attached to CUST-POL-JLH02-LEFT-VN and CUST-POL-JLH02-RIGHT-VN
     CUST-SI-JLH02-INTERNET-N (primary SI) with Routing Policy CUST-POL-JLH02-INTERNET-N
     CUST-SI-JLH02-INTERNET-B (backup SI) with Routing Policy CUST-POL-JLH02-INTERNET-B
- 2 Network Policies
     CUST-NP-JLH02-N: from CUST-POL-JLH02-LEFT-VN to CUST-POL-JLH02-RIGHT-VN all ports all protocols service CUST-SI-JLH02-INTERNET-N
     CUST-NP-JLH02-B: from CUST-POL-JLH02-LEFT-VN to CUST-POL-JLH02-RIGHT-VN all ports all protocols service CUST-SI-JLH02-INTERNET-B

With above configuration, when both network policies are attached to left and right VN, control-node ends up with infinite route replication.

Root cause:
The external route target configured on the left VN is copied as import-rt for both internal routing instance created for two service chain. Due to this, the internal routing instances are leaking routes to each other.
Due to routing policy, the route attribute is edited (to set new Local-pref and community) after the route replication into each others routing instance.

This route replication of re-originated route ends up in endless loop.

You will not see the issue if left network doesn’t have external route-target configured.

Nischal Sheth (nsheth)
tags: added: service-chain
information type: Proprietary → Public
summary: - [R3.0] contrail-control route replication loop
+ contrail-control route replication loop
Revision history for this message
OpenContrail Admin (ci-admin-f) wrote : [Review update] R3.0

Review in progress for https://review.opencontrail.org/21615
Submitter: Prakash Bailkeri (<email address hidden>)

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

Review in progress for https://review.opencontrail.org/21616
Submitter: Prakash Bailkeri (<email address hidden>)

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

Review in progress for https://review.opencontrail.org/21617
Submitter: Prakash Bailkeri (<email address hidden>)

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

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

commit 933d30c7363d7c42eb3128f19b6492c72f3a1fe2
Author: Prakash Bailkeri <email address hidden>
Date: Fri Jul 1 14:29:02 2016 +0530

Prevent route replication loop

Scenario:
With two VRF importing each other and with routing policy attached to both VRF
to edit the BgpAttr of the routes, each DBEntry notification for route replication
would end up deleting and re-adding back the replicated route and notifying the
secondary route. This would cause an endless route replication loop

Solution:
Search for secondary path while replicating the route, should compare the BgpAttr
with original BgpAttr of the secondary path.

Added test to validate the above fix. i.e. time stamp of the replicated path is
not updated on triggering the notification of the primary route.

Change-Id: I3e6b31e8b36efbc091353e828b4f9dfa809cf5ff
Closes-Bug: #1597687
(cherry picked from commit ca58c3d77f09098cf3e056e93591ed2d0163e942)

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

Review in progress for https://review.opencontrail.org/21621
Submitter: Nischal Sheth (<email address hidden>)

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

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

commit ca58c3d77f09098cf3e056e93591ed2d0163e942
Author: Prakash Bailkeri <email address hidden>
Date: Fri Jul 1 14:29:02 2016 +0530

Prevent route replication loop

Scenario:
With two VRF importing each other and with routing policy attached to both VRF
to edit the BgpAttr of the routes, each DBEntry notification for route replication
would end up deleting and re-adding back the replicated route and notifying the
secondary route. This would cause an endless route replication loop

Solution:
Search for secondary path while replicating the route, should compare the BgpAttr
with original BgpAttr of the secondary path.

Added test to validate the above fix. i.e. time stamp of the replicated path is
not updated on triggering the notification of the primary route.

Change-Id: I3e6b31e8b36efbc091353e828b4f9dfa809cf5ff
Closes-Bug: #1597687

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

Reviewed: https://review.opencontrail.org/21621
Committed: http://github.org/Juniper/contrail-controller/commit/ed92b45cbe16a71fe54b1f2f897785658d74538e
Submitter: Zuul
Branch: R3.0.2.x

commit ed92b45cbe16a71fe54b1f2f897785658d74538e
Author: Prakash Bailkeri <email address hidden>
Date: Fri Jul 1 14:29:02 2016 +0530

Prevent route replication loop

Scenario:
With two VRF importing each other and with routing policy attached to both VRF
to edit the BgpAttr of the routes, each DBEntry notification for route replication
would end up deleting and re-adding back the replicated route and notifying the
secondary route. This would cause an endless route replication loop

Solution:
Search for secondary path while replicating the route, should compare the BgpAttr
with original BgpAttr of the secondary path.

Added test to validate the above fix. i.e. time stamp of the replicated path is
not updated on triggering the notification of the primary route.

Change-Id: I3e6b31e8b36efbc091353e828b4f9dfa809cf5ff
Closes-Bug: #1597687

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.