[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-users] Migration of Xen Networking Setup to new ISP
On Tue, 2 Nov 2010 07:53:50 +0100, Simon Hobson <linux@xxxxxxxxxxxxxxxx> wrote: > Thomas Jensen wrote: > >>I currently use pci hide to hide a physical NIC from the Dom0. This >NIC is >>passed to a firewall DomU. Two other NICs are passed to the >firewall DomU >>to create a standard three NIC firewall. The fourth >NIC in the Dom0 is on a >>separate subnet (not part of the firewall) >and is used only for managment of >>the Dom0. >> >>I would like to setup a firewall DomU on the new ISP and then >migrate the >>DomUs to the new firewall one at a time. I am getting >tripped up on the >>fact that my server can't have two gateway >addresses active at one time. > > Well a lot depends on how you want to migrate. There are different > approaches, in part a lot depends on whether you intend to keep the > old ISP going : > I don't plan to keep the old one going once the conversion is completed. > The Big Bang > You switch off the old connection, and turn on the new one. No > complications here, you simply switch configs and wait for the DNS > changes to propagate. Nothing special here except to have all your > configs worked out in advance to minimise downtime. > I am going to move forward with this approach. It has probably been a little more work on my end, but I have been ratcheting down the TTL on all of the DNS records this week. I went from 86400 to 3600 yesterday. This evening, I will ratchet down to 600 and commence the in the middle of the night. I think this will be the most straight forward move and won't require any significant networking changes during the change over. > Dual running > A bit more work, but you parallel run for a while while DNS changes > propagate and eventually turn off the old connection (unless you want > to keep it running). > > Phased migration > You move one bit (service or server) at a time, probably combined > with parallel running. > I had originally thought about implementing a phased approach; essentially having two paths out to the two ISPs running at the same time and moving a DomU from the one to the other one at a time. > You can do policy based routing in your firewall. Setup a new > internal bridge for the new subnet you get from your ISP - it doesn't > need to have a NIC assigned to it. Add extra virtual NICs to the > guests. > I'm not real strong on the whole bridging concept yet and how that translates into Xen space. All of the bridges I currently have now are linked to physical NICs. In at least one case, the physical NIC isn't even physically connected to anything. This NIC would likely be a good candidate for the process you described above. > You then need to set up routing policies (can't help there, never > done it but I know it can be done) so that : > Traffic TO subnet A is routed to the old internal network > Traffic FROM subnet A is routed out via ISP A > Traffic TO subnet B is routed to the new network > Traffic FROM subnet B is routed out via ISP B > > I think you can probably do this by running a shared network with > both subnet A and subnet B on it - ie the extra internal bridge > probably isn't necessary. Something to look into. > > This article explains how it's done with Shorewall (installed by > default on all my systems) > http://shorewall.net/MultiISP.html > I use Shorewall as well on my three NIC firewall. I had done multiple searches online, but hadn't turned up the link you provided. Thanks for the information. > -- > Simon Hobson > > Visit http://www.magpiesnestpublishing.co.uk/ for books by acclaimed > author Gladys Hobson. Novels - poetry - short stories - ideal as > Christmas stocking fillers. Some available as e-books. > > _______________________________________________ > Xen-users mailing list > Xen-users@xxxxxxxxxxxxxxxxxxx > http://lists.xensource.com/xen-users _______________________________________________ Xen-users mailing list Xen-users@xxxxxxxxxxxxxxxxxxx http://lists.xensource.com/xen-users
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |