Re: [FRnOG] [TECH] max MTU sur ONT FTTH Orange

2017-03-30 Par sujet Sarah Nataf 
Bonjour Jérôme,

2017-03-30 10:54 GMT+02:00 Jérôme Nicolle <jer...@ceriz.fr>:

> Avant ça on pouvait bypasser la livebox avec une requête DHCP portant
> les options 77 et 90 appropriées, sur le VLAN832 au cul de l'ONT.
>
> Maintenant il semblerait que la requête elle même doive avoir un
> marqueur DSCP spécifique, ce qui n'est pas possible simplement sur la
> pluaprt des équipements.
>
> Est ce qu'on peut avoir le fin mot de l'histoire sur la façon de
> maintenir le bypass ?
>

Alors clairement : non. Mais je ne doute pas que l'intelligence collective
découvrira la ou les ingénieries à utiliser (d'ailleurs il me semble qu'il
y avait déjà des marquages DSCP sur les qq forums survolés).

Cordialement,
sarah
-- 
Sarah Nataf - <sarah.na...@gmail.com>

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

Re: [FRnOG] [TECH] max MTU sur ONT FTTH Orange

2017-03-30 Par sujet Sarah Nataf 
Bonjour,


Le 29 mars 2017 9:56 PM, "David Ponzone"  a écrit :


Par contre, j’ai toujours du mal à cerner où Orange a activé l’IPoE et où
ils sont encore en PPPoE.
J’ai un paquet de clients en FTTH Orange, par absence d'alternative, et ils
sont  tous en PPPoE.


