Re: [FRnOG] [TECH] [Help]Problème d'OSPF cisco

2021-11-15 Par sujet Gregory CAUCHIE 
Bonjour Julien,

Quelle politique de Local-bref as-tu appliqué sur la redistribution OSPF > iBGP 
?
Peux-tu nous décrire un peu plus la boucle de routage en question ?

--
Greg

> On 15 Nov 2021, at 17:05, Julien CANAT via frnog  wrote:
> 
> Bonjour à tous,
> 
> 
> Nous rencontrons un problème avec l'un de nos clients multi-sites.
> 
> Ce client dispose d'une VRF dans notre MPLS. Les CPE des sites distants 
> (~80) annoncent leurs routes au routeur d'infra auquel ils sont 
> connectés en OSPF. Ces routes sont redistribuées en iBGP entre les 
> routeurs d'infra.
> 
> Entre les deux sites primaires du client, le client dispose d'une FON et 
> fait de l'OSPF pour assurer la redondance entre les sites primaires. Sur 
> les sites primaires l'annonce de routes entre CPE et routeur d'infra est 
> en iBGP. Entre le CPE et les routeurs du client il y a de la 
> redistribution en OSPF, la métrique est plus élevée sur le site 2 (1000) 
> au lieu du default (1).
> 
> Le problème que l'on rencontre est que parfois les routes au lieu 
> d'arriver sur le CPE-site1 sont apprises via l'OSPF du client et le 
> CPE-site2 ce qui a une tendance a créer une légère boucle de routage. Ce 
> problème se résout par un reset de l'OSPF sur le CPE-site1.
> 
> Les routeurs d'infra sont des ASR920, sur les sites primaires il y a des 
> C et l'un d'eux a été remplacé par un 1921 pour écarter le bug 
> matériel.
> 
> Quelqu'un aurait une idée d'où ce problème peut venir ? Serait-ce un bug 
> connu chez Cisco ?
> 
> Comme les pièces jointes sont interdites sur la liste : vous trouverez 
> un schéma ici : https://claude.trinaps.com/s/qx3gY6R5ecPTWAT (mdp: FRnOG).
> 
> J'ai enlevé les détails qui permettraient d'identifier ce client, pour 
> des raisons évidentes de discrétion, mais si certaines choses demandent 
> éclaircissement, je suis bien évidemment prêt à répondre.
> 
> D'avance merci.
> 
> -- 
> Julien CANAT
> 
> TRINAPS - Ingénierie Réseau
> 
> 
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/


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

Re: [FRnOG] [TECH] RE: BGP et /24

2021-10-27 Par sujet Gregory CAUCHIE 


> On 27 Oct 2021, at 17:04, David Ponzone  wrote:
> 
> On part bien sûr du principe qu’il a plusieurs FAI, car sinon BGP est futile.

Je ne te suis pas forcément sur ce point de détail. Dans le cas de deux liens 
avec le même FAI, BGP te permet de piloter une répartition de trafic pour un 
mode "actif-actif”.

--
Grégory

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

Re: [FRnOG] [TECH] RE: BGP et /24

2021-10-26 Par sujet Gregory CAUCHIE 



> On 26 Oct 2021, at 15:57, David Ponzone  wrote:
> 
> Ben tu renumérotes (un truc qu’on kiffe tous).
> Et éventuellement du NAT 1-1 pendant la transition.
> 
> 
>> Le 26 oct. 2021 à 15:51, BELLOTTO Louis  a écrit 
>> :
>> 
>> la moins bonne, c'est que j'ai 6 /27 chez plusieurs opérateurs.
>> sans surnetting possible.

Sans oublier de mettre en place/négocier du peering BGP pour ton nouveau /24 
sur tous tes liens opérateurs.

--
Grégory

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

Re: [FRnOG] [TECH] RE: BGP et /24

2021-10-26 Par sujet Gregory CAUCHIE 
Pour compléter : 

C.f. RFC 7454 §6.1.3 
(https://datatracker.ietf.org/doc/html/rfc7454#section-6.1.3 
). Cette RFC est dans la 
catégorie best practice.

L’équivalent pour IPv6 est le /48.

--
Grégory

> On 26 Oct 2021, at 15:45, BELLOTTO Louis  wrote:
> 
> OK, c'est plus clair et effectivement à l'extrème, si chacun fait du /32 ... 
> bonjour la taille des tables !
> Merci Laurent.
> 
> 
> 
> 
> -Message d'origine-
> De : frnog-requ...@frnog.org  De la part de Laurent 
> Guinchard
> Envoyé : mardi 26 octobre 2021 15:37
> À : frnog-al...@frnog.org
> Objet : [FRnOG] [ALERT] RE: BGP et /24
> 
> C'est une convention/une bonne pratique, sur Internet, les opérateurs ne 
> routent pas de subnet plus petit qu'un /24.
> Cela permet de ne pas faire exploser la taille de la full-view en 30sec. 
> Parce que oui, un /25 ou un /27 c'est possible techniquement ... au même 
> titre qu'un /32. 
> Mais si on se met tous à router des /32, la taille de la table sera tellement 
> grosse qu'on va casser pas mal de routeur sur Internet Il fallait donc fixer 
> une limite, et c'est donc /24.
> 
> NB : la full view est passe cette semaine à 900k routes sur CIDR-report ...
> 
> Cordialement,
> 
> Laurent GUINCHARD
> 
> 
> 
> 
> 
> -Message d'origine-
> De : frnog-requ...@frnog.org  De la part de BELLOTTO 
> Louis Envoyé : mardi 26 octobre 2021 15:27 À : frnog-al...@frnog.org Objet : 
> [FRnOG] [ALERT] BGP et /24
> 
> Hello,
> 
> Un fournisseur de service (protection ddos) qui me dit que pour pouvoir faire 
> du BGP sur nos liens Internet sur plusieurs datacenter, il nous faut des 
> étendues d'adresses IP en /24. J'ai un peu de mal avec cette affirmation et 
> je ne vois pas pourquoi avec un /25 ou /27 ça ne serait pas possible.
> 
> Bien sûr, le /24 est le plus répendu... mais bon. Pas sûr que tout le monde 
> puisse avoir et justifier de 254 adresses.
> 
> Un avis ?
> Merci.
> 
> 
> 
> 
> -
>  Ce message et toutes les pièces jointes sont confidentiels. Il est établi à 
> l'attention exclusive de son ou ses destinataire(s). Toute utilisation de ce 
> message non conforme à sa destination, toute diffusion, copie ou toute 
> publication, totale ou partielle, est interdite, sauf autorisation expresse 
> préalable. Son contenu ne saurait constituer en aucun cas un engagement 
> contractuel, une offre de souscrire à quelconque produit ou instrument 
> financier ou une sollicitation à investir de la part du Groupe La Française 
> et toutes opinions exprimées dans ce message ne sauraient nécessairement 
> refléter celle du Groupe La Française. Le contenu de cet email peut contenir 
> des virus informatiques qui pourraient endommager votre système informatique. 
> Bien que Groupe La Française ait pris toutes les précautions raisonnables 
> pour minimiser ce risque, nous déclinons toute responsabilité pour tout 
> dommage que vous pourriez subir en raison de virus informatiques. Si vous 
> recevez ce courriel par erreur, merci de le détruire et d'en avertir 
> immédiatement l'expéditeur. Nous vous invitons à prendre connaissance de 
> notre politique de confidentialité et de cookies en cliquant ici 
> https://www.la-francaise.com/fr/politique-de-confidentialite-et-de-cookies/ 
> -
>  This message and any attachments are confidential and may be legally 
> privileged or otherwise protected from disclosure. It is intended only for 
> the stated addressee(s). Any use, dissemination, copy or disclosure of this 
> message not in accordance with its purpose, either in whole or in part, is 
> prohibited without our prior formal approval. Its contents, given solely for 
> information, does not constitute a commitment or an offer to subscribe to any 
> financial product by La Française Group. Any opinion expressed in this email 
> may not necessarily reflect the opinion of La Française Group. The content of 
> this email may contain computer viruses that could damage your computer 
> system. Although La Française Group has taken all reasonable precautions to 
> minimize this risk, we decline any liability for any damage you may suffer 
> due to computer viruses. If you are neither the addressee nor an authorized 
> recipient of this message, please notify the sender of receipt immediately 
> and delete this message from your system. We invite you to read our privacy 
> and cookies policy available on the Group’s website by clicking here 
> https://www.la-francaise.com/en/privacy-and-cookies-policy/
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/
> 
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/
> 
> -
>  Ce

Re: [FRnOG] [TECH] OneAccess et leur doc plus secrète que le dossier JFK

2021-10-07 Par sujet Gregory CAUCHIE 
Salut David,

La politique Ekinops est effectivement de ne pas mettre la documentation en 
accès libre.

La logique de distribution des équipements OneAccess est que la doc est donnée 
avec la distribution de l’équipement. En tant que client identifié tu peux 
alors accéder à la base de doc sur leur site. Donc faudrait normalement que tu 
te retournes vers qui t’a procuré l’équipement.

--
Grégory

> On 7 Oct 2021, at 09:56, David Ponzone  wrote:
> 
> Amig[o|a]s Ekinopsie[n|ne]s,
> 
> J’ai récupéré un OneAccess que je dois configurer pour un client.
> C’est pas ma came ce truc là, moi je suis plutôt Patton.
> 
> Quelqu’un sait où je peux trouver la doc de leur OneOS bidule ?
> J’ai l’impression que c’est encore un de ces constructeurs qui croient qu’il 
> fabrique des équipements classés Secret-Défense.
> C’est horripilant.
> 
> Merci!
> 
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/


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

Re: [FRnOG] [TECH] Boîtiers de chiffrement sur câble Ethernet passant par milieu non fiable

2021-08-17 Par sujet Gregory CAUCHIE 
Thales (ex SAFEnet) propose ce genre de boîtier, mais le prix sera surement 
trop élevé vu que la perf permet de monter à très haut débit (quasi-)sans 
introduction de latence.

