On Tue, Apr 13, 2010 at 08:05:13PM +0200, Sylvain Beucler wrote:
> Hey,
>
> On Tue, Apr 13, 2010 at 07:21:20PM +0200, Vincent Caron wrote:
> > 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).
>
> wb!
>
> > 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).
>
> Also: I think this started after we changed the IP addresses:
>
> 2010-02-08 Vincent Caron
>
> * Echange des interfaces eth0/eth1 au niveau assignation: eth1
> reste l'interface publique mais elle a change de MAC
>
> (I don't understand what you did exactly, actually :))
>
>
> > 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.
>
> arpspoof is a bit hard to use there because it needs to be killed. At
> a point I had used this at a client:
> #!/bin/bash
> # Force the gateway to update the MAC adresses
> gateway=$(route -n | grep ^0.0.0.0 | head -1 | awk '{print $2}')
> ip addr list eth0 | grep -E '^ +inet ' | awk '{print $2}' | sed 's,/.*,,' \
> | while read ip
> do
> arpspoof -i eth0 -t $gateway $ip& pid=${!}
> sleep 1
> kill $pid
> done
>
>
> (The main trick is ${!})
I just needed to do it again for .76 (aka lisa aka homepage).
(after blaming shorewall for a good 15mn ;))
So it's not just cvs.gna.org/.78...
--
Sylvain
_______________________________________________
Project mailing list
[email protected]
https://mail.gna.org/listinfo/project