Les pré-requis pour être en IPoE chez Orange sur FTTH = offre FTTH grand
public standard (i.e pas d'IPfixe) et pour ceux qui gardent la box il faut
une livebox 3 ou 4 (grand public, pas la LB pro).

Cdlt,
Sarah

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

[FRnOG] [JOBS] Orange recrute un(e) ingé réseau

2017-02-01 Par sujet Sarah Nataf 
Hello,

Un poste est ouvert dans mon équipe en région parisienne : pour faire
l'ingénierie du réseau backbone et collecte d'Orange France fixe. Au menu :
de l'IP, du MPLS, L3VPN, L2VPN (les offres de gros !), peering, interco
avec les mobiles, du BNG... Et en bonus de très bonnes relations avec nos
supers équipes d'exploitation.

Tout est dans l'offre :
https://orange.jobs/jobs/offer.do?do=fiche=59815

Dispo pour toute question,
sarah
-- 
Sarah Nataf - <sarah.na...@gmail.com>

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

Re: [FRnOG] [TECH] Vraie IP et fausse IP ?

2016-02-16 Par sujet Sarah Nataf 
Bonjour,

2016-02-16 13:42 GMT+01:00 Thomas Barandon <t.baran...@gmail.com>:

>
> Pour Orange, c'est en cours (et absolument pas secret).
> H2 2016 pour la totalité des clients FTTH.
> 2017 pour la totalité du parc ADSL.
>

Attention, ce qui est confirmé c'est bien T1 2016 pour VDSL + FTTH. Par
contre il n'y aura jamais la totalité du parc ADSL en 2017, comme toujours
il y a du parc très hétérogène à traiter et surtout une grosse partie de
legacy malheureusement incompatible.

Cdlt,
-- 
Sarah Nataf

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

Re: [FRnOG] [TECH] AS prepend contrôlé par le tag d'une route statique sur Cisco

2015-07-07 Par sujet Sarah Nataf 
Bonsoir,

2015-07-07 20:22 GMT+02:00 David Ponzone david.ponz...@gmail.com:

 Amis de BGP,

 je réfléchis à un moyen de décider de faire un prepend d’AS vers un peer
 eBGP (les 2 peers sont des AS privés que je gère) qui soit conditionné par
 la présence d’un tag sur la route statique vers un client.



 ip route 10.10.10.0 255.255.255.0 10.0.0.1 tag 100
 je voudrais que le routeur annonce 10.10.10.0/24 avec un prepend au peer
 eBGP.

 Voilà où j’en suis:
 -à priori, impossible de faire un prepend avec une route-map au moment du
 redistribute static. La route statique est toujours importée dans la table
 BGP locale avec un as-path vide.


Effectivement, le prepend est appliqué lorsque la route sort de l'AS, elle
ne peut pas être interne avec son propre numéro d'AS dans l'AS_PATH.


 -j’ai bien pensé à localpref, mais l’IOS refuse une route-map out qui fait
 un match sur le localpref (WTF!)

 Ce que je n’ai pas encore essayé: redistribute static avec une route-map
 qui match le tag pour remettre un tag dans la table BGP locale, et ensuite
 tester ce tag au moment de l’annonce pour faire le prepend, mais à lire
 certains sites/blogs, j’ai l’impression que ce n’est pas possible.


C'est pourtant une méthode standard :
 - à la redistribution static2BGP, toutes les statiques ayant le tag 100
sont marquées avec une communauté BGP asinterne:100 par exemple
 - lors de l'annonce en eBGP vers tels peers, la politique de routage
d'export vers le peer a une entrée qui spécifie que toutes les routes
matchant le tag BGP asinterne:100 ont pour prepend N fois asinterne ?
(et on en profite au passage pour supprimer la communauté si le peer eBGP
n'a pas besoin de ces marquages purement internes)

Cdlt,
sarah
-- 
Sarah Nataf - sarah.na...@gmail.com

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

Re: [FRnOG] [TECH] Attaque DDoS avec SSDP uPNP sur le port 1900

2014-09-04 Par sujet Sarah Nataf 
Bonjour,

2014-09-04 4:20 GMT+02:00 Michel Py mic...@arneill-py.sacramento.ca.us:

 Est-ce que quelqu'un de l'autre coté de la mare voit venir récemment des
 DDoS utilisant SSDP uPNP sur le port 1900 ? Je viens d'en voir une passer,
 ni mieux ni pire que d'habitude mais çà semble être la dernière mode ici.


Effectivement on en voit pas mal passer depuis début août ici : qq pics
entre 5 et 10Gb/s quasi-quotidiens, une pointe à 20Gb/s.
-- 
sarah

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

Re: [FRnOG] [TECH] Attaque DDoS avec SSDP uPNP sur le port 1900

2014-09-04 Par sujet Sarah Nataf 
2014-09-04 9:46 GMT+02:00 David Ponzone david.ponz...@gmail.com:

 5-10Gbps, c’est la BP que ça te prendre réellement, ou ce que ça aurait
 pris si tu avais pas filtré ?


C'est ce que je vois sur les sondes de détection DDOS de l'upstream.
-- 
sarah

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

Re: [FRnOG] [TECH] Utiliser BGP pour se protéger des DDoS

2014-04-03 Par sujet Sarah Nataf 
Bonjour,

2014-04-03 16:13 GMT+02:00 Tristan PILAT tristan.pi...@gmail.com:

 Bonjour,

 La première consistant lors d'une attaque sur une IP précise à annoncer un
 préfix /32 à son fournisseur de trafic via une communauté BGP pour
 blackholer le trafic vers cette IP. Cette méthode semble fonctionner et a
 (...)
 Je me pose en revanche une question; si l'on dispose de deux voisins BGP
 (deux fournisseurs de trafic) et que lors d'une attaque DDoS on identifie
 le lien par lequel l'attaque arrive, on annonce alors à ce voisin BGP en
 particulier notre IP à blackholer. L'attaque sera-t-elle forcément
 re-dirigée dans les mêmes proportions vers l'autre lien ? (j'aurais envie
 de dire oui)


Il faut distinguer la signalisation (BGP) et le trafic. Lorsque le filtrage
du /32 est pris en compte par AS1, le trafic est jeté sur l'AS1. Par contre
côté signalisation BGP : on suppose que l'échange du /32 est local à AS1 et
son client (on ne redistribue pas plus petit que /24 entre 2 AS sauf accord
explicite type celui-ci), donc vu du reste de l'Internet il n'y a aucun
changement dans les routes (la signalisation) = a priori aucune raison que
le trafic soit rerouté vers d'autres chemins. Ainsi l'attaque DDOS n'a pas
de raison d'être redirigée sur l'autre lien.


 En faite j'aimerais que tout ça me soit confirmé.


Pour le reste OK dans les grandes lignes !

Cdlt,
-- 
sarah

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

Re: [FRnOG] [TECH] Utiliser BGP pour se protéger des DDoS

2014-04-03 Par sujet Sarah Nataf 
2014-04-03 18:39 GMT+02:00 Tristan PILAT tristan.pi...@gmail.com:

 Le 3 avril 2014 18:10, Sarah Nataf a écrit :

 2014-04-03 16:13 GMT+02:00 Tristan PILAT :

 Je me pose en revanche une question; si l'on dispose de deux voisins BGP
 (deux fournisseurs de trafic) et que lors d'une attaque DDoS on identifie
 le lien par lequel l'attaque arrive, on annonce alors à ce voisin BGP en
 particulier notre IP à blackholer. L'attaque sera-t-elle forcément
 re-dirigée dans les mêmes proportions vers l'autre lien ? (j'aurais envie
 de dire oui)


 Il faut distinguer la signalisation (BGP) et le trafic. Lorsque le
 filtrage du /32 est pris en compte par AS1, le trafic est jeté sur l'AS1.
 Par contre côté signalisation BGP : on suppose que l'échange du /32 est
 local à AS1 et son client (on ne redistribue pas plus petit que /24 entre 2
 AS sauf accord explicite type celui-ci), donc vu du reste de l'Internet il
 n'y a aucun changement dans les routes (la signalisation) = a priori
 aucune raison que le trafic soit rerouté vers d'autres chemins. Ainsi
 l'attaque DDOS n'a pas de raison d'être redirigée sur l'autre lien.


 Merci pour la réponse !