Autrement, pas possible de faire du MACsec entre tes switch ?

--
Grégory

> On 17 Aug 2021, at 19:13, Benoit Chesneau  wrote:
> 
> hrm pq ne pas mettre a un bout un simple proxy https et connecter les clients 
> en https dessus? la connection seraient ainsi chiffrée de bout en bout. avec 
> un boitier mikrotik a un bout. sinon deux boitiers mikrotik hex ou plus et un 
> tunnel?
> 
> Benoît Chesneau, Enki Multimedia
> 
> On Tue, Aug 17, 2021 at 18:37, DUVERGIER Claude 
>  wrote:
> 
>> Bonjour la liste,
>> 
>> J'aurais besoin de relier au réseau LAN un petit local un peu excentré des 
>> autres locaux de l'immeuble.
>> Problème : je dois passer par les parties communes de l'immeuble pour les 
>> relier...
>> 
>> Les besoins de débit sont très faibles (du web sur 4/5 stations de travail) 
>> donc un simple câble RJ45 suffira, mais avoir mon LAN qui sort, en clair, de 
>> "ma propriété" n'est pas une option.
>> 
>> Je cherche donc 2 boîtiers à placer de part et d'autres du câble pour 
>> assurer un chiffrement des communications qui y transite.
>> 
>> La solution basique mais qui nécessite de la maintenance : 2x mini ordis 
>> avec 2 port Ethernet + du OPNsense qui chiffre/déchiffre le trafic (via 
>> IPSec, OpenVPN, etc.) pour faire routeur entre les 2.
>> 
>> Ça représente environ 560€ avec des APU2E0 de PC Engines, et moins si je 
>> trouve des ordis plus simples et/ou de récup'.
>> 
>> Sinon je fais un pont WiFi (via. 2 bornes Ubiquiti par exempe)... qui offre 
>> son chiffrement, mais c'est quand même ballot d'utiliser le 802.11 juste 
>> pour sa capacité à chiffrer alors que j'ai la possibilité de tirer un câble 
>> cat 7. Là par contre le coût baisse trs fortement.
>> 
>> Mais je me dit que ça doit bien exister en boîtier tout fait/dédié, pour 
>> moins cher...
>> 
>> Le plus proche que j'ai trouvé via mon Google-fu c'est ce "IP-DOOR" de CXR 
>> Anderson Jacobson : https://www.cxr.com/documents/brochures/ip_door.pdf
>> Mais le produit ne semble plus en vente...
>> 
>> Bref : auriez-vous un produit magique similaire en tête ?
>> 
>> Merci
>> 
>> --
>> DUVERGIER Claude
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/


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

Re: [FRnOG] [MISC] SDN (Software Defined Networking): Bullshit ou réalité ?

2021-06-15 Par sujet Gregory CAUCHIE 
Message de Julie : « il semble que je rencontre un petit problème avec ma 
messagerie. Peux-tu prévenir la liste ? »

La bonne nouvelle pour elle c’est qu’après un message encore vide j’ai enfin 
reçu du texte :)

--
Grégory


> Le 15 juin 2021 à 02:44, Michel Py  a 
> écrit :
> 
>> Michel Hostettler a écrit :
>> Le mail est si sécurisé qu'il ne porte aucune information nouvelle.
> 
> C'est comme les SMS : pour éviter que l'information ne fuite, on n'en met pas 
> :P
> 
> J'ai eu la même chose.
> 
> Michel.
> 
> - Mail original -
> De: "Julie" 
> À: "Gregory CAUCHIE" 
> Cc: "Michel Hostettler" , "frnog" 
> 
> Envoyé: Vendredi 11 Juin 2021 17:54:03
> Objet: Re: [FRnOG] [MISC] SDN (Software Defined Networking): Bullshit ou 
> réalité ?
> 
> Sent with ProtonMail Secure Email.
> 
> ‐‐‐ Original Message ‐‐‐
> 
> On Wednesday, June 9th, 2021 at 10:53 PM, Gregory CAUCHIE 
>  wrote:
> 
>> Bonsoir Michel,
>> 
>> serait-il possible de reformuler la nuance dans le terme « approche » ? 
>> désolé mais je n’ai pas bien saisi.
>> 
>> En tentative de réponse TL/DR, SASE de mon point de vue orthogonal à SD-WAN.
>> 
>> SASE c’est une vision d’architecture orientée sécurité, la « spécificité » 
>> de SASE étant de gérer la politique de sécurité de manière cohérente (i.e. 
>> avec une gestion centralisée et une orchestration) sur tous des différents 
>> points de connectivité WAN, y compris les nomades.
>> 
>> Les conférences de SD-WAN se sont mis à parler de SASE parce qu’à partir du 
>> moment où tu fais du local-breakout sur tes sites distants avec le SD-WAN, 
>> il te faut gérer la sécurité sur ces sites distants, non plus avec un simple 
>> FW pour n’autoriser que ton IPSec, mais comme tu le fais sur ton DC/GW 
>> Internet. À côté de cela, étaient offerts sur le marché les solution 
>> SD-Access/SD-LAN qui, sans parlé de marketing, mettaient en avant les 
>> notions sécurité dite « Zero-Trust » avec une gestion par orchestration dans 
>> les campus. De fil en aiguille, Gartner a créé en 2019 cette notion de SASE 
>> qui « package » tout cela, i.e. les concepts de Zero-Trust, de sorties WAN 
>> sur chaque site et utilisateur en remote (‘distributed doors’), et 
>> d’orchestration.
>> 
>> À lire la définition du Gartner, il y a forcément du SD-WAN dans 
>> l’architecture SASE… qui au final ressemble à un méga silo (pour ne pas dire 
>> vendor-lock) de quasi toutes tes briques de sécurité, voire potentiellement 
>> aussi de routage. Les trafics couverts par l’architecture sont l’Est-Ouest 
>> ainsi que la partie flux sortante vers l’Internet des flux Nord-Sud (i.e. 
>> les WAF, DMZ et autres flux entrants Nord-Sud hors VPN ne sont pas 
>> concernés).
>> 
>> Après, l’histoire se répétant, des offres constructeurs créent des « 
>> sous-types » d'architecture SASE. SASE (prononcé « sassy » pour celles/ceux 
>> qui se demanderaient) signifie ’Secure Access Service Edge’, et comme pour 
>> le SDN par exemple, on peut proposer bon nombre d’architecture rentrant dans 
>> ce terme sans pour autant suivre la vision du Gartner. Bilan de ce qu’on a 
>> pu voir par exemple à la dernier « SASE conference 2021 » de mai, les 
>> vendors se basent au f

Re: [FRnOG] [TECH] Système pour gérer les mots de passe 'dernier recours' de vos équipements

2021-06-11 Par sujet Gregory CAUCHIE 



> Le 11 juin 2021 à 16:02, Benoît Grangé  a écrit :
> 
> Mais comment gérez-vous les comptes de 'dernier recours', les comptes
> 'Administrator", les mots de passe 'enable' de vos nombreux d'équipements
> pour qu'ils restent un tant soit peu confidentiels, qu'ils soient
> renouvelés quand un admin s'en va, et que cela supporte une mise à
> l'échelle raisonnable ?
> 
> Avez vous un "cahier bleu" (Paul... si tu me lis) , un KeePass, une vraie
> solution de PAM qui ne vous coûte pas un bras ?

J’ai eu à utiliser pass (https://www.passwordstore.org/) dans une vie 
précédente, je ne le recommanderais pas car on a eu plusieurs petites galères 
d’administration.

J’ai vu des gens tout mettre dans un fichier, chiffré avec ansible vault, et 
mis dans un git. Le retour était négatif s’il y a bon nombre de credentials à 
écrire, et/ou que plusieurs personnes doivent faire des modifs.

Mes 2 préférés pour le moment sont Netbox (un IPAM/DCIM qui propose aussi de 
gérer des ‘secrets’), ou un Key-Value Store type Hashicorp Vault.

Pour la mise à jour, tu couples n’importe lequel de ces éléments avec un outil 
de configuration type playbook ansible, et le tout est joué.

--
Grégory

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

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

2021-06-11 Par sujet Gregory CAUCHIE 



> Le 11 juin 2021 à 07:29, Michel Py  a 
> écrit :
> 
>> 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.

pardon, le « normalement » était mal utilisé. Ceux qui font des 
policy/route-map sur la base de communauté n’ont pas de problème sur un préfixe 
qui manquerait parmi plusieurs. Ils peuvent avoir un problème uniquement pour 
toutes les annonces d’un peer si la config est mauvaise. C’est du tout ou rien.
Pour ceux qui en revanche seraient toujours en policy/route-map avec des 
préfixes (j’ai du mal à y croire mais je ne sais pas aujourd’hui assurer que 
cela n’existe pas), là il pourrait y avoir un oubli.
Rien « d’élastique » du coup dans la norme, seule les différences de 
configuration parmi les multiples AS traversés par une annonce BGP peut induire 
un comportement non homogène.


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

Par routeur interne tu penses aux route-reflector j’imagine. Si oui et pour le 
coup le RR a, sans fonctions BGP add-apth, une meilleure vision globale du 
réseau vu qu’il centralise toutes les informations avant de les redistribuer. 
Le PE a quant à lui la granularité des échanges e-BGP en son sein. Bref, sans 
add-path il est de toute façon impossible d’avoir la totalité des routes 
disponibles dans un seul routeur, ainsi est fait BGP. Et du coup, si tu vas sur 
le looking glass par exemple de Washington DC (RR ou pas), et que les préfixes 
recherchés sont échangés sur des peering à Dallas et New-York, interviendra 
forcément le coût IGP dans la sélection de routes.

Les communautés ou autre policy/route-map ne changent rien à la diversité de 
chemin dans le looking glass. Cette diversité va dépendre de ce que la commande 
du routeur retourne, et donc des paramètres BGP activées ou non (ECMP, 
best-external, add-path, …).

--
Grégory

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

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

2021-06-10 Par sujet 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][BGP] Traffic arrivant sur un seul lien au lieu de deux

