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 |
|