Hi, I''ve been running xen-unstable quite successfully; the virtual disks and new console code seem fine. I''ve got some problems with the networking though, but I''m not sure if I''m trying to do something that''s impossible with the current VFR code. I''m trying to make Xen''s internal network among the domains available to a vpn: the machine is allocated a network in the vpn, 192.168.101.0/24, and domain 0 has an IP tunnel to the vpn server and a single IP address in that network, 192.168.101.254. This network is made visible from the vpn by routing daemons running in domain 0. This much works and domain 0''s vpn connectivity is fine. The other domains then have addresses in 192.168.101.0/24, e.g. 192.168.101.1 for domain 1, with the address added to the VFR for that domain''s vif 0 and the address added as a secondary on the domain''s eth0. The domain then has a default route via 192.168.101.254. Domain 0 has /proc/sys/net/ipv4/ip_forward set to 1. I can ping between domains, and between domain 0 and other domains using 192.168.101.x addresses. However, while packets from the vpn are correctly routed to domains other than 0, packets from those domains appear directly on the physical ethernet rather than being routed via domain 0 and down the vpn tunnel. This does seem to to be working as designed in that the domain has access to the physical ethernet for addresses which have been added to its vif, but it would be useful for this situation if the packets could go via domain 0. Is this something which can be done with the current code? Cheers, Chris. ------------------------------------------------------- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click _______________________________________________ Xen-devel mailing list Xen-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xen-devel
> However, while packets from the vpn are correctly routed to domains > other than 0, packets from those domains appear directly on the > physical ethernet rather than being routed via domain 0 and down the > vpn tunnel. This does seem to to be working as designed in that the > domain has access to the physical ethernet for addresses which have > been added to its vif, but it would be useful for this situation if the > packets could go via domain 0. Is this something which can be done with > the current code?Yes, it is possible. We do it automatically for 169.254.* addresses --- see setup_vfr_rules_for_vif() in tools/xenctl/lib/utils.py in the Xen source repository. A suitable fix for you is to customise your dom_create script to call a private copy of setup_vfr_rules_for_vif which routes 192.* addresses via DOM0 rather than to the physical net interface. -- Keir ------------------------------------------------------- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click _______________________________________________ Xen-devel mailing list Xen-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xen-devel
> I''m trying to make Xen''s internal network among the domains available > to a vpn: the machine is allocated a network in the vpn, > 192.168.101.0/24, and domain 0 has an IP tunnel to the vpn server and a > single IP address in that network, 192.168.101.254. This network is > made visible from the vpn by routing daemons running in domain 0. This > much works and domain 0''s vpn connectivity is fine. > > The other domains then have addresses in 192.168.101.0/24, e.g. > 192.168.101.1 for domain 1, with the address added to the VFR for that > domain''s vif 0 and the address added as a secondary on the domain''s > eth0. The domain then has a default route via 192.168.101.254. Domain 0 > has /proc/sys/net/ipv4/ip_forward set to 1. I can ping between domains, > and between domain 0 and other domains using 192.168.101.x addresses.With this configuration, the packets will go out on the wire directly as you''ve told it that the whole 192.168.101.0/24 subnet is directly accessible from eth0 Try setting the ip addresses for domains >0 to e.g. 192.168.101.1/32 and then set the default route to go via gateway 192.168.101.254 I haven''t tried this, but it should force all packets to go via domain 0 rather than out via the LAN. (You could set a gateway just for 192.168.101.0/24 if you wanted other packets to go on the LAN directly) Ian> However, while packets from the vpn are correctly routed to domains > other than 0, packets from those domains appear directly on the > physical ethernet rather than being routed via domain 0 and down the > vpn tunnel. This does seem to to be working as designed in that the > domain has access to the physical ethernet for addresses which have > been added to its vif, but it would be useful for this situation if the > packets could go via domain 0. Is this something which can be done with > the current code?------------------------------------------------------- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click _______________________________________________ Xen-devel mailing list Xen-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xen-devel
> With this configuration, the packets will go out on the wire > directly as you''ve told it that the whole 192.168.101.0/24 subnet > is directly accessible from eth0 > > Try setting the ip addresses for domains >0 to > e.g. 192.168.101.1/32 and then set the default route to go via > gateway 192.168.101.254 > > I haven''t tried this, but it should force all packets to go via > domain 0 rather than out via the LAN. (You could set a gateway > just for 192.168.101.0/24 if you wanted other packets to go on > the LAN directly) > > IanNo, this won''t work -- the gotcha is that Xen is forwarding packets based on IP address, not MAC address. This approach will force the destination MAC address of packets to DOM0''s MAC address, but not teh IP address. Unless the dest IP address belongs to another domain running on the machine, the packets will still end up on the physical wire. Also, 192.168.101.254 isn''t in 192.168.101.1/32, so I''m not sure this setup would even get that far --- how would the domain ARP for domain 0''s MAC address? -- Keir ------------------------------------------------------- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click _______________________________________________ Xen-devel mailing list Xen-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xen-devel
On 27 Mar 2004, at 16:50, Keir Fraser wrote:>> However, while packets from the vpn are correctly routed to domains >> other than 0, packets from those domains appear directly on the >> physical ethernet rather than being routed via domain 0 and down the >> vpn tunnel. This does seem to to be working as designed in that the >> domain has access to the physical ethernet for addresses which have >> been added to its vif, but it would be useful for this situation if >> the >> packets could go via domain 0. Is this something which can be done >> with >> the current code? > > Yes, it is possible. We do it automatically for 169.254.* addresses > --- see setup_vfr_rules_for_vif() in tools/xenctl/lib/utils.py in the > Xen source repository. > > A suitable fix for you is to customise your dom_create script to call > a private copy of setup_vfr_rules_for_vif which routes 192.* addresses > via DOM0 rather than to the physical net interface.That seems to work fine: this rule gives domain 1 access to the vpn, and with a NAT rule in domain 0, access to the Internet: ADD ACCEPT srcaddr=192.168.101.1 srcaddrmask=255.255.255.255 dst=ANY srcdom=1 srcidx=0 dstdom=0 dstidx=0 proto=any Is there a way to see what the VFR rules currently are? /proc/xen/vfr can be read but returns nothing. Also, is there any way to flush the VFR rules? Thanks, Chris. ------------------------------------------------------- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click _______________________________________________ Xen-devel mailing list Xen-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xen-devel
> That seems to work fine: this rule gives domain 1 access to the vpn, > and with a NAT rule in domain 0, access to the Internet: > > ADD ACCEPT srcaddr=192.168.101.1 srcaddrmask=255.255.255.255 dst=ANY > srcdom=1 srcidx=0 dstdom=0 dstidx=0 proto=any > > Is there a way to see what the VFR rules currently are? /proc/xen/vfr > can be read but returns nothing. Also, is there any way to flush the > VFR rules?You can delete a rule by echoing a DELETE command to /proc/xen/vfr. e.g., to delete the rule you give as an example above, you would send the following to /proc/xen/vfr: DELETE ACCEPT srcaddr=192.168.101.1 srcaddrmask=255.255.255.255 dst=ANY srcdom=1 srcidx=0 dstdom=0 dstidx=0 proto=any Deletion doesn''t get much testing -- hopefully it won;t wedge the machine. :-) To print the VFR rules, ''echo PRINT >/proc/xen/vfr''. This prints the rule list in a hideous format onto Xen''s emergency console(!). We ought to have a better ''get rules'' interface really, but teh VFR will go away with teh new IO world in a short while. -- Keir ------------------------------------------------------- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click _______________________________________________ Xen-devel mailing list Xen-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xen-devel