| 2015-07-08 16:39:06 |
Nischal Sheth |
bug |
|
|
added bug |
| 2015-07-08 16:42:42 |
Nischal Sheth |
description |
Current implementation does not generate l2 routing-instance configuration
for external VNs. This limitation needs to be removed to support the use case
where there are external VNs with BMSs. The following changes need to be
made:
1. Decision to generate l2 routing-instance configuration or not must be made
based on the VN forwarding-mode (see bug 1471637) rather than the external
flag. L2 configuration must not be generated if the forwarding mode is L3 only.
2. Static routes for external VN prefixes should be added to inet.0 to allow user
to export these prefixes into the routing protocol used for inet.0. These routes
should have a discard next-hop since JUNOS does not allow 2 tables with static
routes (even if the prefixes are different) to have table next-hops pointing to
each other. Static routes can either be added as primary routes to inet.0 or by
creating a rib-group for each external VN and applying the rib-group for static
routes added in the corresponding VRF. The former should be the first choice.
Note that the L3 routing-instance configuration for an external VN already has
a static default route with a table next-hop that points to inet.0. There should
be no change to this configuration.
3. Note that the static discard routes in inet.0 added as part of 2 above will not
be used for forwarding, only for route export. Traffic coming in to inet.0 from
outside will be directed to the appropriate VRF based on the forwarding table
filter that's applied to inet.0. This filter is currently being generated but it's
not clear if it supports multiple external VNs. Instead of creating a filter per
external VN, a single filter should be created. This filter should have a term for
each external VN. The term should match the prefixes in the external VN and
redirect the traffic to the routing-instance in question. |
Current implementation does not generate l2 routing-instance configuration
for external VNs. This limitation needs to be removed to support use cases
where there are external VNs with BMSs. The following changes need to be
made:
1. Decision to generate l2 routing-instance configuration or not must be
made based on the VN forwarding-mode (see bug 1471637) rather than the
external flag. L2 configuration must not be generated if the forwarding
mode is L3 only.
2. Static routes for external VN prefixes should be added to inet.0 to
allow user to export these prefixes into the routing protocol used for
inet.0. These routes should have a discard next-hop since JUNOS does not
allow 2 tables with static routes (even if the prefixes are different) to
have table next-hops pointing to each other. Static routes can either be
added as primary routes to inet.0 or by creating a rib-group for each
external VN and applying rib-group to static routes added in corresponding
VRF. The former should be the first choice.
Note that the L3 routing-instance configuration for an external VN already
has a static default route with a table next-hop that points to inet.0.
There will be no change to this configuration.
3. Note that the static discard routes in inet.0 added as part of 2 above
will not be used for forwarding, only for route export. Traffic coming in
to inet.0 will be directed to the appropriate VRF based on the forwarding
table filter that's applied to inet.0. This filter is currently generated
but it's not clear if it supports > 1 external VNs. Instead of creating a
filter per external VN, a single filter must be created. This filter will
should have a term for each external VN. The term should match prefixes in
the external VN and redirect the traffic to routing-instance in question. |
|
| 2015-07-08 16:42:47 |
Nischal Sheth |
nominated for series |
|
juniperopenstack/trunk |
|
| 2015-07-08 16:42:47 |
Nischal Sheth |
bug task added |
|
juniperopenstack/trunk |
|
| 2015-07-08 16:42:47 |
Nischal Sheth |
nominated for series |
|
juniperopenstack/r2.20 |
|
| 2015-07-08 16:42:47 |
Nischal Sheth |
bug task added |
|
juniperopenstack/r2.20 |
|
| 2015-07-08 16:42:57 |
Nischal Sheth |
juniperopenstack/r2.20: assignee |
|
Suresh Balineni (sbalineni) |
|
| 2015-07-08 16:43:00 |
Nischal Sheth |
juniperopenstack/r2.20: importance |
Undecided |
High |
|
| 2015-07-08 16:43:04 |
Nischal Sheth |
juniperopenstack/r2.20: milestone |
|
r2.21 |
|
| 2015-07-08 16:43:34 |
Nischal Sheth |
information type |
Proprietary |
Public |
|
| 2015-07-08 16:44:02 |
Nischal Sheth |
summary |
DM: support l2 and l3 configuration for external VNs |
DM: support L2 and L3 configuration for external VNs |
|
| 2015-07-08 16:44:33 |
Nischal Sheth |
description |
Current implementation does not generate l2 routing-instance configuration
for external VNs. This limitation needs to be removed to support use cases
where there are external VNs with BMSs. The following changes need to be
made:
1. Decision to generate l2 routing-instance configuration or not must be
made based on the VN forwarding-mode (see bug 1471637) rather than the
external flag. L2 configuration must not be generated if the forwarding
mode is L3 only.
2. Static routes for external VN prefixes should be added to inet.0 to
allow user to export these prefixes into the routing protocol used for
inet.0. These routes should have a discard next-hop since JUNOS does not
allow 2 tables with static routes (even if the prefixes are different) to
have table next-hops pointing to each other. Static routes can either be
added as primary routes to inet.0 or by creating a rib-group for each
external VN and applying rib-group to static routes added in corresponding
VRF. The former should be the first choice.
Note that the L3 routing-instance configuration for an external VN already
has a static default route with a table next-hop that points to inet.0.
There will be no change to this configuration.
3. Note that the static discard routes in inet.0 added as part of 2 above
will not be used for forwarding, only for route export. Traffic coming in
to inet.0 will be directed to the appropriate VRF based on the forwarding
table filter that's applied to inet.0. This filter is currently generated
but it's not clear if it supports > 1 external VNs. Instead of creating a
filter per external VN, a single filter must be created. This filter will
should have a term for each external VN. The term should match prefixes in
the external VN and redirect the traffic to routing-instance in question. |
Current implementation does not generate L2 routing-instance configuration
for external VNs. This limitation needs to be removed to support use cases
where there are external VNs with BMSs. The following changes need to be
made:
1. Decision to generate L2 routing-instance configuration or not must be
made based on the VN forwarding-mode (see bug 1471637) rather than the
external flag. L2 configuration must not be generated if the forwarding
mode is L3 only.
2. Static routes for external VN prefixes should be added to inet.0 to
allow user to export these prefixes into the routing protocol used for
inet.0. These routes should have a discard next-hop since JUNOS does not
allow 2 tables with static routes (even if the prefixes are different) to
have table next-hops pointing to each other. Static routes can either be
added as primary routes to inet.0 or by creating a rib-group for each
external VN and applying rib-group to static routes added in corresponding
VRF. The former should be the first choice.
Note that the L3 routing-instance configuration for an external VN already
has a static default route with a table next-hop that points to inet.0.
There will be no change to this configuration.
3. Note that the static discard routes in inet.0 added as part of 2 above
will not be used for forwarding, only for route export. Traffic coming in
to inet.0 will be directed to the appropriate VRF based on the forwarding
table filter that's applied to inet.0. This filter is currently generated
but it's not clear if it supports > 1 external VNs. Instead of creating a
filter per external VN, a single filter must be created. This filter will
should have a term for each external VN. The term should match prefixes in
the external VN and redirect the traffic to routing-instance in question. |
|
| 2015-07-08 16:46:20 |
Nischal Sheth |
description |
Current implementation does not generate L2 routing-instance configuration
for external VNs. This limitation needs to be removed to support use cases
where there are external VNs with BMSs. The following changes need to be
made:
1. Decision to generate L2 routing-instance configuration or not must be
made based on the VN forwarding-mode (see bug 1471637) rather than the
external flag. L2 configuration must not be generated if the forwarding
mode is L3 only.
2. Static routes for external VN prefixes should be added to inet.0 to
allow user to export these prefixes into the routing protocol used for
inet.0. These routes should have a discard next-hop since JUNOS does not
allow 2 tables with static routes (even if the prefixes are different) to
have table next-hops pointing to each other. Static routes can either be
added as primary routes to inet.0 or by creating a rib-group for each
external VN and applying rib-group to static routes added in corresponding
VRF. The former should be the first choice.
Note that the L3 routing-instance configuration for an external VN already
has a static default route with a table next-hop that points to inet.0.
There will be no change to this configuration.
3. Note that the static discard routes in inet.0 added as part of 2 above
will not be used for forwarding, only for route export. Traffic coming in
to inet.0 will be directed to the appropriate VRF based on the forwarding
table filter that's applied to inet.0. This filter is currently generated
but it's not clear if it supports > 1 external VNs. Instead of creating a
filter per external VN, a single filter must be created. This filter will
should have a term for each external VN. The term should match prefixes in
the external VN and redirect the traffic to routing-instance in question. |
Current implementation does not generate L2 routing-instance configuration
for external VNs. This limitation needs to be removed to support use cases
where there are external VNs with BMSs. The following changes need to be
made:
1. Decision to generate L2 routing-instance configuration or not must be
made based on the VN forwarding-mode (see bug 1471637) rather than the
external flag. L2 configuration must not be generated if the forwarding
mode is L3 only.
2. Static routes for external VN prefixes should be added to inet.0 to
allow user to export these prefixes into the routing protocol used for
inet.0. These routes should have a discard next-hop since JUNOS does not
allow 2 tables with static routes (even if the prefixes are different) to
have table next-hops pointing to each other. Static routes can either be
added as primary routes to inet.0 or by creating a rib-group for each
external VN and applying rib-group to static routes added in corresponding
VRF. The former should be the first choice.
Note that the L3 routing-instance configuration for an external VN already
has static default route with a table next-hop that points to inet.0. This
is used to forward traffic coming in from BMSs to the external VRF. There
will be no change to this configuration.
3. Note that the static discard routes in inet.0 added as part of 2 above
will not be used for forwarding, only for route export. Traffic coming in
to inet.0 will be directed to the appropriate VRF based on the forwarding
table filter that's applied to inet.0. This filter is currently generated
but it's not clear if it supports > 1 external VNs. Instead of creating a
filter per external VN, a single filter must be created. This filter will
should have a term for each external VN. The term should match prefixes in
the external VN and redirect the traffic to routing-instance in question. |
|
| 2015-07-08 17:00:58 |
Nischal Sheth |
description |
Current implementation does not generate L2 routing-instance configuration
for external VNs. This limitation needs to be removed to support use cases
where there are external VNs with BMSs. The following changes need to be
made:
1. Decision to generate L2 routing-instance configuration or not must be
made based on the VN forwarding-mode (see bug 1471637) rather than the
external flag. L2 configuration must not be generated if the forwarding
mode is L3 only.
2. Static routes for external VN prefixes should be added to inet.0 to
allow user to export these prefixes into the routing protocol used for
inet.0. These routes should have a discard next-hop since JUNOS does not
allow 2 tables with static routes (even if the prefixes are different) to
have table next-hops pointing to each other. Static routes can either be
added as primary routes to inet.0 or by creating a rib-group for each
external VN and applying rib-group to static routes added in corresponding
VRF. The former should be the first choice.
Note that the L3 routing-instance configuration for an external VN already
has static default route with a table next-hop that points to inet.0. This
is used to forward traffic coming in from BMSs to the external VRF. There
will be no change to this configuration.
3. Note that the static discard routes in inet.0 added as part of 2 above
will not be used for forwarding, only for route export. Traffic coming in
to inet.0 will be directed to the appropriate VRF based on the forwarding
table filter that's applied to inet.0. This filter is currently generated
but it's not clear if it supports > 1 external VNs. Instead of creating a
filter per external VN, a single filter must be created. This filter will
should have a term for each external VN. The term should match prefixes in
the external VN and redirect the traffic to routing-instance in question. |
Current implementation does not generate L2 routing-instance configuration
for external VNs. This limitation needs to be removed to support use cases
where there are external VNs with BMSs.
The following changes need to be made:
1. Decision to generate L2 routing-instance configuration or not must be
made based on the VN forwarding-mode (see bug 1471637) rather than the
external flag. L2 configuration must not be generated if the forwarding
mode is L3 only.
2. Static routes for external VN prefixes should be added to inet.0 to
allow user to export these prefixes into the routing protocol used for
inet.0. These routes should have a discard next-hop since JUNOS does not
allow 2 tables with static routes (even if the prefixes are different) to
have table next-hops pointing to each other. Static routes can either be
added as primary routes to inet.0 or by creating a rib-group for each
external VN and applying rib-group to static routes added in corresponding
VRF. The former should be the first choice.
Note that the L3 routing-instance configuration for an external VN already
has static default route with a table next-hop that points to inet.0. This
is used to forward traffic coming in from BMSs to the external VRF. There
will be no change to this configuration.
3. Note that the static discard routes in inet.0 added as part of 2 above
will not be used for forwarding, only for route export. Traffic coming in
to inet.0 will be directed to the appropriate VRF based on the forwarding
table filter that's applied to inet.0. This filter is currently generated
but it's not clear if it supports > 1 external VNs. Instead of creating a
filter per external VN, a single filter must be created. This filter will
should have a term for each external VN. The term should match prefixes in
the external VN and redirect the traffic to routing-instance in question. |
|
| 2015-07-08 17:25:05 |
Qasim Arham |
bug |
|
|
added subscriber Qasim Arham |
| 2015-09-02 16:51:21 |
Vinay Mahuli |
juniperopenstack/trunk: status |
New |
In Progress |
|
| 2015-09-05 03:49:02 |
OpenContrail Admin |
juniperopenstack/trunk: status |
In Progress |
Fix Committed |
|
| 2015-09-05 04:28:50 |
Nischal Sheth |
juniperopenstack/r2.20: milestone |
r2.21 |
r2.22 |
|
| 2015-09-06 05:47:23 |
Nischal Sheth |
juniperopenstack/r2.20: milestone |
r2.22 |
r2.21 |
|
| 2015-09-08 17:36:29 |
Vinay Mahuli |
juniperopenstack/r2.20: status |
New |
In Progress |
|
| 2015-09-10 00:00:05 |
OpenContrail Admin |
juniperopenstack/r2.20: status |
In Progress |
Fix Committed |
|
| 2015-09-18 22:54:19 |
Vinay Mahuli |
juniperopenstack/r2.20: status |
Fix Committed |
In Progress |
|
| 2017-03-14 00:40:18 |
Sachin Bansal |
juniperopenstack/r2.20: status |
In Progress |
Fix Committed |
|
