Ascend Archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: (ASCEND) Arp routing
On Wed, Apr 08, 1998 at 11:19:01AM -0400, Dave Van Allen wrote:
> There's no such thing as "arp routing", what you have here is Tomfoolery.
While I would also not call it ARP routing, I don't at all see why some
people bash it or dislike it.
> arp was not designed to be used as a routing or re-direction function across
> different subnets. Proxy-arp in a situation like this is a bad hack and
It was not designed for that, but it was designed flexible enough to allow
for that. It allows for even more esoteric hacks like "ARP-for-everything"
which is euphemistically called "IP Switching" or "Layer 3 Switching".
If you keep in mind that IP forwarding in a broadcast domain is nothing
but "find the right MAC to send the frame to" and the IP-Address written
in your routing table or published with a routing protocol is of no real
use to forwarding but to find the MAC to which it must send, Proxy ARP
doesn't look that weird any longer. As with all technology, the basic
thing is to be able to handle it. This means knowing what it does and
what it cannot do, knowing how to configure it, knowing what pitfalls it
has (and Proxy ARP has pretty sharp edges, no doubt) and with this know-
ledge decide where it is applicable and where not. Proxy ARP has a number
of applications where it makes life considerably easier, of course it
does not scale to large environments but this doesn't mean it is nonsense.
> doesn't scale at all. Why not just route, you have all the pieces in place?
Because routing requires you to subnet. If you have just a /24 or even
something smaller (who gets a /24 today) and you want to use it for a
number of different things, subnetting this tiny chunk of address space
again just to build routing groups for even smaller subnets or single
IPs is just painful. Instead running the unsubnetted /x on the Ether-
net and just cutting out single IPs or small "subnets" from it using
Proxy ARP is simple, useful and comfortable.
> Even RIP2 with small timer values will get you out of your problem in a
> fashionable way. OSPF in the later 5.0p tree works well too for your
> situation and is the preferred method for scaling.
You need to grow a lot until OSPF becomes really necessary. I would
tend to suggest RIPv2 to even somewhat extended WANs. OSPF might
become useful if you have an infrastructure with more than 8 or so
hops end-to-end and the RIPv2 setup starts to become sluggish on
flaps or fills your lines with route updates.
--
Kanther-Line: PGP SSH IDEA MD5 GOST RIPE-MD160 3DES RSA FEAL32 RC4
+-o-+--------------------------------------------------------+-o-+
| o | \\\- Brain Inside -/// | o |
| o | ^^^^^^^^^^^^^^ | o |
| o | Andre' Beck (ABPSoft) beck@ibh-dd.de XLink PoP Dresden | o |
+-o-+--------------------------------------------------------+-o-+
++ Ascend Users Mailing List ++
To unsubscribe: send unsubscribe to ascend-users-request@bungi.com
To get FAQ'd: <http://www.nealis.net/ascend/faq>
Follow-Ups:
References: