[Mageia-sysadm] is the svn server down?

Sat Mar 31 18:16:22 CEST 2012

Op zaterdag 31 maart 2012 15:12:18 schreef Michael Scherer:
+> Le samedi 31 mars 2012 à 12:51 +0200, nicolas vigier a écrit :
+> > On Sat, 31 Mar 2012, Michael Scherer wrote:
+> > > For the record, I see that 212.85.158.145 ( alamut default gateway,
+> > > whose reverse is gateway-mageia.ielo.net ) is not answering to ping and
+> > > on the other hand, the default gateway for zarb.org ( 212.85.158.1 )
+> > > answer to ping.
+> > > 
+> > > And I am pretty sure that this gateway is after our switch from a
+> > > network point of view, and so that this should answer fine if our
+> > > switch is unplugged.
+> > > 
+> > > So I suppose that this device ( 158.45 ) do send network
+> > > topology/routing with OSPF or RIP etc, and for some reason, it no
+> > > longer announce the route for our network.
+> > > 
+> > > It could be caused by our switch being broken, but that would be rather
+> > > strange, as I do not know any network equipment that would act like
+> > > this ( doesn't mean that it doesn't exist, but usually, network is not
+> > > that smart ).
+> > 
+> > According to gradator, this is normal if the switch is down. When the
+> > port is down, OSPF automatically clear the route.
+> 
+> But what about the default gateway ? IIRC, that's not our switch ( as
+> this is just a layer 2 switch ), so did it disappear on purpose once the
+> network disappeared too ?
+> 
+> > > So what did IELO said exactly ?
+> > 
+> > The port where our switch is connected is down.
+> > 
+> > But even if the swich is not the problem, it would be a good idea to
+> > replace it for a bigger one, to allow us to connect the arm boards on
+> > it (instead of connecting them behind valstar). We also need to replace
+> > one of the disk on the arm boards which seems to be not working.
+> 
+> Connecting them behind valstar was also to protect them until we
+> properly secured them, since the password is still weak and easy to
+> attack from bruteforce. And AFAIK, we didn't plan to give direct access
+> to people, so that was useless and I think moving to a bastion model for
+> ssh access would be a improvement in term of security for others
+> builders too ( jonund, ecosse, and maybe fiona, depending how the backup
+> are done ).
+> 
+> Also, just replacing the switch is not a improvement, since we will have
+> the same issue if this switch break ( unlikely, but so was the current
+> breakage, or the various hardware issues we faced each time we got there
+> ) so what about trying to have a more redundant setup ?
+> 
+> Most, if not all, of our servers have 2 ethernet interface, so we could
+> try to see if bonding could help ( in case of ethernet card failure ) or
+> see if we can find a setup with 2 switchs ( one that doesn't cost too
+> much, cause of course, cisco can solve the issue for us, we just cannot
+> afford it ).
+> 
+> Can we afford one or two switchs that support it ? ( I lost the name of
+> the current flavor du jour in term of bonding )
+
+i think you're looking for distributed trunking? ie: having 2 cables in two 
+separate switches, so if a switch fails, it stays working...
+
+but those switches are quite expensive, iinm at least 2kEUR/switch
+
+non-distributed trunking is alot cheaper, but that just means half the servers 
+are down.
+
+or we could just not bond and have 2 different networks over such servers. that 
+also works for redundancy, but on l3 instead of l2 and alot cheaper...
+