customers and web servers and level one naps
Gordon Cook
cook at netaxs.com
Fri Sep 6 01:47:45 UTC 1996
ARGH!!!!
On Fri, 6 Sep 1996, Peter Lothberg wrote:
> > Second: allowing such a customer, or an NSP, to attach web services
> > directly to the FDDI ring at the NAP.
>
Peter: If I had thought through the topology of the situation I too
blithly described in the above sentence, the pieces of equipment involved,
and what bits were flowing where, even at my not really sophisticated
level of knowledge, i might have seen the problem that placing a web
server with nothing between it and the gigaswitch FDDI port would have
involved.
Instead, feeling far too confident that I remembered a 14 hour old phone
conversation with stephen stuart correctly, I wrote what i thought I had
heard. I am fully aware now that I heard mistakenly. But I also had no
earthly idea what a cow pie I had stepped into. I would be happy to let
this die.
But since I was not and am not trying to cause problems for the Palo Alto
digital people I have no choice but to answer it - for you write as though
he (stuart-dec-paix) had not corrected my error - something that he has
done.
> This is a security problem, if there is no switch in the middle and
> each host are induvidually attached to the switch.
>
> Next problem is that a host needs to knew what router to send a
> packet to for a particular destination, so either it points
> default at one of the NAP routers, and packets traverse the NAP
> twice, or the host impleements BGP and has a full set of routes.
>
> So host at a the NAP media should be 'strongly not recomended'.
>
Thank you for a good explanation of some of the major reasons why such a
topology would be ill-advised. ;-)
> An interesting scenario is, a router with two FDDI interfaces, one to
> the host and one to the NAP. It now comes down to if it's worth
> the real_estate to have the host there.
What you have just described, is what, if I now understand things
correctly, exists at the Palo Alto Internet exchange.
>
> --Peter
>
Gordon Cook
More information about the NANOG
mailing list