Date: Wed, 15 Mar 2000 23:47:04 -0500 From: "Crist J. Clark" <cjc@cc942873-a.ewndsr1.nj.home.com> To: David Preece <dmpreece@paradise.net.nz> Cc: freebsd-questions@FreeBSD.ORG Subject: Re: (relatively newbie) routing question. Message-ID: <20000315234704.D60836@cc942873-a.ewndsr1.nj.home.com> In-Reply-To: <NDBBLOFHAKIDKINHKCNCIEIOCBAA.dmpreece@paradise.net.nz>; from dmpreece@paradise.net.nz on Thu, Mar 16, 2000 at 11:45:03AM %2B1300 References: <NDBBLOFHAKIDKINHKCNCIEIOCBAA.dmpreece@paradise.net.nz>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, Mar 16, 2000 at 11:45:03AM +1300, David Preece wrote:
> Hi,
>
> What worked: I had my boxen set up like this, and it worked fine:
>
> Internet
> |
> 203.79.92.1 (router provided by ISP)
> |
> 203.79.92.25 (IP of my cable modem, on a class C)
> |
> [BSD] ep0=203.79.92.25 (0xffffff00)
> [BSD] |
> [BSD] natd
> [BSD] |
> [BSD] ed1=192.168.0.1 (0xffffff00)
> |
> [NT] 192.168.0.2 (0xffffff00)
>
> (ipfw show)
> 00100 337 145736 divert 8668 ip from any to any via ep0
> 00200 1941 679991 allow ip from any to any
> (and yes, there was a power cut five minutes ago).
>
> Where [BSD] and [NT] show what is sitting in which box and the hex is subnet
> masks. And it goes, a treat.
Great. Looks good.
> So much so that I feel the urge to try some
> immoral experiments on natd (having a go at load balancing), and set up a
> separate class C - 192.168.1 with another FreeBSD box on it.
>
> ...as above...
> |
> [BSD] ep0=203.79.92.25 (0xffffff00)
> [BSD] |
> [BSD] natd
> [BSD] |
> [BSD] ed1=192.168.0.1 (0xffffff00) ed0=192.168.1.1
> (0xffffff00)
> | |
> [NT] 192.168.0.2 (0xffffff00) [BSD2] ep0=192.168.1.2
> (0xffffff00)
>
> Hopefully with the idea that I can put two natd instances up, a 'release'
> instance onto ep0 to keep the net access up, and the experimental one onto
> ep1 and run trials from BSD2. Now, while I can telnet onto the 'main' BSD
> box from NT fine, I cannot ping 192.168.1.2 from NT. Needless to say,
> pinging (or telnetting) 192.168.1.2 from the main BSD box is no problem.
Hmmm... Odd. Time to do some tcpdump(1)s on the NAT box to see where
these packets are going.
> So, it looks like a routing table problem - let's have a look.
>
> su-2.03# netstat -r
> Routing tables
>
> Internet:
> Destination Gateway Flags Refs Use Netif
> Expire
> default 203-79-92-1.cable2 UGSc 2 266 ep0
> localhost localhost UH 0 1 lo0
> 192.168 link#1 UC 0 0 ed1
> 192.168.0.2 0:50:ba:b2:71:26 UHLW 1 758 ed1 1020
> 192.168.1 link#2 UC 0 0 ed0
> 192.168.1.2 0:0:b4:b2:9:d7 UHLW 1 2 ed0 1132
> 203.79.92 link#3 UC 0 0 ep0
> 203-79-92-1.cable2 0:50:f:3:78:70 UHLW 2 0 ep0 1200
>
> Now I'm no great expert with routing tables, but this seems to be telling me
> that the default router is set as the one from the ISP - great. Loopback is
> going. That a class B starting with 192.168 has ed1 as its' NIC - and hence
> packets addressed for 192.168.1.2 could be expected to go that way (despite
> the fact that we also have the class C 192.168.1 on ed0, and that we
> actually have the hardware address of 192.168.1.2 in the routing table now).
I don't think that is correct. IIRC, the routing table is showing that
192.168.0.0/24 is working fine. The routing table never shows trailing
zero bytes. If no netmask is shown, assume the netmask is its historic
A, B, or C class. Since 192.168.0.0 is a historic class C, all is
well.
Here, I'm going to test by aliasing my inside interface.
# ifconfig de0
de0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
inet 192.168.64.254 netmask 0xffffff00 broadcast 192.168.64.255
ether 00:e0:29:11:d3:a9
media: autoselect (10base2/BNC) status: active
supported media: autoselect 10base5/AUI 10base2/BNC 10baseT/UTP <full-duplex> 10baseT/UTP
# ifconfig de0 inet 10.0.0.1 alias
# ifconfig de0 | grep '10\.0'
inet 10.0.0.1 netmask 0xff000000 broadcast 10.255.255.255
# netstat -rn | grep 10
10 link#2 UC 0 0 de0
# ifconfig de0 inet 10.0.0.1 netmask 0xffffff00 alias
# ifconfig de0 | grep '10\.0'
inet 10.0.0.1 netmask 0xffffff00 broadcast 10.0.0.255
# netstat -rn | grep 10
10/24 link#2 UC 0 0 de0
#
Yep. It does not show trailing zeros in the last case, but is using
the correct netmask.
> This looks to me to be the problem, and the evidence suggests that the
> problem could be used by making 192.168.1 and 192.168.2 my local subnets.
> Thing is, I don't understand why. Especially since all three NIC are set to
> be class C from rc.conf:
>
> ifconfig_ep0="inet 203.79.92.25 netmask 255.255.255.0"
> ifconfig_ed0="inet 192.168.1.1 netmask 255.255.255.0"
> ifconfig_ed1="inet 192.168.0.1 netmask 255.255.255.0"
Looks fine. Agrees with the netstat.
> Is there something fundamental I don't understand about using 0 as the last
> 8 bits of a network address? (Like RFCxxxx says you can't). Or am I missing
> the point somewhere else along the line?
Just how it is displayed.
> I appreciate this is a kinda big mail, but I was trying to illustrate the
> situation as clearly as possible.
However, this just makes the question of why the NT box can't talk
even more perplexing... unless _it_ is not configured properly. Can
BSD2 reach the NT machine?
--
Crist J. Clark cjclark@home.com
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?20000315234704.D60836>