2021-06-10 Par sujet 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/

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

2021-06-09 Par sujet Gregory CAUCHIE 



> Le 9 juin 2021 à 23:29, Radu-Adrian Feurdean  
> a écrit :
> 
> On Wed, Jun 9, 2021, at 18:32, Raphael Mazelier wrote:
>> influencer le trafic in 
> 
> De base, on ne peut *PAS* influencer le trafic in. 
> On peut juste exprimer des souhaits sur les chemins qu'on prefere, souhaits 
> que les reseaux qui envoient du trafic peuvent respecter ou non, selon leur 
> propre politique.
> Cette situation ne manque pas de se montrer quand on a des transitaires avec 
> des profils differents (ex. "tier-1" restrictif combine avec "tier-2" plus 
> ouvert sur l'interco).
> Faut toujours se rappeler que la "LocalPref" (et le "weight") sont 
> prioritaires dans la decision de routage par rapport a la taille de 
> l'AS-path. Et la LocalPref est generalement configure sur des criteres que tu 
> auras du mal a influencer.

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. 

Attention après à ne rien annoncer de plus spécifique qu’un /24 pour l’IPv4, 
certains peers les acceptent mais ne les redistribuent jamais. Donc utiliser 
des /25 peut se faire, si le peer est d’accord, uniquement pour répartir le 
trafic entre deux liens d’un même provider, et ce quelle que soit son 
ingénierie de sélection du best-path BGP.

--
Grégory

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

Re: [FRnOG] [MISC] SDN (Software Defined Networking): Bullshit ou réalité ?

2021-06-09 Par sujet Gregory CAUCHIE 
Bonsoir Michel,

serait-il possible de reformuler la nuance dans le terme « approche » ? désolé 
mais je n’ai pas bien saisi.

En tentative de réponse TL/DR, SASE de mon point de vue orthogonal à SD-WAN. 

SASE c’est une vision d’architecture orientée sécurité, la « spécificité » de 
SASE étant de gérer la politique de sécurité de manière cohérente (i.e. avec 
une gestion centralisée et une orchestration) sur tous des différents points de 
connectivité WAN, y compris les nomades. 
Les conférences de SD-WAN se sont mis à parler de SASE parce qu’à partir du 
moment où tu fais du local-breakout sur tes sites distants avec le SD-WAN, il 
te faut gérer la sécurité sur ces sites distants, non plus avec un simple FW 
pour n’autoriser que ton IPSec, mais comme tu le fais sur ton DC/GW Internet. À 
côté de cela, étaient offerts sur le marché les solution SD-Access/SD-LAN qui, 
sans parlé de marketing, mettaient en avant les notions sécurité dite « 
Zero-Trust » avec une gestion par orchestration dans les campus. De fil en 
aiguille, Gartner a créé en 2019 cette notion de SASE qui « package » tout 
cela, i.e. les  concepts de Zero-Trust, de sorties WAN sur chaque site et 
utilisateur en remote (‘distributed doors’), et d’orchestration.

À lire la définition du Gartner, il y a forcément du SD-WAN dans l’architecture 
SASE… qui au final ressemble à un méga silo (pour ne pas dire vendor-lock) de 
quasi toutes tes briques de sécurité, voire potentiellement aussi de routage. 
Les trafics couverts par l’architecture sont l’Est-Ouest ainsi que la partie 
flux sortante vers l’Internet des flux Nord-Sud (i.e. les WAF, DMZ et autres 
flux entrants Nord-Sud hors VPN ne sont pas concernés).

Après, l’histoire se répétant, des offres constructeurs créent des « sous-types 
» d'architecture SASE. SASE (prononcé « sassy » pour celles/ceux qui se 
demanderaient) signifie ’Secure Access Service Edge’, et comme pour le SDN par 
exemple, on peut proposer bon nombre d’architecture rentrant dans ce terme sans 
pour autant suivre la vision du Gartner. Bilan de ce qu’on a pu voir par 
exemple à la dernier « SASE conference 2021 » de mai, les vendors se basent au 
final sur leurs forces/stratégies pour décliner leurs offres de SASE avec ou 
non des version Cloud, sur site, incluant tel ou tel lot de fonctions de sécu 
(CASB, FWaaS, DLP, ZTNA, …) et du SD-WAN ou pas nécessairement. 

Bref, la « réalité » est en pleine construction, et comme d’hab le marché fera 
juge de paix… la suite donc au prochain épisode :)

--
Grégory

> Le 7 juin 2021 à 15:35, Michel Hostettler 
>  a écrit :
> 
> Bonjour Gregory,
> 
> Faites-vous une différence entre une approche SASE et une approche SD-WAN.
> 
> Je préfère utiliser le terme "approche" comme une façon d'aborder la réalité 
> (les connectivités), plutôt que "technologie".
> 
> Michel
> 
> - Mail original -
> De: "Gregory CAUCHIE" 
> À: "Michel Hostettler" 
> Cc: "Benjamin CALLAR" , "GUILLAUME Cyrille" 
> , "frnog" 
> Envoyé: Lundi 31 Mai 2021 17:12:24
> Objet: Re: [FRnOG] [MISC] SDN (Software Defined Networking): Bullshit ou 
> réalité ?
> 
>> Le 31 mai 2021 à 16:34, Michel Hostettler 
>>  a écrit :
>> 
>> Bonjour,
>> 
>> Je suis toujours à la recherche de définitions, qu'elles soient techniques, 
>> managériales ou philosophiques.
>> 
>> Pour SD-WAN, je me suis construit cette définition (au sens du QUOI, et non 
>> du COMMENT).
>> 
>> "L’approche SD-WAN permet de gérer en local des connectivités internet 
>> globales, à l’aide de fonctions génériques, banalisées. Un réseau virtuel 
>> est créé, qui masque les détails du réseau physique, plus complexe. 
>> L’approche met à profit une couche logicielle intelligente, permettant à 
>> l’utilisateur de s’abstraire des contraintes matérielles sous-jacentes".
> 
> Je te proposerais :
> « Le SD-WAN est une technologie de gestion de la connectivité Internet et 
> inter-sites d'une entreprise, basée sur un ensemble hétérogène d'offres 
> opérateurs. Cette connectivité dispose a minima d'une classification de flux 
> par application, d’une mesure de performance des liens de connectivité, et 
> d’un routage des flux par application et par niveau de performance des liens 
> » 
> 
>> Une définition n'élime pas les difficultés pour la mettre en œuvre.
> 
> +1
> 
>> 
>> Michel
> 
> --
> Grégory


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

Re: [FRnOG] [MISC] SDN (Software Defined Networking): Bullshit ou réalité ?

2021-05-31 Par sujet Gregory CAUCHIE 



> Le 31 mai 2021 à 16:57, Erwan David  a écrit :
> 
> Le 31/05/2021 à 16:34, Michel Hostettler a écrit :
>> Bonjour,
>> Je suis toujours à la recherche de définitions, qu'elles soient techniques, 
>> managériales ou philosophiques.
>> Pour SD-WAN, je me suis construit cette définition (au sens du QUOI, et non 
>> du COMMENT).
>> "L’approche SD-WAN permet de gérer en local des connectivités internet 
>> globales, à l’aide de fonctions génériques, banalisées. Un réseau virtuel 
>> est créé, qui masque les détails du réseau physique, plus complexe. 
>> L’approche met à profit une couche logicielle intelligente, permettant à 
>> l’utilisateur de s’abstraire des contraintes matérielles sous-jacentes".
>> Une définition n'élime pas les difficultés pour la mettre en œuvre.
>> Michel
> 
> Je change une local-pref sur mon BGP : est-ce du SD-Wan ?

tout dépend de comment tu l’as changé.

option a : Tu te connectes en CLI, passe en mode config puis tu commit —> c’est 
pas du SDN

option b : t’as changé un truc dans un fichier ou une base de donnée, ça passe 
par l’usine logicielle de CI/CD puis si tout est ok ça part en prod —> c’est du 
SDN sauce CI/CD

option c : t’es passé par un truc genre playbook Ansible pour redéployer ta 
config —> moi je dirais que c’est le début du SDN, mais c’est perso, pas sûr 
qu’il y ait une démarcation claire là-dessus

—
Grégory


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

Re: [FRnOG] [MISC] SDN (Software Defined Networking): Bullshit ou réalité ?

2021-05-31 Par sujet Gregory CAUCHIE 


> Le 31 mai 2021 à 16:34, Michel Hostettler 
>  a écrit :
> 
> Bonjour,
> 
> Je suis toujours à la recherche de définitions, qu'elles soient techniques, 
> managériales ou philosophiques.
> 
> Pour SD-WAN, je me suis construit cette définition (au sens du QUOI, et non 
> du COMMENT).
> 
> "L’approche SD-WAN permet de gérer en local des connectivités internet 
> globales, à l’aide de fonctions génériques, banalisées. Un réseau virtuel est 
> créé, qui masque les détails du réseau physique, plus complexe. L’approche 
> met à profit une couche logicielle intelligente, permettant à l’utilisateur 
> de s’abstraire des contraintes matérielles sous-jacentes".

Je te proposerais :
« Le SD-WAN est une technologie de gestion de la connectivité Internet et 
inter-sites d'une entreprise, basée sur un ensemble hétérogène d'offres 
opérateurs. Cette connectivité dispose a minima d'une classification de flux 
par application, d’une mesure de performance des liens de connectivité, et d’un 
routage des flux par application et par niveau de performance des liens » 

> Une définition n'élime pas les difficultés pour la mettre en œuvre.

+1

> 
> Michel

--
Grégory

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

Re: [FRnOG] [MISC] SDN (Software Defined Networking): Bullshit ou réalité ?

