Default GW on Different Network

Have a question or want to start a discussion? Post it! No Registration Necessary.  Now with pictures!

Threaded View


Is there anything improper about defining the default gateway as a
host on a network that none of the interfaces belong to (provided that
there's a route table entry for this network)?

Re: Default GW on Different Network


Bob Simon wrote:

Quoted text here. Click to load it

You mean your subnet is 172.16.1.0 /24 and you want to use a GW of
192.168.1.1 (routable from 172.16.1.0 router)?

Couple of things:
1)  Some operating systems will not let you do this.
2)  You have to depend on proxy-arp on the router with 172.16.1.0
interface.
3)  The PC somehow has to know that he has to arp for a gateway that's
no on his subnet.

If you're talking about router, recursive routing will take care of it.

--

hsb


"Somehow I imagined this experience would be more rewarding" Calvin
********************************************************************
Due to the volume of email that I receive, I may not be able to
reply to emails sent to my account. Please post a followup instead.
********************************************************************

Re: Default GW on Different Network


To make an analogy, a default gatewaty is like a door and an IP subnet is
like a room.  If the door that leads out of the room is actually in another
room, then how do you get out?
Having a default gateway IP address which is not in the host subnet is
against best practices of networking and is generally a bad idea.

-----
Scott Perry
Indianapolis, IN
-----

Quoted text here. Click to load it



Re: Default GW on Different Network


Well, with an entry in the route table, you would be able to walk
through the "other room" to get to the door.  Right?

Actually, your comment that this is against best practices answers my
question fine.  But several interesting issues that I don't quite get
yet have been raised so I think it's worth persuing them until I
understand.

When I originally posted the question, I was thinking of the situation
where a client is either connected to one of several wireless routers
or connected via Cat5 and I was considering using the edge router (the
one provided by the ISP) as the default gateway for all situations.  I
see that this is not a good idea because of arp issues.


On Fri, 12 Sep 2008 08:44:45 -0400, "Scott Perry"

Quoted text here. Click to load it

Re: Default GW on Different Network


That would work.  Your wireless clients would ARP out the wireless router IP
address as their LAN default gateway.  The wireless router in turn ARPs out
the ISP provided router as its default gateway.  Although the wireless
clients could detect this using a traceroute, they are not aware of any MAC
addresses or ARP communication outside of their broadcast domain by its very
definition.

-----
Scott Perry
Indianapolis, IN
-----

Quoted text here. Click to load it



Re: Default GW on Different Network


On Thu, 11 Sep 2008 20:11:44 -0500, "Hansang Bae"

Quoted text here. Click to load it

Yes.


I did a quick test and see that both XP and a cheap Linksys wireless
router (BEFW11s4) allow the GW to be on a different network than the
interface.  Do Cisco routers?  What OS are you thinking of that
prevents this?

Quoted text here. Click to load it

Do you mean that the client will arp for the designated gateway's mac
addr and the closest router will have to respond for the GW because it
blocks the broadcast?  Do they do this automatically?  If not, how do
you turn on proxy arp?  In general, is it a good idea to enable this?

Quoted text here. Click to load it

When the PC wants to send a packet off net, won't he broadcast an arp
request (assuming no arp cache entry) regardless of whether the
designated GW is on his network or not?  If so, this issue depends on
the proxy arp point you brought up above, right?

Quoted text here. Click to load it

Sorry, I don't get what you mean.  Please explain.

Re: Default GW on Different Network


Recursive routing means a next hop address normally reachable directly
needs a route to get there. So if I tell you to get to 1.1.1.0 you need
to go via 2.2.2.0, and the route to 2.2.2.0 is via 5.5.5.254, and you
are 3.3.3.1, you're next hop to 5.5.5.254 is 3.3.3.254. This is
generally a bad thing . Its like saying to get from a to b you go via c,
but c is accessible by d.
Recursive routing can cause loops and timeouts.


Bob Simon wrote:
Quoted text here. Click to load it

Re: Default GW on Different Network


Quoted text here. Click to load it



Mostly older operating systems and embedded systems.  Routers will let
you do it, however.


Quoted text here. Click to load it

 
Quoted text here. Click to load it


For example, one thing Unix admins used to do was to set it's own
interface as the default gateway.  This tells the OS that *THE ENTIRE*
world of IP is recheable via the NIC and that the stack should arp for
EVERY IP.  So if a router receives an arp frame for some far away
subnet/IP, the (local) router will answer the arp on behalf of the far
away IP.  Proxy arp is on by default on all cisco routers.  It is *not*
a good idea because you can deliver a packet on behalf of someone who
doesn't know your network.  IE someone just plugs in a PC and can start
talking to anyone in your network due to proxy-arp.



Quoted text here. Click to load it

The first first the the PC does is to figure out if the destination IP
is on the local subnet or a remote subnet.  If it's local, then the PC
will send out an arp request.   If the PC decides that the destination
IP is *not* on the local subnet, he will arp for the gateway because
the PC will know that he has to punt to the GW.


Quoted text here. Click to load it

Other's explained recursive routing so I'll skip this one.  



--

hsb


"Somehow I imagined this experience would be more rewarding" Calvin
********************************************************************
Due to the volume of email that I receive, I may not be able to
reply to emails sent to my account. Please post a followup instead.
********************************************************************

Site Timeline