Core CS · Computer Networks

One broadcast, and then every frame goes to one port

Your host knows an IP address. Its network card cannot use one. Follow the single question that turns 10.0.0.2 into a 48-bit MAC address, and watch a switch fill its own forwarding table while it is passing that question around.

Watch the ARP cache and the MAC table fill, step by step →

A frame cannot leave without a 48-bit destination, and an IP address is not one. ARP is the one question a host broadcasts on its own link to turn an IP address into a MAC address. The switch is the one table that turns that MAC address into a port. Both tables are filled by listening to traffic that was going past anyway.

01 The idea

A frame needs a number the application never had

Your browser asks for 10.0.0.2. The card in your machine cannot do anything with that. What it puts on the wire is a frame, and the first six bytes of a frame are a 48-bit destination MAC address. Not an IP address, not a hostname, not a port. Six bytes, or the frame does not go. So there is a gap between what the software knows and what the hardware needs, and that gap is exactly one question wide.

The two addresses are different kinds of thing, which is why neither can stand in for the other. An IP address is hierarchical and assigned. 10.0.0.2 splits into a network part and a host part, and a router can read the network part alone and know which way to send the packet without knowing anything else about it. A MAC address is flat and burned in. 00:1A:A0:00:00:0B has no network part at all. It names a card, not a place, so nothing can route on it and the only way to find its owner is to shout on the one link that card is attached to and see who answers.

That shout is ARP, the Address Resolution Protocol. A host that needs a MAC address for an IP address on its own link broadcasts a request to every station there, and the one station that owns the address answers directly. The answer is written into the host’s ARP cache with a timer on it, so the question is asked once and every frame after that goes straight out.

Meanwhile the box in the middle is doing its own bookkeeping. A switch has one job that sounds trivial and is not: turn a 48-bit destination into one port number. It is never told anything. It reads the source address of every frame that arrives and writes down which port that frame came in on, so the first frame a station ever sends teaches the switch where that station lives. When it does not yet know a destination it sends the frame out of every port except the one it came in on, and the reply teaches it the other direction.

Put those together and you have the whole chain from an application to a copper pair. IP says which machine on the planet. ARP turns that into a MAC address, and only for the machine on your own link. The switch turns that MAC address into a port. Three lookups, three tables, and two of the three fill themselves in from frames that were going past anyway.

The frame needs a 48-bit destination and IP cannot supply one. ARP broadcasts one question on the local link and caches the one answer. The switch learns from the source address of every frame and decides from the destination address of every frame. Those are two different fields doing two different jobs, and that is the sentence to keep.

MAC address48 bits, six bytes, twelve hex digits, written into the card at manufacture. The first three bytes are the OUI, the block IEEE assigned that manufacturer. It is flat: no network part, so nothing routes on it. Burned in does not mean unchangeable — a driver can put any value it likes in the source field, which is what the attack at the end of section 03 relies on.

ARP cacheA host’s table of IP address to MAC address, for its own link only. One broadcast question and one unicast answer fill one row, and the row expires on a timer so a replaced card does not haunt you.

MAC address tableThe switch’s table of MAC address to port, also called the CAM table or the forwarding table. Every arriving frame writes a row from its source address; a row nothing refreshes is deleted after the ageing time.

02 Worked example

One question, one answer, and two tables that fill themselves

This is the scene for the whole lesson, including the console in section 04 and every address in the cheat sheet. Four devices on one switch, one network, 10.0.0.0/24, mask 255.255.255.0 on all of them. The switch has just been powered on, so its table is empty, and host A has just booted, so its ARP cache is empty too.

Device	IPv4	MAC address	Switch port
A, the host doing the sending	`10.0.0.1`	`00:1A:A0:00:00:0A`	`port 1`
B, the host it wants	`10.0.0.2`	`00:1A:A0:00:00:0B`	`port 2`
C, a bystander	`10.0.0.3`	`00:1A:A0:00:00:0C`	`port 3`
R, the default gateway	`10.0.0.254`	`00:1A:A0:00:00:FE`	`port 4`

