Discrepancy on netstat -w x -I and what Cisco reports
This is very strange.. I can do: netstat -w 10 -I lagg0 input(lagg0) output packets errs bytespackets errs bytes colls 57806 0 41751685 232442 0 51062425 0 56459 0 38341591 225146 0 48865209 0 60687 0 43552946 227987 0 52008241 0 which is roughly 23,000 pps and the Cisco switch reports 30 second input rate 44544000 bits/sec, 16198 packets/sec Another example: netstat -w 10 -I lagg0 input(lagg0) output packets errs bytespackets errs bytes colls 7 0 52180947 89734 0 25304669 0 66847 0 49028588 81737 0 21614941 0 63530 0 43502418 83419 0 24599547 0 8,300 or so pps Cisco: 30 second input rate 1923 bits/sec, 4594 packets/sec In some cases it's pretty close, cisco says 6500 and bsd says 7500.. but sometimes it is way off I even checked the em interfaces directly to see if it was a problem with the lagg interface code and they report weird issues, check below. Kind of weird.. I'm not sure if this is a Cisco issue or Fbsd issue with the counters. It's two different Cisco switches and two fbsd machines that have the same kernel, etc. Maybe this is a side effect of setting my kernel HZ at 4000? Gets even worse like this: netstat -w 100 lagg0 input(Total) output packets errs bytespackets errs bytes colls 9229322 0 33377890249424932 0 3510341158 0 100 seconds, 9.4 million packets? That's 94,000 pps and cisco reports 2 minute input rate 4413 bits/sec, 14892 packets/sec and even check this out: netstat -w 1 lagg0 input(Total) output packets errs bytespackets errs bytes colls 92481 0 31630795 94952 0 34193131 0 89078 0 32498082 91460 0 35094821 0 87540 0 34526292 89992 0 37159101 0 88987 0 32391984 91765 0 35394351 0 netstat -w 1 em0 input(Total) output packets errs bytespackets errs bytes colls 96802 0 39474036 99897 0 42814245 0 93277 0 37018533 95943 0 39860879 0 95916 0 37559076 99032 0 40739640 0 netstat -w 1 em1 input(Total) output packets errs bytespackets errs bytes colls 97102 0 38369949 99508 0 40841183 0 92321 0 35375169 94305 0 37384073 0 92225 0 33171455 94253 0 35209658 0 What in the world?? em0 + em1 is almost 200k pps but lagg0 says 100k and i KNOW it's not doing anywhere near.. cisco report 2 minute output rate 32928000 bits/sec, 5823 packets/sec Now all lagg interfaces are reporting netstat -w 1 lagg1 input(Total) output packets errs bytespackets errs bytes colls 89324 0 30824353 91518 0 32770482 0 85875 0 31924738 87813 0 33552137 0 84105 0 31176932 85666 0 32393051 0 83617 0 32175677 84871 0 33120271 0 90611 0 37313093 92403 0 38818721 0 lagg1 goes directly to another freebsd box and on the other freebsd box I do: netstat -w 1 -I lagg1 input(lagg1) output packets errs bytespackets errs bytes colls 45 0 3078 2213 01890198 0 48 0 3245 1958 01545642 0 43 0 3186 1975 01628916 0 43 0 2905 2169 01918250 0 46 0 3464 1859 01729764 0 46 0 3134 1873 01739662 0 and the other one netstat -w 1 lagg1 input(Total) output packets errs bytespackets errs bytes colls 92149 0 31706183 93523 0 32673138 0 89737 0 28119643 91323 0 28958816 0 Doing all these reports now seems to have the interfaces stuck at packets errs bytespackets errs bytes colls 96937 0 31749525 98551 0 32678863 0 85892 0 29411078 87233 0 30182355 0 90435 0 31628680 91620 0 32215244 0 87383 0 30616741 88278 0 31026608 0 every interface on the machine is reporting the same PPS and bytes.. lol :) So something is extremely fishy about the counters.. I'm going to try and update to -STABLE to see if it makes any difference. It's not just the lagg interface either because all the em's are showing it as well. This is using 4 port Intel Server PCI Express NIC ifstat seems to report correct
Re: Discrepancy on netstat -w x -I and what Cisco reports
Greetings, I just have a question: is netstat -w 100 lagg0 a typo ? If you want to see the traffic only on single interface you should use -I I do not know if this is bug, but netstat -w 100 something_non_existing works on my bsd and just shows Total So may be from here comes the confusion. You think, that netstat count only traffic on lagg0, but it shows you the Total traffic? Paul wrote: This is very strange.. I can do: netstat -w 10 -I lagg0 input(lagg0) output packets errs bytespackets errs bytes colls 57806 0 41751685 232442 0 51062425 0 56459 0 38341591 225146 0 48865209 0 60687 0 43552946 227987 0 52008241 0 which is roughly 23,000 pps and the Cisco switch reports 30 second input rate 44544000 bits/sec, 16198 packets/sec Another example: netstat -w 10 -I lagg0 input(lagg0) output packets errs bytespackets errs bytes colls 7 0 52180947 89734 0 25304669 0 66847 0 49028588 81737 0 21614941 0 63530 0 43502418 83419 0 24599547 0 8,300 or so pps Cisco: 30 second input rate 1923 bits/sec, 4594 packets/sec In some cases it's pretty close, cisco says 6500 and bsd says 7500.. but sometimes it is way off I even checked the em interfaces directly to see if it was a problem with the lagg interface code and they report weird issues, check below. Kind of weird.. I'm not sure if this is a Cisco issue or Fbsd issue with the counters. It's two different Cisco switches and two fbsd machines that have the same kernel, etc. Maybe this is a side effect of setting my kernel HZ at 4000? Gets even worse like this: netstat -w 100 lagg0 input(Total) output packets errs bytespackets errs bytes colls 9229322 0 33377890249424932 0 3510341158 0 100 seconds, 9.4 million packets? That's 94,000 pps and cisco reports 2 minute input rate 4413 bits/sec, 14892 packets/sec Again this is Total not lagg0 and even check this out: netstat -w 1 lagg0 input*(Total) * output packets errs bytespackets errs bytes colls 92481 0 31630795 94952 0 34193131 0 89078 0 32498082 91460 0 35094821 0 87540 0 34526292 89992 0 37159101 0 88987 0 32391984 91765 0 35394351 0 netstat -w 1 em0 input*(Total) * output packets errs bytespackets errs bytes colls 96802 0 39474036 99897 0 42814245 0 93277 0 37018533 95943 0 39860879 0 95916 0 37559076 99032 0 40739640 0 netstat -w 1 em1 input * (Total) * output packets errs bytespackets errs bytes colls 97102 0 38369949 99508 0 40841183 0 92321 0 35375169 94305 0 37384073 0 92225 0 33171455 94253 0 35209658 0 What in the world?? em0 + em1 is almost 200k pps but lagg0 says 100k and i KNOW it's not doing anywhere near.. cisco report 2 minute output rate 32928000 bits/sec, 5823 packets/sec Again missing -I :) Now all lagg interfaces are reporting netstat -w 1 lagg1 input * (Total) * output packets errs bytespackets errs bytes colls 89324 0 30824353 91518 0 32770482 0 85875 0 31924738 87813 0 33552137 0 84105 0 31176932 85666 0 32393051 0 83617 0 32175677 84871 0 33120271 0 90611 0 37313093 92403 0 38818721 0 lagg1 goes directly to another freebsd box and on the other freebsd box I do: netstat -w 1 -I lagg1 input(lagg1) output packets errs bytespackets errs bytes colls 45 0 3078 2213 01890198 0 48 0 3245 1958 01545642 0 43 0 3186 1975 01628916 0 43 0 2905 2169 01918250 0 46 0 3464 1859 01729764 0 46 0 3134 1873 01739662 0 and the other one netstat -w 1 lagg1 input * (Total)* output packets errs bytespackets errs bytes colls 92149 0 31706183 93523 0 32673138 0 89737 0 28119643 91323 0 28958816 0 Doing all these reports now seems to have the interfaces stuck at packets errs bytespackets errs bytes colls 96937 0 31749525 98551 0 32678863 0 85892 0 29411078 87233 0 30182355 0 90435 0 31628680
FreeBSD 4.9 - NIS Authentication Problem (SSHD Illegal User ERROR)
**IF this is the wrong list for this topic please let me know which list I should post network services issues to. I am relatively new to FreeBSD but have quite a bit of experience with NIS on Linux. I am currently working on connecting a FreeBSD 4.9 client connection to NIS server running on OpenBSD 3.9. The ypcat commands are working and I can see the passwd and group files, however when I attempt to login to the machine I keep getting SSHD Illegal User Errors. The type of behavior I am seeing would be common on a Linux machine that uses nssswitch.conf to state which objects to pass authentication through, but its missing the nis value for passwd: or group:. Looking through the FreeBSD website I see that nssswitch was introduced in FreeBSD 5.X. For previous versions of FreeBSD and NIS, are there any additional configurations that need to be done? Possibly with PAM? I have the following values in my /etc/rc.conf files: nisdomainname=myNISdomain nis_client_enable=YES I have followed the FreeBSD NIS/YP Handbook configuration to the T, and still get the illegal user authentication any insight would be greatly appreciated. Thanks much, DK -- David Kramer, RHCE Sr. Systems Engineer Coverity, Inc. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD 4.9 - NIS Authentication Problem (SSHD Illegal User ERROR)
David Kramer schrieb: I am currently working on connecting a FreeBSD 4.9 client connection to NIS server running on OpenBSD 3.9. The ypcat commands are working and I can see the passwd and group files, however when I attempt to login to the machine I keep getting SSHD Illegal User Errors. As a first guess I would recommend: - check /etc/hosts.allow (ssh access control used by FreeBSD) - shadow support - rpcinfo -p openbsd 3.9 works OK? - run ypserv daemon in foregound, check its output -- Volker Jahns, [EMAIL PROTECTED] ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to [EMAIL PROTECTED]
how to identify a PHY?
Hi! From the bugbusting front, I'm often seeing network related issues with unknown (new) PHYs. Can please somebody explain me how one is able to identify what kind of PHY interface is build into a system? Does pciconf output provide some piece of information which leads into getting PHY information? I need to know that to work with the submitter and get their interfaces running (or retrieve information for you to work on). Thanks! Volker ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to [EMAIL PROTECTED]
Current problem reports assigned to freebsd-net@FreeBSD.org
Current FreeBSD problem reports Critical problems Serious problems S Tracker Resp. Description o kern/35442 net[sis] [patch] Problem transmitting runts in if_sis dri a kern/38554 netchanging interface ipaddress doesn't seem to work s kern/39937 netipstealth issue s kern/81147 net[net] [patch] em0 reinitialization while adding aliase s kern/86920 net[ndis] ifconfig: SIOCS80211: Invalid argument [regress o kern/92090 net[bge] bge0: watchdog timeout -- resetting f kern/92552 netA serious bug in most network drivers from 5.X to 6.X o kern/95288 net[pppd] [tty] [panic] if_ppp panic in sys/kern/tty_subr o bin/105925 netproblems with ifconfig(8) and vlan(4) [regression] s kern/105943 netNetwork stack may modify read-only mbuf chain copies o kern/106316 net[dummynet] dummynet with multipass ipfw drops packets o kern/108542 net[bce]: Huge network latencies with 6.2-RELEASE / STABL o bin/108895 netpppd(8): PPPoE dead connections on 6.2 [regression] o kern/109308 net[pppd] [panic] Multiple panics kernel ppp suspected [r o kern/109733 net[bge] bge link state issues [regression] o kern/112528 net[nfs] NFS over TCP under load hangs with impossible p o kern/112686 net[patm] patm driver freezes System (FreeBSD 6.2-p4) i38 o kern/112722 net[udp] IP v4 udp fragmented packet reject o kern/113842 net[ip6] PF_INET6 proto domain state can't be cleared wit o kern/114714 net[gre][patch] gre(4) is not MPSAFE and does not support o kern/114839 net[fxp] fxp looses ability to speak with traffic o kern/115239 net[ipnat] panic with 'kmem_map too small' using ipnat o kern/116077 net[ip] [patch] 6.2-STABLE panic during use of multi-cast f kern/116172 net[tun] [panic] Network / ipv6 recursive mutex panic o kern/116185 net[iwi] if_iwi driver leads system to reboot o kern/116328 net[bge]: Solid hang with bge interface o kern/116747 net[ndis] FreeBSD 7.0-CURRENT crash with Dell TrueMobile o kern/116837 net[tun] [panic] [patch] ifconfig tunX destroy: panic o kern/117043 net[em] Intel PWLA8492MT Dual-Port Network adapter EEPROM o kern/117271 net[tap] OpenVPN TAP uses 99% CPU on releng_6 when if_tap o kern/117423 net[vlan] Duplicate IP on different interfaces o kern/117448 net[carp] 6.2 kernel crash [regression] o kern/118880 net[ip6] IP_RECVDSTADDR IP_SENDSRCADDR not implemented o kern/119225 net[wi] 7.0-RC1 no carrier with Prism 2.5 wifi card [regr o kern/119345 net[ath] Unsuported Atheros 5424/2424 and CPU speedstep n o kern/119361 net[bge] bge(4) transmit performance problem o kern/119945 net[rum] [panic] rum device in hostap mode, cause kernel o kern/120130 net[carp] [panic] carp causes kernel panics in any conste o kern/120266 net[panic] gnugk causes kernel panic when closing UDP soc o kern/120304 net[netgraph] [patch] netgraph source assumes 32-bit time f kern/120966 net[rum]: kernel panic with if_rum and WPA encryption o kern/121080 net[bge] IPv6 NUD problem on multi address config on bge0 o kern/121181 net[panic] Fatal trap 3: breakpoint instruction fault whi o kern/121298 net[em] [panic] Fatal trap 12: page fault while in kernel o kern/121437 net[vlan] Routing to layer-2 address does not work on VLA o kern/121555 netFatal trap 12: current process = 12 (swi1: net) o kern/121624 net[em] [regression] Intel em WOL fails after upgrade to o kern/121872 net[wpi] driver fails to attach on a fujitsu-siemens s711 o kern/121983 net[fxp] fxp0 MBUF and PAE o kern/122033 net[ral] [lor] Lock order reversal in ral0 at bootup [reg o kern/122058 net[em] [panic] Panic on em1: taskq o kern/122082 net[in_pcb] NULL pointer dereference in in_pcbdrop o kern/122195 net[ed] Alignment problems in if_ed f kern/122252 net[ipmi] [bge] IPMI problem with BCM5704 (does not work o kern/122290 net[netgraph] [panic] Netgraph related kmem_map too smal o kern/122427 net[apm] [panic] apm and mDNSResponder cause panic during o kern/122551 net[bge] Broadcom 5715S no carrier on HP BL460c blade usi o kern/122743 net[panic] vm_page_unwire: invalid wire count: 0 o kern/122772 net[em] em0 taskq panic, tcp reassembly bug causes radix f kern/122794 net[lagg] Kernel panic after brings lagg(8) up if NICs ar f kern/122858 net[nsswitch] nsswitch in 7.0 is f*cked up o kern/122875 net[nfs] rstatd: Can't get namelist. 1 - fbsd 7.0-stabl o kern/122954 net[lagg] IPv6 EUI64 incorrectly chosen for lagg devices o kern/122989
Re: how to identify a PHY?
On Mon, May 12, 2008 at 12:35:59PM +0200, Volker wrote: Hi! From the bugbusting front, I'm often seeing network related issues with unknown (new) PHYs. Can please somebody explain me how one is able to identify what kind of PHY interface is build into a system? Does pciconf output provide some piece of information which leads into getting PHY information? I need to know that to work with the submitter and get their interfaces running (or retrieve information for you to work on). If the system is running the simplest thing in order to identifiy the PHYs is to check the oui= and model= output of `devinfo -v`. Otherwise boot verbose and check the OUI and model output of ukphy(4). Marius ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD 4.9 - NIS Authentication Problem (SSHD Illegal User ERROR)
David Kramer wrote: **IF this is the wrong list for this topic please let me know which list I should post network services issues to. I am relatively new to FreeBSD but have quite a bit of experience with NIS on Linux. I am currently working on connecting a FreeBSD 4.9 client connection to NIS server running on OpenBSD 3.9. The ypcat commands are working and I can see the passwd and group files, however when I attempt to login to the machine I keep getting SSHD Illegal User Errors. The type of behavior I am seeing would be common on a Linux machine that uses nssswitch.conf to state which objects to pass authentication through, but its missing the nis value for passwd: or group:. Looking through the FreeBSD website I see that nssswitch was introduced in FreeBSD 5.X. For previous versions of FreeBSD and NIS, are there any additional configurations that need to be done? Possibly with PAM? I have the following values in my /etc/rc.conf files: Have you added special records to /etc/group and /etc/master.passwd files? It should be +::: in /etc/group and +: in /etc/master.passwd. Use vipw to edit password file. nisdomainname=myNISdomain nis_client_enable=YES I have followed the FreeBSD NIS/YP Handbook configuration to the T, and still get the illegal user authentication any insight would be greatly appreciated. Thanks much, DK -- Sincerely yours, Artyom Viklenko. --- [EMAIL PROTECTED] | http://www.aws-net.org.ua/~artem [EMAIL PROTECTED] | FreeBSD: The Power to Serve - http://www.freebsd.org ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: how to identify a PHY?
On 05/12/08 13:19, Marius Strobl wrote: On Mon, May 12, 2008 at 12:35:59PM +0200, Volker wrote: Hi! From the bugbusting front, I'm often seeing network related issues with unknown (new) PHYs. Can please somebody explain me how one is able to identify what kind of PHY interface is build into a system? Does pciconf output provide some piece of information which leads into getting PHY information? I need to know that to work with the submitter and get their interfaces running (or retrieve information for you to work on). If the system is running the simplest thing in order to identifiy the PHYs is to check the oui= and model= output of `devinfo -v`. Otherwise boot verbose and check the OUI and model output of ukphy(4). Marius, thanks for your answer. As far as I understand, the devinfo output will only contain useful information if a driver attaches to the phy. Sometimes a new mainboard hits the market and the ID of the phy's chip is unknown the FreeBSD. If a submitter files a PR and no phy driver attaches, I would like to check if the chip ID is currently known to the system. So I need to know a way to check the ID of a chip without a driver being attached. In short my original question better reads as how do I know the kind of phy if no driver has been attached. Can one retrieve that information out of a verbose boot dmesg (from probing messages)? I would like to first check if a PR might be related to a phy problem at all and if it's just coming with an ID currently unknown to FreeBSD to prepare the PR into a state containing every piece of information needed to have the net-team working easily on it. Thanks Volker ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: how to identify a PHY?
Marius Strobl wrote: If the system is running the simplest thing in order to identifiy the PHYs is to check the oui= and model= output of `devinfo -v`. Otherwise boot verbose and check the OUI and model output of ukphy(4). There's a project for someone in there I'm sure. Linux has mii-tool and mii-diag. Whilst we generally don't need all of the knobs, sometimes it can be useful to dump and poke PHY registers on the MII. src/sys/dev/mii/miibus_if.m contains the newbus interface definition for miibus which would be a place to start. cheers BMS ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: how to identify a PHY?
Volker wrote: ... In short my original question better reads as how do I know the kind of phy if no driver has been attached. Can one retrieve that information out of a verbose boot dmesg (from probing messages)? You can't determine which PHY is in use unless a driver is attached, because it's necessary to attach a driver in order to access the card's MII registers. Same with any other OS. If no PHY driver attached, but a NIC driver attached, you should see this message: device_printf(dev, MII without any PHY!\n); It sounds like someone needs to instrument the code path mii_phy_probe() to print useful information in the situation you describe. cheers BMS ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: how to identify a PHY?
On Mon, May 12, 2008 at 01:55:34PM +0200, Volker wrote: On 05/12/08 13:19, Marius Strobl wrote: On Mon, May 12, 2008 at 12:35:59PM +0200, Volker wrote: Hi! From the bugbusting front, I'm often seeing network related issues with unknown (new) PHYs. Can please somebody explain me how one is able to identify what kind of PHY interface is build into a system? Does pciconf output provide some piece of information which leads into getting PHY information? I need to know that to work with the submitter and get their interfaces running (or retrieve information for you to work on). If the system is running the simplest thing in order to identifiy the PHYs is to check the oui= and model= output of `devinfo -v`. Otherwise boot verbose and check the OUI and model output of ukphy(4). Marius, thanks for your answer. As far as I understand, the devinfo output will only contain useful information if a driver attaches to the phy. Sometimes a new mainboard hits the market and the ID of the phy's chip is unknown the FreeBSD. If a submitter files a PR and no phy driver attaches, I would like to check if the chip ID is currently known to the system. So I need to know a way to check the ID of a chip without a driver being attached. In short my original question better reads as how do I know the kind of phy if no driver has been attached. Can one retrieve that information out of a verbose boot dmesg (from probing messages)? I would like to first check if a PR might be related to a phy problem at all and if it's just coming with an ID currently unknown to FreeBSD to prepare the PR into a state containing every piece of information needed to have the net-team working easily on it. For NIC drivers interfacing with miibus(4) the ukphy(4) driver always matches as a last resort. If even ukphy(4) doesn't attach this means there's a more fundamental problem of some sort with the NIC driver communicating with the MII bus. In that case there's no way to identify which PHYs are on the MII bus (it even doesn't necessarily mean they are unknown to the system.) Marius ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to [EMAIL PROTECTED]
PF NAT and IPSec (ESP) not working
Hi, I probably do something wrong, and I can't seem to get NAT in PF working with IPSec tunnel mode. Here's the network diagram: (172.16.0.0/16) internal network-- remote end of tunnel AA.AA.AA.AA --- XX.XX.XX.XX re0 (Internet) - enc (IPSec) ZZ.ZZ.ZZ.ZZ gif1 --- tun0 --- YY.YY.YY.YY/24 OpenVPN clients I want OpenVPN clients to be NAT'ed to ZZ.ZZ.ZZ.ZZ and then enter the ipsec tunnel, be encrypted and land on the other side. When I've setup NAT using following PF rule: nat pass log on enc0 inet from YY.YY.YY.YY/24 to 172.16.0.0/16 - ZZ.ZZ.ZZ.ZZ the packets go out on gif1 but are not encrypted (no traffic on enc0). Same for following NAT rule: nat pass log on enc0 inet from YY.YY.YY.YY/24 to 172.16.0.0/16 - ZZ.ZZ.ZZ.ZZ Help, please! Thanks, /S ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: read() returns ETIMEDOUT on steady TCP connection
Tim Gebbett wrote: Hi Andre, did some careful testing yesterday and last night. I seem to be still hitting an unknown buffer although the probem is much alleviated. The system achieved a 7hour run at 500mbit where ETIMEDOUT occured. I was feeding 11 other streams to the server whos counters show an uninterrupted eleven hours. The feeder streams are from the same source, so it is unlikely that the one feeding the test could of had a problem without affecting the counters of the others. sysctls are: (loader.conf) hw.em.txd=4096 net.inet.tcp.sendspace=78840 net.inet.tcp.recvspace=78840 kern.ipc.nmbjumbop=51200 kern.ipc.nmbclusters=78840 kern.maxfiles=5 IP stats are miraculously improved, going from a 10% packet loss within stack (output drops) to a consistent zero at peaks of 8 pps. I believe the problem is now being shunted to the NIC from the following output: dev.em.0.debug=1 em0: Adapter hardware address = 0xc520b224 em0: CTRL = 0x48f00249 RCTL = 0x8002 em0: Packet buffer = Tx=16k Rx=48k em0: Flow control watermarks high = 47104 low = 45604 em0: tx_int_delay = 66, tx_abs_int_delay = 66 em0: rx_int_delay = 0, rx_abs_int_delay = 66 em0: fifo workaround = 0, fifo_reset_count = 0 em0: hw tdh = 3285, hw tdt = 3285 em0: hw rdh = 201, hw rdt = 200 em0: Num Tx descriptors avail = 4096 em0: Tx Descriptors not avail1 = 4591225 em0: Tx Descriptors not avail2 = 0 em0: Std mbuf failed = 0 em0: Std mbuf cluster failed = 0 em0: Driver dropped packets = 0 em0: Driver tx dma failure in encap = 0 dev.em.0.stats=1 em0: Excessive collisions = 0 em0: Sequence errors = 0 em0: Defer count = 0 em0: Missed Packets = 16581181 em0: Receive No Buffers = 7460 em0: Receive Length Errors = 0 em0: Receive errors = 0 em0: Crc errors = 0 em0: Alignment errors = 0 em0: Collision/Carrier extension errors = 0 em0: RX overruns = 289717 em0: watchdog timeouts = 0 em0: XON Rcvd = 0 em0: XON Xmtd = 0 em0: XOFF Rcvd = 0 em0: XOFF Xmtd = 0 em0: Good Packets Rcvd = 848158221 em0: Good Packets Xmtd = 1080368640 em0: TSO Contexts Xmtd = 0 em0: TSO Contexts Failed = 0 Does the counter 'Tx Descriptors not avail1' indicate lack of decriptors at the time not available, and would this be symptomatic of something Mark suggested: (the stack) needs to handle local buffer fills not as a failed attempt on transmission that increments the retry counter, a possible better strategy required for backoff when the hardware buffer is full? Indeed. We have rethink a couple of assumptions the code currently makes and has made for the longest time. Additionally the defaults for the network hardware need to be better tuned for workloads like yours. I'm on my way to BSDCan'08 soon and I will discuss these issues at the Developer Summit. -- Andre ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: if_bridge with two subnets
Jay L. T. Cornwall wrote: H.fazaeli wrote: The bridge works as it should: It receives packets from XX.XX.XXX.YYY on the interface connected to the switch, and forwards them on the interface connected to the gateway. The problem is that forwarding between subnets is the responsibility of your switch. The switch does its job, but since the two clients are not on the same IP subnet, they can not reach each other w/o the help of an intermediate router. Perhaps I am mixing up two separate networking concepts. On a machine configured to act as a gateway, I would expect a single interface with more than one subnet to route packets correctly across those subnets. That may not be how it works in practice. If it does not work, I would question why not. If it does work then I would expect the same behaviour on each of a bridge's constituent interfaces? It does work. However, if I understand your setup correctly, the freebsd box has been setup to act as a bridge, not as a router (routing is enabled with sysctl net.inet.ip.forwarding=1). Bridging works when the forwarding is between the same subnets. For freebsd box to route between subnets: - enable routing: sysctl net.inet.ip.forwarding=1 - clients must use the freebsd box as gateway. - IP addresses must be removed from the bridge and assigned to the member interfaces. (the bridge is no longer needed). You may have bridging routing on the same box at the same time but note that a single packet coming into the system either goes through bridging _or_ routing code, but not both. The former case happens if packet's destination MAC address is not that of box. The latter case happens when destination MAC address is that of receiving interface. If you provide a network diagram along with your requirements, we can better discuss the matter. -- With best regards. Hooman Fazaeli [EMAIL PROTECTED] Technical Manager Sepehr S. T. Co. Ltd. Web: http://www.sepehrs.com Tel: (9821)88975701-2 Fax: (9821)88983352 ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: kern/123603: [tcp] tcp_do_segment and Received duplicate SYN
Old Synopsis: tcp_do_segment and Received duplicate SYN New Synopsis: [tcp] tcp_do_segment and Received duplicate SYN Responsible-Changed-From-To: freebsd-amd64-freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Mon May 12 17:42:04 UTC 2008 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=123603 ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Discrepancy on netstat -w x -I and what Cisco reports
Yes it was a typo I meant -w -I It just doesn't add up to what the switch is seeing, and it's directly connected and the traffic can't be going anywhere else. Stefan Lambrev wrote: Greetings, I just have a question: is netstat -w 100 lagg0 a typo ? If you want to see the traffic only on single interface you should use -I I do not know if this is bug, but netstat -w 100 something_non_existing works on my bsd and just shows Total So may be from here comes the confusion. You think, that netstat count only traffic on lagg0, but it shows you the Total traffic? Paul wrote: This is very strange.. I can do: netstat -w 10 -I lagg0 input(lagg0) output packets errs bytespackets errs bytes colls 57806 0 41751685 232442 0 51062425 0 56459 0 38341591 225146 0 48865209 0 60687 0 43552946 227987 0 52008241 0 which is roughly 23,000 pps and the Cisco switch reports 30 second input rate 44544000 bits/sec, 16198 packets/sec Another example: netstat -w 10 -I lagg0 input(lagg0) output packets errs bytespackets errs bytes colls 7 0 52180947 89734 0 25304669 0 66847 0 49028588 81737 0 21614941 0 63530 0 43502418 83419 0 24599547 0 8,300 or so pps Cisco: 30 second input rate 1923 bits/sec, 4594 packets/sec In some cases it's pretty close, cisco says 6500 and bsd says 7500.. but sometimes it is way off I even checked the em interfaces directly to see if it was a problem with the lagg interface code and they report weird issues, check below. Kind of weird.. I'm not sure if this is a Cisco issue or Fbsd issue with the counters. It's two different Cisco switches and two fbsd machines that have the same kernel, etc. Maybe this is a side effect of setting my kernel HZ at 4000? Gets even worse like this: netstat -w 100 lagg0 input(Total) output packets errs bytespackets errs bytes colls 9229322 0 33377890249424932 0 3510341158 0 100 seconds, 9.4 million packets? That's 94,000 pps and cisco reports 2 minute input rate 4413 bits/sec, 14892 packets/sec Again this is Total not lagg0 and even check this out: netstat -w 1 lagg0 input*(Total) * output packets errs bytespackets errs bytes colls 92481 0 31630795 94952 0 34193131 0 89078 0 32498082 91460 0 35094821 0 87540 0 34526292 89992 0 37159101 0 88987 0 32391984 91765 0 35394351 0 netstat -w 1 em0 input*(Total) * output packets errs bytespackets errs bytes colls 96802 0 39474036 99897 0 42814245 0 93277 0 37018533 95943 0 39860879 0 95916 0 37559076 99032 0 40739640 0 netstat -w 1 em1 input * (Total) * output packets errs bytespackets errs bytes colls 97102 0 38369949 99508 0 40841183 0 92321 0 35375169 94305 0 37384073 0 92225 0 33171455 94253 0 35209658 0 What in the world?? em0 + em1 is almost 200k pps but lagg0 says 100k and i KNOW it's not doing anywhere near.. cisco report 2 minute output rate 32928000 bits/sec, 5823 packets/sec Again missing -I :) Now all lagg interfaces are reporting netstat -w 1 lagg1 input * (Total) * output packets errs bytespackets errs bytes colls 89324 0 30824353 91518 0 32770482 0 85875 0 31924738 87813 0 33552137 0 84105 0 31176932 85666 0 32393051 0 83617 0 32175677 84871 0 33120271 0 90611 0 37313093 92403 0 38818721 0 lagg1 goes directly to another freebsd box and on the other freebsd box I do: netstat -w 1 -I lagg1 input(lagg1) output packets errs bytespackets errs bytes colls 45 0 3078 2213 01890198 0 48 0 3245 1958 01545642 0 43 0 3186 1975 01628916 0 43 0 2905 2169 01918250 0 46 0 3464 1859 01729764 0 46 0 3134 1873 01739662 0 and the other one netstat -w 1 lagg1 input * (Total)* output packets errs bytespackets errs bytes colls 92149 0 31706183 93523 0 32673138 0 89737 0 28119643 91323 0 28958816 0 Doing all these reports now seems to have the interfaces stuck at packets errs bytes
Re: FreeBSD 4.9 - NIS Authentication Problem (SSHD Illegal User ERROR)
Thank you all for your responses, I have solved my issue. I needed to have Bash installed and setup for the shell to mount properly when the authentication happens. A symbolic link took care of it. Thanks much, DK Volker Jahns wrote: David Kramer schrieb: I am currently working on connecting a FreeBSD 4.9 client connection to NIS server running on OpenBSD 3.9. The ypcat commands are working and I can see the passwd and group files, however when I attempt to login to the machine I keep getting SSHD Illegal User Errors. As a first guess I would recommend: - check /etc/hosts.allow (ssh access control used by FreeBSD) - shadow support - rpcinfo -p openbsd 3.9 works OK? - run ypserv daemon in foregound, check its output -- Volker Jahns, [EMAIL PROTECTED] -- David Kramer, RHCE Sr. Systems Engineer Coverity, Inc. [EMAIL PROTECTED] o. 415.694.5315 c. 650.302.7889 bb. 415.646.6320 Yahooo: Pollucts AIM: PolluctsXXX ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: kern/123617: [tcp] breaking connection when client downloading files from server
Old Synopsis: breaking connection when client downloading files from server New Synopsis: [tcp] breaking connection when client downloading files from server Responsible-Changed-From-To: freebsd-bugs-freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Mon May 12 22:43:35 UTC 2008 Responsible-Changed-Why: Over to maintainer(s), although I supposed this could also be an re(4) problem. http://www.freebsd.org/cgi/query-pr.cgi?pr=123617 ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to [EMAIL PROTECTED]
