And verrily do I add to the discussion:

On Tue, 10 Aug 1999, Christopher P. Gill wrote:

> ||||||||========-------->>>>>>>>
> On Mon, 9 Aug 1999, Bill Studenmund wrote:
> 
> > That sounds wrong. Were you abole to get the machines talking to the ae0
> > at all with that setup?  
> 
> Yes, I was.  Of course, I needed a crossover cable between the ae0 and the
> uplink port of the hub, but it wasn't any worse. 

If you've got a cross-over cable, it's fine. :-)

> > Usually the "uplink" port is intended to connect to another hub. Even if
> > it's acting as a router, the ae0 interface should be connected to a 
> > normal hub port.
> 
> Really?  Even if all traffic leaving my network has to pass through one
> particular port?  I figure that that would define 'uplink'.  In any case,
> it doesn't work any better now that it's on a 'normal' port.

The idea was that this port is designed so you can take a normal 10Base-T
cable and hook it to another (upstream) hub. So you only need to stock one
type of patch cable, and you only need one type of in-wall wiring.

> > I know you mentioned some appletalk services on ae0 - did they work with   
> > ae0 on the uplink port?
> 
> Yes, they did.

I was trying to see if you had a cross-over cable or not. :-)

> ||||||||========-------->>>>>>>>
> On Mon, 9 Aug 1999, Nathan Raymond wrote:
> 
> Understood.  But it made sense to put it there, since I was going to need
> all the other ports anyway, and that port would in essence be my 'uplink'.
> It makes it easier too when scanning the activity/status lights on the
> hub.  Anyway, there was no real reason to have the crossover cable sit
> around gathering dust.

If you need all the ports and/or have a cross-over cable, it's fine. :-)

> Well, it sounds like I've no reason *not* to use the uplink port.  Like I
> said above, it's not set up that way (uplink out -> ae0) now, and it still
> doesn't work.  I know the cheap hub is a dumb device, but I think that the
> hub manual (if you can call it that) said something about basic jabber
> filtering or something, in some way differentiating the uplink port from
> the others.  I'll have to look at it again.

I think all the jabber filtering does is make sure that the connected
device(s) aren't nonsensical things. i.e. just because they have voltages
present doesn't mean they are really 10Base-T devices. :-)

> ||||||||========-------->>>>>>>>
> On Mon, 9 Aug 1999, Keith Fischer wrote:
> 
> > do a tcpdump on sn0 to see what is going by when you request an nslookup
> > or something from a 198.....  machine. 

Great suggestion!

> Good idea.  I'll try that when I get back home.
> 
> 
> ||||||||========-------->>>>>>>>
> On Mon, 9 Aug 1999, Chris Brown wrote:
> 
> > The second map line might be confusing things. You only need one.
> 
> Well, I'd added that second line because it wasn't working.  It doesn't
> work any better now, but I'll comment it out and make my attempts with the
> simpler configuration.

It should make the inside able to ping the outside. Without it, use telnet
to try to test connectivity. Without this line, you could be able to
telnet, ssh, web brouse, and ftp but still not be able to ping.

> > [use 192.168.1.1 for gateway]
> 
> Well, I've addressed the gateway IP and the port issue above.  It seems
> that if IPNAT were working, it would work with either of the physical
> configurations that I've described.  However, I'll go back and try it in
> the ways suggested above, just in case.

Right. It should work either way, but you'll get more efficient
transmission with the split setup. :-)

> With the outbound port on the NetBSD machine hooked directly to the ADSL
> box, I could ping both outside and inside machines from the NetBSD
> machine, and ping the NetBSD box from outside and inside.  IPNAT still
> didn't work.  I'll try the traceroute from one of the MacOS clients.

traceroute's good as it's udp-based (AFAIK), so it'll go out even if ping
won't work.

Take care,

Bill