Re: [FRnOG] [MISC] Recherche formation « crash course » BGP efficace en IdF
[ Mes questions & réponses sont dans le sens normal de lecture. ]
Le 07/09/2018, Michel Py a écrit :
| | de faire du troubleshooting BGP tout seul
|
| Ca n'existe pas. Le troubleshooting BGP, çà se fait avec le pair.
[...]
En effet et souvent dans la douleur.
En pratique le déminage de bouse avec le pair ça se ramène très souvent
au déminage « tout seul » (et à condition d'avoir plusieurs serveurs internes
dont les ébats sont soigneusement bloqués vers l'Internet) suivi de diplomatie
avec le pair pour lui faire un cours mais sans en avoir l'air.
Le plus pénible dans l'affaire c'est le système de gestion de tickets
d'incidents du pair qui souvent ne gère pas du tout les réponses
par courriel et oblige à faire des tonnes de copier-coller dans leur interface
web propriétaire à tendance sado-maso.
Lorsque ce déminage concerne le voisin en amont de ton pair :
mon AS BGP --- AS de mon FAI --- AS au dessus
je te raconte pas les tortures de diplomatie qu'il faut endurer pour arriver
à ce que ton pair fasse redresser une configuration de son AS au dessus.
Ex. pratique : l'AS au dessus a décidé qu'il n'annonce pas les routes
pour des blocs plus petits qu'un /24, pour tenir les perf. sans avoir à
muscler ses routeurs.
--
« Je reste optimiste. La vie m'a appris qu'avec le temps
le progrès l'emporte toujours. »
Simone Veil
daniel Azuelos
---
Liste de diffusion du FRnOG
http://www.frnog.org/
Re: [FRnOG] [MISC] Re: Equinix et le rafraîchissement des clients pendant la canicule
[ Mes questions & réponses sont dans le sens normal de lecture. ] Le 24/09/2018, David Ponzone a écrit : | Bon et bien Equinix a fermé la piscine. | Autrement dit, les fuites ont été colmatées. L'important n'est pas le colmatage mais l'analyse et la maîtrise des origines de fuites. Un colmatage trop loin d'une fuite créée un risque à retardement et en général bien plus brutal (le colmatage lache comme un barrage). | D’ailleurs, j’ai une question pour les pros du DC et de l’infra. | Quand on achète un bâtiment existant pour en faire un DC, on fait comment pour vérifier le risque d’infiltration par le toit ? On ne fait pas de vérification d'infiltration par le toit. On fait une évaluation globale du risque dégâts des eaux. Par exemple ça peut venir d'ouverture extérieure, de descentes EP ou EU, de colonne d'alimentation en eau, d'une colonne sèche, de canalisation d'alimentation de Sprinklers, de WC qui débordent, de traversée de dalle béton mal étanchée par n'importe quelle canalisation (attention ceci est aussi un risque de propagation d'incendie) : une colonne d'alimentation, une gaine de VMC, n'importe quelle descente. | Il y a des méthodes pour « radiographier » la structure à la recherche d’anomalies avant de signer, ou alors on signe, on fait le DC et on attend la première grosse pluie ? Oui avec un générateur de fumée en fermant toutes les ouvertures extérieures. Si la fumée passe à l'étage supérieur ou bien sort par le toit, il y a un risque dégâts des eaux à rechercher, analyser et supprimer. Une inspection visuelle suffit souvent pour identifier les plus gros risques. Enfin un relevé des compteurs d'eau en pied de bâtiment un soir après que tout le monde soit sorti, puis comparaison avec le même relevé le lendemain matin avant le 1er arrivé permet de détecter des fuites cachées en dalle béton qui ne se manifesteront que tardivement mais très brutalement. Trivialité qu'il peut être utile de répéter : il vaut mieux faire cette enquête avant de signer l'acte de vente. -- « Je reste optimiste. La vie m'a appris qu'avec le temps le progrès l'emporte toujours. » Simone Veil daniel Azuelos --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [MISC] la porte dérobée des serveurs Supermicro
[ Mes questions & réponses sont dans le sens normal de lecture. ]
Le 05/10/2018, Philippe Bourcier a écrit :
> Les gens qui auraient fait ça se seraient donc autant embêté pour
> accéder au réseau OOB de leurs victimes (la BMC elle est reliée à un
> réseau OOB, on est d'accord)... réseau OOB qui aurait donc accès à
> Internet.
> Je sais pas vous, mais chez moi un OOB n'a pas accès à Internet...
> Ca semble être une règle minimale de sécurité.
[...]
Les entreprises qui ont externalisé l'administration de leur parc de
serveurs doivent connecter leur réseau dédié d'admin. (IPMI...) à
l'Internet, moyennant un filtrage (plus ou moins) bien serré.
Et vu le nombre qu'on en voit sur Shodan, la pratique fait fureur.
D'ailleurs sans externalisation, le réseau d'admin. est accessible
indirectement. On ne va pas tous en doudoune en salle serveur pour
intervenir sur le réseau d'admin..
--
« Je reste optimiste. La vie m'a appris qu'avec le temps
le progrès l'emporte toujours. »
Simone Veil
daniel Azuelos
---
Liste de diffusion du FRnOG
http://www.frnog.org/
Re: [FRnOG] [MISC] Client Wifi...
[ Mes questions & réponses sont dans le sens normal de lecture. ]
Le 30/10/2018, Jérôme Quintard a écrit :
> Je cherche un produit miracle, pas cher, qui éventuellement
> s'auto-provisionne en TFTP (il m'en faut près de 500) pour fournir un accès
> Wifi à un matériel.
Le matériel en question a-t-il un port USB, un OS pour lequel existe un
pilote 802.11n ou 802.11ac et un client 802.1X ?
--
« Je reste optimiste. La vie m'a appris qu'avec le temps
le progrès l'emporte toujours. »
Simone Veil
daniel Azuelos
---
Liste de diffusion du FRnOG
http://www.frnog.org/
Re: [FRnOG] [MISC] Truc etrange avec une LB4 et les DNS....
[ Mes questions & réponses sont dans le sens normal de lecture. ]
Le 28/11/2018, Samuel PIRON a écrit :
[...]
> Étonnamment, passer les requêtes DNS sur du TCP résolvaient le
> problème...
>
> Je suspecte qu'ils font de l'interception ou de la limitation du trafic
> DNS, peux-tu être pour éviter les attaques DDoS venant de leur réseau ?
>
> Peux tu tester avec un "+tcp" dans ta requête dig ?
Un simple écrasement UDP peut aussi être mis en évidence avec cette option.
Suggestion : au moment de l'absence de réponse, faire une vérification
différentielle :
dig +notcp ... & dig +tcp ...
--
« Je reste optimiste. La vie m'a appris qu'avec le temps
le progrès l'emporte toujours. »
Simone Veil
daniel Azuelos
---
Liste de diffusion du FRnOG
http://www.frnog.org/
Re: [MISC] [FRnOG] [MISC] Question relative au protocoles utilisés par Mikrotik en Wifi
[ Rédigé dans le sens de lecture professionnel.
Written in the professional reading direction. ]
Le (on) 18/04/2020, Oliver varenne a écrit (wrote):
| Oui depuis au moins septembre dernier. Peut être même aout.
| C'est arrivé soudainement. Pouf.
|
| En gros je viens de tester:
| Je passe en Nstreme sans rien changer aux autres paramètres
| Meme pas 40 secondes apres la connexion: déconnexion avec l'erreur "Extensive
data loss"
|
| Et la, il est 02h54 am... donc le télétravail ne rentre pas en ligne de compte
Si, parce que M. Toutlemonde laisse des pages web actives ouvertes et
ne pense pas à couper Wi-Fi, Bluetooth (2,4 GHz uniquement)...
Si tu as 1 Mac, installe iStumbler 103 et fait un scan des canaux en 5 GHz,
idéalement à proximité des 2 antennes puis sur le trajet (au sol
malheureusement).
| Ecoute, on va pas chercher. Si rien ne vous viens à l'esprit tant pis
| Vais rester en NV2, ça a l'air de tenir et le débit reste plus que correct
comparé à l'ADSL.
Est-ce que ton câble d'antenne aurait pu être touché (un voisin bricoleur,
un oiseau) ?
Est-ce qu'un élément réfléchissant aurait pu s'introduire dans le paysage
radio créant de l'auto-interférence (genre plaque de tôle derrière l'une
des antennes) ?
--
« The ultimate tragedy is not the oppression and cruelty
by the bad people but the silence over that by the good people. »
Martin Luther King Jr.
daniel Azuelos
---
Liste de diffusion du FRnOG
http://www.frnog.org/
