﻿<?xml version="1.0" encoding="utf-8"?>
<rss version="2.0">
  <channel>
    <title>Recent News</title>
    <description>Recent news items from Aspserveur</description>
    <link>http://tickets.aspserveur.com/News/news.aspx</link>
    <dt>Thu, 17 May 2012 12:32:25 GMT</dt>
    <generator>SmarterTrack Enterprise 7.5.4408</generator>
    <item>
      <title>09/05/2012 : Perte de paquets sur les classes IP 93.93.186.0/23 et 62.39.95.0/25</title>
      <summary />
      <link>http://tickets.aspserveur.com/News/7/09052012-perte-de-paquets-sur-les-classes-ip-9393186023.aspx</link>
      <pubDate>Wed, 09 May 2012 15:20:00 GMT</pubDate>
      <guid isPermaLink="false">newsitem7</guid>
      <description>&lt;span style="font-family: tahoma; font-size: 13px;"&gt;Nous avons constat&amp;eacute; une attaque de type DoS sur un serveur d&amp;eacute;di&amp;eacute;. Cette attaque a caus&amp;eacute; des ralentissements sur une partie de notre r&amp;eacute;seau&amp;nbsp;le 09/05/2012&amp;nbsp;entre 16h30 et 17h20. Nous avons prenventivement coup&amp;eacute; l'acc&amp;egrave;s&amp;nbsp;du client&amp;nbsp;pour analyser les logs et mettre en place les contres mesures n&amp;eacute;cessaires au niveau de nos firewalls.&lt;br /&gt;
&lt;br /&gt;
Cette attaque a impact&amp;eacute;e les classes IP suivantes :&lt;br /&gt;
93.93.186.0/23&lt;br /&gt;
62.39.95.0/25&lt;/span&gt;</description>
    </item>
    <item>
      <title>01/03/2012 : Indisponibilite reseau</title>
      <summary />
      <link>http://tickets.aspserveur.com/News/6/01032012-indisponibilite-reseau.aspx</link>
      <pubDate>Thu, 01 Mar 2012 11:57:06 GMT</pubDate>
      <guid isPermaLink="false">newsitem6</guid>
      <description>Nous avons subi un probl&amp;egrave;me sur notre plateforme de filtrage Cisco ASA. Une partie de nos classes r&amp;eacute;seaux filtr&amp;eacute;es par cette plateforme a &amp;eacute;t&amp;eacute; indisponible de 11h15 &amp;agrave; 12h45. &lt;br /&gt;
&amp;nbsp;&lt;br /&gt;
Les classes r&amp;eacute;seaux impact&amp;eacute;s sont :&lt;br /&gt;
- 80.118.147.0/24&lt;br /&gt;
- 93.93.189.0/25&lt;br /&gt;
- 93.93.190.0/24&lt;br /&gt;
- 46.18.208.0/24&lt;br /&gt;
- 46.18.211.0/24&lt;br /&gt;
&lt;br /&gt;
Nous avons r&amp;eacute;agi imm&amp;eacute;diatement en modifiant la configuration pour r&amp;eacute;tablir la disponibilit&amp;eacute; des serveurs.</description>
    </item>
    <item>
      <title>21/02/2012 : Ralentissement d’execution des scripts ASPX v2.0 sur la plateforme mutualise.</title>
      <summary>Ralentissement d’execution des scripts ASPX v2.0 sur la plateforme mutualisé.</summary>
      <link>http://tickets.aspserveur.com/News/5/21022012-ralentissement-dexecution-des-scripts-aspx.aspx</link>
      <pubDate>Tue, 21 Feb 2012 10:50:00 GMT</pubDate>
      <guid isPermaLink="false">newsitem5</guid>
      <description>L'un des serveurs de la plateforme mutualis&amp;eacute; d'ASPSERVEUR connait depuis quelques heures un bug provoquant le ralentissement des scripts cod&amp;eacute;s en ASP.NET v2.0.&lt;br /&gt;
&lt;br /&gt;
Les pages h&amp;eacute;berg&amp;eacute;es sur ce serveur et cod&amp;eacute;es dans ce langage peuvent mettre un temps relativement long &amp;agrave; s&amp;rsquo;ex&amp;eacute;cuter sur le serveur. Cela provoque un ralentissement de la navigation.&lt;br /&gt;
&lt;br /&gt;
En revanche une fois la page charg&amp;eacute;e dans le cache du serveur l'ex&amp;eacute;cution redevient rapide jusqu'au d&amp;eacute;chargement du pool d'application.&lt;br /&gt;
&lt;br /&gt;
Ce bug ne touche pas les sites cod&amp;eacute;s dans d'autres versions d'ASPNET sur ce serveur.&lt;br /&gt;
&lt;br /&gt;
---------&lt;br /&gt;
&lt;br /&gt;
21/02, 21h00 : R&amp;eacute;initialisation des param&amp;egrave;tres ASP.net 2.0 sur le serveur et reboot.&lt;br /&gt;
&lt;br /&gt;
22/02, 08:00 : IISreset sur l'instance du serveur IIS.&lt;br /&gt;
&lt;br /&gt;
25/02, 20:00 : Apr&amp;egrave;s la r&amp;eacute;paration du framework endommag&amp;eacute; sur le serveur les temps d&amp;rsquo;ex&amp;eacute;cution semblent &amp;ecirc;tre revenu &amp;agrave; la normal. L'incident est cl&amp;ocirc;tur&amp;eacute;.</description>
    </item>
    <item>
      <title>29/01/2012 : Coupure service de transit IP BR01.MAR01</title>
      <summary />
      <link>http://tickets.aspserveur.com/News/4/29012012-coupure-service-de-transit-ip-br01mar01.aspx</link>
      <pubDate>Sun, 29 Jan 2012 07:00:00 GMT</pubDate>
      <guid isPermaLink="false">newsitem4</guid>
      <description>&lt;span style="color: rgb(51, 51, 51); font-family: calibri;"&gt;
