On Wed, 2010-04-28 at 11:10 +0200, Sylvain Beucler wrote:
> Vincent, ping?
Sorry, the switch issue as still not been investigated.
I've got a new born baby, Rose, just arrived yesterday in perfect
shape. But the parents are a bit worn out :).
I'll slowly handle my mail again over the next weeks.
> 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
