4 ms·

>In truth, that really is just complicating things. Now your operating system has to first look up the ethernet address of 192.168.1.1, find out it's 11:22:33:4

>In truth, that really is just complicating things. Now your operating system has to first look up the ethernet address of 192.168.1.1, find out it's 11:22:33:44:55:66, and finally generate a packet with destination ethernet address 11:22:33:44:55:66 and destination IP address 10.1.1.1. 192.168.1.1 is just a pointless intermediate step. This is completely wrong, it's not pointless. First, this can be used to easily swap out routers in a network without reconfiguring any clients or even incurring downtime. Without the intermediary gateway IP representation, this would mean you would either have to spoof the MAC on the second router or reconfigure all of the clients to point to the new gateway. Second, ethernet addresses are a layer-2 construct and IP routes are a layer 3 construct. Your default gateway is a layer-3 route to 0.0.0.0/0. There are protocols for exchanging layer-3 routes like BGP/RIP/etc that should not have to know anything about the layer-2 addressing scheme to provide the next-hop address. Third, routers still need to have an IP address on the subnet anyway to originate ICMP messages (e.g. TTL expired, MTU exceeded, etc). Fourth, ARP is still necessary even for the router itself to know how to take incoming IP traffic from the outside and actually forward it to the appropriate device on the local network. Otherwise you would have to statically configure a mapping of local IP addresses to MAC addresses on the router. So ARP is critical for separation of concerns between L2 and L3. We don't live in an ethernet-only world. >excessive ARP starts becoming one of your biggest nightmares. It's especially bad on wifi. Broadcast can become a nightmare. Excessive ARP is a drop in the bucket compared to other discovery crap that computers spew onto networks. The pattern of most computers now is to communicate with the external world (from the LAN perspective) and not much else. So on a network of 1000 computers (an already excessively large broadcast domain), your ARP traffic is going to be a couple of thousand ARP messages every few hours. If this is taking down your WiFi network, you have much bigger problems considering all of those are about a modern webpage load of traffic.

lwansbrough 9y ago
> This is completely wrong, it's not pointless. Pretty reliable rule of software is: if you think it's pointless you probably don't understand it well enough.
- pjmorris 9y ago
  Reliable rule, and not just for software. Seems like a good place for mentioning 'Chesterton's Fence'.... In the matter of reforming things, as distinct from deforming them, there is one plain and simple principle; a principle which will probably be called a paradox. There exists in such a case a certain institution or law; let us say, for the sake of simplicity, a fence or gate erected across a road. The more modern type of reformer goes gaily up to it and says, “I don’t see the use of this; let us clear it away.” To which the more intelligent type of reformer will do well to answer: “If you don’t see the use of it, I certainly won’t let you clear it away. Go away and think. Then, when you can come back and tell me that you do see the use of it, I may allow you to destroy it.
  - msla 9y ago
    Sometimes, a thing is there because it's there, and nobody knows the original purpose, so by Chesterton, nobody would be able to tear it down, because nobody can see the use of it. Chesterton's Fence neatly saves the utterly pointless fences in our lives, regardless of the damage they can cause.
    - brianpan 9y ago
      It's a principle, not an unbreakable rule. The point is to take some time for the due diligence of understanding why. Fences (or laws or code) don't just appear out of nowhere. Someone spent time and energy to put it there. If you don't immediately see its use, you should do some more thinking/archeology.
    - bluGill 9y ago
      How many bad situations have been prevented though? I've seen many situations where someone did try to remove something pointless that really wasn't pointless.
    - Cyranix 9y ago
      I think your conclusion is a result of oversimplifying the concept of Chesterton's Fence. The idea can be restated as "Don't remove what you don't understand", but that doesn't imply "This thing is impossible to understand and may never be removed". A lack of understanding at a point in time doesn't imply a permanent inability to understand. Applied properly, the principle of Chesterton's Fence should provide you with the impetus to observe and learn about the subject. In software, that could involve creating/improving tests, diagramming method/API invocations, monitoring network traffic, etc. As a result of your observations, you should understand the subject deeply enough to determine whether it can be removed safely. If it can't be safely removed, you now have documentation justifying its existence (which may, in some cases, form the basis for a plan to migrate, deprecate, and remove).
nvahalik 9y ago
> this would mean you would either have to spoof the MAC on the second router But isn't this what CARP[1] and HSRP[2] essentially do anyway? Seems like they already found a way around that. [1]: https://www.freebsd.org/doc/handbook/carp.html https://www.freebsd.org/doc/handbook/carp.html [2]: https://www.cisco.com/c/en/us/support/docs/ip/hot-standby-router-protocol-hsrp/9281-3.html https://www.cisco.com/c/en/us/support/docs/ip/hot-standby-ro...

lwansbrough 9y ago

> This is completely wrong, it's not pointless. Pretty reliable rule of software is: if you think it's pointless you probably don't understand it well enough.

pjmorris 9y ago
Reliable rule, and not just for software. Seems like a good place for mentioning 'Chesterton's Fence'.... In the matter of reforming things, as distinct from deforming them, there is one plain and simple principle; a principle which will probably be called a paradox. There exists in such a case a certain institution or law; let us say, for the sake of simplicity, a fence or gate erected across a road. The more modern type of reformer goes gaily up to it and says, “I don’t see the use of this; let us clear it away.” To which the more intelligent type of reformer will do well to answer: “If you don’t see the use of it, I certainly won’t let you clear it away. Go away and think. Then, when you can come back and tell me that you do see the use of it, I may allow you to destroy it.
- msla 9y ago
  Sometimes, a thing is there because it's there, and nobody knows the original purpose, so by Chesterton, nobody would be able to tear it down, because nobody can see the use of it. Chesterton's Fence neatly saves the utterly pointless fences in our lives, regardless of the damage they can cause.
  - brianpan 9y ago
    It's a principle, not an unbreakable rule. The point is to take some time for the due diligence of understanding why. Fences (or laws or code) don't just appear out of nowhere. Someone spent time and energy to put it there. If you don't immediately see its use, you should do some more thinking/archeology.
  - bluGill 9y ago
    How many bad situations have been prevented though? I've seen many situations where someone did try to remove something pointless that really wasn't pointless.
  - Cyranix 9y ago
    I think your conclusion is a result of oversimplifying the concept of Chesterton's Fence. The idea can be restated as "Don't remove what you don't understand", but that doesn't imply "This thing is impossible to understand and may never be removed". A lack of understanding at a point in time doesn't imply a permanent inability to understand. Applied properly, the principle of Chesterton's Fence should provide you with the impetus to observe and learn about the subject. In software, that could involve creating/improving tests, diagramming method/API invocations, monitoring network traffic, etc. As a result of your observations, you should understand the subject deeply enough to determine whether it can be removed safely. If it can't be safely removed, you now have documentation justifying its existence (which may, in some cases, form the basis for a plan to migrate, deprecate, and remove).

nvahalik 9y ago

> this would mean you would either have to spoof the MAC on the second router But isn't this what CARP[1] and HSRP[2] essentially do anyway? Seems like they already found a way around that. [1]: https://www.freebsd.org/doc/handbook/carp.html https://www.freebsd.org/doc/handbook/carp.html [2]: https://www.cisco.com/c/en/us/support/docs/ip/hot-standby-router-protocol-hsrp/9281-3.html https://www.cisco.com/c/en/us/support/docs/ip/hot-standby-ro...