A wants to send an IP packet to 10.0.0.2. Read left to right, and watch what each box writes down rather than what it sends.

A has an IP, not a MAC10.0.0.2 masked with /24 gives 10.0.0.0, the same as A’s own network, so B is on this link. A looks in its ARP cache and finds nothing. The frame has no destination to write.

→

ARP request, broadcastDestination MAC FF:FF:FF:FF:FF:FF, EtherType 0x0806, opcode 1. “Who has 10.0.0.2? Tell 10.0.0.1.” 28 bytes of ARP padded to 46, so a 64-byte frame.

→

The switch learns, then floodsIt reads the source 00:1A:A0:00:00:0A and writes port 1. Only then does it read the destination, sees a broadcast, and sends copies out ports 2, 3 and 4. Never back out port 1.

→

B alone replies, unicastC and R compare the target IP with their own, do not match, and drop it. B does match and answers with opcode 2 straight to 00:1A:A0:00:00:0A. The switch learns B on port 2 and forwards it on port 1 alone.

→

Data frame, one portA caches 10.0.0.2 → 00:1A:A0:00:00:0B and finally sends the real frame, EtherType 0x0800. Both MACs are known, so it leaves on port 2 only.

Count what that cost. One broadcast frame, seen by all three of the other stations, two of which had no use for it. Two unicast frames, the reply and the data. One row in A’s ARP cache and two rows in the switch, one written from each direction of the conversation. Every frame after this one goes out a single port with no broadcast at all, until one of those timers expires. One question bought the whole conversation.

The highlighted node is the one to slow down on, because it does two things in one pass and they read the frame’s two address fields for two unrelated reasons. Learning uses the source address, and it always succeeds: this frame came in on port 1 and says it is from that card, so that card is reachable through port 1, and that is a fact whatever else happens. Forwarding uses the destination address, and it can fail: the switch may never have heard of it. Learning is therefore unconditional and forwarding is not, which is exactly why an unknown destination is flooded rather than dropped.

Now the 64. It is worth doing by hand because it is the one Ethernet size that never varies. An ARP message for IPv4 over Ethernet is a fixed 28 bytes: 2 for hardware type, 2 for protocol type, 1 for hardware address length, 1 for protocol address length, 2 for the opcode, then 6 + 4 for the sender’s MAC and IP and 6 + 4 for the target’s. 2 + 2 + 1 + 1 + 2 + 6 + 4 + 6 + 4 = 28. Ethernet refuses to carry a payload under 46 bytes, so the card adds 46 − 28 = 18 bytes of zero padding. Then 6 + 6 + 2 = 14 bytes of header in front and a 4-byte FCS behind: 14 + 46 + 4 = 64 bytes. Every ARP frame on the wire is the minimum legal frame, request and reply alike. In a capture you will usually see 60 rather than 64, because the card strips the FCS before handing the frame to the operating system.

03 Mechanics

The frame, the switch table and the ARP cache

Three tables, in the order the bytes meet them. First the frame itself, field by field, because every rule below is a rule about one of these fields. The last column is the specific thing that gets marked wrong, not a general warning.

