RE: [FRnOG] [TECH] [BGP] Traffic arrivant sur un seul lien au lieu de deux

[Michel Py via frnog]

> Gregory CAUCHIE a écrit :
> De ce fait, il n'y a normalement pas de trou d’annonce dans une 
> route-map/policy qui oublierait un des préfixes d’un AS. 

Justement, c'est l'interprétation de "normalement" qui m'interpelle :P C'est 
une norme, disons, élastique.

> Autre aspect qui peut faire apparaître des valeurs différentes dans les 
> looking-glass, le lieu où sont établis
> les peering. La sélection du meilleur chemin préfère d'abord le préfixe qui a 
> été appris via un e-BGP directly
> connected, et ensuite aux annonces des autres routeurs de l’AS avec une 
> hiérarchie selon la distance IGP.

Un looking-glass qui interroge un routeur qui ne fait pas eBGP, ça n'a pas 
beaucoup d'intérêt.
C'est d'ailleurs une des raisons pour lesquelles j'avais abordé le sujet : si 
le looking-glass est un routeur interne qui ne reçoit que le meilleur préfixe 
après que localpref ait été changé par une route-map qui regarde les 
communautés, on risque pas de voir les chemins alternatifs.

Michel.


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

Re: [FRnOG] [TECH] choix transitaires

[Vincent Bernat]

 ❦ 11 June 2021 04:06 GMT, Romain BAFFERT:

> cogent par les retours que j’en ai eu + le fait qu’ils n’ont pas tout
> internet ipv6 et que ça sent mauvais de partie avec une rustine…

Cogent est très embêtant pour ça et cela fait des années que cela ne
bouge pas malgré des promesses. En pratique, c'est toutefois assez peu
gênant vu que toutes les apps vont fallback en IPv4 si tu perds ton
second transit. Par contre, si tu as des clients pros derrière, cela
fera sans doute sonner leur monitoring.

Cogent souffre également de mauvaise réputation avec sa politique
commerciale de harceler les gens pour prendre du transit chez eux.

En dehors de ces deux points, Cogent a un excellent rapport
qualité/prix. Étant souvent les moins chers, il y a finalement beaucoup
de monde sur leur réseau. Ils sont aussi disponibles dans beaucoup de
DC, y compris des petits alors que pour d'autres, il faudra
éventuellement aller les chercher en longue distance, voire via une
wave. Pour ma part, ils ont aussi toujours été très flexibles (par
exemple, on nous a monté nx10G sur du CWDM sans soucis pour économiser
le prix des crosscos dans des DC US, on nous offre les ports 1G pour
l'OOB). Et au niveau du support, on a souvent des réponses dans l'heure
et les requêtes type "perte de paquets entre tel hop et tel hop" ou "les
paquets font un détour par ici" sont pris en compte et corrigés en
instant un peu, contrairement à d'autres qui nous disent "Internet,
c'est comme ça".

> D’un point de vue contrat, vu que les prix dégringolent chaque année,
> que négociez vous quand vous entrez chez un fournisseur ? Réévaluation
> des prix sur la durée de l’engagement ? Croissance du débit à prix
> constant etc ? En gros j’ai l’impression que m’engager sur 3 ans sur
> un fournisseur même avec une belle remise sera au final plus douteux
> que de les challenger chaque année :) ça c’était pour la partie
> commerciale.

Si tu dépasses significativement ton commit, tu peux renégocier
régulièrement les prix en disant que pour ce mois-ci, tu passes ton
trafic sur un autre transitaire.

> Et pour finir, je me pose la question de l’opportunité de compléter
> tout de suite / plus tard / pas du tout par une présence avec un IX
> type lyonIX (je suis sur lyon)…

En France, cela fonctionne assez bien pour écouler du trafic. Voici
aussi l'opportunité d'utiliser deux Tiers 2 au lieu de deux Tiers 1.
Cela coûte plus cher, mais cela permet d'éviter à avoir à faire des
peerings ou passer par des IX. De plus en plus proposent également des
prestations anti-DDoS sur demande. Le mélange peut sembler un compromis,
mais cela apporte son lot de problèmes (difficulté à contrôler le trafic
entrant).
-- 
It were not best that we should all think alike; it is difference of opinion
that makes horse-races.
-- Mark Twain, "Pudd'nhead Wilson's Calendar"


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

RE: [FRnOG] [TECH] choix transitaires

[Michel Py via frnog]

> Romain BAFFERT a écrit :
> Contexte : je bâtis notre offre opérateur / hébergeur et je pars sur un 
> principe (peut être idiot;
> arguments pour ou contres bienvenus) de partir en mode « parano » ou « geek 
> puriste » et de raccorder
> mon infra sur deux dc différents avec un Tier1 différent sur chaque, en 
> doublant tout si possible.

Si tu as l'argent, oui. Il n'y a que toi qui peut répondre à cette question.


> Indépendamment de leurs politiques commerciales (ça semble être les soldes en 
> fin
> de trimestre, on me baisse le prix chaque semaine pour que je commande ;) )

C'est les soldes toute l'année ! Il est urgent d'attendre :P


> En gros ils me pondent tous des prix assez similaires et en pleine 
> dégringolade pour du giga de commit sur 10 giga.

Il y a une grosse différence entre ça et du 10G plein ? Ici, 10G plein c'est à 
peine plus de 1000 balles par mois pour certains.


> Si certains petits / débutants ici ont des conseils suivant leur expérience 
> je suis
> preneur…. J’hésite notamment à leur demander l’option d’un lien double sur 
> mes deux dc.

