From: | Alex Pilosov <alex(at)pilosoft(dot)com> |
---|---|
To: | thomas(at)pgsql(dot)com |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: cvsup trouble |
Date: | 2001-09-21 17:10:50 |
Message-ID: | Pine.BSO.4.10.10109211308590.3287-100000@spider.pilosoft.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Fri, 21 Sep 2001, Thomas Lockhart wrote:
> > $ ping cvsup.postgresql.org
> > PING rs.postgresql.org: 64 byte packets
> > 64 bytes from 64.39.15.238: icmp_seq=0. time=57. ms
> > 64 bytes from 64.39.15.238: icmp_seq=1. time=70. ms
> > Perhaps there is a routing problem somewhere between you and 64.39.15.238?
> > That machine is not physically at hub (looks like it's a Rackspace site)
> > so there might be connectivity issues that are different from hub's.
> > What do you get from tracerouting to cvsup.postgresql.org?
>
> *slaps forehead*
>
> I didn't catch on to the different network, and 64.x has always been a
> problem on my firewall/masquerading box since I'm also on a 64.x subnet
> and it keeps wanting to put in default routes for a class A network. So
> it is all a problem on my end.
>
> I had done some testing at another location yesterday, when I was
> finding that cvsup connections were being rejected.
>
> Any hints on how to supress this default route when the network is
> configured?
Best suggestion: Renumber your internal network into one of private
networks (10.*, 192.168.*, 172.16.*).
Alternate suggestion: configure correct netmask for your internal network
(such as, if you choose to be 64.1.1.1 with netmask 255.255.255.0, you
will only lose connectivity to 64.1.1.*, not entire 64.*)
-alex
From | Date | Subject | |
---|---|---|---|
Next Message | Stephan Szabo | 2001-09-21 17:15:09 | Re: an already existing alter table drop column ?!?!?! |
Previous Message | Oleg Bartunov | 2001-09-21 17:00:19 | Re: Further CVS errors |