Re: [libvirt] [PATCH-v4 2/2] Support for static routes on a virtual bridge
On 04/25/2013 04:37 PM, Laine Stump wrote: On 04/25/2013 04:13 PM, Gene Czarcinski wrote: On 04/25/2013 03:13 PM, Gene Czarcinski wrote: On 04/22/2013 11:59 AM, Laine Stump wrote: address should be optional unless prefix or netmask is non-0, although I've now noticed that won't be handled properly due to virSocketAddrGetIpPrefix returning -1 when there is no address or prefix or netmask (I'm fixing that before I push that patch, so you can just toss your 1/2 patch, rebase, and assume it's fixed). I have most of the stuff reworked except for the address, gateway, netmask, and prefix code. Getting all of those balanced so they work correctly is a bit tricky.. 1. For route, I am requiring that both address= and gateway= be specified with address='0.0.0.0' and address='::' being valid addresses. For IPv4, netmask='0.0.0.0' works correctly but prefix=0 does not. For IPv4, address='0.0.0.0' results in a default route. I am not sure what all these extra default routes are going to do to things but lets not get in the way of the experimenter. For IPv6, this address='::', prefix='0' is a slightly different matter as default routes are usually handled differently. I am going to go ahead and implement it but I am not sure it is a good idea. Normally, if you do not specify a prefix for IPv6, the default is 64. But if you do specify one, then it will be used. It is getting real close and it should be ready real soon now ;)) AAGH With IPv4 using address='0.0.0.0' and netmask='0.0.0.0' things work just fine but with prefix not so much. The problem is that with prefix=0, it is not in the xml which then results it it defaulting at a later time. This is an extreme corner case. Usually a zero prefix is just ignored. Defaulting to what? I thought that when I pushed the utility function for that, I modified it to return a prefix of 0 if the address was 0.0.0.0 and neither netmask nor prefix was set. I guess it might be problematic if address was *not* 0 and you wanted an explicit 0 prefix, but I don't think that would ever be useful. If you really want prefix to show up in the xml if someone explicitly puts prefix='0' in there, you can add a bool prefix_specified; to the object, and set that when you see a prefix, even if it's 0. Then in the formatter you'll know that you should write out the value of prefix, even if it's 0. There are a few examples of doing this in either the network or domain xml parser/formatter - just search for occurrences of the word _specified in src/conf/*.[ch] and you'll find them. OK, I have been trying all kinds of things in network_conf.c (which I now need to go back an clean up/simplify) because it is not the problem. The real problem is in virSocketAddrGetIpPrefix(). For IPv4, a valid address is '0.0.0.0' and for IPv6 a similar address is '::' and both are valid addresses. For IPv4, if a netmask of '0.0.0.0' is specified, things work but a prefix=0 is ignored/overridden. For IPv6, the prefix=0 is also overriden with the default of 64. To get this to work, I have to pass INVALID IPv4 and IPv6 addresses or not use the routine if the zero addresses are specified. If the addresses are zero, then I believe we can correctly assume that a prefix of zero is also correct. This code needs to be in bridge_driver.c. Gene -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH-v4 2/2] Support for static routes on a virtual bridge
On 04/26/2013 09:16 AM, Gene Czarcinski wrote: On 04/25/2013 04:37 PM, Laine Stump wrote: On 04/25/2013 04:13 PM, Gene Czarcinski wrote: On 04/25/2013 03:13 PM, Gene Czarcinski wrote: On 04/22/2013 11:59 AM, Laine Stump wrote: address should be optional unless prefix or netmask is non-0, although I've now noticed that won't be handled properly due to virSocketAddrGetIpPrefix returning -1 when there is no address or prefix or netmask (I'm fixing that before I push that patch, so you can just toss your 1/2 patch, rebase, and assume it's fixed). I have most of the stuff reworked except for the address, gateway, netmask, and prefix code. Getting all of those balanced so they work correctly is a bit tricky.. 1. For route, I am requiring that both address= and gateway= be specified with address='0.0.0.0' and address='::' being valid addresses. For IPv4, netmask='0.0.0.0' works correctly but prefix=0 does not. For IPv4, address='0.0.0.0' results in a default route. I am not sure what all these extra default routes are going to do to things but lets not get in the way of the experimenter. For IPv6, this address='::', prefix='0' is a slightly different matter as default routes are usually handled differently. I am going to go ahead and implement it but I am not sure it is a good idea. Normally, if you do not specify a prefix for IPv6, the default is 64. But if you do specify one, then it will be used. It is getting real close and it should be ready real soon now ;)) AAGH With IPv4 using address='0.0.0.0' and netmask='0.0.0.0' things work just fine but with prefix not so much. The problem is that with prefix=0, it is not in the xml which then results it it defaulting at a later time. This is an extreme corner case. Usually a zero prefix is just ignored. Defaulting to what? I thought that when I pushed the utility function for that, I modified it to return a prefix of 0 if the address was 0.0.0.0 and neither netmask nor prefix was set. I guess it might be problematic if address was *not* 0 and you wanted an explicit 0 prefix, but I don't think that would ever be useful. If you really want prefix to show up in the xml if someone explicitly puts prefix='0' in there, you can add a bool prefix_specified; to the object, and set that when you see a prefix, even if it's 0. Then in the formatter you'll know that you should write out the value of prefix, even if it's 0. There are a few examples of doing this in either the network or domain xml parser/formatter - just search for occurrences of the word _specified in src/conf/*.[ch] and you'll find them. OK, I have been trying all kinds of things in network_conf.c (which I now need to go back an clean up/simplify) because it is not the problem. The real problem is in virSocketAddrGetIpPrefix(). For IPv4, a valid address is '0.0.0.0' and for IPv6 a similar address is '::' and both are valid addresses. For IPv4, if a netmask of '0.0.0.0' is specified, things work but a prefix=0 is ignored/overridden. For IPv6, the prefix=0 is also overriden with the default of 64. To get this to work, I have to pass INVALID IPv4 and IPv6 addresses or not use the routine if the zero addresses are specified. If the addresses are zero, then I believe we can correctly assume that a prefix of zero is also correct. This code needs to be in bridge_driver.c. OK, here is the latest. For IPv4. all this stuff with prefix=0 or netmask=0.0.0.0 and address=0.0.0.0 works. For IPv6, anything involving prefix=0 does not appear to work. In fact, it gets an error in syslog (you know, one of those conditions I mentioned that are best ignored so that the bridge interface does not get totally hosed). Here is the message that appears in syslog: - Apr 26 15:09:57 falcon libvirtd: 18332: error : virCommandWait:2315 : internal error Child process (/usr/sbin/ip route add ::/0 via fd00:beef:10:93::2:5 dev virbr15 proto static metric 1) unexpected exit status 2: RTNETLINK answers: File exists Other IPv6 static routes seem to work just fine. I was able to replicate the error by having a network definition with two identical ipv6 static route definitions. However, the first IPv6 route showed up in ip -6 route. Anyway, at this point I believe I have two choices: 1. proceed and ignore the IPv6 ::/0 error (IMHO: bad idea). 2. For ::/0, do not do the static route but instead issue an error message that states this is not supported (my preferred solution). Comments? Suggestion?? Direction?? Gene -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH-v4 2/2] Support for static routes on a virtual bridge
On 04/22/2013 11:59 AM, Laine Stump wrote: address should be optional unless prefix or netmask is non-0, although I've now noticed that won't be handled properly due to virSocketAddrGetIpPrefix returning -1 when there is no address or prefix or netmask (I'm fixing that before I push that patch, so you can just toss your 1/2 patch, rebase, and assume it's fixed). I have most of the stuff reworked except for the address, gateway, netmask, and prefix code. Getting all of those balanced so they work correctly is a bit tricky.. 1. For route, I am requiring that both address= and gateway= be specified with address='0.0.0.0' and address='::' being valid addresses. For IPv4, netmask='0.0.0.0' works correctly but prefix=0 does not. For IPv4, address='0.0.0.0' results in a default route. I am not sure what all these extra default routes are going to do to things but lets not get in the way of the experimenter. For IPv6, this address='::', prefix='0' is a slightly different matter as default routes are usually handled differently. I am going to go ahead and implement it but I am not sure it is a good idea. Normally, if you do not specify a prefix for IPv6, the default is 64. But if you do specify one, then it will be used. It is getting real close and it should be ready real soon now ;)) Gene -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH-v4 2/2] Support for static routes on a virtual bridge
On 04/25/2013 03:13 PM, Gene Czarcinski wrote: On 04/22/2013 11:59 AM, Laine Stump wrote: address should be optional unless prefix or netmask is non-0, although I've now noticed that won't be handled properly due to virSocketAddrGetIpPrefix returning -1 when there is no address or prefix or netmask (I'm fixing that before I push that patch, so you can just toss your 1/2 patch, rebase, and assume it's fixed). I have most of the stuff reworked except for the address, gateway, netmask, and prefix code. Getting all of those balanced so they work correctly is a bit tricky.. 1. For route, I am requiring that both address= and gateway= be specified with address='0.0.0.0' and address='::' being valid addresses. For IPv4, netmask='0.0.0.0' works correctly but prefix=0 does not. For IPv4, address='0.0.0.0' results in a default route. I am not sure what all these extra default routes are going to do to things but lets not get in the way of the experimenter. For IPv6, this address='::', prefix='0' is a slightly different matter as default routes are usually handled differently. I am going to go ahead and implement it but I am not sure it is a good idea. Normally, if you do not specify a prefix for IPv6, the default is 64. But if you do specify one, then it will be used. It is getting real close and it should be ready real soon now ;)) AAGH With IPv4 using address='0.0.0.0' and netmask='0.0.0.0' things work just fine but with prefix not so much. The problem is that with prefix=0, it is not in the xml which then results it it defaulting at a later time. This is an extreme corner case. Usually a zero prefix is just ignored. Gene -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH-v4 2/2] Support for static routes on a virtual bridge
On 04/25/2013 02:13 PM, Gene Czarcinski wrote: It is getting real close and it should be ready real soon now ;)) AAGH With IPv4 using address='0.0.0.0' and netmask='0.0.0.0' things work just fine but with prefix not so much. The problem is that with prefix=0, it is not in the xml which then results it it defaulting at a later time. Is it getting defaulted back to 0? In the past, if we have XML elements that can validly be 0, but where 0 is not the default, it works to add a witness field (has_prefix); if has_prefix is true, then use prefix instead of defaulting to a non-zero prefix that we normally use. Yeah, it's a bit of a pain, but it's not the first time. -- Eric Blake eblake redhat com+1-919-301-3266 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH-v4 2/2] Support for static routes on a virtual bridge
On 04/25/2013 04:13 PM, Gene Czarcinski wrote: On 04/25/2013 03:13 PM, Gene Czarcinski wrote: On 04/22/2013 11:59 AM, Laine Stump wrote: address should be optional unless prefix or netmask is non-0, although I've now noticed that won't be handled properly due to virSocketAddrGetIpPrefix returning -1 when there is no address or prefix or netmask (I'm fixing that before I push that patch, so you can just toss your 1/2 patch, rebase, and assume it's fixed). I have most of the stuff reworked except for the address, gateway, netmask, and prefix code. Getting all of those balanced so they work correctly is a bit tricky.. 1. For route, I am requiring that both address= and gateway= be specified with address='0.0.0.0' and address='::' being valid addresses. For IPv4, netmask='0.0.0.0' works correctly but prefix=0 does not. For IPv4, address='0.0.0.0' results in a default route. I am not sure what all these extra default routes are going to do to things but lets not get in the way of the experimenter. For IPv6, this address='::', prefix='0' is a slightly different matter as default routes are usually handled differently. I am going to go ahead and implement it but I am not sure it is a good idea. Normally, if you do not specify a prefix for IPv6, the default is 64. But if you do specify one, then it will be used. It is getting real close and it should be ready real soon now ;)) AAGH With IPv4 using address='0.0.0.0' and netmask='0.0.0.0' things work just fine but with prefix not so much. The problem is that with prefix=0, it is not in the xml which then results it it defaulting at a later time. This is an extreme corner case. Usually a zero prefix is just ignored. Defaulting to what? I thought that when I pushed the utility function for that, I modified it to return a prefix of 0 if the address was 0.0.0.0 and neither netmask nor prefix was set. I guess it might be problematic if address was *not* 0 and you wanted an explicit 0 prefix, but I don't think that would ever be useful. If you really want prefix to show up in the xml if someone explicitly puts prefix='0' in there, you can add a bool prefix_specified; to the object, and set that when you see a prefix, even if it's 0. Then in the formatter you'll know that you should write out the value of prefix, even if it's 0. There are a few examples of doing this in either the network or domain xml parser/formatter - just search for occurrences of the word _specified in src/conf/*.[ch] and you'll find them. -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] [PATCH-v4 2/2] Support for static routes on a virtual bridge
This patch adds support for adding a static route for a network. The gateway sub-element 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. This updates add the route element to define a static route. The gateway= subelement species the gateway address which is to receive the packets forwarded to the network specified on the route definition. Tests are done to validate that the input definitions are correct. For example, for a static route ip definition, the address must be a network address and not a host address. Additional checks are added to ensure that the specified gateway is directly reachable via a network defined on this bridge. Whan a static route is added to a bridge, there is a slight possibility that the gateway address will be incorrect. If this is handled as an error, that bridge becomes unusable and can only be recovered by rebooting. If the error is ignored, then that network can be destroyed and the network definition file edited to correct the problem. Unfortunately, the error message only appears in syslog. However, with the checks performed when the network definition file is parsed, it is unlikely that this condition will ever occur. Handling of errors in this manner is consistent with other uses of the CommandRun interface. The command used is of the following form: ip route add address/prefix via gateway dev virbr-bridge \ proto static metric 1 . Signed-off-by: Gene Czarcinski g...@czarc.net --- docs/formatnetwork.html.in | 80 + docs/schemas/network.rng | 22 ++ src/conf/network_conf.c| 334 - src/conf/network_conf.h| 20 ++ src/libvirt_private.syms | 1 + src/network/bridge_driver.c| 41 +++ src/util/virnetdev.c | 44 +++ src/util/virnetdev.h | 5 + .../networkxml2xmlin/dhcp6host-routed-network.xml | 2 + .../networkxml2xmlout/dhcp6host-routed-network.xml | 2 + 10 files changed, 550 insertions(+), 1 deletion(-) diff --git a/docs/formatnetwork.html.in b/docs/formatnetwork.html.in index 4dd0415..cbf4a5c 100644 --- a/docs/formatnetwork.html.in +++ b/docs/formatnetwork.html.in @@ -529,6 +529,60 @@ starting. /p +h5a name=elementsStaticrouteStatic Routes/a/h5 +p + It has been possible to define static routes on a virtual bridge + device span class=sinceSince 1.0.5/span. Static route + definitions are used to provide routing information to the + virtualization host for networks which are not defined as a + network on one of the virtual bridges on the virtualization host. +/p + +p + As shown in a href=formatnetwork.html#examplesNoGatewaythis example/a, + it is possible to define a virtual bridge interface with no + IPv4 or IPv6 networks. Such interfaces are useful in supporting + networks which have no visibility or direct connectivity with the + virtualization host, but can be used to support + virtual networks which only have guest connectivity. A guest + with connectivity to the guest-only network and another network + that is directly reachable from the host can act as a gateway between the + networks. A static route added to the visible network definition + provides the routing information so that IP packets can be sent + from the virtualization host to guests on the hidden network. +/p + +p + Here is a fragment of a definition which shows the static + route specification as well as the IPv4 and IPv6 definitions + for network addresses which are referred to in the + codegateway/code gateway address specifications. +/p + +pre + ... +lt;ip address=192.168.122.1 netmask=255.255.255.0gt; + lt;dhcpgt; +lt;range start=192.168.122.128 end=192.168.122.254 /gt; + lt;/dhcpgt; +lt;/ipgt; +lt;route address=192.168.222.0 prefix=24 gateway=192.168.122.2 /gt; +lt;ip family=ipv6 address=2001:db8:ca2:2::1 prefix=64 /gt; +lt;route family=ipv6 address=2001:db8:ca2:3:: prefix=64 gateway=2001:db8:ca2:2::2gt; +lt;/routegt; + ... +/pre + +p + Notice that the coderoute/code elements look very similar to + the codeip/code address specification. Although parts are the same, + the meaning and effects of the two elements are very different. The + codeip/code address specification results in an address being defined + on the virtual bridge whereas the coderoute/code definition is used + to create the static route for the specified network via the gateway address + on the virtual bridge device. +/p + h3a name=elementsAddressAddressing/a/h3