--  --  --
| AS5 |--| AS6 |--| AS7  |
-   -   --
|   ||
-   -   --
| AS2|---| AS3 |--| AS4  |
-   -   --
\  /
 \/
  -
  | AS1|
  -

 Pour clarifier, dans le cas présent par exemple, si l'AS1 constate qu'il
 est attaqué sur le lien AS3 sur l'IP 1.2.3.4, il envoie alors son préfixe
 /32 à blackholer à l'AS3. Supposons que les IP utilisées pour attaquer
 l'IP 1.2.3.4 proviennent de l'AS5, l'AS6 et l'AS7, en quoi est ce que le
 trafic blackholé par L'AS3 ne serait-il pas redirigé vers l'AS2 pour
 arriver sur l'IP 1.2.3.4 dans l'AS1 ?


Mettons que AS1 annonce 1.2.3.0/24 vers l'Internet, et que AS5, 6 et 7
préfèrent la route via AS3 : tout le trafic provenant de ces AS et à
destination du /24 arrive sur AS3, qui l'achemine vers AS1 via son lien
direct.
Si AS1 annonce un /32 à blackholer à AS3, AS3 ne redistribue pas ce /32 :
il n'y a donc aucun changement BGP pour l'annonce du /24 vu des AS 2 à 7.
Donc, tout le trafic à destination du /24 de AS5, AS6 et AS7 arrive
toujours sur AS3 : AS3 jette les paquets à destination de la /32 et
continue à acheminer le reste. Il n'y a pas de redirection automatique de
l'attaque.