C'est quoi que tu appelles un lien double ?


> Pour la partie plus technique : j’ai vu récemment le sujet avec le bordel 
> qu’était bgp. En soi ça ne me
> fait pas peur (j’aurais jamais monté ma boîte y’a 10 ans si j’avais peur :D) 
> mais est-ce que justement
> certains tier1 gèrent mieux / plus de souplesse / meilleur support force de 
> conseils sur la partie bgp ?

Ca va et ça vient :-(
Deux choses à demander : les communautés qu'ils envoient / acceptent, et est-ce 
qu'ils bloquent les préfixes RPKI invalides.


> Et pour finir, je me pose la question de l’opportunité de compléter tout de 
> suite /
> plus tard / pas du tout par une présence avec un IX type lyonIX (je suis sur 
> lyon)…

Plus tard, si financièrement c'est rentable. Quand tu auras une idée de ce que 
ton trafic est, tu fais tes calculs. Ca dépend pas mal du type d'activité.

Michel.


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

[FRnOG] [TECH] choix transitaires

[Romain BAFFERT]

Bonjour à tous,

(Disclaimer : bien qu’ayant pas mal d’expérience réseaux / Cablage / infra / 
sécurité etc depuis une vingtaine d’années, je débute dans le domaine telco / 
ISP en datacenter ;) )

Contexte : je bâtis notre offre opérateur / hébergeur et je pars sur un 
principe (peut être idiot; arguments pour ou contres bienvenus) de partir en 
mode « parano » ou « geek puriste » et de raccorder mon infra sur deux dc 
différents avec un Tier1 différent sur chaque, en doublant tout si possible.


Indépendamment de leurs politiques commerciales (ça semble être les soldes en 
fin de trimestre, on me baisse le prix chaque semaine pour que je commande ;) ) 
quels sont vos retours d’expérience sur les différents « gros » que sont lumen 
/ gtt / telia ? Y’a t’il de vraies différences techniques / support / pratiques 
/ relationnelles qui excluent certains ? J’ai déjà exclu (a tord ou à raison ?) 
cogent par les retours que j’en ai eu + le fait qu’ils n’ont pas tout internet 
ipv6 et que ça sent mauvais de partie avec une rustine…

En gros ils me pondent tous des prix assez similaires et en pleine dégringolade 
pour du giga de commit sur 10 giga. Si certains petits / débutants ici ont des 
conseils suivant leur expérience je suis preneur…. J’hésite notamment à leur 
demander l’option d’un lien double sur mes deux dc. Je me dis que le surcoût 
est peut être négligeable et ça peut aider beaucoup en cas de souci…

D’un point de vue contrat, vu que les prix dégringolent chaque année, que 
négociez vous quand vous entrez chez un fournisseur ? Réévaluation des prix sur 
la durée de l’engagement ? Croissance du débit à prix constant etc ? En gros 
j’ai l’impression que m’engager sur 3 ans sur un fournisseur même avec une 
belle remise sera au final plus douteux que de les challenger chaque année :) 
ça c’était pour la partie commerciale.

Pour la partie plus technique : j’ai vu récemment le sujet avec le bordel 
qu’était bgp. En soi ça ne me fait pas peur (j’aurais jamais monté ma boîte y’a 
10 ans si j’avais peur :D) mais est-ce que justement certains tier1 gèrent 
mieux / plus de souplesse / meilleur support force de conseils sur la partie 
bgp ?

Pour ce qui est du ddos est-ce que certains ici traitent ça a l’extérieur (type 
nawas / neustar / corero) ? J’essaye d’avoir une bonne protection sans pour 
autant me faire exploser d’entrée de jeu au niveau coûts alors que je ne fais 
que commencer cette activité (mais je veux la débuter propre)… l’achat ou la 
prise en leasing de boîtiers me semble pas adaptée au besoin.

Et pour finir, je me pose la question de l’opportunité de compléter tout de 
suite / plus tard / pas du tout par une présence avec un IX type lyonIX (je 
suis sur lyon)…

Au plaisir d’échanger avec la communauté / échange de bons procédés :)

Bonne journée à tous !


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

Re: [FRnOG] [TECH] [BGP] Traffic arrivant sur un seul lien au lieu de deux

[Gregory CAUCHIE]

> Le 10 juin 2021 à 07:56, Michel Py via frnog  a écrit :
> 
> J'avoue que j'ai du mal à saisir les subtilités du peering entre Tier-1, 
> surtout quand c'est sur plusieurs continents. Le Traffic Engineering, les 
> localpref et tout ça, il y a des fois ou ça a l'air plus de discussions de 
> marchand de tapis que de la logique du réseau ou même de la patate chaude. 
> C'est pourtant bien connu, BGP est un protocole de niveau 9.
> 
> +---+--+
> | 9 | Politics |  <=== BGP
> | 8 | Money|
> | 7 | Application  | 
> | 6 | Presentation |
> | 5 | Session  |
> | 4 | Transport|
> | 3 | Network  |
> | 2 | Data Link|
> | 1 | Physical |
> +---+--+
> 
> Donc l'explication, c'est une politique de TE/localpref "régionalisée" ? Tous 
> les routeurs qui sont dans la même "région" ont tous les mêmes "meilleurs" 
> préfixes, et donc aucun ne montre le chemin alternatif ? Pas de route-map qui 
> oublierait "magiquement" de recevoir certains préfixes ?

