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.
Reviewed: https:/ /review. opencontrail. org/29315 github. org/Juniper/ contrail- controller/ commit/ 200b8e885f266da fafb2c2a147ad59 ac53f26b1d
Committed: http://
Submitter: Zuul (<email address hidden>)
Branch: R3.1
commit 200b8e885f266da fafb2c2a147ad59 ac53f26b1d
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: If48e4c9648d7ea 5a8a121c1a46e7f 10ce7451936
Closes-Bug: 1669871