Re: Interface MTU question...

[George Neville-Neil]

On Jul 11, 2012, at 17:57 , Navdeep Parhar wrote:

> On 07/11/12 14:30, g...@freebsd.org wrote:
>> Howdy,
>> 
>> Does anyone know the reason for this particular check in
>> ip_output.c?
>> 
>>  if (rte != NULL && (rte->rt_flags & (RTF_UP|RTF_HOST))) {
>>  /*
>>   * This case can happen if the user changed the MTU
>>   * of an interface after enabling IP on it.  Because
>>   * most netifs don't keep track of routes pointing to
>>   * them, there is no way for one to update all its
>>   * routes when the MTU is changed.
>>   */
>>  if (rte->rt_rmx.rmx_mtu > ifp->if_mtu)
>>  rte->rt_rmx.rmx_mtu = ifp->if_mtu;
>>  mtu = rte->rt_rmx.rmx_mtu;
>>  } else {
>>  mtu = ifp->if_mtu;
>>  }
>> 
>> To my mind the > ought to be != so that any change, up or down, of the
>> interface MTU is eventually reflected in the route.  Also, this code
>> does not check if it is both a HOST route and UP, but only if it is
>> one other the other, so don't be fooled by that, this check happens
>> for any route we have if it's up.
> 
> I believe rmx_mtu could be low due to some intermediate node between this 
> host and the final destination.  An increase in the MTU of the local 
> interface should not increase the path MTU if the limit was due to someone 
> else along the route.

Yes, it turns out to be complex.  We have several places that store the MTU.  
There is the interface,
which knows the MTU of the directly connected link, a route, and the host 
cache.  All three of these
are used to determine the maximum segment size (MSS) of a TCP packet.  The 
route and the interface
determine the maximum MTU that the MSS can have, but, if there is an entry in 
the host cache
then it is preferred over either of the first two.  See tcp_update_mss() in 
tcp_input.c to
see what I'm talking about.

I believe that the quoted code above has been wrong from the day it was 
written, in that what it
really says is "if the route is up" and not "if the route is up and is a host 
route" which is
what I believe people to read that as.  If the belief is that this code is 
really only there for
hosts routes, then the proper fix is to make the sense of the first if match 
that belief
and, again, to change the > to != so that when the administrator of the box 
bumps the MTU in
either direction that the route reflects this.  It is not possible for PMTU on 
a single link
to a host route to bump the number down if the interface says it's not to be 
bumped.  And,
even so, any host cache entry will override and avoid this code.

Best,
George

___
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: ating 100Gbit transfer rate

[Kevin Oberman]

On Wed, Jul 11, 2012 at 9:45 PM, Sami Halabi  wrote:
> Hi,
> Thank your for your response.
>
> i have 2 questions:
> 1. can you explain the looping method that allowed you to reach 100GB ?
> 2. Alcatel-Lucent is routers are given for research internationally ? or
> its locally? what routers we are talking about here and what link do they
> have? i appreciatre if you explain more how do these routers saturate 100GB.

Sure. You create an LSP with a vrf (routing-instance in Juniper-ese)
to place the traffic onto it. The LSP is manually configured at each
hop to traverse to the far end router and that one then points back at
the input router where it is again reversed back towards the
destination. Loop as often as required to saturate the link. (I was
tempted to just say "rinse and repeat, but that might not be clear to
those not in the U.S.)

For information on ANI (and I am not sure if new proposals are being
accepted), see:
http://www.es.net/RandD/advanced-networking-initiative/