L’argent et la politique se traduisent très souvent dans les configurations de 
communautés BGP. Ces communautés sont appliquées sur tous les préfixes reçus 
d’un peering, et les combinaisons de communautés sont utilisées en export pour 
la redistribution ou non et en import pour fixer les Local_pref. De ce fait, il 
n'y a normalement pas de trou d’annonce dans une route-map/policy qui 
oublierait un des préfixes d’un AS. 
Autre aspect qui peut faire apparaître des valeurs différentes dans les 
looking-glass, le lieu où sont établis les peering. La sélection du meilleur 
chemin préfère d'abord le préfixe qui a été appris via un e-BGP directly 
connected, et ensuite aux annonces des autres routeurs de l’AS avec une 
hiérarchie selon la distance IGP. 

--
Grégory

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

Re: [FRnOG] [TECH] mixer bind et knot (par ex) pour augmenter la résilience des NS

[Xavier Beaudouin]

Hello,

Ca s'appelle l'Eugenisme des applications.
On peux aussi parler des OS... Exemple linux qui avais eu avec Java quelques 
vapeurs que d'autre OS
avaient sus gérer lors d'un leap second... il y a quelques années...

D'ailleurs a force d'avoir des Linux en sous marin sur de plus en plus 
d'équipements réseaux me
fait penser à ce problème d'Eugenisme des OS low level... (surtout ceux en 
abandonware).


/Xavier


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

RE: [FRnOG] [TECH] [BGP] Traffic arrivant sur un seul lien au lieu de deux

[Michel Py via frnog]

>> Michel Py a écrit :
>> Comment expliquer que dans certains looking-glass (pas tous), on ne voit 
>> même pas ce chemin ? 

> Emmanuel DECAEN a écrit :
> Peut-être sur la vérification de la route et de l'AS.
> L'AS 34536 n'a pas d'objet route pour 80.77.225.0/24

Et il faudrait regarder RPKI aussi; ce genre de chose peut être sournois, vu 
que personne de connait vraiment la recette de la potion magique différente 
pour tous que les opérateurs utilisent sur leur réseau, c'est bien le coup à se 
retrouver avec un machin automagique obscur.

Michel.


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

Re: [TECH] [FRnOG] Re: Un CDN Down ?

[Raphael Mazelier]

On 10/06/2021 15:41, Damien Wetzel wrote:

Ton systeme ne fonctionne que si tu mets en cache que les sous domaines de ta 
page
(pas le www) et neccessite un developement agile du site (ils sont souvent 
figés et il est difficile d'en changer l'archi)


Disons que si tu as la problèmatique du multi cdn tu dois être assez 
gros pour avoir une équipe de dev capable de réaliser ceci. Après 
globalement ce que tu mets en cache c'est quand meme souvent tes assets 
et ou des choses très statiques qui ne sont pas accédé directement. 
Enfin tu peux tenter de CDNiser tout ton site mais c'est assez casse 
gueule, qu'on se rappelle la blague sur l'invalidation de cache.



D'autres part, j'ai l'impression que la plupart des resolveurs operateurs 
acceptent
et obeissent à des ttl relativement courts contrairement à une époque ancienne.
La solution DNS meme si elle n'est pas parfaite me parait la seule utilisable à 
l'heure
actuelle.


Je suis d'accord qu'avoir un ou plusieurs niveaux d'indirections niveau 
DNS avec des ttl(s) courts (et globalement ca marche meme si moche 
théoriquement) est une solution simple. La question après c'est à qui tu 
confie ta gestion de ton DNS. Les services types route53 sont vraiment 
pratique mais ont souffert leur lots d'indisponibilités. Tu peux aussi 
avoir un mécanisme qui controle différente API de différents fournisseur 
DNS en effet.


--

Raphael Mazelier


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

Re: [FRnOG] [TECH] dns court (était: Un CDN Down ?)

[Jean-Francois Billaud via frnog]

On 10/06/2021 18:20, Stephane Bortzmeyer wrote:

> On Thu, Jun 10, 2021 at 04:12:32PM +0200,
>  Jean-Francois Maeyhieux  wrote 
>  a message of 30 lines which said:
> 
>> Pourquoi pas utiliser plusieurs NS de fournisseurs différents pour
>> servir la zone ?
> 
> C'est en effet une bonne idée, et c'est ainsi que fonctionne .fr (ou,
> beaucoup plus modestement, bortzmeyer.org).
> 
> Malheureusement, beaucoup d'hébergeurs DNS « pour entreprise » ne
> permettent pas de faire des transferts de zones avec la méthode
> normalisée (AXFR), il faut passer par leur interface Web ou leur
> API. Si on veut synchroniser le contenu de sa zone sur les différents
> hébergeurs, il faut se faire un script appelant leurs API.

Bientôt xfr-over-tls DNS Zone Transfer-over-TLS :
https://datatracker.ietf.org/doc/draft-ietf-dprive-xfr-over-tls/
Discussion là :
https://mailarchive.ietf.org/arch/browse/dns-privacy/

Côté déploiement, xfr-over-tls va être à axfr ce que IPv6 est à IPv4.


JFB

-- 
Pourquoi pas le transfert de zone par des kangourous ?

  |\\._
  |   66__
   \_.P
   ,`) (
   )\   / __\__
  / /  / -._);_)
 |  `\/  \ __|\
  \  ;)  / )
   `\|   /__/ /__
jgs  `\__)___)



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

[FRnOG] [TECH] dns court (était: Un CDN Down ?)

[Stephane Bortzmeyer]