&lt;p&gt;&lt;span style="color: rgb(51, 51, 51); font-family: calibri;"&gt;Nous avons subi une panne d'un routeur de bordure BGP4. L'&amp;eacute;quipement a red&amp;eacute;marr&amp;eacute; en boucle &amp;agrave; partir de 08h00 suite &amp;agrave; un d&amp;eacute;faut sur un module GigaEthernet (module PA-GE).&lt;/span&gt;&lt;/p&gt;
&lt;p&gt;&lt;span style="color: rgb(51, 51, 51); font-family: calibri;"&gt;Le fait que l&amp;rsquo;&amp;eacute;quipement impact&amp;eacute; red&amp;eacute;marrait en boucle n&amp;rsquo;a pas &amp;eacute;t&amp;eacute; consid&amp;eacute;r&amp;eacute; comme une panne par les routeurs en redondance ce qui explique l&amp;rsquo;absence de bascule automatique.&lt;/span&gt;&lt;/p&gt;
&lt;p&gt;&lt;span style="color: rgb(51, 51, 51); font-family: calibri;"&gt;Une partie de nos clients a &amp;eacute;t&amp;eacute; impact&amp;eacute;s par une coupure d'acc&amp;egrave;s &amp;agrave; leurs IP publiques. L'&amp;eacute;quipe d'astreinte a r&amp;eacute;agi imm&amp;eacute;diatement afin de retirer physiquement le module en d&amp;eacute;faut et de r&amp;eacute;tablir la disponibilit&amp;eacute; du service &amp;agrave; 9h40.&lt;br /&gt;
&lt;br /&gt;
Nous r&amp;eacute;alisons actuellement un audit de la configuration des &amp;eacute;quipements r&amp;eacute;seaux. Des tests seront planifi&amp;eacute;es prochainement afin de valider les m&amp;eacute;canismes de redondances.&lt;/span&gt;&lt;/p&gt;
&lt;/span&gt;</description>
    </item>
    <item>
      <title>11/10/2010 : RAPPORT D INCIDENT PANNE ELECTRIQUE DU DATACENTER SFR DE MARSEILLE SALENGRO</title>
      <summary>Incident électrique SFR.</summary>
      <link>http://tickets.aspserveur.com/News/2/11102010-rapport-d-incident-panne-electrique-du-datacenter.aspx</link>
      <pubDate>Mon, 11 Oct 2010 07:51:00 GMT</pubDate>
      <guid isPermaLink="false">newsitem2</guid>
      <description>&lt;p&gt;Start time (local):   04.10.10 15:19 PM&lt;br /&gt;
End time (local):    04.10.10 16:00 PM&lt;/p&gt;
&lt;p&gt;Downtime : une interruptions de 40 minutes&lt;/p&gt;
&lt;p&gt;N&amp;deg; d'Incident chez SFR : ticket n&amp;deg; C55900829&lt;/p&gt;
&lt;p&gt; Comme convenu, nous venons de recevoir le premier rapport de SFR concernant l'incident du 04.10.2010.&lt;br /&gt;
&lt;br /&gt;
&lt;/p&gt;</description>
    </item>
    <item>
      <title>07/10/2010 : INDISPONIBILITE RESEAU</title>
      <summary />
      <link>http://tickets.aspserveur.com/News/3/07102010-indisponibilite-reseau.aspx</link>
      <pubDate>Thu, 07 Oct 2010 07:57:00 GMT</pubDate>
      <guid isPermaLink="false">newsitem3</guid>
      <description>&lt;p&gt;Start time (local):   07.10.10 16:11 PM&lt;br /&gt;
End time (local):    07.10.10 16:24 PM&lt;/p&gt;
&lt;p&gt;Downtime : Interruption de 13 minutes sur le service IP/BGP&lt;/p&gt;
&lt;p&gt;Nous avons subi une attaque de type DoS (Deny of Service). Ce flux a provoqu&amp;eacute; la saturation d'un &amp;eacute;quipement r&amp;eacute;seau. Nous avons r&amp;eacute;agit rapidement pour analyser la provenance de l'attaque et l'arr&amp;ecirc;t du serveur en cause.&lt;/p&gt;</description>
    </item>
  </channel>
</rss>
