cloudstack-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Remi Bergsma (JIRA)" <j...@apache.org>
Subject [jira] [Resolved] (CLOUDSTACK-9143) Setup routes for RFC 1918 ip space
Date Sat, 12 Dec 2015 08:54:46 GMT

     [ https://issues.apache.org/jira/browse/CLOUDSTACK-9143?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Remi Bergsma resolved CLOUDSTACK-9143.
--------------------------------------
    Resolution: Fixed

PR merged

> Setup routes for RFC 1918 ip space
> ----------------------------------
>
>                 Key: CLOUDSTACK-9143
>                 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9143
>             Project: CloudStack
>          Issue Type: Bug
>      Security Level: Public(Anyone can view this level - this is the default.) 
>          Components: Virtual Router
>            Reporter: Remi Bergsma
>            Assignee: Remi Bergsma
>            Priority: Critical
>             Fix For: 4.7.0
>
>
> 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 space that is meant for internal
use). More specific routes that may be set have preference over this generic routes so this
works even with private ranges used for public ip space (as shown below).
> When using an internal DNS server some hosts may resolve to an RFC 1918 ip address. The
SSVM has a default gw to public so if it has no route for this ip address space, it will not
work. This PR makes generic RFC 1918 (so all internal ip adresses like 10.0.0.10 etc) to the
local management gateway. This makes them reachable. Without this fix, it is sent upstream
and it is dropped there.
> Should there be a more generic route (smaller prefix), this has preference over the generic
routes.
> Example in my dev environment:
> ```
> root@v-1-VM:~# route -n
> Kernel IP routing table
> Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
> 0.0.0.0         192.168.23.1    0.0.0.0         UG    0      0        0 eth2
> 10.0.0.0        192.168.22.1    255.0.0.0       UG    0      0        0 eth1
> 169.254.0.0     0.0.0.0         255.255.0.0     U     0      0        0 eth0
> 172.16.0.0      192.168.22.1    255.240.0.0     UG    0      0        0 eth1
> 192.168.0.0     192.168.22.1    255.255.0.0     UG    0      0        0 eth1
> 192.168.22.0    0.0.0.0         255.255.255.0   U     0      0        0 eth1
> 192.168.23.0    0.0.0.0         255.255.255.0   U     0      0        0 eth2
> ```
> Route `192.168.0.0/16` goes via `eth1` but `192.168.23.0/24` is more specific and has
preference and goes via `eth2`. It works:
> ```
> root@v-1-VM:~# ping 8.8.8.8
> PING 8.8.8.8 (8.8.8.8): 48 data bytes
> 56 bytes from 8.8.8.8: icmp_seq=0 ttl=49 time=7.179 ms
> ^C--- 8.8.8.8 ping statistics ---
> 1 packets transmitted, 1 packets received, 0% packet loss
> round-trip min/avg/max/stddev = 7.179/7.179/7.179/0.000 ms
> ```
> This solves a lot of the 'internal resolving' issues we face.
> When the public ip address is RFC1918 itself, we do not set the routes.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Mime
View raw message