> On Thu, Jul 12, 2012 at 6:43 AM, Kevin Oberman  wrote:
>>
>> On Wed, Jul 11, 2012 at 1:31 PM, Sami Halabi  wrote:
>> > Hi,
>> >
>> > We have several boxes using 10G cards and using most of the bandwidth.
>> > as a future vision i would like to ask if someone ever combined hardware
>> > with freebsd/linux to saturate 100Gbit of traffic.
>> > what hardware (server, NICs, platform) and  software do you recommend
>> > that
>> > would allow me to acheive my goal?
>> >
>> > Is it possible with servers ? or i need dedicated hardware
>> > (cisco/juniper/other?) if dedicated hardware needed, i would be glad to
>> > hear from your experience what do you recommend in terms of performance
>> > and
>> > price.
>>
>> I don't know of any 100GE hardware for any PC, but I may be a bit
>> behind on the times.
>>
>> The way we saturate a 100GE with a FreeBSD (or Linux) system is using
>> a 10G transmission stream and loop the data stream over the net using
>> MPLS. Works quite well, though no end system ever sees more than about
>> 9.9G, the routers do.
>>
>> We are using Alcatel-Lucent routers at this time for our national test
>> network. It is available for research by educational, commercial and
>> research organizations for a little longer as a federally funded
>> testbed for 100G research. When the funding for that project runs out,
>> most of the hardware will be re-purposed and will no longer be
>> available for research. gnn@ mentioned it about a year ago and
>> suggested that some FreeBSD people might want to submit proposals, but
>> I sw no responses. We have tested with Juniper and they will work,
>> too. All 100G hardware is just a mite pricey, though it has dropped
>> tremendously over the past year and a half and I expect it will
>> continue to do so.
>> --
>> R. Kevin Oberman, Network Engineer
>> E-mail: kob6...@gmail.com
>
>
>
>
> --
> Sami Halabi
> Information Systems Engineer
> NMS Projects Expert
> FreeBSD SysAdmin Expert
>



-- 
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: Interface MTU question...

[Jason Hellenthal]

On Thu, Jul 12, 2012 at 10:55:16AM -0400, George Neville-Neil wrote:
> 
> On Jul 11, 2012, at 17:57 , Navdeep Parhar wrote:
> 
> > On 07/11/12 14:30, g...@freebsd.org wrote:
> >> Howdy,
> >> 
> >> Does anyone know the reason for this particular check in
> >> ip_output.c?
> >> 
> >>if (rte != NULL && (rte->rt_flags & (RTF_UP|RTF_HOST))) {
> >>/*
> >> * This case can happen if the user changed the MTU
> >> * of an interface after enabling IP on it.  Because
> >> * most netifs don't keep track of routes pointing to
> >> * them, there is no way for one to update all its
> >> * routes when the MTU is changed.
> >> */
> >>if (rte->rt_rmx.rmx_mtu > ifp->if_mtu)
> >>rte->rt_rmx.rmx_mtu = ifp->if_mtu;
> >>mtu = rte->rt_rmx.rmx_mtu;
> >>} else {
> >>mtu = ifp->if_mtu;
> >>}
> >> 
> >> To my mind the > ought to be != so that any change, up or down, of the
> >> interface MTU is eventually reflected in the route.  Also, this code
> >> does not check if it is both a HOST route and UP, but only if it is
> >> one other the other, so don't be fooled by that, this check happens
> >> for any route we have if it's up.
> > 
> > I believe rmx_mtu could be low due to some intermediate node between this 
> > host and the final destination.  An increase in the MTU of the local 
> > interface should not increase the path MTU if the limit was due to someone 
> > else along the route.
> 
> Yes, it turns out to be complex.  We have several places that store the MTU.  
> There is the interface,
> which knows the MTU of the directly connected link, a route, and the host 
> cache.  All three of these
> are used to determine the maximum segment size (MSS) of a TCP packet.  The 
> route and the interface
> determine the maximum MTU that the MSS can have, but, if there is an entry in 
> the host cache
> then it is preferred over either of the first two.  See tcp_update_mss() in 
> tcp_input.c to
> see what I'm talking about.
> 
> I believe that the quoted code above has been wrong from the day it was 
> written, in that what it
> really says is "if the route is up" and not "if the route is up and is a host 
> route" which is
> what I believe people to read that as.  If the belief is that this code is 
> really only there for
> hosts routes, then the proper fix is to make the sense of the first if match 
> that belief
> and, again, to change the > to != so that when the administrator of the box 
> bumps the MTU in
> either direction that the route reflects this.  It is not possible for PMTU 
> on a single link
> to a host route to bump the number down if the interface says it's not to be 
> bumped.  And,
> even so, any host cache entry will override and avoid this code.
> 

