Github user wilderrodrigues commented on the pull request:
https://github.com/apache/cloudstack/pull/1214#issuecomment-164003619
Put some time in reading the RFC - yes, I actually did - and also went
through the code (with the latest changes). It LGTM :+1:
I think last @terbo
Github user remibergsma commented on the pull request:
https://github.com/apache/cloudstack/pull/1214#issuecomment-163980980
@terbolous If you'd use a setup like that, you'd also use NAT in which case
it will still work. I think we're fine.
---
If your project is set up for it, you c
Github user remibergsma commented on the pull request:
https://github.com/apache/cloudstack/pull/1214#issuecomment-163980356
Integration tests pass:
```
nosetests --with-marvin --marvin-config=${marvinCfg} -s -a
tags=advanced,required_hardware=true \
component/test_pas
Github user terbolous commented on the pull request:
https://github.com/apache/cloudstack/pull/1214#issuecomment-163912372
Although it is technically possible to use official ip address space on the
public network with routes to rfc1918 I don't know if those scenarios are
widespread o
Github user remibergsma commented on the pull request:
https://github.com/apache/cloudstack/pull/1214#issuecomment-163908940
@terbolous I found an easier solution. When the public nic is on RFC1918,
we do not set the routes. When it is a real public ip, we can safely set the
routes. M
Github user terbolous commented on the pull request:
https://github.com/apache/cloudstack/pull/1214#issuecomment-163906540
Not sure how easy it is to implement, but a configuration setting for
'route rfc1918 per default via the internal network' would probably satisy my
worries as the
Github user remibergsma commented on the pull request:
https://github.com/apache/cloudstack/pull/1214#issuecomment-163905174
@terbolous OK, I see what you mean. Let me have a look and handle this
scenario.
---
If your project is set up for it, you can reply to this email and have you
Github user terbolous commented on the pull request:
https://github.com/apache/cloudstack/pull/1214#issuecomment-16388
My point would be a setup like this:
Management network: 10.1.1.0/24 - this is the internal network on eth2
Configured public network: 172.16.1.0/24 -
Github user remibergsma commented on the pull request:
https://github.com/apache/cloudstack/pull/1214#issuecomment-163898820
Working console:
Github user remibergsma commented on the pull request:
https://github.com/apache/cloudstack/pull/1214#issuecomment-163895685
@terbolous I appreciate your worries, and I'll try to explain why I think
there is nothing to worry about.
Right now, everything that has no specific ro
Github user terbolous commented on the pull request:
https://github.com/apache/cloudstack/pull/1214#issuecomment-163867518
Might only be me, but I think it is a bit assumptious to assume that the
internal network is routable for everyone. To clarify I am mostly worried about
the conso
Github user remibergsma commented on the pull request:
https://github.com/apache/cloudstack/pull/1214#issuecomment-163865718
@terbolous In the example above, I show a cloud that uses RFC1918 space
only. That works fine, as these routes are more specific than the generic ones
I add.
Github user terbolous commented on the pull request:
https://github.com/apache/cloudstack/pull/1214#issuecomment-163862541
What about users who solely use rfc1918 address space? That could easily be
the case for internal or enterprise users.
I am in doubt about this change, as I fe
GitHub user remibergsma opened a pull request:
https://github.com/apache/cloudstack/pull/1214
Setup routes for RFC 1918 ip space
Setup general route for RFC 1918 space, as otherwise it will be sent to the
public gateway and likely to be dropped (internet providers do not route ip
s
14 matches
Mail list logo
