Changing ISP smoothly..

Ok, time to bite the bullet and get rid of a load of legacy junk.

Currently I have two phone lines, one of which has broadband, and whose
number I do not want to keep.

The other does not, and I would like broadband on that with a new supplier.

I run various domains hosted on my own (internal) web server.

I manage a few sites who will reject me unless I am on my old IP
address. Until reconfigured..

I have multiple domains also hosted elsewhere mainly for e-mail: These
will eventually be rationalised.

What I have decided to do is the following, and I would like the
technically knowledgeable to see if there are any flaws.

1/. Move the phone line I want to keep to IDNET. My supplier of choice.

2/. Enable broadband on that line.

3/. Add a second router, with DHCP temporarily disabled so that the main
router is still there and is the natural default route.

4/. configure port 80 passthrough on the new router to point at my
(web)server.

5/. Change all my public sites to point to the new static IP address. By
my reckoning the packets will all come in eventually by the new router,
but return traffic will go out of the old one?

6/. wait a few days for DNS to settle down to the new addresses.

7/. using my old router still as the default, reconfigure all the remote
firewalls to accept the new address also.

8/. Temporarily switch to the new router and check accessibility on the
new IP address. At this point the new ADSL becomes the default route.

9/. Move all mail clients to send via IDNET'S SMTP relay.

10/. enable DHCP and reboot all desktops to pick up the new router as
default route.

11/. Cancel original ISP.

12/. Cancel unwanted BT line

...and then set to work on the *externally* hosted domains..:-)

In article <h6ulhj$181$(E-Mail Removed)>,
The Natural Philosopher <(E-Mail Removed)> wrote:
>Ok, time to bite the bullet and get rid of a load of legacy junk.
>
>Currently I have two phone lines, one of which has broadband, and whose
>number I do not want to keep.
>
>The other does not, and I would like broadband on that with a new supplier.
>
>I run various domains hosted on my own (internal) web server.
>
>I manage a few sites who will reject me unless I am on my old IP
>address. Until reconfigured..
>
>I have multiple domains also hosted elsewhere mainly for e-mail: These
>will eventually be rationalised.
>
>What I have decided to do is the following, and I would like the
>technically knowledgeable to see if there are any flaws.
>
>1/. Move the phone line I want to keep to IDNET. My supplier of choice.
>
>2/. Enable broadband on that line.
>
>3/. Add a second router, with DHCP temporarily disabled so that the main
>router is still there and is the natural default route.
>
>4/. configure port 80 passthrough on the new router to point at my
>(web)server.
>
>5/. Change all my public sites to point to the new static IP address. By
>my reckoning the packets will all come in eventually by the new router,
>but return traffic will go out of the old one?

Remember to add a new virtual hosts entry for the new IP address for
each site.

Also - asymetric routing - it should work... And I don't know of any
ISP at present who block it if they see it, but you never know.

I'd drop the TTL on your domains a few weeks in advance, if you have
that level of control over them.


>6/. wait a few days for DNS to settle down to the new addresses.
>
>7/. using my old router still as the default, reconfigure all the remote
>firewalls to accept the new address also.

You should do this as soon as you know your new IP address. Allow both old
and new for a while. Not that I'm speaking from experience or anything,
oh no...

>8/. Temporarily switch to the new router and check accessibility on the
>new IP address. At this point the new ADSL becomes the default route.
>
>9/. Move all mail clients to send via IDNET'S SMTP relay.
>
>10/. enable DHCP and reboot all desktops to pick up the new router as
>default route.

You need to reboot? Shouldn't - even with windows. (Athough it might be
easier than typing the command, or using the "repair" option)

>11/. Cancel original ISP.
>
>12/. Cancel unwanted BT line
>
>..and then set to work on the *externally* hosted domains..:-)

Good luck!

Gordon

Gordon Henderson wrote:

> In article <h6ulhj$181$(E-Mail Removed)>,
> The Natural Philosopher <(E-Mail Removed)> wrote:

>>5/. Change all my public sites to point to the new static IP address. By
>>my reckoning the packets will all come in eventually by the new router,
>>but return traffic will go out of the old one?

> Also - asymetric routing - it should work... And I don't know of any
> ISP at present who block it if they see it, but you never know.

