A host computer who ARPS for a host on another network?

I'm hoping someone can clairify this as I have learnt two different methods from Train signal Chris Bryant and CBT Nuggets. and I dont know which one is correct.

I have watched each video 3 times each, but have changed the IP addresses and host names because obviously they use different ones.

Chris Bryant states in his videos that if a Host A (10.1.1.2)wants to send a packet onto Host B (192.168.0.5) which is on a different network, it will send out an arp broadcast saying "what is the MAC address of Host B on IP address 192.168.0.5). The default gateway that Host A is connected to replies back by proxy (called proxy arp). It basically pretends to be the MAC address for Host B but Host A doesn't know this fact. Host A now has its defaults gateway's MAC address and has associated it with the destination IP of 192.168.0.5. The entries are added to the host A's arp cache. Frame is sent onto the default gateway.

Jeremy from CBT nuggets describes it differently. He states that Host A would send out an ARP for its default gateway after it discovers from looking at the subnet mask that Host B isn't on his LAN and Host A's routing table tells him where to send it.Host A's default gateway replies back to the ARP request with his MAC address and now Host A adds this information to the frame as "destination MAC" but the destination IP will belong to Host B (192.168.0.5)

I appreciate both methods probably have the same desired effect..i.e. the sending computer gets the MAC address of the local router, but is it done by proxy arp (Bryant) or is it Jeremy's method which suggests to me that host A is pretty smart and knows whats going on(can't think of another way to put it)

perhaps it doesn't matter too much? i dont know personally, but on another topic, i have also noticed that Jeremy from CBT states that its the sender host that determines the size of TCP windowing (flow control) whereas Chris Bryant states explicitly that it is the receiver host that tells the sender how many packets he can send. Bit of a contradiction.

thanks

Find more posts tagged with

Save $250 on 2025 certification boot camps from Infosec!

Book now with code EOY2025

Button

Comments

njkt

I don't know the answer (because i don't know proxy arp) but why not hook up a packet sniffer and find out yourself how it works?

Bl8ckr0uter

Address Resolution Protocol - Wikipedia, the free encyclopedia

Proxy ARP - Wikipedia, the free encyclopedia

RFC 826 - Ethernet Address Resolution Protocol: Or Converting Network Protocol Addresses to 48.bit Ethernet Address for Transmission on Ethernet Hardware
http://www.ietf.org/rfc/rfc1027.txt

gosh1976

ON the ARP issue I believe Jeremy's description is more accurate both from logic and my studies. If it worked the other way then there would be no need to have a default gateway ip learned from dhcp or statically assigned on the client to communicate with a node on another subnet.

As for the TCP flow control Chris Bryant is more right.

MrXpert

Bl8ckr0uter wrote: »

Address Resolution Protocol - Wikipedia, the free encyclopedia

Proxy ARP - Wikipedia, the free encyclopedia

RFC 826 - Ethernet Address Resolution Protocol: Or Converting Network Protocol Addresses to 48.bit Ethernet Address for Transmission on Ethernet Hardware
http://www.ietf.org/rfc/rfc1027.txt

thanks for the articles especially the RFC one which to be honest I had not seen before. I also found this How ARP Works

Proxy arp is how it clearly is done and Bryant got it right again.

Forsaken_GA

MrXpert wrote: »

thanks for the articles especially the RFC one which to be honest I had not seen before. I also found this How ARP Works

Proxy arp is how it clearly is done and Bryant got it right again.

*sigh*

No, the article is not the 100% truth.

The correct answer is that both implementations are correct.

The difference is in whether or not the host has a default gateway set. If it does not, then it will broadcast an ARP for *every* request. If the router has proxy arp enabled, and it has a route for that destination (even a default route), then the router will respond with it's own MAC.

If the host *does* have a default gateway set, then it will not arp for off network IP's. It will compare the destination to it's own local subnet, and if they're not on the same network, it knows that traffic goes to the default gateway, so there's no need to arp for the IP, unless it doesn't have an ARP entry for the default gateway, in which case it will arp for the gateway IP, not the destination IP.