On Thu, Jun 10, 2021 at 04:12:32PM +0200,
 Jean-Francois Maeyhieux  wrote 
 a message of 30 lines which said:

> Pourquoi pas utiliser plusieurs NS de fournisseurs différents pour
> servir la zone ?

C'est en effet une bonne idée, et c'est ainsi que fonctionne .fr (ou,
beaucoup plus modestement, bortzmeyer.org).

Malheureusement, beaucoup d'hébergeurs DNS « pour entreprise » ne
permettent pas de faire des transferts de zones avec la méthode
normalisée (AXFR), il faut passer par leur interface Web ou leur
API. Si on veut synchroniser le contenu de sa zone sur les différents
hébergeurs, il faut se faire un script appelant leurs API.


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

Re: [FRnOG] [ALERT] - Incident appel sortant SFR ????

[David Ponzone]

Ouuuh le troll velu que voilà, je prends au vol :)

Tu veux dire le truc qu’un membre de la liste a déjà tenté il y a quelques 
années, mais qui n’a bien entendu pas décollé puisque 9X% du traffic se passe 
entre 4 acteurs du marché  ?
Je doute que la situation ait changé :)
Ptet que X est un peu plus petit maintenant.

> Le 10 juin 2021 à 16:30, Arnaud Willem  a écrit :
> 
> Tous les $grozop se sont passé le mot ?
> 
> Ici aussi on constate une forte baisse de trafic entrant et des erreurs dans 
> le sens sortant via SFR.
> 
> 
> Et jeudi soir, ça passe pour préchauffer trolldi : Allez, on relance la 
> discussion sur l’XP voix ?
> 


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

Re: [FRnOG] [ALERT] - Incident appel sortant SFR ????

[Arnaud Willem]

Tous les $grozop se sont passé le mot ?

Ici aussi on constate une forte baisse de trafic entrant et des erreurs dans le 
sens sortant via SFR.


Et jeudi soir, ça passe pour préchauffer trolldi : Allez, on relance la 
discussion sur l’XP voix ?



Arnaud Willem
Président
Strong Blue Conseil & Télécom SAS

> On 10 Jun 2021, at 16:04, Jérémie JANTAC  wrote:
> 
> Idem de SIM Free vers Mobile SFR (Niort Frère Telecom)
> 
> -Message d'origine-
> De : frnog-requ...@frnog.org  De la part de 
> Guillaume Denoix
> Envoyé : jeudi 10 juin 2021 15:52
> À : Alexandre Loisel 
> Cc : frnog-al...@frnog.org
> Objet : Re: [FRnOG] [ALERT] - Incident appel sortant SFR 
> 
> Bonjour,
> 
> Ici aussi entre SFR et Free en IDF, depuis au moins 12h15.
> 
> Bonne fin de journée :)
> 
> On Thu, Jun 10, 2021 at 3:45 PM Alexandre Loisel  wrote:
>> 
>> Bonjour à tous,
>> 
>> Sommes nous les seuls à avoir des problèmes d'appels sortant passant par SFR 
>> ? Ou y a-t-il un incident en cours ?
>> 
>> Bonne journée à tous.
>> 
>> Cordialement,
>> 
>> [cid:image001.png@01D75E0F.7BD3D6C0]
>> 
>> 
>> 
>> ---
>> 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/


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

Re: [FRnOG] [TECH] mixer bind et knot (par ex) pour augmenter la résilience des NS

[Bill Woodcock]

> On Jun 10, 2021, at 4:20 PM, Daniel Caillibaud  wrote:
> 
> Salut,
> 
> À propos de la résilience DNS évoquée dans un autre thread, plusieurs NS sur 
> des AS différents
> c'est bien, mais en cas de bug façon fastly, ils pourraient tous tomber comme 
> des dominos.
> 
> Ceux qui ont de la bouteille en la matière ont déjà vu ça se produire ?
> 
> Vu la probabilité, je ne pense pas que ça vaille la peine que j'envisage 
> sérieusement de mixer
> les softs (la probabilité d'une erreur de ma part lié à cette mixité, ou 
> celle d'une
> incompatibilité entre eux étant sûrement plus élevée que celle d'un effet 
> domino), mais je me
> demandais si certains le mettaient en pratique.

Nous utilisons BIND, NSD, PowerDNS et Knot en production, d'une part pour 
donner de la diversité à nos clients, et d'autre part pour pouvoir équilibrer 
entre eux lorsque nous rencontrons des bogues dans l'un ou l'autre.

Chacun a ses forces et ses faiblesses, je ne dirais pas qu'ils sont précisément 
interchangeables.

-Bill



signature.asc
Description: Message signed with OpenPGP

[FRnOG] [TECH] mixer bind et knot (par ex) pour augmenter la résilience des NS

[Daniel Caillibaud]

Salut,

À propos de la résilience DNS évoquée dans un autre thread, plusieurs NS sur 
des AS différents
c'est bien, mais en cas de bug façon fastly, ils pourraient tous tomber comme 
des dominos.

Ceux qui ont de la bouteille en la matière ont déjà vu ça se produire ?

Vu la probabilité, je ne pense pas que ça vaille la peine que j'envisage 
sérieusement de mixer
les softs (la probabilité d'une erreur de ma part lié à cette mixité, ou celle 
d'une
incompatibilité entre eux étant sûrement plus élevée que celle d'un effet 
domino), mais je me
demandais si certains le mettaient en pratique.

-- 
Daniel

R: Parce que ça renverse bêtement l'ordre naturel de lecture !
Q: Mais pourquoi citer en fin de message est-il si effroyable ?
R: Répondre au dessus de la citation
Q: Quelle est la chose la plus désagréable dans un message ?


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

