[FRnOG] RE: [TECH] RFC 7404: Using Only Link-Local Addressing Inside an IPv6 Network
Michel Py a écrit : Comme s'il n'y avait pas assez d'addresses IPv6 pour avoir une excuse de re-créer la merdasse et les abominations du marais. Stephane Bortzmeyer a écrit : La justification des partisans des LLA n'est _pas_ le manque d'adresses IP. J'étais au courant. Il n'est pas nouveau que je sens le souffre à l'IETF depuis que j'ai poliment décliné de co-écrire la justification en question. J'avais doublement tort : techniquement pour des raisons qui n'existent plus depuis longtemps, et politiquement pour les conséquences. Sauf que 10 ans après, j'ai toujours raison; c'est une monstruosité. Utiliser RFC1918, tout le monde l'a fait et continue à le faire. C'était crade, mais au moins il y avait une excuse à moitié bonne. Using Only Link-Local Addressing, c'est crade, çà va faire chier tout le monde, et il n'y a pas d'excuse. Michel. --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [MISC] Datacenter Marocain
Le 19/11/2014 19:54, Antoine Boniface a écrit : Rien à voir avec le parc existant de salles informatiques au Maroc. Elles fonctionnent moins bien ? -- Manu Jacquet --- Liste de diffusion du FRnOG http://www.frnog.org/
[FRnOG] RE: [TECH] RFC 7404: Using Only Link-Local Addressing Inside an IPv6 Network
Stephane Bortzmeyer a écrit : La justification des partisans des LLA n'est _pas_ le manque d'adresses IP. Un malheureux accident de copier/coller à cette heure avancée du petit-matin a enlevé ceci de ma dernière contrib : Toi qui connais DNS mieux que moi, veux-tu recréer la même connerie que nous avons aujourd'hui avec ce qui est presque une DDOS sur l'infra de demander des PTR pour 1.1.168.192.in-addr.arpa ? mets aussi 1.0.168.192.in-addr.arpa. Tu veux çà avec IPv6 ? Michel. --- Liste de diffusion du FRnOG http://www.frnog.org/
[FRnOG] Re: [TECH] RFC 7404: Using Only Link-Local Addressing Inside an IPv6 Network
Cisco a bien du planquer la commande pour modifier l’interface source des erreurs ICMP…. Ca existe en NX-OS, mais introuvable en IOS et IOS-XE. Si ça veut dire un règle de NAT pour altérer les ICMP en question en sortie, c’est pas joli joli. Le 20 nov. 2014 à 08:58, Stephane Bortzmeyer bortzme...@nic.fr a écrit : On Thu, Nov 20, 2014 at 08:56:39AM +0100, David Ponzone david.ponz...@gmail.com wrote a message of 21 lines which said: La sécurité plutôt non ? Il faut lire mon article en entier :-) --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] RE: [TECH] RFC 7404: Using Only Link-Local Addressing Inside an IPv6 Network
❦ 20 novembre 2014 08:09 GMT, Michel Py mic...@arneill-py.sacramento.ca.us : Sauf que 10 ans après, j'ai toujours raison; c'est une monstruosité. Utiliser RFC1918, tout le monde l'a fait et continue à le faire. C'était crade, mais au moins il y avait une excuse à moitié bonne. Using Only Link-Local Addressing, c'est crade, çà va faire chier tout le monde, et il n'y a pas d'excuse. Je ne vois pas trop le lien avec la RFC 1918. Les avantages cités sont : - table de routage plus petite (sans configuration supplémentaire) - plan d'adressage simplifié - moins de configuration à faire - moins de config dans le DNS - plus de sécurité (seul truc en lien avec la RFC 1918 et la RFC n'insiste pas énormément sur ce point) Le selling point, c'est que tu configures une adresse globale en loopback et tout le reste se retrouve juste avec des LLA. En IPv4, c'est comme les unnumebered interface sauf qu'il y a encore moins à configurer. -- Avoid temporary variables. - The Elements of Programming Style (Kernighan Plauger) --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] RE: [TECH] RFC 7404: Using Only Link-Local Addressing Inside an IPv6 Network
Voir la RFC 7404 envoyée par Stéphane à l’origine de ce thread, en particulier la partie sur les inconvénients de l’usage de LLA, puisqu’à priori, c’est ça le point commun avec numéroter les interfaces en RFC1918. Le 20 nov. 2014 à 10:27, Vincent Bernat ber...@luffy.cx a écrit : ❦ 20 novembre 2014 08:09 GMT, Michel Py mic...@arneill-py.sacramento.ca.us : Sauf que 10 ans après, j'ai toujours raison; c'est une monstruosité. Utiliser RFC1918, tout le monde l'a fait et continue à le faire. C'était crade, mais au moins il y avait une excuse à moitié bonne. Using Only Link-Local Addressing, c'est crade, çà va faire chier tout le monde, et il n'y a pas d'excuse. Je ne vois pas trop le lien avec la RFC 1918. Les avantages cités sont : - table de routage plus petite (sans configuration supplémentaire) - plan d'adressage simplifié - moins de configuration à faire - moins de config dans le DNS - plus de sécurité (seul truc en lien avec la RFC 1918 et la RFC n'insiste pas énormément sur ce point) Le selling point, c'est que tu configures une adresse globale en loopback et tout le reste se retrouve juste avec des LLA. En IPv4, c'est comme les unnumebered interface sauf qu'il y a encore moins à configurer. -- Avoid temporary variables. - The Elements of Programming Style (Kernighan Plauger) --- Liste de diffusion du FRnOG http://www.frnog.org/ --- Liste de diffusion du FRnOG http://www.frnog.org/
[FRnOG] [BIZ] PowerEdge 1950 II R610 HP DL380G4 [VTS] SPEC
Bonjour, Toujours sur onduleur: Voici les specs : PowerEdge R610 + 2 chassie en stock (uniquement) Double alimentation Dell PERC 6/i RAID Controller Card 256MB + 2 en stock Drac (entreprise) + 1 en stock CPU X1 XEON L5506 2.13Ghz X3 4G de ram (8G au total) 6 Rack pour Disque 2.5 (sans disque) + disque en option Lecteur DVD + 2 en stock PowerEdge 1950 II Double alimentation RAID 'sur la photo' ou SAS (sur demande) Drac CPU X2 XEON 5160 3.00Ghz X2 2G + X2 1G (total 6G de ram) pas de lecteur HP DL380 G4 U2 Double alimentation CPU X2 3.80Ghz X6 Disque de 300G 3.5 (ISCI) 4G de ram Lecteur A prendre sur place PARIS 15 Merci de faire une proposition Cordialement, Jean-Baptiste Le 19 novembre 2014 19:06, jean-baptiste Pétré ashe...@hotmail.fr a écrit : Bonjour, Bonsoir, je m’excuse pour petit mail. J'ai du matériel qui commence a prendre la poussier et donc je doit m'en débarrasser au plus vite . J'ai trois serveur a ventre : PowerEdge 1950 II PowerEdge R610 HP DL380G4 Serveur a venir cherche sur place. Pour ceux et celle qui serais intéresser contacté moi en priver afin de ne pas trop faire de spam. Merci a vous. Cordialement, --- Liste de diffusion du FRnOG http://www.frnog.org/ --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: Re: [FRnOG] [MISC] Datacenter Marocain
Les salles informatiques des grands clients corporates que nous avons visitées sont un véritable cauchemar. Il s'agit souvent de plateaux de bureaux reconvertis en salle informatique ou de parkings en sous-sol aménagés en Datacenter. Ceci étant dit, cela va évoluer rapidement car il y a une réelle volonté d'agir vite au Maroc et toutes les grandes entreprises sont en train de faire ce qu'il faut pour respecter les normes internationales. --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [MISC] Datacenter Marocain
Même eux ? http://www.nplusone.ma/ Ca a l’air « relativement » sérieux sur la papier, même si ça manque de photos et d’infos sur la société. Le 20 nov. 2014 à 12:21, Antoine Boniface antoine.bonif...@etixgroup.com a écrit : Les salles informatiques des grands clients corporates que nous avons visitées sont un véritable cauchemar. Il s'agit souvent de plateaux de bureaux reconvertis en salle informatique ou de parkings en sous-sol aménagés en Datacenter. Ceci étant dit, cela va évoluer rapidement car il y a une réelle volonté d'agir vite au Maroc et toutes les grandes entreprises sont en train de faire ce qu'il faut pour respecter les normes internationales. --- Liste de diffusion du FRnOG http://www.frnog.org/ --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: Re: [FRnOG] [MISC] Datacenter Marocain
Je ne préfère pas répondre vis-à-vis de nos concurrents. Mais il vaut mieux visiter (en profondeur) avant de signer ;) --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [MISC] Datacenter Marocain
Le tableau n'est quand même pas aussi sombre que ça, n'exagérons rien. On a bien TH chez nous qui pourrait correspondre a la caricature si on va dans ce sens... En plus c'est pas très sympa pour nos confrères locaux qui n'ont pas nécessairement accès a la débauche de moyens dont nous disposons... De mémoire, les DC de quelques banques française a Casa ne correspondent pas a la description du DC bricole dans la cave il me semble. Peut être pas adapte a recevoir des clients tiers mais parfaitement opérationnels pour les besoins desdites banques... Maintenant oui y'a pas equinix, global switch et consors effectivement. Le 20 nov. 2014e à 12:49, Antoine Boniface antoine.bonif...@etixgroup.com a écrit : Je ne préfère pas répondre vis-à-vis de nos concurrents. Mais il vaut mieux visiter (en profondeur) avant de signer ;) --- Liste de diffusion du FRnOG http://www.frnog.org/ --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: Re: [FRnOG] [MISC] Datacenter Marocain
Je ne connais pas tous les DC des banques françaises de Casa, mais je peux vous confirmer que c'est très limite pour ceux visités ou audités et c'est pour cela que toutes les banques sont en train d'agir (notamment pour respecter Bale 3). Nous en avons déjà signé certaines pour leur site de production et/ou leur site de backup. Par contre, concernant les DC des opérateurs télécoms il y a du mieux, notamment avec le site d'INWI à Sapino qui est pas trop mal. Le marché marocain bouge dans le bon sens et c'est tant mieux pour cette industrie. --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] - Blocage des requètes HTTP contenant un header X-Forwarded-For:
Salut, Le 13/11/2014 16:11, Laurent CARON a écrit : Je constate depuis quelques semaines concernant seloger.com (et autres sites du groupe) et depuis ce matin concernant boursorama.com une impossibilité d'accès en passant pas un proxy envoyant X-Forwarded-For: Ah intéressant, j'ai un client qui a également eu le même souci, avec seloger.com ou un autre site du même genre :squid.conf: forwarded_for on - valeur par défaut - accès interdit à ces sites forwarded_for delete - accès autorisé Ne chaînerais-tu pas plusieurs proxy ? genre dansguardian+squid ? Si oui, je viens de vérifier, c'est ce qui semble déranger seloger.com. En paramétrant squid en transparent, le serveur web ne voit qu'une seule ip dans le champs X-Forwarded-For, et seloger.com fonctionne. Exemple: curl --header X-Forwarded-For: 10.10.10.10 http://www.boursorama.com; !DOCTYPE HTML PUBLIC -//IETF//DTD HTML 2.0//EN htmlhead title403 Forbidden/title /headbody h1Forbidden/h1 pYou don't have permission to access / on this server./p /body/html Note intéressante: curl --header X-Forwarded-For: 8.8.8.8 http://www.boursorama.com; fonctionne Il semblerait donc que boursorama n'accepte pas de requètes comportant un X forwarded for contenant une IP RFC1918. Je n'ai pas ce souci sur Boursorama, testé à divers endroits, le souci n'aurait-il pas été corrigé depuis ? Et vous, envoyez-vous un x-forwarded-for (à l'exterieur) ? Je laisse la valeur par défaut, donc oui, honnêtement je m'en fiche un peu qu'un site distant puisse voir mon adressage interne, même si quelque part ça pourrait aider certains petits malins qui profiteraient de la crédulité d'un utilisateur pour obtenir plus vite une info afin d'effectuer une attaque plus ciblée... Bouais... À priori seul ce client a été impacté par ce souci, mais à l'avenir je vais garder un oeil là dessus, et si ça se généralise, passer l'option en mode transparent, ou même en delete si vraiment ils sont décidés à nous eder. Rejetez-vous les requètes dans lesquelles x forwarded for contient une IP RFC1918 ? Est-ce une appliance crypto-communisto-castratrice ? Là par contre je suis preneur d'info sur le pourquoi serait rejetée une IP RFC1918, j'aurais plutôt tendance à penser à des bugs de développeurs qui n'auraient par exemple dans mon cas pas pris en compte le fait que des proxy peuvent être chaînés, et apparaître dans le X-Forwarded-For, ou encore qui croient qu'une 1918 dans un X-Forwarded-For, saimal. Ou bien serait-ce des tentatives pour bloquer des attaques ou même des consultations de sites qui utiliseraient un chaînage de proxy ? Enfin celui qui fait ça avec des proxy bavards de X-Forwarded-For ne serait pas très malin... -- Guillaume Rousseau --- Liste de diffusion du FRnOG http://www.frnog.org/
RE: [FRnOG] [MISC] Datacenter Marocain
Pour nplusone, nous devons faire une visite dans les prochains jours, je vais tenter de prendre qq photos ... Alain -Message d'origine- De : frnog-requ...@frnog.org [mailto:frnog-requ...@frnog.org] De la part de David Ponzone Envoyé : jeudi 20 novembre 2014 12:44 À : Antoine Boniface Cc : frnog@frnog.org; m...@formidable-inc.net Objet : Re: [FRnOG] [MISC] Datacenter Marocain Même eux ? http://www.nplusone.ma/ Ca a lair « relativement » sérieux sur la papier, même si ça manque de photos et dinfos sur la société. Le 20 nov. 2014 à 12:21, Antoine Boniface antoine.bonif...@etixgroup.com a écrit : Les salles informatiques des grands clients corporates que nous avons visitées sont un véritable cauchemar. Il s'agit souvent de plateaux de bureaux reconvertis en salle informatique ou de parkings en sous-sol aménagés en Datacenter. Ceci étant dit, cela va évoluer rapidement car il y a une réelle volonté d'agir vite au Maroc et toutes les grandes entreprises sont en train de faire ce qu'il faut pour respecter les normes internationales. --- Liste de diffusion du FRnOG http://www.frnog.org/ --- Liste de diffusion du FRnOG http://www.frnog.org/ --- Liste de diffusion du FRnOG http://www.frnog.org/
Le: [FRnOG] [TECH] Comportement étrange Firewall / routeur
Bonjour Gautier, Quand tu parles de « désactiver un vdom » : tu as fait quoi exactement ? Tu n’as pas indiqué non plus le modèle du FG et les features activés. L’idéal aurait été d’avoir une capture du trafic envoyé par le serveur pour comprendre ce qui s’est passé. Ma supposition est que tu avais une saturation CPU. Quand tu dis que la charge cpu est passée à 40%, l’info n’est pas précise parce que je suppose que c’est une moyenne (tu peux avoir des pics à 100% qui disparaissent de tes graphes) et si ton fg est multicpu : on n’a pas l’info précise par CPU. Tu peux avoir des CPU qui pioncent et un CPU qui sature … il suffit que le CPU qui sature soit le CPU qui gère le routage dynamique + processus kernel userspace (a priori cpu0) et c'est tout ton boitier qui trinque. Un problème courant serait que ton serveur attaqué génère du trafic qui nécessite d’être traité par le FW en CPU (le NPU envoi les interruption au même CPU sans les ventiler correctement. Si ce CPU est le cpu0 : tu impactes ta ha, ton routage dynamique et autres processus mgmt). La fragmentation, les tempêtes de broadcast, etc. sont par exemple traités en CPU. (Et je ne parle pas de L7) Commandes utiles : 1) #diag hardware sysinfo interrupts (pour voir les interruptions NPU = CPU et la répartition) 2) #conf sys npu #set dedicated-management-cpu enable #end (pour que les interruption NPU ne soient plus envoyées au CPU0 et n’impacte pas les processus « user-space et kernel » qui consomment le CPU0) Bon courage @+ Stephane CROISY --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Comportement étrange Firewall / routeur
Bonjour Gautier, Quand tu parles de « désactiver un vdom » : tu as fait quoi exactement ? Tu n’as pas indiqué non plus le modèle du FG et les features activés. L’idéal aurait été d’avoir une capture du trafic envoyé par le serveur pour comprendre ce qui s’est passé. Ma supposition est que tu avais une saturation CPU. Quand tu dis que la charge cpu est passée à 40%, l’info n’est pas précise parce que je suppose que c’est une moyenne (tu peux avoir des pics à 100% qui disparaissent de tes graphes) et si ton fg est multicpu : on n’a pas l’info précise par CPU. Tu peux avoir des CPU qui pioncent et un CPU qui sature … il suffit que le CPU qui sature soit le CPU qui gère le routage dynamique + processus kernel userspace (a priori cpu0) et c'est tout ton boitier qui trinque. Un problème courant serait que ton serveur attaqué génère du trafic qui nécessite d’être traité par le FW en CPU (le NPU envoi les interruption au même CPU sans les ventiler correctement. Si ce CPU est le cpu0 : tu impactes ta ha, ton routage dynamique et autres processus mgmt). La fragmentation, les tempêtes de broadcast, etc. sont par exemple traités en CPU. (Et je ne parle pas de L7) Commandes utiles : 1) #diag hardware sysinfo interrupts (pour voir les interruptions NPU = CPU et la répartition) 2) #conf sys npu #set dedicated-management-cpu enable #end (pour que les interruption NPU ne soient plus envoyées au CPU0 et n’impacte pas les processus « user-space et kernel » qui consomment le CPU0) Bon courage @+ Stephane --- Liste de diffusion du FRnOG http://www.frnog.org/
[FRnOG] [TECH] Cross connect et période initiale contractuelle
Hello, Mon employeur a une partie de ses infra hébergées chez Equinix (PA2) en sous location via un intermédiaire par lequel nous sommes tenus de passer pour toute prestation. Pour la première fois, nous devons faire par nous même la demande de cross connect fibre pour joindre un partenaire. A reception de la proposition commerciale de l’intermédiaire avec lequel nous travaillons, il aura sans surprise du fas et du recrurent sur cette prestation, mais a ma grande surprise, nous devons également nous engager un an sur cette prestation (c'est la politique contractuelle Equinix d'apres ce qu'on me dit). Il me parait vraiment étrange de devoir s'engager sur de la prestation 'filasse interne', savez vous comment ca se passe dans la vrai vie lorsqu'on travaille en direct avec Equinix? A vot' bon coeur. Fabien --- Liste de diffusion du FRnOG http://www.frnog.org/
RE:[FRnOG] [TECH] Comportement étrange Firewall / routeur
Bonjour Stéphane Quand tu parles de « désactiver un vdom » : tu as fait quoi exactement ? Depuis l'interface graphique VDOM-VDOM-Edit-Disable Tu n’as pas indiqué non plus le modèle du FG et les features activés. En l'occurence il s'agit d'un fortigate 100-D. Pour le client en question, aucune feature spécifique n'est activé (il matche une règle du type any-any accept).D'autres IP du subnet ont l'IPS d'activé. Ma supposition est que tu avais une saturation CPU. J'avais écarté cette supposition que je m'étais faite (cf. suite) Quand tu dis que la charge cpu est passée à 40%, l’info n’est pas précise parce que je suppose que c’est une moyenne (tu peux avoir des pics à 100% qui disparaissent de tes graphes) Cette hypothèse est peu probable : on a une supervision assez agressive sur l'état du(des) CPU(s). Cette ci se déclence notamment dès que l'on se connecte sur l'interface graphique et que tous les graphes s'affichent (ce qui n'a pas d'impact sur le trafic). On aurait eu des alarmes sans aucun doute si il était monté, même temporairement, à 100% et si ton fg est multicpu : on n’a pas l’info précise par CPU. Ma supposition est que tu avais une saturation CPU. (bis) Je reviens sur cette supposition, pendant l'attaque la charge CPU était environ 20-25% supérieure à l'habitude. Pour un firewall qui a 4 CPU, la valeur est troublante. J'aurais donc le CPU0 à 100% et les 3 autres qui ne font rien? Piste très intéressante. Gautier AVRIL De : frnog-requ...@frnog.org [frnog-requ...@frnog.org] de la part de Stéphane C. [papa...@gmail.com] Envoyé : jeudi 20 novembre 2014 15:41 À : frnog@frnog.org Objet : Le: [FRnOG] [TECH] Comportement étrange Firewall / routeur Bonjour Gautier, Quand tu parles de « désactiver un vdom » : tu as fait quoi exactement ? Tu n’as pas indiqué non plus le modèle du FG et les features activés. L’idéal aurait été d’avoir une capture du trafic envoyé par le serveur pour comprendre ce qui s’est passé. Ma supposition est que tu avais une saturation CPU. Quand tu dis que la charge cpu est passée à 40%, l’info n’est pas précise parce que je suppose que c’est une moyenne (tu peux avoir des pics à 100% qui disparaissent de tes graphes) et si ton fg est multicpu : on n’a pas l’info précise par CPU. Tu peux avoir des CPU qui pioncent et un CPU qui sature … il suffit que le CPU qui sature soit le CPU qui gère le routage dynamique + processus kernel userspace (a priori cpu0) et c'est tout ton boitier qui trinque. Un problème courant serait que ton serveur attaqué génère du trafic qui nécessite d’être traité par le FW en CPU (le NPU envoi les interruption au même CPU sans les ventiler correctement. Si ce CPU est le cpu0 : tu impactes ta ha, ton routage dynamique et autres processus mgmt). La fragmentation, les tempêtes de broadcast, etc. sont par exemple traités en CPU. (Et je ne parle pas de L7) Commandes utiles : 1) #diag hardware sysinfo interrupts (pour voir les interruptions NPU = CPU et la répartition) 2) #conf sys npu #set dedicated-management-cpu enable #end (pour que les interruption NPU ne soient plus envoyées au CPU0 et n’impacte pas les processus « user-space et kernel » qui consomment le CPU0) Bon courage @+ Stephane CROISY --- Liste de diffusion du FRnOG http://www.frnog.org/ --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Comportement étrange Firewall / routeur
A creuser. Concernant ta supervision : si c'est du SNMP, elle ne sera peut être pas révélatrice du problème parce que si ton cpu0 est saturé, le processus SNMP du FG sera lui aussi impacté. Quoiqu'il en soit, c'est compliquer de faire autre chose que des suppositions sans traces. La source du problème peut être malheureusement multiple. Le jeu 20 nov. 2014 16:20, Gautier Avril gautier.av...@bretagnetelecom.com a écrit : Bonjour Stéphane Quand tu parles de « désactiver un vdom » : tu as fait quoi exactement ? Depuis l'interface graphique VDOM-VDOM-Edit-Disable Tu n’as pas indiqué non plus le modèle du FG et les features activés. En l'occurence il s'agit d'un fortigate 100-D. Pour le client en question, aucune feature spécifique n'est activé (il matche une règle du type any-any accept).D'autres IP du subnet ont l'IPS d'activé. Ma supposition est que tu avais une saturation CPU. J'avais écarté cette supposition que je m'étais faite (cf. suite) Quand tu dis que la charge cpu est passée à 40%, l’info n’est pas précise parce que je suppose que c’est une moyenne (tu peux avoir des pics à 100% qui disparaissent de tes graphes) Cette hypothèse est peu probable : on a une supervision assez agressive sur l'état du(des) CPU(s). Cette ci se déclence notamment dès que l'on se connecte sur l'interface graphique et que tous les graphes s'affichent (ce qui n'a pas d'impact sur le trafic). On aurait eu des alarmes sans aucun doute si il était monté, même temporairement, à 100% et si ton fg est multicpu : on n’a pas l’info précise par CPU. Ma supposition est que tu avais une saturation CPU. (bis) Je reviens sur cette supposition, pendant l'attaque la charge CPU était environ 20-25% supérieure à l'habitude. Pour un firewall qui a 4 CPU, la valeur est troublante. J'aurais donc le CPU0 à 100% et les 3 autres qui ne font rien? Piste très intéressante. Gautier AVRIL De : frnog-requ...@frnog.org [frnog-requ...@frnog.org] de la part de Stéphane C. [papa...@gmail.com] Envoyé : jeudi 20 novembre 2014 15:41 À : frnog@frnog.org Objet : Le: [FRnOG] [TECH] Comportement étrange Firewall / routeur Bonjour Gautier, Quand tu parles de « désactiver un vdom » : tu as fait quoi exactement ? Tu n’as pas indiqué non plus le modèle du FG et les features activés. L’idéal aurait été d’avoir une capture du trafic envoyé par le serveur pour comprendre ce qui s’est passé. Ma supposition est que tu avais une saturation CPU. Quand tu dis que la charge cpu est passée à 40%, l’info n’est pas précise parce que je suppose que c’est une moyenne (tu peux avoir des pics à 100% qui disparaissent de tes graphes) et si ton fg est multicpu : on n’a pas l’info précise par CPU. Tu peux avoir des CPU qui pioncent et un CPU qui sature … il suffit que le CPU qui sature soit le CPU qui gère le routage dynamique + processus kernel userspace (a priori cpu0) et c'est tout ton boitier qui trinque. Un problème courant serait que ton serveur attaqué génère du trafic qui nécessite d’être traité par le FW en CPU (le NPU envoi les interruption au même CPU sans les ventiler correctement. Si ce CPU est le cpu0 : tu impactes ta ha, ton routage dynamique et autres processus mgmt). La fragmentation, les tempêtes de broadcast, etc. sont par exemple traités en CPU. (Et je ne parle pas de L7) Commandes utiles : 1) #diag hardware sysinfo interrupts (pour voir les interruptions NPU = CPU et la répartition) 2) #conf sys npu #set dedicated-management-cpu enable #end (pour que les interruption NPU ne soient plus envoyées au CPU0 et n’impacte pas les processus « user-space et kernel » qui consomment le CPU0) Bon courage @+ Stephane CROISY --- Liste de diffusion du FRnOG http://www.frnog.org/ --- Liste de diffusion du FRnOG http://www.frnog.org/
RE: [FRnOG] [TECH] Cross connect et période initiale contractuelle
Cher Fabien, C'est exactement comme tu le décris. Mais maintenant y a un barbu dans l'équipe sur pa2... enfin. Thomas -Message d'origine- De : frnog-requ...@frnog.org [mailto:frnog-requ...@frnog.org] De la part de Fabien DEDENON Envoyé : jeudi 20 novembre 2014 16:16 À : frnog-t...@frnog.org Objet : [FRnOG] [TECH] Cross connect et période initiale contractuelle Hello, Mon employeur a une partie de ses infra hébergées chez Equinix (PA2) en sous location via un intermédiaire par lequel nous sommes tenus de passer pour toute prestation. Pour la première fois, nous devons faire par nous même la demande de cross connect fibre pour joindre un partenaire. A reception de la proposition commerciale de l’intermédiaire avec lequel nous travaillons, il aura sans surprise du fas et du recrurent sur cette prestation, mais a ma grande surprise, nous devons également nous engager un an sur cette prestation (c'est la politique contractuelle Equinix d'apres ce qu'on me dit). Il me parait vraiment étrange de devoir s'engager sur de la prestation 'filasse interne', savez vous comment ca se passe dans la vrai vie lorsqu'on travaille en direct avec Equinix? A vot' bon coeur. Fabien --- Liste de diffusion du FRnOG http://www.frnog.org/ --- Liste de diffusion du FRnOG http://www.frnog.org/
[FRnOG] [ALERT] Nerim is dead ?
Bonjour, L'opérateur Nerim viendrait-il de disparaitre de l'Internet ? Tous nos clients Nerim sont dans le rouge et leur site Web injoignable ... Eddy --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] - Blocage des requètes HTTP contenant un header X-Forwarded-For:
On 20/11/2014 13:39, Guillaume Rousseau wrote: Salut, Bonsoir Guillaume, Ne chaînerais-tu pas plusieurs proxy ? genre dansguardian+squid ? Si oui, je viens de vérifier, c'est ce qui semble déranger seloger.com. En paramétrant squid en transparent, le serveur web ne voit qu'une seule ip dans le champs X-Forwarded-For, et seloger.com fonctionne. En effet je chaine plusieurs proxy. Je n'ai pas ce souci sur Boursorama, testé à divers endroits, le souci n'aurait-il pas été corrigé depuis ? Boursorama a été très réactif pour corriger ce pb en effet. Je laisse la valeur par défaut, donc oui, honnêtement je m'en fiche un peu qu'un site distant puisse voir mon adressage interne, même si quelque part ça pourrait aider certains petits malins qui profiteraient de la crédulité d'un utilisateur pour obtenir plus vite une info afin d'effectuer une attaque plus ciblée... Bouais... À priori seul ce client a été impacté par ce souci, mais à l'avenir je vais garder un oeil là dessus, et si ça se généralise, passer l'option en mode transparent, ou même en delete si vraiment ils sont décidés à nous eder. Rejetez-vous les requètes dans lesquelles x forwarded for contient une IP RFC1918 ? Est-ce une appliance crypto-communisto-castratrice ? Là par contre je suis preneur d'info sur le pourquoi serait rejetée une IP RFC1918, j'aurais plutôt tendance à penser à des bugs de développeurs qui n'auraient par exemple dans mon cas pas pris en compte le fait que des proxy peuvent être chaînés, et apparaître dans le X-Forwarded-For, ou encore qui croient qu'une 1918 dans un X-Forwarded-For, saimal. Ou bien serait-ce des tentatives pour bloquer des attaques ou même des consultations de sites qui utiliseraient un chaînage de proxy ? Enfin celui qui fait ça avec des proxy bavards de X-Forwarded-For ne serait pas très malin... Ou alors ces IPs sont utilisés en interne par ces sites et les IPs sont filtrées dans le X-forwarded-for afin que l'on ne puisse pas prétendre être une machine interne depuis l'exterieur de leur réseau... mes 0.02€. --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [ALERT] Nerim is dead ?
Salut, Le 20/11/2014 16:57, Eddy Minet a écrit : L'opérateur Nerim viendrait-il de disparaitre de l'Internet ? Tous nos clients Nerim sont dans le rouge et leur site Web injoignable ... J'ai l'impression que c'est à l'AMS-IX que ça merdoie, les clients Nerim sont coupés de certaines choses (free et online pour seuls exemples que j'ai tout de suite mais pas que amha), mais d'autres choses sont ok (8.8.8.8 par exemple). J'ai même pas osé crée de ticket vu l'ampleur, on va attendre que ça remonte... ou pas... -- Guillaume Rousseau --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [ALERT] Nerim is dead ?
Je confirme ! :-( - Mail original - De: Eddy Minet eddy.mi...@rsi-informatique.fr À: frnog-al...@frnog.org Envoyé: Jeudi 20 Novembre 2014 16:57:33 Objet: [FRnOG] [ALERT] Nerim is dead ? Bonjour, L'opérateur Nerim viendrait-il de disparaitre de l'Internet ? Tous nos clients Nerim sont dans le rouge et leur site Web injoignable ... Eddy --- Liste de diffusion du FRnOG http://www.frnog.org/ --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [ALERT] Nerim is dead ?
Bonjour, Le 20/11/2014 16:57, Eddy Minet a écrit : Bonjour, L'opérateur Nerim viendrait-il de disparaitre de l'Internet ? Tous nos clients Nerim sont dans le rouge et leur site Web injoignable ... Eddy Je confirme : premiers symptômes à 16h44. --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [ALERT] Nerim is dead ?
Le 20/11/14 17:01, Guillaume Rousseau a écrit : J'ai même pas osé crée de ticket vu l'ampleur, on va attendre que ça remonte... ou pas... C'est remonté chez moi (toutes les sessions BGP on fait flip/flap) Laissons les bosser. -- Raphael Mazelier --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [ALERT] Nerim is dead ?
Bonjour, On Thu, 2014-11-20 at 15:57 +, Eddy Minet wrote: Bonjour, L'opérateur Nerim viendrait-il de disparaitre de l'Internet ? Tous nos clients Nerim sont dans le rouge et leur site Web injoignable ... En IPv4, il y a des problèmes apparamment. En IPv6 par contre, ca me semble OK (à première vue)... -- Clément Cavadore signature.asc Description: This is a digitally signed message part
Re: [FRnOG] [ALERT] Nerim is dead ?
Salut, Session BGP avec Nerim coupée sur l'Equinix-IX. Nerim injoignable via Cogent également. Ça merde à plusieurs endroits on dirait. Josselin Lecocq Quantic Telecom Le 20/11/2014 17:01, Guillaume Rousseau a écrit : Salut, Le 20/11/2014 16:57, Eddy Minet a écrit : L'opérateur Nerim viendrait-il de disparaitre de l'Internet ? Tous nos clients Nerim sont dans le rouge et leur site Web injoignable ... J'ai l'impression que c'est à l'AMS-IX que ça merdoie, les clients Nerim sont coupés de certaines choses (free et online pour seuls exemples que j'ai tout de suite mais pas que amha), mais d'autres choses sont ok (8.8.8.8 par exemple). J'ai même pas osé crée de ticket vu l'ampleur, on va attendre que ça remonte... ou pas... --- Liste de diffusion du FRnOG http://www.frnog.org/
RE: [FRnOG] [ALERT] Nerim is dead ?
Je confirme aussi. -Message d'origine- De : frnog-requ...@frnog.org [mailto:frnog-requ...@frnog.org] De la part de François Otho Envoyé : jeudi 20 novembre 2014 17:02 À : Eddy Minet Cc : frnog-al...@frnog.org Objet : Re: [FRnOG] [ALERT] Nerim is dead ? Je confirme ! :-( - Mail original - De: Eddy Minet eddy.mi...@rsi-informatique.fr À: frnog-al...@frnog.org Envoyé: Jeudi 20 Novembre 2014 16:57:33 Objet: [FRnOG] [ALERT] Nerim is dead ? Bonjour, L'opérateur Nerim viendrait-il de disparaitre de l'Internet ? Tous nos clients Nerim sont dans le rouge et leur site Web injoignable ... Eddy --- Liste de diffusion du FRnOG http://www.frnog.org/ --- Liste de diffusion du FRnOG http://www.frnog.org/ - Aucun virus trouvé dans ce message. Analyse effectuée par AVG - www.avg.fr Version: 2015.0.5315 / Base de données virale: 4213/8599 - Date: 20/11/2014 - Aucun virus trouvé dans ce message. Analyse effectuée par AVG - www.avg.fr Version: 2015.0.5315 / Base de données virale: 4213/8599 - Date: 20/11/2014 --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [ALERT] Nerim is dead ?
Le 20/11/2014 17:04, Clement Cavadore a écrit : Bonjour, On Thu, 2014-11-20 at 15:57 +, Eddy Minet wrote: Bonjour, L'opérateur Nerim viendrait-il de disparaitre de l'Internet ? Tous nos clients Nerim sont dans le rouge et leur site Web injoignable ... En IPv4, il y a des problèmes apparamment. En IPv6 par contre, ca me semble OK (à première vue)... Au début en tout cas, là l'IPv6 a l'air de merdouiller aussi -- Guillaume Rousseau --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [ALERT] Nerim is dead ?
Je confirme aussi. Le 20/11/2014 17:05, Josselin Lecocq a écrit : Salut, Session BGP avec Nerim coupée sur l'Equinix-IX. Nerim injoignable via Cogent également. Ça merde à plusieurs endroits on dirait. Josselin Lecocq Quantic Telecom Le 20/11/2014 17:01, Guillaume Rousseau a écrit : Salut, Le 20/11/2014 16:57, Eddy Minet a écrit : L'opérateur Nerim viendrait-il de disparaitre de l'Internet ? Tous nos clients Nerim sont dans le rouge et leur site Web injoignable ... J'ai l'impression que c'est à l'AMS-IX que ça merdoie, les clients Nerim sont coupés de certaines choses (free et online pour seuls exemples que j'ai tout de suite mais pas que amha), mais d'autres choses sont ok (8.8.8.8 par exemple). J'ai même pas osé crée de ticket vu l'ampleur, on va attendre que ça remonte... ou pas... --- Liste de diffusion du FRnOG http://www.frnog.org/ --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [ALERT] Nerim is dead ?
Le 20/11/2014 17:04, Raphael Mazelier a écrit : C'est remonté chez moi (toutes les sessions BGP on fait flip/flap) Laissons les bosser. Ici ça a l'air d'aller mieux à l'instant (17h20) -- Guillaume Rousseau --- Liste de diffusion du FRnOG http://www.frnog.org/
RE: [FRnOG] [ALERT] Nerim is dead ?
Ça revient de mon côté ... --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [ALERT] Nerim is dead ?
Pour moi, Paris est revenu, pas encore Bordeaux Le 20/11/2014 17:22, « Pierre Colombier » pcdw...@pcdwarf.net a écrit : Pour moi aussi , à 17H20 Le 20/11/2014 17:21, Guillaume Rousseau a écrit : Le 20/11/2014 17:04, Raphael Mazelier a écrit : C'est remonté chez moi (toutes les sessions BGP on fait flip/flap) Laissons les bosser. Ici ça a l'air d'aller mieux à l'instant (17h20) --- Liste de diffusion du FRnOG http://www.frnog.org/ --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [ALERT] Nerim is dead ?
Depuis la suisse on les voit “encore”: leur site marche bien, mais le traceroute s’arrête au DE-CIX traceroute to www1.nerim.net (195.5.228.3), 64 hops max, 52 byte packets 1 vpn-gw.lsn1.edsi-tech.com (185.50.188.33) 120.272 ms 138.661 ms 120.051 ms 2 br1.lsn1.edsi-tech.com (185.50.188.10) 132.452 ms 156.743 ms 143.113 ms 3 10gigabitethernet1-4.core1.zrh1.he.net (91.206.52.170) 134.973 ms 124.824 ms 125.068 ms 4 10ge15-2.core1.fra1.he.net (72.52.92.29) 137.226 ms 187.025 ms 132.575 ms 5 * * * 6 * * * 7 * * * 8 * * * 9 * * * On 20 Nov 2014, at 11:05, Fabien GARZIANO fabien.garzi...@groupe-ocealis.com wrote: Je confirme aussi. -Message d'origine- De : frnog-requ...@frnog.org [mailto:frnog-requ...@frnog.org] De la part de François Otho Envoyé : jeudi 20 novembre 2014 17:02 À : Eddy Minet Cc : frnog-al...@frnog.org Objet : Re: [FRnOG] [ALERT] Nerim is dead ? Je confirme ! :-( - Mail original - De: Eddy Minet eddy.mi...@rsi-informatique.fr À: frnog-al...@frnog.org Envoyé: Jeudi 20 Novembre 2014 16:57:33 Objet: [FRnOG] [ALERT] Nerim is dead ? Bonjour, L'opérateur Nerim viendrait-il de disparaitre de l'Internet ? Tous nos clients Nerim sont dans le rouge et leur site Web injoignable ... Eddy --- Liste de diffusion du FRnOG http://www.frnog.org/ --- Liste de diffusion du FRnOG http://www.frnog.org/ - Aucun virus trouvé dans ce message. Analyse effectuée par AVG - www.avg.fr Version: 2015.0.5315 / Base de données virale: 4213/8599 - Date: 20/11/2014 - Aucun virus trouvé dans ce message. Analyse effectuée par AVG - www.avg.fr Version: 2015.0.5315 / Base de données virale: 4213/8599 - Date: 20/11/2014 --- Liste de diffusion du FRnOG http://www.frnog.org/ smime.p7s Description: S/MIME cryptographic signature
Re: [FRnOG] [ALERT] Nerim is dead ?
Le 20 nov. 2014 à 16:57, Eddy Minet eddy.mi...@rsi-informatique.fr a écrit : Bonjour, L'opérateur Nerim viendrait-il de disparaitre de l'Internet ? Tous nos clients Nerim sont dans le rouge et leur site Web injoignable ... Bonsoir, Je confirme que nous avons rencontré un problème dans la VRF qui porte les routes Internet. Nous en cherchons la cause, mais nous savons déjà que l'origine n'est pas un changement de configuration d'un équipement, aucun commit ou clear quelconques n'ayant été effectués pendant les heures avant l'évènement. (Nous excluons donc l'erreur humaine.) Le plus gros de la coupure est liée au temps de re-convergence des PE portant la production des services faisant usage des routes de la DFZ d'Internet. -- Antoine Versini - Nerim --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] RE: [TECH] RFC 7404: Using Only Link-Local Addressing Inside an IPv6 Network
Le 20/11/2014 09:37, Michel Py a écrit : Toi qui connais DNS mieux que moi, veux-tu recréer la même connerie que nous avons aujourd'hui avec ce qui est presque une DDOS sur l'infra de demander des PTR pour 1.1.168.192.in-addr.arpa ? mets aussi 1.0.168.192.in-addr.arpa. Tu veux çà avec IPv6 ? Ca va juste faire quelques zones à rajouter dans AS112, ça parait pas mortel, si ? -- Jérôme Nicolle 06 19 31 27 14 --- Liste de diffusion du FRnOG http://www.frnog.org/
[FRnOG] [MISC] Quelqu'un a un bâillon ?
Plop, Je suppose que vous êtes nombreux à avoir reçu le répondeur automatique de Marie Colin ( a.k.a. https://www.linkedin.com/pub/marie-colin/37/789/202 ). Si quelqu'un d'EXA Technologies lis ça, ce serait sympa de traiter les mails envoyés au support et de couper son répondeur immédiatement. En attendant confirmation, je suggère la désinscription de la liste. Philippe, ton avis ? Le 20/11/2014 23:40, mco...@exatechno.com a écrit : Bonjour, Je suis absente jusqu'au 1er decembre 2014. Pour toute demande urgente, merci d'envoyer un mail à supp...@exatechno.com . Cordialement, Marie Colin -- Jérôme Nicolle 06 19 31 27 14 --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] RE: [TECH] RFC 7404: Using Only Link-Local Addressing Inside an IPv6 Network
On Thu, 2014-11-20 at 23:39 +0100, Jérôme Nicolle wrote: Ca va juste faire quelques zones à rajouter dans AS112, ça parait pas mortel, si ? Ouais, euh en fait, le plus mortel, ca serait d'arriver à les faire rajouter à *tous* les noeuds anycastés de l'AS112. Au risque de se retrouver avec des lame nameserver pour les noeuds non mis à jour... -- Clément Cavadore --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [MISC] Quelqu'un a un bâillon ?
Vu que je me suis aussi ramassé son autorépondeur, j’y vois pas d’objection. On 20 Nov 2014, at 17:53, Jérôme Nicolle jer...@ceriz.fr wrote: Plop, Je suppose que vous êtes nombreux à avoir reçu le répondeur automatique de Marie Colin ( a.k.a. https://www.linkedin.com/pub/marie-colin/37/789/202 ). Si quelqu'un d'EXA Technologies lis ça, ce serait sympa de traiter les mails envoyés au support et de couper son répondeur immédiatement. En attendant confirmation, je suggère la désinscription de la liste. Philippe, ton avis ? Le 20/11/2014 23:40, mco...@exatechno.com a écrit : Bonjour, Je suis absente jusqu'au 1er decembre 2014. Pour toute demande urgente, merci d'envoyer un mail à supp...@exatechno.com . Cordialement, Marie Colin -- Jérôme Nicolle 06 19 31 27 14 --- Liste de diffusion du FRnOG http://www.frnog.org/ smime.p7s Description: S/MIME cryptographic signature
