Re: freevrrp problem
Hi Tom, There is a problem with freevrrpd and em drivers. em driver go down,wait 2 seconds, and become up again when an SIOCIFLLADDR is used. So a flapping problem will appear. The last revision in CVS resolve this problem and a new parameter called carrier_timeout (see the man with the new revision) can be used to precise the number of seconds for waiting interface to be up. New parameters for spanning tree latency and vlan has been added because when a switch port will be down and up, the port switch became in learning state and a flapping problem will result from that. Try to disable spanning tree or set the spanning tree parameter with the duration of the learning state. You can disable monitored circuits too if you want. Is you have any problems about freevrrpd, let me know with logs/conf. Regards, Sebastien. -- [EMAIL PROTECTED] - Original Message - From: "Tom Arnold" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Wednesday, May 12, 2004 3:08 AM Subject: freevrrp problem > Having a problem with a very simple freevrrp config. > This is FreeBSD 5.2.1p5 > > /usr/local/etc/freevrrpd.conf : > [VRID] > serverid = 1 > interface = em0 > priority = 255 > addr = 192.168.13.209/32 > password = dlvip > #masterscript = "/usr/local/bin/master_script.sh" > #backupscript = "/usr/local/bin/backup_script.sh" > > If I start freevrrpd I get : > May 11 17:35:40 downloads1-new freevrrpd[61294]: launching daemon in > background mode > May 11 17:35:40 downloads1-new freevrrpd[61295]: initializing threads and > all VRID > May 11 17:35:40 downloads1-new freevrrpd[61295]: reading configuration file > /usr/local/etc/freevrrpd.conf > May 11 17:35:41 downloads1-new freevrrpd[61295]: send ip = 192.168.13.210, > eth = 0:0:5e:0:1:1 > May 11 17:35:41 downloads1-new freevrrpd[61295]: send ip = 192.168.13.209, > eth = 0:0:5e:0:1:1 > May 11 17:35:41 downloads1-new freevrrpd[61295]: server state vrid 1: master > May 11 17:35:41 downloads1-new freevrrpd[61295]: interface em0 is faulty, > deactivated from VRRP VRIDs > May 11 17:35:42 downloads1-new freevrrpd[61295]: send ip = 192.168.13.210, > eth = 0:4:23:9a:97:a4 > May 11 17:35:42 downloads1-new freevrrpd[61295]: server state vrid 1: backup > > > Hardware is a Dell 650 with, of course, onboard Intel Pro/1000. > Also using freevrrp on other Dell650's, but they came with Pro/100's ( fxp ) > and work fine, so I'm leaning towards hardware or driver quirks, but any > ideas appreciated. > > Thanks. > > -- > > - Tom Arnold - When I was small, I was in love, - > - Sysabend - In love with everything. - > - CareTaker - And now there's only you... - > -- -- Thomas Dolby, "Cloudburst At Shingle Street" - > > ___ > [EMAIL PROTECTED] mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "[EMAIL PROTECTED]" > > Les informations contenues dans ce message sont confidentielles et peuvent constituer des informations privilegiees. Si vous n etes pas le destinataire de ce message, il vous est interdit de le copier, de le faire suivre, de le divulguer ou d en utiliser tout ou partie. Si vous avez recu ce message par erreur, merci de le supprimer de votre systeme, ainsi que toutes ses copies, et d en avertir immediatement l expediteur par message de retour Il est impossible de garantir que les communications par messagerie electronique arrivent en temps utile, sont securisees ou denuees de toute erreur ou virus. En consequence, l expediteur n accepte aucune responsabilite du fait des erreurs ou omissions qui pourraient en resulter. --- - --- The information contained in this e-mail is confidential. It may also be legally privileged. If you are not the addressee you may not copy, forward, disclose or use any part of it. If you have received this message in error, please delete it and all copies from your system and notify the sender immediately by return e-mail. E-mail communications cannot be guaranteed to be timely secure, error or virus-free. The sender does not accept liability for any errors or omissions which arise as a result. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: freevrrp problem
> Do you have filtering turned on/are you allowing multicast out to > the VRRP address? I'm a bit perplexed with "interface em0 is faulty". I What do you mean speaking abount 'allowing multicast out'? I'm having troubles with em0 and multicasts too (this time with RIPv2), can't make them go out all of my emX intefcases simultaneously. Eugene Grosbein ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
[SOLVED] Re: em(4) link flapping
> >>>I tried to replace a cable, to reset the switch, to reboot this > >>>4.9-STABLE > >>>box - nothing helps. What should I try next? > >>Did you tried another port on a switch? > >Yes, I tried several. No change. All other ports of switch > >carry 100Mbit links fine. > Try to plug it to another hardware, other switch or other computer to be > sure. > I think this hardware problem, not software one. And I hope you have a > warranty. You are right. The card is dead - it is detected but not initialized after reboot. Eugene ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: [4.9-R]Can I Make My DSL Connect Go Faster ? (OSX nat hint)
On May 4, 2004 11:50 am, Chuck Swiger wrote: > The Jetman wrote: > [ ... ] > > > Wes: I've used a couple of Internet speed tests, at different times, > > but always w/ the same configs. Neither config has been modified. All > > of the results are the same. I use ADSLGuide and DLSReports as my speed > > tests, which are in different continents, but both report the same > > speeds. I use different browsers, but Java is what does the deal. > > If you're using a DSL provider like Verizon which uses PPPoE, you might try > adjusting your MTU down to 1490 or so, or else you will fragment large data > packets and encounter quite a slowdown. > > Use something like this in your /etc/rc.conf file: > > ifconfig_fxp0="inet 192.168.1.2 netmask 255.255.255.0 mtu 1490" > > ...or run ifconfig directly and see whether this helps. On this exact note (and for sake of saveing hours for someone else...) , I recently turned a Macintosh G3 box running OSX 10.3 into a firewall/nat box without using their brain dead "internet shareing" tool. What I found was their natd sucked wind unless you had the apple vender extention of "clamp_mss yes" in your natd.conf From the natd man page: -clamp_mss This option enables MSS clamping. The MSS value is derived from the MTU of the interface specified in the -interface option. I know this option isn't valid in FreeBSD's natd and I'm not sure if perhaps it is handleded transparently. But with out this option under OSX I saw simular problems as to what you are describing when natting packets, even though the same download form the gateway were AOK (Perhaps soemone a bit more versed on the internals of nat can comment on this under FreeBSD) -- Darcy Buskermolen Wavefire Technologies Corp. ph: 250.717.0200 fx: 250.763.1759 http://www.wavefire.com ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
em driver losing packets
I have a Sun 1U server with 2 built in Intel Pro/1000 "LOMs" (though I had the exact same problem with a previous machine using a standalone Intel NIC). I notice that after the machine has been up for 12-20 hours, the network card starts dropping packets. Here is the relevant dmesg info: em0: port 0x2040-0x207f mem 0xfe68-0xfe69 irq 30 at device 7.0 on pci3 em0: Speed:N/A Duplex:N/A em1: port 0x2000-0x203f mem 0xfe6a-0xfe6b irq 31 at device 7.1 on pci3 em1: Speed:N/A Duplex:N/A em0: Link is up 100 Mbps Full Duplex em1: Link is up 1000 Mbps Full Duplex Limiting icmp unreach response from 1770 to 200 packets/sec ^^^ Not sure what this is, but I received a bunch of them after everything was working and before everything stopped working em1: Excessive collisions = 0 em1: Symbol errors = 0 em1: Sequence errors = 0 em1: Defer count = 0 em1: Missed Packets = 1682 em1: Receive No Buffers = 75 em1: Receive length errors = 0 em1: Receive errors = 0 em1: Crc errors = 0 em1: Alignment errors = 0 em1: Carrier extension errors = 0 em1: XON Rcvd = 0 em1: XON Xmtd = 0 em1: XOFF Rcvd = 0 em1: XOFF Xmtd = 0 em1: Good Packets Rcvd = 119975570 em1: Good Packets Xmtd = 164 em1: Adapter hardware address = 0xc76262ec em1:tx_int_delay = 66, tx_abs_int_delay = 66 em1:rx_int_delay = 488, rx_abs_int_delay = 977 em1: fifo workaround = 0, fifo_reset = 0 em1: hw tdh = 170, hw tdt = 170 em1: Num Tx descriptors avail = 256 em1: Tx Descriptors not avail1 = 0 em1: Tx Descriptors not avail2 = 0 em1: Std mbuf failed = 0 em1: Std mbuf cluster failed = 0 em1: Driver dropped packets = 0 I was running 5.2.1-RELEASE with em driver version 1.7.19 or 1.7.17 (I forget what it comes with). I had the problems so I backported 1.7.25 from 5.2.1-STABLE as of May 10. Same issue. Notice the "missed packets" and "receive no buffers". I assume that means the network card ran out of memory? How much memory does it have? If it uses the mainboard memory, can I make that amount any bigger? The odd thing (which is why I think this is a driver issue) is that it works just fine when the machine is first booted. I am driving approximately 680 mbits/sec of UDP traffic; 1316 byte packets. The only other traffic is arp traffic (em1 has a netmask of 255.255.255.255). I have this problem whether I use kernel polling (HZ=1000) or with rx_abs_int_delay=1000, or with rx_abs_int_delay=500. If I shut off the rx_*int_delay, then CPU load goes to 100% and I still have the same problem. With the abs delay at 1000, cpu load is 90% (about split evenly between user and system). If you have any ideas I'd really appreciate it. Thanks! I'm thinking of trying to backport 1.7.31. Scott ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: freevrrp problem
On Wed, May 12, 2004 at 12:30:26PM +0200, Sebastien Petit wrote: > There is a problem with freevrrpd and em drivers. em driver go down,wait 2 > seconds, and become up again when an SIOCIFLLADDR is used. So a flapping > problem will appear. The last revision in CVS resolve this problem and a new > parameter called carrier_timeout (see the man with the new revision) can be > used to precise the number of seconds for waiting interface to be up. > New parameters for spanning tree latency and vlan has been added because > when a switch port will be down and up, the port switch became in learning > state and a flapping problem will result from that. Try to disable spanning > tree or set the spanning tree parameter with the duration of the learning > state. I grabbed the latest version of CVS yesterday which is how I got it to work at all. Spanning tree is not enabled in the switch. Here's my freevrrpd config from the primary machine. secondary is the same but with 200 for priority. serverid = 1 interface = em0 priority = 255 addr = 192.168.13.209/32 password = dlvip useVMAC = yes carriertimeout = 3 spanningtreelatency = 0 sendgratuitousarp = yes monitoredcircuits = yes AHencryption = no #masterscript = "/usr/local/bin/master_script.sh" #backupscript = "/usr/local/bin/backup_script.sh" Now I can start freevrrpd and within a few seconds the machine is reachable again. if I shut down freevrrpd the machine becomes unreachable for some period of time greater then my ssh timeout. If I start up freevrrpd on the secondary server I get : freevrrpd[64090]: authentification incorrect in a received vrrp packet. Packet is discarded ! And of course at this stage network to both machines becomes flakey as they fight over the vip. Is there a simple patch for .8.7 that makes em0 work? Unfortunatly I was expecting this to be as plug and play as it is on fxp cards, so I'm short on time before my decision point of wasting a few hours on a colo trip to swap the cards out. Thanks! -- - Tom Arnold - When I was small, I was in love, - - Sysabend - In love with everything. - - CareTaker - And now there's only you... - -- -- Thomas Dolby, "Cloudburst At Shingle Street" - ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
multiple conection to internet
Dear BSD'ers Can freebsd routing kernel handle multiple provider (multipath gateway) ? without BGP ? Now I have a (new ) ADSL, and T1 connection to different provider, my LAN is nat-ing behind freebsd router, I want some people in my network to connect to internet via ADSL and some people via T1, based on their IP. They said , i can do that with linux iproute tools, but i dont want to replace my FreeBSD-4.9Stable router with Linux. Please help me, any suggestion is appriciate. regards reza ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: [4.9-R]Can I Make My DSL Connect Go Faster ? (OSX nat hint)
Darcy Buskermolen wrote: I know this option isn't valid in FreeBSD's natd and I'm not sure if perhaps it is handleded transparently. But with out this option under OSX I saw simular problems as to what you are describing when natting packets, even though the same download form the gateway were AOK (Perhaps soemone a bit more versed on the internals of nat can comment on this under FreeBSD) with ipnat you can use the option mssclamp [VALUE] Else, you can use tcpmssd (from /usr/ports/net/tcpmssd) to change your MSS on the fly. Cheers, Beto ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: multiple conection to internet
On Thu, May 13, 2004 at 08:56:24AM +0700, Muhammad Reza wrote: > I want some people in my network to connect to internet via ADSL and some > people via T1, based on their IP. > They said , i can do that with linux iproute tools, but i dont want to > replace my FreeBSD-4.9Stable router with Linux. Yes, using ipfw, ipfilter and pf firewall 'forwarding' rules. Regards, BMS ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