Re: [FRnOG] Re: Re: [TECH] dns court (était: Un CDN Down ?)

[Jean-Francois Maeyhieux]

Pourquoi pas utiliser plusieurs NS de fournisseurs différents pour
servir la zone ?

Cela devrait augmenter la résilience de la zone DNS.
Il faudrait des attaques ciblés sur chaque NS hebergé sur des
infrastructures distinctes pour faire "disparaitre" la zone.

Qu'en pensez vous ?


Le jeudi 10 juin 2021 à 14:11 +0200, Stephane Bortzmeyer a écrit :
> On Thu, Jun 10, 2021 at 01:56:01PM +0200,
>  julien soula  wrote 
>  a message of 20 lines which said:
> 
> > il me semble que le expire du SOA est aussi utilise comme TTL
> > negatif
> > par les resolveurs, non ?
> 
> Ce n'est pas le Expire, c'est un autre champ, celui appelé autrefois
> Minimum TTL (et qui est désormais le TTL des réponses négatives). Le
> résolveur ne le lit pas, il se sert du TTL que le serveur faisant
> autorité a gentiment calculé pour lui (à partir de ce SOA). Cela
> évite
> au résolveur de traiter un cas particulier.
> 
> 
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/


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

Re: [FRnOG] Re: [TECH] dns court (était: Un CDN Down ?)

[Daniel Caillibaud]

Le 10/06/21 à 13:20, Stephane Bortzmeyer  a écrit :
> On Thu, Jun 10, 2021 at 10:15:03AM +0200,
>  Daniel Caillibaud  wrote 
>  a message of 31 lines which said:
> 
> > On peut pas jouer avec ttl/refresh/expire pour régler ce type de pb
> > ?  (un ttl court pour le pb initial soulevé et un expire long au cas
> > où les NS tomberaient)  
> 
> Non. Le TTL est utilisé par les résolveurs, les entrées de
> l'enregistrement SOA (refresh et expire) uniquement par les serveurs
> faisant autorité.

Merci pour le rappel, me suis emmêlé les pinceaux.

J'avais effectivement monté mes expires sur le SOA pour que les autres NS 
gardent ce
qu'ils ont s'ils n'arrivent pas à rafraîchir, ça permet de résister assez 
longtemps à une perte
du SOA (suffisamment pour le savoir et réparer).

-- 
Daniel

Le fait que le monde soit peuplé de crétins permet à
chacun de nous de ne pas se faire remarquer.
Sim


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

RE: [FRnOG] [ALERT] - Incident appel sortant SFR ????

[Jérémie JANTAC]

Idem de SIM Free vers Mobile SFR (Niort Frère Telecom)

-Message d'origine-
De : frnog-requ...@frnog.org  De la part de Guillaume 
Denoix
Envoyé : jeudi 10 juin 2021 15:52
À : Alexandre Loisel 
Cc : frnog-al...@frnog.org
Objet : Re: [FRnOG] [ALERT] - Incident appel sortant SFR 

Bonjour,

Ici aussi entre SFR et Free en IDF, depuis au moins 12h15.

Bonne fin de journée :)

On Thu, Jun 10, 2021 at 3:45 PM Alexandre Loisel  wrote:
>
> Bonjour à tous,
>
> Sommes nous les seuls à avoir des problèmes d'appels sortant passant par SFR 
> ? Ou y a-t-il un incident en cours ?
>
> Bonne journée à tous.
>
> Cordialement,
>
> [cid:image001.png@01D75E0F.7BD3D6C0]
>
>
>
> ---
> 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/

Re: [FRnOG] [ALERT] - Incident appel sortant SFR ????

[Guillaume Denoix]

Bonjour,

Ici aussi entre SFR et Free en IDF, depuis au moins 12h15.

Bonne fin de journée :)

On Thu, Jun 10, 2021 at 3:45 PM Alexandre Loisel  wrote:
>
> Bonjour à tous,
>
> Sommes nous les seuls à avoir des problèmes d'appels sortant passant par SFR 
> ? Ou y a-t-il un incident en cours ?
>
> Bonne journée à tous.
>
> Cordialement,
>
> [cid:image001.png@01D75E0F.7BD3D6C0]
>
>
>
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/


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

Re: [FRnOG] [ALERT] - Incident appel sortant SFR ????

[Hugo SIMANCAS]

pareil ... (toulouse nord)



