:Not really. The private IP space probably never leaves that LAN segment so
:the source IP would get set properly and the default route is irrelevent.
:Whenever
:he communicated with a block that is not diretly attached then the code has
:to
:choose a source address and then send the packet to the next hop (usually
:the
:default route unless you have a dynamic protocol daemon (routed/gated/etc)
:running. As long as your just communicating to directly attached subnets
:everything
:will work peachy regardless of public/private/quantity/netmask.
:
:-Steve
I wish it were that easy. If you have two interfaces on the same LAN
segment, but one is configured with an internal IP and one is
configured with an external IP, and the default route points out the
interface configured with the external IP, then you are ok.
If you have one interface with *two* ip addresses. For example (taking
a real life example):
ash:/home/dillon> ifconfig
fxp0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
inet 208.161.114.66 netmask 0xffffffc0 broadcast 208.161.114.127
inet 10.0.0.3 netmask 0xffffff00 broadcast 10.0.0.255
ether 00:b0:d0:49:3b:fd
media: Ethernet autoselect (100baseTX <full-duplex>)
status: active
Then the 'source IP' address the machine uses is completely up in the
air. It could be the external IP, or the internal IP, and it could
change out from under you if you manipulate the interface with ifconfig.
You have to explicitly bind to the correct source IP if you care.
For our machines I bind our external services specifically to the
external IP. Beyond that I usually don't care because I NAT-out our
internal IP space anyway, so any packets sent 'from' an internal IP
to the internet wind up going through the NAT, which hides the fact
that the source machine chose the wrong IP.
-Matt
:> Yes, but what that snippet showed from ifconfig showed 2 networks, 2 from
:> public IP space and 1 from private IP space, and since it's working the
:> networking code must know/care about something that it's being fed. --
:> Jonathan
:>
:> --
:> Jonathan M. Slivko <[EMAIL PROTECTED]>
:> Blinx Networks
:> http://www.blinx.net/
:>
:> ----- Original Message -----
:> From: "Steven Ames" <[EMAIL PROTECTED]>
:> To: "Jonathan M. Slivko" <[EMAIL PROTECTED]>; "Chris Dillon"
:> <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
:> Sent: Thursday, July 26, 2001 4:56 PM
:> Subject: Re: Why two cards on the same segment...
:>
:>
:> > > Yes, but, I think the issue with the 2 IP classes working is because
:one
:> > is
:> > > not routable, and therefore it's not a real
:> > > IP address, and the router knows this, hence it's not reacting to it
:by
:> > > stopping to work. As long as you use virtual
:> > > ip's (192.168.*.*) then there should be no reason why it wouldn't
:work.
:> > > However, if your talking about a routable
:> > > IP address, then you might have a problem, as there is a difference
:> > between
:> > > a virtual IP address and a real (routable)
:> > > IP address. Just my 0.02 cents. -- Jonathan
:> >
:> > I don't think the networking code knows/cares if something is private or
:> > public IP space. I might be off here but I think the real problem with
:> > two seperate networks on one card (or even on two cards) would be
:> > the default route (can't have two right?) and which IP address gets
:> > used as the 'source IP' on packets leaving the system.
:> >
:> > -Steve
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
