Re: [FRnOG] [MISC] Panne SFR

2019-12-14 Par sujet Franck LABBE 
Hello,

RAS en savoie sur les mobiles...


Le sam. 14 déc. 2019 à 19:09, SIMANCAS Hugo <
hugo.siman...@data-expertise.com> a écrit :

> Bonsoir,
>
> N'y a t il pas une panne géante sur SFR mobile ? Blackout sur une partie
> de la Lozère.
>
> Hugo
>
> Sent from Nine
>
>
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/
>

---
Liste de diffusion du FRnOG
http://www.frnog.org/

[FRnOG] [MISC] Panne SFR

2019-12-14 Par sujet SIMANCAS Hugo 
Bonsoir,

N'y a t il pas une panne géante sur SFR mobile ? Blackout sur une partie de la 
Lozère.

Hugo

Sent from Nine


---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [TECH] Réduction considérable des bogons de Team Cymru

2019-12-14 Par sujet Patrick Maigron 
Bonjour,

C'était une hypothèse que tu faisais Philippe non ?

J'ai un peu fouillé dans les fichiers de statistiques du RIPE et j'ai
l'impression que ça vient bien de là.

Team Cymru doit se baser sur les plages d'adresses "available" (libres
pour enregistrement futur, donc à filtrer comme bogons).

Le nombre de ranges "available" en début de mois :
01-sept 2476
01-oct 2484
01-nov 1815
01-dec 0

Il a baissé de 2500 entre début octobre et début décembre, ça doit
expliquer une grosse partie de la chute des fullbogons de Team Cymru.

En regardant par taille de range, on a pour les plus nombreux :
01-sept
846 ranges de 512
   1315 ranges de 256

01-oct
851 ranges de 512
   1317 ranges de 256

01-nov
218 ranges de 512
   1589 ranges de 256

01-dec
0

Le pool contenait en gros 2200 ranges de petite taille /24 et /23
jusqu'à fin septembre. En octobre le RIPE a distribué la majorité des
/23, et en novembre il a fini les /23 et a distribué les /24 jusqu'à
avoir épuisé tous les ranges "available".

Jusqu'à octobre on n'avait pas trop de mouvement dans fullbogons parce
qu'on distribuait des /22, on ne touchait pas aux ranges plus petits
dans le pool. Et les /22 qu'on distribuait entraient temporairement dans
le pool (après abandon par un LIR ou en provenance de l'IANA) mais
étaient ré-alloués toute de suite, donc peu d'incidence sur les bogons.
Normalement les ranges récupérés d'un LIR passent d'abord en quarantaine
avant d'être ré-alloués, mais ils sont dans un stock à part (indiqués
comme reserved et pas available) donc pas d'incidence sur les bogons non
plus.

Maintenant il reste à attendre que les autres régions soient dans le
même état que RIPE et on aura un fichier fullbogons qui deviendra
identique au fichier des bogons simples (modulo les ranges qui passent
temporairement dans le pool avant ré-allocation)...

A+,

Patrick.


Le 14/12/2019 à 05:07, Michel Py a écrit :
> Bonsoir Philippe,
> 
>> Philippe Bourcier a écrit :
>> Ils ont vu que le RIPE disait que c'était fini chez eux et ils ont check 
>> leurs bogons et trouvé plein de
>> networks RIPE. Du coup ils ont trouvé un bug dans un de leur script, qu'ils 
>> ont re-run et bim...
> 
> Merci, est-ce que tu peux dévoiler tes sources ?
> (c'est trolldi, je suis trop fainéant pour chercher).
> 
> Michel.


---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [TECH] Problème MTU sur Nexus 3064Pq

2019-12-14 Par sujet Jeremy 

Bonjour,

Après un reload du switch qui pose problème, la MTU est ok.
Donc sachez le, sur certaines version de NXos, pas besoin de reload, 
mais en version 6 rev 5 et inférieur, il faut reload. Pas besoin sur les 
versions supérieures.


Excellent week end à tous,

Jérémy

Le 14/12/2019 à 00:38, Jeremy a écrit :
On me glisse à l'oreille via un gazoulli qu'il faut impérativement 
reload le switch en cas de changement de la Qos MTU à la volée.

Bon bah caramba, on va prévenir les clients !

J'indiquerais si cela résoud le problème ou non.

Le 13/12/2019 à 22:45, Jeremy a écrit :

Bonjour les amis,

Je viens ici pour trouver conseil sur un problème de MTU sur lequel 
je m'arrache les cheveux.
La typologie du réseau est simple. Un lien de transport L2L 
transparent opéré par TDF entre Lille et Valenciennes.

Tous les équipements sont des Nexus 3064PQ.

Le chemin fait :
Nexus Lille > Nexus Valenciennes > Nexus Marly > Nexus Anzin

Sur cette liaison, la MTU doit être à 9216 octets. J'ai pu 
l'appliquer sur tous les switchs sauf celui de Marly qui refuse 
toujours d'appliquer la Qos.


En conf, j'ai appliqué ces commandes :
policy-map type network-qos jumbo
  class type network-qos class-default
    mtu 9216
system qos
  service-policy type network-qos jumbo

Sans effet sur les ports.
J'ai donc appliqué une autre méthode glané sur le net, qui consiste à 
enlever le Trunk du port, passer un "no switchport", puis un "mtu 
9216" puis repasser le port en mode Trunk. Ca a fonctionné sur celui 
de Valenciennes qui était récalcitrant aussi. L'interface devrait me 
dire ça (sur le switch de Valenciennes) :


Ethernet1/48 is up
 Dedicated Interface
  Hardware: 100/1000/1 Ethernet, address: fc5b.39xx. (bia 
fc5b.39xx.)

  Description: Core: xxx-LILLE-to-MARLY59-xxx
  MTU 9216 bytes, BW 1000 Kbit, DLY 10 usec

Mais elle me dis ça sur le switch de Marly:

Ethernet1/48 is up
 Dedicated Interface
  Hardware: 100/1000/1 Ethernet, address: 6412.25xx. (bia 
6412.25xx.)

  Description: Core: xxx-LILLE-via-NEXUS-3K-xxx
  MTU 1500 bytes, BW 1000 Kbit, DLY 10 usec

Même version d'Os sur les deux switch :
Software
(...)
  system:    version 6.0(2)U6(8)

Difficile de faire beaucoup de tests (shutdown, reload) car c'est en 
prod, et il faut shutdown tout le trafic et c'est pas toujours 
évident...
Est ce que quelqu'un aurait une idée lumineuse qui résoudrait ce 
casse tête ?


Merci !
Jérémy


---
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/