| 2016-04-07 18:01:15 |
Nischal Sheth |
bug |
|
|
added bug |
| 2016-04-07 18:01:22 |
Nischal Sheth |
nominated for series |
|
juniperopenstack/trunk |
|
| 2016-04-07 18:01:22 |
Nischal Sheth |
bug task added |
|
juniperopenstack/trunk |
|
| 2016-04-07 18:02:09 |
Nischal Sheth |
juniperopenstack/trunk: assignee |
|
Divakar Dharanalakota (ddivakar) |
|
| 2016-04-07 18:12:00 |
Nischal Sheth |
description |
TBD |
When doing SNAT+DNAT for bgpaas it would it be useful to use a new fixed
TTL value for the forward flow. The client VM typically uses a TTL of 1
for its eBGP session by default - this causes problems if user forgets to configure multi hop on the bgp session. Note that the client thinks it's
setting up the session to the default GW and DNS server IPs, so it's not
intuitive to use multi hop.
Proposed fix (from Divakar) is to have agent maintain TTL in flow entry
and when Vrouter sees a non-zero TTL, it copies this value to the packet.
There are 2 additional items that would be nice to have:
- If the incoming TTL for the forward flow is 1, then vRouter sets the
outgoing TTL in reverse packet going back to the VM to 1 as well
- If the incoming TTL for the forward flow is 255, then vRouter sets the
outgoing TTL in reverse packet going back to the VM to 255 as well
The second item is useful if the client VM is using GTSM for BGP session.
See https://tools.ietf.org/html/rfc5082. The first item is just paranoia
to further the illusion that the bgp server(s) are directly connected to
the client VM. |
|
| 2016-04-07 18:15:17 |
Nischal Sheth |
description |
When doing SNAT+DNAT for bgpaas it would it be useful to use a new fixed
TTL value for the forward flow. The client VM typically uses a TTL of 1
for its eBGP session by default - this causes problems if user forgets to configure multi hop on the bgp session. Note that the client thinks it's
setting up the session to the default GW and DNS server IPs, so it's not
intuitive to use multi hop.
Proposed fix (from Divakar) is to have agent maintain TTL in flow entry
and when Vrouter sees a non-zero TTL, it copies this value to the packet.
There are 2 additional items that would be nice to have:
- If the incoming TTL for the forward flow is 1, then vRouter sets the
outgoing TTL in reverse packet going back to the VM to 1 as well
- If the incoming TTL for the forward flow is 255, then vRouter sets the
outgoing TTL in reverse packet going back to the VM to 255 as well
The second item is useful if the client VM is using GTSM for BGP session.
See https://tools.ietf.org/html/rfc5082. The first item is just paranoia
to further the illusion that the bgp server(s) are directly connected to
the client VM. |
When doing SNAT+DNAT for bgpaas it would it be useful to use a new fixed
TTL value for the forward flow. The client VM typically uses a TTL of 1
for its eBGP session by default - this causes problems if user forgets to configure multi hop on the bgp session. Note that the client thinks it's
setting up the session to the default GW and DNS server IPs, so it's not
intuitive to use multi hop.
Proposed fix (from Divakar) is to have agent maintain TTL in flow entry
and when Vrouter sees a non-zero TTL, it copies this value to the packet.
The fixed value can be hard coded value like 64 or can be picked up from
net.ipv4.ip_default_ttl sysctl.
There are 2 additional items that would be nice to have:
- If the incoming TTL for the forward flow is 1, then vRouter sets the
outgoing TTL in reverse packet going back to the VM to 1 as well
- If the incoming TTL for the forward flow is 255, then vRouter sets the
outgoing TTL in reverse packet going back to the VM to 255 as well
The second item is useful if the client VM is using GTSM for BGP session.
See https://tools.ietf.org/html/rfc5082. The first item is just paranoia
to further the illusion that the bgp server(s) are directly connected to
the client VM. |
|
| 2016-04-07 18:22:25 |
Nischal Sheth |
description |
When doing SNAT+DNAT for bgpaas it would it be useful to use a new fixed
TTL value for the forward flow. The client VM typically uses a TTL of 1
for its eBGP session by default - this causes problems if user forgets to configure multi hop on the bgp session. Note that the client thinks it's
setting up the session to the default GW and DNS server IPs, so it's not
intuitive to use multi hop.
Proposed fix (from Divakar) is to have agent maintain TTL in flow entry
and when Vrouter sees a non-zero TTL, it copies this value to the packet.
The fixed value can be hard coded value like 64 or can be picked up from
net.ipv4.ip_default_ttl sysctl.
There are 2 additional items that would be nice to have:
- If the incoming TTL for the forward flow is 1, then vRouter sets the
outgoing TTL in reverse packet going back to the VM to 1 as well
- If the incoming TTL for the forward flow is 255, then vRouter sets the
outgoing TTL in reverse packet going back to the VM to 255 as well
The second item is useful if the client VM is using GTSM for BGP session.
See https://tools.ietf.org/html/rfc5082. The first item is just paranoia
to further the illusion that the bgp server(s) are directly connected to
the client VM. |
When doing SNAT+DNAT for bgpaas it would it be useful to use a new fixed
TTL value for the forward flow. The client VM typically uses a TTL of 1
for its eBGP session by default - this causes problems if user forgets to configure multi hop on the bgp session. Note that the client thinks it's
setting up the session to the default GW and DNS server IPs, so it's not
intuitive to use multi hop.
Proposed fix (from Divakar) is to have agent maintain TTL in flow entry
and when Vrouter sees a non-zero TTL, it copies this value to the packet.
The fixed value can be hard coded value like 64 or can be picked up from
net.ipv4.ip_default_ttl sysctl.
There are 2 additional items that would be nice to have:
- If the incoming TTL for the forward flow is 1, then vRouter sets the
outgoing TTL in reverse packet going back to the VM to 1 as well
- If the incoming TTL for the forward flow is 255, then vRouter sets the
outgoing TTL in reverse packet going back to the VM to 255 as well
The second item is useful if the client VM is using GTSM for BGP session.
See https://tools.ietf.org/html/rfc5082.
The first item is just to further the illusion that the bgp server(s) are
directly connected to the client VM. |
|
| 2016-04-26 09:18:18 |
OpenContrail Admin |
juniperopenstack/trunk: status |
New |
In Progress |
|
| 2016-04-27 06:01:04 |
OpenContrail Admin |
nominated for series |
|
juniperopenstack/r3.0 |
|
| 2016-04-27 06:01:04 |
OpenContrail Admin |
bug task added |
|
juniperopenstack/r3.0 |
|
| 2016-04-27 06:01:04 |
OpenContrail Admin |
bug task added |
|
juniperopenstack/r3.0 |
|
| 2016-07-22 10:48:25 |
OpenContrail Admin |
nominated for series |
|
juniperopenstack/r3.1 |
|
| 2016-07-22 10:48:25 |
OpenContrail Admin |
bug task added |
|
juniperopenstack/r3.1 |
|
| 2016-07-22 10:48:25 |
OpenContrail Admin |
bug task added |
|
juniperopenstack/r3.1 |
|
| 2016-08-01 06:26:02 |
OpenContrail Admin |
juniperopenstack/r3.1: status |
In Progress |
Fix Committed |
|
| 2016-08-01 06:26:04 |
OpenContrail Admin |
juniperopenstack/r3.1: milestone |
|
r3.1.0.0-fcs |
|
| 2016-11-01 06:30:42 |
OpenContrail Admin |
nominated for series |
|
juniperopenstack/r3.2 |
|
| 2016-11-01 06:30:42 |
OpenContrail Admin |
bug task added |
|
juniperopenstack/r3.2 |
|
| 2016-11-01 06:30:42 |
OpenContrail Admin |
bug task added |
|
juniperopenstack/r3.2 |
|
| 2016-11-02 05:11:17 |
OpenContrail Admin |
juniperopenstack/trunk: status |
In Progress |
Fix Committed |
|
| 2016-11-02 05:11:19 |
OpenContrail Admin |
juniperopenstack/trunk: milestone |
|
r4.0 |
|
| 2016-11-02 05:12:42 |
OpenContrail Admin |
juniperopenstack/r3.2: status |
In Progress |
Fix Committed |
|
| 2016-11-02 05:12:44 |
OpenContrail Admin |
juniperopenstack/r3.2: milestone |
|
r3.2.0.0-fcs |
|
| 2016-11-17 18:11:03 |
OpenContrail Admin |
juniperopenstack/r3.0: status |
In Progress |
Fix Committed |
|
| 2016-11-17 18:11:04 |
OpenContrail Admin |
juniperopenstack/r3.0: milestone |
|
r3.0.4.0 |
|