Avec le même raisonnement, si l'on fait cette fois-ci l'hypothèse que 30%
du trafic arrive par le lien AS2-AS1 et 70% par AS3-AS1 lors de l'attaque,
et bien via le blackhole sur AS3, 70% du trafic DDOS sera jeté (celui via
AS3) et 30% de l'attaque arrivera toujours sur AS1 (via le lien AS2-AS1).
Toujours pas de redirection de l'attaque, car vu de l'Internet
(AS2,4,5,6,7), il n'y a aucun changement de chemin vers 1.2.3.0/24. Seul
AS3 connaît la plus spécifique, et pour lui la destination c'est /dev/null.

-- 
sarah

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

Re: [FRnOG] Re: [MISC] Un cas d'utilisation d'un préfixe AfriNIC en dehors de l'Afrique

2013-02-19 Par sujet Sarah Nataf 
Bonjour,

[Enfin retrouvé un PC, ça sera plus simple que via twitter]

Comme signalé par Radu, ce sont des blocs ERX, cf.
http://www.ripe.net/lir-services/resource-management/erx/completed-transfers/transfer-of-networks-in-154-8

(Le 154.1.0.0/16 va te plaire Stéphane, il était historiquement
chez... Goldman Sachs :)

2013/2/19 Stephane Bortzmeyer bortzme...@nic.fr:
 Si. Mauvaise migration d'un préfixe historique vers AfriNIC. Cela va
 être compliqué lorsqu'AfriNIC commencera à allouer dedans... Déployer
 la RPKI ou bien un marché d'adresses IP là-dedans va être coton.

D'où mes réactions à ton article. Quand tu évoques le
vol/détournement, ou que tu écris que personne n'est titulaire de ces
préfixes, ce n'est pas si simple : d'après les RIR les transferts ont
bien été effectués ?

Cdlt,
-- 
sarah


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

Re: [FRnOG] [MISC] [MICHU] Trolldi / phénomène étrange Orange end-user

2012-11-16 Par sujet Sarah Nataf 
Bonjour,

2012/11/16 Julien BREVIERE r...@supramoteur.com:
 Bonjour à tous,

(...)
 L'IP WAN (donc normalement une IP routable. si j'en crois mes 15 ans
 d'expérience) attribuée
 par Orange est d'un jour a l'autre devenue non routable ..

 En gros ils m'attribuent une IP RFC1918 ... et le pire c'est que j'ai encore
 (TRES lentement) de l'accès
 à Internet

 Est-ce bien raisonnable ? normal ?
 - d'une part d'attribuer une IP WAN sur un bloc RFC1918 (par exemple la
 j'ai : 172.17.49.64 ...)
 - que l'internet passe encore (!!!) ?

 Et ca pousse le vice jusqu'à m'indiquer que pour l'administration à
 distance ... l'url a utiliser
 est http://172.17. (sic)

disclaimer je ne travaille pas sur la partie box / accès /disclaimer

Mmm, ça me semble louche. Etes-vous sûr de regarder l'adresse WAN
attribuée pour le service Internet et non celle du service Vidéo ou
autre ? Il n'y a pas de NAT 444 dans le réseau, donc je ne vois pas
très bien comment la navigation Internet serait possible... :-)

Cdlt,
-- 
sarah


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

Re: [FRnOG] [MISC] [MICHU] Trolldi / phénomène étrange Orange end-user

2012-11-16 Par sujet Sarah Nataf 
2012/11/16 Julien BREVIERE r...@supramoteur.com


 Non non c'est bien la bonne a priori
 ci-dessous, copié collé de la page Configuration / Informations système :
(...)

Comme vu en privé avec Julien --et pour stopper les fantasmes sur le
NAT 444-- c'est donc la plage réservée aux accès spécifiques, comme
par exemple les lignes en litige de paiment ou aux diagnostics
particuliers.

Cdlt / bon week-end,
sarah


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

Re: [FRnOG] [TECH] Rapport sur les sources de Mal, OVH fait son entrée dans le Top 10

2012-10-31 Par sujet Sarah Nataf 
2012/10/31  o...@ovh.net:
 On Wed, Oct 31, 2012 at 12:29:40PM +0100, Stephane Bortzmeyer wrote:
 Le rapport HostExploit 2012 sur les plus grandes sources de Mal de l'Internet

 puisqu'on me pose la question (ça fait vendre
 de mettre ovh dans les url/subject ?)