/ ::1  Hugo SIMANCAS
Directeur Technique Associé
https://www.data-expertise.com [https://www.data-expertise.com/]
Support technique : 09 78 23 20 29
Standard : 05 34 26 02 46 | Ligne directe : 05 34 26 50 57
Mobile : 06 95 44 29 64
!Utilisez notre plateforme visio libre & gratuite : 
https://conf.data-expertise.com/ [https://conf.data-expertise.com/]
!Pad collaboratif libre & gratuit sécurisé https://pad.data-expertise.com/ 
[https://pad.data-expertise.com/]

Les informations contenues dans ce courrier électronique sont confidentielles 
et protégées par le secret professionnel. En tout état de cause, elles ne sont 
destinées qu'à la personne ou entreprise dont le nom est mentionné ci-dessus. 
Veuillez aviser l'expéditeur de toute difficulté ou de toute erreur dans la 
transmission de ce document. Si vous n'êtes pas le destinataire du présent 
courrier, vous n'êtes pas autorisé, sous peine de poursuites à en prendre des 
copies, le divulguer ou le diffuser. La présence de cette note prouve également 
que ce message électronique a été vérifié par un logiciel anti-virus.



Le 10/06/2021 à 15:44, Alexandre Loisel a écrit :
> Bonjour à tous,
>
> Sommes nous les seuls à avoir des problèmes d'appels sortant passant par SFR 
> ? Ou y a-t-il un incident en cours ?
>
> Bonne journée à tous.
>
> Cordialement,
>
> [cid:image001.png@01D75E0F.7BD3D6C0]
>
>
>
> ---
> Liste de diffusion du FRnOG
> http://antiphishing.data-expertise.com/1/aHVnby5zaW1hbmNhc0BkYXRhLWV4cGVydGlzZS5jb218VlJDNDc0NjUz/www.frnog.org/


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

Re: [FRnOG] [ALERT] - Incident appel sortant SFR ????

[DONNET, Sylvain]

Ah oui. +1
Mais entrant aussi. Un ami vient de galérer pour me joindre (Orange->SFR)

Le 10/06/2021 15:45, « frnog-ow...@frnog.org au nom de Alexandre Loisel » 
 a écrit :

Bonjour à tous,

Sommes nous les seuls à avoir des problèmes d'appels sortant passant par 
SFR ? Ou y a-t-il un incident en cours ?

Bonne journée à tous.

Cordialement,

[cid:image001.png@01D75E0F.7BD3D6C0]



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





Ce message électronique et tous les fichiers attachés peuvent contenir des 
informations confidentielles et destinées exclusivement à l’usage de la 
personne dont le nom est mentionné ci-dessus. Si vous n'êtes pas destinataire 
de ce message, vous n'êtes pas autorisés à le lire, l'imprimer, le garder, le 
copier, le divulguer, le distribuer, l'utiliser, ni dans son ensemble, ni en 
partie, sans autorisation préalable. Si vous recevez ce message par erreur, 
merci de le détruire et d’en avertir sans délai l’expéditeur.

Le contenu de ce message ne pourrait engager la responsabilité de DDO 
Organisation que s’il a été émis par une personne dûment habilitée agissant 
dans le strict cadre des fonctions auxquelles elle est employée et à des fins 
non étrangères à ses attributions. Tout message électronique étant susceptible 
d’altération au cours de son acheminement sur Internet, DDO Organisation et le 
Groupe Cogeser ne peuvent être tenus responsables de son contenu. En outre, les 
idées et opinions présentées dans ce message sont celles de son auteur et ne 
représentent pas nécessairement celles de DDO Organisation ni du Groupe Cogeser.

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

[FRnOG] [ALERT] - Incident appel sortant SFR ????

[Alexandre Loisel]

Bonjour à tous,

Sommes nous les seuls à avoir des problèmes d'appels sortant passant par SFR ? 
Ou y a-t-il un incident en cours ?

Bonne journée à tous.

Cordialement,

[cid:image001.png@01D75E0F.7BD3D6C0]



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

Re: [TECH] [FRnOG] Re: Un CDN Down ?

[Damien Wetzel]

Ton systeme ne fonctionne que si tu mets en cache que les sous domaines de ta 
page
(pas le www) et neccessite un developement agile du site (ils sont souvent 
figés et il est difficile d'en changer l'archi)

on peut partir du principe qu'un DNS robuste aura moins de chances
de tomber en panne qu'un CDN robuste , don on limite la proba de panne
sans l'eliminer totalement.
D'autres part, j'ai l'impression que la plupart des resolveurs operateurs 
acceptent
et obeissent à des ttl relativement courts contrairement à une époque ancienne.
La solution DNS meme si elle n'est pas parfaite me parait la seule utilisable à 
l'heure
actuelle.
Cordialement,
Damien 

Raphael Mazelier writes:
 > 
 > On 09/06/2021 14:51, Renaud Chaput wrote:
 > > a m'ammène à la question du multi-CDN, est ce que sa complexité
 > > se justifie pour palier à des problemes comme celui rencontré hier
 > > qui sont quand meme relativement trés rares ?
 > 
 > Cela dépend de ton buisness comme toujours.
 > 
 > Le multi CDN n'est pas nécessairement complexe et tu n'as pas besoin 
 > d'un intermédiaire pour le faire.
 > 
 > Cela dépend evidement de ce que tu caches mais cela ne me parait pas 
 > déconnant d'avoir une brique interne qui construit les URLs de ce que tu 
 > as à cacher/servir via ton CDN.
 > 
 > On le faisait dans un previous job et cela avait beaucoup d'avantage, 
 > redondance de CDN, controle des couts aussi. Et tout cela sans 
 > intervention/magie DNS.
 > 
 > Tu peux meme cacher le resultat avec un ttl assez court pour lisser les 
 > gros burst et protéger tes origines. Cela ne te protégera pas 
 > complétement mais cela limitera beaucoup la casse.
 > 
 > Sinon en beaucoup plus simple tu utilise un DNS type route53 et tu fais 
 > du weighted DNS sur les x domains de tes x CDNs. Alors évidement dans ce 
 > cas tu déportes le spof chez ton fournisseur de DNS.
 > 
 > 
 > > Est ce que avoir une config de secours sur un autre CDN + un DNS
 > > configurable
 > > rapidement avec des TTL courrs ~1min a un sens ?
 > Voir ci dessus, perso je pense que cela peut valoir le coup, mais tout 
 > dépend de ton buisness.
 > >
 > > Le gros problème du multi-CDN c’est la configuration du-dit CDN. Si tu ne
 > > t’en sers que pour du cache simple de fichiers statiques, pourquoi pas,
 > > mais si tu fais des choses plus complexes (réécriture de requêtes,
 > > sécurité, optimisation d’images, routage dynamique, intelligence at the
 > > edge) ça devient beaucoup plus compliqué.
 > 
 > J'ai un avis assez tranché sur le fait qu'on ne devrait pas mettre 
 > d'intelligence spécifique à un fournissseur CDN (ou autre d'ailleurs) 
 > pour des raisons de risque de couplage.
 > 
 > Sinon quand tu veux bouger pour x raisons (souvent financière) tu es un 
 > petit peu dans le mal.
 > 
 > >
 > > Et vu que la grosse force de Fastly c’est de pouvoir faire un peu ce que tu
 > > veux en terme de config, ça me parait vraiment complexe de le redonder. Et
 > > ensuite, quelle est la probabilité que ta brique qui gère la redondance
 > > cause à son tour une panne, est-ce plus ou moins élevé que la proba que
 > > Fastly (ou autre) tombe ? Est-ce que tu n’introduis pas un SPOF via ton
 > > outil de multi-CDN ?
 > >
 > > Bref, sujet complexe et pas évident quand on commence à considérer tous les
 > > aspects.
 > 
 > Assurément mais passionnant.
 > 
 > --
 > 
 > Raphael
 > 
 > 
 > 
 > ---
 > Liste de diffusion du FRnOG
 > http://www.frnog.org/

