[libvirt] [PATCH] v2:Support for adding a static route to a bridge

[Gene Czarcinski]

On 04/04/2013 12:08 PM, Laine Stump wrote:
> 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.
OK, I am back from virt-manager.
> 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)
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