2021-05-31 Par sujet Gregory CAUCHIE 
Bonjour,

> Le 28 mai 2021 à 17:15, Kévin CHAILLY  a écrit :
> 
> Alors sans doute, il y a le bon et le mauvais SDN, mais j'aimerais bien qu'on 
> arrête de me vendre un concept magique et qu'on explique quelles solutions 
> apporte à quel problème un produit donné, et qu'on arrête les management 
> centralisés obligatoires et autre abonnement 
> si-tu-le-prends-pas-je-route-plus-tes-paquets, je veux avoir le choix 
> d'arrêter de payer le vendeur si le service n'est pas rendu, car j'ai déja 
> payé le produit.


Salut Kévin, dans ce cas ce n’est pas le SDN que tu dois balayer, mais juste le 
commercial :). SDN n’implique pas de routage centralisé, quant au management 
centralisé faut rentrer plus dans le détail de ce qui changerait je pense car 
je trouve que le management des réseaux à toujours été en quelque-sorte 
centralisé dans la zone Syslog/SNMP/Bastion.

> Au final, certaines solutions pourtant pertinentes technologiquement se font 
> éconduire a la porte car apportant plus de restrictions que d'avancées. 
> Ouaip, c'est bien de faire du CI/CD et de lâcher la CLI, mais l'obliger, je 
> veux que ce soit ma décision et pas celle du vendeur alors que rien ne le 
> justifie technologiquement. 

Bah là pour le coup je veux bien une explication car je ne vois pas comment 
l’un peut fonctionner sans l’autre. Du moins, je ne vois pas comment tu peux 
faire de « Continuous Deployment » dans ce cas.
Si tu utilises CI/CD jusqu’au Continuous Delivery, effectivement tu n’est pas 
obligé de changer tes habitudes de prod en CLI. Mais pour le coup tu n’as rien 
gagné, et je dirais même que tu as surtout perdu ton temps, car ta phase 
d’ingénierie restera complètement décorrélée de la vie de ta prod… c’est 
d’ailleurs le cas de figure qui historiquement a fait émerger la culture 
DevOps, vu que les XP/Agile/etc sortaient très vite des trucs tout beau tout 
chaud mais qui ne pouvaient jamais aller en prod. Donc pour réussir in fine à 
faire du CI/CD jusqu’à la prod, faut respecter le concept de ‘cattle’ qui dit 
en gros qu’on ne touche à la config des équipements en CLI qu’en phase de 
développement (i.e. avant les tests).

> Moi, j'aime bien openvSwitch, en plus y'a pas SDN dans le titre, ni dans la 
> description, c'est open, c'est virtual, c'est un switch. même le titre 
> apporte une réponse a une problématique donnée, 

c’est marrant comme exemple car openvSwitch a une API pour faire du SDN, et 
notamment faire de l’openFlow avec OVSDB qui est donc du tout centralisé… mais 
on peut aussi y faire du SDN autrement (i.e. non centralisé), voire ne pas en 
faire du tout, comme quoi ce sujet de SDN n’est pas si « noir et blanc » que ça.



> Le 28 mai 2021 à 18:28, Michel Py  a 
> écrit :
> 
> C'est une bière très chère, mais quand tu veux !

Salut Michel, noté :)

> Fast-forward 3 mois plus tard, le vendeur de pompes usées évidemment ce n'est 
> plus son problème dès que la commande est passée, et qui c'est qui se 
> retrouve baisé à essayer de faire marcher la bouse très chère qui non 
> seulement ne sert à rien mais en plus double la complexité de l'usine à gaz ? 
> ben c'est David et Michel, entre autres.

Malheureusement du Business As Usual dans beaucoup (trop) de boîtes, et ce pour 
tout type de trucs à vendre, non ? je vois en tout cas dans ton argument plutôt 
une problématique entre tech et direction qu’une problématique de technologie.
Et en témoignage, je peux dire ne pas avoir vu de « double » complexité. Mais 
il y a bien une complexité à gérer, à savoir celle de pouvoir maîtriser 
l’ensemble des éléments de routage et de sécurité, voire également de 
virtualisation. Bref ce qu’on avait avant en plusieurs boîtes, voire réparti 
sur deux équipes, on l’a ici nécessaire chez une seule personne. Donc un sujet 
de compétence et donc de formation.



> Le 31 mai 2021 à 14:54, Benjamin CALLAR  a écrit :
> 
> Je suis d'ailleurs curieux (sans trahir de secret), de savoir quelles 
> solutions techniques sont mises en place ? Ça semble joli à voir :)
> 
> Je suis malheureusement forcé de constater que grand nombres de solutions 
> "SD-WAN" ne permettent uniquement que de faire du Policy-Based Routing 
> statique et manuel au dessus d'un VPN IPSec (parfois même, ce n'est pas 
> compris) ... mais le terme SD-WAN se vends plus cher ;)

Cyrille infirmera peut être mes propos, mais cela semble être en grande partie 
du « standard SD-WAN » avec du DPI pour la catégorisation du trafic, un 
mécanisme de mesure de SLA des tunnels (type BFD ad-hoc ou mesure OAM des 
paquets data), et une configuration par l'administrateur de « poids métier » + 
seuil de reroutage par application.
Là où il semble y avoir une fonction que tous n’ont pas, c’est la possibilité 
de rerouter via un site de transit (i.e. pas un autre provider pour aller de A 
à B mais de faire A-C-B, où C est un site SD-WAN).

--
Grégory

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

Re: [FRnOG] [MISC] SDN (Software Defined Networking): Bullshit ou réalité ?

2021-05-28 Par sujet Gregory CAUCHIE 
Bonjour,

au risque d’être vu pour ce que je ne suis pas, je reprend ci-dessous un 
extrait d’une autre discussion FRnOG de ce jour en lien avec l’objet de cette 
discussion. 

> Le 28 mai 2021 à 08:59, David Ponzone  a écrit :
> 
> 
>> Le 28 mai 2021 à 08:23, Michel Py  a 
>> écrit :
>> 
>> 
>> Yàkà acheter la solution SD-WAN et laisser le clickodrome automagique tout 
>> faire :P C'est démodé, ton modèle : laisser l'ingénieur réseau faire de la 
>> configuration ? pfff.
>> 
> 
> Ouais et avec un peu de chance, ça fait comme Kosc: ça pousse une mauvaise 
> conf sur tout le backbone et tu dois envoyer des techs dans la nuit pour 
> restaurer :)



Il y a deux choses qui me donnent envie de réagir à cet extrait.

La première chose nest pas d’être contre David ni Michel, je ne les connais pas 
d'ailleurs et ces échanges me font dire que je prendrais bien une bière avec 
eux, dès qu’on pourra, pour faire connaissance et alimenter la discussion :). 
C’est plutôt de tenter de comprendre d’où vient cette croyance que dans SDx 
(pour faire court) il n’y a plus de gens du réseau réseau qui contrôlent, font 
des choix, debug ni tordent le truc au plus proche de ce qu’ils souhaitent ?
Pour ma part en tout cas, je n’ai jamais vu d’offre d’IA capable de générer 
toute seule une configuration réseau capable de répondre à la demande du DSI, 
métier, ou autre réseau-phobe… donc il est et reste toujours besoin d'au moins 
un(e) barbu(e) qui s’y colle quoi qu’il arrive, de l’étape de design au 
troubleshooting. Si l’on fait une archi SDN à base de netbox + jenkins|AWX + 
ansible, comme la contribution récente de Jerikan par exemple, impossible de la 
réaliser sans personnes du réseau. Idem si l’on fait du SDN à la mode OpenFlow, 
ou en SD-WAN, faut bien des connaissances réseau pour gérer la configuration du 
système de connectivité. Et puis les clickodrome qui génèrent de la config 
datent de bien avant le SDN, par exemple sur les ASA et catalyst pour ne citer 
qu’eux.
Est-ce au final une « peur » de ne plus avoir d’accès CLI ? Le SDN n’implique 
pourtant pas la fin complète et définitive du CLI mais pousse, comme le monde 
des admin-sys l'a adopté en majorité, à un CLI restreint à l’accès en lecture 
et avec une poussée des config via le CI/CD pour tracer les changements et 
éviter au maximum de pousser une connerie (car dans SDN il n’y a pas de 
fonction auto-magique de prévention des bêtises, cette pseudo-fonction est le 
résultat de l’expérience des gens mise sous code pour jouer des tests de 
non-régression de façon systématique). Comment l’expliquez-vous ?

La deuxième chose qui me donne envie de réagir, c’est que pendant ce temps là 
on ne parle pas de tout le lot de problèmes et de questions qui restent ouverts 
avec le SDN « d’aujourd’hui ». On a un peu évoqué le vendor-lock… sujet qui ne 
date pas du SDN/SD-WAN et qui reste un sujet important. On ne parle pas de nos 
outils de management et leurs IHM qui, d’aussi loin que ma mémoire remonte 
(i.e. HP-NM), nous font râler au quotidien. Le SD-WAN n’en est pas exempt. Etc. 
Bref on ne parle pas, du moins je ne le vois pas et je suis preneur de 
correction si je me trompe, de comment on arrive à se simplifier la tâche au 
quotidien pour un réseau qui donne plus de satisfaction qu’il ne le faisait 
hier… et qui arrête d’être le coupable tout désigné dès que ça toussote 
quelque-part. Vous partagez cet avis ?

--
Grégory

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

Re: [FRnOG] [MISC] SDN (Software Defined Networking): Bullshit ou réalité ?

2021-05-25 Par sujet Gregory CAUCHIE 
Bonjour,

> Le 23 mai 2021 à 18:28, David Ponzone  a écrit :
> 
> Pour compléter ce que tout le monde dit, plein de choses pertinentes 
> d’ailleurs, j’ai un peu de mal avec l’aspect nécessairement centralisé du SDN.

