Re: [FRnOG] [TECH] max MTU sur ONT FTTH Orange
Bonjour Jérôme, 2017-03-30 10:54 GMT+02:00 Jérôme Nicolle : > 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 - --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] max MTU sur ONT FTTH Orange
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
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&id=59815 Dispo pour toute question, sarah -- Sarah Nataf - --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Vraie IP et fausse IP ?
Bonjour, 2016-02-16 13:42 GMT+01:00 Thomas Barandon : > > 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
Bonsoir, 2015-07-07 20:22 GMT+02:00 David Ponzone : > 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 :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 :100 ont pour prepend N fois ? (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 - --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Attaque DDoS avec SSDP uPNP sur le port 1900
2014-09-04 9:46 GMT+02:00 David Ponzone : > 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] Attaque DDoS avec SSDP uPNP sur le port 1900
Bonjour, 2014-09-04 4:20 GMT+02:00 Michel Py : > 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] Utiliser BGP pour se protéger des DDoS
2014-04-03 18:39 GMT+02:00 Tristan PILAT : > 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] [TECH] Utiliser BGP pour se protéger des DDoS
Bonjour, 2014-04-03 16:13 GMT+02:00 Tristan PILAT : > 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] Re: [MISC] Un cas d'utilisation d'un préfixe AfriNIC en dehors de l'Afrique
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 : > 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 Julien BREVIERE > > > 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] [MISC] [MICHU] Trolldi / phénomène étrange Orange end-user
Bonjour, 2012/11/16 Julien BREVIERE : > 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) je ne travaille pas sur la partie box / accès 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] [TECH] Rapport sur les sources de Mal, OVH fait son entrée dans le Top 10
2012/10/31 : > 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/9/5 Stephane Bortzmeyer : > 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] Re: [ALERT] Trouble dans la force ( soucis vers AS3215 )
2012/7/26 Richard DEMONGEOT : > 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] [ALERT] Trouble dans la force ( soucis vers AS3215 )
Hello,
2012/7/26 Raphael MAUNIER :
> 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: [TECH] Rapport sur la résilience de l'Internet en France
Bonjour, 2012/6/27 Raphaël Durand > 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/6/13 Jérôme Nicolle > 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/6/13 Jérôme Nicolle > 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/6/12 Arnaud Fenioux > 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 > (...) > > > 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: [TECH] augmentation table de routage BGP et gestion de celle-ci sur les routeurs
2012/1/16 Guillaume Barrot > Ca ressemble un peu à un Mpls vpn "acces internet" ton truc. > > Ca rappelle la solution de Paul Francis de "Virtual Aggregation" : http://www.cisco.com/web/about/ac123/ac147/archived_issues/ipj_13-1/131_aggregation.html J'attends que Stéphane nous poste une synthèse de http://tools.ietf.org/html/draft-ietf-grow-va-06 http://tools.ietf.org/html/draft-ietf-grow-va-auto-05 http://tools.ietf.org/html/draft-ietf-grow-simple-va-04 ... sarah --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] Re: Des soucis avec Tata sur PA2 ?
2011/11/7 Martin-Zack Mekkaoui > Faut en profiter pour faire une upgrade de vos versions non ? :) > 2011/11/7 Sylvain Busson > 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.
Bonjour, 2011/1/7 Laurent CARON : > 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/
