Mac Addresses & ARP

I am having some problems with understanding Mac Addressing and ARP as a frame moves from one device to the next, in particular what happens to the source and destination MAC addresses.

Host A pings Host F (all devices have just been turned on, disregard console connection on Host F, assume it's an ethernet connection)

1. Host A issues a DNS Server request to get Host F's IP address and the
DNS Server replies with the IP address for Host F

2. Host A issues an ARP broadcast for Host F's Mac address

3. Host F sends an ARP reply (unicast) to host A with it's Mac address

4. Host A now has the 4 pieces of information it needs to send the ping:
Source IP, Destination IP, Source Mac, Dest Mac

5. SW1 gets the frame, looks at the source Mac address. If the source Mac address is not in its Mac Address Table, SW1 adds it.

6. SW1 looks at the Destination Mac address and consults its Mac address table, if SW1 finds an entry for the Destination Mac address it Forwards the frame (unicast), if not it then floods it (broadcast). If the Mac is seen to be on the same interface that the frame came in on, it filters the frame (drops it).

7. The frame reaches SW2 and the procedure is the same as 6 above, but the frame eventually only reaches Host B.

8. The frame was also sent to R1 but while Routers accept broadcasts they do not forward broadcasts. R1 issues an ARP Reply (unicast) with the Mac Address of the interface that the frame came in on. R1 then consults its ARP cache to see if it has an entry for the Destination Mac address.

Let's say R1 doesn't have an ARP entry. R1 issues its Proxy ARP request and gets a reply from Host F. The ping is sent. Destination reached.

Hopefully, all that is correct. What I'm having problems with is how the Mac Addresses change as they move from device to device.

Host A
SRC MAC: Host A
DEST MAC: Host F

SW1
SRC MAC: Host A
DEST MAC: Host F

SW2
SRC MAC: Host A
DEST MAC: Host F

R1
SRC MAC: Host A
DEST MAC: Host F
DEST MAC (proxy to Host A): R1 local interface

SRC MAC: R1
DEST MAC: Host F

Find more posts tagged with

Free for TechExams community: Cybersecurity salary guide

Compare cert salaries and plan your next career move

Button

Comments

Forsaken_GA

certmister wrote: »

2. Host A issues an ARP broadcast for Host F's Mac address

Nope. Host F is across a router, so it's on a different subnet. The host knows that by comparing the destination IP vs it's own IP and Subnet mask. Since it knows it's off net, it will forward to it's default gateway. It will issue an ARP request for it's GW IP address if it doesn't already have an entry.

This is assuming you're not using Proxy arp.

So the ping would be destined to the remote IP, but to the default gateways MAC. Once the router gets it, it swaps the source MAC with it's own and swaps the destination mac with the mac of the end node, in this case host F.

The MAC's change at a layer 3 interface, that's it. It'll stay the same on the layer 2 segment.

Forsaken_GA

To elaborate a little bit on this -

It would be insane to have to keep a mac address for every node on the internet. And what about nodes which do not have mac addresses?

To show this in action -

porthos:~# arp -a
? (192.168.3.1) at 00:12:7f:f3:f9:80 on nfe0 [ethernet]
? (192.168.3.

at 00:30:1b:bd:d4:a9 on nfe0 [ethernet]
? (192.168.3.255) at ff:ff:ff:ff:ff:ff on nfe0 permanent [ethernet]

This is my arp table before a ping

porthos:~# ping 192.168.1.13
PING 192.168.1.13 (192.168.1.13): 56 data bytes
64 bytes from 192.168.1.13: icmp_seq=0 ttl=254 time=2.124 ms
64 bytes from 192.168.1.13: icmp_seq=1 ttl=254 time=1.596 ms
64 bytes from 192.168.1.13: icmp_seq=2 ttl=254 time=1.663 ms
64 bytes from 192.168.1.13: icmp_seq=3 ttl=254 time=1.666 ms
--- 192.168.1.13 ping statistics ---
4 packets transmitted, 4 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 1.596/1.762/2.124/0.211 ms

This is me pinging a host on another network

porthos:~# arp -a
? (192.168.3.1) at 00:12:7f:f3:f9:80 on nfe0 [ethernet]
? (192.168.3.

at 00:30:1b:bd:d4:a9 on nfe0 [ethernet]
? (192.168.3.255) at ff:ff:ff:ff:ff:ff on nfe0 permanent [ethernet]

This is my arp table after ping

No change. So an arp packet was never sent, and the router didnt proxy the arp request (it couldnt have if one was never made)

Now let's try pinging another host on the same subnet!

porthos:~# ping 192.168.3.9
PING 192.168.3.9 (192.168.3.9): 56 data bytes
64 bytes from 192.168.3.9: icmp_seq=0 ttl=64 time=0.315 ms
^C
--- 192.168.3.9 ping statistics ---
1 packets transmitted, 1 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 0.315/0.315/0.315/0.000 ms
porthos:~# arp -a
? (192.168.3.1) at 00:12:7f:f3:f9:80 on nfe0 [ethernet]
? (192.168.3.

at 00:30:1b:bd:d4:a9 on nfe0 [ethernet]
? (192.168.3.9) at 00:30:1b:bd:d4:a9 on nfe0 [ethernet]
? (192.168.3.255) at ff:ff:ff:ff:ff:ff on nfe0 permanent [ethernet]

And now I have an arp entry for 192.168.3.9

don't confuse proxy arp as a normal operation of arp, it's not. It's an ugly filthy nasty hack. Cisco turns it on by default (and I turn it off!), but you'll generally only find it in use in very specific instances. Proxy ARP basically makes your network appear to be flat with everything in the same subnet (that's why the host will send an arp request that the router can act as a proxy for). Sure, the router switching the frame can sort of be seen as acting like a proxy, but that's not the same thing as proxy ARP. The host is smart enough to know when it needs to send an ARP broadcast and when it needs to just send it directly to the gateway.

Anything else would result in huge amounts of arp traffic, and in huge amounts of memory consumed to keep those arp tables, especially on core border routers. The way ARP actually works is that a machine only keeps arp entries for networks it has interfaces in, and then sends everything else to the next hop address (default gateway if host, and default gateway or direct route if a router), assuming that device will pick up the responsibility for properly delivering the traffic.

This behavior changes if I do not set a default gateway on a host, however. Then I'll broadcast ARP packets, and then I would need proxy ARP.

You need to keep in mind the separation of layers. I will *never* get host F's mac address directly. It would do no good for any device to give me host F's mac address. If I addressed a frame to host F's mac address from host A, it would get dropped - no host in the layer 2 domain has that mac address.

Instead, the router would lie and when I ARP for host F's mac address, it would reply with the mac address of the interface it has in that layer 2 domain. So now host A thinks it can talk to host F if it sends a frame to R1's mac address. host A doesn't know it's R1. After all, it asked for host F, why would R1 lie and say it was host F? But that's exactly what R1 did - it lied and said it has host F's address, and then when it gets the frame, it swaps the destination from it's own address to host F's and changes the source from host A to itself.

Those of you familiar with security practices may be thinking to yourself 'hey that sounds like a man in the middle attack'. That's exactly how proxy ARP functions.

Bolton07

Forsaken_GA wrote: »

Nope. Host F is across a router, so it's on a different subnet. The host knows that by comparing the destination IP vs it's own IP and Subnet mask. Since it knows it's off net, it will forward to it's default gateway. It will issue an ARP request for it's GW IP address if it doesn't already have an entry.

This is assuming you're not using Proxy arp.

So the ping would be destined to the remote IP, but to the default gateways MAC. Once the router gets it, it swaps the source MAC with it's own and swaps the destination mac with the mac of the end node, in this case host F.

Did you mean to say 'So the ping would be destined to the remote IP, but to the default gateways MAC' ?

Can you correct that please?

Thanks

chmorin

Bolton07 wrote: »

Did you mean to say 'So the ping would be destined to the remote IP, but to the default gateways MAC' ?

Can you correct that please?

Thanks

I can't speak for what he meant to say, but what he said was correct. The packet will have the Layer 3 IP information for Host F, while the frame will have the Layer 2 Ethernet MAC information for the gateway.

Forsaken_GA

Bolton07 wrote: »

Did you mean to say 'So the ping would be destined to the remote IP, but to the default gateways MAC' ?

Can you correct that please?

Thanks

Nope, ICMP isn't a layer 2 protocol. The ping would be destined to the remote IP, but the frame would be addressed to the local gateways mac address.

It's easier to think of it like this -

The layer 3 address is used to denote absolute final delivery. Ie, it's going to this IP and that's that.

The layer 2 address is used for local segment delivery only. If the host you're trying to reach isn't on that segment, then it goes to the egress point for that segment instead (either because you have a default gateway, or because of proxy arp).

IP is like your cell phone provider. They need to be able to deliver to you wherever you are, even if they have to use someone elses network to do it.

Ethernet is like your local post office. If your letter isn't destined for someone local, they shove it on a truck or plane to be gotten out of their office. If it is destined for local delivery, they give it to a mailman and deliver it

certmister

Thanks for all the information but it will take me a little while to go over what happens when a Router is added to the mix. I am getting ready for ICND1 and my understanding of this topic is not very advanced.

In the meantime, I think it would help if I got the process right for Switches first and then move on to Routers. So, heres a new diagram

Ping request from Host A to Host B (all devices just turned on)

1. Host A issues a DNS Server request (not shown) to get Host B's IP address and the DNS Server replies with the IP address for Host B

2. Host A issues an ARP broadcast for Host B's Mac address

3. Host B sends an ARP reply (unicast) to host A with it's Mac address

4. Host A now has the 4 pieces of information it needs to send the ping:
Source IP, Destination IP, Source Mac, Dest Mac

5. SW1 gets the frame, looks at the source Mac address. The source Mac address is not in its Mac Address Table, SW1 adds it.

6. SW1 looks at the Destination Mac address and consults its Mac address table, SW1 floods the frame (broadcast).

7. The frame reaches SW2 and the procedure is the same as 5 above and the broadcast reaches Host B. I assume that if SW2 was running for a while and had learned of Host F's Mac address it would forward the ping instead of flooding it.

Host A
SRC MAC: Host A
DEST MAC: Host B

SW1
SRC MAC: Host A
DEST MAC: Host B

SW2
SRC MAC: Host A (Is this right or is the src mac=sw1?)
DEST MAC: Host B

Host B
SRC MAC: Host A (Same question here?)
DEST MAC: Host B

Forsaken_GA

certmister wrote: »

5. SW1 gets the frame, looks at the source Mac address. The source Mac address is not in its Mac Address Table, SW1 adds it.

Actually, it should have already learned the MAC from when Host A issued the ARP request. The ARP request had to have been issued with the source mac of Host A, otherwise Host B wouldn't have been able to unicast a reply

6. SW1 looks at the Destination Mac address and consults its Mac address table, SW1 floods the frame (broadcast).

This is also unlikely, SW1 should have learned which port is associated with that MAC when the arp reply came back

SW2
SRC MAC: Host A (Is this right or is the src mac=sw1?)
DEST MAC: Host B

Host B
SRC MAC: Host A (Same question here?)
DEST MAC: Host B

Switches that are only performing as layer 2 devices do not modify source and destination mac addresses. It is only when you cross a layer 3 boundary that mac addresses need to be swapped around. The only thing the switches do is pay attention to the source address and what port that source came from so when that address shows up as a destination instead, it already knows which port to send it out instead of having to flood it

certmister

Quote:
Originally Posted by certmister

5. SW1 gets the frame, looks at the source Mac address. The source Mac address is not in its Mac Address Table, SW1 adds it.

Actually, it should have already learned the MAC from when Host A issued the ARP request. The ARP request had to have been issued with the source mac of Host A, otherwise Host B wouldn't have been able to unicast a reply

Quote:
6. SW1 looks at the Destination Mac address and consults its Mac address table, SW1 floods the frame (broadcast).
This is also unlikely, SW1 should have learned which port is associated with that MAC when the arp reply came back

AAh! Damn it! Another mistake by me but very good for you to spot that. I completely forgot who gets a copy of the ARP message.

Quote:
SW2
SRC MAC: Host A (Is this right or is the src mac=sw1?)
DEST MAC: Host B

Host B
SRC MAC: Host A (Same question here?)
DEST MAC: Host B
Switches that are only performing as layer 2 devices do not modify source and destination mac addresses. It is only when you cross a layer 3 boundary that mac addresses need to be swapped around. The only thing the switches do is pay attention to the source address and what port that source came from so when that address shows up as a destination instead, it already knows which port to send it out instead of having to flood it

That makes a lot of sense, very well explained. When I am answering an exam question which asks about how the frame is changing do I assume L2 Switches are being used?

Forsaken_GA

That depends entirely on the question, context would count. If it's only switches involved, mac address stays the same. If there's a router involved, then the packet will be addressed to the default gateways MAC as it leaves the hosts, on purpose. It won't actually change until the router is ready to send it out on the wire to the destination network, so you could say the mac's change at the ingress point to the destination network.

It's actually a little misleading to say the MAC's are swapped.

What actually happens is that when the routers ethernet interface receives the frame, it strips the ethernet frame. The next hop might have to go out a serial interface, for example, so ethernet framing would not be appropriate. When it routes the underlying IP packet back out of itself and onto a new layer 2 domain, it encapsulates the IP packet with the appropriate frame.

So in your original example, if Host A is sending to Host F, the source MAC is host A and the destination mac is R1. Once R1 accepts that frame, it strips the ethernet frame, and when it goes to send it out the interace that has Host F connected, it encapsulates the IP packet with a new ethernet frame which has Host F as the destination MAC and R1 as the Source MAC.

So your IP packet stays the same end to end, but your layer 2 encapsulation is going to change at every layer 3 hop

tech-airman

Live and breath encapsulation and decapsulation of the OSI model. Ommmmmmmmmmmmm.

Bl8ckr0uter

Forsaken_GA wrote: »

Those of you familiar with security practices may be thinking to yourself 'hey that sounds like a man in the middle attack'. That's exactly how proxy ARP functions.

Wow, I never thought of it this way.

*You must spread rep around blah*

Forsaken_GA

Bl8ckr0uter wrote: »

Wow, I never thought of it this way.

Yeah, Proxy ARP is right up there with NAT on my list of 'Evil Network Services that need to die die die die die in a very big fire'