Re: fbsd amd64 and fast_ipsec
On Wed, 14 Mar 2007, rms_zaphod wrote: Hi , OK, I have used these ken mods for my file server/nat/router/firewall servers for years. (kern ops then question) options FAST_IPSEC device crypto With 6.2, with latest (3.13.07) cvsup -L 2 -h `(fastest_cvsup -q -c us )` /root/stable-supfile make buildworld etc...I STILL cannot get setkey nor racoon to function. I keep getting a pfkey error, and cannot establish a VPN tunnel. I can if I use: can you be more specific about which "racoon"? Which "setkey" and what errors when doing what? I'll be happy to fix more amd64/(fast)ipsec bugs but I need details so I can try to reproduce them. -- Bjoern A. Zeeb bzeeb at Zabbadoz dot NeT ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Generic ioctl and ether_ioctl don't agree
On Wed, Mar 14, 2007 at 12:50:12PM +, Bruce M. Simpson wrote: > Yar Tikhiy wrote: > >Hi folks, > > > >Quite a while ago I noticed that our ioctl handlers get the ioctl > >command via u_long, but ether_ioctl()'s command argument is int. > >This disarray dates back to 1998, when ioctl functions started to > >take u_long as the command, but ether_ioctl() was never fixed. > >Fortunately, our ioctl command coding still fits in 32 bits, or > >else we would've got problems on 64-bit arch'es already. I'd like > >to fix this long-standing bug some day after RELENG_7 is branched. > >Of course, this will break ABI to network modules on all 64-bit > >arch'es. BTW, the same applies to other L2 layers, such as firewire, > >which seems to have been cloned from if_ethersubr.c. > > > This is one of those annoying things which breaks compatibility with > external modules. > > I'm not sure about this, though. I was getting sign extension warnings > on amd64 last week when I was testing the IGMPv3 aware mtest(8). Perhaps > if we're fixing these ABIs, we should commit to an explicit C99 type > with known bit width, i.e. uint32_t. > > I would be much happier if we began using C99 types in the code. This is a point to discuss in -arch as it's closely related to the generic ioctl interface. Let's move this thread to -arch. It's been a vague issue to me whether to use a fixed-width type or a basic type in particular kernel code. Of course, it's better to use a fixed-width type when it comes to network packets or hardware registers. OTOH, errno is int. But not all cases are that simple. Do we have a guideline for that? -- Yar ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Generic ioctl and ether_ioctl don't agree
On Wed, Mar 14, 2007 at 10:01:38AM -0500, Brooks Davis wrote: > On Wed, Mar 14, 2007 at 01:20:23PM +0300, Yar Tikhiy wrote: > > Hi folks, > > > > Quite a while ago I noticed that our ioctl handlers get the ioctl > > command via u_long, but ether_ioctl()'s command argument is int. > > This disarray dates back to 1998, when ioctl functions started to > > take u_long as the command, but ether_ioctl() was never fixed. > > Fortunately, our ioctl command coding still fits in 32 bits, or > > else we would've got problems on 64-bit arch'es already. I'd like > > to fix this long-standing bug some day after RELENG_7 is branched. > > Of course, this will break ABI to network modules on all 64-bit > > arch'es. BTW, the same applies to other L2 layers, such as firewire, > > which seems to have been cloned from if_ethersubr.c. > > > > Any objections or comments? Thanks! > > Why wait? We're allowed to break module ABIs in current at any time and > there's no chance modules built on RELENG_6 will work on RELENG_7 > trees anyway. Perhaps I was over-conservative. :-) -- Yar ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Scalability problem from route refcounting
Kris Kennaway wrote: I have recently started looking at database performance over gigabit ethernet, and there seems to be a bottleneck coming from the way route reference counting is implemented. On an 8-core system it looks like we spend a lot of time waiting for the rtentry mutex: maxtotal wait_total count avg wait_avg cnt_hold cnt_lock name [...] 408 950496 1135994 301418 3 324876 55936 net/if_ethersubr.c:397 (sleep mutex:bge1) 974 968617 1515169 253772 3 514741 60581 dev/bge/if_bge.c:2949 (sleep mutex:bge1) 2415 18255976 1607511 25384171 6 125174 3131 netinet/tcp_input.c:770 (sleep mutex:inp) 233 1850252 2080506 14181713140 126897 netinet/tcp_usrreq.c:756 (sleep mutex:inp) 384 6895050 2737492 29900223 992100 73942 dev/bge/if_bge.c:3506 (sleep mutex:bge1) 626 5342286 2760193 30147717 947616 54158 net/route.c:147 (sleep mutex:radix node head) 326 3562050 3381510 3014771111 133968 110104 net/route.c:197 (sleep mutex:rtentry) 146 947173 5173813 301477 31744578 120961 net/route.c:1290 (sleep mutex:rtentry) 146 953718 5501119 301476 31863285 121819 netinet/ip_output.c:610 (sleep mutex:rtentry) 50 4530645 7885304 1423098 3 5 642391 788230 kern/subr_turnstile.c:489 (spin mutex:turnstile chain) i.e. during a 30 second sample we spend a total of >14 seconds (on all cpus) waiting to acquire the rtentry mutex. This appears to be because (among other things), we increment and then decrement the route refcount for each packet we send, each of which requires acquiring the rtentry mutex for that route before adjusting the refcount. So multiplexing traffic for lots of connections over a single route is being partly rate-limited by those mutex operations. The rtentry locking actually isn't that much of a problem in itself and rtalloc1() in net/route.c only gets the blame because this function aquires the lock for the routing table entry and returns a locked entry. It is the job of the callers to unlock it as soon as possible again. Here arpresolve() in netinet/if_ether.c is the offending function keeping the lock over an extended period causing the contention and long wait times. ARP is a horrible mess and I don't have a quick fix for this. There is some work in progress for quite some time to replace the current ARP code with something more adequate. That's not finished yet though. This is not the end of the story though, the bge driver is a serious bottleneck on its own (e.g. I nulled out the route locking since it is not relevant in my environment, at least for the purposes of this test, and that exposed bge as the next problem -- but other drivers may not be so bad). -- Andre ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: kern/106722: [net] [patch] ifconfig may not connect an interface to known network
Gleb Smirnoff wrote: I was afraid that this would raise an argument on multipath routing. Let's temporary do not speak about multipath but just decide what is the correct way to remove conflicting routes when we are assigning an IP prefix to a local interface? IMO when configuring a interface with an IP address and network it should kick out previous host and/or network routes matching it. Unless those are from locally configured interfaces, then it should reject the new attempt. The current behavior is a big problem when running routing daemons like OpenBGPD or OpenOSPFD. If you add a second router to a subnet and that router receives that subnet already via the routing protocol you can't configure the interface. For the routing daemon a RTM_CHANGE in the replacement case is fine. -- Andre ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
IPv6 bridge0 link-local address
I've configured a bridge0 interface that bridges fxp0 and em0. I have a global IPv6 address configured on it and IPv6 works fine. # ifconfig bridge0 bridge0: flags=8043 mtu 1500 inet x.x.x.82 netmask 0xfff0 broadcast x.x.x.95 inet6 2001:4877:1777:1001::1 prefixlen 64 ether ac:de:48:49:71:91 priority 32768 hellotime 2 fwddelay 15 maxage 20 member: fxp0 flags=3 member: em0 flags=3 I'm trying to run route6d and it aborts because there is no link local address on the bridge0 interface. I can't even tell route6d to ignore the interface because it won't get past initialization. Is anyone routing route6d over a bridge0 interface and if so, did you add a link local address manually (can you even do that) or some other trick? # route6d -d newif fxp0 found address fe80:1::202:a5ff:fe87:4012/64 index: 1, mtu: 1500, metric: 0 join fxp0 ff02::9 newif em0 found address fe80:2::20e:cff:fe9f:f40a/64 index: 2, mtu: 1500, metric: 0 join em0 ff02::9 newif fxp1 found address fe80:3::2d0:b7ff:fe3c:9dae/64 index: 3, mtu: 1500, metric: 0 join fxp1 ff02::9 found address 2001:4877:1713:1002::1/64 newif fxp2 found address fe80:4::2d0:b7ff:fe3f:42c0/64 index: 4, mtu: 1500, metric: 0 join fxp2 ff02::9 found address 2001:4877:1713:1003::1/64 newif lo0 found address ::1/128 found address fe80:6::1/64 index: 6, mtu: 1500, metric: 0 newif bridge0 found address 2001:4877:1713:1001::1/64 newif gif0 found address fe80:8::202:a5ff:fe87:4012/64 -- :: index: 8, mtu: 1280, metric: 0 join gif0 ff02::9 found address 2001:4877:1700:29::2/128 -- :: newif tun0 found address fe80:9::202:a5ff:fe87:4012/64 -- :: index: 9, mtu: 1500, metric: 0 join tun0 ff02::9 newif gif1 found address 2001:4877:1713:1011::1/64 -- :: found address fe80:b::202:a5ff:fe87:4012/64 -- :: index: 11, mtu: 1280, metric: 0 join gif1 ff02::9 No ifindex found at bridge0 (no link-local address?) Thanks, Tom ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
CARP Question
Hello. I've got two servers configured as follows: a) /etc/rc.conf: ifconfig_xl0="inet 192.168.0.2 netmask 255.255.255.0" ifconfig_fxp0="inet 192.168.101.4 netmask 255.255.255.0" cloned_interfaces="carp0 carp1 carp2 carp3" ifconfig_carp0="vhid 1 advskew 100 pass 192.168.101.10" ifconfig_carp1="vhid 2 pass 192.168.101.10" ifconfig_carp2="vhid 3 advskew 100 pass 192.168.0.4" ifconfig_carp3="vhid 4 pass 192.168.0.4" /etc/sysctl.conf: net.inet.carp.arpbalance=1 net.inet.carp.preempt=1 b) /etc/rc.conf: ifconfig_fxp0="inet 192.168.101.1 netmask 255.255.255.0" ifconfig_fxp1="inet 192.168.0.3 netmask 255.255.255.0" cloned_interfaces="carp0 carp1 carp2 carp3" ifconfig_carp0="vhid 1 pass 192.168.101.10" ifconfig_carp1="vhid 2 advskew 100 pass 192.168.101.10" ifconfig_carp2="vhid 3 pass 192.168.0.4" ifconfig_carp3="vhid 4 advskew 100 pass 192.168.0.4" /etc/sysctl.conf: net.inet.carp.arpbalance=1 net.inet.carp.preempt=1 With this I would expect that, being both servers online, they should have two MASTER and two BACKUP carp interfaces each. Instead, one has all MASTERs and the other all BACKUPs. a) ifconfig carp0: flags=49 mtu 1500 inet 192.168.101.10 netmask 0xff00 carp: BACKUP vhid 1 advbase 1 advskew 100 carp1: flags=49 mtu 1500 inet 192.168.101.10 netmask 0xff00 carp: BACKUP vhid 2 advbase 1 advskew 0 carp2: flags=49 mtu 1500 inet 192.168.0.4 netmask 0xff00 carp: BACKUP vhid 3 advbase 1 advskew 100 carp3: flags=49 mtu 1500 inet 192.168.0.4 netmask 0xff00 carp: BACKUP vhid 4 advbase 1 advskew 0 b) ifconfig carp0: flags=49 mtu 1500 inet 192.168.101.10 netmask 0xff00 carp: MASTER vhid 1 advbase 1 advskew 0 carp1: flags=49 mtu 1500 inet 192.168.101.10 netmask 0xff00 carp: MASTER vhid 2 advbase 1 advskew 100 carp2: flags=49 mtu 1500 inet 192.168.0.4 netmask 0xff00 carp: MASTER vhid 3 advbase 1 advskew 0 carp3: flags=49 mtu 1500 inet 192.168.0.4 netmask 0xff00 carp: MASTER vhid 4 advbase 1 advskew 100 Why? bye & Thanks av. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: IPv6 bridge0 link-local address
On 15/03/07, Tom Pusateri <[EMAIL PROTECTED]> wrote: I've configured a bridge0 interface that bridges fxp0 and em0. I have a global IPv6 address configured on it and IPv6 works fine. # ifconfig bridge0 bridge0: flags=8043 mtu 1500 inet x.x.x.82 netmask 0xfff0 broadcast x.x.x.95 inet6 2001:4877:1777:1001::1 prefixlen 64 ether ac:de:48:49:71:91 priority 32768 hellotime 2 fwddelay 15 maxage 20 member: fxp0 flags=3 member: em0 flags=3 [snip] I don't know precisely what's about if_bridge. According to the rfc2373 (App.A) it should be similar to: fe80::aede:48ff:fe49:7191%bridge0 Hmm.. but if you try the `ifconfig bridge0 inet6 eui64` command, you''ll see: ifconfig: could not determine link local address wbr, pluknet. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: CARP Question
Hi, Andrea Venturoli wrote: Hello. I've got two servers configured as follows: a) /etc/rc.conf: ifconfig_xl0="inet 192.168.0.2 netmask 255.255.255.0" ifconfig_fxp0="inet 192.168.101.4 netmask 255.255.255.0" cloned_interfaces="carp0 carp1 carp2 carp3" ifconfig_carp0="vhid 1 advskew 100 pass 192.168.101.10" ifconfig_carp1="vhid 2 pass 192.168.101.10" ifconfig_carp2="vhid 3 advskew 100 pass 192.168.0.4" ifconfig_carp3="vhid 4 pass 192.168.0.4" /etc/sysctl.conf: net.inet.carp.arpbalance=1 net.inet.carp.preempt=1 b) /etc/rc.conf: ifconfig_fxp0="inet 192.168.101.1 netmask 255.255.255.0" ifconfig_fxp1="inet 192.168.0.3 netmask 255.255.255.0" cloned_interfaces="carp0 carp1 carp2 carp3" ifconfig_carp0="vhid 1 pass 192.168.101.10" ifconfig_carp1="vhid 2 advskew 100 pass 192.168.101.10" ifconfig_carp2="vhid 3 pass 192.168.0.4" ifconfig_carp3="vhid 4 advskew 100 pass 192.168.0.4" /etc/sysctl.conf: net.inet.carp.arpbalance=1 net.inet.carp.preempt=1 With this I would expect that, being both servers online, they should have two MASTER and two BACKUP carp interfaces each. Instead, one has all MASTERs and the other all BACKUPs. a) ifconfig carp0: flags=49 mtu 1500 inet 192.168.101.10 netmask 0xff00 carp: BACKUP vhid 1 advbase 1 advskew 100 carp1: flags=49 mtu 1500 inet 192.168.101.10 netmask 0xff00 carp: BACKUP vhid 2 advbase 1 advskew 0 carp2: flags=49 mtu 1500 inet 192.168.0.4 netmask 0xff00 carp: BACKUP vhid 3 advbase 1 advskew 100 carp3: flags=49 mtu 1500 inet 192.168.0.4 netmask 0xff00 carp: BACKUP vhid 4 advbase 1 advskew 0 b) ifconfig carp0: flags=49 mtu 1500 inet 192.168.101.10 netmask 0xff00 carp: MASTER vhid 1 advbase 1 advskew 0 carp1: flags=49 mtu 1500 inet 192.168.101.10 netmask 0xff00 carp: MASTER vhid 2 advbase 1 advskew 100 carp2: flags=49 mtu 1500 inet 192.168.0.4 netmask 0xff00 carp: MASTER vhid 3 advbase 1 advskew 0 carp3: flags=49 mtu 1500 inet 192.168.0.4 netmask 0xff00 carp: MASTER vhid 4 advbase 1 advskew 100 Why? man carp: net.inet.carp.preempt Allow virtual hosts to preempt each other. It is also used to failover carp interfaces as a group. When the option is enabled and one of the carp enabled physical interfaces goes down, advskew is changed to 240 on all carp inter- faces. See also the first example. Disabled by default. bye & Thanks av. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]" -- Best Wishes, Stefan Lambrev ICQ# 24134177 ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: CARP Question
Stefan Lambrev wrote: man carp: net.inet.carp.preempt Allow virtual hosts to preempt each other. It is also used to failover carp interfaces as a group. When the option is enabled and one of the carp enabled physical interfaces goes down, advskew is changed to 240 on all carp inter- faces. See also the first example. Disabled by default. Yes, I had read that. Since this two boxes are, amidst other things, acting as routers, I do want the interface pair to go into master state all at once. However I had understood that, once the other box comes up again, the two interfaces which had switched should go back to backup state and be masters on the alive-again host. In other words, after one server solved its troubles, I should have the initial status again. How can I accomplish this? BTW, I used to have this working on 4.x using the now discontinued freevrrpd port. I can't believe this is not possible anymore now. bye & Thanks av. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: [PATCH] fbsd amd64 and fast_ipsec
Bjoern A. Zeeb wrote: > > On Wed, 14 Mar 2007, rms_zaphod wrote: > > Hi , > >> OK, I have used these ken mods for my file server/nat/router/firewall >> servers >> for years. (kern ops then question) >> >> options FAST_IPSEC >> device crypto >> >> With 6.2, with latest (3.13.07) cvsup -L 2 -h `(fastest_cvsup -q -c us )` >> /root/stable-supfile >> >> make buildworld etc...I STILL cannot get setkey nor racoon to function. I >> keep getting a pfkey error, and cannot establish a VPN tunnel. I can if I >> use: > > can you be more specific about which "racoon"? > Which "setkey" and what errors when doing what? > > I'll be happy to fix more amd64/(fast)ipsec bugs but I need details so > I can try to reproduce them. > > -- > Bjoern A. Zeebbzeeb at Zabbadoz dot NeT > > OK...I only have a few things...this is what I get as a response: > > testor# setkey -D > pfkey_open: Protocol not supported > testor# racoon > racoon: something error happened while pfkey initializing. > testor# > > That's all I can say. Today, I did do a full cvsup and world build on > 5.4, and I recieved the same error message. Perhaps an update in cv's is > the problem??? > > I'm using racoon from /usr/ports/security/ipsec-tools ---current ports > tree. > > I will do a build using 6.2 without a world rebuild and see what happens. > ___ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "[EMAIL PROTECTED]" > > -- View this message in context: http://www.nabble.com/fbsd-amd64-and-fast_ipsec-tf3405028.html#a9506441 Sent from the freebsd-net mailing list archive at Nabble.com. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