Here's a working example -

Here's my arp table before I do anything at all:

root@mormont:~# arp -an
? (192.168.4.1) at 00:12:7f:f3:f9:80 [ether] on eth0
root@mormont:~#

root@mormont:~# route -n
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
192.168.4.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0
0.0.0.0 192.168.4.1 0.0.0.0 UG 0 0 0 eth0

As the routing table shows, I have a default gateway defined

root@mormont:~# ping google.com
PING google.com (74.125.93.105) 56(84) bytes of data.
64 bytes from qw-in-f105.1e100.net (74.125.93.105): icmp_req=1 ttl=50 time=25.6 ms
64 bytes from qw-in-f105.1e100.net (74.125.93.105): icmp_req=2 ttl=50 time=22.8 ms
64 bytes from qw-in-f105.1e100.net (74.125.93.105): icmp_req=3 ttl=50 time=26.0 ms
64 bytes from qw-in-f105.1e100.net (74.125.93.105): icmp_req=4 ttl=50 time=24.5 ms
^C
--- google.com ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3000ms
rtt min/avg/max/mdev = 22.830/24.790/26.094/1.276 ms

I'm pinging google.com

root@mormont:~# arp -an
? (192.168.4.1) at 00:12:7f:f3:f9:80 [ether] on eth0

My ARP cache has not changed.

root@mormont:~# ping 192.168.4.50
PING 192.168.4.50 (192.168.4.50) 56(84) bytes of data.
64 bytes from 192.168.4.50: icmp_req=1 ttl=64 time=3.75 ms
64 bytes from 192.168.4.50: icmp_req=2 ttl=64 time=0.282 ms
64 bytes from 192.168.4.50: icmp_req=3 ttl=64 time=0.294 ms
64 bytes from 192.168.4.50: icmp_req=4 ttl=64 time=0.247 ms
^C
--- 192.168.4.50 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3005ms
rtt min/avg/max/mdev = 0.247/1.144/3.756/1.508 ms

I'm pinging a host on the local subnet.

root@mormont:~# arp -an
? (192.168.4.50) at 00:11:32:0a:99:ad [ether] on eth0
? (192.168.4.1) at 00:12:7f:f3:f9:80 [ether] on eth0

Now I have a new ARP entry.

I don't currently have a working example of proxy arp setup, and I can't cobble one together at the moment (at work, lab is remote), but if you really need to see it in action, I'll see what I can do later on.

However, it's also dependent on the TCP/IP stack. Some implementations will not be intelligent enough to check the destination IP against the locally configured IP and figure out it needs to default the traffic, and will ARP anyway. It's fairly rare to find implementations that act like that anymore, however, and I make it a point to avoid products like that.

ARP is a frequently misunderstood topic.

But in situations like these, you should never take the word of anyone else without validating what they're saying yourself through some testing.

Nate--IRL--

In what cases would you want to use Proxy ARP? Would it not be better to assign a Default Gateway to all the hosts?

Nate

Forsaken_GA

Nate--IRL-- wrote: »

In what cases would you want to use Proxy ARP? Would it not be better to assign a Default Gateway to all the hosts?

Nate

There is no case where I would *want* to use proxy arp. Implementing what is essentially a MITM attack on my network on purpose doesn't sit well with me, nor does the unnecessary increase in broadcast traffic.

But some solutions don't leave you with a choice. Calix GPON's have a special place in hell as far as I'm concerned for just this issue.

higherho

Nate--IRL-- wrote: »

In what cases would you want to use Proxy ARP? Would it not be better to assign a Default Gateway to all the hosts?

Nate

For security reasons proxy arp is typically disabled on routers.

gosh1976

@Forsaken_GA - thanks for that explanation. I only vaguely remember something about an explanation of proxy arp from my studies.

A random thought that this thread gave me: It's important to be careful of taking some statements as absolutes and to be careful of making statements as if they are absolutes not only in life but in IT!