-- 



~
Damien WETZEL (ATANAR TECHNOLOGIES)("`-/")_.-'"``-._
http://www.atanar.com  . . `; -._)-;-,_`)
  (v_,)'  _  )`-.\  ``-'
Phone:+33 9 67 35 09 05_.- _..-_/ / ((.'
- So much to do, so little time -   ((,.-'   ((,/
~


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

Re: [FRnOG] [TECH][BGP] Traffic arrivant sur un seul lien au lieu de deux

[Gregory CAUCHIE]

> Le 10 juin 2021 à 04:53, Michel Py  a 
> écrit :
> 
>> Gregory CAUCHIE a écrit :
>> Je ne partage pas cette analyse car le principe du subnet le plus spécifique 
>> (préféré au moins
>> spécifique) est toujours appliqué sur chaque routeur quoi qu’il arrive. Il 
>> est donc vrai que
>> l’AS-path comme le MED peuvent ne pas être pris en compte pour le routage 
>> BGP chez des peers,
>> mais la solution qu’a rappelé David (i.e. annoncer le /23 aux 2, et un /24 à 
>> chacun, sans prepend)
>> garanti de faire arriver les flux d’un /24 par un peer plutôt qu’un autre et 
>> vice-versa.
> 
> Ceci étant dit, et même si j'ai plussoyé la suggestion de David, c'est quand 
> même une solution à prendre avec des pincettes.
> Dans le cas d'un client de Cogent qui veut parler au /24 qui n'est annoncé 
> que chez SFR, ou du client SFR qui veut parler au /24 qui n'est annoncé que 
> chez Cogent, et que le lien Cogent <--> SFR est saturé, ça va pas être le 
> pied. C'est déjà arrivé et ça arrivera encore. Le prepend c'est très 
> imparfait, mais couper les blocs IP en deux (ce que plein "d'optimiseurs BGP" 
> font à tort et à travers) ça a des inconvénients aussi.

Je suis d’accord Michel, à la nuance près que la « qualité » sur le chemin 
entre tes clients et ton AS, c’est un sujet beaucoup plus vaste et pour lequel 
le cas que tu remontes se posent tout autant sans mécanisme d’optimisation 
entre 2 de tes peers. On pourrait aussi ajouter d’ailleurs que ce n’est pas 
parce que tu divises ton /23 en 2x /24 que tu fais une répartition 50-50 du 
trafic en 1re tes liens, vu que chaque IP n’attire pas la même quantité de 
trafic. C’est un outil qui marche à tous les coups, à la différence du prepend, 
pour forcer le routage, mais dont les avantages et limites doivent être bien 
compris (comme partout dans le routage j’ai envie de dire :) ).

--
Grégory

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

[FRnOG] Re: Re: [TECH] dns court (était: Un CDN Down ?)

[Stephane Bortzmeyer]

On Thu, Jun 10, 2021 at 01:56:01PM +0200,
 julien soula  wrote 
 a message of 20 lines which said:

> il me semble que le expire du SOA est aussi utilise comme TTL negatif
> par les resolveurs, non ?

Ce n'est pas le Expire, c'est un autre champ, celui appelé autrefois
Minimum TTL (et qui est désormais le TTL des réponses négatives). Le
résolveur ne le lit pas, il se sert du TTL que le serveur faisant
autorité a gentiment calculé pour lui (à partir de ce SOA). Cela évite
au résolveur de traiter un cas particulier.


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

[FRnOG] Re: [TECH] dns court (était: Un CDN Down ?)

[Stephane Bortzmeyer]

On Thu, Jun 10, 2021 at 10:15:03AM +0200,
 Daniel Caillibaud  wrote 
 a message of 31 lines which said:

> On peut pas jouer avec ttl/refresh/expire pour régler ce type de pb
> ?  (un ttl court pour le pb initial soulevé et un expire long au cas
> où les NS tomberaient)

Non. Le TTL est utilisé par les résolveurs, les entrées de
l'enregistrement SOA (refresh et expire) uniquement par les serveurs
faisant autorité.


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

Re: [FRnOG] [TECH][BGP] Traffic arrivant sur un seul lien au lieu de deux

[David Ponzone]

Oui, et il y a 2 objets routes pour le même /20:

route:  80.77.224.0/20
descr:  Newel Informatique (GlobalNewel)
origin: AS12670
mnt-by: AS12670-MNT
mnt-routes: NEWEL-MNT
created:2003-07-29T12:44:48Z
last-modified:  2005-06-09T14:56:29Z
source: RIPE

route:  80.77.224.0/20
descr:  Newel Informatique (GlobalNewel)
origin: AS34536
mnt-by: NEWEL-MNT
created:2005-06-09T14:59:10Z
last-modified:  2005-06-09T14:59:10Z
source: RIPE

Je pense pas que ça ait une incidence réelle mais ça vaut le coup de mettre à 
jour, d’autant plus que COMPLETEL n’est même plus un upstream de AS34536.

> Le 10 juin 2021 à 09:13, Willy Manga  a écrit :
> 
> 
> Ce n'est pas forcément lié mais est-ce que vous pourriez aligner vos
> annonces avec les objets route (dans la base  IRR du RIPE) ?
> 
> il y a présentement :
> - 1 objet route pour 80.77.225.0/24 avec pour origine as12670
> - aucun objet route ni pour 80.77.225.0/24 ou 80.77.224.0/24 avec pour
> origine as34536
> 
> - pas de ROA aussi (mais ça peut être l'objet d'un autre débat)
> 
> -- 
> Willy Manga
> @ongolaboy
> https://ongola.blogspot.com/
> 


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

Re: [FRnOG] [TECH] dns court (était: Un CDN Down ?)

[Daniel Caillibaud]

Le 09/06/21 à 12:04, Stephane Bortzmeyer  a écrit :
> > Est ce que avoir une config de secours sur un autre CDN + un DNS
> > configurable rapidement avec des TTL courrs ~1min a un sens ?  
> 
> Je rappele qu'un TTL DNS court est un excellent moyen d'aggraver les
> conséquences d'une panne ou d'une attaque contre vos serveurs DNS
> faisant autorité. TTL de 10 minutes : vous devez être sûr que vos
> serveurs faisant autorité seront sauvés en moins de 10 minutes.

On peut pas jouer avec ttl/refresh/expire pour régler ce type de pb ?
(un ttl court pour le pb initial soulevé et un expire long au cas où les NS 
tomberaient)

Je me suis jamais bcp penché sur la question car si mes NS sont tous HS c'est 
que j'ai plus de
prod du tout… mais pour le cas des cdn j'avais compris que ça pouvait faire 
l'affaire.

-- 
Daniel

A force d’accepter l’inacceptable, on en vient à croire que c’est la norme.
Jeune prof démissionnaire


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

Re: [FRnOG] [TECH][BGP] Traffic arrivant sur un seul lien au lieu de deux

[Willy Manga]

Bonjour,

On 09/06/2021 20:09, Mathieu KERN via frnog wrote:
> Bonjour a tous, 
> 
> J'ai un problème avec notre AS34536 que j'ai du mal a comprendre, nous avons 
> deux liens, avec cogent et SFR, et annonçons nos préfixes 80.77.225.0/24 et 
> 80.77.224.0/24 des deux cotés, en utilisant l'AS prepending pour ne faire 
> rentrer que l'un des prefixes pour chaque lien quand ils sont fonctionnels. 
> Le 224 passe par SFR ( AS1557) et le 225 devrais passer par cogent, mais ce 
> n'est pas le cas depuis plusieurs jours, alors que la configuration n'a pas 
> changé depuis des semaines.  
> 
> Hors en regardant plusieurs looking glass je ne vois pas de problème 
> d'annonces. J'ai même demandé a cogent, qui me confirme que eux même 
> reçoivent bien nos annonces BGP avec les bons chemins. 
> 
> Si quelqu' un peut m'orienter dans le bonne direction, je lui en serais 
> reconnaissant. 

Ce n'est pas forcément lié mais est-ce que vous pourriez aligner vos
annonces avec les objets route (dans la base  IRR du RIPE) ?

il y a présentement :
- 1 objet route pour 80.77.225.0/24 avec pour origine as12670
- aucun objet route ni pour 80.77.225.0/24 ou 80.77.224.0/24 avec pour
origine as34536

- pas de ROA aussi (mais ça peut être l'objet d'un autre débat)

-- 
Willy Manga
@ongolaboy
https://ongola.blogspot.com/



OpenPGP_signature
Description: OpenPGP digital signature

Re: [FRnOG] [TECH] [BGP] Traffic arrivant sur un seul lien au lieu de deux

[Emmanuel DECAEN]

Le 10/06/2021 à 01:15, Michel Py via frnog a écrit :
Comment expliquer que dans certains looking-glass (pas tous), on ne 
voit même pas ce chemin ? 


Peut-être sur la vérification de la route et de l'AS.

L'AS 34536 n'a pas d'objet route pour 80.77.225.0/24

$ whois -T route 80.77.225.0/24
route:  80.77.225.0/24
origin: AS12670
mnt-by: AS12670-MNT


$ whois -T route 80.77.224.0/24
route:  80.77.224.0/20
origin: AS12670
mnt-by: AS12670-MNT
mnt-routes: NEWEL-MNT

route:  80.77.224.0/20
origin: AS34536
mnt-by: NEWEL-MNT

Bonne journée.

--
*Emmanuel DECAEN*


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