Re: use of non-contiguous masks in address lookups ?
> every now and then the issue comes up on whether we still need > to support non-contiguous masks in address lookups. > I seem to remember someone (perhaps on this list) making a > case for their presence, but forgot the details. > So, does anyone know of a practical use of non contiguous masks ? I vote for removing non-contiguous masks. They are incompatible with CIDR, which was introduced in 1993 (!). Non-contiguous masks have been unsupported in many routers produced the last 10 years or so. E.g. for Juniper M/MX/T routers you specify an interface address with a contiguous mask (1.2.3.4/29 etc). It is *not possible* to specify a non-contiguous mask. Address lookup is always based on longest prefix match. Steinar Haug, Nethelp consulting, sth...@nethelp.no ___ 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"
Bug? adding a vlan on ix is not elegant
If I have my ix0 up and add another vlan... eg ifconfig vlan777 vlandev ix0 vlan777 10.77.7.1/24 the act of creating a vlan causes all the other vlans to go offline for 15 seconds. Rudy ___ 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: Bug? adding a vlan on ix is not elegant
On May 24, 2012, at 11:45 AM, Rudy (bulk) wrote: > > If I have my ix0 up and add another vlan... eg > ifconfig vlan777 vlandev ix0 vlan777 10.77.7.1/24 > the act of creating a vlan causes all the other vlans to go offline for 15 > seconds. > > Rudy What version of FreeBSD are you running? The little interruption might be due to the vlan hwfilter reprogramming on the adapter, but 15 secs sound too much. ___ 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: LRO support for IPv6
On 23. May 2012, at 08:22 , Venkat Duvvuru wrote: > Folks, > Can somebody please explain me why "tcp checsum" calculation is mandated in > the freebsd network stack (tcp_input--->in6_cksum) albeit the card supports > it? > > Probably Steve is the right person who can answer this. Just for public reference; we talked offline. The code simply was never done and let's see how much of it I can get into the tree the next 48 hours. /bz -- Bjoern A. Zeeb You have to have visions! It does not matter how good you are. It matters what good you do! ___ 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: use of non-contiguous masks in address lookups ?
On 24. May 2012, at 07:43 , sth...@nethelp.no wrote: >> every now and then the issue comes up on whether we still need >> to support non-contiguous masks in address lookups. >> I seem to remember someone (perhaps on this list) making a >> case for their presence, but forgot the details. >> So, does anyone know of a practical use of non contiguous masks ? > > I vote for removing non-contiguous masks. They are incompatible with > CIDR, which was introduced in 1993 (!). > > Non-contiguous masks have been unsupported in many routers produced > the last 10 years or so. Contrary I still know people using them and relying on it. Not sure on which version they are. I am not quite sure what micro-optimizations on legacy IP will help us after a decade or longer. Let it rest and die gracefully the next years. Of course, fixing bugs still considered good:) /bz -- Bjoern A. Zeeb You have to have visions! It does not matter how good you are. It matters what good you do! ___ 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: use of non-contiguous masks in address lookups ?
On Thu, May 24, 2012 at 11:19:54AM +, Bjoern A. Zeeb wrote: > > On 24. May 2012, at 07:43 , sth...@nethelp.no wrote: > > >> every now and then the issue comes up on whether we still need > >> to support non-contiguous masks in address lookups. > >> I seem to remember someone (perhaps on this list) making a > >> case for their presence, but forgot the details. > >> So, does anyone know of a practical use of non contiguous masks ? > > > > I vote for removing non-contiguous masks. They are incompatible with > > CIDR, which was introduced in 1993 (!). > > > > Non-contiguous masks have been unsupported in many routers produced > > the last 10 years or so. > > Contrary I still know people using them and relying on it. Not sure on > which version they are. > > I am not quite sure what micro-optimizations on legacy IP will help > us after a decade or longer. Let it rest and die gracefully the next > years. Of course, fixing bugs still considered good:) the point of my question was to get [f]actual usage information on non contiguous masks, because i don't know of any (at least on ipv4, maybe in ipv6 there is one). The answer does not have to affect FreeBSD, if that is what worries you. cheers luigi ___ 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"
[PATCH] IPv6 rtadvd: little optimization
Hi,
Since upgrading to FreeBSD 8.3, I noticed that after rtadvd starts, it
does not respond to router solicitations during a quite long time.
I have made a patch which speeds up rtadvd's start by making fewer calls
to if_indextoname. Moreover, it will react properly in case
if_indextoname fails.
Would anyone object to this patch ?
===
Index: if.c
===
--- if.c(revision 235474)
+++ if.c(working copy)
@@ -472,11 +472,18 @@ update_ifinfo(struct ifilist_head_t *ifi_head, int
ifindex != ifm->ifm_index)
continue;
+ /* ifname */
+ if (if_indextoname(ifm->ifm_index, ifname) ==
NULL) {
+ syslog(LOG_WARNING,
+ "<%s> ifname not found (idx=%d)",
+ __func__, ifm->ifm_index);
+ continue;
+ }
+
/* lookup an entry with the same ifindex */
TAILQ_FOREACH(ifi, ifi_head, ifi_next) {
if (ifm->ifm_index == ifi->ifi_ifindex)
break;
- if_indextoname(ifm->ifm_index, ifname);
if (strncmp(ifname, ifi->ifi_ifname,
sizeof(ifname)) == 0)
break;
@@ -495,15 +502,7 @@ update_ifinfo(struct ifilist_head_t *ifi_head, int
ifi->ifi_ifindex = ifm->ifm_index;
/* ifname */
- if_indextoname(ifm->ifm_index, ifi->ifi_ifname);
- if (ifi->ifi_ifname == NULL) {
- syslog(LOG_WARNING,
- "<%s> ifname not found (idx=%d)",
- __func__, ifm->ifm_index);
- if (ifi_new)
- free(ifi);
- continue;
- }
+ strncpy(ifi->ifi_ifname, ifname, IFNAMSIZ);
if ((s = socket(AF_INET6, SOCK_DGRAM, 0)) < 0) {
syslog(LOG_ERR,
===
___
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: use of non-contiguous masks in address lookups ?
On Thu, May 24, 2012 at 02:07:11PM +0200, Luigi Rizzo wrote: > On Thu, May 24, 2012 at 11:19:54AM +, Bjoern A. Zeeb wrote: > > > > On 24. May 2012, at 07:43 , sth...@nethelp.no wrote: > > > > >> every now and then the issue comes up on whether we still need > > >> to support non-contiguous masks in address lookups. > > >> I seem to remember someone (perhaps on this list) making a > > >> case for their presence, but forgot the details. > > >> So, does anyone know of a practical use of non contiguous masks ? > > > > > > I vote for removing non-contiguous masks. They are incompatible with > > > CIDR, which was introduced in 1993 (!). > > > > > > Non-contiguous masks have been unsupported in many routers produced > > > the last 10 years or so. > > > > Contrary I still know people using them and relying on it. Not sure on > > which version they are. > > > > I am not quite sure what micro-optimizations on legacy IP will help > > us after a decade or longer. Let it rest and die gracefully the next > > years. Of course, fixing bugs still considered good:) > > the point of my question was to get [f]actual usage information on non > contiguous masks, because i don't know of any (at least on ipv4, > maybe in ipv6 there is one). The answer does not have to affect > FreeBSD, if that is what worries you. Load balansing: #netstat -rnfinet | sed -Ee 's|([ .])[1-9][0-9][.]|\1XX.|' -e 's|([ .])[1-9][0-9][0-9][.]|\1XXX.|' | head -8 Routing tables Internet: DestinationGatewayFlagsRefs Use Netif Expire 0.0.0.0&0x101 XX.XXX.222.58 UGS 0 1241 vlan9 0.0.0.1&0x101 XXX.XX.246.254 UGS 0 1387 vlan1 0.0.1.0&0x101 XXX.XX.246.254 UGS 0 1568 vlan1 0.0.1.1&0x101 XX.XXX.222.58 UGS 0 1491 vlan9 ___ 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: Any deployment with very many small (/28 .. /32) subnets ?
On Thu, May 24, 2012 at 09:16:05AM +0200, Luigi Rizzo wrote: > Also related to my previous question on lookups, I believe some > ISPs may have a huge number of very small subnets (say /28 or > even smaller) attached to some kind of virtual interfaces > (vlans, gif, tun,...). > > Can anyone comment on what the numbers are (i.e. 100-1k-10k subnets ?) > and whether the subnets are taken from a single larger pool which > only includes such subnets, or they are randomly scattered across > a large number of /24 subnets ? When I ruled provider with /18 public pool and some private pools, there was about 100+ routes per router from 1..5 blocks /25 .. /22 per router, I try to minimize number of blocks per router (till 2008). Now wery little provider looks (last digit of vlan100..vlan202 not displayed): >netstat -rnfinet | sed -Ee 's|^| |' -e 's| [1-9][0-9][.]| XX.|g' -e 's| >[1-9][0-9][0-9][.]| XXX.|g' -e 's|X[.][1-9][0-9][0-9][.]|X.XXX.|g' -e >'s|X[.][1-9][0-9][.]|X.XX.|g' Routing tables Internet: DestinationGatewayFlagsRefs Use Netif Expire defaultXXX.XXX.212.33 UGS284116 2747511260 vlan0 0.0.0.1link#11UH 00 disc0 XX.XXX.0.0/24 link#22U 7 160800724 vlan10 XX.XXX.0.254 link#22UHS 00lo0 XX.XXX.2.0/28 link#25U 0 169319158 vlan10 XX.XXX.2.14link#25UHS 00lo0 XX.XXX.2.16/29 link#46U 00 vlan12 XX.XXX.2.22link#46UHS 00lo0 XX.XXX.2.24/29 link#47U 0 122053043 vlan12 XX.XXX.2.30link#47UHS 00lo0 XX.XXX.2.32/29 link#45U 14 65791304 vlan12 XX.XXX.2.38link#45UHS 03lo0 XX.XXX.2.40/29 link#44U 00 vlan12 XX.XXX.2.46link#44UHS 00lo0 XX.XXX.2.48/29 link#43U 00 vlan12 XX.XXX.2.54link#43UHS 00lo0 XX.XXX.2.56/29 link#42U 00 vlan12 XX.XXX.2.62link#42UHS 00lo0 XX.XXX.2.64/29 link#40U 34 39851507 vlan11 XX.XXX.2.70link#40UHS 00lo0 XX.XXX.2.76/30 link#48U 00 vlan20 XX.XXX.2.78link#48UHS 00lo0 XX.XXX.2.80/29 link#39U 00 vlan11 XX.XXX.2.86link#39UHS 00lo0 XX.XXX.2.88/29 link#38U 0 267457525 vlan11 XX.XXX.2.94link#38UHS 00lo0 XX.XXX.2.96/29 link#36U 00 vlan11 XX.XXX.2.102 link#36UHS 00lo0 XX.XXX.2.104/29link#23U 0 48128977 vlan10 XX.XXX.2.110 link#23UHS 00lo0 XX.XXX.2.112/29link#34U 3 110435637 vlan11 XX.XXX.2.118 link#34UHS 00lo0 XX.XXX.2.120/29link#33U 00 vlan11 XX.XXX.2.126 link#33UHS 05lo0 XX.XXX.2.176/29link#32U 00 vlan11 XX.XXX.2.182 link#32UHS 00lo0 XX.XXX.2.184/29link#31U 00 vlan11 XX.XXX.2.190 link#31UHS 00lo0 XX.XXX.2.192/29link#30U 00 vlan10 XX.XXX.2.198 link#30UHS 00lo0 XX.XXX.2.200/29link#29U 00 vlan10 XX.XXX.2.206 link#29UHS 00lo0 XX.XXX.2.216/29link#28U 00 vlan10 XX.XXX.2.222 link#28UHS 00lo0 XX.XXX.2.224/29link#27U 1 51358289 vlan10 XX.XXX.2.230 link#27UHS 00lo0 XX.XXX.2.232/29link#26U 0 128803235 vlan10 XX.XXX.2.238 link#26UHS 00lo0 XX.XXX.2.248/29link#24U 066067 vlan10 XX.XXX.2.254 link#24UHS 06lo0 XX.XXX.3.128/26link#37U 00 vlan11 XX.XXX.3.190 link#37UHS 00lo0 XX.XXX.3.192/26link#35U 0 79757547 vlan11 XX.XXX.3.254 link#35UHS 00lo0 XX.XXX.255.188/30 link#20U 00 vlan8 XX.XXX.255.190 link#20UHS 00lo0 XX.XXX.255.192/27 link#18
Re: kern/168294: [ixgbe] [patch] ixgbe driver compiled in kernel has no Flow Director support although loaded as a module has one
Old Synopsis: ixgbe driver compiled in kernel has no Flow Director support although loaded as a module has one New Synopsis: [ixgbe] [patch] ixgbe driver compiled in kernel has no Flow Director support although loaded as a module has one Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Thu May 24 20:50:32 UTC 2012 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=168294 ___ 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/164400: [ipsec] immediate crash after the start of ipsec processing
The following reply was made to PR kern/164400; it has been noted by GNATS. From: "Bjoern A. Zeeb" To: bug-follo...@freebsd.org, eug...@zhegan.in, "Andrew A. Khlebutin" Cc: Subject: Re: kern/164400: [ipsec] immediate crash after the start of ipsec processing Date: Thu, 24 May 2012 21:50:38 + (UTC) Hi, Cc:ing other reports in the PR so given ESP is doing all AH gives you, can you confirm that not chaining ESP and AH but just ESP fixes the problem? Also note that AH is questioned to become obsolete for ESP null encryption. Not sure we are there yet. I see the problem and I'll try to fix it anyway as a differnt chain might as well trigger it. /bz -- Bjoern A. Zeeb You have to have visions! Stop bit received. Insert coin for new address family. ___ 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"
Major performance hit with ToS setting
When we set the ToS bits for less than best effort (also called scavenger) on packets (ToS=32), performance on FreeBSD 8.2 is terrible. It was as good as best effort on FreeBSD 7.3 (assuming no congestion). I will look into what 9 does, but does anyone have an idea of why 8.2 behaves so badly when ToS is set to 32? Here is an example of what happens to performance: nuttcp with ToS=0: 622.5000 MB / 1.00 sec = 5221.7570 Mbps 623.3125 MB / 1.00 sec = 5228.5883 Mbps 624. MB / 1.00 sec = 5234.4495 Mbps With ToS=32 (0x20): 0.3750 MB / 1.00 sec =3.1457 Mbps 0.5000 MB / 1.00 sec =4.1942 Mbps 0.5000 MB / 1.00 sec =4.1942 Mbps This is,of course, on a 10G interface. On 7.3 there is little difference between the two. We are using cubic CC on the 8.2 system. -- R. Kevin Oberman, Network Engineer E-mail: kob6...@gmail.com ___ 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/164400: [ipsec] immediate crash after the start of ipsec processing
Synopsis: [ipsec] immediate crash after the start of ipsec processing Responsible-Changed-From-To: freebsd-net->bz Responsible-Changed-By: bz Responsible-Changed-When: Thu May 24 23:40:20 UTC 2012 Responsible-Changed-Why: Whoops, it wasn't assigned to me yet. I broke it, I'll fix it though it has taken me a while to get to this. http://www.freebsd.org/cgi/query-pr.cgi?pr=164400 ___ 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: Major performance hit with ToS setting
On 24. May 2012, at 22:55 , Kevin Oberman wrote: > When we set the ToS bits for less than best effort (also called > scavenger) on packets (ToS=32), performance on FreeBSD 8.2 is > terrible. It was as good as best effort on FreeBSD 7.3 (assuming no > congestion). I will look into what 9 does, but does anyone have an > idea of why 8.2 behaves so badly when ToS is set to 32? > Here is an example of what happens to performance: > nuttcp with ToS=0: > 622.5000 MB / 1.00 sec = 5221.7570 Mbps > 623.3125 MB / 1.00 sec = 5228.5883 Mbps > 624. MB / 1.00 sec = 5234.4495 Mbps > > With ToS=32 (0x20): > 0.3750 MB / 1.00 sec =3.1457 Mbps > 0.5000 MB / 1.00 sec =4.1942 Mbps > 0.5000 MB / 1.00 sec =4.1942 Mbps > > This is,of course, on a 10G interface. On 7.3 there is little > difference between the two. We are using cubic CC on the 8.2 system. This looks like a different problem than just TOS. I assume however that not setting the TOS you get the same as expected performance? Which NIC? /bz -- Bjoern A. Zeeb You have to have visions! It does not matter how good you are. It matters what good you do! ___ 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: Major performance hit with ToS setting
On Thu, May 24, 2012 at 4:43 PM, Bjoern A. Zeeb wrote: > On 24. May 2012, at 22:55 , Kevin Oberman wrote: > >> When we set the ToS bits for less than best effort (also called >> scavenger) on packets (ToS=32), performance on FreeBSD 8.2 is >> terrible. It was as good as best effort on FreeBSD 7.3 (assuming no >> congestion). I will look into what 9 does, but does anyone have an >> idea of why 8.2 behaves so badly when ToS is set to 32? >> Here is an example of what happens to performance: >> nuttcp with ToS=0: >> 622.5000 MB / 1.00 sec = 5221.7570 Mbps >> 623.3125 MB / 1.00 sec = 5228.5883 Mbps >> 624. MB / 1.00 sec = 5234.4495 Mbps >> >> With ToS=32 (0x20): >> 0.3750 MB / 1.00 sec = 3.1457 Mbps >> 0.5000 MB / 1.00 sec = 4.1942 Mbps >> 0.5000 MB / 1.00 sec = 4.1942 Mbps >> >> This is,of course, on a 10G interface. On 7.3 there is little >> difference between the two. We are using cubic CC on the 8.2 system. > > This looks like a different problem than just TOS. I assume however > that not setting the TOS you get the same as expected performance? > > Which NIC? The two nuttcp runs were identical and we got similar results with iperf. All tests were using Myricom (mxge) cards. -- R. Kevin Oberman, Network Engineer E-mail: kob6...@gmail.com ___ 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"
Use of V_tcbinfo lock in tcp_do_segment()
Folks, I am trying to understand the need to hold the V_tcbinfo lock
in part of this function [code included below for reference].
At present this causes the socket upcall to be called with the
V_tcbinfo lock held, which I'd like to avoid. We release this lock
right after this section.
Looking at the code, it seems the lock is needed if we were in
FIN_WAIT_2 and tcp_close() the connection. The lock also seems to be
protecting V_twq_2msl.
Would it be an acceptable solution if we deferred calling
socantrecvmore() till after the lock can be dropped (after the swtich
statement). tcp_twstart() can be changed to return tp if the
connections survives, or NULL if it doesn't, much like what
tcp_close() does. Also a new lock could be added to protect the
V_rwq_2msl queue.
If this sounds acceptable, I can generate a patch against -CURRENT. I
would appreciate feedback.
-vijay
relevant code from tcp_do_segment():
if (thflags & TH_FIN) {
if (TCPS_HAVERCVDFIN(tp->t_state) == 0) {
socantrcvmore(so);
/*
* If connection is half-synchronized
* (ie NEEDSYN flag on) then delay ACK,
* so it may be piggybacked when SYN is sent.
* Otherwise, since we received a FIN then no
* more input can be expected, send ACK now.
*/
if (tp->t_flags & TF_NEEDSYN)
tp->t_flags |= TF_DELACK;
else
tp->t_flags |= TF_ACKNOW;
tp->rcv_nxt++;
}
switch (tp->t_state) {
/*
* In SYN_RECEIVED and ESTABLISHED STATES
* enter the CLOSE_WAIT state.
*/
case TCPS_SYN_RECEIVED:
tp->t_starttime = ticks;
/* FALLTHROUGH */
case TCPS_ESTABLISHED:
tp->t_state = TCPS_CLOSE_WAIT;
break;
/*
* If still in FIN_WAIT_1 STATE FIN has not been acked so
* enter the CLOSING state.
*/
case TCPS_FIN_WAIT_1:
tp->t_state = TCPS_CLOSING;
break;
/*
* In FIN_WAIT_2 state enter the TIME_WAIT state,
* starting the time-wait timer, turning off the other
* standard timers.
*/
case TCPS_FIN_WAIT_2:
INP_INFO_WLOCK_ASSERT(&V_tcbinfo);
KASSERT(ti_locked == TI_WLOCKED, ("%s: dodata "
"TCP_FIN_WAIT_2 ti_locked: %d", __func__,
ti_locked));
tcp_twstart(tp);
INP_INFO_WUNLOCK(&V_tcbinfo);
return;
}
___
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"
