kernel: arpresolve: can't allocate llinfo for 65.59.233.102
Garrett Cooper
yanegomi at gmail.com
Fri Sep 14 06:34:32 UTC 2012
On Thu, Sep 13, 2012 at 11:29 PM, Вадим Уразаев <tretuliy2 at gmail.com> wrote:
> I am using two lagg interfaces :
> lagg0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
> options=400b8<VLAN_MTU,VLAN_HWTAGGING,JUMBO_MTU,VLAN_HWCSUM,VLAN_HWTSO>
> ether 00:1b:21:55:a7:c4
> nd6 options=9<PERFORMNUD,IFDISABLED>
> media: Ethernet autoselect
> status: active
> laggproto lacp
> laggport: igb1 flags=1c<ACTIVE,COLLECTING,DISTRIBUTING>
> laggport: igb0 flags=1c<ACTIVE,COLLECTING,DISTRIBUTING>
>
> lagg1: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
> options=400b8<VLAN_MTU,VLAN_HWTAGGING,JUMBO_MTU,VLAN_HWCSUM,VLAN_HWTSO>
> ether 00:1b:21:63:59:c8
> nd6 options=9<PERFORMNUD,IFDISABLED>
> media: Ethernet autoselect
> status: active
> laggproto lacp
> laggport: igb3 flags=1c<ACTIVE,COLLECTING,DISTRIBUTING>
> laggport: igb2 flags=1c<ACTIVE,COLLECTING,DISTRIBUTING>
>
> I am not using ipfw nat for a while, and problem still occur.
>
> uname -a
> FreeBSD bras-2 9.0-RELEASE FreeBSD 9.0-RELEASE #1: Tue Feb 28 10:50:04 EET
> 2012 root at bras:/usr/obj/usr/src/sys/BRAS amd64
> Xeon X3440/RAM - 4G, two network cards Intel Pro 1000 ET Dual Port.
> It has 400 Mbit/s traffic at peak going through.
>
>
> my ipfw rules are:
>
> 00100 allow ip from any to any via lo0
> 00200 deny ip from 127.0.0.0/8 to any
> 00300 deny ip from any to 127.0.0.0/8
> 00400 netgraph 1 udp from 10.0.0.0/8 to any dst-port 53 in via vlan* //
> Filter MX recods requests from RFC Net
> 00500 deny ip from table(2) to not x.x.x.x dst-port 25
> 01000 allow udp from any 68 to any dst-port 67 in via vlan*
> 01100 deny log icmp from any to any icmptypes 5,9,10
> 07000 allow ip from any to table(80) dst-port 53 // DNS ALLOW
> 07100 allow ip from table(80) 53 to any // DNS Reverse Allow
> 07200 allow ip from any to x.x.x.x // Billing Allow
> 07300 allow ip from x.x.x.x to any // Billing Reverse Allow
> 08000 fwd 127.0.0.1,83 ip from table(3) to not x.x.x.x dst-port 80,443,8080
> in recv vlan* // New-Computers
> 08100 fwd 127.0.0.1,82 ip from not table(20) to not x.x.x.x dst-port
> 80,443,8080 in recv vlan* // Debotors
> 09000 allow ip from any to 255.255.255.255 dst-port 67 in via vlan*
> 10000 allow ip from table(20) to table(10) in recv vlan* // UA-IX Without
> shapers
> 10100 allow ip from table(10) to table(20) out xmit vlan*
> 10200 allow ip from table(20,0) to any in recv vlan*
> 10300 allow ip from any to table(20,0) out xmit vlan*
> 40000 pipe tablearg ip from any to table(20) out xmit vlan*
> 40100 pipe tablearg ip from table(21) to any in recv vlan*
> 40800 allow ip from table(20) to any out xmit ext_if
> 40900 allow ip from any to table(20) in recv ext_if
> 50000 allow ip from me to any
> 50005 allow tcp from any to me established
> 50010 allow tcp from any to me dst-port 125,53,83,84 setup
> 50020 allow udp from any to me dst-port 53,161
> 50030 allow icmp from any to me icmptypes 0,8
> 50040 allow tcp from x.x.x.x to me dst-port 72 setup
> 50050 deny tcp from any to me dst-port 72 setup
> 50100 allow ip from any to me
> 50300 allow ip from any to any out via vlan*
> 65500 deny log ip from any to any
> 65535 allow ip from any to any
>
> route monitor didn`t show event that changes default router.
> I use a script in crontab to restore proper gateway, for now.
> I am wandering: is it dummynet issue, because we all using it.
> My statistics of changing default gateway is follows
> August 5
> August 14
> August 18
> September 2
> September 6
>
> I will appriciate any suggestion in debugging that problem.
Try disabling tso at the global level in the kernel. Under some
circumstances with some drives VLAN_HWTSO -> TSO.
-Garrett
More information about the freebsd-net
mailing list