Vincent, ping?
On Thu, Apr 15, 2010 at 10:18:34PM +0200, Sylvain Beucler wrote:
> 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
