Re: [FRnOG] [FRNOG][MISC] Facturation RIPE et Chorus Pro

[Damien DUJARDIN]

Bonjour à tous,

Chorus Pro ne concerne que les fournisseurs français. Le RIPE ayant son
siège aux Pays-Bas, aucun problème pour facturer à l'ancienne.

Certaines administrations n'aiment pas ça, mais c'est parfaitement légal.

Chez nous on a l'habitude, ça passe tout seul au service comptable.

Là ou ça se complique c'est quand une grosse multinationale facture depuis
un siège à l'étranger, mais en utilisant une adresse d'une entité (parfois
fictive) en France.  Ou comment faire appliquer la loi Chorus Pro à des
polonais ou des japonais qui ne parlent pas anglais



Le lun. 31 juil. 2023 à 17:47, Marc Abel  a écrit :

> Bonjour,
>
> Jusqu'à ce jour on a réussi à régler nos factures RIPE directement.
>
> Notez qu'on paye d'un côté la partie HT au RIPE-NCC et de l'autre la TVA
> française (à l'état je suppose).
>
> Comme la facture n'arrive pas dans le SI facturation il faut la
> récupérer et l'y injecter (merci aux collègues qui font ça).
>
> Le souci vient du délai trop court donné par le RIPE-NCC pour régler la
> facture versus nos délais d'instruction et ceux du payeur qui effectue
> le virement in fine.
>
> Marc ABEL pour CD93
>
> Le 31/07/2023 à 15:12, Olivier Pruneyrac a écrit :
> > Bonjour,
> >
> > Nous intervenons pour accompagner une métropole dans sa déclaration en
> tant que LIR auprès du RIPE.
> > A ce titre la métropole se demande comment la facturation pourra avoir
> lieu compte tenu de l'obligation de passer par Chorus Pro pour facturer une
> administration française.
> > Le RIPE ne peut pas utiliser Chorus Pro.
> >
> > Une administration française LIR abonnée à frnog pourrait-elle nous
> indiquer comment elle réalise l'enregistrement de la facturation RIPE ?
> Passe elle par un intermédiaire pour cela ?
> >
> > Merci d'avance
> >
> > Cordialement
> >
> > Olivier Pruneyrac
> > 06 26 65 68 43
> >
> > ---
> > 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/

[FRnOG] [TECH] Retour d'expérience sur kit de rackage avec déport de cablage

[Damien DUJARDIN]

Bonsoir à tous,

Je suis à la recherche de retour d'expérience sur des kits de rackage avec
déport de cablage en face avant, comme ceux de Rackmount.IT par exemple:
https://www.rackmount.it/products/industrials/fortirack-industrial/rm-fr-t10i.htm

Tout particulièrement, les kits vont être expédiés, déjà précablés et
configurés, et on redoute que malgré toutes nos précautions de packaging,
les vibrations du transport (manutention, camion et parfois avions) ne
créent des faux contacts sur les déports à l'arrivée.

Dans le temps, avez-vous rencontré des problèmes d'inversion de câblage
dans les déports (erreur ou malfaçon des intervenants locaux alors qu'ils
ne sont pas censés y toucher justement) ?

Et sinon on est preneur d'avis sur la qualité des kit Rackmount.IT, ou de
leurs concurrents si vous en connaissez

Merci d'avance

Damien

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

Re: [FRnOG] [MISC] Dans la série est-ce bien ou pas le draft sur 127/8...

[Damien DUJARDIN]

Bonjour à tous

Les entreprises qui consomment du service, et disposant de leur propre IT
(donc hors PME branché sur une simple box) ne feront absolument rien tant
qu'elle ne seront pas contraintes de le faire
- Soit par obligation légale (ce qui n'arrivera certainement jamais)
- Soit par obligation de service (Imaginons que Office365 annonce l'arrêt
du support IPv4)
- Soit par intérêt financier (Imaginons que Office365 fasse une réduction
de 30% pour les clients IPv6)

Et là je parle juste de la partie WAN, typiquement via des proxys, comme
indiqué par Solarus.

Il n'y a qu'à regarder combien de sociétés attendent la fin de vie des T2
pour migrer sur du trunk SIP... malgré l'intérêt financier souvent non
négligeable

Pour le déploiement IPv6 sur le LAN utilisateurs, il faudrait avoir les
mêmes contraintes sur des services non proxyfiable (ou très difficilement)
...Ou sinon demander à Cisco de facturer l'option IPv4 sur leurs routeurs



Le jeu. 18 nov. 2021 à 15:44, Solarus  a écrit :

> Le 2021-11-18 09:34, Dominique Rousseau a écrit :
>
> > Mais pour les utilisateurs en "entreprise", on en est probablement plus
> > loin.
> >
> > Ipv6 et Ipv4 vont certainement cohabiter encore longtemps.
> >
>
> Si les entreprises veulent garder un LAN en IPv4 ou en Dual-Stack,
> qu'elles le fassent, rien ne les empêche. Pour activer la navigation web
> en IPv6 tout peut se faire au niveau du proxy de sortie.
>
> Tout ce qu'on demande aux entreprises c'est d'avoir leurs services
> Internet accessibles en dual-stack, et là comme d'habitude y'a plus de
> monde pour troller et se trouver des excuses que pour faire son boulot.
> On peut critiquer les GAFAM mais Google et Facebook ils sont accessibles
> en full IPv6, alors que notre dernier champion national en date Nua.ge
> n'en propose pas.
>
> Ca reste une bonne idée ces RFC, continuons de pourrir IPv4, ouvrir des
> failles de sécurité et générer des bugs de routage, et tout le monde
> priera pour passer à IPv6 le plus vite possible.
>
> Y'a ceux qui trollent et ceux qui négocient leur compétence en IPv6 sur
> le marché de l'emploi. Je vous encourage à faire partie des seconds.
>
> Amicalement,
> Solarus
>
>
> ---
> 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

[Damien DUJARDIN]

Il n'y a que moi que ça perturbe de voir un firewall statefull gérer une
fonctionnalité de redondance stateless?

Le jour où tu perds un transit, tu vas perdre toutes les connexions en
cours..

Pas glop

Damien



Le mar. 26 oct. 2021 à 20:23, David Ponzone  a
écrit :

>
> > Le 26 oct. 2021 à 19:36, Jerome Lien  a écrit :
> >
> > Étant un débutant dans ce monde, j'entends les conseils et j'ecoutes les
> > retours d'expériences. Car difficile de bien ce faire conseiller au final
> > sur le choix des équipements d'où ma question ;-)
>
> Pouvoir faire du BGP n’est pas le seul paramètre.
> Il faut aussi voir ce qu’on va mettre comme lien.
> Pour du sub-1G, on peut faire ça sur à peu près n’importe quoi.
> Si un port 10G de transit est nécessaire (mais suffisant pour tenir
> quelques années), ça élimine quelques options.
> J’oublierais VyOS et toute autre routeur soft qui n’implémente pas DPDK ou
> équivalent.
> Donc plutôt 6Wind (c’est très bien 6Wind).
> Après, un ASR1001-X avec 16Go de RAM doit faire le job, mais tu peux pas
> dépasser 3 ports 10G. Après faut prendre un chassis plus gros, ou du HX
> (arggg le porte-monnaie).
>
> > Effectivement, un opérateur ( luxembourgeois) m'a parlé de le faire avec
> un
> > fortinet... Mais j'étais fort septique…
> >
>
> Ca a aucun sens.
> Un Forti avec la RAM pour tenir la full-table, c’est minimum un 500, mais
> plutôt un 1000.
> Leur CPU sont optimisés pour le filtrage, mais je doute qu’ils le soient
> pour BGP.
> Si le but c’est de faire que du BGP, pourquoi mettre autant de pognon dans
> un firewall ?
> Si le but c’est de faire BGP et sécurité, il va y avoir concurrence en
> permanence sur le CPU entre le filtrage et le BGP, et en cas de délire de
> l’un ou de l’autre, ça va pas être beau à voir.
> La séparation des fonctions, c’est quand même un principe hyper sympa.
> Si Forti a mis du BGP dans les chassis, c’est pas pour en faire un routeur
> de transit, mais plutôt pour iBGP je pense.
>
> Je suis prêt à être contredit, si quelqu’un ose avouer que ses borders
> sont des FG :)
>
>
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/
>

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

Re: [FRnOG] [TECH] Outlook / MS smtp server sans reverse

[Damien DUJARDIN]

Je pense que c'était vrai il y a quelques temps mais que ça ne l'est plus
maintenant

Ma connexion grand public d'un opérateur bien connu valide le forward
reverse alors que je n'ai rien demandé. Donc on doit être des millions dans
ce cas.

Enfin, si ça nettoie toujours 90% du spam, on va surtout pas s'en plaindre
et continuer à appliquer cette règle.

On se reposera la question quand ce filtrage nous amenera plus de problèmes
que de solutions

Bonne soirée à tous



Le sam. 23 oct. 2021 à 20:17, Michel Py 
a écrit :

> > Laurent-Charles FABRE a écrit :
> > Il n'est pas demandé à ce qu'il soit signifiant, juste qu'il existe.
> > Il y même un avis plutôt répandu (ok on est de le feeling là) que le nom
> de
> > serveur indiqué dans le HELO ne matche pas forcément avec le reverse.
>
> Ce qui est absolument impossible à faire quand on a un serveur
> multi-domaine. Même à la maison, sur mon vénérable serveur de mail qui a
> été sur aDSL et maintenant sur câble coax, j'ai plusieurs domaines. Le HELO
> ou EHLO qui est le même que le reverse, c'est de la foutaise écrite par les
> même chimpanzés qui mettent des disclaimers à la fin de leur email. Ca ne
> sert qu'à une seule chose : emmerder le monde.
>
>
> > Archange a écrit :
> > Or la bonne pratique ce n’est pas seulement un reverse, c’est un forward
> > confirmed reverse: il faut que ton reverse résolve vers la même IP.
>
> Oui, car Claude Michu qui se fait contaminer par un merdiciel d'envoi de
> spam ne va pas avoir cette configuration, alors que le serveur de mail
> légitime va l'avoir.
>
> > Chez moi, la mise en place de ces deux vérifications (rDNS + fcrDNS)
> coupe 99 % des
> > connexions illégitimes (qui auraient éventuellement débouché sur un mail
> ou pas, ça
> > bloque aussi des connexions qui tente d’utiliser en open relay). Après
> je ne suis
> > évidemment pas du tout représentatif, mais ça reste quand même une bonne
> pratique utile.
>
> En effet. Le forward confirmed reverse est une demande raisonnable.
>
> Michel.
>
>

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

Re: [FRnOG] [TECH] Outlook / MS smtp server sans reverse

[Damien DUJARDIN]

Merci pour les retours.

Si je comprends bien c'est plus un problème de compatibilité qu'un réel
apport de sécurité.

Vu que les opérateurs, même grand publics, génèrent des reverse pour toutes
leurs IPs, çe n'est plus vraiment justifié de nos jours.

Damien

Le ven. 22 oct. 2021 à 22:36, Alain Bitschiné  a
écrit :

> Bonjour,
>
> Beaucoup de spams sont envoyés de machines corrompues, perso ou serveur.
> Ce contrôle permettait (c'est peut-être moins le cas maintenant) d'éliminer
> beaucoup de ces machines.
>
> La configuration correcte de la résolution DNS inverse pour un serveur de
> messagerie est essentielle. Je dirais même que c'est la base. C'est un
> critère suffisant de rejet pour beaucoup de messageries... peut-être parce
> que c'est un contrôle facile à mettre en place au niveau d'un MTA sans
> avoir à installer un vrai antispam.
>
> Je n'ai pas re-testé récemment, mais Google/Gmail, entre autres, rejettait
> les mails de serveurs sans résolution inverse valide. Chez d'autres, même
> si ce n'est pas bloqué directement par le MTA, c'est pris en compte dans le
> scoring du mail réalisé par les antispam.
>
> Il y a aussi des RBL qui utilisent ce critère... Même Microsoft demande
> que la résolution inverse soit correcte pour pouvoir être retiré de leur
> black list.
>
> Le nom de domaine du serveur qui envoie le mail n'a pas besoin de
> correspondre à celui de l'émetteur du mail. En revanche, il y a d'autres
> outils (SPF, DKIM, DMARC) qui permettent de vérifier qu'un serveur est
> habilité.
>
> Alain
>
> Le 22/10/2021 21:50, Damien DUJARDIN a écrit :
>
> Bonsoir à tous,
>
> Connaissez-vous l'apport de ce contrôle en terme de sécurité ?
> Vu qu'on ne contrôle pas que le reverse corresponde au domaine de l'email
> emeteur, j'ai du mal à voir ce qu'on essaye d'empêcher ?
>
> Damien
>
> Le ven. 22 oct. 2021 à 19:15, David Ponzone  a
> écrit :
>
> Je suis une grosse feignasse, car j’utilise PowerDNS mais j’avais la
> flemme de chercher.
> Donc Paul, merci!
>
> Redoutable leur truc pour répondre une IP seulement si le service est up….
>
> Le 22 oct. 2021 à 18:54, Paul Caranton  a
>
> écrit :
>
>
> Pour IPv6 (et IPv4), il est possible de générer des reverses à la volée
>
> avec PowerDNS et les enregistrements LUA :
> https://doc.powerdns.com/authoritative/lua-records/
>
>
> Paul
>
> Le 22/10/2021 à 18:46, David Ponzone a écrit :
>
> Et j’ai tendance à penser qu’avec IPv6, ça va pas s’arranger.
> Ou alors va falloir utiliser du DNS avec génération à la volée du
>
> reverse quand il n’y a aucun reverse spécifique configuré.
>
> Ca existe peut-être déjà, j’ai pas regardé….
>
> Le 22 oct. 2021 à 18:33, me  a écrit :
>
>
> Sinon des ips sans reverse ça arrive de plus en plus en ce moment,
>
> j’ai de plus en plus ça ici
>
>
> ---
> 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/
>
>

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

Re: [FRnOG] [TECH] Outlook / MS smtp server sans reverse

[Damien DUJARDIN]

Bonsoir à tous,

Connaissez-vous l'apport de ce contrôle en terme de sécurité ?
Vu qu'on ne contrôle pas que le reverse corresponde au domaine de l'email
emeteur, j'ai du mal à voir ce qu'on essaye d'empêcher ?

Damien

Le ven. 22 oct. 2021 à 19:15, David Ponzone  a
écrit :

> Je suis une grosse feignasse, car j’utilise PowerDNS mais j’avais la
> flemme de chercher.
> Donc Paul, merci!
>
> Redoutable leur truc pour répondre une IP seulement si le service est up….
>
> > Le 22 oct. 2021 à 18:54, Paul Caranton  a
> écrit :
> >
> > Pour IPv6 (et IPv4), il est possible de générer des reverses à la volée
> avec PowerDNS et les enregistrements LUA :
> https://doc.powerdns.com/authoritative/lua-records/
> >
> > Paul
> >
> > Le 22/10/2021 à 18:46, David Ponzone a écrit :
> >> Et j’ai tendance à penser qu’avec IPv6, ça va pas s’arranger.
> >> Ou alors va falloir utiliser du DNS avec génération à la volée du
> reverse quand il n’y a aucun reverse spécifique configuré.
> >> Ca existe peut-être déjà, j’ai pas regardé….
> >>
> >>> Le 22 oct. 2021 à 18:33, me  a écrit :
> >>>
> >>>
> >>> Sinon des ips sans reverse ça arrive de plus en plus en ce moment,
> j’ai de plus en plus ça ici
> >>>
> >>
> >> ---
> >> 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] OSPF cost et référence

[Damien DUJARDIN]

Bonjour Emmanuel,

C'est une bonne idée d'avoir la maîtrise de tes poids OSPF et de sortir du
mode automatique.

La contrainte principale est que la somme des coûts du chemin le plus long
de peut pas dépasser 65000 de mémoire (c'est un entier 16 bits dans les
implémentations)
J'espère donc que tu n'as pas trop de liens 100Mb/s à 1 points chacuns
:-)