I reckon it won't work. NAT routers/firewalls [for one] seeing responses
coming back from an IP address they didn't request them from will ignore the
traffic, and the browser will just think your site is unresponsive.

If you do manage to get a port forward working via a router that isn't the
default route for the given server, I would be interested to know how you
did it.

--
<http://ale.cx/> (AIM:troffasky) ((E-Mail Removed))
22:23:45 up 110 days, 14:57, 3 users, load average: 0.17, 0.31, 0.23
"If being trapped in a tropical swamp with Anthony Worral-Thompson and
Christine Hamilton is reality then I say, pass the mind-altering drugs"
-- Humphrey Lyttleton

alexd wrote:
> Gordon Henderson wrote:
>
>> In article <h6ulhj$181$(E-Mail Removed)>,
>> The Natural Philosopher <(E-Mail Removed)> wrote:
>
>>> 5/. Change all my public sites to point to the new static IP address. By
>>> my reckoning the packets will all come in eventually by the new router,
>>> but return traffic will go out of the old one?
>
>> Also - asymetric routing - it should work... And I don't know of any
>> ISP at present who block it if they see it, but you never know.
>
> I reckon it won't work. NAT routers/firewalls [for one] seeing responses
> coming back from an IP address they didn't request them from will ignore the
> traffic, and the browser will just think your site is unresponsive.
>

OK, is that a fair point? MM. yes, it probably is. the responses will
come from a different IP address. I'll ponder that one.
..

> If you do manage to get a port forward working via a router that isn't the
> default route for the given server, I would be interested to know how you
> did it.
>

Its should not be beyond the wit of man.. actually there is one simple
way to do it. I can add a second interface on a different subnet, to the
(Linux) server, and bind a second default route to that. Nasty, but I've
done it often enough to set up routers..

That will allow symmetrical routing via either virtual interface.

So in effect my server will have two IP addresses on two interfaces with
a separate default route for either..if IP forwarding is off on it, it
won't then magically route between the two
..

So
#ifconfig etho:1 192.168.2.100
to set up a second interface on eth0:1 and

#route add default gw 192.168.2.1 eth0:1

for example..

Actually, its a fair way to make a resilient-ish server using twin DSL
if you have split DNS 'A' records.. or use DYNDNS for 'failover' DNS..

I cant remember what selects from a pair of equivalent default routes
for outbound connections. I do remember that one an NT server that was
giving precisely 50% packet loss, it simply picked alternately :-)

I do know that once a server is bound to a given interface, it will
return packets via that interface, so the question would be as to how to
bind apache to both...aha. It listens on all unless told not to. So no
issues there.

Looks like you spotted the flaw, and there is a simple enough workaround.

I wonder what happens to desktops if you have TWO DHCP servers running.

The Natural Philosopher wrote:

> Looks like you spotted the flaw, and there is a simple enough workaround.

This may be of interest, if you've got a spare weekend:

http://kindlund.wordpress.com/2007/1...tiple-default-
routes-in-linux/

> I wonder what happens to desktops if you have TWO DHCP servers running.

If both are giving out correct information and non-overlapping, I should
have thought users would be none the wiser.

--
<http://ale.cx/> (AIM:troffasky) ((E-Mail Removed))
23:07:30 up 110 days, 15:40, 3 users, load average: 0.08, 0.20, 0.26
"If being trapped in a tropical swamp with Anthony Worral-Thompson and
Christine Hamilton is reality then I say, pass the mind-altering drugs"
-- Humphrey Lyttleton

alexd wrote:
> The Natural Philosopher wrote:
>
>> Looks like you spotted the flaw, and there is a simple enough workaround.
>
> This may be of interest, if you've got a spare weekend:
>
> http://kindlund.wordpress.com/2007/1...tiple-default-
> routes-in-linux/
>

Hmm. I THOUGHT that was the default behaviour without having to set up
explicit routes..

I.e. that servers will respond via the interface to which they are
bound..and from which they receive IP requests..

Ping might not..

Oh well if it doesn't work the simpler way, that will assuredly work.




>> I wonder what happens to desktops if you have TWO DHCP servers running.
>
> If both are giving out correct information and non-overlapping, I should
> have thought users would be none the wiser.
>

Hmm. I tried it at one stage and things just hung, but the software was
'experimental' to say the least.