Something else to look into ... 

# ifconfig lagg0 mtu 1492
ifconfig: ioctl (set mtu): Invalid argument

This is on stable/8 r238264 when the interface was up/up and down/down

Also attempted on the member interfaces dc0 and dc1


-- 

 - (2^(N-1))
___
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: Interface MTU question...

[Andrew Boyer]

On Jul 12, 2012, at 12:55 PM, Jason Hellenthal wrote:
> Something else to look into ... 
> 
> # ifconfig lagg0 mtu 1492
> ifconfig: ioctl (set mtu): Invalid argument
> 
> This is on stable/8 r238264 when the interface was up/up and down/down
> 
> Also attempted on the member interfaces dc0 and dc1


It's disabled by default, but I don't know why.  This seems to work for us.

-Andrew

Index: sys/net/if_lagg.c
===
--- sys/net/if_lagg.c   (revision 238402)
+++ sys/net/if_lagg.c   (working copy)
@@ -752,8 +752,18 @@
break;
 
case SIOCSIFMTU:
-   /* Do not allow the MTU to be changed once joined */
-   error = EINVAL;
+   LAGG_WLOCK(sc);
+   SLIST_FOREACH(lp, &sc->sc_ports, lp_entries) {
+   if (!error) {
+   /* Call the base ioctl for each port */
+   error = (*lp->lp_ioctl)(lp->lp_ifp, cmd, data);
+   }
+   }
+   if (!error) {
+   /* Update the aggregate MTU */
+   sc->sc_ifp->if_mtu = ifr->ifr_mtu;
+   }
+   LAGG_WUNLOCK(sc);
break;
 
default:

--
Andrew Boyerabo...@averesystems.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: Interface MTU question...

[Doug Barton]

While y'all are looking at MTU (which is an increasingly important topic
as we move into a Gig+ world) I'm wondering what our support is for
https://tools.ietf.org/html/rfc4821 ?? I asked this a while back and
never got an answer.

This method of PMTUD is really important given the massive (stupid)
brokenness of people routinely blocking all of ICMPv4.

Doug
___
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"

System doesn't detect unplugged network cable and doesn't set interface up properly with DHCP

[Yuri]

I have the simplest possible DHCP setup: ifconfig_re0="DHCP" in 
/etc/rc.conf.


When the system boots, it gets connected fine.

Now,  I disconnect my laptop and connect it to another network.
When cable is disconnected, IP address of this interface stays the same, 
old one is not removed.
When I plug it into another network, the same IP address stays. New IP 
doesn't get set. This is bad.
So I have to manually do 'ifconfig re0 down && remove  && 
ifconfig re0 up'.


I believe, once interface is set as "DHCP", all those things should 
happen automatically. dhclient should drop the old IP when cable is 
unplugged, and should set it up anew when cable is plugged back.


Is my system misconfigured in some way, or this is the way how it works 
in FreeBSD?


Yuri
___
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: Interface MTU question...

[George Neville-Neil]

On Jul 12, 2012, at 12:55 , Jason Hellenthal wrote:

> 
> 
> On Thu, Jul 12, 2012 at 10:55:16AM -0400, George Neville-Neil wrote:
>> 
>> On Jul 11, 2012, at 17:57 , Navdeep Parhar wrote:
>> 
>>> On 07/11/12 14:30, g...@freebsd.org wrote:
 Howdy,
 
 Does anyone know the reason for this particular check in
 ip_output.c?
 
