| 2016-03-07 18:45:53 |
Sanju Abraham |
bug |
|
|
added bug |
| 2016-03-07 18:46:07 |
Sanju Abraham |
nominated for series |
|
juniperopenstack/r2.21.x |
|
| 2016-03-07 18:46:07 |
Sanju Abraham |
bug task added |
|
juniperopenstack/r2.21.x |
|
| 2016-03-07 18:46:07 |
Sanju Abraham |
nominated for series |
|
juniperopenstack/trunk |
|
| 2016-03-07 18:46:07 |
Sanju Abraham |
bug task added |
|
juniperopenstack/trunk |
|
| 2016-03-07 18:46:07 |
Sanju Abraham |
nominated for series |
|
juniperopenstack/r3.0 |
|
| 2016-03-07 18:46:07 |
Sanju Abraham |
bug task added |
|
juniperopenstack/r3.0 |
|
| 2016-03-07 18:46:46 |
Nischal Sheth |
juniperopenstack/r2.21.x: assignee |
|
Sachin Bansal (sbansal) |
|
| 2016-03-07 18:46:55 |
Nischal Sheth |
juniperopenstack/r3.0: assignee |
|
Sachin Bansal (sbansal) |
|
| 2016-03-07 18:47:03 |
Nischal Sheth |
juniperopenstack/trunk: assignee |
|
Sachin Bansal (sbansal) |
|
| 2016-03-07 18:47:05 |
Nischal Sheth |
juniperopenstack/r2.21.x: importance |
Undecided |
Medium |
|
| 2016-03-07 18:47:07 |
Nischal Sheth |
juniperopenstack/r3.0: importance |
Undecided |
Medium |
|
| 2016-03-07 18:47:08 |
Nischal Sheth |
juniperopenstack/trunk: importance |
Undecided |
Medium |
|
| 2016-03-07 18:47:23 |
Nischal Sheth |
nominated for series |
|
juniperopenstack/r2.20 |
|
| 2016-03-07 18:47:23 |
Nischal Sheth |
bug task added |
|
juniperopenstack/r2.20 |
|
| 2016-03-07 18:47:29 |
Nischal Sheth |
juniperopenstack/r2.20: importance |
Undecided |
Medium |
|
| 2016-03-07 18:47:35 |
Nischal Sheth |
juniperopenstack/r2.20: assignee |
|
Sachin Bansal (sbansal) |
|
| 2016-03-07 18:47:56 |
Nischal Sheth |
tags |
|
config service-chain snat |
|
| 2016-03-07 18:48:04 |
Nischal Sheth |
information type |
Proprietary |
Public |
|
| 2016-03-07 18:50:32 |
Nischal Sheth |
juniperopenstack/trunk: milestone |
|
r3.1.0.0-fcs |
|
| 2016-03-07 18:50:50 |
Nischal Sheth |
juniperopenstack/trunk: milestone |
r3.1.0.0-fcs |
|
|
| 2016-03-07 18:53:55 |
Sachin Bansal |
juniperopenstack/trunk: assignee |
Sachin Bansal (sbansal) |
Suresh Balineni (sbalineni) |
|
| 2016-03-16 22:03:24 |
OpenContrail Admin |
juniperopenstack/trunk: status |
New |
In Progress |
|
| 2016-03-18 06:56:48 |
OpenContrail Admin |
juniperopenstack: milestone |
|
r3.1.0.0-fcs |
|
| 2016-03-18 06:56:53 |
OpenContrail Admin |
juniperopenstack/trunk: status |
In Progress |
Fix Committed |
|
| 2016-03-18 21:51:21 |
OpenContrail Admin |
juniperopenstack/r3.0: status |
New |
In Progress |
|
| 2016-03-18 21:51:21 |
OpenContrail Admin |
juniperopenstack/r3.0: assignee |
Sachin Bansal (sbansal) |
Suresh Balineni (sbalineni) |
|
| 2016-03-19 05:55:49 |
Nischal Sheth |
juniperopenstack/r2.20: status |
New |
Won't Fix |
|
| 2016-03-19 05:55:52 |
Nischal Sheth |
juniperopenstack/r2.21.x: status |
New |
Won't Fix |
|
| 2016-03-28 17:52:27 |
Nischal Sheth |
juniperopenstack/r2.20: status |
Won't Fix |
New |
|
| 2016-03-28 17:52:30 |
Nischal Sheth |
juniperopenstack/r2.21.x: status |
Won't Fix |
New |
|
| 2016-03-28 17:52:38 |
Nischal Sheth |
nominated for series |
|
juniperopenstack/r2.22.x |
|
| 2016-03-28 17:52:38 |
Nischal Sheth |
bug task added |
|
juniperopenstack/r2.22.x |
|
| 2016-03-28 17:52:44 |
Nischal Sheth |
juniperopenstack/r2.22.x: importance |
Undecided |
High |
|
| 2016-03-28 17:52:48 |
Nischal Sheth |
juniperopenstack/r2.20: importance |
Medium |
High |
|
| 2016-03-28 17:52:50 |
Nischal Sheth |
juniperopenstack/r2.21.x: importance |
Medium |
High |
|
| 2016-03-28 17:52:52 |
Nischal Sheth |
juniperopenstack/r3.0: importance |
Medium |
High |
|
| 2016-03-28 17:52:54 |
Nischal Sheth |
juniperopenstack/trunk: importance |
Medium |
High |
|
| 2016-03-28 17:53:01 |
Nischal Sheth |
juniperopenstack/r2.22.x: assignee |
|
Suresh Balineni (sbalineni) |
|
| 2016-03-28 17:53:08 |
Nischal Sheth |
juniperopenstack/r2.21.x: assignee |
Sachin Bansal (sbansal) |
Suresh Balineni (sbalineni) |
|
| 2016-03-28 17:53:14 |
Nischal Sheth |
juniperopenstack/r2.20: assignee |
Sachin Bansal (sbansal) |
Suresh Balineni (sbalineni) |
|
| 2016-03-30 08:32:26 |
eon |
bug |
|
|
added subscriber eon |
| 2016-03-30 18:03:24 |
OpenContrail Admin |
juniperopenstack/r2.21.x: status |
New |
In Progress |
|
| 2016-03-31 17:40:07 |
Sebastien DOIDO |
bug |
|
|
added subscriber Sebastien DOIDO |
| 2016-04-02 06:22:16 |
OpenContrail Admin |
juniperopenstack/r2.21.x: milestone |
|
r2.21.2 |
|
| 2016-04-05 17:06:30 |
OpenContrail Admin |
juniperopenstack/trunk: status |
Fix Committed |
In Progress |
|
| 2016-04-05 18:03:15 |
OpenContrail Admin |
nominated for series |
|
juniperopenstack/r2.20.x |
|
| 2016-04-05 18:03:15 |
OpenContrail Admin |
bug task added |
|
juniperopenstack/r2.20.x |
|
| 2016-04-05 18:03:15 |
OpenContrail Admin |
bug task added |
|
juniperopenstack/r2.20.x |
|
| 2016-04-05 18:15:38 |
OpenContrail Admin |
juniperopenstack/r2.20: status |
New |
In Progress |
|
| 2016-04-05 18:57:20 |
OpenContrail Admin |
juniperopenstack/r2.22.x: status |
New |
In Progress |
|
| 2016-04-06 04:41:05 |
OpenContrail Admin |
juniperopenstack/r2.20: status |
In Progress |
Fix Committed |
|
| 2016-04-06 04:41:06 |
OpenContrail Admin |
juniperopenstack/r2.20: milestone |
|
r2.23 |
|
| 2016-04-06 17:36:14 |
Sachin Bansal |
juniperopenstack/trunk: status |
In Progress |
Fix Committed |
|
| 2016-04-06 17:36:30 |
Sachin Bansal |
juniperopenstack/r2.20.x: status |
In Progress |
Won't Fix |
|
| 2016-04-07 00:17:11 |
OpenContrail Admin |
juniperopenstack/r2.22.x: status |
In Progress |
Fix Committed |
|
| 2016-04-07 00:17:13 |
OpenContrail Admin |
juniperopenstack/r2.22.x: milestone |
|
r2.22.2 |
|
| 2016-04-07 18:38:37 |
OpenContrail Admin |
juniperopenstack/r3.0: status |
In Progress |
Fix Committed |
|
| 2016-04-08 16:57:21 |
OpenContrail Admin |
juniperopenstack/r3.0: status |
Fix Committed |
In Progress |
|
| 2016-04-08 18:12:33 |
OpenContrail Admin |
juniperopenstack/r2.22.x: status |
Fix Committed |
In Progress |
|
| 2016-04-08 18:15:36 |
OpenContrail Admin |
juniperopenstack/r2.20: status |
Fix Committed |
In Progress |
|
| 2016-04-09 04:25:54 |
OpenContrail Admin |
juniperopenstack/r2.20: status |
In Progress |
Fix Committed |
|
| 2016-04-12 21:20:00 |
OpenContrail Admin |
juniperopenstack/r2.22.x: status |
In Progress |
Fix Committed |
|
| 2016-04-17 18:04:01 |
Nischal Sheth |
description |
SNAT VRF has the public FIP (Floating IP) prefixes as they are re-originated because of the way SNAT is implemented as service chain.
To reproduce:
===========
1-> Create a public VN and make it external and shared.
2-> Use the public VN to associate FIP to VM
3-> Create neutron LR and assign public VN as the external gateway to LR
4-> SNAT instance and SNAT VRF gets created
5-> SNAT VRF will have public FIP routes in addtion to the public SNAT IP and the default route.
Expectation:
==========
SNAT VRF should not have public FIP routes. |
SNAT VRF has the public FIP (Floating IP) prefixes as they are re-originated because of the way SNAT is implemented as service chain.
To reproduce:
=============
1-> Create a public VN and make it external and shared.
2-> Use the public VN to associate FIP to VM
3-> Create neutron LR and assign public VN as the external gateway to LR
4-> SNAT instance and SNAT VRF gets created
5-> SNAT VRF will have public FIP routes in addtion to the public SNAT IP and the default route.
Problems:
=========
There are 2 related issues in this scenario:
1. Each SNAT VRF has all public FIP routes. If the number of LR/SNATs is
X and total number of public FIPs is Y, there are X*Y routes across all
SNAT VRFs. Each such route needs to be sent to 2 vRouters (active/backup).
Hence there's a 2*X*Y scaling issue.
2. The SNAT VRF mentioned above is actually the "left" VRF. There's also a
"right" VRF that gets created for the each SNAT. This VRF belongs to the
public VN and has a "connection" to the default VRF of the public VN. Thus
each such right VRF imports all public FIP routes. Further, since all such
right VRFs belong to the public VN, all routes in these VRFs are sent to
all Z vRouters that have a public floating IP or SNAT instance. Hence we
have a X*Y*Z scaling issue.
Expectation:
============
SNAT left VRF should not have public FIP routes
SNAT right VRF should not have public FIP routes |
|
| 2016-04-17 18:15:44 |
Nischal Sheth |
description |
SNAT VRF has the public FIP (Floating IP) prefixes as they are re-originated because of the way SNAT is implemented as service chain.
To reproduce:
=============
1-> Create a public VN and make it external and shared.
2-> Use the public VN to associate FIP to VM
3-> Create neutron LR and assign public VN as the external gateway to LR
4-> SNAT instance and SNAT VRF gets created
5-> SNAT VRF will have public FIP routes in addtion to the public SNAT IP and the default route.
Problems:
=========
There are 2 related issues in this scenario:
1. Each SNAT VRF has all public FIP routes. If the number of LR/SNATs is
X and total number of public FIPs is Y, there are X*Y routes across all
SNAT VRFs. Each such route needs to be sent to 2 vRouters (active/backup).
Hence there's a 2*X*Y scaling issue.
2. The SNAT VRF mentioned above is actually the "left" VRF. There's also a
"right" VRF that gets created for the each SNAT. This VRF belongs to the
public VN and has a "connection" to the default VRF of the public VN. Thus
each such right VRF imports all public FIP routes. Further, since all such
right VRFs belong to the public VN, all routes in these VRFs are sent to
all Z vRouters that have a public floating IP or SNAT instance. Hence we
have a X*Y*Z scaling issue.
Expectation:
============
SNAT left VRF should not have public FIP routes
SNAT right VRF should not have public FIP routes |
SNAT VRF has the public FIP (Floating IP) prefixes as they are re-originated because of the way SNAT is implemented as service chain.
To reproduce:
=============
1-> Create a public VN and make it external and shared.
2-> Use the public VN to associate FIP to VM
3-> Create neutron LR and assign public VN as the external gateway to LR
4-> SNAT instance and SNAT VRF gets created
5-> SNAT VRF will have public FIP routes in addtion to the public SNAT IP and the default route.
Problems:
=========
There are 2 related issues in this scenario:
1. Each SNAT VRF has all public FIP routes. If the number of LR/SNATs is
X and total number of public FIPs is Y, there are X*Y routes across all
SNAT VRFs. Each such route needs to be sent to 2 vRouters (active/backup).
Hence there's a 2*X*Y scaling issue.
Note that all these routes may also get advertised to the SDN GW if family
route-target is not enabled on the bgp sessions between CNs and GW.
2. The SNAT VRF mentioned above is actually the "left" VRF. There's also a
"right" VRF that gets created for the each SNAT. This VRF belongs to the
public VN and has a "connection" to the default VRF of the public VN. Thus
each such right VRF imports all public FIP routes. Further, since all such
right VRFs belong to the public VN, all routes in these VRFs are sent to
all Z vRouters that have either a public floating IP or active/backup SNAT
instance. Hence there's a X*Y*Z scaling issue.
Note that these routes don't get advertised to the SDN GW since they are
just copies of the original routes in the primary VRF of public VN.
Expectation:
============
SNAT left VRF should not have public FIP routes
SNAT right VRF should not have public FIP routes |
|
| 2016-04-17 18:26:59 |
Nischal Sheth |
description |
SNAT VRF has the public FIP (Floating IP) prefixes as they are re-originated because of the way SNAT is implemented as service chain.
To reproduce:
=============
1-> Create a public VN and make it external and shared.
2-> Use the public VN to associate FIP to VM
3-> Create neutron LR and assign public VN as the external gateway to LR
4-> SNAT instance and SNAT VRF gets created
5-> SNAT VRF will have public FIP routes in addtion to the public SNAT IP and the default route.
Problems:
=========
There are 2 related issues in this scenario:
1. Each SNAT VRF has all public FIP routes. If the number of LR/SNATs is
X and total number of public FIPs is Y, there are X*Y routes across all
SNAT VRFs. Each such route needs to be sent to 2 vRouters (active/backup).
Hence there's a 2*X*Y scaling issue.
Note that all these routes may also get advertised to the SDN GW if family
route-target is not enabled on the bgp sessions between CNs and GW.
2. The SNAT VRF mentioned above is actually the "left" VRF. There's also a
"right" VRF that gets created for the each SNAT. This VRF belongs to the
public VN and has a "connection" to the default VRF of the public VN. Thus
each such right VRF imports all public FIP routes. Further, since all such
right VRFs belong to the public VN, all routes in these VRFs are sent to
all Z vRouters that have either a public floating IP or active/backup SNAT
instance. Hence there's a X*Y*Z scaling issue.
Note that these routes don't get advertised to the SDN GW since they are
just copies of the original routes in the primary VRF of public VN.
Expectation:
============
SNAT left VRF should not have public FIP routes
SNAT right VRF should not have public FIP routes |
SNAT VRF has the public FIP (Floating IP) prefixes as they are re-originated because of the way SNAT is implemented as service chain.
To reproduce:
=============
1-> Create a public VN and make it external and shared.
2-> Use the public VN to associate FIP to VM
3-> Create neutron LR and assign public VN as the external gateway to LR
4-> SNAT instance and SNAT VRF gets created
5-> SNAT VRF will have public FIP routes in addtion to the public SNAT IP and the default route.
Problems:
=========
There are 2 related issues in this scenario:
1. Each SNAT VRF has all public FIP routes. If the number of LR/SNATs is
X and total number of public FIPs is Y, there are X*Y routes across all
SNAT VRFs. Each such route needs to be sent to 2 vRouters (active/backup).
Hence there's a 2*X*Y scaling issue.
Note that all these routes may also get advertised to the SDN GW if family
route-target is not enabled on the bgp sessions between CNs and GW.
2. The SNAT VRF mentioned above is actually the "left" VRF. There's also a
"right" VRF that gets created for the each SNAT. This VRF belongs to the
public VN and has a "connection" to the default VRF of the public VN. Thus
each such right VRF imports all public FIP routes. Further, since all such
right VRFs belong to the public VN, all routes in these VRFs are sent to
all Z vRouters that have either a public floating IP or active/backup SNAT
instance. Hence there's a X*Y*Z scaling issue.
Note that these routes don't get advertised to the SDN GW since they are
just copies of the original routes in the primary VRF of public VN.
Expectation:
============
SNAT left VRF should not have public FIP routes
SNAT right VRF should not have public FIP routes
Temporary Fix:
==============
Ignore the "connection" between the SNAT right VRF and the default VRF of
public VN. This addresses problem 2 above. Further, do not set VRF assign
rule for right interfaces of SNAT instance. This lets SNAT work properly
even though all the right VRFs are empty.
Solution:
=========
Do not create left/right VRFs for SNAT i.e. do not use service chaining
to implement SNAT.
Related Bugs:
=============
Also see the following:
Bug 1562200
Bug 1567752
Bug 1562200 |
|
| 2016-04-17 18:27:47 |
Nischal Sheth |
description |
SNAT VRF has the public FIP (Floating IP) prefixes as they are re-originated because of the way SNAT is implemented as service chain.
To reproduce:
=============
1-> Create a public VN and make it external and shared.
2-> Use the public VN to associate FIP to VM
3-> Create neutron LR and assign public VN as the external gateway to LR
4-> SNAT instance and SNAT VRF gets created
5-> SNAT VRF will have public FIP routes in addtion to the public SNAT IP and the default route.
Problems:
=========
There are 2 related issues in this scenario:
1. Each SNAT VRF has all public FIP routes. If the number of LR/SNATs is
X and total number of public FIPs is Y, there are X*Y routes across all
SNAT VRFs. Each such route needs to be sent to 2 vRouters (active/backup).
Hence there's a 2*X*Y scaling issue.
Note that all these routes may also get advertised to the SDN GW if family
route-target is not enabled on the bgp sessions between CNs and GW.
2. The SNAT VRF mentioned above is actually the "left" VRF. There's also a
"right" VRF that gets created for the each SNAT. This VRF belongs to the
public VN and has a "connection" to the default VRF of the public VN. Thus
each such right VRF imports all public FIP routes. Further, since all such
right VRFs belong to the public VN, all routes in these VRFs are sent to
all Z vRouters that have either a public floating IP or active/backup SNAT
instance. Hence there's a X*Y*Z scaling issue.
Note that these routes don't get advertised to the SDN GW since they are
just copies of the original routes in the primary VRF of public VN.
Expectation:
============
SNAT left VRF should not have public FIP routes
SNAT right VRF should not have public FIP routes
Temporary Fix:
==============
Ignore the "connection" between the SNAT right VRF and the default VRF of
public VN. This addresses problem 2 above. Further, do not set VRF assign
rule for right interfaces of SNAT instance. This lets SNAT work properly
even though all the right VRFs are empty.
Solution:
=========
Do not create left/right VRFs for SNAT i.e. do not use service chaining
to implement SNAT.
Related Bugs:
=============
Also see the following:
Bug 1562200
Bug 1567752
Bug 1562200 |
SNAT VRF has the public FIP (Floating IP) prefixes as they are re-originated because of the way SNAT is implemented as service chain.
To reproduce:
=============
1-> Create a public VN and make it external and shared.
2-> Use the public VN to associate FIP to VM
3-> Create neutron LR and assign public VN as the external gateway to LR
4-> SNAT instance and SNAT VRF gets created
5-> SNAT VRF will have public FIP routes in addtion to the public SNAT IP and the default route.
Problems:
=========
There are 2 related issues in this scenario:
1. Each SNAT VRF has all public FIP routes. If the number of LR/SNATs is
X and total number of public FIPs is Y, there are X*Y routes across all
SNAT VRFs. Each such route needs to be sent to 2 vRouters (active/backup).
Hence there's a 2*X*Y scaling issue.
Note that all these routes may also get advertised to the SDN GW if family
route-target is not enabled on the bgp sessions between CNs and GW.
2. The SNAT VRF mentioned above is actually the "left" VRF. There's also a
"right" VRF that gets created for the each SNAT. This VRF belongs to the
public VN and has a "connection" to the default VRF of the public VN. Thus
each such right VRF imports all public FIP routes. Further, since all such
right VRFs belong to the public VN, all routes in these VRFs are sent to
all Z vRouters that have either a public floating IP or active/backup SNAT
instance. Hence there's a X*Y*Z scaling issue.
Note that these routes don't get advertised to the SDN GW since they are
just copies of the original routes in the primary VRF of public VN.
Expectation:
============
SNAT left VRF should not have public FIP routes
SNAT right VRF should not have public FIP routes
Temporary Fix:
==============
Ignore the "connection" between the SNAT right VRF and the default VRF of
public VN. This addresses problem 2 above. Further, do not set VRF assign
rule for right interfaces of SNAT instance. This lets SNAT work properly
even though all the right VRFs are empty.
Solution:
=========
Do not create left/right VRFs for SNAT i.e. do not use service chaining
to implement SNAT.
Related Bugs:
=============
Also see the following:
Bug 1567752
Bug 1562200 |
|
| 2016-04-18 21:03:22 |
OpenContrail Admin |
juniperopenstack/trunk: status |
Fix Committed |
In Progress |
|
| 2016-04-18 21:06:33 |
OpenContrail Admin |
juniperopenstack/r2.20: status |
Fix Committed |
In Progress |
|
| 2016-04-18 21:09:23 |
OpenContrail Admin |
juniperopenstack/r2.22.x: status |
Fix Committed |
In Progress |
|
| 2016-04-21 00:05:55 |
Nischal Sheth |
juniperopenstack/trunk: status |
In Progress |
Fix Committed |
|
| 2016-04-21 00:06:13 |
Nischal Sheth |
juniperopenstack/r3.0: milestone |
|
r3.0.2.0 |
|
| 2016-04-21 05:58:17 |
Nischal Sheth |
juniperopenstack/r2.20: status |
In Progress |
Fix Committed |
|
| 2016-04-21 05:58:24 |
Nischal Sheth |
juniperopenstack/r2.22.x: status |
In Progress |
Fix Committed |
|
| 2016-04-21 05:58:27 |
Nischal Sheth |
juniperopenstack/r3.0: status |
In Progress |
Fix Committed |
|
| 2016-04-21 06:04:55 |
Nischal Sheth |
juniperopenstack/r2.21.x: status |
In Progress |
Fix Committed |
|
| 2016-05-25 18:36:31 |
OpenContrail Admin |
juniperopenstack/r2.21.x: status |
Fix Committed |
In Progress |
|
| 2016-05-26 04:54:53 |
OpenContrail Admin |
juniperopenstack/r2.21.x: status |
In Progress |
Fix Committed |
|