Dennis Ferguson wrote:
> On 2009-08-24, The Natural Philosopher <(E-Mail Removed)> wrote:
>> 3/. Add a second router, with DHCP temporarily disabled so that the main
>> router is still there and is the natural default route.
>>
>> 4/. configure port 80 passthrough on the new router to point at my
>> (web)server.
>>
>> 5/. Change all my public sites to point to the new static IP address. By
>> my reckoning the packets will all come in eventually by the new router,
>> but return traffic will go out of the old one?
>
> This bit confuses me a bit.
>
> If your server is configured with a public IP address now there should
> be a step in there where you add a second public address to the same
> interface. The need for this probably precludes the server from using
> DHCP for any configuration at all, so you'll be manually configuring
> the default route in the server too (if you aren't already) and can point
> it at which ever router suits you. Note, however, that it is
> current best practice for ISPs to filter out traffic from customers
> with source addresses other than those assigned by that ISP, and while
> many (most?) ISPs don't bother with this you'll want to make sure that
> one of your ISPs is among the latter or the asymmetry in the choice of
> inbound and outbound ISP won't work. Some host firewall filters will
> let you redirect host-generated outbound packets based on source address,
> in effect allowing you to pick a default route based on the source address
> of the packet you are sending, so if your server is capable of this you
> may be able to straighten out the asymmetry for inbound connections this
> way.
>
> On the other hand if your server is configured with a private IP
> address only, and you are configuring your router to forward port
> 80 via NAT to get those packets to the server, then asymmetric routing
> of the return packets for inbound connections simply won't work. In
> this case the only way I know to make this work is to configure a
> second private address on the server, have each of the routers forward
> packets to the server using a separate private address, and then
> in the server use outbound packet filtering based on source address to
> get the outbound packets back to the same router as the inbound
> packets arrived from.
>
> In either case it seems like you'll need a step in there where
> you configure your server with a second address.
>
> Dennis Ferguson

Yup. read on..you are not the only one to point that out..

The only issue seems to be whether or not I need to set up split routing
tables.

Still even that is not a great pain really.

Mark wrote:
> On Mon, 24 Aug 2009 19:18:28 +0100, The Natural Philosopher
> <(E-Mail Removed)> wrote:
>
>> Ok, time to bite the bullet and get rid of a load of legacy junk.
>>
>> Currently I have two phone lines, one of which has broadband, and whose
>> number I do not want to keep.
>>
>> The other does not, and I would like broadband on that with a new supplier.
>>
>> I run various domains hosted on my own (internal) web server.
>>
>> I manage a few sites who will reject me unless I am on my old IP
>> address. Until reconfigured..
>>
>> I have multiple domains also hosted elsewhere mainly for e-mail: These
>> will eventually be rationalised.
>>
>> What I have decided to do is the following, and I would like the
>> technically knowledgeable to see if there are any flaws.
>>
>> 1/. Move the phone line I want to keep to IDNET. My supplier of choice.
>>
>> 2/. Enable broadband on that line.
>>
>> 3/. Add a second router, with DHCP temporarily disabled so that the main
>> router is still there and is the natural default route.
>>
>> 4/. configure port 80 passthrough on the new router to point at my
>> (web)server.
>>
>> 5/. Change all my public sites to point to the new static IP address. By
>> my reckoning the packets will all come in eventually by the new router,
>> but return traffic will go out of the old one?
>>
>> 6/. wait a few days for DNS to settle down to the new addresses.
>>
>> 7/. using my old router still as the default, reconfigure all the remote
>> firewalls to accept the new address also.
>>
>> 8/. Temporarily switch to the new router and check accessibility on the
>> new IP address. At this point the new ADSL becomes the default route.
>>
>> 9/. Move all mail clients to send via IDNET'S SMTP relay.
>>
>> 10/. enable DHCP and reboot all desktops to pick up the new router as
>> default route.
>>
>> 11/. Cancel original ISP.
>>
>> 12/. Cancel unwanted BT line
>>
>> ..and then set to work on the *externally* hosted domains..:-)
>
> Remember it is possible that your second line uses a different route
> to the exchange and may sync at a lower speed when it is broadband
> enabled.
>
Not a worry for me.

I am actually slightly more short of upload speed.

And in any case the BRAS will screw me down to the nearest 500kbps..I'm
currently synching in the 4600-5300 range, but never get more than 4000
actual transfer rates.