| 2016-03-25 23:15:29 |
Nischal Sheth |
bug |
|
|
added bug |
| 2016-03-25 23:15:39 |
Nischal Sheth |
nominated for series |
|
juniperopenstack/r3.0 |
|
| 2016-03-25 23:15:39 |
Nischal Sheth |
bug task added |
|
juniperopenstack/r3.0 |
|
| 2016-03-25 23:15:39 |
Nischal Sheth |
nominated for series |
|
juniperopenstack/trunk |
|
| 2016-03-25 23:15:39 |
Nischal Sheth |
bug task added |
|
juniperopenstack/trunk |
|
| 2016-03-25 23:15:45 |
Nischal Sheth |
juniperopenstack/r3.0: importance |
Undecided |
High |
|
| 2016-03-25 23:27:45 |
Nischal Sheth |
description |
Consider a service chain where the last service instance has mode In-Network-NAT. |
Consider a service chain where the last instance in the chain has mode
In-Network-NAT. An internal service RI is created for both the left VN
and the right VN (public). The right service RI has a connection to the
primary/default RI of the public VN.
If there's X such service chains, there will X service RIs connected to
the public VN.
Say that the number of routes in the public VN is Y (this would usually
include the IP addresses assigned to each of the NAT SIs instances above
and the all floating IPs allocated in the system)
Hence there will be X*Y routes in the control nodes. Further, all these
X*Y routes will need to be downloaded to all the vRouters that have any
SNAT SI. Hence we have X*Y*Z scaling problem.
Technically, the right service RI is not even required for In-Network-NAT
since we do not re-originate routes from the left VN into public. Even if
we create the RI, we shouldn't connect it to the primary RI of public VN. |
|
| 2016-03-25 23:28:07 |
Nischal Sheth |
description |
Consider a service chain where the last instance in the chain has mode
In-Network-NAT. An internal service RI is created for both the left VN
and the right VN (public). The right service RI has a connection to the
primary/default RI of the public VN.
If there's X such service chains, there will X service RIs connected to
the public VN.
Say that the number of routes in the public VN is Y (this would usually
include the IP addresses assigned to each of the NAT SIs instances above
and the all floating IPs allocated in the system)
Hence there will be X*Y routes in the control nodes. Further, all these
X*Y routes will need to be downloaded to all the vRouters that have any
SNAT SI. Hence we have X*Y*Z scaling problem.
Technically, the right service RI is not even required for In-Network-NAT
since we do not re-originate routes from the left VN into public. Even if
we create the RI, we shouldn't connect it to the primary RI of public VN. |
Consider a service chain where the last instance in the chain has mode
In-Network-NAT. An internal service RI is created for both the left VN
and the right VN (public). The right service RI has a connection to the
primary RI of the public VN.
If there's X such service chains, there will X service RIs connected to
the public VN.
Say that the number of routes in the public VN is Y (this would usually
include the IP addresses assigned to each of the NAT SIs instances above
and the all floating IPs allocated in the system)
Hence there will be X*Y routes in the control nodes. Further, all these
X*Y routes will need to be downloaded to all the vRouters that have any
SNAT SI. Hence we have X*Y*Z scaling problem.
Technically, the right service RI is not even required for In-Network-NAT
since we do not re-originate routes from the left VN into public. Even if
we create the RI, we shouldn't connect it to the primary RI of public VN. |
|
| 2016-03-25 23:28:33 |
Nischal Sheth |
description |
Consider a service chain where the last instance in the chain has mode
In-Network-NAT. An internal service RI is created for both the left VN
and the right VN (public). The right service RI has a connection to the
primary RI of the public VN.
If there's X such service chains, there will X service RIs connected to
the public VN.
Say that the number of routes in the public VN is Y (this would usually
include the IP addresses assigned to each of the NAT SIs instances above
and the all floating IPs allocated in the system)
Hence there will be X*Y routes in the control nodes. Further, all these
X*Y routes will need to be downloaded to all the vRouters that have any
SNAT SI. Hence we have X*Y*Z scaling problem.
Technically, the right service RI is not even required for In-Network-NAT
since we do not re-originate routes from the left VN into public. Even if
we create the RI, we shouldn't connect it to the primary RI of public VN. |
Consider a service chain where the last instance in the chain has mode
In-Network-NAT. An internal service RI is created for both the left VN
and the right VN (public). The right service RI has a connection to the
primary RI of the public VN.
If there's X such service chains, there will X service RIs connected to
the public VN.
Say that the number of routes in the public VN is Y (this would usually
include the IP addresses assigned to each of the NAT SIs instances above
and the all floating IPs allocated in the system)
Hence there will be X*Y routes in the control nodes. Further, all these
X*Y routes will need to be downloaded to all Z vRouters that have any
SNAT SI. Hence we have X*Y*Z scaling problem.
Technically, the right service RI is not even required for In-Network-NAT
since we do not re-originate routes from the left VN into public. Even if
we create the RI, we shouldn't connect it to the primary RI of public VN. |
|
| 2016-03-25 23:28:56 |
Nischal Sheth |
juniperopenstack/r3.0: assignee |
|
Sachin Bansal (sbansal) |
|
| 2016-03-25 23:29:03 |
Nischal Sheth |
juniperopenstack/trunk: assignee |
|
Sachin Bansal (sbansal) |
|
| 2016-03-30 00:21:17 |
OpenContrail Admin |
juniperopenstack/trunk: status |
New |
In Progress |
|
| 2016-03-31 21:18:10 |
OpenContrail Admin |
juniperopenstack: milestone |
|
r3.1.0.0-fcs |
|
| 2016-03-31 21:18:15 |
OpenContrail Admin |
juniperopenstack/trunk: status |
In Progress |
Fix Committed |
|
| 2016-04-01 17:48:25 |
OpenContrail Admin |
nominated for series |
|
juniperopenstack/r2.21.x |
|
| 2016-04-01 17:48:25 |
OpenContrail Admin |
bug task added |
|
juniperopenstack/r2.21.x |
|
| 2016-04-01 17:48:25 |
OpenContrail Admin |
bug task added |
|
juniperopenstack/r2.21.x |
|
| 2016-04-02 06:22:12 |
OpenContrail Admin |
juniperopenstack/r2.21.x: milestone |
|
r2.21.2 |
|
| 2016-04-05 17:06:32 |
OpenContrail Admin |
juniperopenstack/trunk: status |
Fix Committed |
In Progress |
|
| 2016-04-06 17:35:18 |
Sachin Bansal |
juniperopenstack/trunk: status |
In Progress |
Fix Committed |
|
| 2016-04-08 16:57:23 |
OpenContrail Admin |
juniperopenstack/r3.0: status |
New |
In Progress |
|
| 2016-04-12 17:45:55 |
OpenContrail Admin |
juniperopenstack/r3.0: status |
In Progress |
Fix Committed |
|
| 2016-05-02 11:01:55 |
Vinay Mahuli |
juniperopenstack/r3.0: milestone |
|
r3.0.2.0 |
|
| 2016-08-04 06:30:22 |
Nischal Sheth |
juniperopenstack/r2.21.x: status |
In Progress |
Won't Fix |
|
| 2016-08-04 06:30:32 |
Nischal Sheth |
juniperopenstack/r2.21.x: milestone |
r2.21.2 |
|
|