Forsaken_GA

gosh1976 wrote: »

@Forsaken_GA - thanks for that explanation. I only vaguely remember something about an explanation of proxy arp from my studies.

A random thought that this thread gave me: It's important to be careful of taking some statements as absolutes and to be careful of making statements as if they are absolutes not only in life but in IT!

I find it's easiest to live by the motto of 'Trust, but verify'. Especially in the face of conflicting information.

And asking how ARP works is one of my favorite interview questions. It's one of those questions that tells me pretty darn quick who read about in a book once or twice, and who really knows the protocol.

Zartanasaurus

Forsaken_GA wrote: »

I find it's easiest to live by the motto of 'Trust, but verify'. Especially in the face of conflicting information.

And asking how ARP works is one of my favorite interview questions. It's one of those questions that tells me pretty darn quick who read about in a book once or twice, and who really knows the protocol.

How would those two groups respond to the question?

Forsaken_GA

Zartanasaurus wrote: »

How would those two groups respond to the question?

Most folks are just able to tell me it sends a broadcast out for the IP asking who has that IP, and what's your mac address, and that's it. Which, at it's core is certainly a valid answer. For an entry level sysadmin. I expect a bit more out of network engineers.

Most people don't get it right. They either know how it works as I demonstrated above, but get dumbfounded when I ask them to explain how ARP works without a gateway set. Or they they think the proxy arp method is the only one. I've only ever had two people give me the correct explanation. And that's why I love the question. It's simple on it's face, as is the protocol, and most people take it for granted. Yet ARP problems can bring a network to it's knees. So when I ask that question, I'm not only asking how ARP works, I'm asking how detail oriented the candidate is, as well as asking them how curious they are about how it all works under the hood.