De quelle centralisation parles-tu exactement David ? celle du « management » 
d'où on pousse les config ? celle de la connaissance et de la prise de décision 
du routage/switching à effectuer ? autre ?
Mis à part une utilisation d’openFLow, qui peut se justifier ci ou là, et donc 
une centralisation de la connaissance et du calcul du routage, je ne vois pas 
personnellement pas de relation bijective entre SDN et centralisation.


> Le 23 mai 2021 à 17:26, Hosman Beyrouti  
> a écrit :
> 
> Mais la question de pourquoi on appel cela SDN maintenant?
> 
> Personnellement j'appel cela une Infrastructure DevOps.

Un nouveau vaste sujet, quelle définition pour DevOps :)

Moi je vois le DevOps (et ses consorts NetOps, NetDevOps, SecOps, NetSecOps, …) 
comme une _culture_ qui utilise typiquement « Agile » comme méthodologie 
(Scrum, XP, …) de coordination et le CI/CD comme outillage de déploiement 
d’infrastructures As Code. Bref comme des principes de travail et 
d’organisation.
Le SDN pourrait être le pan réseau dans l’infrastructure as Code, mais comme on 
a pu le parcourir dans ce thread, le mot SDN est aussi utilisé dans des cas 
sans infra as code. Ce constat peut se décliner aussi d'ailleurs sur le 
stockage (Software Defined Storage) et les serveurs (Software Defined Compute).
Bon je suis pas mal niveau bingo d’acronyme, je vais m’arrêter là 

--
Grégory

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

Re: [FRnOG] [MISC] SDN (Software Defined Networking): Bullshit ou réalité ?

2021-05-22 Par sujet Gregory CAUCHIE 


> Le 21 mai 2021 à 10:59, Xavier Beaudouin  a écrit :
> 
> Après le jour où le machin se fracasse ou que la license est venue a 
> expiration, on peux très vite sortir le camion a popcorn et attendre qu'on 
> appelle un dino pour réparer le merdier.
> 
> Le cote gênant, c'est surtout le coté privateur de cette mode aka vendor 
> locked.

Je suis en phase avec l’argument du vendor-lock. On peut argumenter 
qu’aujourd’hui on a déjà du vendor-lock quand on utilise des fonctions type 
MC-LAG ou HA dans le BNG (PPP, DHCP, …), mais c’est un périmètre moins étendu 
que toute la solution SD-WAN, i.e. la totalité des équipements et du 
manager/orchestrateur.
Aussi, il y a une solution OpenSource SD-WAN (cf. FLexiWAN) dont 
l’implémentation équipement est effectivement opensource mais dont le 
manager/orchestrateur est propriétaire. Le vendor lock est donc moindre du fait 
qu’on est dans un univers Linux où on peut compléter le SD-WAN « basique » avec 
ce qu’on veut d’autre. Reste toujours ce vendor-lock du manager/orchestrateur 
aujourd’hui inhérent au SD-WAN, sans de grosses chances que cela change dans le 
futur.

Pour la partie licence en revanche, beaucoup de constructeur ont une solution 
où l’expiration de la licences ne provoque pas l’arrêt de la solution. Il n’y a 
simplement plus de support dans ces cas là. Pour d’autres en revanche, tout 
s’arrête et le hardware devient clairement inutilisable. Ce point licence se 
juge donc en fonction du constructeur.


> Le 21 mai 2021 à 13:04, Pierre Colombier via frnog  a écrit :
> 
> J'attends avec impatience le syndrome de la poule et de l'oeuf.
> Quand le déploiement automatisé du "software defined" reposera sur lui-même, 
> et qu'il faudra reseter l'ensemble parce que la manager s'est fait hacker, ça 
> promet d'être un spectacle amusant…

Rien de différent avec ce qui se fait actuellement non ? qui n’a jamais poussé 
une « grosse bêtise » dans un script appliqué à beaucoup de machines ? le SDN 
ce n’est pas de l’IA (avec tout ce qu’on pourrait en dire de pour et contre), 
donc reste toujours la qualité de ce qui est poussé, niveau 
architecture-ingénierie-configuration. L’avantage d’un SDN utilisant les 
concept de CI/CD, c’est de pouvoir détecter le plus possible d’erreurs avant 
déploiement, voire de faire très vite un retour arrière dès la première erreur 
poussée, et donc de limiter le plus possible la casse.


> Le 21 mai 2021 à 11:33, Marc Abel  a écrit :
> 
> Pardonnez ma méfiance envers la centralisation du control-plane mais j'ai 
> déjà subi des déboires à cause de technos censées fiabiliser le réseau...
> Certains d'entre vous ont-ils eu des serveurs injoignables parce que le HA 
> foirait ? ou avec HSRP/VRRP/load ballancer/ etc. quelle que soit la cause.


Oui. Le cas le plus simple est quand tu as un problème sur le Tx d’un des 
routeurs, amenant la situation où les deux passent en master. Dans ce cas pas 
de soucis sur les flux upstream serveur vers extérieur, mais problème sur les 
flux downstream, avec autant de différents impacts que d’ingénierie en place.


> Le 21 mai 2021 à 12:42, Benjamin CALLAR  a écrit :
> 
> En ce qui concerne le SD-WAN, simple Bullshit ... faire du routage 
> intelligent, ce n'est pas nouveau, et ça ne se vends pas aussi cher ! 

Certes le routage intelligent n’est pas nouveau, mais SD-WAN ne se résume pas à 
ça. Les Ipanéma, Riverbed, SilverPeak, Streamcore and Co ont du ajouter faire 
du dev a minima pour la montée de tunnels et pour mettre en place et coupler 
des mécanisme de mesure de bout-en-bout sur le tunnel pour prendre en compte 
les comportement du WAN et surtout des différents débits de l’accès distant.

--
Grégory

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

Re: [FRnOG] [MISC] SDN (Software Defined Networking): Bullshit ou réalité ?

2021-05-21 Par sujet Gregory CAUCHIE 
Erratum, "un nouveau paradigme d’exploitation" et non "un nouveau paradigme 
d’innovation", sorry

> Le 21 mai 2021 à 09:54, Gregory CAUCHIE  a écrit :
> 
> Salut Michel,
> 
>> Le 21 mai 2021 à 07:09, Michel Py  a 
>> écrit :
>> 
>> Je prétends pas être psy, mais dans les contribs de mes co-listiers, dont 
>> certains je me sens proche et d'autres carrément pas, j'ai lu toute la gamme 
>> entre "ras-le-bol" et "plein-les-c..."
>> Là ou ça devient intéressant, ce n'est pas les gens qui sont d'habitude 
>> d'accord avec moi, mais ceux avec qui je n'ai pas ou peu d'atomes crochus. 
>> Et dont certains, comme tu le dirais, on jeté le bébé avec l'eau du bain.
> 
> Je ne pense pas avoir compris ton point.
> 
> 
>> Le problème que j'ai avec SDN (plus du coté sysadmin) et SD-WAN (plus du 
>> coté netadmin) c'est que en fait, ça n'existe pas. Aucune innovation, que 
>> des technologies qui existaient bien avant que le marketing n'invente le 
>> nouveau buzzword à la mode, bref c'est un ramassis de conneries
> 
> Pour avoir fait sur le terrain pas mal d’années de pousse paquet, plusieurs 
> années de "SDN" et un peu d’années de SD-WAN, je ne peux qu’être en désaccord 
> sur le fait que ça n’existe pas. 
> Le SDN n’est pas forcément qu’une histoire pour les sysadmin faisant de 
> l’hébergement voire avec du cloud par-dessus. Ça se décline aussi sur le 
> pousse-paquet des familles.
> Le SD-WAN n’est pas essentiel, le routage dynamique non plus après tout, je 
> ne compte plus le nombre de réseaux d’ETI en routage statique. C’est juste 
> une histoire classique de complexité à opérer, d’impact ou non sur le 
> business et de sous-sous. Dans le cas du SD-WAN, si t’as une problématique de 
> bande-passante et de priorisation de flux que DSCP seul ne peux gérer (pour x 
> raisons), tu peux soit payer un x10 de bande-passante et souvent ne pas voir 
> d’amélioration (vu chez des clients), soit te monter tout seul ton mélange de 
> VPN, de DPI et de routage sur la base de qualité de transport de tes tunnels 
> (beau challenge), soit prendre le produit packagé sous label SD-WAN. 
> 
> Quant à l’innovation, je pense qu’on a aussi ici une problématique de 
> définition. À partir de quel moment une solution est-elle innovante ? quel 
> seuil pour parler de « révolution" ? MPLS a eu un énorme impact sur 
> l’industrie et pourtant la base du protocole n’est que mélange des 
> caractéristiques de datagramme IP et de circuit ATM/Frame Relay/ Le VLAN 
> a permis d’énormément rationaliser la taille des infra sans pour autant 
> changer la technique de commutation. Les VPN, GRE et autres VxLAN sont tous 
> des techniques de tunnelisation/overlay comme un VLAN au dessus d’une infra 
> mutualisée. Arpanet s’est monté en overlay des réseaux de l’époque, donc pas 
> nouveau et pourtant chaque VPN a eu son propre impact (site distant, 
> extension de LAN entre DC, …) . 
> Bref à chaque fois on met plusieurs trucs dans une même boîte pour diminuer 
> (pas supprimer, juste baisser) la complexité de gestion et le TCO. Donc à 
> voir où se placer entre d’un côté « pas d'innovation depuis l’apparition du 
> datagramme IP » et de l’autre « SD-WAN apporte un nouveau paradigme 
> d’innovation ». 
> 
> —
> Grégory


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

Re: [FRnOG] [MISC] SDN (Software Defined Networking): Bullshit ou réalité ?

2021-05-21 Par sujet Gregory CAUCHIE 
Salut Michel,