Field	Bytes	What it holds	The point
Preamble + SFD	`7 + 1`	Seven bytes of alternating ones and zeros so the receiver’s clock can lock on, then 10101011 saying the frame starts on the next bit.	`not part of the frame` — not in the 64, not in the 1518, and not covered by the FCS.
Destination MAC	`6`	Who the frame is for on this link. FF:FF:FF:FF:FF:FF means every station.	The field a switch reads to decide. It may not know the answer.
Source MAC	`6`	The card that sent it. Always an individual address; a broadcast can never appear here.	The field a switch reads to learn. It always can.
Type / Length	`2`	1536 (0x0600) or above is an EtherType naming the payload: 0x0800 IPv4, 0x0806 ARP, 0x86DD IPv6. 1500 (0x05DC) or below is an 802.3 length instead.	Two readings of the same two bytes, and the split is exactly at 1500 versus 1536.
Payload	`46 to 1500`	The packet the layer above handed down. Anything shorter than 46 is padded with zeros up to 46 by the sending card.	1500 is the Ethernet MTU. 46 is the floor that produces the 64-byte minimum frame.
FCS	`4`	A CRC-32 over everything from the first byte of the destination MAC to the last byte of the payload.	A trailer, because a value computed over a block cannot be written before that block exists.
Interframe gap	`12`	96 bit times of silence before the next frame may begin.	Not bytes of the frame, but time on the wire that any honest throughput calculation has to include.

Why the minimum is 64 bytes, and why that is not a round number. It is 512 bit times, and 512 ÷ 8 = 64 bytes. On 10 Mbps shared Ethernet, which is 10⁷ bits per second and not a power of two, that is 512 ÷ 10⁷ s = 51.2 microseconds. Original Ethernet put every station on one coaxial cable, and a station could only notice a collision while it was still transmitting. The worst case is that A starts, its signal takes the full one-way propagation time to reach the far end of the cable, B starts an instant before it arrives, and B’s collision signal takes the same time coming back: one full round trip. 802.3 fixed the maximum network diameter so that round trip fits inside 512 bit times, then required every frame to occupy the wire for at least 512 bit times, so a sender is guaranteed to still be sending when the bad news reaches it. The 46-byte minimum payload is what is left over: 64 − 6 − 6 − 2 − 4 = 46. Note that signals travel through copper or fibre at roughly 2 × 10⁸ m/s, about two thirds of the speed of light in vacuum, which is what made 2500 metres of cable an expensive number of bit times.

CSMA/CD, accurately. Carrier Sense: listen first, and do not start while somebody else’s signal is on the medium. Multiple Access: everyone shares one medium and nobody grants permission. Collision Detection: keep listening while you transmit, and if what is on the wire is not what you are putting on it, two stations started close enough together to overlap. The sender then stops immediately, sends a 32-bit jam signal so every other station registers a collision rather than a merely corrupt frame, and backs off. Binary exponential backoff picks a random integer r from 0 to 2ᵏ − 1, where k is the number of collisions this frame has suffered, capped at 10, and waits r slot times of 512 bits each. One collision gives 0 or 1 slots, two gives 0 to 3, ten and beyond gives 0 to 1023, and after 16 attempts the card gives up and reports the failure upward. The randomness is the whole mechanism: two stations that backed off by the same fixed amount would collide again for ever.

And it is switched off on every link you will meet. This is the half that gets left out and the half interviewers reward. Your link is a switch port and one card, full duplex, with a separate pair for each direction. A collision requires two transmitters sharing one medium, and there is now exactly one transmitter per direction, so a collision cannot physically occur. Full duplex therefore disables CSMA/CD outright: no carrier sense, no detection, no jam, no backoff, and a station transmits whenever it likes. IEEE 802.3 has deprecated half-duplex operation and the 64-byte minimum survives purely as compatibility. One historical clause worth carrying: half-duplex gigabit Ethernet had to stretch the slot time to 4096 bit times with carrier extension, because at 1000 Mbps a 512-bit slot covers a useless distance. Almost nobody deployed it, which tells you how completely switching had already won. Two terms fall out of this and interviewers pair them. A collision domain is the set of stations whose transmissions can collide with each other, and a switch gives every port a collision domain of its own, which is exactly why a modern link has one transmitter per direction. A broadcast domain is the set of stations a broadcast frame reaches, and a switch floods broadcasts rather than stopping them, so it does not divide one; a router or a VLAN boundary does.

So no station is contending for the medium any more. What is doing the work instead is a table inside the switch, and it makes exactly five decisions.

