Re: 1 Gb network NFS issues
Sorry, i've mistyped: en0: flags=8863 mtu 8000 media: autoselect (100baseTX ) status: active It is interface configuration from other location (100Mbps lan) so in my home network the same but media is 1Gb link. On 06.02.2008, at 9:11, Nicholas Kulikov wrote: Hello all, I'm trying setup NFS in 1 Gb home network and found some strange issues: Current NFS performance is about 30-35 Mb/s but few days ago i had 40-45 Mb/s. I've made some changes in server configuration (moved to FreeBSD 6.3 and changed network driver to nfe) and I can't catch what is wrong... Network structure: NFS server (FreeBSD 6.3) | | 1 Gb link | NFS client (Mac OS X 10.5.1) Server configuration - nfe0: flags=8843 mtu 8000 options=48 Client configuration en0: flags=8863 mtu 8000 media: autoselect (100baseTX ) status: active client mount share by using the following parameters: tcp vers=3 rsize=40960 wsize=40960 readahead=16 rdirplus nolocks intr noatime I've tried copy big file (about 3 Gb) and tcdump-ed client and server packets: 07:11:08.350744 IP (tos 0x0, ttl 64, id 51461, offset 0, flags [DF], proto TCP (6), length 176) 192.168.254.249.nfs > 192.168.254.254.2468561782: reply ok 124 access attr: REG 660 ids 1001/1006 sz 3958224896 nlink 1 rdev 133/134414584 fsid 5e fileid 2013005 a/m/ctime 1199479211.00 1199479280.00 1201346449.00 c 001f 07:11:08.350793 IP (tos 0x0, ttl 64, id 46719, offset 0, flags [DF], proto TCP (6), length 52) 192.168.254.254.49158 > 192.168.254.249.nfsd: ., cksum 0x7f70 (incorrect (-> 0xd9e5), 22844:22844(0) ack 27581 win 65535 30749984> 07:11:08.350988 IP (tos 0x0, ttl 64, id 9526, offset 0, flags [DF], proto TCP (6), length 168) 192.168.254.254.2468561783 > 192.168.254.249.nfs: 116 read fh 1143,951878/33632261 32768 bytes @ 0 07:11:08.351069 IP (tos 0x0, ttl 64, id 8470, offset 0, flags [DF], proto TCP (6), length 168) 192.168.254.254.2468561784 > 192.168.254.249.nfs: 116 read fh 1143,951878/33632261 32768 bytes @ 32768 07:11:08.351145 IP (tos 0x0, ttl 64, id 65343, offset 0, flags [DF], proto TCP (6), length 168) 192.168.254.254.2468561785 > 192.168.254.249.nfs: 116 read fh 1143,951878/33632261 32768 bytes @ 65536 07:11:08.351242 IP (tos 0x0, ttl 64, id 11022, offset 0, flags [DF], proto TCP (6), length 168) 192.168.254.254.2468561786 > 192.168.254.249.nfs: 116 read fh 1143,951878/33632261 32768 bytes @ 98304 07:11:08.351314 IP (tos 0x0, ttl 64, id 59209, offset 0, flags [DF], proto TCP (6), length 168) 192.168.254.254.2468561787 > 192.168.254.249.nfs: 116 read fh 1143,951878/33632261 32768 bytes @ 131072 07:11:08.351383 IP (tos 0x0, ttl 64, id 39733, offset 0, flags [DF], proto TCP (6), length 168) 192.168.254.254.2468561788 > 192.168.254.249.nfs: 116 read fh 1143,951878/33632261 32768 bytes @ 163840 07:11:08.351450 IP (tos 0x0, ttl 64, id 33325, offset 0, flags [DF], proto TCP (6), length 168) 192.168.254.254.2468561789 > 192.168.254.249.nfs: 116 read fh 1143,951878/33632261 32768 bytes @ 196608 07:11:08.351516 IP (tos 0x0, ttl 64, id 50481, offset 0, flags [DF], proto TCP (6), length 168) 192.168.254.254.2468561790 > 192.168.254.249.nfs: 116 read fh 1143,951878/33632261 32768 bytes @ 229376 07:11:08.351582 IP (tos 0x0, ttl 64, id 50464, offset 0, flags [DF], proto TCP (6), length 168) 192.168.254.254.2468561791 > 192.168.254.249.nfs: 116 read fh 1143,951878/33632261 32768 bytes @ 262144 07:11:08.351658 IP (tos 0x0, ttl 64, id 37215, offset 0, flags [DF], proto TCP (6), length 168) 192.168.254.254.2468561792 > 192.168.254.249.nfs: 116 read fh 1143,951878/33632261 32768 bytes @ 294912 07:11:08.351739 IP (tos 0x0, ttl 64, id 6496, offset 0, flags [DF], proto TCP (6), length 168) 192.168.254.254.2468561793 > 192.168.254.249.nfs: 116 read fh 1143,951878/33632261 32768 bytes @ 327680 07:11:08.351750 IP (tos 0x0, ttl 64, id 49495, offset 0, flags [DF], proto TCP (6), length 52) 192.168.254.249.nfsd > 192.168.254.254.49158: ., cksum 0x15e5 (correct), 27581:27581(0) ack 23076 win 49943 07:11:08.351754 IP (tos 0x0, ttl 64, id 36632, offset 0, flags [DF], proto TCP (6), length 52) 192.168.254.249.nfsd > 192.168.254.254.49158: ., cksum 0x1501 (correct), 27581:27581(0) ack 23308 win 49939 07:11:08.351758 IP (tos 0x0, ttl 64, id 21313, offset 0, flags [DF], proto TCP (6), length 52) 192.168.254.249.nfsd > 192.168.254.254.49158: ., cksum 0x141c (correct), 27581:27581(0) ack 23540 win 49936 07:11:08.351783 IP (tos 0x0, ttl 64, id 50759, offset 0, flags [DF], proto TCP (6), length 52) 192.168.254.249.nfsd > 192.168.254.254.49158: ., cksum 0x1338 (correct), 27581:27581(0) ack 23772 win 49932 07:11:08.351801 IP (tos 0x0, ttl 64, id 56942, offset 0, flags [DF], proto TCP (6), length 52) 192.168.254.249.nfsd > 192.168.254.254.49158: ., cksum 0x1254 (correct), 27581
ospf cost and route selection (openospfd)
Hello,
I am trying to use openospfd 4.0 over FreeBSD 6.2 in order
to provide redundancy for routing between LAN 1 and LAN 2.
The picture is as follows:
Locality 1 (LAN 1) Locality 2 (LAN 2)
WAN X
Router 1 WAN YRouter 2
Router 1 is connected to LAN 1 on one side
and to two WANs, X and Y, on the other side.
The same holds for Router 2, it is connected
to LAN 2, WAN X and WAN Y.
There are gre tunnels between the routers
over both WAN X and WAN Y. These tunnels get
encrypted with IPsec transport.
I have configured openospfd over both gre interfaces.
The preferred link that I would like to be used for routing
of LANs is the gre tunnel between 1 and 2 over WAN X.
The cost of that link is the least of both costs.
But, openospfd converges with routing between 1 and 2
over WAN Y, not WAN X. I have no clue why.
LAN 1 is 192.168.1.0/24, LAN 2 is 192.168.2.0/24.
gre30 is the link over WAN X, gre31 over WAN Y. 10.10.0.0/16 is WAN X,
10.20.0.0/16 is WAN Y.
Configuration of gre tunnels:
Router 1:
gre30: flags=b051 mtu 1476
tunnel inet 10.10.1.2 --> 10.10.2.2
inet 10.30.1.2 --> 10.30.2.2 netmask 0xff00
gre31: flags=b051 mtu 1476
tunnel inet 10.20.1.2 --> 10.20.2.2
inet 10.31.1.2 --> 10.31.2.2 netmask 0xff00
Router 2:
gre30: flags=b051 mtu 1476
tunnel inet 10.10.2.2 --> 10.10.1.2
inet 10.30.2.2 --> 10.30.1.2 netmask 0xff00
gre31: flags=b051 mtu 1476
tunnel inet 10.20.2.2 --> 10.20.1.2
inet 10.31.2.2 --> 10.31.1.2 netmask 0xff00
Configuration of openospfd:
Router 1:
router-id 0.0.0.1
redistribute connected
area 0.0.0.0 {
interface gre30 {
metric 20
}
interface gre31 {
metric 50
}
}
Router 2:
router-id 0.0.0.2
redistribute connected
area 0.0.0.0 {
interface gre30 {
metric 20
}
interface gre31 {
metric 50
}
}
ospfctl show rib:
Router 1:
Destination Nexthop Path TypeType CostUptime
0.0.0.2 10.31.2.2 Intra-Area Router20 00:03:51
10.30.1.2/32 10.31.2.2 Intra-Area Network 40 00:03:41
10.31.1.2/32 10.31.2.2 Intra-Area Network 70 00:03:51
10.10.0.0/16 10.31.2.2 Type 1 ext Network 120 00:03:51
10.20.0.0/16 10.31.2.2 Type 1 ext Network 120 00:03:51
192.168.2.0/24 10.31.2.2 Type 1 ext Network 120 00:03:51
Router 2:
Destination Nexthop Path TypeType CostUptime
0.0.0.1 10.31.1.2 Intra-Area Router20 00:04:51
10.30.2.2/32 10.31.1.2 Intra-Area Network 40 00:04:44
10.31.2.2/32 10.31.1.2 Intra-Area Network 70 00:04:51
10.10.0.0/16 10.31.1.2 Type 1 ext Network 120 00:04:51
10.20.0.0/16 10.31.1.2 Type 1 ext Network 120 00:04:51
192.168.1.0/24 10.31.1.2 Type 1 ext Network 120 00:04:51
ospfctl show interface detail:
Router 1:
Interface gre31, line protocol is UP
Internet address 10.31.1.2/24, Area 0.0.0.0
Linkstate unknown
Router ID 0.0.0.1, network type POINTOPOINT, cost: 50
Transmit delay is 1 sec(s), state P2P, priority 1
Designated Router (ID) 0.0.0.0, interface address 0.0.0.0
Backup Designated Router (ID) 0.0.0.0, interface address 0.0.0.0
Timer intervals configured, hello 10, dead 40, wait 40, retransmit 5
Hello timer due in 00:00:06
Uptime 00:06:04
Neighbor count is 1, adjacent neighbor count is 1
Interface gre30, line protocol is UP
Internet address 10.30.1.2/24, Area 0.0.0.0
Linkstate unknown
Router ID 0.0.0.1, network type POINTOPOINT, cost: 20
Transmit delay is 1 sec(s), state P2P, priority 1
Designated Router (ID) 0.0.0.0, interface address 0.0.0.0
Backup Designated Router (ID) 0.0.0.0, interface address 0.0.0.0
Timer intervals configured, hello 10, dead 40, wait 40, retransmit 5
Hello timer due in 00:00:06
Uptime 00:06:04
Neighbor count is 1, adjacent neighbor count is 1
Router 2:
Interface gre31, line protocol is UP
Internet address 10.31.2.2/24, Area 0.0.0.0
Linkstate unknown
Router ID 0.0.0.2, network type POINTOPOINT, cost: 50
Transmit delay is 1 sec(s), state P2P, priority 1
Designated Router (ID) 0.0.0.0, interface address 0.0.0.0
Backup Designated Router (ID) 0.0.0.0, interface address 0.0.0.0
Timer intervals configured, hello 10, dead 40, wait 40, retransmit 5
Hello timer due in 00:00:09
Uptime 00:06:02
Neighbor count is 1, adjacent neighbor count is 1
Interface gre30, line protocol is UP
Internet address 10.30.2.2/24, Area 0.0.0.0
Linkstate unknown
Router ID 0.0.0.2, network type POINTOPOINT, cost: 20
Transmit delay is 1 sec(s), state P2P, priority 1
Designated Router (ID) 0.0.0.0, inter
Re: ospf cost and route selection (openospfd)
Josef, good day. Currently I can not answer your question, sorry. I just have the remark. Wed, Feb 06, 2008 at 03:41:04PM +0100, Josef Pojsl wrote: > ospfctl show rib: > Router 1: > Destination Nexthop Path TypeType CostUptime > 0.0.0.2 10.31.2.2 Intra-Area Router20 00:03:51 > 10.30.1.2/32 10.31.2.2 Intra-Area Network 40 00:03:41 > 10.31.1.2/32 10.31.2.2 Intra-Area Network 70 00:03:51 'Cost' column looks perfectly correct: in order to reach the other router, the path with cost 20 is selected (presumably, WAN X); path to 10.30.1.2/32 costs 20+20: 20 from WAN X interface and 20 from the gre30 on the other end; and path to 10.31 costs 70=20+50, WAN X + gre31 on the other end. The only weird thing is the nexthop value. Your 'netstat -rn' shows routes via gre31 too? If yes, maybe the verbose mode of the openospfd (-v) will show something interesting? -- Eygene ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
crpc-0.7.4
Hi all, The CRPC (C-based remote procedure call) version 0.7.4 is now available. To download the package use the link on the project site - http://crpc.sourceforge.net/ Write me back, if you have any questions. Andrey. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: named.root
Petri Helenius wrote: Any chance the recent root zone changes would make it to 7.0? I will certainly prepare the change request and submit it to [EMAIL PROTECTED] However please understand that this is a very low priority issue. The first thing a resolving name server does when starting up is to use the addresses in the root hints file to query a root server to update its local cache of the root zone. It only needs to find ONE good address in that file to accomplish this. Doug -- This .signature sanitized for your protection ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: modifying permissions in /dev
Hi Bruce, Thanks for this. /etc/rc.d/devfs start results in eval: 1: syntax error: unterminated quoted string My devfs.rules looks like this [hostname_ruleset=10] add path 'da*s* mode 0666 group wheel should I add the fd0/cd0? On Feb 4, 2008 6:11 PM, Bruce M. Simpson <[EMAIL PROTECTED]> wrote: > lysergius2001 wrote: > > Hi > > > > Recently installed AMD64 6.3-stable and I am having a problem with > > devfs.conf and /dev. I understand the entries in devfs.conf should > modify > > the permissions on devices in /dev. For some reason or other this is > not > > happening. Can anyone shed some light on this? What am I doing wrong? > > > > Try using devfs.rules -- devfs.conf entries will not be applied after > boot, unless you force them to be reapplied by running /etc/rc.d/devfs > start from a superuser shell. > > BMS > -- Lysergius says "Stay light and trust gravity" ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: named.root
> Date: Wed, 06 Feb 2008 11:26:29 -0800 > From: Doug Barton <[EMAIL PROTECTED]> > Sender: [EMAIL PROTECTED] > > Petri Helenius wrote: > > > > Any chance the recent root zone changes would make it to 7.0? > > I will certainly prepare the change request and submit it to [EMAIL > PROTECTED] > However please understand that this is a very low priority issue. The > first thing a resolving name server does when starting up is to use > the addresses in the root hints file to query a root server to update > its local cache of the root zone. It only needs to find ONE good > address in that file to accomplish this. > > Doug > > -- > > This .signature sanitized for your protection > ___ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "[EMAIL PROTECTED]" > Doug, This is both true and false because an IPv6 only DNS server (this may be an imaginary entity) will not find any root servers without the new file. I think it is probably not high priority, but is of MUCH higher then the typical root list since it can have a real impact. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: [EMAIL PROTECTED] Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 pgpoMD2xbGtMz.pgp Description: PGP signature
Re: named.root
Kevin Oberman wrote: Doug, This is both true and false because an IPv6 only DNS server (this may be an imaginary entity) It is. Modulo some theoretical exercise being performed by people who are smart enough to know how to prime them already, there are no IPv6-only name servers. Even though the root is ready now, only 112 of the 281 TLDs have IPv6 glue of any sort. The IPv6-only Internet is a long way away. Now everything I just said will become less true going forward, which is why I said I will do the change request ASAP. But it's still not urgent, and any impact that not doing the change tomorrow might have is so minimal as to be basically immeasurable. Doug -- This .signature sanitized for your protection ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: named.root
> Date: Wed, 06 Feb 2008 14:41:14 -0800 > From: Doug Barton <[EMAIL PROTECTED]> > > Kevin Oberman wrote: > > > Doug, > > > > This is both true and false because an IPv6 only DNS server (this may be > > an imaginary entity) > > It is. Modulo some theoretical exercise being performed by people who > are smart enough to know how to prime them already, there are no > IPv6-only name servers. Even though the root is ready now, only 112 of > the 281 TLDs have IPv6 glue of any sort. The IPv6-only Internet is a > long way away. > > Now everything I just said will become less true going forward, which > is why I said I will do the change request ASAP. But it's still not > urgent, and any impact that not doing the change tomorrow might have > is so minimal as to be basically immeasurable. Doug, I agree. That's why I said that it is not high-priority, but I wanted to make people aware that this was not just the usual case when a root server moves to a new address. I do suspect that there may be real IPv6 only DNS servers out there, but, if they exist, they are probably in China and will never point at the real root servers. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: [EMAIL PROTECTED] Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 pgpRu99p6JJ1f.pgp Description: PGP signature
Re: modifying permissions in /dev
lysergius2001 wrote this message on Wed, Feb 06, 2008 at 20:48 +: > Thanks for this. > > /etc/rc.d/devfs start results in > eval: 1: syntax error: unterminated quoted string > > My devfs.rules looks like this > > [hostname_ruleset=10] > > add path 'da*s* mode 0666 group wheel ^ seem to be missing a quote where... > should I add the fd0/cd0? > > > On Feb 4, 2008 6:11 PM, Bruce M. Simpson <[EMAIL PROTECTED]> wrote: > > > lysergius2001 wrote: > > > Hi > > > > > > Recently installed AMD64 6.3-stable and I am having a problem with > > > devfs.conf and /dev. I understand the entries in devfs.conf should > > modify > > > the permissions on devices in /dev. For some reason or other this is > > not > > > happening. Can anyone shed some light on this? What am I doing wrong? > > > > Try using devfs.rules -- devfs.conf entries will not be applied after > > boot, unless you force them to be reapplied by running /etc/rc.d/devfs > > start from a superuser shell. -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: crpc-0.7.4
On 07/02/2008, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > Hi all, > > The CRPC (C-based remote procedure call) version 0.7.4 is now available. > To download the package use the link on the project site - > http://crpc.sourceforge.net/ > > Write me back, if you have any questions. How's this different from Sun's RPC stuff? Adrian -- Adrian Chadd - [EMAIL PROTECTED] ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: crpc-0.7.4
* Adrian Chadd <[EMAIL PROTECTED]> [Thu, 7 Feb 2008 14:21:01 +0900]:
On 07/02/2008, [EMAIL PROTECTED] <[EMAIL PROTECTED]>
wrote:
> Hi all,
>
> The CRPC (C-based remote procedure call) version 0.7.4 is now
available.
> To download the package use the link on the project site -
> http://crpc.sourceforge.net/
>
> Write me back, if you have any questions.
How's this different from Sun's RPC stuff?
Adrian
--
Adrian Chadd - [EMAIL PROTECTED]
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
I worked generally on the programer's interface. For example, in SunRPC
we have such definition and
client code:
const MAXSORTSIZE = 64;
const MAXSTRINGLEN = 64;
typedef string str; /* the string itself */
struct sortstrings {
str ss;
};
program SORTPROG {
version SORTVERS {
sortstrings SORT(sortstrings) = 1;
} = 1;
} = 22855;
#include
#include
#include "sort.h"
int
main(int argc, char **argv) {
char *machinename;
struct sortstrings args, res;
int i;
machinename = argv[1];
args.ss.ss_len = argc - 2; /* substract off progname,
machinename */
args.ss.ss_val = &argv[2];
res.ss.ss_val = (char **)NULL;
if ((i = callrpc(machinename, SORTPROG, SORTVERS, SORT,
xdr_sortstrings, &args, xdr_sortstrings, &res)))
{
fprintf(stderr, "%s: call to sort service failed. ",
argv[0]);
clnt_perrno(i);
fprintf(stderr, "\n");
exit(1);
}
exit(0);
}
But using CRPC we can have rather simular client code like this:
#include
__remote int
sort(char **ssp, int size) __attribute__((__format_ptr(0[1])));
int
main(int argc, char **argv) {
int res;
res = sort(argv+1,argc-1);
exit(0);
}
In CRPC, all the stub information is extracted from the prototype
declaration, function call is the same, as
in ordinary program. Also the system could work with any data type,
defined in the C code.
And this file is to compiled with the rcc only, cause it is a gcc
wrapper.
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