(snip) merci pour les infos sur les récentes évolutions.

Mais c'est vrai que le titre est trompeur, OVH a souvent (toujours?)
figuré dans le top10 de HostExploit --aucun jugement de valeur, c'est
juste un fait-- et de ce fait la France y est souvent très bien
classée \o/

sarah


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

Re: [FRnOG] [TECH] Quelles machines pinguer pour vérifier sa connectivité Internet ?

2012-09-06 Par sujet Sarah Nataf 
2012/9/5 Stephane Bortzmeyer bortzme...@nic.fr:
 Je crois que c'est une question qui concerne directement les
 opérateurs réseau (j'ai cité Free pour les exemples mais cela n'a rien
 de spécifique à Free). Avis bienvenus.

 http://www.bortzmeyer.org/que-pinguer.html

Tu parles de ping, as-tu envisagé l'echo plus UDP ? e.g.
http://www.broadband-forum.org/technical/download/TR-143.pdf

Cdlt,
sarah


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

Re: [FRnOG] [ALERT] Trouble dans la force ( soucis vers AS3215 )

2012-07-26 Par sujet Sarah Nataf 
Hello,

2012/7/26 Raphael MAUNIER rmaun...@neotelecoms.com:
 Hello,

 Si votre support explose car vos clients  n'arrivent plus à joindre une 
 partie de AS3215, c'est normal

 Un opérateur US vient de leaker une partie des routes Orange ( pas beaucoup, 
 c'est pour ça que c'est passé ) , et ça a fait un peu de dégats.

 L'impact pour nous était 25 minutes de soucis de routage. Certains opérateurs 
 n'ont pas encore résolu de leur coté.

Les premières alertes d'injoignabilité de préfixes 3215 sont tombées vers 9h44.
A priori erreur de conf de l'AS4565
(We had a mis-configuration (...)
We apologize for any problems/inconvenience that this caused.)

Un grand grand merci à Neo pour votre réactivité.

 PS : Et c'est parti pour un troll avec RPKI :)

[... SVP n'oubliez pas de modifier le titre du mail pour les trolls
habituels...]

Cdt,
sarah


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

Re: [FRnOG] Re: [ALERT] Trouble dans la force ( soucis vers AS3215 )

2012-07-26 Par sujet Sarah Nataf 
2012/7/26 Richard DEMONGEOT rich...@demongeot.biz:
 Concernant RPKI :
 Premier point :
 Orange n'a pas signé ses préfixes. Ils auront donc la même validation que
 les préfixes émis (erreur ou non) par un autre AS.

En fait si, il existe des ROAs pour une partie des préfixes de
l'AS3215 depuis quelques mois. Cependant, comme aucun AS n'applique
concrètement de filtres sur routes invalid --peut-être un AS d'après
le RIPE, sans doute pour du test/recherche--, elles ont été tout
autant touchées que les routes sans ROAs ou d'ailleurs que les routes
sans route-object.

Cdlt,
-- 
sarah


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

Re: [FRnOG] Re: [TECH] Rapport sur la résilience de l'Internet en France

2012-06-27 Par sujet Sarah Nataf 
Bonjour,

2012/6/27 Raphaël Durand raphael.dur...@ultrawaves.net

 On parle de la résilience de l'Internet français. Planter Internet à
 l'échelle mondiale est difficile, les réseaux aux USA me laissent rêveur,
 mais notre très jacobin Internet français me parait plus fragile.


Auriez-vous des liens (études, rapport) qui abordent cette question ?
J'entends sur la comparaison de la résilience de l'Internet entre zones
géographiques, pas forcément sur la France d'ailleurs.

Cdlt,
-- 
sarah

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

Re: [FRnOG] [TECH] Influence des bonnes pratiques sur les incidents BGP