Destination MAC in the arriving frame	In the MAC table?	What the switch does	Which ports
Unicast, e.g. 00:1A:A0:00:00:0B	Yes, port 2, and the frame arrived on port 1	Forward	`port 2 alone`
Unicast	Yes, port 1, and the frame arrived on port 1	Filter, discard it	`none` — both stations are already on that segment
Unicast	No entry at all	Flood — unknown-unicast flooding	`every port except the ingress port`
Broadcast, FF:FF:FF:FF:FF:FF	Never stored; a broadcast is never a source	Flood	`every port except the ingress port`
Multicast, e.g. 01:00:5E:...	Not stored unless IGMP snooping built a group table	Flood, or forward to the group	`every port except the ingress port`

Source to learn, destination to decide. Swapping those two is the commonest wrong answer about switches, so say it deliberately. The switch learns from the source because the source is a fact it can verify by arrival: this frame came in on port 3 and claims that card, so that card is reachable through port 3. It decides from the destination, which is a question it may not yet be able to answer. That asymmetry is what makes a switch plug-and-play: no configuration file, no address list, and one frame in each direction is enough to teach it. Flooding is not a failure mode, it is the honest behaviour of a box that has not been told anything yet, and it is self-correcting because the reply arrives with the missing station as its source. Rows do not live for ever either: Cisco IOS deletes a MAC-table row 300 seconds after the last frame from that address, and the Linux bridge uses the same 300 seconds by default. Traffic refreshes a row, so an active station never ages out and a silent one does.

That is the switch. The remaining table is the one inside the host, and ARP fills it with two frames that differ in more than their opcode.

Property	ARP request	ARP reply
Opcode	`1`	`2`
Destination MAC on the frame	`FF:FF:FF:FF:FF:FF` broadcast	`the requester’s MAC` unicast
Who receives it	`every station on the link`	`one station`
Target hardware address field	All zeros. That field is the question.	The answerer’s own MAC. That field is the answer.
Who responds	Only the station that owns the target IP. Everyone else drops it silently.	Nobody. It is the response.
EtherType, and size on the wire	`0x0806`, 64-byte frame	`0x0806`, 64-byte frame

One rule from RFC 826 that gets skipped. Everybody on the link sees the request, and the request carries the sender’s IP and the sender’s MAC in its own fields. A station that already holds a row for that sender must update it. A station that does not hold one is only allowed to create one if it is the target of the request. So a request does not merely fetch an answer, it also refreshes what the link already believed, without adding a row on every machine that happened to overhear it.

The off-link rule, which is the point of the whole topic. Before a host ARPs for anything, it runs one test: mask the destination IP with your own subnet mask and compare with your own network. A wants 10.0.0.2: 10.0.0.2 AND 255.255.255.0 = 10.0.0.0, and A’s own network is 10.0.0.1 AND 255.255.255.0 = 10.0.0.0. Same, so B is on this link and A ARPs for 10.0.0.2 itself. Now A wants 203.0.113.9: 203.0.113.9 AND 255.255.255.0 = 203.0.113.0, which is not 10.0.0.0. Off-link. A does not ARP for 203.0.113.9, and could not usefully try: an ARP request is a broadcast frame, routers do not forward broadcast frames, and no station on this link owns that address to answer. Instead A reads its routing table, finds the default gateway 10.0.0.254, and ARPs for the gateway’s MAC. The frame it finally sends carries destination MAC 00:1A:A0:00:00:FE and destination IP 203.0.113.9 at the same time, and that pair is the idea in one line: the MAC is this hop, the IP is the whole journey.

