| For those not familiar with ARP, I'll provide a simple description here.
The TCP/IP software suite uses IP addresses to route packets (data). IP is
designed to operate over many different types of hardware mediums. The Address
Resolution Protocol (ARP) is used to map Internet addresses to physical
hardware addresses. For IP to work over the Ethernet, the IP node sending a
packet must know the physical Ethernet hardware address of the destination
node (end node or router). For the rest of this information, I'll assume that
IP is executing over an Ethernet network. IP maintains an ARP cache of IP to
Ethernet address pairs. If a destination IP address does not have an entry in
the ARP cache IP must obtain the Ethernet address of the destination IP node;
this is known as resolving the IP address to a physical hardware. When IP
wants to resolve the IP address, IP sends a broadcast message that asks the
destination node to provide its physical hardware address which maps to the IP
address.
Now, lets attempt to address the questions in note 269.0. In note
260.0, NBOSWS::BLUNDELL writes:
>>>
>>> We are using the AXPvme CPU in a Front End communication configuration.
>>> We experience a problem with the ARP (Address Resolution Protocol)
>>> handling in the unit as follows, the CPU (called X) broadcasts the ARP
>>> request with the broadcast IP address instead of using the correct address
>>> to device Y, which is known by X. This gives an extreme load in our inhouse
>>> network since the requests are very much frequent.
>>>
Sounds to me that, so far, the VxWorks implementation is executing
correctly. In order for CPU X to communicate to CPU Y the IP/Ethernet mapping
has to be known.
When you say the CPU X knows device Y -- do you mean that IP executing
on node X already knows the IP/Ethernet mapping of node Y? How did CPU X
know CPU Y's IP/Ethernet mapping -- hard coded or had performed an ARP packet
exhange already at some point in time?
I'm not an expert on the VxWorks implementation of IP. However, here
are some things to consider and investigate.
The ARP cache is normally limited to a specific number of entries.
When IP needs to add an entry to the ARP cache, and the cache is currently full,
the oldest entry is deleted to make room for the new entry. You didn't
mention how many IP systems CPU X communicates with. If its only one then
there shouldn't be that many entries in the cache unless IP nodes are
broadcasting their IP/Ethernet mapping when they boot or at periodic
intervals. Try using the arpShow() function to dump the ARP cache to see how
many entries there are in the cache. If CPU X is always ARPing CPU Y the ARP
cache may be configured too small. You could look for a VxWorks definition to
increase the ARP cache limit. Maybe a VxWorks expert could help here :-).
Also, entries in the cache time out and are deleted. Could the mapping to CPU
Y be timming out causing CPU X to re-ARP CPU Y?
Most implementations of IP provide an interface to add entries to the
ARP cache. VxWorks does provide a function to add ARP entries in arpLib. The
function arpAdd() always you to specify that an entry is permanent. If you
knew the IP/Ethernet mapping to CPU Y, you could create an entry which will
not be subject to timing out or deletion to make room for a dynamically
resolved IP/Hardware address mapping. However, this has a downside. This
would mean that if CPU Y's Ethernet address was to change, then the software
for the front end would have to be modified.
Regards,
-Steve-
|
| >You could look for a VxWorks definition to increase the ARP cache
>limit.
You can't change the size of the arp table on VxWorks without being
able to re-compile the network code, which you can't. There is a global
variable, arptab_size, which gives the size of the table. However,
changing it will screw up future calculations on the table, which is
allocated statically.
The current size of the table (VxWorks V5.2B) allows 592 arp entries.
You'd hope that would be plenty large enough to prevent arp thrashing.
|
| Hi (this note is also posted to realtime@helix)
Below is the reply from the customer. 2 questions are prompted from his
reply:-
1. Can anyone provide details of how ARP cache entries are invalidated?
Customer is saying that the ARP packets are still being sent evry 2
minutes. My info says that completed entries are timed out after 20
minutes, it sounds like VxWorks is doing that after 2 minutes, who is
correct?
2. Can someone update the VxWorks docu to document what this customer
found?
Rgds
Bill
Customer response ----------
Hello,
Thank's for your response. We did some more investigations on our
VxWorks
system in forms of LAN analyzing etc.
Our conclusion as follows:
Add a submask in the VxWorks boot:
"inet on ethernet (e) : xxx.xxx.xxx.xxx:ffffff00"
Now ARP is sent every two minutes to the specified host, instead many
times per
second to all hosts connected to the network.
This is something DEC should write about in the documentation. A
general
comment is that the AXPvme documentation is "thin".
A comment:
>>coments from Bill Blundell
>>
>>To expand on what Steve Ducharme says, the request
>>MUST be broadcast to the network, this is
>>the only mechanism available to ensure that all
>>possible destinations on the network are checked
>>ASAP. However, when the adress has been obtained,
>>it is cached for future use hence the broadcast should
>>only occur once, the first time the destination station is
>>accessed.
Yes, I agree that the ARP must be transmitted in broadcast. Our problem
is that
the ARP message asked for the ethernet address
for the broadcast IP address. Our ARP cach now contains only two
entries, one
per host.
Thanks again
------------
|