How can I find the reason network writes fail with ENOMEM on 7.x?
I'm getting network write failures on a host running 7.2-PRERELEASE (I know, I should update it to STABLE, but I've heard of similar reports on 7-S too) Failures are expressed for example in BIND named[72084]: /usr/src/lib/bind/isc/../../../contrib/bind9/lib/isc/unix/socket.c:1567: unexpected error: named[72084]: internal_send: 192.168.71.91#1049: Cannot allocate memory named[72084]: client 192.168.71.91#1049: error sending response: out of memory and on ssh session spontaneously breaking with "Write failed: Cannot allocate memory" Frequency of those failures clearly correlates with network load for the host, which is mainly doing dummynet and ng_nat. How can I find what to tune in this case? -- Eugene Perevyazko ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: How can I find the reason network writes fail with ENOMEM on 7.x?
On Fri, Dec 11, 2009 at 08:37:29AM -0200, Victor Lima wrote: > Have you checked your memory integrity? Maybe you should consider > buying some more mem to that machine. Have you check with top(1) how > much memory is actually available when the write fails? > That's not the lack of virtual/physical memory - the host has some "free" and lots of "Inact" memory and uses no swap space yet. Can it be related to those sysctls? vm.kmem_size_scale: 3 vm.kmem_size_max: 335544320 vm.kmem_size_min: 0 vm.kmem_size: 335544320 -- Eugene Perevyazko ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: How can I find the reason network writes fail with ENOMEM on 7.x?
Have you checked your memory integrity? Maybe you should consider buying some more mem to that machine. Have you check with top(1) how much memory is actually available when the write fails? Att, Victor Lima Em 11/12/2009, às 08:29, Eugene Perevyazko escreveu: I'm getting network write failures on a host running 7.2-PRERELEASE (I know, I should update it to STABLE, but I've heard of similar reports on 7-S too) Failures are expressed for example in BIND named[72084]: /usr/src/lib/bind/isc/../../../contrib/bind9/lib/isc/ unix/socket.c:1567: unexpected error: named[72084]: internal_send: 192.168.71.91#1049: Cannot allocate memory named[72084]: client 192.168.71.91#1049: error sending response: out of memory and on ssh session spontaneously breaking with "Write failed: Cannot allocate memory" Frequency of those failures clearly correlates with network load for the host, which is mainly doing dummynet and ng_nat. How can I find what to tune in this case? -- Eugene Perevyazko ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org" ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Racoon site-to site
I have a site-to-site vpn between these two:
1. FreeBSD 7.2-RELEASE-p4, racoon, ipsec-tools-0.7.3
2. Symantec VPN 100, (also known as "Nexland Pro 800")
I have intermittent connection problems between these two and I can't seem
to identify what the problem is. I realize the complexity and challenge in
getting two different ipsec-boxes talking to each other but I thought I
would have a go before I replace the Symantec-box. If I restart racoon or
wait approximately 30 min the connection is re-established.
What would be the obvious way to debug this? Any suggestions on what to
tweak appreciated.
//Jon
Info:
Keying: IKE PSK
Phase1:
encryption: DES
Authentication: MD5
SA Lifetime: 28800 seconds
Phase2:
Encryption: DES
Authentication: MD5
SA Lifetime: 3600 seconds
racoon.conf:
pathpre_shared_key "/usr/local/etc/racoon/psk.txt";
log info;
padding # options are not to be changed
{
maximum_length 20;
randomize off;
strict_checkoff;
exclusive_tail off;
}
timer
{
counter 5;
interval10 sec;
persend 1;
phase1 30 sec;
phase2 15 sec;
}
listen
{
isakmp local.ip.address [500];
}
remote re.mote.ip.address [500]
{
exchange_mode aggressive,main;
doi ipsec_doi;
situation identity_only;
my_identifier address local.ip.address;
peers_identifieraddress re.mote.ip.address;
initial_contact on;
lifetimetime 8 hour;
passive off;
proposal_check obey;
generate_policy off;
proposal {
encryption_algorithmdes;
hash_algorithm md5;
authentication_method pre_shared_key;
lifetime time 30 sec;
dh_group1;
}
}
sainfo (address 192.168.1.0/24 any address 192.168.100.0/24 any)
{
pfs_group 1;
lifetimetime3600 sec;
encryption_algorithmdes;
authentication_algorithmhmac_md5,hmac_sha1;
compression_algorithm deflate;
}
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: Racoon site-to site
Jon Otterholm wrote:
>
> If I restart racoon or wait approximately 30 min the connection is
> re-established.
Since this is approximately ½of the phase 2 lifetime, you are probably
running into lifetime negotiation issues, or PFS issues.
> What would be the obvious way to debug this? Any suggestions on what
> to tweak appreciated.
I would turn up the debugging on racoon to get more information around
the time that the tunnel fails.
> sainfo (address 192.168.1.0/24 any address 192.168.100.0/24 any)
> {
> pfs_group 1;
> lifetimetime3600 sec;
> encryption_algorithmdes;
> authentication_algorithmhmac_md5,hmac_sha1;
> compression_algorithm deflate;
> }
My hunch is that you have a PFS mismatch, so that the first tunnel
negotiates, but the second SA negotiation fails, then the third
succeeds, etc.
--
David DeSimone == Network Admin == f...@verio.net
"I don't like spinach, and I'm glad I don't, because if I
liked it I'd eat it, and I just hate it." -- Clarence Darrow
This email message is intended for the use of the person to whom it has been
sent, and may contain information that is confidential or legally protected. If
you are not the intended recipient or have received this message in error, you
are not authorized to copy, distribute, or otherwise use this message or its
attachments. Please notify the sender immediately by return e-mail and
permanently delete this message and any attachments. Verio, Inc. makes no
warranty that this email is error or virus free. Thank you.
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: ndis: broken scan
On 12/7/09, Paul B Mahol wrote: > Patch attached to fix scan results. > Bug is obvious if you use -v flag: > ifconfig -v wlan0 list scan > > It is interesting, that it never got noticed. I got hit with this one > when working on WPA instead of WPA2(RSN). In that case wpa_supplicant > would never pick AP because it doesnt see WPA, it could see only RSN, > now with this patch it see much more, like WME; and > ifconfig wlan0 list scan > output is more useful. > http://www.freebsd.org/cgi/query-pr.cgi?pr=141376 Bump! -- Paul B Mahol ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: Racoon site-to site
11 dec 2009 kl. 17.34 skrev "David DeSimone" :
Jon Otterholm wrote:
If I restart racoon or wait approximately 30 min the connection is
re-established.
Since this is approximately ½of the phase 2 lifetime, you are proba
bly
running into lifetime negotiation issues, or PFS issues.
What would be the obvious way to debug this? Any suggestions on what
to tweak appreciated.
I would turn up the debugging on racoon to get more information around
the time that the tunnel fails.
sainfo (address 192.168.1.0/24 any address 192.168.100.0/24 any)
{
pfs_group 1;
lifetimetime3600 sec;
encryption_algorithmdes;
authentication_algorithmhmac_md5,hmac_sha1;
compression_algorithm deflate;
}
My hunch is that you have a PFS mismatch, so that the first tunnel
negotiates, but the second SA negotiation fails, then the third
succeeds, etc.
But wood it not fail more offen then? I have set up a cronjob to ping
a server on the private Networks from the bad-side every 2 minutes and
somethimes it works for days without a single failure.
What debuglevel would be suitable?
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: Racoon site-to site
At 11:33 AM 12/11/2009, David DeSimone wrote:
Jon Otterholm wrote:
>
> If I restart racoon or wait approximately 30 min the connection is
> re-established.
Since this is approximately ½of the phase 2 lifetime, you are probably
running into lifetime negotiation issues, or PFS issues.
> What would be the obvious way to debug this? Any suggestions on what
> to tweak appreciated.
I would turn up the debugging on racoon to get more information around
the time that the tunnel fails.
> sainfo (address 192.168.1.0/24 any address 192.168.100.0/24 any)
> {
> pfs_group 1;
> lifetimetime3600 sec;
> encryption_algorithmdes;
> authentication_algorithmhmac_md5,hmac_sha1;
> compression_algorithm deflate;
> }
My hunch is that you have a PFS mismatch, so that the first tunnel
negotiates, but the second SA negotiation fails, then the third
succeeds, etc.
You might also want to turn on DPD (dead peer
detection) in ipsectools if you dont already have
it on both sides. Are you really using des for
the crypto ? Also, when the session is
negotiated, take a look at the output of
setkey -D
and see what was actually negotiated and post it
here (just make sure you get rid of the info on the E and A lines.
e.g.
1.1.1.2 2.2.2.2
esp mode=tunnel spi=125444787(0x077a22b3) reqid=16416(0x4020)
E: 3des-cbc 770cdd7b 770cdd7b 770cdd7b 770cdd7b 770cdd7b 770cdd7b
A: hmac-sha1 5cfdbabb 5cfdbabb 5cfdbabb 5cfdbabb 5cfdbabb
ie. mask out the 5cfdbabb and 770cdd7b values
before posting as thats your crypto :)
Also, when things "jam up", try instead,
racoonctl vpn-disconnect
and you wont have to restart things.
Also, what does
sysctl net.key.preferred_oldsa
show ?
---Mike
Mike Tancsa, tel +1 519 651 3400
Sentex Communications,m...@sentex.net
Providing Internet since 1994www.sentex.net
Cambridge, Ontario Canada www.sentex.net/mike
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: kern/141376: [ndis] [patch] broken scan by passing ies and ies_len pointer to net80211
Old Synopsis: ndis: broken scan New Synopsis: [ndis] [patch] broken scan by passing ies and ies_len pointer to net80211 Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Fri Dec 11 19:48:19 UTC 2009 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=141376 ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: Racoon site-to site
On 2009-12-11 20.23, "Mike Tancsa" wrote:
> At 11:33 AM 12/11/2009, David DeSimone wrote:
>> Jon Otterholm wrote:
>>>
>>> If I restart racoon or wait approximately 30 min the connection is
>>> re-established.
>>
>> Since this is approximately ½of the phase 2 lifetime, you are probably
>> running into lifetime negotiation issues, or PFS issues.
>>
>>> What would be the obvious way to debug this? Any suggestions on what
>>> to tweak appreciated.
>>
>> I would turn up the debugging on racoon to get more information around
>> the time that the tunnel fails.
>>
>>> sainfo (address 192.168.1.0/24 any address 192.168.100.0/24 any)
>>> {
>>> pfs_group 1;
>>> lifetimetime3600 sec;
>>> encryption_algorithmdes;
>>> authentication_algorithmhmac_md5,hmac_sha1;
>>> compression_algorithm deflate;
>>> }
>>
>> My hunch is that you have a PFS mismatch, so that the first tunnel
>> negotiates, but the second SA negotiation fails, then the third
>> succeeds, etc.
>
>
> You might also want to turn on DPD (dead peer
> detection) in ipsectools if you dont already have
> it on both sides. Are you really using des for
> the crypto ? Also, when the session is
> negotiated, take a look at the output of
> setkey -D
> and see what was actually negotiated and post it
> here (just make sure you get rid of the info on the E and A lines.
>
> e.g.
> 1.1.1.2 2.2.2.2
> esp mode=tunnel spi=125444787(0x077a22b3) reqid=16416(0x4020)
> E: 3des-cbc 770cdd7b 770cdd7b 770cdd7b 770cdd7b 770cdd7b 770cdd7b
> A: hmac-sha1 5cfdbabb 5cfdbabb 5cfdbabb 5cfdbabb 5cfdbabb
>
> ie. mask out the 5cfdbabb and 770cdd7b values
> before posting as thats your crypto :)
>
>
>
>Also, when things "jam up", try instead,
>
> racoonctl vpn-disconnect
>
> and you wont have to restart things.
>
> Also, what does
> sysctl net.key.preferred_oldsa
>
> show ?
It has not jamed up yet but here is output from sysctl:
net.key.preferred_oldsa: 1
Would it help setting it to 0 to force renewal of keys at reconnection?
//Jon
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: Racoon site-to site
At 04:43 PM 12/11/2009, Jon Otterholm wrote: > Also, what does > sysctl net.key.preferred_oldsa > > show ? It has not jamed up yet but here is output from sysctl: net.key.preferred_oldsa: 1 Would it help setting it to 0 to force renewal of keys at reconnection? I think it should allow your end to honor the other side's new SA should it want one ahead of schedule ---Mike Mike Tancsa, tel +1 519 651 3400 Sentex Communications,m...@sentex.net Providing Internet since 1994www.sentex.net Cambridge, Ontario Canada www.sentex.net/mike ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: Racoon site-to site
Mike Tancsa wrote: At 04:43 PM 12/11/2009, Jon Otterholm wrote: > Also, what does > sysctl net.key.preferred_oldsa > > show ? It has not jamed up yet but here is output from sysctl: net.key.preferred_oldsa: 1 Would it help setting it to 0 to force renewal of keys at reconnection? I think it should allow your end to honor the other side's new SA should it want one ahead of schedule yes this sysctl allows the other side to negotiate a new key at any time. (for example after it reboots). If you have the old SA prefered, then after your peer reboots and comes up again. You can't communicate with it until the SA you negotiated with him originally times out (which may be some minutes or even hours later). ---Mike Mike Tancsa, tel +1 519 651 3400 Sentex Communications,m...@sentex.net Providing Internet since 1994www.sentex.net Cambridge, Ontario Canada www.sentex.net/mike ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org" ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
10gigE link with FreeBSD hosts ?
I am seeing Sun Microsystems branded 10gigE adaptors (pci-x) on ebay nowadays for $500. So ... let's say I took some plain-jane, modern-ish PC (intel core, or c2d, pci-x, etc.) and set up this topology: a <-- cable --> b <-- cable --> c and on each of (a) and (c) put one 10gigE adaptor, and on (b) put two 10gigE adaptors, and set up bridging on (b) Would it be reasonable to then expect to transfer data from (a) to (c) at a, roughly, 10 gigabit/s rate ? If not, what is the limiting factor ? The idea is that I would use a commodity PC + multiple pci-X slots as a "poor mans" 10gigE switch ... I can't afford an actual 10gigE switch, but I don't need that many ports anyway. Any comments or field reports would be appreciated. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: 10gigE link with FreeBSD hosts ?
Can't get 10 gigabit thru a PCI-X slot, it doesnt have the bandwidth, you need PCI Express, in fact you will find that lots of factors will come into play and might keep you from achieving optimal thruput. For a two port adapter you will need an 8x PCIE slot, preferably Gen 2, and if all three systems don't have that its gonna slow everyone down. Further, once you involve packet forwarding it gets even more demanding. Trying to do it 'on the cheap' and you might get 3 or 4 Gb, maybe even worse depending. Takes quality to get real performance, sorry :) Jack On Fri, Dec 11, 2009 at 2:30 PM, George Sanders wrote: > > > I am seeing Sun Microsystems branded 10gigE adaptors (pci-x) on ebay > nowadays for $500. > > So ... let's say I took some plain-jane, modern-ish PC (intel core, or c2d, > pci-x, etc.) and set up this topology: > > > a <-- cable --> b <-- cable --> c > > and on each of (a) and (c) put one 10gigE adaptor, and on (b) put two > 10gigE adaptors, and set up bridging on (b) > > Would it be reasonable to then expect to transfer data from (a) to (c) at > a, roughly, 10 gigabit/s rate ? > > If not, what is the limiting factor ? > > The idea is that I would use a commodity PC + multiple pci-X slots as a > "poor mans" 10gigE switch ... I can't afford an actual 10gigE switch, but I > don't need that many ports anyway. > > Any comments or field reports would be appreciated. > > > > > > ___ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org" > ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