> Le 21 mai 2021 à 07:09, Michel Py  a 
> écrit :
> 
> Je prétends pas être psy, mais dans les contribs de mes co-listiers, dont 
> certains je me sens proche et d'autres carrément pas, j'ai lu toute la gamme 
> entre "ras-le-bol" et "plein-les-c..."
> Là ou ça devient intéressant, ce n'est pas les gens qui sont d'habitude 
> d'accord avec moi, mais ceux avec qui je n'ai pas ou peu d'atomes crochus. Et 
> dont certains, comme tu le dirais, on jeté le bébé avec l'eau du bain.

Je ne pense pas avoir compris ton point.


> Le problème que j'ai avec SDN (plus du coté sysadmin) et SD-WAN (plus du coté 
> netadmin) c'est que en fait, ça n'existe pas. Aucune innovation, que des 
> technologies qui existaient bien avant que le marketing n'invente le nouveau 
> buzzword à la mode, bref c'est un ramassis de conneries

Pour avoir fait sur le terrain pas mal d’années de pousse paquet, plusieurs 
années de "SDN" et un peu d’années de SD-WAN, je ne peux qu’être en désaccord 
sur le fait que ça n’existe pas. 
Le SDN n’est pas forcément qu’une histoire pour les sysadmin faisant de 
l’hébergement voire avec du cloud par-dessus. Ça se décline aussi sur le 
pousse-paquet des familles.
Le SD-WAN n’est pas essentiel, le routage dynamique non plus après tout, je ne 
compte plus le nombre de réseaux d’ETI en routage statique. C’est juste une 
histoire classique de complexité à opérer, d’impact ou non sur le business et 
de sous-sous. Dans le cas du SD-WAN, si t’as une problématique de 
bande-passante et de priorisation de flux que DSCP seul ne peux gérer (pour x 
raisons), tu peux soit payer un x10 de bande-passante et souvent ne pas voir 
d’amélioration (vu chez des clients), soit te monter tout seul ton mélange de 
VPN, de DPI et de routage sur la base de qualité de transport de tes tunnels 
(beau challenge), soit prendre le produit packagé sous label SD-WAN. 

Quant à l’innovation, je pense qu’on a aussi ici une problématique de 
définition. À partir de quel moment une solution est-elle innovante ? quel 
seuil pour parler de « révolution" ? MPLS a eu un énorme impact sur l’industrie 
et pourtant la base du protocole n’est que mélange des caractéristiques de 
datagramme IP et de circuit ATM/Frame Relay/ Le VLAN a permis d’énormément 
rationaliser la taille des infra sans pour autant changer la technique de 
commutation. Les VPN, GRE et autres VxLAN sont tous des techniques de 
tunnelisation/overlay comme un VLAN au dessus d’une infra mutualisée. Arpanet 
s’est monté en overlay des réseaux de l’époque, donc pas nouveau et pourtant 
chaque VPN a eu son propre impact (site distant, extension de LAN entre DC, …) 
. 
Bref à chaque fois on met plusieurs trucs dans une même boîte pour diminuer 
(pas supprimer, juste baisser) la complexité de gestion et le TCO. Donc à voir 
où se placer entre d’un côté « pas d'innovation depuis l’apparition du 
datagramme IP » et de l’autre « SD-WAN apporte un nouveau paradigme 
d’innovation ». 

—
Grégory

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

Re: [FRnOG] [MISC] SDN (Software Defined Networking): Bullshit ou réalité ?

2021-05-20 Par sujet Gregory CAUCHIE 
Je suis étonné que vous jettiez tous le bébé avec l’eau du bain.

SDN a vu sa définition évolué dans le temps, d’abord uniquement autour de 
l’OpenFlow, comme évoqué précédemment par Rémi Desgrange, puis l’IETF et 
d’autres s’en sont aussi emparé sur la base qu'en gros ’software’ n’était pas 
obligé de se limiter à OpenFlow et que d’autres techno pouvaient aussi rentrer 
dans un cadre de "mise en place" par le software… sauf qu’au final on ne défini 
jamais de quelle gestion/définition/mise en place on traite exactement.

Pour ma part, je vois le SDN comme une application pour le réseau des concepts 
de CI/CD et d’infrastructure as Code. L’intérêt selon moi est la possibilité de 
valider son ingénierie sur du quasi iso-prod, systématiser les tests de non 
régression et garantir une reproductibilité (évoquée aussi par Xavier Claude) 
des états du réseau (avec le concept immutable, vs. snowflake). Bref faire sur 
le réseau ce que l’on fait avec les applications, i.e. après *beaucoup* de 
boulot, avoir un rythme d’évolution et une qualité de mise en prod 
incomparable, mais à la différence que les clouds ne peuvent pas être utilisés 
pour le pur LAN/WAN et que l’on doit donc se tourner vers d’autres types de 
solution. Du moins moi et mes précédentes équipes n’avons jamais réussi à faire 
passer des protocoles utilisant du broadcast/multicast (LLDP, Hello IGP, …) sur 
de l’OpenStack/DevStack et consoeurs.

Après dire que cloud et hébergement sont pareils, c’est pour moi ne pas avoir 
compris la différence en termes d’expérience client. Je n’ai jamais vu 
d’entreprise offre une mise en place d’un setup d’infra réseau/serveur/stockage 
en moins de plusieurs jours après la première formulation du besoin du client 
(et je suis très très gentil), alors qu’avec le cloud ça se fait dans le quart 
d’heure sans l’aide de terraform.

Quant à SDWAN… c’est pas du bullshit mais un plus grand fourre-tout, avec plus 
ou moins de capacité des API pour le SDN, plus ou moins d’orchestration des 
outils propriétaires, plus ou moins de sécurité (firewall, IPS/IDS, anti-spam, 
anti-malware, …), plus ou moins de DPI pour la reconnaissance des applis, plus 
ou moins de capacité à superviser la qualité des différents tunnels VPN, plus 
ou moins de capacité de routage/switching (VRF, NAT, BGP, IGP, …), etc. Et je 
suis d’ailleurs étonné que personne n’ai lâché le mot SASE pour crier encore 
plus au bullshit.

Ne me faites pas dire enfin qu’il n’y a aucun marketing là-dedans. Je reviens 
sur la formule de départ, ne jetons pas le bébé avec l’eau du bain. Il y a un 
peu de bon grain dans tout cela.

--
Grégory

> Le 20 mai 2021 à 20:31, Vincent Habchi  a écrit :
> 
>> On 20 May 2021, at 19:18, Toussaint OTTAVI  wrote:
>> 
>> 
>> Le 20/05/2021 à 15:04, Pierre DOLIDON a écrit :
>>> Si je résume, SDN est au réseau ce que Cloud est à l'hébergement ? 
>> 
>> J'allais le dire, mais tu m'as coupé l'herbe sous le pied :-)
> 
> Un jour, le groupe Accor lancera une nouvelle chaîne d’hôtels appelés « Cloud 
> » et le slogan sera « les spécialistes de l’hébergement ».
> 
> Bon, je sors … … …
> 
> V.
> 
> 
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/


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

Re: [FRnOG] [BIZ] French Terminology - Wavelength

2021-05-17 Par sujet Gregory CAUCHIE 
« la nouvelle vague » considers a kind of movement from a new generation of 
people and techniques creating a new kind of movies. Therefore « Vague » is 
closer to « wave » like for example « someone is enjoying a wave of sympathy ».

In physics, and specifically in optics, we use the term ‘onde’ to characterise 
the form of movement. A sinusoid wave would be « onde sinusoïdale », the wave 
particule duality is called « dualité onde corpuscule », and a wavelength a « 
longueur d’onde ».

--
Grégory

> Le 17 mai 2021 à 12:03, Rod Beck  a écrit :
> 
> And what about 'La Nouvelle Vague"?  Like Hiroshima Mon Amour ... À bout de 
> souffle or the pedestrian Le Weekend ...
> 
> 
> 
> 
> Roderick Beck
> 
> Global Network Capacity Procurement
> 
> United Cable Company
> 
> www.unitedcablecompany.com
> http://unitedcablecompany.com/video/
> New York City & Budapest
> 
> rod.b...@unitedcablecompany.com
> 
> Budapest: 36-70-605-5144
> 
> NJ: 908-452-8183
> 
> 
> [cid:750aff5b-ab16-4e7c-b0da-f1697cce4e27]
> 
> 
> From: frnog-requ...@frnog.org  on behalf of David 
> Ponzone 
> Sent: Monday, May 17, 2021 10:17 AM
> To: Pierre Colombier 
> Cc: frnog@frnog.org 
> Subject: Re: [FRnOG] [BIZ] French Terminology - Wavelength
> 
> « Vague » is also correct to describe the propagation of a virus :)
> 
>> Le 17 mai 2021 à 10:09, Pierre Colombier via frnog  a écrit 
>> :
>> 
>> "Wavelength" translates to "Longueur d'onde"
>> 
>> 
>> "Ondes" is definitively the right term for "waves" like radio waves.
>> 
>> "Vague" is for the sea waves.
>> 
>> in other contexts and especially in technical and scientific language, 
>> "Vague" would first be undertood as "unclear"/"fuzzy" unsless it visually 
>> refers to the curve or progagation of sea waves.
>> 
>> 
>> 
>> 
>> 
>> 
>> ---
>> 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] Optimisation bascule BGP arista

2021-04-13 Par sujet Gregory CAUCHIE 
Il semble que Arista-2, quand il reçoit les routes de Arista-1, juge ces routes 
meilleures que celles apprises en eBGP. Cela se voit au nombre de routes reçues 
en retour par Arista-1 (i.e. quasi rien). Arista-2 juge donc que pour sortir de 
ton AS il faut aller vers Arista-1 via le lien « iBGP », et ton temps de 
bascule est donc lié au fait que Arista-2 doit apprendre les withdraw de 
Arista-1, ou que le timer de session tombe si c’est arista-1 qui est HS, pour 
ne plus prendre en compte les routes de Arista-1 et alors sortir en direct via 
les routes restantes. 
Aurais-tu une ingénierie de local-pref, ou autre, pour expliquer tout cela ?