if (rte != NULL && (rte->rt_flags & (RTF_UP|RTF_HOST))) {
/*
 * This case can happen if the user changed the MTU
 * of an interface after enabling IP on it.  Because
 * most netifs don't keep track of routes pointing to
 * them, there is no way for one to update all its
 * routes when the MTU is changed.
 */
if (rte->rt_rmx.rmx_mtu > ifp->if_mtu)
rte->rt_rmx.rmx_mtu = ifp->if_mtu;
mtu = rte->rt_rmx.rmx_mtu;
} else {
mtu = ifp->if_mtu;
}
 
 To my mind the > ought to be != so that any change, up or down, of the
 interface MTU is eventually reflected in the route.  Also, this code
 does not check if it is both a HOST route and UP, but only if it is
 one other the other, so don't be fooled by that, this check happens
 for any route we have if it's up.
>>> 
>>> I believe rmx_mtu could be low due to some intermediate node between this 
>>> host and the final destination.  An increase in the MTU of the local 
>>> interface should not increase the path MTU if the limit was due to someone 
>>> else along the route.
>> 
>> Yes, it turns out to be complex.  We have several places that store the MTU. 
>>  There is the interface,
>> which knows the MTU of the directly connected link, a route, and the host 
>> cache.  All three of these
>> are used to determine the maximum segment size (MSS) of a TCP packet.  The 
>> route and the interface
>> determine the maximum MTU that the MSS can have, but, if there is an entry 
>> in the host cache
>> then it is preferred over either of the first two.  See tcp_update_mss() in 
>> tcp_input.c to
>> see what I'm talking about.
>> 
>> I believe that the quoted code above has been wrong from the day it was 
>> written, in that what it
>> really says is "if the route is up" and not "if the route is up and is a 
>> host route" which is
>> what I believe people to read that as.  If the belief is that this code is 
>> really only there for
>> hosts routes, then the proper fix is to make the sense of the first if match 
>> that belief
>> and, again, to change the > to != so that when the administrator of the box 
>> bumps the MTU in
>> either direction that the route reflects this.  It is not possible for PMTU 
>> on a single link
>> to a host route to bump the number down if the interface says it's not to be 
>> bumped.  And,
>> even so, any host cache entry will override and avoid this code.
>> 
> 
> Something else to look into ... 
> 
> # ifconfig lagg0 mtu 1492
> ifconfig: ioctl (set mtu): Invalid argument
> 
> This is on stable/8 r238264 when the interface was up/up and down/down
> 
> Also attempted on the member interfaces dc0 and dc1
> 

Can you file a bug on that one?

Best,
George

___
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: Interface MTU question...

[George Neville-Neil]

On Jul 12, 2012, at 14:28 , Doug Barton wrote:

> While y'all are looking at MTU (which is an increasingly important topic
> as we move into a Gig+ world) I'm wondering what our support is for
> https://tools.ietf.org/html/rfc4821 ?? I asked this a while back and
> never got an answer.
> 
> This method of PMTUD is really important given the massive (stupid)
> brokenness of people routinely blocking all of ICMPv4.

We do not support that RFC and support in other OSs is quite limited.
It does not seem to be have been taken up by the Internet community
in general.

That being said, it is an interesting mechanism.  Probably not a bad idea
for a wish list item.

Best,
George

___
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: System doesn't detect unplugged network cable and doesn't set interface up properly with DHCP

[Chris Benesch]

Thats pretty standard for BSD and most Unixes.  DHCP hands out leases for a
specified period of time, so unless there is a reason to reset it, it
wont.  Windows does that, but it is designed more as a client / user facing
OS whereas BSD is designed to run in the background silently serving you
content and directing traffic.

I can save you some steps though,

ps -ax | grep dhclient

You will get a list, on the one that is dhclient or /sbin/dhclient, take
the number at the far left, thats the process ID

kill 
dhclient re0

That will force it to acquire a new address.

On Thu, Jul 12, 2012 at 1:41 PM, Yuri  wrote:

