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
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list