2012-06-13 Par sujet Sarah Nataf 
2012/6/13 Jérôme Nicolle jer...@ceriz.fr

 Le 12/06/12 21:30, Sarah Nataf a écrit :
  Je suis notamment intéressée par tout outil qui
  permettrait d'élargir la détection des usurpations d'adresses

(...)


  Du coup, la première chose à faire serait une remise en cause
 individuelle de tous les réseaux représentés dans la salle, en se

 [ Euh, arrête le marketing on est sur la liste [TECH ] :) ]


 il est urgent d'y travailler sérieusement et que tous les opérateurs de
 la place co-financent le montage d'une infrastructure de collecte des
 tables et le développement des logiciels d'analyse.

 Qui lead ? Qui paye ? Et d'ailleurs, comment on fait ?
 Je te laisse bien volontiers les deux premières questions. Pour la


Ah au contraire tu sembles bien parti pour le blablah, c'est plutôt la
partie technique qui m'intéresse.


 troisième, j'ai des tas d'idées, mais elles risques de ne pas plaire. Un
 bon début est d'utiliser des groupements existants, comme le NLNog Ring,
 comme outil de diagnostic en temps réel.


Yes il faudrait que je creuse ce concept.

Ensuite on peut envisager de tous mettre en place des boites noires pour
 stocker tous les updates BGP émis et reçus, pour du forensic. Valeur
 ajoutée ? Nulle. Coût ? Ça va vite taper dans le gros SAN de plusieurs
 armoires. Ça commence bien.


On est d'accord. De plus il existe déjà de nombreux projets de collecteurs
de routes, sous diverses formes, pas besoin de réinventer la roue. Et ce
dont on a besoin en général ce sont de collecteurs éloignés au sens BGP
(genre pour superviser la plaque Asie, Amérique du Sud, etc), plutôt que de
collecteurs sur ses propres peers dont on reçoit directement les routes et
dont on peut plus facilement repérer les écarts.

Reste l'analyse de l'ensemble de ces updates collectés, qui n'auraient
 de sens que si ils sont bien recoupés entre elles, et qui demande
 d'intégrer un très très grand nombre de données contextuelles dont j'ai
 aucune idée de comment les collecter de façon fiable et universelle.

 Des suggestions ?


Idée sur une base différente : plutôt que collecter des updates BGP, RPKI
pourrait peut-être facilement compléter les outils existants, pour une
surveillance pas forcément en temps réel, et avec des petits moyens en
terme d'infrastructure car on ne partagerait que les alertes (encore
faut-il voir sous quelle forme)... ? Ca pourrait être un aspect à creuser,
encore faudrait-il que je trouve le temps de générer les premiers
certificats pour notre AS.

Cdlt,
-- 
sarah

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

Re: [FRnOG] [TECH] Influence des bonnes pratiques sur les incidents BGP

2012-06-13 Par sujet Sarah Nataf 
2012/6/13 Jérôme Nicolle jer...@ceriz.fr

 Le 13/06/12 14:39, Sarah Nataf a écrit :
  Idée sur une base différente : plutôt que collecter des updates BGP,
  RPKI pourrait peut-être facilement compléter les outils existants, pour
  une surveillance pas forcément en temps réel, et avec des petits moyens
  en terme d'infrastructure car on ne partagerait que les alertes (encore
  faut-il voir sous quelle forme)... ? Ca pourrait être un aspect à
  creuser, encore faudrait-il que je trouve le temps de générer les
  premiers certificats pour notre AS.

 Tu crois qu'on pourrait inclure ça dans la liste des best-practices ?
 Genre, avoir tous un ou plusieurs route-reflector accessible en
 eBGP-multihop sur simple demande ?


Ouille, une BCP qui imposerait le eBGP multihop, c'est clairement
antinomique... Ca ne va pas le faire...

Sinon sans partage des UPDATES ni des RIB, il y aurait peut-être moyen de
partager des alertes RPKI ? Même en temps différé ça permettrait d'avoir
une meilleure vision sur les AS qui annoncent tout et n'importe quoi.
-- 
sarah

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