> I have the simplest possible DHCP setup: ifconfig_re0="DHCP" in
> /etc/rc.conf.
>
> When the system boots, it gets connected fine.
>
> Now,  I disconnect my laptop and connect it to another network.
> When cable is disconnected, IP address of this interface stays the same,
> old one is not removed.
> When I plug it into another network, the same IP address stays. New IP
> doesn't get set. This is bad.
> So I have to manually do 'ifconfig re0 down && remove  && ifconfig
> re0 up'.
>
> I believe, once interface is set as "DHCP", all those things should happen
> automatically. dhclient should drop the old IP when cable is unplugged, and
> should set it up anew when cable is plugged back.
>
> Is my system misconfigured in some way, or this is the way how it works in
> FreeBSD?
>
> Yuri
> __**_
> freebsd-net@freebsd.org mailing list
> http://lists.freebsd.org/**mailman/listinfo/freebsd-net
> To unsubscribe, send any mail to 
> "freebsd-net-unsubscribe@**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: Interface MTU question...

[Doug Barton]

On 07/12/2012 01:50 PM, George Neville-Neil wrote:
> 
> On Jul 12, 2012, at 14:28 , Doug Barton wrote:
> 
>> While y'all are looking at MTU (which is an increasingly important topic
>> as we move into a Gig+ world) I'm wondering what our support is for
>> https://tools.ietf.org/html/rfc4821 ?? I asked this a while back and
>> never got an answer.
>>
>> This method of PMTUD is really important given the massive (stupid)
>> brokenness of people routinely blocking all of ICMPv4.
> 
> We do not support that RFC and support in other OSs is quite limited.
> It does not seem to be have been taken up by the Internet community
> in general.
> 
> That being said, it is an interesting mechanism.  Probably not a bad idea
> for a wish list item.

Thanks for the response.

Doug
___
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: System doesn't detect unplugged network cable and doesn't set interface up properly with DHCP

[Freddie Cash]

On Thu, Jul 12, 2012 at 1:52 PM, Chris Benesch  wrote:
> Thats pretty standard for BSD and most Unixes.  DHCP hands out leases for a
> specified period of time, so unless there is a reason to reset it, it
> wont.  Windows does that, but it is designed more as a client / user facing
> OS whereas BSD is designed to run in the background silently serving you
> content and directing traffic.
>
> I can save you some steps though,
>
> ps -ax | grep dhclient
>
> You will get a list, on the one that is dhclient or /sbin/dhclient, take
> the number at the far left, thats the process ID
>
> kill 
> dhclient re0

pkill dhclient
dhclient re0

Saves a few more steps.  :)

There's also:

service netif restart re0

-- 
Freddie Cash
fjwc...@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: System doesn't detect unplugged network cable and doesn't set interface up properly with DHCP

[Chris Benesch]

I work with an old version of AIX all day, there are no shortcuts :(

On Thu, Jul 12, 2012 at 2:01 PM, Freddie Cash  wrote:

> On Thu, Jul 12, 2012 at 1:52 PM, Chris Benesch 
> wrote:
> > Thats pretty standard for BSD and most Unixes.  DHCP hands out leases
> for a
> > specified period of time, so unless there is a reason to reset it, it
> > wont.  Windows does that, but it is designed more as a client / user
> facing
> > OS whereas BSD is designed to run in the background silently serving you
> > content and directing traffic.
> >
> > I can save you some steps though,
> >
> > ps -ax | grep dhclient
> >
> > You will get a list, on the one that is dhclient or /sbin/dhclient, take
> > the number at the far left, thats the process ID
> >
> > kill 
> > dhclient re0
>
> pkill dhclient
> dhclient re0
>
> Saves a few more steps.  :)
>
> There's also:
>
> service netif restart re0
>
> --
> Freddie Cash
> fjwc...@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: System doesn't detect unplugged network cable and doesn't set interface up properly with DHCP

[Brian Reichert]

On Thu, Jul 12, 2012 at 02:01:51PM -0700, Freddie Cash wrote:
> There's also:
> 
> service netif restart re0

Does devfs expose loss-of-link events?

If so, one would think that one could script something that watches for
link-up notifications...