Pour les valeurs à donner, ça va dépendre de ton contexte.
Dans un contexte mono-site où le chemin prioritaire est réellement le plus
gros, tes valeurs devraient bien fonctionner

Dans notre cas, (un maillage de fibres multi-sites distants), on a aussi
pris en compte la latence et la techno des liens dans nos calculs.
In fine, on a fait des simulations d'OSPF pour s'assurer que la charge soit
bien réparti sur l'intégralité de notre maillage, y compris en cas de perte
d'un lien

Bon courage

Damien


Le mer. 25 août 2021 à 17:57, Emmanuel DECAEN 
a écrit :

> Bonjour,
>
> Aujourd'hui, bien que sa référence de bande passante soit à 100 Mbps, le
> calcul de cout OSPF (et donc sa référence) dépend beaucoup des
> implémentations des éditeurs/constructeurs de routeurs.
>
> Dans FRR en v8, bien que la documentation indique 100 Mbps, la référence
> par défaut (no auto-cost) semble être 100 Gbps.
> # show ip ospf interface
> ens21 is up
>ifindex 5, MTU 1500 bytes, BW 1 Mbit
> 
>Router ID a.b.c.d, Network Type BROADCAST, Cost: 10
>
> 100G / 10G => cost 10
>
>
> Sur les Nexus Cisco, la référence par défaut est à 40 Gbps (conforme à
> la doc).
> # show ip ospf interface
> Ethernet1/48 is up, line protocol is up
>  Unnumbered interface using IP address of loopback0
>  State P2P, Network type P2P, cost 4
>
> 40G / 10G => cost 4
>
> Évidemment, c'est assez incohérent d'avoir deux couts différents pour
> une interface de même débit ;-)
>
> Je vais donc choisir une référence commune, et je pensais prendre une
> référence 1Tbps:
> auto-cost reference-bandwidth 1000 Gbps
>
> 1G -> 1000
> 10G -> 100
> 100G -> 10
>
> Qu'en pensez-vous ?
> Qu'avez-vous choisi dans votre environnement (informatique interne,
> datacenter, VM) ?
>
> Merci.
> --
> Emmanuel DECAEN
>
>
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/
>

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

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

