Hello,

juste pour info, hier :

- Coupure entre 6h et 7h du matin
- 2 coupures l'après-midi
- 3 coupures entre 19h et 20h (la capture ci-dessous commence à la deuxième)
- 1 ce matin

A chaque fois, c'est très court 7 - 10 sec

Le signal fibre est bon voire très bon : down entre -15 et -16dBm / up env 2.2 dBm

J'ai l'impression d'avoir à faire à une régression suite aux travaux de maintenance réalisés le 31.03 entre 1h et 4h du matin.
Mon NRO n'était plus joignable, voir https://www.free-reseau.fr/cha74-5-FTTH

J'espère que ça se rétablisse vite et qu'on n'est pas (re)parti pour des semaines ou mois de galère...

oui ma vision est un peu optimiste je te l'accorde. Mais l'idée est que le coaxial à l'échelle nationale (je ne parle pas d'opérateurs locaux), se terminera le jour de la vente de SFR.
La vente "finale" de SFR se fera plusieurs mois après l'annonce des dernières modalités.
Pour moi, ça reste tout à fait envisageable que SFR envoie des courriers/mails dès l'annonce officielle de la vente et ferme des plaques de coaxial (3 mois plus tard par exemple) avant la date effective de la vente. Je ne pense pas que le délai de prévenance pour le coaxial soit contrôler par l'ARCEP comme pour le cuivre. 1 gros mois de préavis (45 jours pour être large niveau délai de courrier/autre) me semble légalement possible.
Car il y aura forcément une enquête des instances FR et EU pour la concurrence.
Je n'imagine pas que le réseau coaxial de SFR survive à la vente.

En tout cas, je n'ai vu aucun changement au niveau du ping par rapport aux services que j'utilise habituellement.

Je suis assez d'accord, mais c'est orthogonal avec le fait d'avoir un équipement qui fait du filtrage devant à mon sens.

bah au moins pour router :p

après ton paquet pour le filtrer faut l'avoir. Alors qu'il se crashe sur un unifi ou sur un serveur...

Pire que ça, c'est pour les DNS. Y a une attaque qui s'appuie sur le nombre de port possible pour la réponse. Et quand tu mets un firewall, au lieu de toute la plage des 65k - 1 ports de sortie t'as qu'un subset de port, et tu redeviens vulnérable à cette attaque.

En général si la table de contextes est pleine ca vide les plus anciens contextes, ou pire, ca discard les paquets entrant parfois legit. Et sans prévenir que la table est pleine. Ça tu t'en rends vite compte dans une entreprise c'est que ça se met à ne plus résoudre les noms et des fois oui.

Par contre sur l'OS en question tu peux utiliser des règles pour limiter les attaques d'amplification ou le nombre de réponse/sec vers une IP

un ACL sur un serveur ca remonte "haut" et dans des tables specifiques Si y a pas de service en écoute l'OS drope le paquet sans plus d'effort pour l'acheminer. Le seul truc c'est paramétrer l'OS pour ne pas répondre un ICMP port unreach (ca vaut aussi pour les firewalls)