(I don't know about devfs anywhere near as much as I want to.)

> -- 
> Freddie Cash
> fjwc...@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"

-- 
Brian Reichert  
BSD admin/developer at large
___
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: System doesn't detect unplugged network cable and doesn't set interface up properly with DHCP

[Chris Benesch]

Maybe another option to dhclient to have it poll the interface every 2-3
seconds to see if it has lost a link and if so, set the lease timer to be
expired, and wait for it to come back and once it does, it will acquire a
new address.
___
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: System doesn't detect unplugged network cable and doesn't set interface up properly with DHCP

[Paul A. Procacci]

On Thu, Jul 12, 2012 at 03:25:07PM -0700, Chris Benesch wrote:
> Maybe another option to dhclient to have it poll the interface every 2-3
> seconds to see if it has lost a link and if so, set the lease timer to be
> expired, and wait for it to come back and once it does, it will acquire a
> new address.
> ___
> 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"

The Operating system should generate a devd event.

Something like the following in /usr/local/etc/devd.conf should do the trick,
though I haven't tested the below with anything other than carp interfaces.
I suspect it works just the same.

##
notify 30 {
match "system" "IFNET";
match "subsystem" "em0_or_whatever";
match "type" "LINK_UP";
action "/usr/local/sbin/script_to_do_something.sh up";
};

notify 30 {
match "system" "IFNET";
match "subsystem" "em0_or_whatever";
match "type" "LINK_DOWN";
action "/usr/local/sbin/script_to_do_something.sh down";
};
##

~Paul



This message may contain confidential or privileged information. If you are not 
the intended recipient, please advise us immediately and delete this message. 
See http://www.datapipe.com/legal/email_disclaimer/ for further information on 
confidentiality and the risks of non-secure electronic communication. If you 
cannot access these links, please notify us by reply message and we will send 
the contents to 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"

Broadcom NetXtreme BCM5719 support

[Jason Wolfe]

Hi,

I have an HP ProLiant DL360p Gen8 server in my possession for testing,
and it appears the Broadcom NetXtreme BCM5719 doesn't yet have
support.  I noticed someone asking about server support on
freebsd-questions last month, but it didn't garner much attention.
Played around with 8.3-RELEASE, 8-STABLE and 9.1-BETA1 trees from
yesterday and poked around the commits to ensure I wasn't missing
anything.  Everything appears to be functioning fine except for the
NIC.

bge0:  mem
0xf6bf-0xf6bf,0xf6be-0xf6be,0xf6bd-0xf6bd irq
32 at device 0.0 on pci3
bge0: CHIP ID 0x05719001; ASIC REV 0x5719; CHIP REV 0x57190; PCI-E
miibus0:  on bge0
bge0: Ethernet Address: xx:xx:xx:xx:xx:xx
...
bge0: watchdog timeout -- resetting
bge0: link state changed to UP
bge0: link state changed to DOWN
bge0: link state changed to UP
bge0: link state changed to DOWN
bge0: link state changed to UP
bge0: link state changed to DOWN
...


bge0@pci:0:3:0:0:   class=0x02 card=0x169d103c chip=0x165714e4
rev=0x01 hdr=0x00
vendor  = 'Broadcom Corporation'
device  = 'NetXtreme BCM5719 Gigabit Ethernet PCIe'
class   = network
subclass= ethernet

Anything in the pipe on this one, or any access I can provide that
might assist us?

Jason
___
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: Enable LRO by default on igb

[Ihsan Junaidi Ibrahim]

I did a quick file download test on the LRO-enabled device (forwarding is 
turned on) and there's no perceive drop-off in forwarding performance.

The test is very unscientific (over the Internet) as I don't have access to a 
local test bed where I can do more in-depth testing.

Sysctl LRO stats gave me these:
dev.igb.0.queue0.lro_queued: 53
dev.igb.0.queue0.lro_flushed: 53
dev.igb.0.queue1.lro_queued: 121
dev.igb.0.queue1.lro_flushed: 120
dev.igb.0.queue2.lro_queued: 14895
dev.igb.0.queue2.lro_flushed: 8200
dev.igb.0.queue3.lro_queued: 77
dev.igb.0.queue3.lro_flushed: 76

Just curious on why flushed and queued numbers did not seem to match.

ihsan

On Jul 8, 2012, at 12:26 AM, Jack Vogel wrote:

> Because of problems with forwarding when it was turned on, however this has
> recently been fixed supposedly, if someone using the driver in an
> environment
> with forwarding could verify that there is no problem with it enabled I'd
> be happy
> to change it to be on by default.
> 
> Jack
> 
> 
> On Sat, Jul 7, 2012 at 9:01 AM, Ihsan Junaidi Ibrahim  wrote:
> 
>> Hi folks,
>> 
>> Just curious is there a reason why LRO isn't turned on by default for
>> igb(4) like for other capabilities?
>> 
>> I have a couple of 82575EB igb devices and LRO had to be turned on
>> manually.
>> 
>> Thanks.___
>> 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"

___
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: System doesn't detect unplugged network cable and doesn't set interface up properly with DHCP

[Kevin Lo]

Yuri wrote:
> I have the simplest possible DHCP setup: ifconfig_re0="DHCP" in 
> /etc/rc.conf.
> 
> When the system boots, it gets connected fine.
> 
> Now,  I disconnect my laptop and connect it to another network.
> When cable is disconnected, IP address of this interface stays the same, 
> old one is not removed.
> When I plug it into another network, the same IP address stays. New IP 
> doesn't get set. This is bad.
> So I have to manually do 'ifconfig re0 down && remove  && 
> ifconfig re0 up'.
> 
> I believe, once interface is set as "DHCP", all those things should 
> happen automatically. dhclient should drop the old IP when cable is 
> unplugged, and should set it up anew when cable is plugged back.
> 
> Is my system misconfigured in some way, or this is the way how it works 
> in FreeBSD?

Add the following lines to /etc/devd.conf:

notify 0 {
match "system"  "IFNET";
match "type""LINK_DOWN";
media-type  "ethernet";
action "/etc/rc.d/dhclient quietstop $subsystem; ifconfig
$subsystem inet 0.0.0.0";
};

Then restart devd(8).

> Yuri

Kevin

___
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: Broadcom NetXtreme BCM5719 support

[Eugene M. Zheganin]

Hi.

On 13.07.2012 04:39, Jason Wolfe wrote:

bge0:  mem
0xf6bf-0xf6bf,0xf6be-0xf6be,0xf6bd-0xf6bd irq
32 at device 0.0 on pci3
bge0: CHIP ID 0x05719001; ASIC REV 0x5719; CHIP REV 0x57190; PCI-E
miibus0:  on bge0
bge0: Ethernet Address: xx:xx:xx:xx:xx:xx
...
bge0: watchdog timeout -- resetting
bge0: link state changed to UP
bge0: link state changed to DOWN
bge0: link state changed to UP
bge0: link state changed to DOWN
bge0: link state changed to UP
bge0: link state changed to DOWN
...


bge0@pci:0:3:0:0:   class=0x02 card=0x169d103c chip=0x165714e4
rev=0x01 hdr=0x00
 vendor  = 'Broadcom Corporation'
 device  = 'NetXtreme BCM5719 Gigabit Ethernet PCIe'
 class   = network
 subclass= ethernet

Anything in the pipe on this one, or any access I can provide that
might assist us?

I got a BMC5722 chip (and IBM x3250 mX systems), but same stuff with 
timeout/resets. I can say 8.1/8.2 were more stable concerning bge(4).
You could try to switch off tso and vlanhwtso, at least it did the trick 
for me (did it ? not sure though. I was having problems one a month on 
8.1/8.2, after upgrading to 8.3-STABLE I start having problems with it 
every day, literally, after ifconfig bge0 -tso -vlanhwtso it's running 
for 5 day now.)


Eugene.
___
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: TCP Regression Test Suite

[Julian Stecklina]

George Neville-Neil  wrote:

>
>On Jul 7, 2012, at 23:31 , Julian Stecklina wrote:
>
>> Hello,
>> 
>> do you know of a TCP regression test suite with IPv6 support?
>> 
>
>Alas, not a good one.

And bad ones? ;-)

-- 
Sent from my phone. Please excuse my brevity.
___
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"