[Damien DUJARDIN]

Bonjour à tous

N'y aurait-il pas une piste au travers du BGP anycast ?
Si chaque client autorise plusieurs fournisseurs de CDNs à annoncer son
même préfix unique, on se retrouverait avec de l'anycast multi fournisseurs.
Reste la contrainte d'être ultra réactif pour pouvoir arrêter les annonces
en cas de panne, via un health-check du service et des appels d'API

Mais pour moi cela n'est pas viable à l'échelle d'un seul client, on ne va
pas monopoliser un /24 par site web protégé.
Il faudrait des grappes de clients, utilisant les mêmes fournisseurs de CDN.

Est-ce que le jeu en vaut vraiment la chandelle pour une panne qui a duré
moins d'une heure ?
N'y a-t-il pas un risque d'introduire un nouveau risque de panne plus élevé
que la défaillance d'un fournisseur ?

J'en doute

Damien


Le mer. 9 juin 2021 à 13:38, Ludovic LACOSTE  a
écrit :

> De temps en temps, lire les RFCs, les respecter, et penser que nos pairs
> ont bossé dessus des heures sans réellement être rémunérés pour le bien de
> tous, ça fait du bien à l'internet (et l'égo aussi) 
> Merci @Pierre Colombier
>
> -Message d'origine-
> De : frnog-requ...@frnog.org  De la part de
> Pierre Colombier via frnog
> Envoyé : mercredi 9 juin 2021 13:27
> À : frnog@frnog.org
> Objet : Re: [FRnOG] Re: [ALERT] Un CDN Down ?
>
> Je pense que le DNS n'est pas la solution à cause du temps de propagation
> et des caches qui ne respectent pas les ttl courts.
>
> Pour ne pas avoir le problème des caches (y compris celui dans le browser
> du client) , Il faut que ton site soit capable de générer en quelques
> instants des url différentes pointant sur l'autre CDN.
>
>
> Mais je pense que c'est beaucoup d'efforts pour rien car déjà c'est un
> évènement très rare et qui quand il arrive dure généralement
> potentiellement moins que le temps de détecter le problème et de prendre
> les mesures.
>
> En plus, tu n'est pas à l'abris d'introduire des bugs dans ton propre
> système qui au final aggravera le problème.
>
> On 09/06/2021 11:56, Damien Wetzel wrote:
> > Bonjour,
> >
> > En tant que revendeur de la solution, on a un peu souffert hier ;)
> >
> > Cela 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 ?
> >
> > Est ce que avoir une config de secours sur un autre CDN + un DNS
> > configurable rapidement avec des TTL courrs ~1min a un sens ?
> >
> > Vos avis m'interressent.
> >
> > Cordialement,
> > Damien
> >
> >
> > Stephane Bortzmeyer writes:
> >   > On Tue, Jun 08, 2021 at 12:17:17PM +0200,
> >   >  Kévin GUERY via frnog  wrote
> >   >  a message of 14 lines which said:
> >   >
> >   > > Apparemment de gros problèmes sur paypal, twitch, amazon et autres
> >   > > qui sembleraient liés à un problème sur CDN ?
> >   >
> >   > Post-mortem de Fastly. Moins bien que ceux de Cloudflare mais
> meilleur
> >   > que ceux d'Orange.
> >   >
> >   > https://www.fastly.com/blog/summary-of-june-8-outage
> >   >
> >   >
> >   > ---
> >   > 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] Convertisseur Fibre 1G LC - Cuivre en DC