Gratuitous ARP, and why the same design makes ARP unsafe. A gratuitous ARP is a host asking for its own IP address, which sounds pointless and is not. Sent at boot it is duplicate address detection: if anybody replies, the address is already taken. Sent after a failover it is a cache update, and any VRRP router or keepalived node that takes over a virtual IP broadcasts one so hosts repoint their caches and the switch relearns the port in milliseconds instead of after the ageing timer. That works because RFC 826 has no authentication of any kind and hosts accept replies they never asked for, which is also precisely how ARP spoofing works: an attacker on the same link repeatedly announces that the gateway’s IP belongs to the attacker’s MAC, every host caches it, and the attacker sits in the middle of every conversation leaving the link. It only works from inside the broadcast domain, so the defences are switch features rather than host ones: Dynamic ARP Inspection validates each reply against the DHCP snooping table and drops the rest, and static ARP entries pin the mappings that matter.

05 Cheat sheet

Twelve answers to have ready

Every row is something you can be asked to state or compute in under ten seconds. The right-hand column is the specific wrong answer that gets given, not a general caution.

What they ask	The answer	The trap
Ethernet II frame, in order	`6 dst MAC + 6 src MAC + 2 type + 46..1500 payload + 4 FCS`	`counting the 8-byte preamble and SFD as part of the frame`
Minimum and maximum frame	`64 and 1518 bytes`	Quoting 64 as the minimum payload. The payload floor is 46.
Why the minimum is 64	`512 bit times = the worst-case collision round trip on 10 Mbps coax`	`“because the standard says so”`, which invites the follow-up you cannot answer
Size of a MAC address	`48 bits = 6 bytes = 12 hex digits`	Saying 32 bits by confusing it with IPv4, or 64 by confusing it with EUI-64.
EtherType values	`0x0800 IPv4, 0x0806 ARP, 0x86DD IPv6`	`swapping 0x0800 and 0x0806` — they differ by one hex digit and mean different layers
Size of an ARP frame	`28 ARP + 18 pad + 14 header + 4 FCS = 64 bytes`	Forgetting the padding and answering 46. ARP is always the minimum frame.
What a switch learns from	`the SOURCE MAC of every arriving frame, against the ingress port`	`saying the destination MAC`
Destination MAC not in the table	`flood on every port except the one it arrived on`	Saying the switch drops it. A missing row means “not heard from yet”, not “does not exist”.
How long a row lives	`MAC table 300 s on Cisco IOS and the Linux bridge; ARP cache 4 hours on Cisco IOS`	`quoting one timer for the other table`
Request versus reply	`request is broadcast, reply is unicast, both 0x0806, both 64 bytes`	Saying both are broadcast. The answerer already knows who asked.
Destination on another network	`ARP for the default gateway’s IP, never for the far host’s`	`ARPing for the remote address` — routers do not forward the broadcast, so nothing could answer
Collision versus broadcast domain	`one collision domain per switch port; one broadcast domain per switch, per VLAN`	Saying a switch splits broadcast domains. Only a router or a VLAN boundary does that.

Learn on source, decide on destinationTwo address fields in the same frame, read by the same switch, for two unrelated jobs. Learning cannot fail because arrival proves the fact. Deciding can fail, and when it does the frame is flooded rather than dropped.

Broadcast once, unicast for ever afterOne 64-byte ARP request buys a cache row that serves every frame until the timer expires. That is the whole economics of ARP: an interruption for every station on the link, paid once, in exchange for direct delivery thereafter.

The MAC is this hop, the IP is the journeyA frame leaving for another network carries the gateway’s MAC and the far host’s IP at the same time. Every router along the way rewrites both MAC addresses and touches neither IP address.

06 Where & why

Both tables are commands you can type on a real machine

Neither table is a teaching abstraction. Both are live state you can print on a machine in front of you, and the two timers below are real defaults you can look up in the documentation of the products that ship them.

Cisco IOS

Both tables, two commands, two very different timers

show mac address-table prints the switch’s MAC-to-port rows with their VLAN and whether each was learned dynamically or configured statically; the default ageing time is 300 seconds, set with mac address-table aging-time. show arp prints the router’s IP-to-MAC rows and their age in minutes; the default ARP timeout on an interface is 4 hours, set with arp timeout. Two tables, two independent timers, and nothing in either device coordinates them.

