Re: [IPCop-user] Alias IP - No arp refresh

[Simon B. <si...@ho...>]

Hi Joe,
> Anyone else having an issue with alias IPs and arp? I see arp requests
> for the interface IP every minute, but the alias IPs only send an arp
> request when the IP is initialized or IPCop is rebooted.

This is normal and expected. When an interface is initialised with the IP
addresses the TCP stack issues an ARP request to the network to determine if
the IP address is currently in use on the network. If there is no response
then the IP address is assigned to the interface and the interface is marked
as up.

You have mentioned in another post that you have seen arp requests from the
IPCOP interface for the GATEWAY ip address every min or so. This is normal
as any traffic that is sent from your IPCOP must be sent via the gateway ip
and ipcop has to know which mac address to send the packet to. The packet
will be sent with destination IP address such as 17.0.0.1 but with the
gateway MAC address. The gateway in this instance will then forward the
packet to its gateway (the next router in the line) and so on.

But, I'd be interested in the traffic flows just before the ARP request. If
there are normal ip traffic packets that are transmitted to the gateway
followed by an ARP for the gateway, this would indicate a problem with the
gateway. Entries in the ARP cache are periodically and automatically
verified unless continually used or there is no response from the
destination.

> Been having
> issues with my ISP halting forwarding traffic to me and found that all
> I have to do is uncheck and recheck the alias IP box in the GUI
> (forces an arp request) and things magically start working again...

This maybe a red herring I think. More happens than just an ARP request. The
interface is reset (perhaps someone can confirm this in this instance?) and
the gateway will see that layer 2 has gone down (which is what happens when
layer1 goes - ethernet unplugged). This forces a reset on the gateway as
well as the interface that you reset. A method of testing this is to unplug
the connection to the gateway and then plug it back in. My guess will be
that all will start to work again.

Anyway, all this points to a hardware or software issue with the ISP. I
would check that the routing is ok by using tools on
<http://www.traceroute.org/>. The routing of your subnet (alias IP's) should
always be there and you should be able to see that the route taken for the
primary IP address is the same as the aliases.

If this was an issue with the IPCOP interface/hardware, then you would see
traffic from the gateway destined for your IP addresses being placed on the
wire with no response, followed by an ARP request for the alias IP address
all from the gateway MAC/IPaddress. 
 
> 
> Running 1.4.21 RED/GREEN/BLUE/ORANGE
> 
> Have this statement in my rc.firewall.local to SNAT the Orange IP to
> the public IP:
> 
> /sbin/iptables -t nat -A CUSTOMPOSTROUTING -s 192.168.253.18 -o eth3
> -j SNAT --to [PUBLIC IP]
> 
> Inbound traffic is port forwarded to the Orange IP.

This is fine and only changes the IP address of traffic initiated by
192.168.253.18. It has no effect on traffic initiated from the internet as
this will be handled by the inbound Nat rules and the source IP of the
response packets will be the same as the alias IP address where the packets
were sent to.

I hope that this helps.

Simon.

PS. For those that are interested this may be a useful resource:
<http://linux-ip.net/html/index.html>
PPS. Your mileage may vary :-)