Je vois les solutions suivantes à ton cas :
1/ faire en sorte qu’il n’y ait pas de préférence, au niveau tie-break BGP et 
jusqu’au niveau ebgp vs. ibgp, entre tes routeurs
2/ sinon annonce ton préfixe d’interco eBGP dans un IGP, et ne met pas de 
next-hop-self, comme ça en qqn ms après que ton lien tombe, toutes les routes 
préférées sur arista-1 seront automatiquement invalidées
3/ t’as enfin la possibilité de jouer sur le timer de withdraw, et le mettre à 
0 pour annoncer les pertes de routes sans attente. Ça a des conséquences, et 
donc on évite chez les opérateurs, mais si tu ne proposes pas de transit le 
risque est faible.

--
Greg

> Le 7 avr. 2021 à 16:32, Alexis Lameire  a écrit :
> 
> J'étais en train de lire le début du thread et alais proposer du BGP PIC.
> 
> Et que vois-je plus loin, la réponse de Julien.
> 
> Je pense vraiment que c'est la bonne voie où aller. Ça permet à tes
> routeurs de calculer une route de backup pour chaque préfix qui sera promue
> en cas de coupure.
> 
> Cordialement
> Alexis Lameire
> 
> Le mer. 7 avr. 2021 à 10:10, Julien OHAYON  a écrit :
> 
>> Je confirme, "bgp additional-paths install" c'est magique pour ne pas
>> attendre 20 min.
>> 
>> 
>> Une petite doc pour optimiser le tout :
>> https://eos.arista.com/inet-edge-config/
>> 
>> 
>> 
>> 
>> Arista EOS Central - Configurations and Optimizations for Internet Edge
>> Routing
>> eos.arista.com
>> ContentsIntroductionA Note on 32 vs. 64 Bit EOSArista Multi-Agent BGP
>> ConfigurationArista FlexRoute ConfigurationChanging ACL
>> ImplementationAdjusting show tech-support OutputsISP Peering Configurations
>> and OptimizationValidating Hardware before AdvertisingEnabling Fast Failure
>> Detection with BFDEnabling missing route-map handling (RFC 8212
>> behavior)Removing Private BGP ASNsEnabling BGP CommunitiesAdjusting
>> community processing orderAdjusting BGP Maximum-Routes ValueFiltering
>> Extraneous or Malicious RoutesBGP Prefix Independent ConvergenceResource
>> Public... Continue reading →
>> 
>> 
>> 
>> 
>> De : frnog-requ...@frnog.org  de la part de
>> Pierre LANCASTRE 
>> Envoyé : mercredi 7 avril 2021 09:56:01
>> À : Laurent Laurent
>> Cc : David Ponzone; Clement Cavadore; FRnOG
>> Objet : Re: [FRnOG] [Tech] Optimisation bascule BGP arista
>> 
>> Hello
>> 
>> Tu peux explorer la piste du pic-edge pour préinstaller en FIB le backup
>> path
>> 
>> router bgp 
>> bgp additional-paths install
>> 
>> Tu devrais avoir tes routes comme suit :
>> 
>> * > x.x.x.x/yy 
>> * b x.x.x.x/yy 
>> 
>> J'ai pas encore testé avec un full feed mais en principe ça fonctionne.
>> 
>> En tout cas en lab ca fait le boulot
>> 
>> ++
>> 
>> Pierre
>> 
>> 
>> Le mer. 7 avr. 2021 à 09:42, Laurent Laurent 
>> a écrit :
>> 
>>> Je n'ai pas encore ouvert un ticket chez Arista car on est passé par un
>>> intégrateur et lui est au courant, ça va être la prochaine étape ;)
>>> 
>>> Voici le sh ip bgp summary de l'arista 2 :
>>> 
>>>  Description Neighbor V  AS   MsgRcvd
>>> MsgSent  InQ OutQ  Up/Down State   PfxRcd PfxAcc
>>>  Operateur 2xx.xx.xx.xx  4  x   17670891
>>> 53466800   27d23h Estab   833592 833527
>>>  arista-1 198.18.255.1 4  x   20127835
>>> 365120500   27d23h Estab   827988 827988
>>> 
>>> On voit que le arista 2 possède presque toutes les routes via l'ibgp.
>>> 
>>> Merci encore pour votre aide.
>>> 
>>> Le mer. 7 avr. 2021 à 09:30, David Ponzone  a
>>> écrit :
>>> 
 Tu peux envoyer le sh ip bgp sum de arista2, au cas où.
 
 Tu as ouvert un case chez Arista ? C’est peut-être un bug connu chez
>> eux.
 
 Le 7 avr. 2021 à 09:25, Laurent Laurent 
>> a
 écrit :
 
 J'ai peur aussi que ce soit le cas, mais pas forcément la partie BGP
>> mais
 plus la partie hardware.
 
  Description  Neighbor V  AS   MsgRcvd
 MsgSent  InQ OutQ  Up/Down State   PfxRcd PfxAcc
  Operateur1   xx.xx.xx.xxx4  X1586
 14998200   12:30:04 Estab   827948 827948
  Arista2  198.18.255.2   4  X3080607
 1624221700

Re: [FRnOG] [TECH] Subnet ip publique sur LAN

2021-03-17 Par sujet Gregory CAUCHIE 
> Le 17 mars 2021 à 18:14, Radu-Adrian Feurdean 
>  a écrit :
> 
> On Wed, Mar 17, 2021, at 16:07, Gregory CAUCHIE wrote:
>> 
>> Si tu n’as pas d’échange avec eux, ça ne sert à rien de les éviter. 
> 
> NON
> 1 - parce-que c'est une mauvaise pratique. L'internet fonctionne a base de 
> standards respecte par tous les participants, et RFC1918 en fait partie.
> 2 - parce-que "never say never". Tu ne sais jamais de quoi le futur sera fait.

En sortant ainsi la phrase ainsi du contexte, la réaction se comprend.

> Donc encore ine fois, ne *JAMAIS* faire ca sur une nouvelle installation. Sur 
> de l'existant, fait se mettre dans un coin de la tete qu'il faudra normaliser 
> un jour ou autre (sachant que d'habitude plus le temps passe, plus c'est 
> difficile de changer).

on est tous d’accord, ça a été dit et redit, et je me joins à tout cela, je ne 
reviendrais pas encore une fois dessus.

> Et surtout, ne *JAMAIS* dire a quelqu'un (surtout novice ou non technique) 
> que c'est une pratique acceptable. Ca ne l'est *PAS* .

Je ne suis pas le meilleur en sémantique, donc entre recommandable, acceptable, 
etc je n’ai pas d’avis. En revanche, en pur technique, pour les gens qui ont 
déjà déployé de l’IP publique en LAN, la problématique n’est pas sujette à 
débat. Soit tu as des adresses en interne que tu souhaites joindre en externe, 
et là bah le routage IP à plat t’empêche de joindre l’extérieur ; soit tu as 
des en interne des adresses IP publiques que tu n’as pas besoin de joindre en 
externe, et là pas de problème… enfin bien évidemment tant que l’utilisation de 
l’adressage publique comme de tes besoins ne change pas, ce qui n’est 
clairement pas garanti. Ce n’est en tout cas pas une histoire de pays ni de km.


> Le 17 mars 2021 à 18:28, Erwan David  a écrit :
> 
> Et si RFC 1918 ne suffit pas, ne pas oublier que RFC 6598 définis un /10
> d'IP privées (100.64.0.0/10)

La référence qui me semble plus pertinente, et qui inclus les deux RFC 
ci-dessus, est le RFC6890 "Special-Purpose IP Address Registries"   qui est 
plus complète sur ce qui est utilisable, où et comment, en source comme en 
destination, sur réseau publique, privé ou uniquement dans de la documentation.

--
Grégory

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

Re: [FRnOG] [TECH] Segment Routing

2021-03-17 Par sujet Gregory CAUCHIE 
Bonjour,

> Le 15 mars 2021 à 15:20, Olivier Eche  a écrit :
> 
> De plus la bascule du monde LDP vers SR se fait plutôt bien en utilisant
> des mapping server.

pourquoi un mapping-server et pas « juste » un changement de preference 
protocole / distance administrative pour ta migration ?
Tu avais des routeurs non SR-capable ? un use-case particulier ?

--
Greg

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

Re: [FRnOG] [TECH] Subnet ip publique sur LAN

2021-03-17 Par sujet Gregory CAUCHIE 


> Le 17 mars 2021 à 16:45, David Ponzone  a écrit :
> 
> Faut éviter de prendre des exemples rapides et premier degré ces temps-ci, 
> car ils sont pris comme tel.
> Ma faute.
> 
> C’est très culotté de penser que le client n’aura jamais d’échange avec une 
> IP Google ou AWS.

Idem pour moi (je me rends compte maintenant), l’objectif de mon côté était 
d’insister sur « avec qui tu as besoin de communiquer ».
Et effectivement, une entité qui ne communiquerait pas avec Google Search et 
YouTube ça semble rare. Pour AWS et GCP, à voir en revanche, les parts de 
marchés sont plus réparties, donc possible.

> Par contre un /16 au Vietnam, y a moins de risque.

Moins de risques oui, mais pas de garantie. C’est cette nuance que je voulais 
apporter.

--
Greg

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

Re: [FRnOG] [TECH] Subnet ip publique sur LAN

2021-03-17 Par sujet Gregory CAUCHIE 
Bonjour,

> Le 16 mars 2021 à 11:48, David Ponzone  a écrit :
> 
> Aucune autre conséquence.
> Tu peux utiliser du publique comme si c’était du privé, faut juste éviter de 
> taper dans des IP de Google ou AWS.

Si tu n’as pas d’échange avec eux, ça ne sert à rien de les éviter. Tout comme 
le nombre de km n’a de la même manière rien à voir dans l’histoire. La question 
de base qui doit être posée est : as-tu en interne une IP publique que tu dois 
pouvoir joindre en externe ? certes le NAT gère le cas du plan de transfert, 
mais ça ne règle pas le routage interne au LAN !

