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 ${!})
--
Sylvain
_______________________________________________
Project mailing list
[email protected]
https://mail.gna.org/listinfo/project