[Damien DUJARDIN]

Bonjour,

Nous utilisons des convertisseurs FS.COM depuis pas mal de temps, y compris
dans des conditions parfois complexes à l'étranger (Electricité,
Humidité).. et aucune panne jusqu'à présent
https://www.fs.com/fr/products/119644.html
Un avantage que nous apprécions est la possibilité d'en monter plusieurs
dans un châssis 1U double alimenté
https://www.fs.com/fr/products/35348.html

Vu le prix, tu peux prévoir un convertisseur de spare dans le rack, mais
sincèrement on n'a jamais eu besoin de s'en servir jusqu'à présent

Damien


Le jeu. 4 mars 2021 à 09:36, Fabien H  a écrit :

> Bonjour,
>
> je suis à la recherche d'un convertisseur fiable pour brancher une porte
> de collecte monomode LC 1G sur un routeur CISCO avec port Cuivre 1G.
>
> Je ne peux pas utiliser nos SW CISCO pour faire la conversion pour des
> raisons d'isolation des VLAN qui y transitent.
>
> Avez-vous des références très fiables (uptime et non buggé) et pas trop
> trop cher ? Alim 220V
>
> Merci,
> Fabien
>

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

Re: [FRnOG] [TECH] Pourquoi les entreprises désactivent IPv6

[Damien DUJARDIN]

Zscaler est un gros pare feu déporté dans le cloud, et facturé en SaaS à
ses clients entreprises qui n'ont pas envie de maintenir Proxy+ips+nextGen
en interne. C'est particulièrement utilisé par des boîtes avec de nombreux
petits sites géographiquement éloignés, qui veulent profiter du cloud pour
attendre le serveur Zscaler le plus proche

Tu peux l'utiliser du simple proxy Web déclaré dans les navigateurs, au
filtrage complet de tout ton traffic internet au travers de tunnels. Chaque
client choisi ce qu'il redirige vers Zscaler, comme il choisirait ce qu'il
redirige vers un pare-feu en interne.
Comme tout service de sécurité privatif, c'est le client qui choisi le
niveau de sécurité qu'il active sur la plate-forme.

Concernant l'inspection SSL/TLS, cela est possible car le client injecte
volontairement une AC racine privée sur ses postes de travail. Et ce n'est
pas Zscaler qui l'auto-injecte par magie, cela est heureusement impossible.
C'est bel et bien le client qui le fait volontairement, typiquement via des
GPOs sur son parc de machine, comme il le fairait s'il déployait de
l'inspection SSL sur un proxy interne.
Ça a ses limites, comme par exemple l'utilisation de BYOD sur lequel
l'administrateur ne peut pas forcément injecter l'AC racine privee, ou
encore l'utilisation d'un navigateur qui utilise son propre magasin de
certificats non modifiable par un administrateur entreprise.
Cote risques, c'est au client de voir si faire inspecter tout son traffic
SSL par un acteur cloud, qui plus est américain, est judicieux ou non.

Bonne soirée à tous


Le mer. 27 janv. 2021 à 23:41, Benoit FrNOG Plessis via frnog <
frnog@frnog.org> a écrit :