Re: [FRnOG] [TECH] Influence des bonnes pratiques sur les incidents BGP

2012-06-12 Par sujet Sarah Nataf 
2012/6/12 Arnaud Fenioux afeni...@gmail.com

 merci!
 J espere que Nicolas Ruff a sorti qql phrases cultes cette année encore ;)


Tout ce qui se passe au SSTIC reste au SSTIC :)

Plus sérieusement si le hijacking BGP vous intéresse ou si vous avez des
astuces maisons pour superviser ces incidents n'hésitez pas à me trouver au
prochain FRnOG ! Je suis notamment intéressée par tout outil qui
permettrait d'élargir la détection des usurpations d'adresses, que ce soit
grâce à des points de monitoring un peu originaux (AS éloigné au sens BGP
mais dont on pourrait obtenir des RIB, outil d'historique de routes peu
connus), des mécanismes à créer (e.g. coopération entre AS pour partage
d'alertes RPKI), etc.

[J'allais ajouter : si vous ne savez pas qui je suis trouvez Mat_A mais
forcément c'est un des rares frnog auquel il n'est pas inscrit.]
-- 
sarah


 2012/6/12 Alexandre Archambault aarchamba...@corp.free.fr
 (...)
 
 https://www.sstic.org/media/SSTIC2012/SSTIC-actes/influence_des_bonnes_pratiques_sur_les_incidents_b/SSTIC2012-Slides-influence_des_bonnes_pratiques_sur_les_incidents_bgp-contat_valadon_nataf.pdf
 


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

Re: [FRnOG] Re: Des soucis avec Tata sur PA2 ?

2011-11-07 Par sujet Sarah Nataf 
2011/11/7 Martin-Zack Mekkaoui mar...@mekkaoui.fr

 Faut en profiter pour faire une upgrade de vos versions non ? :)


2011/11/7 Sylvain Busson bus...@nic.fr

 en court :-)

 Le 07/11/2011 16:38, Martin-Zack Mekkaoui a écrit :

 Faut en profiter pour faire une upgrade de vos versions non ? :)


Mais le pire c'est que ces versions sont très récentes. Et encore faut-il
que la version patchée --sortie il y a 1 mois ou 2 selon les versions
JunOS-- corrige bien ce comportement... La semaine va être longue pour
certains.

Cdlt,
-- 
sarah

Re: [FRnOG] Contact admin Orange Business/FT / Routage 46.21.120.

2011-01-07 Par sujet Sarah Nataf 
Bonjour,

2011/1/7 Laurent CARON lca...@unix-scripts.info:
 On Fri, Jan 07, 2011 at 05:15:35PM +0100, Raphael Maunier wrote:
 Généralement, il faut contacter ton opérateur directement :)

 Mon opérateur annonce bien le préfixe, mais certains opérateurs ne
 semblent pas accepter les paquets en provenance/à destination de ce
 subnet.

 $ traceroute 46.21.120.1
 traceroute to 46.21.120.1 (46.21.120.1), 30 hops max, 40 byte packets
  1  rv14lo-bidon.bstest06.Rennes.francetelecom.net (193.253.160.3)  42.452 ms 
  43.570 ms  44.540 ms
  2  80.10.245.1 (80.10.245.1)  45.957 ms !N  47.161 ms !N  48.610 ms !N
 $

 Une ACL pas à jour, ? :(

Ce préfixe ne semble pas non plus visible sur d'autres looking-glass :
---
Show Level 3 (San Francisco, CA) BGP routes for 46.21.120.0/24

No matching routes found for 46.21.120.0/24.
---

Il est bien accessible depuis l'AS 3215 d'habitude ? En tout cas les
upstreams ne semblent pas le recevoir non plus, donc on ne peut pas
faire grand chose...
-- 
sarah
---
Liste de diffusion du FRnOG
http://www.frnog.org/