A few of my other favorite interview questions are asking how DNS works (more people get that one right, but it's amazing how many do get it wrong), and how traceroute works. The traceroute question in particular is always a fun one, because there are two methods, and most folks are usually only aware of the ICMP method. I've only ever had one person accurately explain the non ICMP method.

headshot

Forsaken_GA wrote: »

*sigh*

No, the article is not the 100% truth.

The correct answer is that both implementations are correct.

The difference is in whether or not the host has a default gateway set. If it does not, then it will broadcast an ARP for *every* request. If the router has proxy arp enabled, and it has a route for that destination (even a default route), then the router will respond with it's own MAC.

If the host *does* have a default gateway set, then it will not arp for off network IP's. It will compare the destination to it's own local subnet, and if they're not on the same network, it knows that traffic goes to the default gateway, so there's no need to arp for the IP, unless it doesn't have an ARP entry for the default gateway, in which case it will arp for the gateway IP, not the destination IP.

Here's a working example -

Here's my arp table before I do anything at all:

root@mormont:~# arp -an
? (192.168.4.1) at 00:12:7f:f3:f9:80 [ether] on eth0
root@mormont:~#

root@mormont:~# route -n
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
192.168.4.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0
0.0.0.0 192.168.4.1 0.0.0.0 UG 0 0 0 eth0

As the routing table shows, I have a default gateway defined

root@mormont:~# ping google.com
PING google.com (74.125.93.105) 56(84) bytes of data.
64 bytes from qw-in-f105.1e100.net (74.125.93.105): icmp_req=1 ttl=50 time=25.6 ms
64 bytes from qw-in-f105.1e100.net (74.125.93.105): icmp_req=2 ttl=50 time=22.8 ms
64 bytes from qw-in-f105.1e100.net (74.125.93.105): icmp_req=3 ttl=50 time=26.0 ms
64 bytes from qw-in-f105.1e100.net (74.125.93.105): icmp_req=4 ttl=50 time=24.5 ms
^C
--- google.com ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3000ms
rtt min/avg/max/mdev = 22.830/24.790/26.094/1.276 ms

I'm pinging google.com

root@mormont:~# arp -an
? (192.168.4.1) at 00:12:7f:f3:f9:80 [ether] on eth0

My ARP cache has not changed.

root@mormont:~# ping 192.168.4.50
PING 192.168.4.50 (192.168.4.50) 56(84) bytes of data.
64 bytes from 192.168.4.50: icmp_req=1 ttl=64 time=3.75 ms
64 bytes from 192.168.4.50: icmp_req=2 ttl=64 time=0.282 ms
64 bytes from 192.168.4.50: icmp_req=3 ttl=64 time=0.294 ms
64 bytes from 192.168.4.50: icmp_req=4 ttl=64 time=0.247 ms
^C
--- 192.168.4.50 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3005ms
rtt min/avg/max/mdev = 0.247/1.144/3.756/1.508 ms

I'm pinging a host on the local subnet.

root@mormont:~# arp -an
? (192.168.4.50) at 00:11:32:0a:99:ad [ether] on eth0
? (192.168.4.1) at 00:12:7f:f3:f9:80 [ether] on eth0

Now I have a new ARP entry.

I don't currently have a working example of proxy arp setup, and I can't cobble one together at the moment (at work, lab is remote), but if you really need to see it in action, I'll see what I can do later on.

However, it's also dependent on the TCP/IP stack. Some implementations will not be intelligent enough to check the destination IP against the locally configured IP and figure out it needs to default the traffic, and will ARP anyway. It's fairly rare to find implementations that act like that anymore, however, and I make it a point to avoid products like that.

ARP is a frequently misunderstood topic.

But in situations like these, you should never take the word of anyone else without validating what they're saying yourself through some testing.

Very nice. Thanks for the clarification.

MrXpert

Amazing this discussion. Thank you for your help. ARP is a very interesting topic.

capitanuionut

What's going on is that Host A compares the destination ip address and subnet mask with his own...and if the destination host is on other subnet than he is ...Host will search an entry in the arp cache for it's default gateway mac address...if he cannot find one then will broadcast an ARP request for the gateway's mac address..

The default gateway responds ar this with his mac address...Host A encapsulates the frame and send it to the router's interface...then the router is responsible for finding the remote address based on the destination ip address...

ITdude

Forsaken_GA wrote: »

Most people don't get it right. They either know how it works as I demonstrated above, but get dumbfounded when I ask them to explain how ARP works without a gateway set. Or they they think the proxy arp method is the only one.

And, do any of these ever get a chance at getting the job and expanding their horizons?

Forsaken_GA

ITdude wrote: »

And, do any of these ever get a chance at getting the job and expanding their horizons?

I don't make those decisions, I just make a recommendation to my boss, who does.

I make my recommendation based on my impression of the overall quality of the candidate. Knowledge, attitude, and social skills all play a part in it. I'm not going to recommend to hire someone that I want to strangle within the first 5 minutes of talking to him, I don't care if he's a Quintuple CCIE/Triple JNCIE.

As far as answering your question goes, it all depends. I don't expect people to answer perfectly, as long as they're in the ballpark, I'm pretty lenient. If they've got no clue, then I might let one of those go, but if they struggle with every question about how simple and fundamental protocols work, I can't recommend in good conscience a hire. We don't hire for entry level, successful applicants will have their paws on the pipes after the first week, so you need to know what you're doing.

pham0329

To go along with what Forsaken said, here's a couple paragraphs from the CCNP SWITCH FLG

A host identifies its nearest router, also known as the default gateway or next hop, by its IP address. If the host understands something about routing, it recognizes that all packets destined off-net must be sent to the gateway’s MAC address rather than the far end’s MAC address. Therefore, the host first sends an ARP request to find the gateway’s MAC address. Then packets can be relayed to the gateway directly without having to look for ARP entries for individual destinations.

If the host is not so savvy about routing, it might still generate ARP requests for every offnet destination, hoping that someone will answer. Obviously, the off-net destinations cannot answer because they never receive the ARP request broadcasts; these requests are not forwarded across subnets. Instead, you can configure the gateway to provide a proxy ARP function so that it will reply to ARP requests with its own MAC address, as if the destination itself had responded.