Activity log for bug #1649707

Date Who What changed Old value New value Message
2016-12-13 22:03:41 Nischal Sheth bug added bug
2016-12-13 22:03:51 Nischal Sheth nominated for series juniperopenstack/trunk
2016-12-13 22:03:51 Nischal Sheth bug task added juniperopenstack/trunk
2016-12-13 22:33:29 Nischal Sheth description . Consider the following BGPaaS use case. There are a number of control + data plane VMs that form a single entity. All VMs participate in the data plane, but only a single VM is elected to run BGP to the contrail controller. If the active VM fails, another VM is elected to run BGP. The source address for the BGPaaS session is a loopback address that is configured as an AAP on all the VMIs. This common loopback also allows incoming data traffic to be load balanced to all VMs. Existing BGPaaS functionality requires the creation of a BGPaaS object per VMI, even though there's a single established BGP session at any given point. This bug tracks an enhancement to allow a single shared BGPaaS object to be associated with all VMIs for the entity. The following changes are anticipated: 1. Configuration Change schema to add a new property to BGPaaS object to indicate that the object can be associated with multiple VMIs and only a single VMI can have an established bgp session. The ip address field is mandatory when this new property is set. A single client bgp-router object will be created and associated with the BGPaaS object. 2. Control Control node needs to handle a new incoming tcp session with the same source port as an existing bgpaas session. It should bring down any existing bgpaas session and bring up the new one, triggering graceful restart if appropriate. 3. Vrouter vRouter and agent need to handle failure of bgpaas VMs wherein the new active VM is on the same vRouter as the previous active VM. IOW, the newly initiated bgp session will be associated with another VMI that's on the same vRouter. There are some potentially tricky issues here with TCP session setup and TCB cleanup on base OS in control node since the vROuter uses the same source port for old and new sessions.
2016-12-14 00:47:35 Nischal Sheth description Consider the following BGPaaS use case. There are a number of control + data plane VMs that form a single entity. All VMs participate in the data plane, but only a single VM is elected to run BGP to the contrail controller. If the active VM fails, another VM is elected to run BGP. The source address for the BGPaaS session is a loopback address that is configured as an AAP on all the VMIs. This common loopback also allows incoming data traffic to be load balanced to all VMs. Existing BGPaaS functionality requires the creation of a BGPaaS object per VMI, even though there's a single established BGP session at any given point. This bug tracks an enhancement to allow a single shared BGPaaS object to be associated with all VMIs for the entity. The following changes are anticipated: 1. Configuration Change schema to add a new property to BGPaaS object to indicate that the object can be associated with multiple VMIs and only a single VMI can have an established bgp session. The ip address field is mandatory when this new property is set. A single client bgp-router object will be created and associated with the BGPaaS object. 2. Control Control node needs to handle a new incoming tcp session with the same source port as an existing bgpaas session. It should bring down any existing bgpaas session and bring up the new one, triggering graceful restart if appropriate. 3. Vrouter vRouter and agent need to handle failure of bgpaas VMs wherein the new active VM is on the same vRouter as the previous active VM. IOW, the newly initiated bgp session will be associated with another VMI that's on the same vRouter. There are some potentially tricky issues here with TCP session setup and TCB cleanup on base OS in control node since the vROuter uses the same source port for old and new sessions. Consider the following BGPaaS use case. There are a number of control + data plane VMs that form a single entity. All VMs participate in the data plane, but only a single VM is elected to run BGP to the contrail controller. If the active VM fails, another VM is elected to run BGP. The source address for the BGPaaS session is a loopback address that is configured as an AAP on all the VMIs. This common loopback is also used as the next-hop for all routes advertised by the VM thus allowing incoming data traffic to be load balanced to all VMs. Existing BGPaaS functionality requires the creation of a BGPaaS object per VMI, even though there's a single established BGP session at any given point. This bug tracks an enhancement to allow a single shared BGPaaS object to be associated with all VMIs for the entity. The following changes are anticipated: 1. Configuration Change schema to add a new property to BGPaaS object to indicate that the object can be associated with multiple VMIs and only a single VMI can have an established bgp session. The ip address field is mandatory when this new property is set. A single client bgp-router object will be created and associated with the BGPaaS object. 2. Control Control node needs to handle a new incoming tcp session with the same source port as an existing bgpaas session. It should bring down any existing bgpaas session and bring up the new one, triggering graceful restart if appropriate. 3. Vrouter vRouter and agent need to handle failure of bgpaas VMs wherein the new active VM is on the same vRouter as the previous active VM. IOW, the newly initiated bgp session will be associated with another VMI that's on the same vRouter. There are some potentially tricky issues here with TCP session setup and TCB cleanup on base OS in control node since the vROuter uses the same source port for old and new sessions.
2016-12-14 00:51:52 Nischal Sheth description Consider the following BGPaaS use case. There are a number of control + data plane VMs that form a single entity. All VMs participate in the data plane, but only a single VM is elected to run BGP to the contrail controller. If the active VM fails, another VM is elected to run BGP. The source address for the BGPaaS session is a loopback address that is configured as an AAP on all the VMIs. This common loopback is also used as the next-hop for all routes advertised by the VM thus allowing incoming data traffic to be load balanced to all VMs. Existing BGPaaS functionality requires the creation of a BGPaaS object per VMI, even though there's a single established BGP session at any given point. This bug tracks an enhancement to allow a single shared BGPaaS object to be associated with all VMIs for the entity. The following changes are anticipated: 1. Configuration Change schema to add a new property to BGPaaS object to indicate that the object can be associated with multiple VMIs and only a single VMI can have an established bgp session. The ip address field is mandatory when this new property is set. A single client bgp-router object will be created and associated with the BGPaaS object. 2. Control Control node needs to handle a new incoming tcp session with the same source port as an existing bgpaas session. It should bring down any existing bgpaas session and bring up the new one, triggering graceful restart if appropriate. 3. Vrouter vRouter and agent need to handle failure of bgpaas VMs wherein the new active VM is on the same vRouter as the previous active VM. IOW, the newly initiated bgp session will be associated with another VMI that's on the same vRouter. There are some potentially tricky issues here with TCP session setup and TCB cleanup on base OS in control node since the vROuter uses the same source port for old and new sessions. Consider the following BGPaaS use case. There are a number of control + data plane VMs that form a single entity. All VMs participate in the data plane, but only a single VM is elected to run BGP to the contrail controller. If the active VM fails, another VM is elected to run BGP. The source address for the BGPaaS session is a loopback address that is configured as an AAP on all the VMIs. This common loopback is also used as the next-hop for all routes advertised by the VM thus allowing incoming data traffic to be load balanced to all VMs. Existing BGPaaS functionality requires the creation of a unique BGPaaS object per VMI, even though there's a single established BGP session at any given point. This bug tracks an enhancement to allow a single shared BGPaaS object to be associated with all VMIs for the entity. The following changes are anticipated: 1. Configuration Change schema to add a new property to BGPaaS object to indicate that the object can be associated with multiple VMIs and only a single VMI can have an established bgp session. The ip address field is mandatory when this new property is set. A single client bgp-router object will be created and associated with the BGPaaS object. 2. Control Control node needs to handle a new incoming tcp session with the same source port as an existing bgpaas session. It should bring down any existing bgpaas session and bring up the new one, triggering graceful restart if appropriate. 3. Vrouter vRouter and agent need to handle a failure of BGPaaS VMs wherein the new active VM is on the same vRouter as the previous active VM. IOW, the newly initiated bgp session will be associated with another VMI that's on the same vRouter. This may require some tweaks to the logic to initiate SNAT+DNAT for BGPaaS session. There may also be some tricky issues here with TCP session setup and TCB cleanup on base OS in control node since the vROuter uses the same source port for both old and new sessions.
2017-01-27 09:25:19 Hari Prasad Killi juniperopenstack/trunk: assignee Srinivasan Venkatakrishnan (srinivn)
2017-02-21 06:18:20 OpenContrail Admin juniperopenstack/trunk: status New In Progress
2017-03-20 16:02:52 Nischal Sheth tags config contrail-control vrouter bgpaas config contrail-control vrouter
2017-04-26 15:17:29 OpenContrail Admin juniperopenstack/trunk: status In Progress Fix Committed
2017-04-26 15:17:31 OpenContrail Admin juniperopenstack/trunk: milestone r4.0
2017-05-20 00:07:03 Nischal Sheth juniperopenstack/trunk: status Fix Committed In Progress
2017-05-23 04:00:00 Nischal Sheth juniperopenstack/trunk: milestone r4.0.0.0-fcs r4.0.1.0
2017-05-23 04:00:33 Nischal Sheth juniperopenstack/trunk: assignee Srinivasan Venkatakrishnan (srinivn) Sachin Bansal (sbansal)
2017-05-30 22:40:47 Jim Reilly tags bgpaas config contrail-control vrouter att-aic-contrail bgpaas config contrail-control vrouter
2017-06-06 18:20:30 Jeba Paulaiyan nominated for series juniperopenstack/r4.0
2017-06-06 18:20:30 Jeba Paulaiyan bug task added juniperopenstack/r4.0
2017-06-06 18:20:38 Jeba Paulaiyan juniperopenstack/trunk: milestone r4.0.1.0 r4.1.0.0-fcs
2017-06-06 18:20:51 Jeba Paulaiyan juniperopenstack/r4.0: assignee Sachin Bansal (sbansal)
2017-06-06 18:20:54 Jeba Paulaiyan juniperopenstack/r4.0: importance Undecided Wishlist
2017-06-26 18:36:51 Nischal Sheth nominated for series juniperopenstack/r3.2
2017-06-26 18:36:51 Nischal Sheth bug task added juniperopenstack/r3.2
2017-06-26 18:37:14 Nischal Sheth juniperopenstack/r3.2: importance Undecided Wishlist
2017-06-26 18:37:24 Nischal Sheth juniperopenstack/r3.2: assignee Sachin Bansal (sbansal)
2017-06-26 18:40:33 Nischal Sheth juniperopenstack/r3.2: milestone r3.2.4.0
2017-06-26 18:44:42 Nischal Sheth juniperopenstack/r3.2: assignee Sachin Bansal (sbansal) Srinivasan Venkatakrishnan (srinivn)
2017-06-26 18:45:07 Nischal Sheth juniperopenstack/r4.0: assignee Sachin Bansal (sbansal) Srinivasan Venkatakrishnan (srinivn)
2017-06-26 18:45:18 Nischal Sheth juniperopenstack/trunk: assignee Sachin Bansal (sbansal) Srinivasan Venkatakrishnan (srinivn)
2017-06-28 04:48:27 OpenContrail Admin juniperopenstack/r4.0: status New In Progress
2017-06-28 19:11:48 Jeba Paulaiyan juniperopenstack/r4.0: milestone r4.0.1.0
2017-06-29 13:55:28 OpenContrail Admin juniperopenstack/trunk: status In Progress Fix Committed
2017-06-29 16:22:42 OpenContrail Admin juniperopenstack/r4.0: status In Progress Fix Committed
2017-06-30 09:39:17 OpenContrail Admin juniperopenstack/trunk: status Fix Committed In Progress
2017-07-05 10:29:29 OpenContrail Admin juniperopenstack/trunk: status In Progress Fix Committed
2017-07-09 12:33:26 OpenContrail Admin juniperopenstack/trunk: status Fix Committed In Progress
2017-07-11 08:07:51 Hari Prasad Killi juniperopenstack/r4.0: status Fix Committed New
2017-07-12 23:30:45 OpenContrail Admin juniperopenstack/r3.2: status New In Progress
2017-07-12 23:54:26 OpenContrail Admin juniperopenstack/r4.0: status New In Progress
2017-07-13 05:55:10 OpenContrail Admin juniperopenstack/r3.2: status In Progress Fix Committed
2017-07-13 11:00:57 OpenContrail Admin juniperopenstack/r3.2: status Fix Committed In Progress
2017-07-13 17:46:36 OpenContrail Admin juniperopenstack/trunk: status In Progress Fix Committed
2017-07-14 06:33:33 OpenContrail Admin juniperopenstack/trunk: status Fix Committed In Progress
2017-07-14 20:59:20 OpenContrail Admin juniperopenstack/r3.2: status In Progress Fix Committed
2017-07-14 21:51:42 Sachin Bansal juniperopenstack/r3.2: status Fix Committed New
2017-07-14 21:51:49 Sachin Bansal juniperopenstack/r3.2: assignee Srinivasan Venkatakrishnan (srinivn) Ranjeet R (rranjeet-n)
2017-07-16 04:33:34 OpenContrail Admin juniperopenstack/trunk: status In Progress Fix Committed
2017-07-16 12:49:27 OpenContrail Admin juniperopenstack/r4.0: status In Progress Fix Committed
2017-07-17 06:06:49 OpenContrail Admin juniperopenstack/trunk: status Fix Committed In Progress
2017-07-17 18:56:21 Jeba Paulaiyan juniperopenstack/r3.2: milestone r3.2.4.0 r3.2.5.0
2017-07-18 10:15:42 OpenContrail Admin juniperopenstack/r3.2: status New In Progress
2017-07-18 10:15:42 OpenContrail Admin juniperopenstack/r3.2: assignee Ranjeet R (rranjeet-n) Srinivasan Venkatakrishnan (srinivn)
2017-07-18 17:12:38 OpenContrail Admin juniperopenstack/r4.0: status Fix Committed In Progress
2017-07-19 08:55:33 OpenContrail Admin juniperopenstack/trunk: status In Progress Fix Committed
2017-07-25 08:08:42 OpenContrail Admin juniperopenstack/r3.2: status In Progress Fix Committed
2017-07-25 08:08:43 OpenContrail Admin juniperopenstack/r3.2: milestone r3.2.5.0 r3.2.4.0
2017-07-28 19:36:36 OpenContrail Admin juniperopenstack/trunk: status Fix Committed In Progress
2017-08-01 15:24:28 OpenContrail Admin juniperopenstack/r4.0: status In Progress Fix Committed
2017-08-17 16:29:08 Nischal Sheth juniperopenstack/r3.2: status Fix Committed In Progress
2017-08-17 18:14:23 Nischal Sheth juniperopenstack/r3.2: milestone r3.2.4.0 r3.2.5.0
2017-08-17 18:14:30 Nischal Sheth juniperopenstack/r4.0: status Fix Committed In Progress
2017-08-18 05:08:52 Hari Prasad Killi juniperopenstack/r3.2: assignee Srinivasan Venkatakrishnan (srinivn) Ranjeet Ramalingam (rranjeet)
2017-08-18 05:09:22 Hari Prasad Killi juniperopenstack/r4.0: assignee Srinivasan Venkatakrishnan (srinivn) Ranjeet Ramalingam (rranjeet)
2017-08-18 05:09:38 Hari Prasad Killi juniperopenstack/trunk: assignee Srinivasan Venkatakrishnan (srinivn) Ranjeet Ramalingam (rranjeet)
2017-08-18 22:34:16 Ranjeet R juniperopenstack/r3.2: assignee Ranjeet Ramalingam (rranjeet) Ranjeet R (rranjeet-n)
2017-08-18 22:34:19 Ranjeet R juniperopenstack/r4.0: assignee Ranjeet Ramalingam (rranjeet) Ranjeet R (rranjeet-n)
2017-08-18 22:34:22 Ranjeet R juniperopenstack/trunk: assignee Ranjeet Ramalingam (rranjeet) Ranjeet R (rranjeet-n)
2017-08-25 18:18:08 Ranjeet R juniperopenstack/r3.2: assignee Ranjeet R (rranjeet-n) Srinivasan Venkatakrishnan (srinivn)
2017-08-25 18:18:40 Ranjeet R juniperopenstack/r4.0: assignee Ranjeet R (rranjeet-n) Srinivasan Venkatakrishnan (srinivn)
2017-08-25 18:18:53 Ranjeet R juniperopenstack/trunk: assignee Ranjeet R (rranjeet-n) Srinivasan Venkatakrishnan (srinivn)
2017-08-28 17:34:35 OpenContrail Admin juniperopenstack/r4.0: status In Progress Fix Committed
2017-08-28 17:51:26 OpenContrail Admin juniperopenstack/r3.2: status In Progress Fix Committed
2017-09-02 08:24:39 OpenContrail Admin juniperopenstack/trunk: status In Progress Fix Committed
2017-10-23 09:17:52 Emil Muratov bug added subscriber Emil Muratov
2017-11-08 11:30:53 OpenContrail Admin juniperopenstack/trunk: status Fix Committed In Progress
2017-11-09 05:31:37 Hari Prasad Killi juniperopenstack/trunk: status In Progress Fix Committed