On 04/04/2013 12:08 PM, Laine Stump wrote:
On 04/02/2013 03:31 PM, Laine Stump wrote:
On 03/15/2013 02:10 PM, Gene Czarcinski wrote:
This patch adds support for adding a static route for a network. The "via" specifies the gateway's IP address. Both IPv4 and IPv6 static routes are supported although it is expected that this functionality will have more use with IPv6. (First I want to make sure I correctly understand what you're wanting to do, so I'm going to try and explain it in my own words...)
From reading your earlier messages, my understanding is that the aim of this patch is to automatically setup a route to a virtual network whose bridge device has no IP address assigned, and is therefore reachable only via one of the guests, is this correct?
In other words, let's say that I have the following two networks defined (using IPv4 and all static IPs for brevity, but the entire discussion is equally applicable to IPv6):
<network> <name>netVisibleToHost</name> <bridge name='virbr1'/> <forward mode='route'/> <ip address='192.168.200.1' prefix='24'/> </network>
<network> <name>netHiddenFromHost</name> <bridge name='virbr2'/> </network>
and you have a guestDirect that has two interfaces:
<interface type='network'> <!-- 192.168.200.2/24 --> <source network='netVisibleToHost'/> </interface> <interface type='network'> <!-- 192.168.201.1/24 --> <source network='netHiddenFromHost'/> </interface>
and another guestIndirect that has only one interface:
<interface type='network'> <!-- 192.168.201.2/24 --> <source network='netHiddenFromHost'/> </interface>
Additionally, the default route on guestDirect points to 192.168.200.1, and the default route on guestIndirect points to 192.168.201.1.
(Presumably you don't want to simply add an IP address to netHiddenFromHost because (while it would solve your routing problems) it would violate some security policy you've built into your network topology - namely that all traffic to and from netHiddenFromHost *must* go through guestDirect.)
Traffic outbound from guestIndirect would have no problem reaching its destination - it would go across netHiddenFromHost to guestDirect (192.168.201.1), which would know to forward it to the host (192.168.200.1) via netVisibleToHost, and the host presumably knows how to get to anywhere. The problem comes when trying to route the *response* destined for 192.168.201.2 (guestIndirect) - the outside world may know that those packets have to be sent to the host, but the host doesn't have a route for 192.168.201.0/24 - only guestDirect does.
So, the solution is to add a route on the *host* that points traffic destined for 192.168.201.0/24 to guestDirect, a.k.a. 192.168.200.2.
Since there's no place in /etc/sysconfig/network-scripts/route-* to put static routes with destinations that are only reachable through a transient interface such as the bridge devices created by libvirt, the obvious solution is to cause libvirt to add such a route, and the way you propose to do that is to add an <ip> element in the network named "netUnreachable".
Am I understanding the issue so far? I believe you do understand. OK, I am back from virt-manager. Except that it's obvious from your response that I misunderstood your
On 04/03/2013 04:02 PM, Gene Czarcinski wrote: patch, and thought that you were trying to make the route to an otherwise unreachable network a part of the unreachable network's config :-) (my defense is that the dual usage of the <ip> element to define a route confused me) You were correct to be confused. At first, I thought your suggestions for <route> were just cosmetic but then I realized that, in general, an <ip> definition resulted in a specific ".1" or ":1" device address would be assigned to an interface (bridge). The net address looked similar but there would be no device address assigned to the interface/bridge but there would be an entry for a (static) route.
While the backend will continue to be more or less the same and instantiate the static route, the "front" end will add a new element: <route>. I intend to keep "via" for specifying the gateway rather than using "gateway.". This makes it consistent with the ip-route command. So, to add a static would, the text would look like: <route address='<IPv4-network-addr>' prefix='24' via='<IPv4-gateway-addr>' /> or <route family='ipv6' address='<IPv6-net-addr>' prefix='64' via='<IPv6-gateway-addr>' /> More work: I will need to go back and "fix" the virt-manager code.
Based on my now corrected understanding that the route is added to the config of the network which is directly connected to the gateway (rather than the network *beyond* the gateway), I have two comments/requests:
1) I think a separate <route> element is a better idea than trying to make <ip> dual purpose. Aside from confusing simple-minded people like me, when things are intertwined like that it has the potential to lead to an ambiguous situation further down the road. Also, using a separate <route> element is closer to the system config files as well as more similar to the xml used by the virInterface APIs (aka netcf).
Right on ... see above.
2) Although /sbin/ip uses the term "via", I do think that "gateway" would be the preferred term, since that's been in use for many years with the (admittedly now deprecated) /sbin/route command, as well as what is used in the system ifcfg-* and route-* files.
OK, how about having it both ways. If we can have both mask and prefix, why not both via and gateway. I know gateway has some history attached to it but the new /sbin/ip uses via. I am just trying to keep a line of text being as close to not exceeding 80 characters as practical. Correct me if I am wrong but all of this is suppose to be free-form and this should be valid: <route ip='ipv6' address='fd00:dead:beef:472::1' prefix='64' gateway='fd00:dead:beef:10::2' /> Of course, when it gets written back out by code it will all be on a "single" line. How about one of you other folks chiming in on this. gateway? ... via? ... anybody (besides the two of us) care??
3) I would prefer to eliminate use of /sbin/ip and do this directly via netlink/libnl. I would be willing to have this done in a separate patch that also re-wrote virNetDev(Set|Clear)IPAddress.
This is going to take some research, etc. to do so, yes, lets do this "later" as a separate patch and use what we know works for now (kludgy as it is). At least we are now in agreement as to what the end-point is ;) Gene