> On 27/01/2021 21:23, Radu-Adrian Feurdean wrote:
> > On Wed, Jan 27, 2021, at 18:57, Benoit FrNOG Plessis via frnog wrote:
> >> J'ai récement découvert "Zscaler" qui intercepte n'importe quel site
> >> SSL/TLS qu'il soit avec HSTS, DANE ou DNS CAA. Le truc serait pas payant
> >> qu'on le prendrait pour un rootkit je pense ...
> > Ce n'est pas interception, c'est du proxy.
>
> Comme disent les anglais potahto potayto
>
> C'est un proxy qui fonctionne sans l'accord des applications, filtre les
> requetes DNS, injecte un certificat AC "caché" (non visible dans l'OS) ...
>
> On est au dela d'un simple proxy, voir même d'un proxy transparent
>
>
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/
>

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

Re: [FRnOG] [FRNOG][TECH] Network Access Control

[Damien DUJARDIN]

Bonsoir,

On a déployé du NAC en multi-sites, multi-vlan, multi-équipements, et
c'est... pas simple.
La totale, avec réseau de parking, et bientôt un portail captif unifié
filaire et wifi si tout va bien
Une fois en place, c'est génial, tu peux dire aux utilisateurs de brancher
n'importe quoi sur n'importe quelle prise.
L'équipe peut enfin se consacrer à des sujets plus intéressants que
affecter des vlans

Comme dit plus haut, le 802.1x ça juste marche sur du Windows + AD +
certificats via ADCS
C'est complètement transparent, y compris lors de la masterisation des
postes.
A aucun moment l'utilisateur ne s'en rend compte, on gère même
l'affectation de vlan selon des groupes utilisateurs AD
Bon rien que ça, on ne va pas se le cacher, c'est un peu de boulot, mais
une fois en place ca tourne tout seul, quasiment aucune charge de
troubleshoot.

En revanche, le gros du boulot c'est le reste, car pour qu'un NAC soit
vraiment efficace, tout doit être NACé, du sol au plafond.
Pour y arriver, ne comptez pas que sur le 802.1x.
On a eu beau chercher, et chercher encore, très peu d'équipements en place
(en dehors des PCs) étaient capable de faire du 802.1x dans notre contexte
Le peu qui était censé le faire (comme nos téléphones IPs) le faisait mal,
voir très mal.
Et ca nous bloquait pour les équipements normalement auto-provisionnés en
sortie de carton (téléphone, borne wifi, DECT, ..), car sans conf 802.1x
initiale, pas d'accès au serveur de provisionning..

Bref, on a fait de l'authent MAC en parallèle du 802.1x, pas le choix.
Bon, on va pas se le cacher, l'authen MAC c'est plus pour l'affectation
automatique des VLANs que pour la sécurité, c'est trop facile à usurper.

On a des milliers de prises à gérer, et on affecte quasiment plus aucun
vlan à la main.
Notre HelpDesk est parfaitement autonome pour déplacer des bureaux, des
imprimantes et j'en passe.
Au final, on a surtout gagné en réactivité et en flexibilité.

Pour conclure, un NAC n'apporte pas grand chose en terme de sécurité
Certes ça protège un peu, mais tant que des "potentiels méchants" auront
accès physiquement aux équipements et aux prises, vous ne pourrez pas les
protéger correctement.
Ceci est aussi vrai en 802.1x ultra sécurisé via certificats, car vous ne
pourrez pas empêcher la pose d'un man in the middle physique, à l'insu de
l'utilisateur réellement connecté à la prise.
Il ne vous libérera donc pas de tout filtrer et contrôler via des pare-feux
dignes de ce nom.
Tout ce qui est sensible devrait en plus être réencapsulé dans des tunnels,
ou accéder depuis des postes virtuels distant à mon sens.
Et surtout, passez les patchs partout, ca va de soi, et pas uniquement sur
les PCs bien sûr.

Par contre, l'affectation automatique de vlan sur des milliers de prises,
c'est le pied !
Pour rien au monde on ne reviendrai la dessus

Enfin pour le sujet du VPN, attention aux perfs.
Le VPN ça consomme du CPU sur le poste, et c'est difficile de faire passer
beaucoup (vraiment beaucoup) de trafic.
Je n'arrive pas à dépasser les 40Mb/s et à condition de plafonner à 100%
tous les coeurs de mon i7

Bonne soirée à tous



Le mar. 1 sept. 2020 à 20:46, Philippe Bourcier  a
écrit :

> Bonsoir,
>
> 802.1x sans client lourd ca fonctionne parfaitement et ca se déploie
> rapidement...
> C'était mon approche favorite jusqu'au Covid.
>
> > Cela me parait un meilleur investissement de considérer que le LAN n'est
> plus un réseau de
> > confiance (approche Zero Trust)
> > et que l'utilisateur doive être connecté en VPN en interne comme en
> externe (always on).
>
> Mais j'avoue que je trouve ca vraiment sexy comme approche de faire du
> "tous en VPN", d'autant que les clients VPNs sont bien au point pour ce qui
> est du suivi/validation des mises à jour AV/OS pré-connexion... Je trouve
> que c'est une très bonne idée.
>
>
> Cordialement,
> --
> Philippe Bourcier
> web : http://sysctl.org/
> blog : https://www.linkedin.com/today/author/philippebourcier
>
>
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/
>

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

Re: [FRnOG] [TECH] FRNOG [TECH] Fwd: Message important concernant les élections du RIPE

[Damien DUJARDIN]

Tu aurais du lire mieux (troll gratuit du vendredi)

Techniquement il utilise un bit réservé dans l'entête donc ça peut
fonctionner.

Par contre la modif est énorme puisque ce bit doit être pris en compte dans
tout ce qui manipule de l'ipv4.
C'est encore plus risqué que la transition ipv6 car le matériel non
compatible ne verra pas ce bit et routera donc vers la mauvaise cible. Bon
courage pour le troubleshoot.

Il relativise la modification en promettant immédiatement monts et
merveilles aux membres. Méthodes classique des politiciens.
Tous le marketing est bien rodé, il vend du rêve.
Je me suis arrêté de lire quand il a dit "vous n'aurez vos IPs que si je
suis élu"
Ça en dit tout sur le personnage.

Sinon d'après vous, on est sur quels profils du côté des votants, plutôt
technique ou plutôt managers politiciens ?

Pour ma part, c'est technique, et ça sera mon premier vote au RIPE

Que pensez vous des autres candidats (en dehors des iraniens bien sûr)?

Bonne soirée

Damien

Le ven. 8 mai 2020 à 20:00, Julien Escario  a
écrit :

> Il faudrait peut être expliquer pourquoi sa proposition est une
> aberration totale ?
>
> Si j'ai bien compris, le monsieur propose de jouer sur la représentation
> de l'IP dans un paquet. En changeant [0-255].[0-255].[0-255].[0-255] en
> [0-65535].[0-65535].
> Ce qui est une connerie abominable au niveau technique puisque dans un
> paquet, il n'y a aucun point, uniquement |0-F]{8} donc c'est strictement
> la même chose.
>
> J'ai arrêté ma lecture à ce stade tellement j'ai trouvé ça à des années
> lumières de la connaissance technique qu'il faut pour causer de ça. Si
> même moi, avec mes quelques notions de réseau je comprends ça (tout en
> ramant pas mal pour suivre les prez des RIPE Meeting), le mec n'a juste
> rien à faire ni au RIPE, ni à proposer un draft.
>
> Juste ou j'aurais dû lire mieux ?
>
> Julien
>
> Le 08/05/2020 à 19:44, Hugues Voiturier a écrit :
> > Est-ce que c’est un troll ?
> >
> > Dans le cas contraire, ce genre de propos est franchement indigne d’une
> ML comme FRnOG…
> >
> > Hugues
> > AS57199 - AS50628
> >
> >> On 8 May 2020, at 19:24, Bruno LEAL DE SOUSA 
> wrote:
> >>
> >> Hello,
> >>
> >> Je ne connais pas ce fameux candidat mais au vu de la complexité
> d'adoption
> >> de l'IPv6 et de l'attachement à l'IPv4, proposer ce type de solution est
> >> intelligent et encourageant !
> >>
> >> A suivre...
> >>
> >> Bruno LEAL DE SOUSA
> >> 06.01.23.45.96
> >>
> >> Le ven. 8 mai 2020 à 15:42, Christophe PLESSIS  a
> écrit :
> >>
> >>> Bonjour,
> >>> Avez vous reçu cette information pour augmenter le nombre d’ipv4 ? Quel
> >>> est votre avis ?
> >>> A bon entendeur.
> >>> Christophe
> >>>
> >>> De : Elad Cohen 
> >>> Envoyé : vendredi 8 mai 2020 00:06
> >>> À : contact 
> >>> Objet : Message important concernant les élections du RIPE
> >>>
> >>> Bonjour,
> >>>
> >>> Je m'appelle Elad Cohen et je suis candidat au conseil
> d'administration du
> >>> RIPE lors des prochaines élections, qui auront lieu le 13 de ce mois.
> >>>
> >>> J'ai créé une solution technique avec laquelle il y aura plus de 4 294
> 967
> >>> 296 adresses IPv4 pour les 5 registres Internet régionaux, y compris le
> >>> RIPE, vous pouvez en savoir plus à ce sujet ici :
> >>>
> >>>
> https://www.ripe.net/ripe/mail/archives/members-discuss/2020-April/003676.html
> >>>
> >>> Le problème « d'épuisement d'IPv4 » sera derrière nous et chaque membre
> >>> RIPE recevra au moins un /21 d'adresses IPv4 gratuites si je suis élu.
> >>> Personne d'autre ne mettra en œuvre ma solution technique, je vous
> demande
> >>> votre vote en ligne. Sans votre vote en ligne à la prochaine assemblée
> >>> générale du RIPE, ma solution technique ci-dessus ne sera pas mise en
> œuvre.
> >>>
> >>> Veuillez vous inscrire au vote en ligne pour les élections du RIPE en
> >>> utilisant le lien suivant :
> >>> https://www.ripe.net/s/gm-registration-may-2020
> >>>
> >>> Si vous rencontrez un problème pour vous inscrire au vote en ligne,
> >>> veuillez envoyer un courrier électronique à a...@ripe.net >>> a...@ripe.net>
> >>>
> >>> ---
> >>>
> >>> Outre la solution technique susmentionnée au problème de «
> l'épuisement de
> >>> l'IPv4 », il existe deux autres solutions techniques que je
> m'efforcerai de
> >>> mettre en œuvre si j'ai l'honneur d'être élu :
> >>>
> >>>
> >>> Une solution technique au problème mondial du spam par courrier
> >>> électronique :
> >>>
> >>>
> https://www.ripe.net/ripe/mail/archives/members-discuss/2020-April/003778.html
> >>>
> >>> Une solution technique au problème mondial de l'amplification de
> >>> l'usurpation du DDoS :
> >>>
> >>>
> https://www.ripe.net/ripe/mail/archives/members-discuss/2020-April/003902.html
> >>>
> >>> ---
> >>>
> >>> Si vous votez pour moi et que je suis élu, je ferai en sorte que RIPE
> >>> devienne :
> >>>
> >>> - Une organisation 100% transparente.
> >>>
> >>> - Une organisation centrée sur le LIR (il y aura un ANS de 24 heures
> pour
> >>> chaque demande d'assistance, 

Re: [FRnOG] [Tech] Opérateurs et DSCP

[Damien DUJARDIN]

C'est ce qu'on fait deja quand on gère les deux extrémités.
On était donc parti sur de la QoS DSCP car rien de distingue plus un paquet
IPSEC d'un autre paquet IPSEC.
La couche VPN recopie les en-têtes DSCP mais elles n'arrivent pas jusqu'où
bout, surtout quand on change d'opérateurs en cours de route.
Et bien sûr on n'a pas le choix d'avoir le même opérateur de bout en bout,
sinon çe serait trop facile.


Le jeu. 2 avr. 2020 à 01:21, David Ponzone  a
écrit :

> Ben monte des tunnels et tu es peinard
>
> > Le 2 avr. 2020 à 01:13, Damien DUJARDIN  a
> écrit :
> >
> > Merci pour vos retours
> >
> > Effectivement l'idée n'est pas de demander à tous les opérateurs de
> > prioriser nos flux, on n'en est pas encore là.
> >
> > Mais s'ils pouvaient déjà ne pas reseter nos marquages ce serait déjà un
> > bon début
>
>

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

Re: [FRnOG] [Tech] Opérateurs et DSCP

[Damien DUJARDIN]

Merci pour vos retours

Effectivement l'idée n'est pas de demander à tous les opérateurs de
prioriser nos flux, on n'en est pas encore là.

Mais s'ils pouvaient déjà ne pas reseter nos marquages ce serait déjà un
bon début

Le jeu. 2 avr. 2020 à 00:50, Alexis  a écrit :

> Bonjour,
>
> Les champs DSCP, dès que ça sort de ton WAN, fait une croix dessus (sauf
> si tu payes l'option qui va bien chez ton opérateur ... mais vu le prix
> de ces options, tu es au courant quand tu la payes :)).
>
> Si on pouvait forcer la priorisation de tout ou partie de son trafic sur
> internet (sans payer l'option dédiée), tout le monde mettrait tout son
> trafic youtube et facebook en EF et ça ne ferait pas plus avancer le
> schmilblick.
>
> D'une manière générale, pour ne pas être embêté sur de la voix, il faut
> une connexion dédiée sur les points les plus enclins à saturer (oui oui,
> je pointe du doigt la boucle locale du petit télé-travailleur au
> fin-fond de la creuse ... mais pas que !). Ça n'empêche pas les peerings
> des opérateurs de saturer mais c'est quand même moins fréquent qu'une
> saturation de boucle locale, surtout en restant sur du trafic français pur.
>
> Alexis
>
> Le 01/04/2020 à 22:18, Damien DUJARDIN a écrit :
> > Bonsoir à tous,
> >
> > On est en plein projet de QoS pour nos systèmes audio/Vidéo.
> > En interne, no soucis, mais en externe les choses se compliquent..
> >
> > De votre expérience, est-ce que les opérateurs français respectent les
> > marquages DSCP ?
> > Avez-vous remarqué une différence de traitement entre réseaux Pro et
> Persos
> > ?
> >
> > D'après nos tests, les marquages ont du mal à atteindre nos employés
> > actuellement en télétravail.
> >
> > J'ai parcouru une étude interessante sur le sujet, et l'Europe semble est
> > en retard sur la neutralité DSCP..
> > https://www.sciencedirect.com/science/article/pii/S0140366417312835
> >
> > Avez-vous un avis sur la question ?
> >
> > ---
> > 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/

[FRnOG] [Tech] Opérateurs et DSCP

[Damien DUJARDIN]

Bonsoir à tous,

On est en plein projet de QoS pour nos systèmes audio/Vidéo.
En interne, no soucis, mais en externe les choses se compliquent..

De votre expérience, est-ce que les opérateurs français respectent les
marquages DSCP ?
Avez-vous remarqué une différence de traitement entre réseaux Pro et Persos
?

D'après nos tests, les marquages ont du mal à atteindre nos employés
actuellement en télétravail.

J'ai parcouru une étude interessante sur le sujet, et l'Europe semble est
en retard sur la neutralité DSCP..
https://www.sciencedirect.com/science/article/pii/S0140366417312835

Avez-vous un avis sur la question ?

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

Re: [FRnOG] [MISC] Deploiement WIFI

[Damien DUJARDIN]

+1 pour Aerohive (bien sur plus cher que Ubiquiti)
- Superbe console de gestion centralisé Cloud ou OnPremise
- Templating rudement efficace
- Fonctionnalité intégré de tunneling "VPN Gateway" sacrément efficace pour
remonter jusqu'à un portail captif

Mais le nerf de la guerre c'est le positionnement des bornes.
Faites vous accompagner par des pros des ondes radios pour éviter les zones
blanches et/ou les perturbations de signal

Le ven. 7 févr. 2020 à 14:48, Kevin CHAILLY | Service Technique <
kchai...@adeo-informatique.com> a écrit :

> "Les imprimantes HP et le réseau, c’est un poème"
>
>
> Les imprimantes HP, c'est aussi plein d'humour.
>
>
> Une MAJ de sécurité pour IE a été publiée ( CVE 2019-1367 ) qui a un peu
> cassé jscript ( ne pas confondre avec javascript, jscript c'est du VB écrit
> avec une syntaxe JS ).
>
>
> Du coup ça a un peu cassé les drivers HP. Mais pas tout le temps !
>
>
> C'est a croire que chez HP y'en a un qui a trop lu ça :
>
>
> https://gist.github.com/aras-p/6224951
>
>
> Cordialement,
>
>
>
> Kevin CHAILLY
>
> Service Technique
>
> *Adeo-informatique*
>
> Tel. 04 688 24 688
>
> *www.adeo-informatique.fr *
>
>
> * *
> --
> *De :* frnog-requ...@frnog.org  de la part de
> Philippe ASTIER 
> *Envoyé :* vendredi 7 février 2020 14:15:01
> *À :* Emmanuel DECAEN; Cécile MARTRON via frnog
> *Objet :* Re: [FRnOG] [MISC] Deploiement WIFI
>
>
> Sur plusieurs iphones, les utilisateurs concernés ont du retenter plusieurs
> fois la première connexion (jusqu'à 10 fois pour un vieil
> iPhone) afin que cela fonctionne, c'est assez déroutant comme comportement.
> Une fois que c'est paramétré, plus de soucis, le téléphone se connecte
> et se reconnecte sans problème.
>
>
> J'ai pas demandé : sur un portail captif ou en natif ? Attention aux
> certificats auto-signés si redirection HTTPS par exemple.
> Attention aussi, il y a des fonctionnalités comme le band-steering qui
> posent des soucis (qu’Ubiquiti retire depuis le firmware 5.0 en beta
> d’ailleurs).
>
> Je parle bien de l'impression depuis le réseau Wifi entreprise (et pas depuis
> le réseau Wifi invités).
> Il y a beaucoup de gens dans la même situation avec les imprimantes HP sur
> les forums Ubiquiti.
>
>
> Les imprimantes HP et le réseau, c’est un poème… le truc genre « auro-IP »
> qui te met en l’air un réseau et tu comprends avec un wireshark que s’il ne
> trouve pas de DHCP, il en démarre un lui-même. Bref, je diverge mais on est
> vendredi. :)
>
> Pour contourner le problème, j'ai fini par désactiver le « Enable Multicast
> and Broadcast Filtering" sur le réseau Wifi invités (portail invités)
> pour que cela fonctionne de nouveau pour les utilisateurs du réseau Wifi
> entreprise.
>
>
> Si tu filtres le multicast/broadcast, tu casses le protocole Bonjour
> justement, donc faut pas. Par contre ce qui m’embête c’est que tu sembles
> suggérer que le faire sur un SSID le fait en faite au niveau de la borne
> (est-ce vraiment surprenant d’ailleurs ?).
>
> On peut en discuter en privé, si tu veux.
>
>
> Yep, tu as mon mail :)
>

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

