Re: [FRnOG] [TECH] Orange / ROA invalide 90.1.128.0/17
Bonsoir, Je confirme aussi que le problème a été résolu, la rpki a été mis à jour. Les prefixes sont de nouveau visible depuis Cogent, Telia, Tata. Merci à ceux qui sont intervenus chez Orange :) Cordialement, Alexandre BATON > Le 23 mars 2020 à 22:23, Gary BLUM via frnog a écrit : > > Bonsoir, > Cela a été corrigé il y a 1h30 : > > RP/0/RSP0/CPU0:core1#show bgp rpki table ipv4 | i 90.1.0.0/17 > 90.1.0.0/17 17 3215 > RP/0/RSP0/CPU0:core1# > > RP/0/RSP0/CPU0:core1#sh bgp ipv4 un 90.1.0.0/17 > BGP routing table entry for 90.1.0.0/17 > Versions: > Process bRIB/RIB SendTblVer > Speaker 8947404589474045 > Last Modified: Mar 23 20:53:42.047 for 01:27:47 > Paths: (14 available, best #5) > X 3215, (received-only) > Origin-AS validity: valid > > RP/0/RSP0/CPU0:core1#show route ipv4 un 90.1.0.0/17 > Routing entry for 90.1.0.0/17 > Known via "bgp 209097", distance 20, metric 0 > Tag 209097, type external > Installed Mar 23 20:53:46.607 for 01:26:27 > > > > > Agréable journée, > > -- > Gary > >> -Message d'origine- >> De : frnog-requ...@frnog.org De la part de Alarig >> Le Lay >> Envoyé : lundi 23 mars 2020 21:55 >> À : frnog@frnog.org >> Objet : Re: [FRnOG] [TECH] Orange / ROA invalide 90.1.128.0/17 >> >> On lun. 23 mars 18:45:59 2020, Alexandre BATON wrote: >>> En grattant un peu plus sur https://rpki-validator.ripe.net, ce n’est pas >>> le seul >> prefixe concerné sur l’AS3215. >>> >>> * 92.145.0.0/16 a été splitté le 24/01 en 2 x /17 (92.145.0.0/17 et >> 92.145.128.0/17) avec des ROA invalides >>> * 92.131.0.0/16 a été splitté le 24/01 en 2 x /17 (92.131.0.0/17 et >> 92.131.128.0/17) avec des ROA invalides >>> * 86.209.0.0/16 a été splitté le 27/01 en 2 x /17 (86.209.0.0/17 et >> 86.209.128.0/17) avec des ROA invalides >>> * 81.251.0.0/16 a été splitté le 24/01 en 2 x /17 (81.251.0.0/17 et >> 81.251.128.0/17) avec des ROA invalides >>> * 80.12.196.0/22 est passé d’un /22 à 1 /23 le 02/03 (80.12.196.0/23) avec >>> une >> ROA invalide >>> >>> ça commence à faire qq centaines de milliers d’IP avec une ROA invalide chez >> Orange... >>> >>> Je me demande comment ça s'est passé, la personne qui a validé le split des >> prefixes a oublié qu’ils utilisaient une RPKI? A moins que ça ne soit pas >> les même >> équipes qui gèrent la RPKI et qu’il y ai eu un problème de communication ... >>> >>> Cordialement, >>> >>> Alexandre BATON >> >> Je vois bien les deux /17 depuis mon AS, et je filtre le RPKI : >> >> bird> show route all primary where net ~ [ 90.1.0.0/16+ ] >> Table master4: >> 90.1.128.0/17unicast [ibgp_regis_ipv4 19:58:55.731 from >> 45.91.126.255] * >> (100/?) [AS3215i] >> via 10.0.4.8 on gre2 >> Type: BGP univ >> BGP.origin: IGP >> BGP.as_path: 204092 34019 3215 >> BGP.next_hop: 89.234.186.7 >> BGP.med: 50 >> BGP.local_pref: 100 >> BGP.community: (34019,3215) (34019,65000) (34019,65010) >> (34019,65534) (64496,100) (64496,34019) (65512,20001) >> BGP.large_community: (208627, 0, 204092) (208627, 100, 100) >> 90.1.0.0/17 unicast [ibgp_regis_ipv4 19:58:55.731 from >> 45.91.126.255] * >> (100/?) [AS3215i] >> via 10.0.4.8 on gre2 >> Type: BGP univ >> BGP.origin: IGP >> BGP.as_path: 204092 34019 3215 >> BGP.next_hop: 89.234.186.7 >> BGP.med: 50 >> BGP.local_pref: 100 >> BGP.community: (34019,3215) (34019,65000) (34019,65010) >> (34019,65534) (64496,100) (64496,34019) (65512,20001) >> BGP.large_community: (208627, 0, 204092) (208627, 100, 100) >> >> -- >> Alarig >> >> >> --- >> Liste de diffusion du FRnOG >> http://www.frnog.org/ > > --- > Liste de diffusion du FRnOG > http://www.frnog.org/ smime.p7s Description: S/MIME cryptographic signature
RE: [FRnOG] [TECH] Orange / ROA invalide 90.1.128.0/17
Bonsoir, Cela a été corrigé il y a 1h30 : RP/0/RSP0/CPU0:core1#show bgp rpki table ipv4 | i 90.1.0.0/17 90.1.0.0/17 17 3215 RP/0/RSP0/CPU0:core1# RP/0/RSP0/CPU0:core1#sh bgp ipv4 un 90.1.0.0/17 BGP routing table entry for 90.1.0.0/17 Versions: Process bRIB/RIB SendTblVer Speaker 8947404589474045 Last Modified: Mar 23 20:53:42.047 for 01:27:47 Paths: (14 available, best #5) X 3215, (received-only) Origin-AS validity: valid RP/0/RSP0/CPU0:core1#show route ipv4 un 90.1.0.0/17 Routing entry for 90.1.0.0/17 Known via "bgp 209097", distance 20, metric 0 Tag 209097, type external Installed Mar 23 20:53:46.607 for 01:26:27 Agréable journée, -- Gary > -Message d'origine- > De : frnog-requ...@frnog.org De la part de Alarig > Le Lay > Envoyé : lundi 23 mars 2020 21:55 > À : frnog@frnog.org > Objet : Re: [FRnOG] [TECH] Orange / ROA invalide 90.1.128.0/17 > > On lun. 23 mars 18:45:59 2020, Alexandre BATON wrote: > > En grattant un peu plus sur https://rpki-validator.ripe.net, ce n’est pas > > le seul > prefixe concerné sur l’AS3215. > > > > * 92.145.0.0/16 a été splitté le 24/01 en 2 x /17 (92.145.0.0/17 et > 92.145.128.0/17) avec des ROA invalides > > * 92.131.0.0/16 a été splitté le 24/01 en 2 x /17 (92.131.0.0/17 et > 92.131.128.0/17) avec des ROA invalides > > * 86.209.0.0/16 a été splitté le 27/01 en 2 x /17 (86.209.0.0/17 et > 86.209.128.0/17) avec des ROA invalides > > * 81.251.0.0/16 a été splitté le 24/01 en 2 x /17 (81.251.0.0/17 et > 81.251.128.0/17) avec des ROA invalides > > * 80.12.196.0/22 est passé d’un /22 à 1 /23 le 02/03 (80.12.196.0/23) avec > > une > ROA invalide > > > > ça commence à faire qq centaines de milliers d’IP avec une ROA invalide chez > Orange... > > > > Je me demande comment ça s'est passé, la personne qui a validé le split des > prefixes a oublié qu’ils utilisaient une RPKI? A moins que ça ne soit pas les > même > équipes qui gèrent la RPKI et qu’il y ai eu un problème de communication ... > > > > Cordialement, > > > > Alexandre BATON > > Je vois bien les deux /17 depuis mon AS, et je filtre le RPKI : > > bird> show route all primary where net ~ [ 90.1.0.0/16+ ] > Table master4: > 90.1.128.0/17unicast [ibgp_regis_ipv4 19:58:55.731 from > 45.91.126.255] * > (100/?) [AS3215i] > via 10.0.4.8 on gre2 > Type: BGP univ > BGP.origin: IGP > BGP.as_path: 204092 34019 3215 > BGP.next_hop: 89.234.186.7 > BGP.med: 50 > BGP.local_pref: 100 > BGP.community: (34019,3215) (34019,65000) (34019,65010) > (34019,65534) (64496,100) (64496,34019) (65512,20001) > BGP.large_community: (208627, 0, 204092) (208627, 100, 100) > 90.1.0.0/17 unicast [ibgp_regis_ipv4 19:58:55.731 from > 45.91.126.255] * > (100/?) [AS3215i] > via 10.0.4.8 on gre2 > Type: BGP univ > BGP.origin: IGP > BGP.as_path: 204092 34019 3215 > BGP.next_hop: 89.234.186.7 > BGP.med: 50 > BGP.local_pref: 100 > BGP.community: (34019,3215) (34019,65000) (34019,65010) > (34019,65534) (64496,100) (64496,34019) (65512,20001) > BGP.large_community: (208627, 0, 204092) (208627, 100, 100) > > -- > Alarig > > > --- > Liste de diffusion du FRnOG > http://www.frnog.org/ --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Orange / ROA invalide 90.1.128.0/17
On lun. 23 mars 18:45:59 2020, Alexandre BATON wrote: > En grattant un peu plus sur https://rpki-validator.ripe.net, ce n’est pas le > seul prefixe concerné sur l’AS3215. > > * 92.145.0.0/16 a été splitté le 24/01 en 2 x /17 (92.145.0.0/17 et > 92.145.128.0/17) avec des ROA invalides > * 92.131.0.0/16 a été splitté le 24/01 en 2 x /17 (92.131.0.0/17 et > 92.131.128.0/17) avec des ROA invalides > * 86.209.0.0/16 a été splitté le 27/01 en 2 x /17 (86.209.0.0/17 et > 86.209.128.0/17) avec des ROA invalides > * 81.251.0.0/16 a été splitté le 24/01 en 2 x /17 (81.251.0.0/17 et > 81.251.128.0/17) avec des ROA invalides > * 80.12.196.0/22 est passé d’un /22 à 1 /23 le 02/03 (80.12.196.0/23) avec > une ROA invalide > > ça commence à faire qq centaines de milliers d’IP avec une ROA invalide chez > Orange... > > Je me demande comment ça s'est passé, la personne qui a validé le split des > prefixes a oublié qu’ils utilisaient une RPKI? A moins que ça ne soit pas les > même équipes qui gèrent la RPKI et qu’il y ai eu un problème de communication > ... > > Cordialement, > > Alexandre BATON Je vois bien les deux /17 depuis mon AS, et je filtre le RPKI : bird> show route all primary where net ~ [ 90.1.0.0/16+ ] Table master4: 90.1.128.0/17unicast [ibgp_regis_ipv4 19:58:55.731 from 45.91.126.255] * (100/?) [AS3215i] via 10.0.4.8 on gre2 Type: BGP univ BGP.origin: IGP BGP.as_path: 204092 34019 3215 BGP.next_hop: 89.234.186.7 BGP.med: 50 BGP.local_pref: 100 BGP.community: (34019,3215) (34019,65000) (34019,65010) (34019,65534) (64496,100) (64496,34019) (65512,20001) BGP.large_community: (208627, 0, 204092) (208627, 100, 100) 90.1.0.0/17 unicast [ibgp_regis_ipv4 19:58:55.731 from 45.91.126.255] * (100/?) [AS3215i] via 10.0.4.8 on gre2 Type: BGP univ BGP.origin: IGP BGP.as_path: 204092 34019 3215 BGP.next_hop: 89.234.186.7 BGP.med: 50 BGP.local_pref: 100 BGP.community: (34019,3215) (34019,65000) (34019,65010) (34019,65534) (64496,100) (64496,34019) (65512,20001) BGP.large_community: (208627, 0, 204092) (208627, 100, 100) -- Alarig --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Orange / ROA invalide 90.1.128.0/17
En grattant un peu plus sur https://rpki-validator.ripe.net, ce n’est pas le seul prefixe concerné sur l’AS3215. * 92.145.0.0/16 a été splitté le 24/01 en 2 x /17 (92.145.0.0/17 et 92.145.128.0/17) avec des ROA invalides * 92.131.0.0/16 a été splitté le 24/01 en 2 x /17 (92.131.0.0/17 et 92.131.128.0/17) avec des ROA invalides * 86.209.0.0/16 a été splitté le 27/01 en 2 x /17 (86.209.0.0/17 et 86.209.128.0/17) avec des ROA invalides * 81.251.0.0/16 a été splitté le 24/01 en 2 x /17 (81.251.0.0/17 et 81.251.128.0/17) avec des ROA invalides * 80.12.196.0/22 est passé d’un /22 à 1 /23 le 02/03 (80.12.196.0/23) avec une ROA invalide ça commence à faire qq centaines de milliers d’IP avec une ROA invalide chez Orange... Je me demande comment ça s'est passé, la personne qui a validé le split des prefixes a oublié qu’ils utilisaient une RPKI? A moins que ça ne soit pas les même équipes qui gèrent la RPKI et qu’il y ai eu un problème de communication ... Cordialement, Alexandre BATON > Le 23 mars 2020 à 18:15, Gary BLUM a écrit : > > Bonjour, > Je confirme l'ensemble des dires. > > J'ai envoyé l' email a l'une des personnes *-c du inetnum concerné chez > Orange. > En espérant qu'il puisse résoudre le problème. > > > Agréable journée, > > -- > Gary > AS209097 > >> -Message d'origine- >> De : frnog-requ...@frnog.org De la part de >> Alexandre BATON >> Envoyé : lundi 23 mars 2020 17:42 >> À : frnog-t...@frnog.org >> Cc : Alexandre BATON >> Objet : [FRnOG] [TECH] Orange / ROA invalide 90.1.128.0/17 >> >> Bonjour le FRnOG, >> >> Nous avons constaté depuis quelques semaines que nous ne pouvons plus >> joindre un prefixe d’Orange: 90.1.0.0/16 (AS3215) depuis notre AS (AS50446). >> Auncun problème pour joindre d’autres prefixe d’Orange (ex: 193.248.0.0/16, >> 194.51.0.0/16…) (rtt, loss, jitter normal). >> Pour joindre l’AS3215 nous passons par Cogent et Verizon. >> >> Après recherche, il s’avère que le 90.1.0.0/16 d’Orange a été splité en 2 >> prefix >> /17 (90.1.0.0/17 et 90.1.128.0/17) le 24/01/20 et que l’annonce du /16 a >> disparu. >> (cf le routing history venant de RIPE stats: >> https://stat.ripe.net/widget/routing- >> history#w.resource=90.1.0.0=2018-12- >> 08T00:00:00=2020-03-23T00:00:00) >> >> Ces 2 x /17 ne sont pas vu par tout le monde. >> Déjà via les RCCs du RIPE, la liste des peers voyant les 2x /17 passent de >> 219 >> peers contre 269 peers voyant le /16 avant le 24/01. >> Et en comparant les looking glass de quelques opérateurs: >> >> • Le LG d’Opentransit confirme bien qu’il y a 2 x /17 d’annoncés et plus >> le /16 (https://lg.opentransit.net/) >> • Les LG de Tata et Telia ne voient pas les /17 >> (https://lg.telia.net/?type=bgp=s-ipx-i1=90.1.128.0/17 et >> http://lg.beta.as6453.net/prefix_bgpmap/mtt/ipv4?q=90.1.128.0/17) >> • Le LG de Cogent ne voit pas les 2 x /17 et ils ne me sont pas annoncés >> en BGP (https://www.cogentco.com/fr/network/looking-glass) >> • Verizon m’annonce les 2 x /17 en BGP. >> • Le route server de HE voit bien les 2 x /17 (telnet >> route-server.he.net) >> >> Si on regarde les ROA/RPKI, elle est défini pour 90.1.0.0/16 et pas les 2x >> /17. >> Elle est considéré comme invalide pour les 2x /17 (pas inconnu, mais bien >> invalide!). >> (https://rpki-validator.ripe.net/announcement- >> preview?asn=AS3215=90.1.128.0%2F17) >> >> Hypothèse: Orange a splité un /16 en 2 x /17 sans mettre à jour la RPKI et >> leurs >> annonces se retrouvent filtrées par certains opérateurs. >> >> Dans mon cas, c’est problématique, nous avons 2 fournisseurs de transit pour >> joindre l’AS3215: Cogent et Verizon. >> Verizon m’annonce bien les 2x /17 mais pas Cogent. >> La route la plus courte pour Orange pour joindre notre AS passe par Cogent. >> Donc pour joindre le prefix 90.1.0.0/16, nous sortons via Verizon et Orange >> essaye de nous répondre par Cogent qui (je suppose) drop le paquet… >> Comme précisé au début, aucun problème pour joindre d’autres prefix d’Orange >> via Cogent. >> >> Vous auriez un bon contact chez Orange pour démêler ça? (Je ne suis pas >> client >> chez eux, donc pas moyen d’ouvrir un ticket). >> >> Cordialement, >> >> Alexandre BATON smime.p7s Description: S/MIME cryptographic signature
RE: [FRnOG] [TECH] Orange / ROA invalide 90.1.128.0/17
Bonjour, Je confirme l'ensemble des dires. J'ai envoyé l' email a l'une des personnes *-c du inetnum concerné chez Orange. En espérant qu'il puisse résoudre le problème. Agréable journée, -- Gary AS209097 > -Message d'origine- > De : frnog-requ...@frnog.org De la part de > Alexandre BATON > Envoyé : lundi 23 mars 2020 17:42 > À : frnog-t...@frnog.org > Cc : Alexandre BATON > Objet : [FRnOG] [TECH] Orange / ROA invalide 90.1.128.0/17 > > Bonjour le FRnOG, > > Nous avons constaté depuis quelques semaines que nous ne pouvons plus > joindre un prefixe d’Orange: 90.1.0.0/16 (AS3215) depuis notre AS (AS50446). > Auncun problème pour joindre d’autres prefixe d’Orange (ex: 193.248.0.0/16, > 194.51.0.0/16…) (rtt, loss, jitter normal). > Pour joindre l’AS3215 nous passons par Cogent et Verizon. > > Après recherche, il s’avère que le 90.1.0.0/16 d’Orange a été splité en 2 > prefix > /17 (90.1.0.0/17 et 90.1.128.0/17) le 24/01/20 et que l’annonce du /16 a > disparu. > (cf le routing history venant de RIPE stats: > https://stat.ripe.net/widget/routing- > history#w.resource=90.1.0.0=2018-12- > 08T00:00:00=2020-03-23T00:00:00) > > Ces 2 x /17 ne sont pas vu par tout le monde. > Déjà via les RCCs du RIPE, la liste des peers voyant les 2x /17 passent de 219 > peers contre 269 peers voyant le /16 avant le 24/01. > Et en comparant les looking glass de quelques opérateurs: > > • Le LG d’Opentransit confirme bien qu’il y a 2 x /17 d’annoncés et plus > le /16 (https://lg.opentransit.net/) > • Les LG de Tata et Telia ne voient pas les /17 > (https://lg.telia.net/?type=bgp=s-ipx-i1=90.1.128.0/17 et > http://lg.beta.as6453.net/prefix_bgpmap/mtt/ipv4?q=90.1.128.0/17) > • Le LG de Cogent ne voit pas les 2 x /17 et ils ne me sont pas annoncés > en BGP (https://www.cogentco.com/fr/network/looking-glass) > • Verizon m’annonce les 2 x /17 en BGP. > • Le route server de HE voit bien les 2 x /17 (telnet > route-server.he.net) > > Si on regarde les ROA/RPKI, elle est défini pour 90.1.0.0/16 et pas les 2x > /17. > Elle est considéré comme invalide pour les 2x /17 (pas inconnu, mais bien > invalide!). > (https://rpki-validator.ripe.net/announcement- > preview?asn=AS3215=90.1.128.0%2F17) > > Hypothèse: Orange a splité un /16 en 2 x /17 sans mettre à jour la RPKI et > leurs > annonces se retrouvent filtrées par certains opérateurs. > > Dans mon cas, c’est problématique, nous avons 2 fournisseurs de transit pour > joindre l’AS3215: Cogent et Verizon. > Verizon m’annonce bien les 2x /17 mais pas Cogent. > La route la plus courte pour Orange pour joindre notre AS passe par Cogent. > Donc pour joindre le prefix 90.1.0.0/16, nous sortons via Verizon et Orange > essaye de nous répondre par Cogent qui (je suppose) drop le paquet… > Comme précisé au début, aucun problème pour joindre d’autres prefix d’Orange > via Cogent. > > Vous auriez un bon contact chez Orange pour démêler ça? (Je ne suis pas client > chez eux, donc pas moyen d’ouvrir un ticket). > > Cordialement, > > Alexandre BATON --- Liste de diffusion du FRnOG http://www.frnog.org/
[FRnOG] [TECH] Orange / ROA invalide 90.1.128.0/17
Bonjour le FRnOG, Nous avons constaté depuis quelques semaines que nous ne pouvons plus joindre un prefixe d’Orange: 90.1.0.0/16 (AS3215) depuis notre AS (AS50446). Auncun problème pour joindre d’autres prefixe d’Orange (ex: 193.248.0.0/16, 194.51.0.0/16…) (rtt, loss, jitter normal). Pour joindre l’AS3215 nous passons par Cogent et Verizon. Après recherche, il s’avère que le 90.1.0.0/16 d’Orange a été splité en 2 prefix /17 (90.1.0.0/17 et 90.1.128.0/17) le 24/01/20 et que l’annonce du /16 a disparu. (cf le routing history venant de RIPE stats: https://stat.ripe.net/widget/routing-history#w.resource=90.1.0.0=2018-12-08T00:00:00=2020-03-23T00:00:00) Ces 2 x /17 ne sont pas vu par tout le monde. Déjà via les RCCs du RIPE, la liste des peers voyant les 2x /17 passent de 219 peers contre 269 peers voyant le /16 avant le 24/01. Et en comparant les looking glass de quelques opérateurs: • Le LG d’Opentransit confirme bien qu’il y a 2 x /17 d’annoncés et plus le /16 (https://lg.opentransit.net/) • Les LG de Tata et Telia ne voient pas les /17 (https://lg.telia.net/?type=bgp=s-ipx-i1=90.1.128.0/17 et http://lg.beta.as6453.net/prefix_bgpmap/mtt/ipv4?q=90.1.128.0/17) • Le LG de Cogent ne voit pas les 2 x /17 et ils ne me sont pas annoncés en BGP (https://www.cogentco.com/fr/network/looking-glass) • Verizon m’annonce les 2 x /17 en BGP. • Le route server de HE voit bien les 2 x /17 (telnet route-server.he.net) Si on regarde les ROA/RPKI, elle est défini pour 90.1.0.0/16 et pas les 2x /17. Elle est considéré comme invalide pour les 2x /17 (pas inconnu, mais bien invalide!). (https://rpki-validator.ripe.net/announcement-preview?asn=AS3215=90.1.128.0%2F17) Hypothèse: Orange a splité un /16 en 2 x /17 sans mettre à jour la RPKI et leurs annonces se retrouvent filtrées par certains opérateurs. Dans mon cas, c’est problématique, nous avons 2 fournisseurs de transit pour joindre l’AS3215: Cogent et Verizon. Verizon m’annonce bien les 2x /17 mais pas Cogent. La route la plus courte pour Orange pour joindre notre AS passe par Cogent. Donc pour joindre le prefix 90.1.0.0/16, nous sortons via Verizon et Orange essaye de nous répondre par Cogent qui (je suppose) drop le paquet… Comme précisé au début, aucun problème pour joindre d’autres prefix d’Orange via Cogent. Vous auriez un bon contact chez Orange pour démêler ça? (Je ne suis pas client chez eux, donc pas moyen d’ouvrir un ticket). Cordialement, Alexandre BATON smime.p7s Description: S/MIME cryptographic signature
