Make BGPaaS port change processing more defensive

Bug #1669871 reported by Nischal Sheth
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Juniper Openstack
Status tracked in Trunk
R3.0
Fix Committed
Medium
Nischal Sheth
R3.1
Fix Committed
Medium
Nischal Sheth
R3.2
Fix Committed
Medium
Nischal Sheth
Trunk
Fix Committed
Medium
Nischal Sheth

Bug Description

Consider the following scenario:

Peer1 has source port p1
Peer2 has source port p2

Configuration for Peer1 is changed to have port p2 i.e. both Peer1 and
Peer2 have port p2. Existing implementation removes Peer2 from it's port
to peer mapping table under the assumption that the port for Peer2 will
soon change to a new value. However, if the port for Peer1 is now changed
back to p1, the port to peer mapping table no longer has an entry that
maps p2 to Peer2.

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

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

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

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

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

Review in progress for https://review.opencontrail.org/29315
Submitter: Nischal Sheth (<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/29320
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/29312
Committed: http://github.org/Juniper/contrail-controller/commit/cec60a1481caff349b177cc86b450659f297c2df
Submitter: Zuul (<email address hidden>)
Branch: master

commit cec60a1481caff349b177cc86b450659f297c2df
Author: Nischal Sheth <email address hidden>
Date: Fri Mar 3 09:36:02 2017 -0800

Make BGPaaS config processing more defensive

Consider the following scenario:

Peer1 has source port p1
Peer2 has source port p2

Configuration for Peer1 is changed to have port p2 i.e. both Peer1 and
Peer2 have port p2. Existing implementation removes Peer2 from it's port
to peer mapping table under the assumption that the port for Peer2 will
soon change to a new value. However, if the port for Peer1 is now changed
back to p1, the port to peer mapping table no longer has an entry that
maps p2 to Peer2.

Fix by using a multimap instead of map to maintain port to peer mapping.
It's expected that duplicate port values may only be seen in transient
situations when the ST is being restarted and/or has a bug. This change
lets the CN get to a sane configuration once any configuration issues
are fixed.

Change-Id: If48e4c9648d7ea5a8a121c1a46e7f10ce7451936
Closes-Bug: 1669871

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

Review in progress for https://review.opencontrail.org/29315
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/29315
Committed: http://github.org/Juniper/contrail-controller/commit/200b8e885f266dafafb2c2a147ad59ac53f26b1d
Submitter: Zuul (<email address hidden>)
Branch: R3.1

commit 200b8e885f266dafafb2c2a147ad59ac53f26b1d
Author: Nischal Sheth <email address hidden>
Date: Fri Mar 3 09:36:02 2017 -0800

Make BGPaaS config processing more defensive

Consider the following scenario:

Peer1 has source port p1
Peer2 has source port p2

Configuration for Peer1 is changed to have port p2 i.e. both Peer1 and
Peer2 have port p2. Existing implementation removes Peer2 from it's port
to peer mapping table under the assumption that the port for Peer2 will
soon change to a new value. However, if the port for Peer1 is now changed
back to p1, the port to peer mapping table no longer has an entry that
maps p2 to Peer2.

Fix by using a multimap instead of map to maintain port to peer mapping.
It's expected that duplicate port values may only be seen in transient
situations when the ST is being restarted and/or has a bug. This change
lets the CN get to a sane configuration once any configuration issues
are fixed.

Change-Id: If48e4c9648d7ea5a8a121c1a46e7f10ce7451936
Closes-Bug: 1669871

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

Reviewed: https://review.opencontrail.org/29320
Committed: http://github.org/Juniper/contrail-controller/commit/dbce53f1dd11c4eb2b4ff6e3609c9d7d04ef6159
Submitter: Zuul (<email address hidden>)
Branch: R3.0

commit dbce53f1dd11c4eb2b4ff6e3609c9d7d04ef6159
Author: Nischal Sheth <email address hidden>
Date: Fri Mar 3 09:36:02 2017 -0800

Make BGPaaS config processing more defensive

Consider the following scenario:

Peer1 has source port p1
Peer2 has source port p2

Configuration for Peer1 is changed to have port p2 i.e. both Peer1 and
Peer2 have port p2. Existing implementation removes Peer2 from it's port
to peer mapping table under the assumption that the port for Peer2 will
soon change to a new value. However, if the port for Peer1 is now changed
back to p1, the port to peer mapping table no longer has an entry that
maps p2 to Peer2.

Fix by using a multimap instead of map to maintain port to peer mapping.
It's expected that duplicate port values may only be seen in transient
situations when the ST is being restarted and/or has a bug. This change
lets the CN get to a sane configuration once any configuration issues
are fixed.

Change-Id: If48e4c9648d7ea5a8a121c1a46e7f10ce7451936
Closes-Bug: 1669871

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

Review in progress for https://review.opencontrail.org/29314
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/29314
Committed: http://github.org/Juniper/contrail-controller/commit/aa776f8880c97522fd7b4b1dc41a45baecd383e4
Submitter: Zuul (<email address hidden>)
Branch: R3.2

commit aa776f8880c97522fd7b4b1dc41a45baecd383e4
Author: Nischal Sheth <email address hidden>
Date: Fri Mar 3 09:36:02 2017 -0800

Make BGPaaS config processing more defensive

Consider the following scenario:

Peer1 has source port p1
Peer2 has source port p2

Configuration for Peer1 is changed to have port p2 i.e. both Peer1 and
Peer2 have port p2. Existing implementation removes Peer2 from it's port
to peer mapping table under the assumption that the port for Peer2 will
soon change to a new value. However, if the port for Peer1 is now changed
back to p1, the port to peer mapping table no longer has an entry that
maps p2 to Peer2.

Fix by using a multimap instead of map to maintain port to peer mapping.
It's expected that duplicate port values may only be seen in transient
situations when the ST is being restarted and/or has a bug. This change
lets the CN get to a sane configuration once any configuration issues
are fixed.

Change-Id: If48e4c9648d7ea5a8a121c1a46e7f10ce7451936
Closes-Bug: 1669871

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

Other bug subscribers

Remote bug watches

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