Re: [FRnOG] [TECH] Discussion technique

[Damien DUJARDIN]

Merci pour tous ces retours.

On cherche juste à faire du DFZ en edge, donc effectivement un 9001-S avec
2 ports 10G en natif me semble être une bonne option.

Le jeu. 7 nov. 2019 à 23:29, Pierre Emeriaud  a écrit :

> Le jeu. 7 nov. 2019 à 23:19, loutre Mini  a
> écrit :
> >
> > Fonctionnellement un asr1001 sait faire tout ce que fait un 9001 ?
>
> Dans ce sens je ne sais pas. Mais un 9001 ne sait faire ni l2tp ni
> ipsec par exemple.
>
>
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/
>

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

Re: [FRnOG] [TECH] Discussion technique

[Damien DUJARDIN]

Ca c'est en 8GB.
Théoriquement en version 16GB c'est plus selon la datasheet:

Up to 3,500,000 IPv4 or 3,000,000 IPv6 routes - 16 GB Memory
BGP RR Scalability up to 11,500,000 IPv4 or 10,000,000 IPv6 routes - 16 GB
Memory

Bon après c'est la théorie hein, d'où ma question ..


Le jeu. 7 nov. 2019 à 21:42, Hugues Voiturier  a
écrit :

> Selon la Datasheet, le 1001-X c’est 1M Routes v4 ou 500K routes v6, une
> route v6 étant égale à 2 routes v4 en RIB
>
> Ce qui laisse quelque chose comme 120k entrées de rab avant que le matos
> ne soit en limite de RIB.
>
> Perso, j’achèterais plutôt un machin plus gros…
>
> > On 7 Nov 2019, at 21:28, Damien DUJARDIN 
> wrote:
> >
> > Bonsoir à tous,
> >
> > Pour le coup ça m’intéresserait également de savoir combien d'interco BGP
> > full table IPv4 et IPv6 vous arriver à faire rentrer dans un ASR 1001-X
> > 16GB ?
> > Le tout avec des temps de convergence corrects bien entendu..
> >
> > Est-ce le meilleur choix en ce moment (même hors Cisco) pour faire du
> > multihoming sur 3/4 liens de façon stable sans avoir à y revenir tous
> les 4
> > matins  ?
> >
> >
> > Le dim. 3 nov. 2019 à 09:03, Sébastien 65  a
> écrit :
> >
> >> Salut,
> >>
> >> Un ASR 1001 est capable d'avaler combien de full view IPv4 et IPv6 ?
> >>
> >> Est-ce que 2 v4 + 2 v6 et 2 IX (FR-IX/EQUI-IX) le mettra à genou ?
> >>
> >> Un retour de prod m'intéresse.
> >> --
> >> *De :* frnog-requ...@frnog.org  de la part de
> >> Jérôme Nicolle 
> >> *Envoyé :* samedi 2 novembre 2019 15:37:29
> >> *À :* frnog@frnog.org 
> >> *Objet :* Re: [FRnOG] [TECH] Discussion technique
> >>
> >> Salut Yoann,
> >>
> >> Le 01/11/2019 à 20:15, Yoann Lagrange a écrit :
> >>> Bonjour je souhaiterais commencer mon activité d'opérateur Télécom
> >>> ayant de bonnes connaissances en réseaux mais je ne souhaite pas du
> >>> tout utiliser la gamme ASR de chez cisco étant donné le prix
> >>> exorbitant pour le peux de bande passante.
> >>
> >> Un 1001x c'st 5-7k€ en broke. Si t'as pas de quoi t'en payer une paire
> >> pour commencer à jouer, tu vas en chier.
> >>
> >>> Les routeurs Microtik sont t-ils capable d'assurer le routage
> >>> (Statique et BGP) et la gestion des sessions PPPoE et IPoE.
> >>
> >> NON. Pas en IPv6, pas dans les versions actuelles. Et tu peux pas
> >> décemment monter un cœur de réseau sans dual-stack complet en fin 2019.
> >>
> >> Un cœur commercial, from scratch, en broke + presta, c'est 50-80k€ de
> >> CAPEX et 3k€ d'OPEX hors portes de collecte et support, avec tout le
> >> minimum des services requis (hors voix). Si t'as pas ça à mettre sur la
> >> table, mieux vaut t'en tenir à de la marque blanche.
> >>
> >> @+
> >>
> >> --
> >> Jérôme Nicolle
> >> +33 6 19 31 27 14
> >>
> >>
> >> ---
> >> 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] Discussion technique