Si tu as en interne une adresse publique d’un site web concernant « un truc qui 
semble pas important et qui est hébergé à l’autre bout de la terre » mais que 
tu as besoin d'accéder à cette page, bah ton routeur avant le NAT va te router 
en interne plutôt qu’à la destination à l’autre bout de la terre.

De la même manière, si tu as en interne des IP publiques d’une grande banque 
française à côté de chez toi mais que tu n’as jamais à échanger avec elle, 
alors pas de problème de routage dans ton LAN, tu iras bien vers ta Gateway etc.

À noter pour info (vu dans une entreprise du CAC40), l’utilisation de proxy 
Internet au niveau du NAT. Cela « tunnelise » le traffic jusqu’au boîtier NAT, 
les routeurs « LANs » n’ont pour rôle que de joindre le proxy et les 
utilisateurs, sans connaissance de l’extérieur. Cela demande de se creuser un 
peu sur l’archi réseau, rien d’insurmontable, mais niveau exploitation et 
évolutivité, c’est une autre paire de manche.

--
Greg

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

Re: [FRnOG] [MISC] Utiliser un ordinateur hors ligne à l'ère du cloud

2021-03-08 Par sujet Gregory CAUCHIE 
Je ne comprend pas bien l’inquiétude initiale du coup si le futur évoqué a 
d’ores et déjà une alternative viable. Qu’ai-je loupé ?

En passant, quelqu’un(e) aurait un retour d’expérience sur nextcloud 
(nextcloud.com ) ?

--
Grégory

> Le 5 mars 2021 à 19:27, Vincent Finance via frnog  a écrit :
> 
> Pareil ici, je n'utilise plus de systèmes sous Windows. J'ai un MacBook
> Air et un Mac Mini qui serventt de temps en temps, mais mes machines
> sont sous GNU/Linux et sous OpenBSD en ce moment.
> 
> Le vendredi 05 mars 2021 à 18:59 +0100, mlrx via frnog a écrit :
>> Le 05/03/2021 à 18:49, Daniel via frnog a écrit :
>>> Bon, on est déjà deux :)
>> deux +1
>> 
>> 
> 
> 
> 
> 
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/


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

Re: [FRnOG] [MISC] Utiliser un ordinateur hors ligne à l'ère du cloud

2021-03-05 Par sujet Gregory CAUCHIE 
L’open source (Linux, Open office, …) n'est-il pas une solution locale et « 
durable » pour une utilisation perso comme pro ?

--
Greg

> Le 5 mars 2021 à 18:08, Vincent Finance via frnog  a écrit :
> 
> Bonjour,
> 
> Je trouve que cette analogie n'est pas forcément la meilleure pour
> cette situation, puisque que le numérique est plus hétérogène que les
> réseaux d'eau et d'électricité.
> Le plus gros problème du cloud est que beaucoup ont une confiance
> aveugle en cet écosystème, alors qu'il est toujours important de garder
> en tête que ce n'est jamais qu'un réseau de machines hébergées chez
> quelqu'un d'autre.
> 
> D'autre part, la réaction de Vincent est tout à fait légitime en ce
> moment, surtout si on s'intéresse au caractère vie privée qui fait
> polémique assez souvent.
> J'ai aussi du mal avec le streaming, puisque tout n'est pas disponible
> partout et qu'il peut être nécessaire d'avoir plusieurs comptes pour
> regarder tous les films que l'on veut voir. Mais bon, c'est un autre
> sujet.
> 
> Le cloud n'est pas forcément une mauvaise chose sur le papier, mais
> quand je vois que tout le monde passe par des entreprises comme
> CloudFare, Amazon ou encore Google, je me dis que c'est franchement pas
> terrible. Cela fait de gros SPOF qui sont hébergés aux USA, un pays qui
> n'a pas de réglement de protection des données comme chez nous. J'en
> suis pas fan personnellement et c'est pour ça que je fais partie du
> collectif CHATONS (https://chatons.org).
> 
> Autre chose qui est vrai : il n'y a plus grand chose à faire sur un PC
> non connecté à Internet, à part se divertir et programmer, mais bon,
> c'est une conséquence à notre dépendance de plus en plus grande avec
> Internet.
> 
> Vincent F.
> 
> Le vendredi 05 mars 2021 à 17:52 +0100, David Ponzone a écrit :
>> Hmmm avant, « chacun »  produisait son énergie (feu) et aller
>> chercher l’eau au puits.
>> Puis les réseaux de distribution d’électricité et d’eau sont arrivés.
>> 
>>> Le 5 mars 2021 à 17:47, Vincent  a écrit :
>>> 
>>> Salut,
>>> 
>>> Ce qui me fait en fait le plus peur, c'est la perte de contrôle et
>>> d'autonomie.
>>> C'est très angoissant de tout perdre juste parce que je n'ai plus
>>> accès à Internet, j'aime bien avoir
>>> mes propres ordinateurs sur lesquels j'ai le contrôle et je décide.
>>> Le fait de ne rien posséder, m'inquiète également,
>>> je n'apprécie pas de payer pour des choses qui ne m'appartiennent
>>> pas.
>>> 
>>> C'est vrai que je suis en quelque sorte un "survivaliste"
>>> numérique, j'aime bien l'idée d'avoir un ordinateur qui
>>> fonctionne de manière autonome même sans accès à Internet.
>>> Mais pour combien de temps encore j'aurai la liberté de faire ça ?
>>> lorsque tout le monde aura migré dans le cloud, j'ai bien peur
>>> qu'on
>>> ne me laisse plus le choix.
>>> 
>>> On a pas autant de liberté dans le cloud, où généralement il faut
>>> respecter des CGU qui peuvent changer du jour au lendemain,
>>> ou pire le prestataire fait faillite et ferme tous ses serveurs.
>>> Concernant la vie privée, c'est aussi un problème, sur le cloud on
>>> est obligé de faire confiance à des personnes qui ont
>>> accès 24H/24 à nos données.
>>> 
>>> Le cloud me parait aussi dangereux dans le cas où un gouvernement
>>> autoritaire se met en place, il aura juste à aller
>>> se servir en un seul endroit vu que tout est centralisé, c'est
>>> beaucoup plus simple que d'aller chercher les données
>>> sur les machines individuelles de millions de personnes.
>>> 
>>> Il existe déjà une sorte de grainothèque: archive.org est une
>>> association qui s’occupe de l'archivage sur Internet, ils proposent
>>> même de télécharger des films et de la musique en torrent.
>>> 
>>> Concernant l'offre légale totalement "dématérialisée", je n'y
>>> trouve pas mon compte pour les films, la plus part des offres ont
>>> des DRM
>>> empêchant la copie privée, à part quelques offres de film
>>> indépendants il n'y a pas grand chose.
>>> 
>> 
>> 
>> ---
>> 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] BGP internal routes et external routes

2021-03-01 Par sujet Gregory CAUCHIE 
Bonjour,

Si le souhait est d’équilibrer le trafic que tu envoies en différents points 
vers ton peer, alors le plus « standard » (i.e. qui marche dès aujourd’hui chez 
tous les constructeurs) est d’utiliser soit les Local_pref soit la 
désagrégation de préfixes côté interne (ça a été évoqué plus tôt il me semble). 
Le local_pref est bien plus simple à mettre en place, à condition que ta règle 
d’ingénierie « accepte » que tu aies plusieurs valeurs pour un même peering.

Si le souhait est d’équilibrer le trafic du peer vers toi, les options de MED 
ou de prepend sont possibles mais dépendent de la configuration qu’utilise ton 
peer (on peut débrayer le fonctionnement de préférence MED ou prepend dans les 
routeurs, cette discrimination n'est pas obligatoire dans la RFC). Le plus sûr, 
et pas compliqué, est de désagréger tes annonces. Si tu annonces x.x.0.0/22 en 
temps normal, tu gardes ces annonces sur tes deux routeurs et tu ajoutes d’un 
côté x.x.0.0/23 vs x.x.2.0/23 de l'autre. Ainsi tu provoques une répartition 
dont le pourcentage côté volume de trafic dépendra de ce qu’attire telle ou 
telle adresse. À affiner après selon tes caractéristiques et la « pression » 
que te met ton peer.

--
Grégory

> Le 1 mars 2021 à 12:27, Kevin Thiou  a écrit :
> 
> La conf en face c'est Est / Ouest.
> Le pkoi ? volonté du peer d'équilibrer la charge.
> Mais je ne peux pas le faire avec les routeurs actuels se sera donc
> actif/secours.
> 
> Le lun. 1 mars 2021 à 11:53, David Ponzone  a
> écrit :
> 
>> Mais pourquoi tu veux mixer les 2 ?
>> Dans ce cas, autant pratiquer la patate chaude: le routeur qui reçoit un
>> paquet du LAN l’envoie directement à ton peer, sans passer par l’autre.
>> De toute façon, chez ton peer, tu es soit sur le même routeur pour les 2
>> ports, soit un port sur leur « Ouest »  et un sur leur « Est » .
>> 
>>> Le 1 mars 2021 à 11:35, Kevin Thiou  a écrit :
>>> 
>>> Merci de t'être penché sur le sujet.
>>> 
>>> Sûrement ai je mal exprimé mon besoin.
>>> 
>>> Je suis connecté au même peer privé sur les deux routeurs.
>>> 
>>> Du coup je reçois strictement la même route sur mon routeur A et mon
>>> routeur B, mais l'un et l'autre l'apprennent avec une route eBGP et une
>>> route iBGP.
>>> 
>>> Il faut donc pouvoir mixer les deux. La commande donnée pour cisco est la
>>> bonne mais les ASR sont encore en phase d'intégration.
>>> 
>>> Ca attendra donc leur mise en production.
>>> 
>> 
>> 
> 
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/


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