Linux · ip neigh

The ARP cache is a neighbour table with states

ip neigh show prints each mapping with a state: REACHABLE means confirmed recently, STALE means believed but unverified, INCOMPLETE means a request went out and no reply has come back. Linux revalidates a reachable entry after roughly 30 seconds of silence rather than aging it out flatly, which is why the numbers here never match Cisco’s. On a machine running a software bridge, bridge fdb show prints the other table, the kernel’s own MAC-to-port rows.

Wireshark

The section 02 exchange is two rows in a capture

Type arp in the filter and the pair appears: one frame to Broadcast reading “Who has 10.0.0.2? Tell 10.0.0.1”, then one frame straight back reading “10.0.0.2 is at 00:1a:a0:00:00:0b”. Expand either and the 18 bytes of zero padding are listed explicitly as Padding under the Ethernet II node, which is the quickest way to convince yourself the 46-byte floor is real.

keepalived · VRRP

A gratuitous ARP is how a failover finishes

Two routers share one virtual IP and one virtual MAC, which RFC 5798 defines as 00-00-5E-00-01-{VRID}. When the backup takes over it broadcasts a gratuitous ARP for the virtual address. That single frame repoints every host’s ARP cache and, because the switch learns from its source, moves the MAC-table row to the new port at the same instant. Without it the failover would be invisible until two separate timers happened to expire.

The division of labour, in one line to be able to defend on the spot. IP says which machine on the planet. ARP turns that into a MAC address, and only on your own link. The switch turns that MAC address into a port. Three lookups, three tables, and the last two are filled by listening rather than by being configured.

07 Interview questions

What they ask, and what they follow up with

This topic is a favourite because one question separates recital from understanding: given a destination, which address does the host actually resolve. Expect the interviewer to change the destination halfway through your answer and watch what you do.

A host on your LAN knows the destination IP address. Walk me through everything that happens before the first data frame goes out.

It masks the destination with its own subnet mask first and compares with its own network. Same network, so the destination is on this link, and it looks that IP up in its ARP cache. On a miss it broadcasts an ARP request to FF:FF:FF:FF:FF:FF asking who owns that address; the switch learns the sender’s MAC from the source field and floods the frame out every port except the one it arrived on. The owner alone answers with a unicast reply, the switch learns that MAC too, the host writes the mapping into its cache, and only then does the data frame leave with a real 48-bit destination.

Give me the Ethernet II frame field by field, with sizes.

Six bytes of destination MAC, six of source MAC, two of EtherType, 46 to 1500 bytes of payload, four bytes of FCS. That is 18 bytes of wrapping, so the frame runs from 64 to 1518 bytes. In front of it on the wire sit a 7-byte preamble and a 1-byte start-of-frame delimiter, and behind it a 12-byte interframe gap, but none of those three are part of the frame and none are covered by the FCS. Quoting 26 or 38 bytes of Ethernet overhead is the standard slip: 26 folds the 8-byte preamble and delimiter into the frame, and 38 folds the 12-byte gap in on top of that.

Why is the minimum Ethernet frame 64 bytes?

Because collision detection on shared coaxial Ethernet needed a sender to still be transmitting when the collision signal came back to it. 802.3 sized the maximum cable run so the worst-case round trip fits inside 512 bit times, then required every frame to occupy the wire for at least 512 bit times. 512 bits ÷ 8 = 64 bytes, and at 10 Mbps that is 51.2 microseconds. Subtract the 18 bytes of header and FCS and the 46-byte minimum payload falls out; it was never chosen for its own sake.

Ethernet II has no length field. If a payload was padded, how does the receiver know where the real data ends?

It does not, at layer 2, and it is not meant to. Ethernet hands the whole 46-byte payload up and the upper-layer header carries the true length: IPv4 has a Total Length field, and an ARP message for IPv4 over Ethernet is a fixed 28 bytes by definition. Anything past that length is padding and is ignored. It also explains the two readings of the two bytes after the source MAC. DIX Ethernet II put a type number there first, IEEE 802.3 later put a length in the same position, and a card accepts both because no legal length can reach 1536: 1500 or below is a length, 0x0600 or above is a type.