[Damien DUJARDIN]

Bonsoir à tous,

Pour le coup ça m’intéresserait également de savoir combien d'interco BGP
full table IPv4 et IPv6 vous arriver à faire rentrer dans un ASR 1001-X
16GB ?
Le tout avec des temps de convergence corrects bien entendu..

Est-ce le meilleur choix en ce moment (même hors Cisco) pour faire du
multihoming sur 3/4 liens de façon stable sans avoir à y revenir tous les 4
matins  ?


Le dim. 3 nov. 2019 à 09:03, Sébastien 65  a écrit :

> Salut,
>
> Un ASR 1001 est capable d'avaler combien de full view IPv4 et IPv6 ?
>
> Est-ce que 2 v4 + 2 v6 et 2 IX (FR-IX/EQUI-IX) le mettra à genou ?
>
> Un retour de prod m'intéresse.
> --
> *De :* frnog-requ...@frnog.org  de la part de
> Jérôme Nicolle 
> *Envoyé :* samedi 2 novembre 2019 15:37:29
> *À :* frnog@frnog.org 
> *Objet :* Re: [FRnOG] [TECH] Discussion technique
>
> Salut Yoann,
>
> Le 01/11/2019 à 20:15, Yoann Lagrange a écrit :
> > Bonjour je souhaiterais commencer mon activité d'opérateur Télécom
> > ayant de bonnes connaissances en réseaux mais je ne souhaite pas du
> > tout utiliser la gamme ASR de chez cisco étant donné le prix
> > exorbitant pour le peux de bande passante.
>
> Un 1001x c'st 5-7k€ en broke. Si t'as pas de quoi t'en payer une paire
> pour commencer à jouer, tu vas en chier.
>
> > Les routeurs Microtik sont t-ils capable d'assurer le routage
> > (Statique et BGP) et la gestion des sessions PPPoE et IPoE.
>
> NON. Pas en IPv6, pas dans les versions actuelles. Et tu peux pas
> décemment monter un cœur de réseau sans dual-stack complet en fin 2019.
>
> Un cœur commercial, from scratch, en broke + presta, c'est 50-80k€ de
> CAPEX et 3k€ d'OPEX hors portes de collecte et support, avec tout le
> minimum des services requis (hors voix). Si t'as pas ça à mettre sur la
> table, mieux vaut t'en tenir à de la marque blanche.
>
> @+
>
> --
> Jérôme Nicolle
> +33 6 19 31 27 14
>
>
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/
>

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