On Tue, 2010-04-06 at 11:37 +0200, Sylvain Beucler wrote: > Hi, > > CVS was reported to be down. > > Just in case, I ran again what fixed the issue last time: > petzi:~# arpspoof -i eth1 78.40.125.78 > 0:e0:81:5a:60:3f ff:ff:ff:ff:ff:ff 0806 42: arp reply 78.40.125.78 is-at > 0:e0:81:5a:60:3f > > It fixed the problem immediately. > > > Vincent, can you investigate what's wrong? > > Petzi was not rebooted, but Loïc may have brought the network down > when restarting SVN this week-end.
Back from a week off, I was sick (dumb cold). Right now, I know: - that this problem (bogus ARP routing in some switch) only occurs for Petzi - I had some spanning tree problems on an upstream switch, but it was fixed by my provider and I don't know the details - I have had large quantities of MAC addresses per interfaces and switch ports due to virtualization with no issue for at least 2 years - this server has an IPMI module which taps directly (the hardware way) into the eth0/BCM5721 network interface and it misbehaves in some ways during the interface setup. The PHY basically stops working during ~50sec while it's being brought up at ifup time, but AFAIK it just works afterwards. There's some MAC/ethernet soup here that's obviously horrible, I've seen similar problems on different brands (Tyan/Dell mobo + Nvidia/Broadcom chips). I'll create a ticket at Bearstech to check our switches, it has to be done anyway (I don't even know all of their configuration...). Do you think the arpspoof trick could be wired in the ifup sequence ? Something like a ' up sleep 60 && arpspoof -i eth1 78.40.125.78' in the right section of /etc/network/interfaces (the 60sec delay making up for the aforementionned IPMI bug). At least it should not harm. _______________________________________________ Project mailing list [email protected] https://mail.gna.org/listinfo/project
