Trent,
Thank you for your answer. Setting the arp entry for the default gateway
gives an improvement indeed. There are no more missing packets!. I have
done some network monitoring as suggested by Tom and I found the
following (Partial "tcpdump -i eth0 -n arp" command output):
19:07:28.854526 ARP, Request who-has 201.208.128.1 tell 201.208.134.118,
length 28
19:07:29.854527 ARP, Request who-has 201.208.128.1 tell 201.208.134.118,
length 28
19:07:30.854526 ARP, Request who-has 201.208.128.1 tell 201.208.134.118,
length 28
19:07:47.263749 ARP, Request who-has 207.126.103.202 tell 10.36.36.36,
length 46
19:07:59.126529 ARP, Request who-has 201.208.128.1 tell 201.208.134.118,
length 28
19:08:00.126528 ARP, Request who-has 201.208.128.1 tell 201.208.134.118,
length 28
19:08:01.126529 ARP, Request who-has 201.208.128.1 tell 201.208.134.118,
length 28
19:08:02.626528 ARP, Request who-has 201.208.128.1 tell 201.208.134.118,
length 28
19:08:03.626527 ARP, Request who-has 201.208.128.1 tell 201.208.134.118,
length 28
19:08:04.626527 ARP, Request who-has 201.208.128.1 tell 201.208.134.118,
length 28
19:08:06.226533 ARP, Request who-has 201.208.128.1 tell 201.208.134.118,
length 28
19:08:06.340548 ARP, Reply 201.208.128.1 is-at 00:90:1a:a0:1f:51, length 46
19:08:46.766526 ARP, Request who-has 201.208.128.1 tell 201.208.134.118,
length 28
19:08:47.766526 ARP, Request who-has 201.208.128.1 tell 201.208.134.118,
length 28
19:08:48.424818 ARP, Reply 201.208.128.1 is-at 00:90:1a:a0:1f:51, length 46
19:09:07.302280 ARP, Request who-has 209.0.72.7 tell 10.36.36.36, length 46
19:09:27.119023 ARP, Request who-has 201.208.128.1 tell 201.208.134.118,
length 28
19:09:28.118528 ARP, Request who-has 201.208.128.1 tell 201.208.134.118,
length 28
19:09:29.118528 ARP, Request who-has 201.208.128.1 tell 201.208.134.118,
length 28
19:09:30.134526 ARP, Request who-has 201.208.128.1 tell 201.208.134.118,
length 28
19:09:31.134526 ARP, Request who-has 201.208.128.1 tell 201.208.134.118,
length 28
19:09:32.134526 ARP, Request who-has 201.208.128.1 tell 201.208.134.118,
length 28
19:09:33.142526 ARP, Request who-has 201.208.128.1 tell 201.208.134.118,
length 28
19:09:34.142528 ARP, Request who-has 201.208.128.1 tell 201.208.134.118,
length 28
19:09:35.142528 ARP, Request who-has 201.208.128.1 tell 201.208.134.118,
length 28
19:09:36.146524 ARP, Request who-has 201.208.128.1 tell 201.208.134.118,
length 28
19:09:36.255875 ARP, Reply 201.208.128.1 is-at 00:90:1a:a0:1f:51, length 46
During these ARP request, there is incoming communication but not
outgoing (no Default GateWay founded). The ARP cache shows the ISP DGW
address as "(incomplete)" during these updates. Could it be caused by a
problem at the ISP side? Is it possible that there is some type of
attack protection (on the DGW) that restrict the ARP reply to one each
few seconds?
I have changed the sysctl.conf values as you indicated, specially
"net.ipv4.neigh.eth0.gc_stale_time" , but the ARP request still shows
every few seconds, so there is something forcing the update. I have seen
no "ARP unsolicited reply" so I don't think it could be an arp-spoofing
attack. Anyway I installed arpwatch and found this:
arpwatch: bogon 00:90:1a:a0:1f:51 eth0
arpwatch: bogon 10.36.36.36 00:30:0a:0c:30:fb eth0
These repeats regularly. 00:90:1a:a0:1f:51 is the ISP DGW. I did a dig
-x on all 3 IPs (201.208.128.1, 172.17.49.239, 10.36.36.36) and only
201.208.128.1 shows a valid DNS name (the ISP domain), so I assume that
is the valid DGW. Could the ARP Request of 172.17.49.239 cause the ARP
cache update?
I have dismissed cabling errors as after the "arp -s ...", there are no
missing packets anymore.
Regards,
On 08/30/10 21:04, Trent O'Callaghan wrote:
> see below for suggestions:
>
> On 28 August 2010 02:46, Carlos Siso <[email protected]
> <mailto:[email protected]>> wrote:
>
> ...
> The weird part:
>
> 1.- Disabling one of the internal network interfaces ("ifdown eth1" or
> "ifdown eth2") fix the problem for the other one.
> 2.- While pinging from inside the router/firewall to the Internet, the
> packet loss, when pinging from a PC in the "loc" or "cus" zones, are
> reduced considerably (at almost 1% packed loss on an 10 minute ping
> period). Actually, I keep a console session on the router/firewall
> pinging the default gateway at the Internet to have things working
> (more
> or less).
>
> Instead of pinging the gateway, can you set the arp entry for the IP
> ADDRESS as static and see if that also gives an improvement?
>
> sudo arp -s 201.208.128.1 00:00:00:00:00:00
> [but with 00:00:00:00:00:00 replaced with correct mac-address]
>
> I have had a similar situation but my newer builds are working without
> the pinging
>
> What I did for newer builds is in /etc/sysctl.conf I placed:
> net.netfilter.nf_conntrack_acct = 1
> net.ipv4.conf.eth0.arp_announce = 2
> net.ipv4.conf.eth0.arp_filter = 1
> net.ipv4.neigh.eth0.gc_stale_time = 3600
>
>
> Any help you could provide to resolve this problem will be
> appreciated.
> Thank you.
>
> Regards,
>
> Carlos Siso
>
>
> --
> --
> Carlos Siso
>
>
>
> ------------------------------------------------------------------------------
> Sell apps to millions through the Intel(R) Atom(Tm) Developer Program
> Be part of this innovative community and reach millions of netbook
> users
> worldwide. Take advantage of special opportunities to increase
> revenue and
> speed time-to-market. Join now, and jumpstart your future.
> http://p.sf.net/sfu/intel-atom-d2d
> _______________________________________________
> Shorewall-users mailing list
> [email protected]
> <mailto:[email protected]>
> https://lists.sourceforge.net/lists/listinfo/shorewall-users
>
>
>
>
> --
> Regards,
> Trent O'Callaghan
> Network Manager
> Nearmap
>
> www.nearmap.com <http://www.nearmap.com>
>
>
> ------------------------------------------------------------------------------
> This SF.net Dev2Dev email is sponsored by:
>
> Show off your parallel programming skills.
> Enter the Intel(R) Threading Challenge 2010.
> http://p.sf.net/sfu/intel-thread-sfd
>
>
> _______________________________________________
> Shorewall-users mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/shorewall-users
--
--
Carlos Siso
------------------------------------------------------------------------------
This SF.net Dev2Dev email is sponsored by:
Show off your parallel programming skills.
Enter the Intel(R) Threading Challenge 2010.
http://p.sf.net/sfu/intel-thread-sfd
_______________________________________________
Shorewall-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/shorewall-users