How does a switch build its MAC address table?

It reads the source address of every frame that arrives and records it against the port it arrived on, with a timestamp. Nothing is configured and nothing is requested; it is pure observation of traffic that was passing anyway. A row is refreshed each time that address is seen again and deleted once it has not been seen for the ageing time, which is 300 seconds on Cisco IOS and on the Linux bridge. A broadcast or multicast address is never learned, because it can never legitimately appear in a source field.

What does a switch do with a frame whose destination MAC is not in its table?

It floods it, sending a copy out of every port except the one it arrived on. It never drops the frame, because a missing row means “I have not heard from that station yet” rather than “that station does not exist”. The behaviour is self-correcting: the reply comes back carrying that station as its source, the row gets written, and the next frame in that direction is forwarded on one port. It is also what separates a switch from a hub, which floods every frame for ever because it has no table at all.

Is CSMA/CD running on the link between your laptop and the switch?

No. That link is full duplex with a separate pair for each direction and exactly one transmitter per direction, so a collision cannot physically occur and CSMA/CD is disabled outright: no carrier sense, no detection, no jam, no backoff. It only ever applied to a shared medium, which in practice means coaxial Ethernet and hubs, and IEEE 802.3 has deprecated half-duplex operation. Answering it that way round shows you know both that the mechanism exists and that it does not run, which is the actual thing being tested.

Explain binary exponential backoff.

After a collision the station stops, sends a 32-bit jam signal so every station registers a collision rather than a merely corrupt frame, then waits a random number of slot times before retrying. The number is drawn uniformly from 0 to 2ᵏ − 1, where k is the collision count for this frame capped at 10, and a slot is 512 bit times. One collision gives 0 or 1, two gives 0 to 3, ten and beyond gives 0 to 1023, and the card abandons the frame after 16 attempts. Doubling the range thins out a crowded medium, and the randomness is what stops two stations retrying in lockstep for ever.

Your host wants to reach an address on a different network. Which IP address does it ARP for?

The default gateway’s, never the far host’s. An ARP request is a broadcast frame and routers do not forward broadcast frames, so the question could never reach the far host, and no station on this link owns that address to answer it. The host masks the destination, sees it is off-link, takes the next hop from its routing table and resolves that instead. The frame that goes out then carries the gateway’s MAC as its layer 2 destination and the far host’s IP as its layer 3 destination at the same time: the MAC is this hop, the IP is the whole journey.

ARP request and ARP reply: which is broadcast and which is unicast, and why?

The request is broadcast because the asker does not yet know which card to address, so it has to interrupt the whole link. The reply is unicast because the answerer does know: the request carried the sender’s hardware address in its own fields, so the answer can go straight back. Broadcasting the reply as well would interrupt every card on the link with a message meant for one of them. Both frames are 64 bytes on the wire, since 28 bytes of ARP gets padded up to the 46-byte minimum payload.

What is a gratuitous ARP?

Hard

Host A is configured 10.0.0.1 with mask 255.255.255.0 and gateway 10.0.0.254. Host D sits on the same switch, configured 10.0.0.9 with mask 255.255.0.0 by mistake, and the same gateway. Both send a packet to 10.0.5.7, which is a real host reachable through the router. Work the masks bit by bit, give the IP address each host ARPs for, say which of the two packets is delivered, and name the single configured value that produced the difference.

Follow-up

Both hosts are on the same wire, both have the same correct gateway configured, and the broken one never asks the gateway for anything at all. The symptom looks like a routing failure and no router is involved in it, which is why this is usually diagnosed last.

Show the hint

Do both AND operations on paper for both hosts before deciding anything, and remember that the result of that comparison is what chooses whose MAC address gets requested, not whether a request is sent.