Date: Sun, 30 Sep 2001 22:55:08 -0400 From: "jason" <jasonc@concentric.net> To: <questions@freebsd.org> Subject: Problems after IP change Message-ID: <009001c14a24$7c334f20$05d85c42@speakeasy.net>
next in thread | raw e-mail | index | archive | help
Due to the problems after the NYC incident back on 9/11 my ISP has made many
changes in my configuration to get my service back. They immediately moved
my circuit from NYC (New York) to WDC (Washington DC) which allowed me to
keep same IP there was quite a bit of congestion. Well last week they said
they were moving some of us to SEA (Seattle) which would require an IP
change. This switch was not successfully accomplished yet. Here is the
details.
I am running two BSD machines. One with 4.2 and the other with 4.3. Each
was the latest release at the time of install. They were both up and
running fine with the old static addresses of 216.27.148.134 and
216.27.148.138. At present these are the only two BSD machines on the
network but there are several Win9x machines running.
I set these IP addresses in /etc using a file called start_if.<interface>
For one it is called start_if.dc0 and the other start_if.lnc0.
The entry in dc0 machine was:
ifconfig dc0 inet 216.27.148.134 216.27.148.1 netmask 255.255.255.0
ifconfig dc0 inet 192.168.1.103 192.168.1.1 netmask 255.255.255.255 alias
The entry in lnc0 machine was:
ifconfig dc0 inet 216.27.148.138 216.27.148.1 netmask 255.255.255.0
ifconfig dc0 inet 192.168.1.104 192.168.1.1 netmask 255.255.255.255 alias
These worked just fine when I was connected to NYC then WDC. I added the
192.168 address to allow machines using my other second DSL line to have an
address in their subnet they can connect to. Otherwise if they use the real
internet IP the connections will go out one DSL line and through the
internet than back on the other DSL line which wastes precious DSL
bandwidth.
When I was told of the migration to SEA I changed the start_if files. The
IP change was temporary so I commented out the old IP addresses so I didn't
have to delete the line. This would make switching back far easier.
The entry in dc0 machine became:
#ifconfig dc0 inet 216.27.148.134 216.27.148.1 netmask 255.255.255.0
ifconfig dc0 inet 66.92.216.2 66.92.216.1 netmask 255.255.255.0
#ifconfig dc0 inet 192.168.1.103 192.168.1.1 netmask 255.255.255.255 alias
The entry in lnc0 machine became:
#ifconfig lnc0 inet 216.27.148.138 216.27.148.1 netmask 255.255.255.0
ifconfig lnc0 inet 66.92.216.6 66.92.216.1 netmask 255.255.255.0
#ifconfig lnc0 inet 192.168.1.104 192.168.1.1 netmask 255.255.255.255 alias
I was able to ping any 66.92.216.0 address but unable to ping past that
point. My ISP support department indicated that they seen my ARP messages
hitting their gateway but when they logged into the gateway and tried to
ping my addresses they did not respond. I verified this my trying to ping
from another connection outside my LAN to these addresses. I traced the
connection and found I was making it to the gateway but everything timed out
then. These machines would respond to pings if initiated on the same LAN.
It was as if the computers refused to communicate with anyone not on the
local LAN.
I later commented out all lines except for the one ifconfig line that had
each machines 66.92.216.0 address. This had no affect.
Here is the ifconifg command from lnc0 at present:
> ifconfig
lnc0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
inet 66.92.216.6 netmask 0xffffff00 broadcast 66.92.216.1
inet6 fe80::280:5fff:fef4:1042%lnc0 prefixlen 64 scopeid 0x1
ether 00:80:5f:f4:10:42
lp0: flags=8810<POINTOPOINT,SIMPLEX,MULTICAST> mtu 1500
faith0: flags=8000<MULTICAST> mtu 1500
gif0: flags=8010<POINTOPOINT,MULTICAST> mtu 1280
gif1: flags=8010<POINTOPOINT,MULTICAST> mtu 1280
gif2: flags=8010<POINTOPOINT,MULTICAST> mtu 1280
gif3: flags=8010<POINTOPOINT,MULTICAST> mtu 1280
lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> mtu 16384
inet6 fe80::1%lo0 prefixlen 64 scopeid 0x8
inet6 ::1 prefixlen 128
inet 127.0.0.1 netmask 0xff000000
ppp0: flags=8010<POINTOPOINT,MULTICAST> mtu 1500
sl0: flags=c010<POINTOPOINT,LINK2,MULTICAST> mtu 552
>
And here is the same thing for dc0:
dc0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
inet 66.92.216.2 netmask 0xffffff00 broadcast 66.92.216.1
inet6 fe80::220:78ff:fe08:9fc%dc0 prefixlen 64 scopeid 0x1
inet 66.92.216.3 netmask 0xffffffff broadcast 66.92.216.1
inet 66.92.216.4 netmask 0xffffffff broadcast 66.92.216.1
inet 66.92.216.9 netmask 0xffffffff broadcast 66.92.216.1
inet 66.92.216.10 netmask 0xffffffff broadcast 66.92.216.1
inet 66.92.216.11 netmask 0xffffffff broadcast 66.92.216.1
inet 192.168.1.103 netmask 0xffffff00 broadcast 192.168.1.1
ether 00:20:78:08:09:fc
media: autoselect (100baseTX) status: active
supported media: autoselect 100baseTX <full-duplex> 100baseTX
10baseT/UT
P <full-duplex> 10baseT/UTP none
lp0: flags=8810<POINTOPOINT,SIMPLEX,MULTICAST> mtu 1500
faith0: flags=8000<MULTICAST> mtu 1500
gif0: flags=8010<POINTOPOINT,MULTICAST> mtu 1280
gif1: flags=8010<POINTOPOINT,MULTICAST> mtu 1280
gif2: flags=8010<POINTOPOINT,MULTICAST> mtu 1280
gif3: flags=8010<POINTOPOINT,MULTICAST> mtu 1280
lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> mtu 16384
inet6 fe80::1%lo0 prefixlen 64 scopeid 0x8
inet6 ::1 prefixlen 128
inet 127.0.0.1 netmask 0xff000000
ppp0: flags=8010<POINTOPOINT,MULTICAST> mtu 1500
sl0: flags=c010<POINTOPOINT,LINK2,MULTICAST> mtu 552
2:45am ftp:~ >
Several windows machines were affected by the IP change and they are now all
up and running. Anyone have any ideas what might be the problem? What
could have gone wrong here?
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-questions" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?009001c14a24$7c334f20$05d85c42>