[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: routing: subnet behind gateway in that subnet



Hello Stefan,

On Wed, Mar 12, 2003 at 03:23:22AM +0100, Stefan Radomski wrote:
> On Wed, 2003-03-12 at 00:49, Arne P. Boettger wrote:
> 
> > Elegant solution is splitting the /27 further apart. How many
> > machines do you have that need to be publically reaced? 
> 
> As we have only 30 public accessible ip adresses and the deployment is
> meant to be scalable, it is desirable not to loose one.
> 
> > You could split it in two /28s, and use one for the link to the
> > provider and the other one for your local machines. 
> 
> That would "waste" 16 ip adresses as I understand it, unless we would
> install a switch at the interface to the computer center (cc), but we
> couldn't enforce security with our gateway/router.

Well, yes you will not be able too use the rest of the address
space.

> > Or split it in four /29s, use one for the link to the provider and
> > the rest for your machines. 
> 
> Wouldn't we loose 2 ip adresses with every split one for broadcast and
> the network ip?

Yes, you do. 

> > Fact is that you should have public addresses for this structure.
> > Another option would be to move the WLAN to another router with an
> > official IP address behind your router/firewall.
> 
> I still don't understand why it isn't possible/desirable to have an
> explicit route for our gateway and declare, that the rest of the net is
> reachable through that gateway. 
> Would it be a solution to ask for an additional ip for our router in
> another subnet? 

The problem is that your setup requires a seperate ip network
between your provider's router and your router. The minimal solution
would be a /30 network. 

Your suggested routing layout would give a confusing routing. The
router would get a packet for one address in your network, but not
the router. It looks into it's routing table and sees that the
packet should be routed to your router, with the router's address in
your network. Because it is not one one of the directly attached
networks, it checks the routing table and sees that the packet
should be routed to your router - that can't work.

If you have a manual route for a network, the router address to that
network cannot be part of that network, that's against the basics of
routing.

> > By the way: This is not a strange routing problem at the computer
> > center, it's a strange idea you had - sorry to say that. 
> > And either your computer center has noone understanding routing to
> > consult you or you didn't tell them the whole story, because what
> > you have now looks to me like you didn't tell your provider about
> > that WLAN stuff... 
> 
> Well, as it raises the problems I mentioned (router only *reachable*
> from internet) it seems strange to me, but I must admit that I had this
> latent feeling that the cc was right.. :)
> But nevertheless, it seems to me that every "elegant" solution implies a
> loss of usable ip adresses, am I right here?

I would choose a different wording. You don't loose addresses, you
invest them into a functional network.

> > Oh by the way, of course you can put a filtering bridge there
> > instead, but filtering on layer two for layer three information is a
> > bit awkward - proper routing should be prefered.
> 
> As the other replies point out too, this seems to be the way to go for
> us, unless there is a solution not to loose a single ip address with
> proper routing.
> I would also prefer a clean routing solution, but loosing more than one
> ip to achieve it is not an option. Are there any cons with a bridge
> solution that anyone is aware of?

Last time I heard someone trying bridgeing with Linux did not turn
out too good, but that may have improved. 
Ask me again next month, by then I will have checked back on it ;-)

Ciao, Arne.
-- 
 ,``o. OpenBSD        -        Debian GNU/Linux        -        Solaris  >o)
>( ,c@ GPG 1024D/913C2F81 2000-10-11  Arne P. Boettger <apb@createx.de>  /\\
 ',,,' Fingerprint = 6ED9 9A64 CD8A EB6F D841  0391 2F08 8F86 913C 2F81 _\_V

Attachment: pgpZXTgv5XfjF.pgp
Description: PGP signature


Reply to: