On 04/03/2013 04:02 PM, Gene Czarcinski 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. Except that it's obvious from your response that I misunderstood your 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) 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). 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. 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. -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list