Hello,
I have a very simple router/firewall setup with 3 Ethernet interfaces..
The setup is used to share an Internet connection between 2 unrelated
group of people. The setup is:
- eth0 connects to the Internet (net zone) via ADSL modem (IP address is
DHCP assigned by provider).
- eth1 connects to a local network (loc zone).
- eth2 connects to an another local network (cus zone).
Traffice shaping is not configured nor any other packet limit option.
The "cus" zone is not a "DMZ" and there is NAT implemented
between eth0
and eth1,eth2.
Everything is working as planned (routing, Nat, filtering etc.) except
for the following problem:
1.- Ping from a PC in the "loc" zone to any address (active) in the
Internet miss some (aprox. 1% to 20% ) packets.
2.- Ping from a PC in the "cus" zone to any address (active) in the
Internet miss some (aprox. 1% to 20% ) packets.
I have performed the following test:
1.- Pinging from inside the router/firewall (fw zone) to the same
addresses at the Internet does **not** miss packets.
2.- Pinging from a PC in the "loc" zone to the router/firewall does
**not** miss packets.
3.- Pinging from a PC in the "cus" zone to the router/firewall does
**not** miss packets.
4.- Pinging from a PC in the "loc" zone to a PC in the "cus"
zone does
**not** miss packets.
5.- Pinging from a PC in the "cus" zone to a PC in the "loc"
zone does
**not** miss packets.
6.- Connecting a PC directly to the ADSL modem and pinging the same
addresses at the Internet does **not** miss packets.
Additional information:
1.- All the router/firewall hardware, including the network cards has
been replaced and the problem persists.
2.- The ADSL modem was replaced and the problem persist.
2.- The network interfaces (eth0, eth1 and eth2) does **not** report any
error (frame, overruns, drops etc.).
3.- The problems first show itself with a Gentoo based router/firewall
and then with a Ubuntu based one. The Gentoo system was compiled without
IPV6 support.
4.- The missing packet problem shows with other protocols (Browsing,
VoIP, ftp etc.) to any valid site.
5.- With VoIP, the problem shows as intermittent audio silences on
outgoing audio (from the loc/cus zones to the Internet), while incoming
audio (from the Internet to the loc/cus zones) does **not** shows problems.
6.- The logs does not shows any dropped or rejected packet aside proper
"net2fw" filtered packets.
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).
The system information:
/sbin/shorewall version
4.4.6
ip addr show
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue state UNKNOWN
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast
state UNKNOWN qlen 1000
link/ether 40:61:86:78:73:5f brd ff:ff:ff:ff:ff:ff
inet 201.208.134.118/19 brd 201.208.159.255 scope global eth0
inet6 fe80::4261:86ff:fe78:735f/64 scope link
valid_lft forever preferred_lft forever
3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast
state UNKNOWN qlen 1000
link/ether 00:e0:4c:36:c6:0e brd ff:ff:ff:ff:ff:ff
inet 192.168.30.1/24 brd 192.168.30.255 scope global eth1
inet6 fe80::2e0:4cff:fe36:c60e/64 scope link
valid_lft forever preferred_lft forever
4: eth2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast
state UNKNOWN qlen 1000
link/ether 00:00:21:f1:50:d0 brd ff:ff:ff:ff:ff:ff
inet 192.168.249.1/24 brd 192.168.249.255 scope global eth2
inet6 fe80::200:21ff:fef1:50d0/64 scope link
valid_lft forever preferred_lft forever
ip route show
192.168.30.0/24 dev eth1 proto kernel scope link src 192.168.30.1
192.168.249.0/24 dev eth2 proto kernel scope link src 192.168.249.1
201.208.128.0/19 dev eth0 proto kernel scope link src 201.208.134.118
default via 201.208.128.1 dev eth0 metric 100
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
On 8/27/10 11:46 AM, Carlos Siso wrote:> 1.- All the router/firewall hardware, including the network cards has > been replaced and the problem persists.What about the cables?> The weird part: > > 1.- Disabling one of the internal network interfaces ("ifdown eth1" or > "ifdown eth2") fix the problem for the other one.Are the two internal networks bridged outside of the gateway/router? Are you sure?> 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). >I think that you need to monitor the traffic with a packet stiffer and see what is happening on the links. And be sure to look at the ethernet headers and ARP traffic. -Tom -- Tom Eastep \ When I die, I want to go like my Grandfather who Shoreline, \ died peacefully in his sleep. Not screaming like Washington, USA \ all of the passengers in his car http://shorewall.net \________________________________________________ ------------------------------------------------------------------------------ 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
I have seen similar symptoms with ipmi Suggest check of BIOS settings and disable IPMI, if not required. Sent from my iPhone On 28/08/2010, at 3:49 AM, Tom Eastep <teastep@shorewall.net> wrote:> On 8/27/10 11:46 AM, Carlos Siso wrote: > >> 1.- All the router/firewall hardware, including the network cards has >> been replaced and the problem persists. > > What about the cables? > > >> The weird part: >> >> 1.- Disabling one of the internal network interfaces ("ifdown eth1" or >> "ifdown eth2") fix the problem for the other one. > > Are the two internal networks bridged outside of the gateway/router? > > Are you sure? > >> 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). >> > > I think that you need to monitor the traffic with a packet stiffer and > see what is happening on the links. And be sure to look at the ethernet > headers and ARP traffic. > > -Tom > -- > Tom Eastep \ When I die, I want to go like my Grandfather who > Shoreline, \ died peacefully in his sleep. Not screaming like > Washington, USA \ all of the passengers in his car > http://shorewall.net \________________________________________________ > > ------------------------------------------------------------------------------ > 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 > Shorewall-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/shorewall-users------------------------------------------------------------------------------ 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
Tom, Thank for your response, 1.- I tested the cables and they are ok. Aside, the network communication inside the "loc" and "cus" zones are working Ok and there is no report of any communicactions erros in the interface cards. 2.- Each network have they own separate switch and I am sure there is not a bridge between them (by cable or wireless). 3.- I will start the packet analysis later today. Regards, On 08/27/10 15:19, Tom Eastep wrote:> On 8/27/10 11:46 AM, Carlos Siso wrote: > >> 1.- All the router/firewall hardware, including the network cards has >> been replaced and the problem persists. > What about the cables? > > >> The weird part: >> >> 1.- Disabling one of the internal network interfaces ("ifdown eth1" or >> "ifdown eth2") fix the problem for the other one. > Are the two internal networks bridged outside of the gateway/router? > > Are you sure? > >> 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). >> > I think that you need to monitor the traffic with a packet stiffer and > see what is happening on the links. And be sure to look at the ethernet > headers and ARP traffic. > > -Tom > > > ------------------------------------------------------------------------------ > 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 > Shorewall-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/shorewall-users-- -- 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
Trent, I will check the BIOS as soon as I cant shutdown the router. Thank yoy. Regards, On 08/27/10 22:12, Trent O''Callaghan wrote:> I have seen similar symptoms with ipmi > > Suggest check of BIOS settings and disable IPMI, if not required. > > Sent from my iPhone > > On 28/08/2010, at 3:49 AM, Tom Eastep <teastep@shorewall.net> wrote: > >> On 8/27/10 11:46 AM, Carlos Siso wrote: >> >>> 1.- All the router/firewall hardware, including the network cards has >>> been replaced and the problem persists. >> What about the cables? >> >> >>> The weird part: >>> >>> 1.- Disabling one of the internal network interfaces ("ifdown eth1" or >>> "ifdown eth2") fix the problem for the other one. >> Are the two internal networks bridged outside of the gateway/router? >> >> Are you sure? >> >>> 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). >>> >> I think that you need to monitor the traffic with a packet stiffer and >> see what is happening on the links. And be sure to look at the ethernet >> headers and ARP traffic. >> >> -Tom >> -- >> Tom Eastep \ When I die, I want to go like my Grandfather who >> Shoreline, \ died peacefully in his sleep. Not screaming like >> Washington, USA \ all of the passengers in his car >> http://shorewall.net \________________________________________________ >> >> ------------------------------------------------------------------------------ >> 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 >> Shorewall-users@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/shorewall-users > ------------------------------------------------------------------------------ > 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 > Shorewall-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/shorewall-users >-- -- 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
Trent, I check the BIOS and it does not support IPMI. Thank you anyway. On 08/30/10 09:51, Carlos Siso wrote:> Trent, > > I will check the BIOS as soon as I cant shutdown the router. Thank yoy. > > Regards, > > On 08/27/10 22:12, Trent O''Callaghan wrote: >> I have seen similar symptoms with ipmi >> >> Suggest check of BIOS settings and disable IPMI, if not required. >> >> Sent from my iPhone >> >> On 28/08/2010, at 3:49 AM, Tom Eastep <teastep@shorewall.net> wrote: >> >>> On 8/27/10 11:46 AM, Carlos Siso wrote: >>> >>>> 1.- All the router/firewall hardware, including the network cards has >>>> been replaced and the problem persists. >>> What about the cables? >>> >>> >>>> The weird part: >>>> >>>> 1.- Disabling one of the internal network interfaces ("ifdown eth1" or >>>> "ifdown eth2") fix the problem for the other one. >>> Are the two internal networks bridged outside of the gateway/router? >>> >>> Are you sure? >>> >>>> 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). >>>> >>> I think that you need to monitor the traffic with a packet stiffer and >>> see what is happening on the links. And be sure to look at the ethernet >>> headers and ARP traffic. >>> >>> -Tom >>> -- >>> Tom Eastep \ When I die, I want to go like my Grandfather who >>> Shoreline, \ died peacefully in his sleep. Not screaming like >>> Washington, USA \ all of the passengers in his car >>> http://shorewall.net \________________________________________________ >>> >>> ------------------------------------------------------------------------------ >>> 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 >>> Shorewall-users@lists.sourceforge.net >>> https://lists.sourceforge.net/lists/listinfo/shorewall-users >> ------------------------------------------------------------------------------ >> 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 >> Shorewall-users@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/shorewall-users >>-- -- 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
see below for suggestions: On 28 August 2010 02:46, Carlos Siso <casiso@gmail.com> 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 IPADDRESS 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 > Shorewall-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/shorewall-users >-- Regards, Trent O''Callaghan Network Manager Nearmap 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
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 <casiso@gmail.com > <mailto:casiso@gmail.com>> 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 > Shorewall-users@lists.sourceforge.net > <mailto:Shorewall-users@lists.sourceforge.net> > 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 > Shorewall-users@lists.sourceforge.net > 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
The arpwatch output is: arpwatch: bogon 172.17.49.239 00:90:1a:a0:1f:51 eth0 arpwatch: bogon 10.36.36.36 00:30:0a:0c:30:fb eth0 Regards, On 08/30/10 21:04, Trent O''Callaghan wrote:> see below for suggestions: > > On 28 August 2010 02:46, Carlos Siso <casiso@gmail.com > <mailto:casiso@gmail.com>> 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 > Shorewall-users@lists.sourceforge.net > <mailto:Shorewall-users@lists.sourceforge.net> > 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 > Shorewall-users@lists.sourceforge.net > 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