Arp table size - any adjustments?
Hi, I have an FreeBSD amd64 9-STABLE system running as a router for various bits and pieces - this has a 'lot' of hosts on it's LAN (literally thousands) - most are NAT end points etc. Looking at the output from 'arp -a -n' it regularly lists 2,000-3,000 entries. Is there anything I need to tune for this kind of quantity (or more), or is it all 'auto-adjusting' on 9.0-S onwards? Thanks, -Karl ___ 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: Arp table size - any adjustments?
On Thu, Dec 13, 2012 at 09:47:12AM +, Karl Pielorz wrote: K> I have an FreeBSD amd64 9-STABLE system running as a router for various K> bits and pieces - this has a 'lot' of hosts on it's LAN (literally K> thousands) - most are NAT end points etc. K> K> Looking at the output from 'arp -a -n' it regularly lists 2,000-3,000 K> entries. Is there anything I need to tune for this kind of quantity (or K> more), or is it all 'auto-adjusting' on 9.0-S onwards? Nope, there is no autotuning here yet. The hash table size is hardcoded in sys/net/if_llatbl.h. The name of constant is LLTBL_HASHTBL_SIZE. -- Totus tuus, Glebius. ___ 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"
ng_ether naming
ng_ether uses if_xname for naming its nodes. This could be troublesome for mapping interface names to their ng_ether companions in the face of interface renaming capability. Especially given that interface renaming and ng_ether _module_ loading may happen in an arbitrary order. I am not sure how to solve this best. One possibility is to use if_dname+if_dunit combination for ng_ether naming. This should be stable and available for querying. This behavior should also be backward compatible with ng_ether being compiled into kernel (if_dname+if_dunit == if_xname before any renaming could occur). Another possibility is to do ng_ether renaming when its interface is renamed. This seems nicer but appears to be more work and more intrusive, because interfaces would have to know about their ng_ether nodes. What do you think? Thank you. And just in case: $ ifconfig -l net0 lo0 $ ngctl list There are 2 total nodes: Name: re0 Type: ether ID: 0001 Num hooks: 0 Name: ngctl11353 Type: socket ID: 0003 Num hooks: 0 -- Andriy Gapon ___ 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: ng_ether naming
On 13.12.2012 15:46, Andriy Gapon wrote: ng_ether uses if_xname for naming its nodes. This could be troublesome for mapping interface names to their ng_ether companions in the face of interface renaming capability. Especially given that interface renaming and ng_ether _module_ loading may happen in an arbitrary order. I am not sure how to solve this best. One possibility is to use if_dname+if_dunit combination for ng_ether naming. This should be stable and available for querying. This behavior should also be backward compatible with ng_ether being compiled into kernel (if_dname+if_dunit == if_xname before any renaming could occur). Another possibility is to do ng_ether renaming when its interface is renamed. This seems nicer but appears to be more work and more intrusive, because interfaces would have to know about their ng_ether nodes. Not exactly. You can register for ifnet_departure_event and ifnet_arrival_event. Interface renaming is done via sending departure event with old name and arrvial event with new one. What do you think? Thank you. And just in case: $ ifconfig -l net0 lo0 $ ngctl list There are 2 total nodes: Name: re0 Type: ether ID: 0001 Num hooks: 0 Name: ngctl11353 Type: socket ID: 0003 Num hooks: 0 -- WBR, Alexander ___ 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"
igb issues
hi, I'm trying out a 4way Dell PowerEdge C5125/AMD server with onboard Intel(R) PRO/1000 Network Connection version - 2.3.1 when running FreeBsd 8.3 (from sometime around Nov 2) all is ok. with latest (at least Fridays') 9.1-PRERELEASE it's getting 'constipated'. It seems that NFS writes slowdown to a halt, and so I'm getting 'not responding' errors. I am using the same kernel on different hosts with out any problems, even with Intel(R) PRO/1000 Network Connection version - 2.3.4 Any ideas? danny ___ 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: ng_ether naming
on 13/12/2012 14:08 Alexander V. Chernikov said the following: > On 13.12.2012 15:46, Andriy Gapon wrote: >> >> ng_ether uses if_xname for naming its nodes. >> This could be troublesome for mapping interface names to their ng_ether >> companions >> in the face of interface renaming capability. Especially given that >> interface >> renaming and ng_ether _module_ loading may happen in an arbitrary order. >> >> I am not sure how to solve this best. >> >> One possibility is to use if_dname+if_dunit combination for ng_ether naming. >> This >> should be stable and available for querying. This behavior should also be >> backward compatible with ng_ether being compiled into kernel >> (if_dname+if_dunit == >> if_xname before any renaming could occur). >> >> Another possibility is to do ng_ether renaming when its interface is renamed. >> This seems nicer but appears to be more work and more intrusive, because >> interfaces would have to know about their ng_ether nodes. > > Not exactly. You can register for ifnet_departure_event and > ifnet_arrival_event. > > Interface renaming is done via sending departure event with old name and > arrvial > event with new one. Good to know. Thank you! So which approach sounds better? Or maybe there is even a better one? >> >> What do you think? >> Thank you. >> >> And just in case: >> $ ifconfig -l >> net0 lo0 >> $ ngctl list >> There are 2 total nodes: >>Name: re0 Type: ether ID: 0001 Num hooks: 0 >>Name: ngctl11353 Type: socket ID: 0003 Num hooks: 0 >> > > -- Andriy Gapon ___ 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: igb issues
Try putting the driver from 9.1 back onto 8.3 and see if you still see a problem. That will indicate if its in the driver or the stack/OS. If you have any question about doing this send me email. Is NFS using UDP or TCP? Regards, Jack On Thu, Dec 13, 2012 at 8:05 AM, Daniel Braniss wrote: > hi, > I'm trying out a 4way Dell PowerEdge C5125/AMD server with onboard > Intel(R) PRO/1000 Network Connection version - 2.3.1 > > when running FreeBsd 8.3 (from sometime around Nov 2) all is ok. > with latest (at least Fridays') 9.1-PRERELEASE it's getting 'constipated'. > > It seems that NFS writes slowdown to a halt, and so I'm getting 'not > responding' errors. > > I am using the same kernel on different hosts with out any problems, > even with Intel(R) PRO/1000 Network Connection version - 2.3.4 > > Any ideas? > > danny > > > ___ > 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"
Re: ng_ether naming
On Thu, Dec 13, 2012 at 5:25 PM, Andriy Gapon wrote: > on 13/12/2012 14:08 Alexander V. Chernikov said the following: > > On 13.12.2012 15:46, Andriy Gapon wrote: > >> > >> ng_ether uses if_xname for naming its nodes. > >> This could be troublesome for mapping interface names to their ng_ether > companions > >> in the face of interface renaming capability. Especially given that > interface > >> renaming and ng_ether _module_ loading may happen in an arbitrary order. > >> > >> I am not sure how to solve this best. > >> > >> One possibility is to use if_dname+if_dunit combination for ng_ether > naming. This > >> should be stable and available for querying. This behavior should also > be > >> backward compatible with ng_ether being compiled into kernel > (if_dname+if_dunit == > >> if_xname before any renaming could occur). > >> > >> Another possibility is to do ng_ether renaming when its interface is > renamed. > >> This seems nicer but appears to be more work and more intrusive, because > >> interfaces would have to know about their ng_ether nodes. > > > > Not exactly. You can register for ifnet_departure_event and > ifnet_arrival_event. > > > > Interface renaming is done via sending departure event with old name and > arrvial > > event with new one. > > Good to know. Thank you! > > > So which approach sounds better? > Or maybe there is even a better one? > > The best is interface event handling. Just recopy the new name from if_xname and should be done. > >> > >> What do you think? > >> Thank you. > >> > >> And just in case: > >> $ ifconfig -l > >> net0 lo0 > >> $ ngctl list > >> There are 2 total nodes: > >>Name: re0 Type: ether ID: 0001 Num > hooks: 0 > >>Name: ngctl11353 Type: socket ID: 0003 Num > hooks: 0 > >> > > > > > > > -- > Andriy Gapon > ___ > 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" > -- Ermal ___ 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: ipv6 route ignores MTU.
Zaphod Beeblebrox wrote this message on Wed, Dec 12, 2012 at 22:50 -0500: > FreeBSD virtual.accountingreality.com 9.1-RC2 FreeBSD 9.1-RC2 #6 r241240: > Sat Oct 6 01:43:35 EDT 2012 > r...@virtual.accountingreality.com:/usr/obj/usr/src/sys/VRA > amd64 > > I have set a high MTU: > > em0: flags=8843 metric 0 mtu 9014 > > options=4019b > ether 00:15:17:0d:04:a8 > inet x.y.z.q netmask 0xffe0 broadcast x.y.z.q1 > inet6 fe80::215:17ff:fe0d:4a8%em0 prefixlen 64 scopeid 0x5 > inet6 2001:1928:1::52 prefixlen 64 > inet 192.168.221.2 netmask 0xff00 broadcast 192.168.221.255 > nd6 options=21 > media: Ethernet autoselect (1000baseT ) > status: active > > curiously, although: > > [1:2:301]root@virtual:~> route -n get 192.168.221.84 >route to: 192.168.221.84 > destination: 192.168.221.0 >mask: 255.255.255.0 > interface: em0 > flags: > recvpipe sendpipe ssthresh rtt,msecmtuweightexpire >0 0 0 0 9014 1 0 > > shows the correct MTU, > > [1:5:304]root@virtual:~> route -n get -inet6 2001:1928:1::84 >route to: 2001:1928:1::84 > destination: 2001:1928:1:: >mask: ::::: > interface: em0 > flags: > recvpipe sendpipe ssthresh rtt,msecmtuweightexpire >0 0 0 0 1500 1 0 > > shows the wrong MTU. > > The MTU in this case is set in the ifconfig_em0 rc.conf entry and the > machine has been rebooted. Are you sure that the mtu is set before the ipv6 address is assigned to the interface? The route inherits what ever MTU was on the interface when the route was created... It will be clamped if it is lower, but will not be increased... This is so you can set the MTU on a route (say you have a broken low memory device that only accept 512 byte packets) and it will stay the way you set it.. -- 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 "freebsd-net-unsubscr...@freebsd.org"
Re: ipv6 route ignores MTU.
On Thu, Dec 13, 2012 at 2:31 PM, John-Mark Gurney wrote: > > The MTU in this case is set in the ifconfig_em0 rc.conf entry and the > > machine has been rebooted. > > Are you sure that the mtu is set before the ipv6 address is assigned > to the interface? The route inherits what ever MTU was on the interface > when the route was created... It will be clamped if it is lower, but > will not be increased... This is so you can set the MTU on a route > (say you have a broken low memory device that only accept 512 byte packets) > and it will stay the way you set it.. Ordinarily, I would expect that since the MTU setting is in the ifconfig_em0 configuration line, this was sufficient. However, I realize now that this is not the case. Putting the MTU into the ipv6_ifconfig line did the trick. This is a rather serious violation of POLA --- I would suggest that some thought should be given to how this is configured and documented. ___ 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"
