Options
A host computer who ARPS for a host on another network?
MrXpert
Member Posts: 586 ■■■□□□□□□□
in CCNA & CCENT
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
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
I'm an Xpert at nothing apart from remembering useless information that nobody else cares about.
Comments
-
Options
njkt
Member Posts: 31 ■■□□□□□□□□
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? -
Options
Bl8ckr0uter
Inactive Imported Users Posts: 5,031 ■■■■■■■■□□
-
Optionsgosh1976
Member Posts: 441
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. -
OptionsMrXpert
Member Posts: 586 ■■■□□□□□□□
Bl8ckr0uter 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.I'm an Xpert at nothing apart from remembering useless information that nobody else cares about. -
Options
Forsaken_GA
Member Posts: 4,024
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. -
Options
Nate--IRL--
Member Posts: 103 ■■□□□□□□□□
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 -
OptionsForsaken_GA
Member Posts: 4,024
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. -
Optionshigherho
Member Posts: 882
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. -
Optionsgosh1976
Member Posts: 441
@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! -
OptionsForsaken_GA
Member Posts: 4,024
@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. -
Options
Zartanasaurus
Member Posts: 2,008 ■■■■■■■■■□
How would those two groups respond to the question?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.Currently reading:
IPSec VPN Design 44%
Mastering VMWare vSphere 5 42.8% -
OptionsForsaken_GA
Member Posts: 4,024
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. -
Options
headshot
Member Posts: 77 ■■□□□□□□□□
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. -
OptionsMrXpert
Member Posts: 586 ■■■□□□□□□□
Amazing this discussion. Thank you for your help. ARP is a very interesting topic.I'm an Xpert at nothing apart from remembering useless information that nobody else cares about.
-
Optionscapitanuionut
Member Posts: 55 ■■□□□□□□□□
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... -
Options
ITdude
Member Posts: 1,181 ■■■□□□□□□□
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?
I usually hang out on 224.0.0.10 (FF02::A) and 224.0.0.5 (FF02::5) when I'm in a non-proprietary mood.
__________________________________________
Simplicity is the ultimate sophistication.
(Leonardo da Vinci) -
OptionsForsaken_GA
Member Posts: 4,024
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. -
Optionspham0329
Member Posts: 556
To go along with what Forsaken said, here's a couple paragraphs from the CCNP SWITCH FLGA 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.
