Re: [FRnOG] [TECH] Umbrella perte icmp

[Fabien H]

Bonjour,

depuis une machine Linux  : mtr -t 208.67.222.222
depuis une machine Windows : utiliser WinMTR

Ca aidera à voir sur 15 minutes ou 1H à quel endroit se produit le problème
(attention certains routeurs rate-limitent l'ICMP volontairement)



Le mar. 21 mai 2024 à 09:24, Stéphane CIRCHIRILLO <
circhirillo.steph...@gmail.com> a écrit :

> Bonjour à tous,
>
> Nous constatons de façon très sporadique des pertes de ping durant quelques
> secondes (30-60s) vers les services DNS Umbrella (ex OpenDNS)
> 208.67.222.222.
>
> Seul ce service Internet est impacté, les SLA vers 8.8.8.8 et autres sont
> OK.
>
> Notre transitaire est Jaguar Network (FreePro), qui ne constate rien.
> L'OBL est Axione (plaque Vauclusienne).
>
> Auriez-vous des problème similaire vers Umbrella ?
> Des idées de diag. Pas de looking-glass trouvé pour Umbrella.
>
> Merci pour votre aide.
>
> --
> *CIRCHIRILLO Stéphane*
> 06 69 61 55 61
> circhirillo.steph...@gmail.com
>
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/
>

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

Re: [FRnOG] [TECH] annonces IP subnet administration sur nouveau transit IP

[Fabien H]

exact !

Le ven. 9 févr. 2024 à 13:42, David Ponzone  a
écrit :

> Les 2 transits peuvent même annoncer le PA en même temps, si le client
> conserve un lien vers chaque transit pendant 15 jours (il passera son
> default sur le nouveau au plus tôt par contre).
>
>
> Le 9 févr. 2024 à 13:39, Fabien H  a écrit :
>
> Impeccable :-)
>
> Donc environ 15 jours avant, le titulaire des IP met le 2eme AS sur le
> prefixe.
> Le jour J heure H, l'ancien opérateur arrête d'annoncer le préfixe à ses
> transitaires, et le nouvel opérateur annonce le préfixe à ses transitaires
> Environ 15 jours après, le titulaire des IP enlève l'ancien AS du préfixe
>
> Ca semble optimal avec très peu d'interruption de service
>
> Merci
>
> Le ven. 9 févr. 2024 à 13:35, Thomas Brenac  a écrit :
>
> Le RPKI est géré par le titulaire des IP dans son LIR et il peux mettre
> deux AS autorises sur un prefixe donne , puis virer l’un quelques semaines
> plus tard.
>
>
> ___
> Thomas BRENAC
> +33686263575
>
>
> On 9 Feb 2024, at 13:31, Fabien H  wrote:
>
> Merci pour vos réponses :
>
> l'administration a un bloc allocated PA mais pas d'ASN.
>
> Et effectivement ça ne sera pas en BGP mais en routage statique ... du coup
> imaginons que l'administration le jour J heure H modifie ses ROA existants
> ou ajoute un ROA en plus pour faire pointer sur le nouvel AS, j'ai peur que
> certains transitaires refusent le routage tant qu'ils n'ont pas mis à jour
> leur base RPKI ..
>
> ou alors c'est juste avec mes transitaires Upstream proches que je dois
> négocier ?
>
> Merci
>
>
> Le ven. 9 févr. 2024 à 13:23, ic  a écrit :
>
> io,
>
> On 9 Feb 2024, at 12:39, Marc Abel  wrote:
>
> Ce nouvel opérateur est alors un opérateur de transit, l'administration
>
> établit avec lui une liaison BGP, elle lui annonce ses subnets.
>
> sauf si ce n’est pas en BGP…  vu qu’il est mentionné que c’est l’AS du
> nouvel opérateur qui va annoncer le subnet.
>
> Une migration sans coupure semble compliquée dans ce cas…
>
> @Fabien tu peux clarifier "possèdent leurs propres plages d'adresse IP” ?
> Ils sont LIR ? C’est une PI ? Si c’est une sous-allocation de l’opérateur,
> ce n’est pas migrable...
>
> ++ ic
>
>
> ---
> 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] annonces IP subnet administration sur nouveau transit IP

[Fabien H]

Impeccable :-)

Donc environ 15 jours avant, le titulaire des IP met le 2eme AS sur le
prefixe.
Le jour J heure H, l'ancien opérateur arrête d'annoncer le préfixe à ses
transitaires, et le nouvel opérateur annonce le préfixe à ses transitaires
Environ 15 jours après, le titulaire des IP enlève l'ancien AS du préfixe

Ca semble optimal avec très peu d'interruption de service

Merci

Le ven. 9 févr. 2024 à 13:35, Thomas Brenac  a écrit :

> Le RPKI est géré par le titulaire des IP dans son LIR et il peux mettre
> deux AS autorises sur un prefixe donne , puis virer l’un quelques semaines
> plus tard.
>
>
> ___
> Thomas BRENAC
> +33686263575
>
>
> On 9 Feb 2024, at 13:31, Fabien H  wrote:
>
> Merci pour vos réponses :
>
> l'administration a un bloc allocated PA mais pas d'ASN.
>
> Et effectivement ça ne sera pas en BGP mais en routage statique ... du coup
> imaginons que l'administration le jour J heure H modifie ses ROA existants
> ou ajoute un ROA en plus pour faire pointer sur le nouvel AS, j'ai peur que
> certains transitaires refusent le routage tant qu'ils n'ont pas mis à jour
> leur base RPKI ..
>
> ou alors c'est juste avec mes transitaires Upstream proches que je dois
> négocier ?
>
> Merci
>
>
> Le ven. 9 févr. 2024 à 13:23, ic  a écrit :
>
> io,
>
> On 9 Feb 2024, at 12:39, Marc Abel  wrote:
>
> Ce nouvel opérateur est alors un opérateur de transit, l'administration
>
> établit avec lui une liaison BGP, elle lui annonce ses subnets.
>
> sauf si ce n’est pas en BGP…  vu qu’il est mentionné que c’est l’AS du
> nouvel opérateur qui va annoncer le subnet.
>
> Une migration sans coupure semble compliquée dans ce cas…
>
> @Fabien tu peux clarifier "possèdent leurs propres plages d'adresse IP” ?
> Ils sont LIR ? C’est une PI ? Si c’est une sous-allocation de l’opérateur,
> ce n’est pas migrable...
>
> ++ ic
>
>
> ---
> 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] annonces IP subnet administration sur nouveau transit IP

[Fabien H]

Merci pour vos réponses :

l'administration a un bloc allocated PA mais pas d'ASN.

Et effectivement ça ne sera pas en BGP mais en routage statique ... du coup
imaginons que l'administration le jour J heure H modifie ses ROA existants
ou ajoute un ROA en plus pour faire pointer sur le nouvel AS, j'ai peur que
certains transitaires refusent le routage tant qu'ils n'ont pas mis à jour
leur base RPKI ..

ou alors c'est juste avec mes transitaires Upstream proches que je dois
négocier ?

Merci


Le ven. 9 févr. 2024 à 13:23, ic  a écrit :

> io,
>
> > On 9 Feb 2024, at 12:39, Marc Abel  wrote:
> >
> > Ce nouvel opérateur est alors un opérateur de transit, l'administration
> établit avec lui une liaison BGP, elle lui annonce ses subnets.
>
> sauf si ce n’est pas en BGP…  vu qu’il est mentionné que c’est l’AS du
> nouvel opérateur qui va annoncer le subnet.
>
> Une migration sans coupure semble compliquée dans ce cas…
>
> @Fabien tu peux clarifier "possèdent leurs propres plages d'adresse IP” ?
> Ils sont LIR ? C’est une PI ? Si c’est une sous-allocation de l’opérateur,
> ce n’est pas migrable...
>
> ++ ic
>
>
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/
>

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

[FRnOG] [TECH] Re: annonces IP subnet administration sur nouveau transit IP

[Fabien H]

ROA pas SOA désolé :-)

Le ven. 9 févr. 2024 à 11:30, Fabien H  a écrit :

> Bonjour,
>
> certaines administrations (Départements par exemple) possèdent leurs
> propres plages d'adresse IP.
>
> Dans le cas d'un appel d'offres, l'opérateur Internet de l'administration
> peut être amené à changer. J'essaie de comprendre la procédure de migration
> pour que cela se fasse de manière transparente le jour J à l'heure H:
>
> J'imagine que quelques jours avant la migration de FAI (1 semaine ?), il
> faut déclarer au RIPE un nouveau SOA avec  l'AS du nouveau FAI et le subnet
> public de l'administration ?
>
> - il y a donc un nouveau SOA en parallèle du SOA déjà existant sur le
> subnet sur l'AS de l'ancien FAI ?
> - Pas d'impact si plusieurs SOA / plusieurs AS pour un même subnet au RIPE
> ?
> - Je suppose qu'on ne peut pas faire du déclaratif uniquement, il doit y
> avoir un échange d'une manière ou d'une autre avec le propriétaire du
> subnet ? (l'administration)
> - Je pense qu'il y aura le RPKI à gérer si applicable également
>
> Merci pour vos réponses
>
> Cordialement
> Fabien
>
>
>

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

[FRnOG] [TECH] annonces IP subnet administration sur nouveau transit IP

[Fabien H]

Bonjour,

certaines administrations (Départements par exemple) possèdent leurs
propres plages d'adresse IP.

Dans le cas d'un appel d'offres, l'opérateur Internet de l'administration
peut être amené à changer. J'essaie de comprendre la procédure de migration
pour que cela se fasse de manière transparente le jour J à l'heure H:

J'imagine que quelques jours avant la migration de FAI (1 semaine ?), il
faut déclarer au RIPE un nouveau SOA avec  l'AS du nouveau FAI et le subnet
public de l'administration ?

- il y a donc un nouveau SOA en parallèle du SOA déjà existant sur le
subnet sur l'AS de l'ancien FAI ?
- Pas d'impact si plusieurs SOA / plusieurs AS pour un même subnet au RIPE
?
- Je suppose qu'on ne peut pas faire du déclaratif uniquement, il doit y
avoir un échange d'une manière ou d'une autre avec le propriétaire du
subnet ? (l'administration)
- Je pense qu'il y aura le RPKI à gérer si applicable également

Merci pour vos réponses

Cordialement
Fabien

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

[FRnOG] [TECH] signalement ARCEP dysfonctionnement support FTTH

[Fabien H]

Bonjour,

cela fait plusieurs fois récemment que le support de l'opérateur OW..
n'honore pas les RDV de dépannage FTTH planifiés et cloture le ticket en
mentant sur la réalité (client non présent, non joignable sur le numéro
indiqué, ..) sans que nous puissions répondre, et donc avec responsabilité
client.

Avez vous déjà fait un signalement ARCEP, est-ce efficace ? Ou alors passer
par l'AOTA ?

Je tiens à préciser que nous n'avions pas ces problèmes de fiabilité sur
les dépannages SDSL et FTTO, qui se passaient globalement biens. Le fait
que ce soit du dépannage avec des sous traitants Grand Public sur la FTTH
ne doit surement pas aider, mais ça n'est pas mon problème, et surtout ça
ne justifie pas de mentir sur les suivis et de cloturer sans droit de
réponse.

Merci,
Fabien

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

Re: [FRnOG] [TECH] Stratégie redondance/branchement switchs coeur de réseau

[Fabien H]

Non pas forcément.

Après on peut aussi vouloir étendre le L2 sur plusieurs DC ? c'est pas bien
?


Le lun. 2 oct. 2023 à 15:16, Raphael Mazelier  a écrit :

> On 02/10/2023 15:13, Fabien H wrote:
>
> > Merci pour vos réponses.
> >
> > Dans mon esprit, je posais plus la question dans un contexte coeur de
> > réseau opérateur. On peut aussi ouvrir le débat dans un contexte campus
> > mais ce n'était pas le but premier..
>
> Coeur de réseau opérateur ? mais dans ce cas as tu vraiment besoin de L2
> inter-site ? :)
>
> --
> Raphael Mazelier
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/
>

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

Re: [FRnOG] [TECH] Stratégie redondance/branchement switchs coeur de réseau

[Fabien H]

Merci pour vos réponses.

Dans mon esprit, je posais plus la question dans un contexte coeur de
réseau opérateur. On peut aussi ouvrir le débat dans un contexte campus
mais ce n'était pas le but premier..

Le lun. 2 oct. 2023 à 14:57, Raphael Mazelier  a écrit :

> Well honnêtement pour un petit campus (définir le nombre de switchs)
> déployer de l'evpn me semble overkill. Parfois le plus simple le meilleur.
>
> Vu la statistiques de pannes personnellement je ne ferais ni stack ni truc
> machin truc mais je prendrais juste des switchs de spare avec un vrai
> entraînement pour les remplacer.
>
> Au pire, un peu de spanning tree si tu souhaites vraiment double attacher
> vers tes switchs leaf... je n'ai jamais vu de cas ou ce genre de redondance
> m'a sauvé de quoi ce soit (sachant que bien les so-called switch coeur de
> réseaux sont dans la même salle alimenté par la même source... ). En
> revanche toute les techniques de redondances m'ont causé bien des soucis..
>
> (c'est d'ailleurs valable dans bien des domaines systèmes également)
>
> --
> Raphael Mazelier
>
> On 02/10/2023 14:46, Thierry Chich wrote:
>
> > Bonjour
> >
> > Je suis assez en phase avec ce que tu dis dans les datacentres, ou les
> > MAN,  et tout le toutim, mais sur un site, je ne vois pas trop comment
> > tu rends le service au client. Le type arrive avec son pc, il recoit son
> > ip en dhcp, et il se passe quoi après ?
> >
> > C'est une question, pas une agression, c'est juste que je n'ai pas vu
> > d'archi de ce type en place, et je ne vois pas comment ça fonctionne.
> >
> > Le 02/10/2023 à 10:01, Nicolas Vuillermet a écrit :
> >
> >> Hello,
> >>
> >> En 2023 parler encore de stack est une aberration.
> >>
> >> à la limite du virtual chassis à la VSS et encore... ces technos
> >> sombres te finissent par péter entre les mains, il y a un moment dans
> >> le cycle de vie où tu te retrouves à redémarrer toute la stack...
> >> "Récemment", y'a 1 an quand j'étais sur un réseau legacy, j'ai une
> >> stack de C6840 qui m'a pété en pleine tronche ; debug ospf a mem-leak
> >> sur un des noeuds du chassis, reboot de celui-ci, au retour le L2
> >> passait plus entre les deux par contre le L3 nickel :>
> >>
> >> Dukou en 2023 ce qu'on fait ; *EVPN*.
> >>
> >> EVPN VxLAN ou MPLS en fonction de comment tu es riche, plan contrôle
> >> BGP, tout le monde est décideur dans ton réseau, tu peux rajouter des
> >> noeuds un peu où tu veux, tu peux faire un réseau de clos comme mettre
> >> tes switchs un peu n'importe où, entre Nexus 9k, Arista, Juniper
> >> QFX/MX, c'est pas le matériel qui manque.
> >>
> >> ça se debug bien mieux qu'une stack, ça sait interagir avec des
> >> Hyperviseurs vmware avec NSX ou proxmox avec l'intégration SDN... bref
> >>
> >> Je parle même pas du fait que t'as plus besoin de te poser de question
> >> de si tes membres vont se reconnaître après une mise à jour qui est un
> >> réel problème en cas de stack.
> >>
> >> P'tite overview Arista que j'aime bien :
> >> https://www.arista.com/en/um-eos/eos-evpn-overview
> >> D'ici 10 ans, ceux qui seront en pure L2 dans leur campus alors que le
> >> broke sera floodé de switch campus L2VPN capable seront bien en retard.
> >>
> >> De plus, des solutions SDN réelles apparaissent telle que Arista
> >> CloudVision ou Juniper Myst pour orchestrer un tel réseau quand faire
> >> une vingtaine de ligne de cli devient trop ardu.
> >>
> >> Nicolas
> >>
> >> Le 02/10/2023 à 09:14, Fabien H a écrit :
> >>
> >>> Bonjour,
> >>>
> >>> Avec le recul, que préconisez vous pour avoir une archi plus résiliente
> >>> possible au niveau des SW coeur de réseau ?
> >>>
> >>> Stack de switch avec LAG ?
> >>> switchs de type virtual chassis avec LAG virtuel ?
> >>>
> >>> La question porte aussi sur la fiabilité de l'architecture retenue en
> >>> cas
> >>> de défaillance d'un des switchs, est-ce que globalement, hors bugs,
> avec
> >>> des OS à jour, ça continue à fonctionner comme prévu (le stack
> >>> continue à
> >>> fonctionner sur 1 noeud ou le virtual chassis continue à fonctionner
> >>> sur 1
> >>> noeud)
> >>>
> >>> Merci pour vos retours,
> >>> Fabien
> >>>
> >>> ---
> >>> Liste de diffusion du FRnOG
> >>> htt

[FRnOG] [TECH] Stratégie redondance/branchement switchs coeur de réseau

[Fabien H]

Bonjour,

Avec le recul, que préconisez vous pour avoir une archi plus résiliente
possible au niveau des SW coeur de réseau ?

Stack de switch avec LAG ?
switchs de type virtual chassis avec LAG virtuel ?

La question porte aussi sur la fiabilité de l'architecture retenue en cas
de défaillance d'un des switchs, est-ce que globalement, hors bugs, avec
des OS à jour, ça continue à fonctionner comme prévu (le stack continue à
fonctionner sur 1 noeud ou le virtual chassis continue à fonctionner sur 1
noeud)

Merci pour vos retours,
Fabien

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

Re: [FRnOG] [TECH] Convertisseur 10G BiDi vers 10G LR ou SR ou BaseT

[Fabien H]

Bonjour,

La version SFP+ gèrerait les SFP 1G d'après les questions / réponses :
https://www.fs.com/fr/products/131591.html



Le ven. 25 août 2023 à 23:06, Clément Cavadore  a
écrit :

> Bonsoir,
>
> Et du sfp vers sfp (en 1G, donc), vous en avez vus ? On dirait que c'est
> plus compliqué à trouver que su SFP vers 1000BaseT.
>
> Chez FS je n'ai pas vu autre chose que du sfp+, savez vous si leur modèle
> gère aussi le 1G ? Si quelqu'un en a un sous la main et peur faire le test,
> le résultat m'intéresse :-)
>
> Bon week-end !
>
> Clément Cavadore
>
> Le 25 août 2023 12:47:36 GMT+02:00, Fabien H  a
> écrit :
> >Bonjour,
> >
> >effectivement on voit que ce n'est pas du même niveau qu'un media
> >converter. Je ne pense pas que mon client ait besoin d'aller aussi loin
> >mais je garde l'idée, merci
> >
> >Le ven. 25 août 2023 à 11:27, Julien RICHER  a écrit :
> >
> >>
> >> Le jeu. 24 août 2023 à 14:16, Fabien H  a
> écrit :
> >>
> >>> Bonjour,
> >>>
> >>> je recherche un convertisseur qui permette la conversion 10G BiDi vers
> 10G
> >>> LR ou SR ou BaseT.
> >>>
> >>> Il faudrait un produit bien entendu fiable, à un prix correct, et
> >>> acceptant
> >>> des SFP+ du marché.
> >>>
> >>> Avez-vous des références commercialisées actuellement ? Est-ce que FS
> part
> >>> exemple ferait ça ? Au pire du pire, un petit switch de marque peut
> faire
> >>> l'affaire.
> >>>
> >>
> >>
> >> Le vrai produit pour faire ça c'est un transponder.
> >> Cette carte par exemple ( https://www.fs.com/products/30515.html )
> gère
> >> 4x "10G vers 10G", donc par exemple multi-mode vers mono-mode, 10G-LR
> vers
> >> WDM...
> >>
> >> Il faut la mettre dans un chassis, par exemple :
> >> https://www.fs.com/products/39214.html
> >>
> >> C'est bien sûr la solution la plus chère par rapport à un switch ou un
> >> vulgaire media-converter, le choix dépend donc du besoin : transparence
> >> protocolaire, report de link, monitoring...
> >>
> >>
> >
> >---
> >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 10G BiDi vers 10G LR ou SR ou BaseT

[Fabien H]

Bonjour,

effectivement on voit que ce n'est pas du même niveau qu'un media
converter. Je ne pense pas que mon client ait besoin d'aller aussi loin
mais je garde l'idée, merci

Le ven. 25 août 2023 à 11:27, Julien RICHER  a écrit :

>
> Le jeu. 24 août 2023 à 14:16, Fabien H  a écrit :
>
>> Bonjour,
>>
>> je recherche un convertisseur qui permette la conversion 10G BiDi vers 10G
>> LR ou SR ou BaseT.
>>
>> Il faudrait un produit bien entendu fiable, à un prix correct, et
>> acceptant
>> des SFP+ du marché.
>>
>> Avez-vous des références commercialisées actuellement ? Est-ce que FS part
>> exemple ferait ça ? Au pire du pire, un petit switch de marque peut faire
>> l'affaire.
>>
>
>
> Le vrai produit pour faire ça c'est un transponder.
> Cette carte par exemple ( https://www.fs.com/products/30515.html )  gère
> 4x "10G vers 10G", donc par exemple multi-mode vers mono-mode, 10G-LR vers
> WDM...
>
> Il faut la mettre dans un chassis, par exemple :
> https://www.fs.com/products/39214.html
>
> C'est bien sûr la solution la plus chère par rapport à un switch ou un
> vulgaire media-converter, le choix dépend donc du besoin : transparence
> protocolaire, report de link, monitoring...
>
>

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

Re: [FRnOG] [TECH] Convertisseur 10G BiDi vers 10G LR ou SR ou BaseT

[Fabien H]

impecc merci pour ce retour précis :-)

Le jeu. 24 août 2023 à 15:12, Raphael Mazelier  a écrit :

> On 24/08/2023 14:52, Fabien H wrote:
>
> > Oups, désolé j'ai cherché sur google et fs en cherchant media converter
> > Bidi ou SR mais je n'étais pas tombé là desus : c'est un bon départ merci
> >
> > Reste à voir si quelqu'un les utilise et en est content dans le temps ..
>
> J'ai en mis en prod depuis genre 8ans et ils marchent toujours. Au prix du
> truc tu peux te permettre de prendre du spare.
>
> --
> Raphael Mazelier
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/
>

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

Re: [FRnOG] [TECH] Convertisseur 10G BiDi vers 10G LR ou SR ou BaseT

[Fabien H]

Effectivement pas mal le  CRS305-1G-4S+IN :
https://mikrotik.com/product/crs305_1g_4s_in :

les mini switch mikrotik sont stables ? (car j'avais lu que certains
routeurs de la marque avaient tendance à être instables dans certains
contextes (BGP, ..), mais rien à voir ?)

Merci



Le jeu. 24 août 2023 à 15:07, David Ponzone  a
écrit :

> Un petit switch Mikrotik avec 2 ports SFP+ peut aussi faire le job,
> peut-être moins cher, et permettra de superviser en plus.
>
> > Le 24 août 2023 à 14:52, Fabien H  a écrit :
> >
> > Oups, désolé j'ai cherché sur google et fs en cherchant media converter
> > Bidi ou SR mais je n'étais pas tombé là desus : c'est un bon départ merci
> >
> > Reste à voir si quelqu'un les utilise et en est content dans le temps ..
> >
> >
> > Le jeu. 24 août 2023 à 14:49, Vincent Tondellier via frnog <
> frnog@frnog.org>
> > a écrit :
> >
> >> Bonjour,
> >>
> >> On jeudi 24 août 2023 14:15:32 CEST, Fabien H wrote:
> >>> je recherche un convertisseur qui permette la conversion 10G BiDi vers
> >> 10G
> >>> LR ou SR ou BaseT.
> >>>
> >>> Il faudrait un produit bien entendu fiable, à un prix correct, et
> >> acceptant
> >>> des SFP+ du marché.
> >>>
> >>> Avez-vous des références commercialisées actuellement ? Est-ce que FS
> >> part
> >>> exemple ferait ça ?
> >>
> >> Je ne connais pas ces produits, mais 10s de recherche donnent ca :
> >>
> >> https://www.fs.com/fr/c/fiber-to-fiber-media-converters-1044
> >>
> >> https://www.fs.com/fr/c/copper-to-fiber-media-converters-1038
> >>
> >>
> >> ---
> >> 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 10G BiDi vers 10G LR ou SR ou BaseT

[Fabien H]

 Oups, désolé j'ai cherché sur google et fs en cherchant media converter
Bidi ou SR mais je n'étais pas tombé là desus : c'est un bon départ merci

Reste à voir si quelqu'un les utilise et en est content dans le temps ..


Le jeu. 24 août 2023 à 14:49, Vincent Tondellier via frnog 
a écrit :

> Bonjour,
>
> On jeudi 24 août 2023 14:15:32 CEST, Fabien H wrote:
> > je recherche un convertisseur qui permette la conversion 10G BiDi vers
> 10G
> > LR ou SR ou BaseT.
> >
> > Il faudrait un produit bien entendu fiable, à un prix correct, et
> acceptant
> > des SFP+ du marché.
> >
> > Avez-vous des références commercialisées actuellement ? Est-ce que FS
> part
> > exemple ferait ça ?
>
> Je ne connais pas ces produits, mais 10s de recherche donnent ca :
>
> https://www.fs.com/fr/c/fiber-to-fiber-media-converters-1044
>
> https://www.fs.com/fr/c/copper-to-fiber-media-converters-1038
>
>
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/
>

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

[FRnOG] [TECH] Convertisseur 10G BiDi vers 10G LR ou SR ou BaseT

[Fabien H]

Bonjour,

je recherche un convertisseur qui permette la conversion 10G BiDi vers 10G
LR ou SR ou BaseT.

Il faudrait un produit bien entendu fiable, à un prix correct, et acceptant
des SFP+ du marché.

Avez-vous des références commercialisées actuellement ? Est-ce que FS part
exemple ferait ça ? Au pire du pire, un petit switch de marque peut faire
l'affaire.

J'ai vu le produit Huawei OSN 850 mais il est en EOL.

Merci,
Fabien

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

[FRnOG] [BIZ] Fibre noire Lyon et péripherie

[Fabien H]

Bonjour,

pour un de nos clients nous recherchons un fournisseur de fibre noire / FON
entre son site de Lyon est et son site en périphérie de Lyon Est (distance
à vol d'oiseau 13 km en passant par le centre de Lyon)

Contraintes : Débit 10G
Latence < 5ms
Redondance de lien et cheminement

Nous savons que ça risque de chiffrer en FAS et ABO mais c'est son besoin

Une encapsulation L2 10G peut faire l'affaire aussi.

Merci pour vos retours en privé si vous souhaitez.

Cordialement,
Fabien

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

Re: [FRnOG] [TECH] ping Virtual-Access depuis routeur de terminaison

[Fabien H]

Problème résolu : en utilisant une  ip unnumbered LoopbackX au lieu de
Port-channel5.Y,
la connexion fonctionne et le ping ... source ... depuis le LNS aussi !

Merci David !

Virtual-Access3.63 is up, line protocol is up
  Hardware is Virtual Access interface
  Description: L2TP
  Interface is unnumbered. Using address of Loopback15 (X.Y.Z.T)
  MTU 1460 bytes, BW 10 Kbit/sec, DLY 10 usec,
 reliability 255/255, txload 31/255, rxload 9/255
  Encapsulation PPP, LCP Open
  Open: IPCP
  PPPoE vaccess, cloned from AAA, AAA, AAA, AAA, Virtual-Template6
  Vaccess status 0x0
  Keepalive set (10 sec)
 19 packets input, 352 bytes
 20 packets output, 297 bytes
  Last clearing of "show interface" counters never

Le jeu. 9 mars 2023 à 10:40, Fabien H  a écrit :

> Oui le CPE ping le 10.10.2.103 :
>
> #ping 10.10.2.103
> Type escape sequence to abort.
> Sending 5, 100-byte ICMP Echos to 10.10.2.103, timeout is 2 seconds:
> !
> Success rate is 100 percent (5/5), round-trip min/avg/max = 8/8/8 ms
>
> RAS sur Loopback10
>
> #show running-config interface Loopback 10
>
> interface Loopback10
>  description LOOPBACK10
>  ip address 10.10.2.103 255.255.255.255
> end
>
> Ca semble donc venir du fait que dans mon virtual template, l'ip
> unnumbered est une interface L2 et non pas une loopback ?
>
> Interface is unnumbered. Using address of Port-channel5.3968 (0.0.0.0)
>
>  Il me semble que je suis obligé de mettre cette interface pour que ça
> fonctionne
>
>
> Le jeu. 9 mars 2023 à 08:45, David Ponzone  a
> écrit :
>
>> Le CPE peut pinger 10.10.2.103 ?
>>
>> Loopback10 a pas une particularité (dans un VRF) ?
>>
>> > Le 9 mars 2023 à 07:27, Fabien H  a écrit :
>> >
>> > Sur cette interco (Orange) l'ip unnumbered est une interface niveau 2 :
>> >
>> > interface Virtual-Template6 type serial
>> > mtu 1460
>> > ip unnumbered Port-channel5.3968
>> > ip tcp adjust-mss 1420
>> > ppp authentication chap pap AAA_AUTH
>> > ppp authorization Telco-AAA
>> > ppp accounting Telco-AAA
>> >
>> > Le mer. 8 mars 2023 à 23:07, David Ponzone  a
>> > écrit :
>> >
>> >> C’est quoi l’IP dans le Virtual-Template du LNS ?
>> >> Généralement, c’est un ip unnumbered LoopbackX.
>> >>
>> >> Si tu ping le CPE avec cette IP là comme source, ça passe ?
>> >>
>> >>> Le 8 mars 2023 à 22:50, Fabien H  a écrit :
>> >>>
>> >>> Non aucune sur le Dialer0 ni sur le Virtual Template ...
>> >>>
>> >>>
>> >>>
>> >>> Le mer. 8 mars 2023 à 22:08, David Ponzone  a
>> >>> écrit :
>> >>>
>> >>>> Pas d’acl ?
>> >>>>
>> >>>> David Ponzone
>> >>>>
>> >>>>
>> >>>>
>> >>>>> Le 8 mars 2023 à 21:39, Fabien H  a écrit :
>> >>>>>
>> >>>>> Sur le CPE
>> >>>>>
>> >>>>> #show ip route 10.10.2.103
>> >>>>> % Subnet not in table
>> >>>>>
>> >>>>> C'est donc la route par défaut qui est prise en compte (qui
>> fonctionne
>> >> le
>> >>>>> client a bien Internet)
>> >>>>>
>> >>>>> #show ip route 0.0.0.0
>> >>>>> Routing entry for 0.0.0.0/0, supernet
>> >>>>> Known via "static", distance 1, metric 0 (connected), candidate
>> default
>> >>>>> path
>> >>>>> Routing Descriptor Blocks:
>> >>>>> * directly connected, via Dialer0
>> >>>>>Route metric is 0, traffic share count is 1
>> >>>>>
>> >>>>>
>> >>>>>
>> >>>>>> Le mer. 8 mars 2023 à 21:10, David Ponzone <
>> david.ponz...@gmail.com>
>> >> a
>> >>>>>> écrit :
>> >>>>>>
>> >>>>>> Ok alors ce qu’il faut c’est un
>> >>>>>>
>> >>>>>> show ip route 10.10.2.103
>> >>>>>>
>> >>>>>> sur le CPE
>> >>>>>>
>> >>>>>> David Ponzone
>> >>>>>>
>> >>>>>>
>> >>>>>>
>> >>>>>> Le 8 mars 2023 à 20:46, Fabien H  a écrit
>> :
>> >>>>>>
>> >>>

Re: [FRnOG] [TECH] ping Virtual-Access depuis routeur de terminaison

[Fabien H]

Oui le CPE ping le 10.10.2.103 :

#ping 10.10.2.103
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.10.2.103, timeout is 2 seconds:
!
Success rate is 100 percent (5/5), round-trip min/avg/max = 8/8/8 ms

RAS sur Loopback10

#show running-config interface Loopback 10

interface Loopback10
 description LOOPBACK10
 ip address 10.10.2.103 255.255.255.255
end

Ca semble donc venir du fait que dans mon virtual template, l'ip unnumbered
est une interface L2 et non pas une loopback ?

Interface is unnumbered. Using address of Port-channel5.3968 (0.0.0.0)

 Il me semble que je suis obligé de mettre cette interface pour que ça
fonctionne


Le jeu. 9 mars 2023 à 08:45, David Ponzone  a
écrit :

> Le CPE peut pinger 10.10.2.103 ?
>
> Loopback10 a pas une particularité (dans un VRF) ?
>
> > Le 9 mars 2023 à 07:27, Fabien H  a écrit :
> >
> > Sur cette interco (Orange) l'ip unnumbered est une interface niveau 2 :
> >
> > interface Virtual-Template6 type serial
> > mtu 1460
> > ip unnumbered Port-channel5.3968
> > ip tcp adjust-mss 1420
> > ppp authentication chap pap AAA_AUTH
> > ppp authorization Telco-AAA
> > ppp accounting Telco-AAA
> >
> > Le mer. 8 mars 2023 à 23:07, David Ponzone  a
> > écrit :
> >
> >> C’est quoi l’IP dans le Virtual-Template du LNS ?
> >> Généralement, c’est un ip unnumbered LoopbackX.
> >>
> >> Si tu ping le CPE avec cette IP là comme source, ça passe ?
> >>
> >>> Le 8 mars 2023 à 22:50, Fabien H  a écrit :
> >>>
> >>> Non aucune sur le Dialer0 ni sur le Virtual Template ...
> >>>
> >>>
> >>>
> >>> Le mer. 8 mars 2023 à 22:08, David Ponzone  a
> >>> écrit :
> >>>
> >>>> Pas d’acl ?
> >>>>
> >>>> David Ponzone
> >>>>
> >>>>
> >>>>
> >>>>> Le 8 mars 2023 à 21:39, Fabien H  a écrit :
> >>>>>
> >>>>> Sur le CPE
> >>>>>
> >>>>> #show ip route 10.10.2.103
> >>>>> % Subnet not in table
> >>>>>
> >>>>> C'est donc la route par défaut qui est prise en compte (qui
> fonctionne
> >> le
> >>>>> client a bien Internet)
> >>>>>
> >>>>> #show ip route 0.0.0.0
> >>>>> Routing entry for 0.0.0.0/0, supernet
> >>>>> Known via "static", distance 1, metric 0 (connected), candidate
> default
> >>>>> path
> >>>>> Routing Descriptor Blocks:
> >>>>> * directly connected, via Dialer0
> >>>>>Route metric is 0, traffic share count is 1
> >>>>>
> >>>>>
> >>>>>
> >>>>>> Le mer. 8 mars 2023 à 21:10, David Ponzone  >
> >> a
> >>>>>> écrit :
> >>>>>>
> >>>>>> Ok alors ce qu’il faut c’est un
> >>>>>>
> >>>>>> show ip route 10.10.2.103
> >>>>>>
> >>>>>> sur le CPE
> >>>>>>
> >>>>>> David Ponzone
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> Le 8 mars 2023 à 20:46, Fabien H  a écrit :
> >>>>>>
> >>>>>> En fait je fais tous les tests depuis le routeur de terminaison :
> >>>>>>
> >>>>>> Quand je parlais de Loopback10 je faisais le ping depuis le routeur
> de
> >>>>>> coeur
> >>>>>>
> >>>>>> #ping 10.10.49.70 source 10.10.2.103
> >>>>>> Type escape sequence to abort.
> >>>>>> Sending 5, 100-byte ICMP Echos to 10.10.49.70, timeout is 2 seconds:
> >>>>>> Packet sent with a source address of 10.10.2.103
> >>>>>> .
> >>>>>>
> >>>>>>
> >>>>>> #show ip route 10.10.49.70
> >>>>>> Routing entry for 10.10.49.70/32
> >>>>>> Known via "connected", distance 0, metric 0 (connected, via
> interface)
> >>>>>> Routing Descriptor Blocks:
> >>>>>> * directly connected, via Virtual-Access3.42
> >>>>>>   Route metric is 0, traffic share count is 1
> >>>>>>
> >>>>>> #show ip route 10.10.2.103
> >>>>>> Routing entry for 10.10.2.103/32
> &

Re: [FRnOG] [TECH] ping Virtual-Access depuis routeur de terminaison

[Fabien H]

Sur cette interco (Orange) l'ip unnumbered est une interface niveau 2 :

interface Virtual-Template6 type serial
 mtu 1460
 ip unnumbered Port-channel5.3968
 ip tcp adjust-mss 1420
 ppp authentication chap pap AAA_AUTH
 ppp authorization Telco-AAA
 ppp accounting Telco-AAA

Le mer. 8 mars 2023 à 23:07, David Ponzone  a
écrit :

> C’est quoi l’IP dans le Virtual-Template du LNS ?
> Généralement, c’est un ip unnumbered LoopbackX.
>
> Si tu ping le CPE avec cette IP là comme source, ça passe ?
>
> > Le 8 mars 2023 à 22:50, Fabien H  a écrit :
> >
> > Non aucune sur le Dialer0 ni sur le Virtual Template ...
> >
> >
> >
> > Le mer. 8 mars 2023 à 22:08, David Ponzone  a
> > écrit :
> >
> >> Pas d’acl ?
> >>
> >> David Ponzone
> >>
> >>
> >>
> >>> Le 8 mars 2023 à 21:39, Fabien H  a écrit :
> >>>
> >>> Sur le CPE
> >>>
> >>> #show ip route 10.10.2.103
> >>> % Subnet not in table
> >>>
> >>> C'est donc la route par défaut qui est prise en compte (qui fonctionne
> le
> >>> client a bien Internet)
> >>>
> >>> #show ip route 0.0.0.0
> >>> Routing entry for 0.0.0.0/0, supernet
> >>> Known via "static", distance 1, metric 0 (connected), candidate default
> >>> path
> >>> Routing Descriptor Blocks:
> >>> * directly connected, via Dialer0
> >>> Route metric is 0, traffic share count is 1
> >>>
> >>>
> >>>
> >>>> Le mer. 8 mars 2023 à 21:10, David Ponzone 
> a
> >>>> écrit :
> >>>>
> >>>> Ok alors ce qu’il faut c’est un
> >>>>
> >>>> show ip route 10.10.2.103
> >>>>
> >>>> sur le CPE
> >>>>
> >>>> David Ponzone
> >>>>
> >>>>
> >>>>
> >>>> Le 8 mars 2023 à 20:46, Fabien H  a écrit :
> >>>>
> >>>> En fait je fais tous les tests depuis le routeur de terminaison :
> >>>>
> >>>> Quand je parlais de Loopback10 je faisais le ping depuis le routeur de
> >>>> coeur
> >>>>
> >>>> #ping 10.10.49.70 source 10.10.2.103
> >>>> Type escape sequence to abort.
> >>>> Sending 5, 100-byte ICMP Echos to 10.10.49.70, timeout is 2 seconds:
> >>>> Packet sent with a source address of 10.10.2.103
> >>>> .
> >>>>
> >>>>
> >>>> #show ip route 10.10.49.70
> >>>> Routing entry for 10.10.49.70/32
> >>>> Known via "connected", distance 0, metric 0 (connected, via interface)
> >>>> Routing Descriptor Blocks:
> >>>> * directly connected, via Virtual-Access3.42
> >>>>Route metric is 0, traffic share count is 1
> >>>>
> >>>> #show ip route 10.10.2.103
> >>>> Routing entry for 10.10.2.103/32
> >>>> Known via "connected", distance 0, metric 0 (connected, via interface)
> >>>> Routing Descriptor Blocks:
> >>>> * directly connected, via Loopback10
> >>>>Route metric is 0, traffic share count is 1
> >>>>
> >>>>
> >>>>
> >>>>
> >>>> #show interfaces Virtual-Access3.42
> >>>> Virtual-Access3.42 is up, line protocol is up
> >>>> Hardware is Virtual Access interface
> >>>> Description: L2TP
> >>>> Interface is unnumbered. Using address of Port-channel5.3968 (0.0.0.0)
> >>>> MTU 1460 bytes, BW 10 Kbit/sec, DLY 10 usec,
> >>>>   reliability 255/255, txload 13/255, rxload 1/255
> >>>> Encapsulation PPP, LCP Open
> >>>> Open: IPCP
> >>>> PPPoE vaccess, cloned from AAA, AAA, AAA, Virtual-Template7
> >>>> Vaccess status 0x0
> >>>> Keepalive set (10 sec)
> >>>>   31877351 packets input, 8299425416 bytes
> >>>>   49833640 packets output, 45207837399 bytes
> >>>> Last clearing of "show interface" counters never
> >>>>
> >>>>
> >>>>
> >>>>
> >>>> Le mer. 8 mars 2023 à 20:09, David Ponzone 
> a
> >>>> écrit :
> >>>>
> >>>> Sur le CPE, fais un:
> >>>>
> >>>> show ip route 
> >>>>
> >>>>
> >>>> Est-ce que Loopack10 est l’interface que tu utilises dans ton
> >>>>
> >>>> Virtual-Template ?
> >>>>
> >>>>
> >>>> Le 8 mars 2023 à 20:03, Fabien H  a écrit :
> >>>>
> >>>>
> >>>> Bonjour,
> >>>>
> >>>>
> >>>> j'essaie de pinger une IP portée par une interface Virtual-Access (un
> >>>>
> >>>> ADSL)
> >>>>
> >>>> depuis le routeur de terminaison lui-même en coeur de réseau mais cela
> >> ne
> >>>>
> >>>> fonctionne pas.
> >>>>
> >>>>
> >>>> Idem quand je fais
> >>>>
> >>>>
> >>>> ping  source Loopback10
> >>>>
> >>>>
> >>>> avec Loopback10 porté par le routeur de terminaison.
> >>>>
> >>>>
> >>>> Savez-vous pourquoi ?
> >>>>
> >>>>
> >>>> Pourtant tout semble correct au niveau routage pour que cela
> fonctionne.
> >>>>
> >>>> Un
> >>>>
> >>>> ping depuis un autre routeur de l'infra avec les
> >>>>
> >>>> routes
> >>>>
> >>>> qui vont bien fonctionne.
> >>>>
> >>>>
> >>>> Merci,
> >>>>
> >>>> Fabien
> >>>>
> >>>>
> >>>> ---
> >>>>
> >>>> 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] ping Virtual-Access depuis routeur de terminaison

[Fabien H]

Non aucune sur le Dialer0 ni sur le Virtual Template ...



Le mer. 8 mars 2023 à 22:08, David Ponzone  a
écrit :

> Pas d’acl ?
>
> David Ponzone
>
>
>
> > Le 8 mars 2023 à 21:39, Fabien H  a écrit :
> >
> > Sur le CPE
> >
> > #show ip route 10.10.2.103
> > % Subnet not in table
> >
> > C'est donc la route par défaut qui est prise en compte (qui fonctionne le
> > client a bien Internet)
> >
> > #show ip route 0.0.0.0
> > Routing entry for 0.0.0.0/0, supernet
> >  Known via "static", distance 1, metric 0 (connected), candidate default
> > path
> >  Routing Descriptor Blocks:
> >  * directly connected, via Dialer0
> >  Route metric is 0, traffic share count is 1
> >
> >
> >
> >> Le mer. 8 mars 2023 à 21:10, David Ponzone  a
> >> écrit :
> >>
> >> Ok alors ce qu’il faut c’est un
> >>
> >> show ip route 10.10.2.103
> >>
> >> sur le CPE
> >>
> >> David Ponzone
> >>
> >>
> >>
> >> Le 8 mars 2023 à 20:46, Fabien H  a écrit :
> >>
> >> En fait je fais tous les tests depuis le routeur de terminaison :
> >>
> >> Quand je parlais de Loopback10 je faisais le ping depuis le routeur de
> >> coeur
> >>
> >> #ping 10.10.49.70 source 10.10.2.103
> >> Type escape sequence to abort.
> >> Sending 5, 100-byte ICMP Echos to 10.10.49.70, timeout is 2 seconds:
> >> Packet sent with a source address of 10.10.2.103
> >> .
> >>
> >>
> >> #show ip route 10.10.49.70
> >> Routing entry for 10.10.49.70/32
> >> Known via "connected", distance 0, metric 0 (connected, via interface)
> >> Routing Descriptor Blocks:
> >> * directly connected, via Virtual-Access3.42
> >> Route metric is 0, traffic share count is 1
> >>
> >> #show ip route 10.10.2.103
> >> Routing entry for 10.10.2.103/32
> >> Known via "connected", distance 0, metric 0 (connected, via interface)
> >> Routing Descriptor Blocks:
> >> * directly connected, via Loopback10
> >> Route metric is 0, traffic share count is 1
> >>
> >>
> >>
> >>
> >> #show interfaces Virtual-Access3.42
> >> Virtual-Access3.42 is up, line protocol is up
> >> Hardware is Virtual Access interface
> >> Description: L2TP
> >> Interface is unnumbered. Using address of Port-channel5.3968 (0.0.0.0)
> >> MTU 1460 bytes, BW 10 Kbit/sec, DLY 10 usec,
> >>reliability 255/255, txload 13/255, rxload 1/255
> >> Encapsulation PPP, LCP Open
> >> Open: IPCP
> >> PPPoE vaccess, cloned from AAA, AAA, AAA, Virtual-Template7
> >> Vaccess status 0x0
> >> Keepalive set (10 sec)
> >>31877351 packets input, 8299425416 bytes
> >>49833640 packets output, 45207837399 bytes
> >> Last clearing of "show interface" counters never
> >>
> >>
> >>
> >>
> >> Le mer. 8 mars 2023 à 20:09, David Ponzone  a
> >> écrit :
> >>
> >> Sur le CPE, fais un:
> >>
> >> show ip route 
> >>
> >>
> >> Est-ce que Loopack10 est l’interface que tu utilises dans ton
> >>
> >> Virtual-Template ?
> >>
> >>
> >> Le 8 mars 2023 à 20:03, Fabien H  a écrit :
> >>
> >>
> >> Bonjour,
> >>
> >>
> >> j'essaie de pinger une IP portée par une interface Virtual-Access (un
> >>
> >> ADSL)
> >>
> >> depuis le routeur de terminaison lui-même en coeur de réseau mais cela
> ne
> >>
> >> fonctionne pas.
> >>
> >>
> >> Idem quand je fais
> >>
> >>
> >> ping  source Loopback10
> >>
> >>
> >> avec Loopback10 porté par le routeur de terminaison.
> >>
> >>
> >> Savez-vous pourquoi ?
> >>
> >>
> >> Pourtant tout semble correct au niveau routage pour que cela fonctionne.
> >>
> >> Un
> >>
> >> ping depuis un autre routeur de l'infra avec les
> >>
> >> routes
> >>
> >> qui vont bien fonctionne.
> >>
> >>
> >> Merci,
> >>
> >> Fabien
> >>
> >>
> >> ---
> >>
> >> 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] ping Virtual-Access depuis routeur de terminaison

[Fabien H]

Sur le CPE

#show ip route 10.10.2.103
% Subnet not in table

C'est donc la route par défaut qui est prise en compte (qui fonctionne le
client a bien Internet)

#show ip route 0.0.0.0
Routing entry for 0.0.0.0/0, supernet
  Known via "static", distance 1, metric 0 (connected), candidate default
path
  Routing Descriptor Blocks:
  * directly connected, via Dialer0
  Route metric is 0, traffic share count is 1



Le mer. 8 mars 2023 à 21:10, David Ponzone  a
écrit :

> Ok alors ce qu’il faut c’est un
>
> show ip route 10.10.2.103
>
> sur le CPE
>
> David Ponzone
>
>
>
> Le 8 mars 2023 à 20:46, Fabien H  a écrit :
>
> En fait je fais tous les tests depuis le routeur de terminaison :
>
> Quand je parlais de Loopback10 je faisais le ping depuis le routeur de
> coeur
>
> #ping 10.10.49.70 source 10.10.2.103
> Type escape sequence to abort.
> Sending 5, 100-byte ICMP Echos to 10.10.49.70, timeout is 2 seconds:
> Packet sent with a source address of 10.10.2.103
> .
>
>
> #show ip route 10.10.49.70
> Routing entry for 10.10.49.70/32
>  Known via "connected", distance 0, metric 0 (connected, via interface)
>  Routing Descriptor Blocks:
>  * directly connected, via Virtual-Access3.42
>  Route metric is 0, traffic share count is 1
>
> #show ip route 10.10.2.103
> Routing entry for 10.10.2.103/32
>  Known via "connected", distance 0, metric 0 (connected, via interface)
>  Routing Descriptor Blocks:
>  * directly connected, via Loopback10
>  Route metric is 0, traffic share count is 1
>
>
>
>
> #show interfaces Virtual-Access3.42
> Virtual-Access3.42 is up, line protocol is up
>  Hardware is Virtual Access interface
>  Description: L2TP
>  Interface is unnumbered. Using address of Port-channel5.3968 (0.0.0.0)
>  MTU 1460 bytes, BW 10 Kbit/sec, DLY 10 usec,
> reliability 255/255, txload 13/255, rxload 1/255
>  Encapsulation PPP, LCP Open
>  Open: IPCP
>  PPPoE vaccess, cloned from AAA, AAA, AAA, Virtual-Template7
>  Vaccess status 0x0
>  Keepalive set (10 sec)
> 31877351 packets input, 8299425416 bytes
> 49833640 packets output, 45207837399 bytes
>  Last clearing of "show interface" counters never
>
>
>
>
> Le mer. 8 mars 2023 à 20:09, David Ponzone  a
> écrit :
>
> Sur le CPE, fais un:
>
> show ip route 
>
>
> Est-ce que Loopack10 est l’interface que tu utilises dans ton
>
> Virtual-Template ?
>
>
> Le 8 mars 2023 à 20:03, Fabien H  a écrit :
>
>
> Bonjour,
>
>
> j'essaie de pinger une IP portée par une interface Virtual-Access (un
>
> ADSL)
>
> depuis le routeur de terminaison lui-même en coeur de réseau mais cela ne
>
> fonctionne pas.
>
>
> Idem quand je fais
>
>
> ping  source Loopback10
>
>
> avec Loopback10 porté par le routeur de terminaison.
>
>
> Savez-vous pourquoi ?
>
>
> Pourtant tout semble correct au niveau routage pour que cela fonctionne.
>
> Un
>
> ping depuis un autre routeur de l'infra avec les
>
> routes
>
> qui vont bien fonctionne.
>
>
> Merci,
>
> Fabien
>
>
> ---
>
> 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] ping Virtual-Access depuis routeur de terminaison

[Fabien H]

routeur de Terminaison pour moi c'est routeur de coeur désolé !

Le mer. 8 mars 2023 à 20:46, Fabien H  a écrit :

> En fait je fais tous les tests depuis le routeur de terminaison :
>
> Quand je parlais de Loopback10 je faisais le ping depuis le routeur de
> coeur
>
> #ping 10.10.49.70 source 10.10.2.103
> Type escape sequence to abort.
> Sending 5, 100-byte ICMP Echos to 10.10.49.70, timeout is 2 seconds:
> Packet sent with a source address of 10.10.2.103
> .
>
>
> #show ip route 10.10.49.70
> Routing entry for 10.10.49.70/32
>   Known via "connected", distance 0, metric 0 (connected, via interface)
>   Routing Descriptor Blocks:
>   * directly connected, via Virtual-Access3.42
>   Route metric is 0, traffic share count is 1
>
> #show ip route 10.10.2.103
> Routing entry for 10.10.2.103/32
>   Known via "connected", distance 0, metric 0 (connected, via interface)
>   Routing Descriptor Blocks:
>   * directly connected, via Loopback10
>   Route metric is 0, traffic share count is 1
>
>
>
>
> #show interfaces Virtual-Access3.42
> Virtual-Access3.42 is up, line protocol is up
>   Hardware is Virtual Access interface
>   Description: L2TP
>   Interface is unnumbered. Using address of Port-channel5.3968 (0.0.0.0)
>   MTU 1460 bytes, BW 10 Kbit/sec, DLY 10 usec,
>  reliability 255/255, txload 13/255, rxload 1/255
>   Encapsulation PPP, LCP Open
>   Open: IPCP
>   PPPoE vaccess, cloned from AAA, AAA, AAA, Virtual-Template7
>   Vaccess status 0x0
>   Keepalive set (10 sec)
>  31877351 packets input, 8299425416 bytes
>  49833640 packets output, 45207837399 bytes
>   Last clearing of "show interface" counters never
>
>
>
>
> Le mer. 8 mars 2023 à 20:09, David Ponzone  a
> écrit :
>
>> Sur le CPE, fais un:
>> show ip route 
>>
>> Est-ce que Loopack10 est l’interface que tu utilises dans ton
>> Virtual-Template ?
>>
>> > Le 8 mars 2023 à 20:03, Fabien H  a écrit :
>> >
>> > Bonjour,
>> >
>> > j'essaie de pinger une IP portée par une interface Virtual-Access (un
>> ADSL)
>> > depuis le routeur de terminaison lui-même en coeur de réseau mais cela
>> ne
>> > fonctionne pas.
>> >
>> > Idem quand je fais
>> >
>> > ping  source Loopback10
>> >
>> > avec Loopback10 porté par le routeur de terminaison.
>> >
>> > Savez-vous pourquoi ?
>> >
>> > Pourtant tout semble correct au niveau routage pour que cela
>> fonctionne. Un
>> > ping depuis un autre routeur de l'infra avec les
>> routes
>> > qui vont bien fonctionne.
>> >
>> > Merci,
>> > Fabien
>> >
>> > ---
>> > Liste de diffusion du FRnOG
>> > http://www.frnog.org/
>>
>>

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

Re: [FRnOG] [TECH] ping Virtual-Access depuis routeur de terminaison

[Fabien H]

En fait je fais tous les tests depuis le routeur de terminaison :

Quand je parlais de Loopback10 je faisais le ping depuis le routeur de coeur

#ping 10.10.49.70 source 10.10.2.103
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.10.49.70, timeout is 2 seconds:
Packet sent with a source address of 10.10.2.103
.


#show ip route 10.10.49.70
Routing entry for 10.10.49.70/32
  Known via "connected", distance 0, metric 0 (connected, via interface)
  Routing Descriptor Blocks:
  * directly connected, via Virtual-Access3.42
  Route metric is 0, traffic share count is 1

#show ip route 10.10.2.103
Routing entry for 10.10.2.103/32
  Known via "connected", distance 0, metric 0 (connected, via interface)
  Routing Descriptor Blocks:
  * directly connected, via Loopback10
  Route metric is 0, traffic share count is 1




#show interfaces Virtual-Access3.42
Virtual-Access3.42 is up, line protocol is up
  Hardware is Virtual Access interface
  Description: L2TP
  Interface is unnumbered. Using address of Port-channel5.3968 (0.0.0.0)
  MTU 1460 bytes, BW 10 Kbit/sec, DLY 10 usec,
 reliability 255/255, txload 13/255, rxload 1/255
  Encapsulation PPP, LCP Open
  Open: IPCP
  PPPoE vaccess, cloned from AAA, AAA, AAA, Virtual-Template7
  Vaccess status 0x0
  Keepalive set (10 sec)
 31877351 packets input, 8299425416 bytes
 49833640 packets output, 45207837399 bytes
  Last clearing of "show interface" counters never




Le mer. 8 mars 2023 à 20:09, David Ponzone  a
écrit :

> Sur le CPE, fais un:
> show ip route 
>
> Est-ce que Loopack10 est l’interface que tu utilises dans ton
> Virtual-Template ?
>
> > Le 8 mars 2023 à 20:03, Fabien H  a écrit :
> >
> > Bonjour,
> >
> > j'essaie de pinger une IP portée par une interface Virtual-Access (un
> ADSL)
> > depuis le routeur de terminaison lui-même en coeur de réseau mais cela ne
> > fonctionne pas.
> >
> > Idem quand je fais
> >
> > ping  source Loopback10
> >
> > avec Loopback10 porté par le routeur de terminaison.
> >
> > Savez-vous pourquoi ?
> >
> > Pourtant tout semble correct au niveau routage pour que cela fonctionne.
> Un
> > ping depuis un autre routeur de l'infra avec les
> routes
> > qui vont bien fonctionne.
> >
> > Merci,
> > Fabien
> >
> > ---
> > Liste de diffusion du FRnOG
> > http://www.frnog.org/
>
>

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

[FRnOG] [TECH] ping Virtual-Access depuis routeur de terminaison

[Fabien H]

Bonjour,

j'essaie de pinger une IP portée par une interface Virtual-Access (un ADSL)
depuis le routeur de terminaison lui-même en coeur de réseau mais cela ne
fonctionne pas.

Idem quand je fais

ping  source Loopback10

avec Loopback10 porté par le routeur de terminaison.

Savez-vous pourquoi ?

Pourtant tout semble correct au niveau routage pour que cela fonctionne. Un
ping depuis un autre routeur de l'infra avec les routes
qui vont bien fonctionne.

Merci,
Fabien

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

Re: [FRnOG] [TECH] Valeur MTU PPPOE FTTH

[Fabien H]

Peut-être vérifier sur ton LNS que ton interface de Collecte opérateur ait
bien un MTU à minimum 2000 ?

Le ven. 10 févr. 2023 à 13:25, Sébastien 65  a écrit :

> Sur le CPE j'ai le MRU à 1492 et MRRU à 1524 comme sur le LNS, sauf que je
> n'ai aucune indication de type Reducing MTU sur le CPE.
>
> J'ai l'impression que sur la chaine SFR il y a un équipement qui fait
> n'importe quoi et me bouffe mon MTU !
>
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/
>

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

Re: [FRnOG] [TECH] SBC - Proxy SIP

[Fabien H]

Bonjour,

ne pas oublier non plus que Freeswitch avec l'option bypass_media peut
faire de manière élégante un bon SBC en traitant uniquement la
signalisation et en forwardant le média vers des serveurs média (asterisk
ou FS). Bien sur l'empreinte mémoire est beaucoup plus lourde qu'un
openSIPS, mais la mise en oeuvre beaucoup plus simple (la gestion des RFC
est simplifiée)



Le mer. 29 juin 2022 à 11:56, Benoît GIGAREL  a
écrit :

> Bonjour à tous,
>
> Merci pour ses premiers retours.
>
> Effectivement derrière ce mot SBC, il y a plusieurs fonctionnalités qui
> s’y cache et notre recherche est sur la distribution de notre futur Trunk
> C4 vers des trunk C5 fournis à nos clients.
>
> On revient au final toujours à Kamailio  (Pour OpenSIPS, j’ai pas
> forcément eu des retours positifs dans sa gestion en production), car les
> solutions propriétaires représentent un budget non négligeable.
>
> Il va falloir se plonger dans les RFC 
>
>
> Cordialement,
>
> 
> [cid:image001.png@01D88BAB.B0908780]
>
> Benoît GIGAREL
>
> Téléphone : +33(0)5 54 81 00 05
> Mail :  bgiga...@izarlink.com
> Web : www.izarlink.com
> 45 allée Th. Monod - Technopole Izarbel - 64210 BIDART
>
> Confidentialité : Ce message et les éventuelles pièces attachées sont
> confidentiels.
> Si vous avez reçu ce message par erreur, veuillez en informer l'expéditeur
> immédiatement et ne pas divulguer le contenu à une tierce personne.
> Ne pas l'utiliser pour quelque raison que ce soit, ne pas stocker ou
> copier l'information qu'il contient sur un quelconque support.
>
> De : Greg 
> Envoyé : mercredi 29 juin 2022 11:06
> À : David Ponzone 
> Cc : Jacques MICHAU ; Alain Bieuzent <
> alain.bieuz...@free.fr>; Mickael Monsieur ;
> Benoît GIGAREL ; frnog-tech 
> Objet : Re: [FRnOG] [TECH] SBC - Proxy SIP
>
> Bonjour, vous pouvez connecter les trunk sip des clients sur telcobridges,
> les cas typiques:
>
> https://telcobridges.com/use-cases/#CPaaSSIPTrunking
>
> ср, 29 июн. 2022 г. в 10:49, David Ponzone  >:
> Attention à un petit malentendu que je vois se pointer :)
> Dans la tête de l’OP, le SBC, c’est la machine qui lui permet de connecter
> son trunk wholesale (qu’il appelle C4) à ses trunks clients (qu’il appelle
> C5).
> Or beaucoup de SBC (commerciaux) ne font que de la
> sécurité/topology-hiding/normalisation/transcoding.
> C’est le cas de TelcoBridges.
>
> Pour Ribbon, je connais pas, mais quand je lis leur site, je le sens venir
> le passage par la case « ah pour terminer des trunks SIP client, il faut
> ajouter un autre équipement, c’est juste 150k€ en plus ».
>
> Donc je comprends la recherche d’une solution OpenSource de l'OP, parce
> que démarrer cette activité avec une solution commerciale, c’est faire un
> gros chèque pour un truc rigide, éventuellement fiable mais qui ne fera pas
> tout.
>
> Le 29 juin 2022 à 10:25, Greg  megaho...@gmail.com>> a écrit :
>
> Bonjour, dans payant Telcobridges.
>
> вт, 28 июн. 2022 г. в 19:43, Jacques MICHAU via frnog  >:
> Certes, certes. Dans les payants vraiment SBC y'a Ribbon aussi.
>
> C'est juste pour donner des noms à Mr OP.
>
> Jacques
>
> Le 28/06/2022 à 16:25, David Ponzone a écrit :
> > Je sais bien qu’avec IP, les frontières deviennent floues, mais
> Wildix/3CX ne sont absolument pas des SBC ou SoftSwitch au sens où l’OP
> l’entend.
> > Ce sont des SoftSwitch bien sûr, puisqu’ils switchent des appels VoIP en
> soft, mais avec une orientation purement iPBX/Centrex.
> >
> >
> >> Le 28 juin 2022 à 14:58, Jacques MICHAU via frnog  > a écrit :
> >>
> >> Il y a aussi wildix et 3CX qui eux-mêmes reprennent toutes ces briques
> et proposent un truc propret pour éviter de mettre le nez dans les RFC ;
> mais payant bien sûr.
> >>
> >
> > ---
> > 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] [BIZ] Contact Bouygues Ventes Indirectes (FTTH)

[Fabien H]

Ca marche merci



Le mar. 7 juin 2022 à 13:00, Mickael C.  a
écrit :

> Bonjour
>
> Thierry Kupfer
> 066-993-9372
>
>
> Dites lui que vous l'appelez de ma part, Mickael Cerqueira, flexnetwork.
>
> Bonne journée
>
> Le mar. 7 juin 2022, 12:14, Fabien H  a écrit :
>
>> Bonjour,
>>
>> je recherche un contact mail récent chez Bouygues Ventes Indirectes (porte
>> de collecte FTTH)
>>
>> Réponse en privé serait mieux je pense..
>>
>> Merci !
>> Fabien
>>
>> ---
>> Liste de diffusion du FRnOG
>> http://www.frnog.org/
>>
>

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

[FRnOG] [BIZ] Contact Bouygues Ventes Indirectes (FTTH)

[Fabien H]

Bonjour,

je recherche un contact mail récent chez Bouygues Ventes Indirectes (porte
de collecte FTTH)

Réponse en privé serait mieux je pense..

Merci !
Fabien

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

Re: [FRnOG] [TECH] Rejet d'emails par outlook.com

[Fabien H]

C'est un peu l'oeuf et la poule cette histoire :-)

Donc faut en passer progressivement en espérant pas trop de rejet lors de
la phase d'augmentation ...




Le mar. 5 avr. 2022 à 12:38, David Ponzone  a
écrit :

> Peut-être qu’ils aiment les IP qui ont une réputation positive (donc un
> historique), plutôt que celles avec une réputation à 0 (donc pas
> d’historique).
>
>
> > Le 5 avr. 2022 à 12:20, Fabien H  a écrit :
> >
> > +1 exactement le même phénomène il y'a 2 semaines, ajout d'une IP propre,
> > SPF OK, exactement la même erreur. Pas de souci avec une IP propre
> utilisée
> > depuis plusieurs années..
> >
> > Ce qui est inquiétant dans le message d'Outlook.com : ils semblent sous
> > entendre qu'une partie du réseau est dans leur blocklist .. !? Il faut
> > ésperer qu'ils ne diminuent pas la réputation de l'ensemble du bloc /24
> par
> > exemple, parce qu'en temps que FAI, ça risque de poser de gros problèmes
> ..
> >
> > Fabien
> >
>
>

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

Re: [FRnOG] [TECH] Rejet d'emails par outlook.com

[Fabien H]

+1 exactement le même phénomène il y'a 2 semaines, ajout d'une IP propre,
SPF OK, exactement la même erreur. Pas de souci avec une IP propre utilisée
depuis plusieurs années..

Ce qui est inquiétant dans le message d'Outlook.com : ils semblent sous
entendre qu'une partie du réseau est dans leur blocklist .. !? Il faut
ésperer qu'ils ne diminuent pas la réputation de l'ensemble du bloc /24 par
exemple, parce qu'en temps que FAI, ça risque de poser de gros problèmes ..

Fabien



Le mar. 5 avr. 2022 à 12:12, Artur  a écrit :

> Bonjour les gens,
>
> J'ai récemment ajouté 2 adresses IP supplémentaires pour envoyer des
> emails depuis une plateforme d'interactivité vers ses utilisateurs (pas de
> spam).
> Le spf a été mis à jour il y a une dizaine de jours.
> Lors de cette opération il y a eu 1 ou 2 emails qui ont été rejetés chez
> Office365 et Outlook probablement à cause du TTL sur le spf.
> Si côté Office365 il y a la possibilité de délister une ip en particulier
> ce qui a été fait, il ne semble pas y avoir grand chose côté outlook.com.
>
> Une dizaine de jours est passé et je vois que de nouveau outlook.com
> rejette carrément un email à destination d'une BAL sur le domaine
> hotmail.fr :
>
>  : host eur.olc.protection.outlook.com[104.47.18.161]
>  said: 550 5.7.1 Unfortunately, messages from [a.b.c.d] weren't sent.
>  Please contact your Internet service provider since part of their
> network
>  is on our block list (S3140). You can also refer your provider to
>  http://mail.live.com/mail/troubleshooting.aspx#errors.
>  [AM7EUR06FT029.eop-eur06.prod.protection.outlook.com] (in reply to
> MAIL
>  FROM command)
>
> Je précise que les deux adresses ip sortantes pour le smtp sont des ip
> failover OVH qui n'ont pas été utilisées pendant assez longtemps (1 an ou
> plus) ni pour envoi d'emails, ni pour autre chose d'ailleurs. Je peux les
> donner en privé si nécessaire.
>
> Que me conseillez-vous pour résoudre ce problème, svp ?
>
> --
> Cordialement,
> Artur
>
>
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/
>

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

Re: [FRnOG] [MISC] Logiciel d'inventaire orienté objet

[Fabien H]

Bonsoir,

merci beaucoup à tout le monde pour les réponses.

iTop, j'ai déjà essayé de le personnaliser : Je trouvais que la doc était
un peu difficile à trouver, peut-être que le support aiderait. Et ensuite,
c'est subjectif, mais je trouvais que les menus et formulaires n'étaient
pas forcément très agréables à l'utilisation mais ça c'est du détail, ça
peut se re-développer si on utilise l'API.

J'aurai vraiment aimé avoir un logiciel un peu plus souple, avec des objets
rapides à modéliser, et une IHM sympathique en glisser-déposer.. Mais je
dois réver un peu, ou alors il y'a des contraintes techniques que je ne
vois pas forcément

Fabien

Le jeu. 20 janv. 2022 à 17:21, Arnaud Gelly  a
écrit :

> +1 pour iTop.
>
>
> Le lien entre les objets se fait à l'import. Ex : 1 VM dépend d'un cluster
> qui dépend de plusieurs hyperviseurs qui dépendent chacun d'un serveur
> physique.
>
> Mais ensuite la gestion de l'analyse d'impact entre éléments est graphique
> :
>
> https://www.itophub.io/wiki/media?media=3_0_0%3Auser%3Aitop_analyse_impact_3.0.png
>
>
> C'est un peu long à modéliser mais le jeu en vaut la chandelle.
>
> Cordialement.
> --
> Arnaud
>
>
>
>
> On Thu, 20 Jan 2022 at 10:22, Dominique Rousseau 
> wrote:
>
> > Le Thu, Jan 20, 2022 at 09:53:29AM +0100, Frederic Hermann [
> > fhe-fr...@neptune.fr] a écrit:
> > > Bonjour Fabien,
> > >
> > > iTop de Combodo (https://www.itophub.io/page/about-itop) est un CMDB
> > > qui qui pourrait correspondre.
> >
> > +1
> >
> > J'utilise pas iTop, mais c'est ce à quoi j'ai tout de suite pensé en
> > lisant la question.
> >
> >
> > --
> > Dominique Rousseau
> > Neuronnexion, Prestataire Internet & Intranet
> > 6 rue des Hautes cornes - 8 Amiens
> > tel: 03 22 71 61 90 - fax: 03 22 71 61 99 - http://www.neuronnexion.coop
> >
> >
> > ---
> > 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] [MISC] Logiciel d'inventaire orienté objet

[Fabien H]

Bonjour,

J'ai mis dans Misc parce que le sujet est à cheval avec le système et qu'on
cherche un peu le mouton à 5 pattes : Nous recherchons un logiciel
d'inventaire de parc client, si possible open source, et qui soit orienté
objet : je m'explique :

L'idée serait de ne pas être limité par un schéma de base de données figé
(Serveur, routeur, Switch, ..) mais de pouvoir définir soit même ses objets
un peu comme un diagramme objet mais plus simple et plus intuitif:

On définirait nos propres objets : Client,  Site, Routeur, Switch, Serveur,
OS, Service, .. avec leur attributs.

Et chaque objet pourrait être relié avec un ou n autres librement.

On serait donc devant un tableau blanc sur lequel on irait poser les
objets, remplir les attributs en cliquant sur l'objet et tracer les liens
entre les objets à la souris

Une fois qu'un "arbre" est fait pour un ou plusieurs clients, on pourrait
rechercher très rapidement un type d'objet (Routeur(s) par exemple) ou un
attribut précis sur un type d'objet (Retrouve moi tous les routeurs avec
l'attribut marque = CISCO et l'attribut modèle = ISR ...)

Pour ceux qui connaissent, FusionInventory est un bon début, mais une vraie
usine à gaz parce que à mon avis contrainte par un schéma de base de
données..

Est-ce que ça vous parle ou alors je suis parti vraiment trop loin ?

merci :-)

Fabien

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

Re: [FRnOG] [TECH] Suggestions sur routeur VPN IPSEC

[Fabien H]

On a perdu de temps en temps quelques CISCO RV132 / RV134 en vol (et bien
sur à 150 km de distance), la conf était perdue, il a fallu la réinjecter
sur site.

Depuis on a arrêté mais peut-être que les RV340 sont plus stables..



Le ven. 8 oct. 2021 à 14:58, Niffo  a écrit :

> Le vendredi 08 octobre 2021 à 12:31 +0200, Pierre DOLIDON a écrit :
>
> > Bonjour la liste.
> > Je suis à la recherche de routeur VPN IPSEC. rien d'extraordinaire,
> > mais
> > je suis un peu perdu sur la quantité d'offre, et j'apprécierai vos
> > retours.
> > je ne suis pas fermé ni aux boitiers tout intégrés (genre cisco
> > RV340)
>
> Justement, ici c'est Cisco RV340 (moins de 200€). Ca juste marche,
> interface user friendly et tu auras même du VPN en Gigabit.
>
>
> --
> Nicolas "Niffo" GRESSARD
> N.G.C.D.I - Infogérance et hébergement
> https://www.ngcdi.fr
>
>
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/
>

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

Re: [FRnOG] [TECH] Rx max sur SFP 10G LR

[Fabien H]

Bonjour,

OK merci pour les réponses précises de tout le monde,

bonne journée,
Fabien

Le mer. 18 août 2021 à 08:33, Julien CANAT  a
écrit :

> Hello,
>
> On a des intercos courtes en monomode (dans la même baie) en 10G et 1G
> sans problèmes depuis des années, tu peux y aller sans problèmes.
>
> Comme le mentionnait quelqu'un avant moi, ça permet de réduire les
> références, de ne pas avoir de stock sur de la jarretière multi-mode,
> bref de se simplifier un peu la vie.
>
> Cordialement,
>
> Le 17/08/2021 à 17:50, ic a écrit :
> > io,
> >
> >> On 17 Aug 2021, at 17:14, Fabien H  wrote:
> >>
> >> Mais malgré tout je me demandai sur le long terme si ce n'était pas
> mauvais
> >> pour le SFP+ et si sa durée de vie n'allait pas être réduite à cause de
> ça ?
> >>
> >> Je pensais mettre un réducteur mais je ne sais pas trop ou en trouver
> et si
> >> c'est fiable ..
> > En monomode je ne crois pas qu’il y ait “moins” que du LR et c’est une
> façon assez standard de faire.
> >
> > Si jamais, tu trouves des atténuateurs sur fs.com pour pas cher mais je
> ne pense pas que ce soit nécessaire.
> >
> > ++ ic
> >
> >
> > ---
> > Liste de diffusion du FRnOG
> >
> http://antiphishing.trinaps.com/1/anVsaWVuLmNhbmF0QHRyaW5hcHMuY29tfFZSQzE3MjYxNzc%3D/www.frnog.org/
>
> --
> Julien CANAT
>
> TRINAPS - Ingénierie Réseau
>
> Ingénieur réseau
>
> julien.ca...@trinaps.com
>
> (+33)3 39 03 40 59
> (+33)6 13 68 27 45
> Techn'hom 3 - 11 rue Sophie Germain 9 Belfort
>
> www.trinaps.com
>
>
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/
>

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

[FRnOG] [TECH] Rx max sur SFP 10G LR

[Fabien H]

Bonjour,
nous avons plusieurs fournisseurs qui indiquent dans leur STAS qu'il faut
un module 10G de type SFP-10G-LR ou SFP-10G-LR-S pour s'interconnecter à
eux donc maximum 10 km de distance, mais dans les faits, ils mettent un
boitier qui est directement dans notre baie et on se retrouve avec des
niveaux Rx sur le SFP+ LR à -2,4 ou -2,6 dBm

C'est dans la plage préconisée par CISCO entre 0.5 et -14.4 dBm :

https://www.cisco.com/c/en/us/products/collateral/interfaces-modules/transceiver-modules/data_sheet_c78-455693.html

Mais malgré tout je me demandai sur le long terme si ce n'était pas mauvais
pour le SFP+ et si sa durée de vie n'allait pas être réduite à cause de ça ?

Je pensais mettre un réducteur mais je ne sais pas trop ou en trouver et si
c'est fiable ..

Merci,
Fabien

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

Re: [FRnOG] [MISC] Liste de diffusion simple clients

[Fabien H]

Merci pour les retours,

PHPList installé très simplement en 15 min et 1er test fait, interface web
relativement conviviale et jolie (pour les collègues ça compte..)

c'est simple et ça marche bien !

Fabien

Le mar. 1 juin 2021 à 11:42, Gabriel  a écrit :

>
> Hello Fabien,
>
> On utilise mlmmj ( http://mlmmj.org/ ), pour debian: apt show mlmmj
>
> Il est très "simple et efficace".
>
> Je coche...
> - [x] paquet Linux Debian
> - [x] Installation simple
> - [x] Alimentation des membres dans l'outil en injectant régulièrement un
> fichier texte
>
> Ca ne correspond pas forcement a tous tes critères, mais je te laisse voir!
>
> Amicalement,
>
> Gabriel
>

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

Re: [FRnOG] [MISC] Liste de diffusion simple clients

[Fabien H]

Super c'est tout à fait le type de soft que je cherche et l'interface web a
l'air conviviale

merci !

Fabien



Le mar. 1 juin 2021 à 11:26, Hugues Voiturier  a
écrit :

> Hello,
>
> Chez nous on utilise PHPList qui semble cocher tous tes critères.
>
>
> Hugues Voiturier
> Consultant en architecture réseau
> AS57199
>
> > On 1 Jun 2021, at 11:14, Fabien H  wrote:
> >
> > Bonjour,
> >
> > nous recherchons pour communiquer sur nos avis de maintenance ou
> incidents
> > un logiciel de liste de diffusion simple sous Linux :
> >
> > - paquet Linux Debian/ubuntu ou Centos
> > - Installation simple (pas très fan de Sympa par exemple..)
> > - Alimentation des membres (= nos clients) dans l'outil en injectant
> > régulièrement un fichier texte ou eventuellement en base de données MySQL
> > - envoi des mails en Bcc et gestion assez correcte des entêtes mail pour
> ne
> > pas que les mails arrivent trop en spam (on suppose que SPF et DKIM sont
> OK)
> > -  Gestion des mails TXT et HTML (même si on sait que le HTML n'est pas
> > recommandé)
> >
> > Merci,
> > Fabien
> >
> > ---
> > 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] [MISC] Liste de diffusion simple clients

[Fabien H]

OK oui OK à réflechir, il vaut mieux envoyer un mail /personne toutes les X
secondes

Le mar. 1 juin 2021 à 11:19, Romain  a écrit :

> Pour permettre l’opt-out en un clic, mettre tout le monde en bcc est une
> mauvaise pratique.
>
> > Le 1 juin 2021 à 11:16, Fabien H  a écrit :
> >
> > Bonjour,
> >
> > nous recherchons pour communiquer sur nos avis de maintenance ou
> incidents
> > un logiciel de liste de diffusion simple sous Linux :
> >
> > - paquet Linux Debian/ubuntu ou Centos
> > - Installation simple (pas très fan de Sympa par exemple..)
> > - Alimentation des membres (= nos clients) dans l'outil en injectant
> > régulièrement un fichier texte ou eventuellement en base de données MySQL
> > - envoi des mails en Bcc et gestion assez correcte des entêtes mail pour
> ne
> > pas que les mails arrivent trop en spam (on suppose que SPF et DKIM sont
> OK)
> > -  Gestion des mails TXT et HTML (même si on sait que le HTML n'est pas
> > recommandé)
> >
> > Merci,
> > Fabien
> >
> > ---
> > Liste de diffusion du FRnOG
> > http://www.frnog.org/
>

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

[FRnOG] [MISC] Liste de diffusion simple clients

[Fabien H]

Bonjour,

nous recherchons pour communiquer sur nos avis de maintenance ou incidents
un logiciel de liste de diffusion simple sous Linux :

- paquet Linux Debian/ubuntu ou Centos
- Installation simple (pas très fan de Sympa par exemple..)
- Alimentation des membres (= nos clients) dans l'outil en injectant
régulièrement un fichier texte ou eventuellement en base de données MySQL
- envoi des mails en Bcc et gestion assez correcte des entêtes mail pour ne
pas que les mails arrivent trop en spam (on suppose que SPF et DKIM sont OK)
-  Gestion des mails TXT et HTML (même si on sait que le HTML n'est pas
recommandé)

Merci,
Fabien

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

Re: [FRnOG] [ALERT] Soucis sur FranceIX + AWS ?

[Fabien H]

Bonjour,
La matinée va être longue je sens ..

Chez nous, sur 2 transitaires différents, des pertes de paquet en traversée
de Zayo et atteindre certaines destinations par exemple e.ext.nic.fr

Problème localisé chez Zayo ?

Fabien


Le mer. 26 mai 2021 à 07:29, Arnaud Willem  a écrit :

> Salut Gaetan, tous,
>
> Pareil ici, je vois la même chose via un transit Zayo (qui passe par
> FranceIX), et depuis $home (Orange), ça bute sur le peering
> Opentransit-Amazon.
>
>
>
>
>
> Arnaud Willem
>
> > On 26 May 2021, at 07:23, Gaetan Allart  wrote:
> >
> > Bonjour,
> >
> > Depuis une 30aine de minutes, on a des soucis pour joindre
> > destinations AWS à travers le FranceIX.
> >
> > $ curl 52.31.18.229
> >
> > $ curl 52.17.135.24
> >
> > $ curl 34.252.189.25
> >
> >
> > $ traceroute 52.31.18.229
> > traceroute to 52.31.18.229 (52.31.18.229), 30 hops max, 60 byte packets
> > 1  185.46.228.253 (185.46.228.253)  1.086 ms  1.174 ms  1.301 ms
> > 2  be1.2004.er01.lil01.ip-max.net (46.20.247.110)  50.845 ms  50.893
> > ms  50.985 ms
> > 3  * * te0-1-0-1.er02.par02.ip-max.net (46.20.254.203)  50.800 ms
> > 4  te0-0-2-0.er01.lyo01.ip-max.net (46.20.254.132)  51.046 ms  50.827
> > ms  50.776 ms
> > 5  rtr-interixp-l2-v500.rezopole.net (77.95.71.252)  51.817 ms  52.108
> ms *
> > 6  amazon-th2.par.franceix.net (37.49.236.118)  14.323 ms  18.071 ms
> 18.016 ms
> > 7  * * *
> > 8  * * *
> > 9  * * *
> > 10  * * *
> > 11  * * *
> > 12  * * *
> > 13  * * *
> > 14  * * *
> > 15  * * *
> > 16  * * *
> > 17  * * *
> > 18  * * *
> >
> > Quelqu'un observe la même chose ?
> >
> > Merci,
> > Bonne journée,
> >
> > --
> >
> > Gaëtan Allart
> > Nexylan
> >
> >
> > ---
> > 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] Broadband Access Aggregation and DSL Configuration

[Fabien H]

Il y'a effectivement de la fragmentation sur le CPE sur le trafic montant.
C'est un fonctionnement habituel. Normalement ton CPE est dimensionné
selon le débit de ton lien, donc le CPU devrait suivre même avec un peu de
fragmentation.

Sachant que la plupart du temps c'est le trafic descendant qui a le débit
le plus élevé sur un lien donc le CPE ne subit pas de fragmentation dans le
sens descendant (le LNS oui mais il est surement dimensionné)



Le mar. 11 mai 2021 à 10:13, Kevin Thiou  a écrit :

> Pour changer toujours dans le dépatouillage :)
>
> J'ai des comportements étranges.
>
> Avec les valeurs MTU 1460 et tcp mss 1420, la grande majorité des liens
> semblent fonctionner.
>
> Pour certains j'ai des problèmes de débit.
>
> Je me pose la question de la puissance du CPE, car dans beaucoup de cas il
> y a un RB2011.
> Je ne demande pas une solution mais juste une validation de ma réflexion.
>
> La station cliente (windows souvent) à une MTU à 1500, l'interface LAN
> client sur le CPE a une MTU de 1500.
> La session pppoe se retrouve avec une MTU à 1460. L'interface de
> terminaison sur le cisco est aussi à 1460.
>
> Me trompè-je si je pense qu'une grosse partie de la fragmentation a lieu
> sur le CPE ?
> Et par conséquent si le CPE est un peu juste niveau CPU le débit s'écroule.
>
> Merci de vos lumières
>
>
> Le mar. 4 mai 2021 à 23:21, Kevin Thiou  a écrit :
>
>> Je me posais justement la question des calculs théoriques.
>>
>> j'ai trouvé ca comme article :
>>
>>
>> https://www.gigabit-wireless.com/gigabit-wireless/actual-maximum-throughput-gigabit-ethernet/
>>
>>
>> Le mar. 4 mai 2021 à 23:10, David Ponzone  a
>> écrit :
>>
>>> J’ai pas osé te le suggérer :)
>>> Le 2011, il commence à dater.
>>> CHR dans une VM c’est pas mal pour les tests de BW.
>>>
>>> Je pense pas qu’ un MTU/MSS un peu réduit puisse générer une perte
>>> significative de bande passante (pas 70% en tout cas).
>>> Il y a des spécialistes en Maths Appliquées aux Problèmes de MTU sur la
>>> liste, je suis sûr qu’ils vont venir m'égorger si j’ai tort, tu as juste à
>>> attendre.
>>>
>>>
>>> Le 4 mai 2021 à 23:04, Kevin Thiou  a écrit :
>>>
>>> Merde le mikrotik qui me permet de faire mes tests est un RB2011 et il
>>> galère à envoyer plus ...
>>>
>>> Donc avec un serveur de test public mikrotik on atteint des valeurs bien
>>> meilleurs.
>>>
>>> Le mar. 4 mai 2021 à 23:01, Kevin Thiou  a écrit :
>>>
 j'ai le même modèle.

 Je vais essayer de comparer à d'autres collectes qui ont le même CPE et
 faire des tests croisés.

 Le mar. 4 mai 2021 à 22:53, David Ponzone  a
 écrit :

> Sur un hAPac2, je suis à 470Mbps en TCP sur un FTTH collecté en
> PPP/L2TP (c’est le CPU du MK qui limite à 470 à priori).
> Avec MTU 1460 et MSS 1420 sur mon Virtual-Template.
>
> Donc je pense que ton problème est ailleurs.
> Ou alors tu te méfies pas assez du CPU de ton MK.
> Le test UDP prend moins de CPU que TCP, donc si ton MK est moins
> puissant que mon hAPac2, c’est peut-être lui qui te limite en TCP (en tout
> cas, qui limite le bandwidth-test).
>
> > Le 4 mai 2021 à 22:39, Kevin Thiou  a écrit :
> >
> > Je ne vais pas rentrer dans le c'est la faute à truc.
> > Pour le moment, celui qui m'occupe ne commence pas par un S.
> >
> > Si je met la conf ip mtu 1460 et tcp adjust-mss 1420, j'ai une vrai
> perte de débit en tcp par rapport à l'udp par exemple.
> >
> > J'utilise l'outil de test de mikrotik qui donne des résultat que je
> trouve acceptable.
> > En udp je monte a 420Mbps alors que je plafonne à 125Mbps en tcp.
> >
> > Donc en plus de ne pas suivre les STAS, les clients n'ont pas la BP
> annoncée.
> >
>
>
>>>

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

Re: [FRnOG] [TECH] Broadband Access Aggregation and DSL Configuration

[Fabien H]

Ou alors autre solution tu mets le MTU / TCP MSS qui t'arrange sur le VT
global.

Et sur tes ADSL/VDSL, tu peux faire envoyer par ton radius les attributs IP
forcés :

mtu 1460
ip tcp adjust-mss 1420



Le mar. 4 mai 2021 à 22:49, Fabien H  a écrit :

> Sinon utilise des VT différents avec des MTU différents selon les
> interfaces de collecte ? La collecte ADSL/VDSL est livrée à part ?
>
> Le mar. 4 mai 2021 à 22:39, Kevin Thiou  a écrit :
>
>> Je ne vais pas rentrer dans le c'est la faute à truc.
>> Pour le moment, celui qui m'occupe ne commence pas par un S.
>>
>> Si je met la conf ip mtu 1460 et tcp adjust-mss 1420, j'ai une vrai perte
>> de débit en tcp par rapport à l'udp par exemple.
>>
>> J'utilise l'outil de test de mikrotik qui donne des résultat que je
>> trouve acceptable.
>> En udp je monte a 420Mbps alors que je plafonne à 125Mbps en tcp.
>>
>> Donc en plus de ne pas suivre les STAS, les clients n'ont pas la BP
>> annoncée.
>>
>> Le mar. 4 mai 2021 à 22:33, David Ponzone  a
>> écrit :
>>
>>> Ah c’est pas un problème opérationnel mais juste un fournisseur qui veut
>>> un ping clean à 2000 ?
>>> C’est qui ce casse-pieds ? C’est un acronyme à 3 lettres qui commence
>>> par S et finit par R ?
>>> Ah mais tu avais tout dit en Janvier: SFR REFLEX (c’est so 1980 comme
>>> nom…)
>>>
>>> Tu as donc un Arista entre le Cisco et SFR ?
>>> Si tu mets temporairement (à 3h du mat), l’IP sur l’Arista plutôt que le
>>> Cisco, le ping est ok à 2000 ?
>>> Je vois que ça comme manière de procéder.
>>>
>>> Mais surtout, surtout, n’oublie pas qu’il est tout à fait possible que
>>> SFR aient fait de la merde de leur côté.
>>>
>>> > Le 4 mai 2021 à 22:24, Kevin Thiou  a écrit :
>>> >
>>> > je l'ai fait sur certains accès.Et ça fonctionne pour certaines
>>> collectes.
>>> >
>>> > Mais certains fournisseurs veulent pouvoir faire un ping -s 2000
>>> df-bit et
>>> > que cela fonctionne.
>>> >
>>> > C'est d'ailleurs écrit dans leur STAS.
>>> >
>>> > Le mar. 4 mai 2021 à 22:17, Fabien H  a écrit
>>> :
>>> >
>>> >> Dans tu virtual-Template sur le LNS, comme indiqué précedemment, tu as
>>> >> bien mis :
>>> >>
>>> >> mtu 1460
>>> >> ip tcp adjust-mss 1420
>>> >>
>>> >> ?
>>> >> A priori c'est le seul endroit où il faut jouer sur le MTU.
>>> >>
>>> >>
>>> >> Le mar. 4 mai 2021 à 22:13, Kevin Thiou  a
>>> écrit :
>>> >>
>>> >>> Je relance le sujet.
>>> >>> Toujours en galère avec certains accès, des problèmes de MTU en veux
>>> tu en
>>> >>> voilà.
>>> >>>
>>> >>> Mon souci du moment c'est comment faire en sorte que la MTU entre le
>>> LAC
>>> >>> du
>>> >>> provider et mon LNS soit a 2000 minimum.
>>> >>> J'ai essayé de mettre :  ip mtu 2000 sur l'interface loopback qui
>>> termine
>>> >>> les tunnels L2TP mais ça n'a pas l'air de fonctionner.
>>> >>> Le ping  df-bit size 2000 ne passe pas.
>>> >>>
>>> >>> Si quelqu'un a fait marcher une conf similaire sur un asr je suis
>>> preneur.
>>> >>>
>>> >>> Merci
>>> >>>
>>> >>> Le mer. 24 mars 2021 à 22:04, Radu-Adrian Feurdean <
>>> >>> fr...@radu-adrian.feurdean.net> a écrit :
>>> >>>
>>> >>>> On Wed, Mar 24, 2021, at 15:56, Kevin Thiou wrote:
>>> >>>>> L2 et L3 sur le même port.
>>> >>>>>
>>> >>>>> Le paquet qui passe c'est 1460.
>>> >>>>
>>> >>>> ip tcp adjust-mss 1420 ?
>>> >>>>
>>> >>>> 1420 = 1460 - 40 (IP + TCP headers)
>>> >>>>
>>> >>>>
>>> >>>> ---
>>> >>>> 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] Broadband Access Aggregation and DSL Configuration

[Fabien H]

Sinon utilise des VT différents avec des MTU différents selon les
interfaces de collecte ? La collecte ADSL/VDSL est livrée à part ?

Le mar. 4 mai 2021 à 22:39, Kevin Thiou  a écrit :

> Je ne vais pas rentrer dans le c'est la faute à truc.
> Pour le moment, celui qui m'occupe ne commence pas par un S.
>
> Si je met la conf ip mtu 1460 et tcp adjust-mss 1420, j'ai une vrai perte
> de débit en tcp par rapport à l'udp par exemple.
>
> J'utilise l'outil de test de mikrotik qui donne des résultat que je trouve
> acceptable.
> En udp je monte a 420Mbps alors que je plafonne à 125Mbps en tcp.
>
> Donc en plus de ne pas suivre les STAS, les clients n'ont pas la BP
> annoncée.
>
> Le mar. 4 mai 2021 à 22:33, David Ponzone  a
> écrit :
>
>> Ah c’est pas un problème opérationnel mais juste un fournisseur qui veut
>> un ping clean à 2000 ?
>> C’est qui ce casse-pieds ? C’est un acronyme à 3 lettres qui commence par
>> S et finit par R ?
>> Ah mais tu avais tout dit en Janvier: SFR REFLEX (c’est so 1980 comme
>> nom…)
>>
>> Tu as donc un Arista entre le Cisco et SFR ?
>> Si tu mets temporairement (à 3h du mat), l’IP sur l’Arista plutôt que le
>> Cisco, le ping est ok à 2000 ?
>> Je vois que ça comme manière de procéder.
>>
>> Mais surtout, surtout, n’oublie pas qu’il est tout à fait possible que
>> SFR aient fait de la merde de leur côté.
>>
>> > Le 4 mai 2021 à 22:24, Kevin Thiou  a écrit :
>> >
>> > je l'ai fait sur certains accès.Et ça fonctionne pour certaines
>> collectes.
>> >
>> > Mais certains fournisseurs veulent pouvoir faire un ping -s 2000 df-bit
>> et
>> > que cela fonctionne.
>> >
>> > C'est d'ailleurs écrit dans leur STAS.
>> >
>> > Le mar. 4 mai 2021 à 22:17, Fabien H  a écrit :
>> >
>> >> Dans tu virtual-Template sur le LNS, comme indiqué précedemment, tu as
>> >> bien mis :
>> >>
>> >> mtu 1460
>> >> ip tcp adjust-mss 1420
>> >>
>> >> ?
>> >> A priori c'est le seul endroit où il faut jouer sur le MTU.
>> >>
>> >>
>> >> Le mar. 4 mai 2021 à 22:13, Kevin Thiou  a
>> écrit :
>> >>
>> >>> Je relance le sujet.
>> >>> Toujours en galère avec certains accès, des problèmes de MTU en veux
>> tu en
>> >>> voilà.
>> >>>
>> >>> Mon souci du moment c'est comment faire en sorte que la MTU entre le
>> LAC
>> >>> du
>> >>> provider et mon LNS soit a 2000 minimum.
>> >>> J'ai essayé de mettre :  ip mtu 2000 sur l'interface loopback qui
>> termine
>> >>> les tunnels L2TP mais ça n'a pas l'air de fonctionner.
>> >>> Le ping  df-bit size 2000 ne passe pas.
>> >>>
>> >>> Si quelqu'un a fait marcher une conf similaire sur un asr je suis
>> preneur.
>> >>>
>> >>> Merci
>> >>>
>> >>> Le mer. 24 mars 2021 à 22:04, Radu-Adrian Feurdean <
>> >>> fr...@radu-adrian.feurdean.net> a écrit :
>> >>>
>> >>>> On Wed, Mar 24, 2021, at 15:56, Kevin Thiou wrote:
>> >>>>> L2 et L3 sur le même port.
>> >>>>>
>> >>>>> Le paquet qui passe c'est 1460.
>> >>>>
>> >>>> ip tcp adjust-mss 1420 ?
>> >>>>
>> >>>> 1420 = 1460 - 40 (IP + TCP headers)
>> >>>>
>> >>>>
>> >>>> ---
>> >>>> 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] Broadband Access Aggregation and DSL Configuration

[Fabien H]

Dans tu virtual-Template sur le LNS, comme indiqué précedemment, tu as bien
mis :

 mtu 1460
 ip tcp adjust-mss 1420

?
A priori c'est le seul endroit où il faut jouer sur le MTU.


Le mar. 4 mai 2021 à 22:13, Kevin Thiou  a écrit :

> Je relance le sujet.
> Toujours en galère avec certains accès, des problèmes de MTU en veux tu en
> voilà.
>
> Mon souci du moment c'est comment faire en sorte que la MTU entre le LAC du
> provider et mon LNS soit a 2000 minimum.
> J'ai essayé de mettre :  ip mtu 2000 sur l'interface loopback qui termine
> les tunnels L2TP mais ça n'a pas l'air de fonctionner.
> Le ping  df-bit size 2000 ne passe pas.
>
> Si quelqu'un a fait marcher une conf similaire sur un asr je suis preneur.
>
> Merci
>
> Le mer. 24 mars 2021 à 22:04, Radu-Adrian Feurdean <
> fr...@radu-adrian.feurdean.net> a écrit :
>
> > On Wed, Mar 24, 2021, at 15:56, Kevin Thiou wrote:
> > > L2 et L3 sur le même port.
> > >
> > > Le paquet qui passe c'est 1460.
> >
> > ip tcp adjust-mss 1420 ?
> >
> > 1420 = 1460 - 40 (IP + TCP headers)
> >
> >
> > ---
> > 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] Subnet ip publique sur LAN

[Fabien H]

Solution propre : changer le LAN pour respecter la RFC
Solution sale : Sur le routeur qui sert de passerelle LAN, faire des routes
statiques avec masque plus précis que le masque du LAN et envoyer vers la
Gateway Internet

Le mar. 16 mars 2021 à 11:22, Stephane EVEILLARD <
stephane.eveill...@outlook.fr> a écrit :

> Bonjour
>
> C’est un phénomène plus fréquent qu’on ne pense
> Comment se connecte-t-il à Internet pour le moment ?
>
>
> Cordialement / Best Regards
>
> Stéphane EVEILLARD
>
>
>
>
>
> De : frnog-requ...@frnog.org  De la part de
> Richard MATOS
> Envoyé : mardi 16 mars 2021 11:16
> À : frnog-tech 
> Objet : [FRnOG] [TECH] Subnet ip publique sur LAN
>
> Salut la liste,
>
> J'ai un client qui utilise un plage d'adresse ip publique sur son LAN,
> est-ce que certains parmi vous ont rencontré ce cas de figure ?
> Si oui quelle solution avez-vous implémenté?
>
> Merci
>
>
> --
> Richard MATOS
>
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/
>

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

Re: [FRnOG] [TECH] Ping / traceroute vers Orange depuis ce matin 10H

[Fabien H]

OK merci pour les retours.

Après de nombreux tests : J'ai l'impression que c'est un phénomène local
(box ou ADSL là bas) car d'autres IP sur le même plan sont OK : Ex:
193.253.55.100

Je n'avais pas vu à ma connaissance ce genre de phénomène (latence sur
traceroute différente de latence sur ping ..) . j'ai essayé avec plusieurs
tailles de paquets, pas mieux.

Du coup désolé pour le bruit



Le ven. 12 mars 2021 à 13:59, Oliver varenne  a
écrit :

> J'ai le meme phénomène depuis chez moi (ip free)
>
>
>
>
>
> Cordialement,
>
>
>
> Olivier Varenne
> Co-gérant, Commercial & Développeur
> T +33 (0)4 27 04 40 00 | ipconnect.fr
>
> Suivez-nous !
>
>
>
> > -Message d'origine-----
> > De : frnog-requ...@frnog.org  De la part de
> > Fabien H
> > Envoyé : vendredi 12 mars 2021 13:27
> > À : frnog-tech 
> > Objet : [FRnOG] [TECH] Ping / traceroute vers Orange depuis ce matin 10H
> >
> > Bonjour,
> >
> > Depuis 2 IP de 2 transitaires, j'ai un ping très élevé vers plusieurs IP
> > ORANGE alors que le traceroute est normal. Nous avons également des
> > plaintes de clients sur de l'IPSEC :
> >
> > Je n'ai pas mis ALERT car j'ai un doute mais le phénomène est présent
> > depuis les 2 IP source des transitaires sur 2 localisations différentes :
> >
> > Exemple IP Orange : 193.253.55.213
> >
> > - Ping de 250-300ms, IPSEC à 250ms
> >
> >
> >
> > Sending 5, 100-byte ICMP Echos to 193.253.55.213, timeout is 2
> > seconds:
> > Packet sent with a source address of X.Y.Z !
> > Success rate is 100 percent (5/5), round-trip min/avg/max =
> > 257/316/377 ms
> >
> > - Traceroute à 27ms
> >
> >   2 be2471.ccr41.par01.atlas.cogentco.com (130.117.49.37) [AS 174] 8
> > msec 8 msec 7 msec
> >   3 be3183.ccr31.par04.atlas.cogentco.com (154.54.38.66) [AS 174] 8
> > msec
> > be3626.rcr21.par05.atlas.cogentco.com (130.117.1.46) [AS 174] 8
> > msec 8 msec
> >   4  *
> > francetelecom.par04.atlas.cogentco.com (130.117.15.58) [AS 174] 8
> > msec *
> >   5 hundredgige0-9-0-32.auvtr5.aubervilliers.opentransit.net
> > (193.251.151.52) [AS 5511] 8 msec *
> > ae0-0.niidf201.rbci.orange.net (81.253.184.181) [AS 31167] 8 msec
> >   6 ae0-0.niidf201.rbci.orange.net (81.253.184.181) [AS 31167] 8 msec *
> > *
> >   7  *  *  *
> >   8  *  *  *
> >   9  *  *  *
> >  10  *  *  *
> >  11  *
> > lputeaux-656-1-141-213.w193-253.abo.wanadoo.fr (193.253.55.213)
> > [AS 3215] 26 msec 32 msec
> >  12 lputeaux-656-1-141-213.w193-253.abo.wanadoo.fr (193.253.55.213)
> > [AS 3215] 27 msec *  31 msec
> >
> > Vous avez la même chose ?
> >
> > Merci
> >
> > Fabien
> >
> > ---
> > 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] Ping / traceroute vers Orange depuis ce matin 10H

[Fabien H]

Bonjour,

Depuis 2 IP de 2 transitaires, j'ai un ping très élevé vers plusieurs IP
ORANGE alors que le traceroute est normal. Nous avons également des
plaintes de clients sur de l'IPSEC :

Je n'ai pas mis ALERT car j'ai un doute mais le phénomène est présent
depuis les 2 IP source des transitaires sur 2 localisations différentes :

Exemple IP Orange : 193.253.55.213

- Ping de 250-300ms, IPSEC à 250ms



Sending 5, 100-byte ICMP Echos to 193.253.55.213, timeout is 2 seconds:
Packet sent with a source address of X.Y.Z
!
Success rate is 100 percent (5/5), round-trip min/avg/max = 257/316/377 ms

- Traceroute à 27ms

  2 be2471.ccr41.par01.atlas.cogentco.com (130.117.49.37) [AS 174] 8 msec 8
msec 7 msec
  3 be3183.ccr31.par04.atlas.cogentco.com (154.54.38.66) [AS 174] 8 msec
be3626.rcr21.par05.atlas.cogentco.com (130.117.1.46) [AS 174] 8 msec 8
msec
  4  *
francetelecom.par04.atlas.cogentco.com (130.117.15.58) [AS 174] 8 msec *
  5 hundredgige0-9-0-32.auvtr5.aubervilliers.opentransit.net
(193.251.151.52) [AS 5511] 8 msec *
ae0-0.niidf201.rbci.orange.net (81.253.184.181) [AS 31167] 8 msec
  6 ae0-0.niidf201.rbci.orange.net (81.253.184.181) [AS 31167] 8 msec *  *
  7  *  *  *
  8  *  *  *
  9  *  *  *
 10  *  *  *
 11  *
lputeaux-656-1-141-213.w193-253.abo.wanadoo.fr (193.253.55.213) [AS
3215] 26 msec 32 msec
 12 lputeaux-656-1-141-213.w193-253.abo.wanadoo.fr (193.253.55.213) [AS
3215] 27 msec *  31 msec

Vous avez la même chose ?

Merci

Fabien

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

Re: [FRnOG] [TECH] Supervision latence et traceroute tout en un

[Fabien H]

Exact.

Sans interface web : Pour les variations de chemin, nous utilisons un
script qui lance un traceroute régulièrement, et si un changement de saut
est detectée, alors ça nous envoie un mail avec le avant / après. Certains
sauts étant dynamiques vers certaines IP (plusieurs routes en alternance),
on les exclut de la vérification..



Le ven. 12 mars 2021 à 08:15, Sébastien 65  a écrit :

> Bonjour Fabien,
>
> A ma connaissance, il n'y a pas d'interface web pour MTR permettant de
> consulter l'historisation des résultats ?
>
> J'ai besoin par exemple de pouvoir revenir en arrière sur une période
> donnée afin de voir la latence (vérif si dégradation ou pas) ainsi que de
> pouvoir croiser avec le chemin emprunté.
>
>
> ------
> *De :* Fabien H 
> *Envoyé :* vendredi 12 mars 2021 08:11
> *À :* Sébastien 65 
> *Cc :* frnog-t...@frnog.org 
> *Objet :* Re: [FRnOG] [TECH] Supervision latence et traceroute tout en un
>
> Bonjour Sebastien,
>
> mtr sous linux !
>
> Ou éventuellement WinMTR sous Windows
>
> Le ven. 12 mars 2021 à 08:08, Sébastien 65  a
> écrit :
>
> Bonjour à tous,
>
> Existe-t-il un outil avec une interface web permettant de visualiser la
> latence et le chemin emprunté pour joindre une destination ?
>
> Je cherche une interface capable de me donner la variation sur la latence
> ainsi que le changement de chemin.
>
> J'utilise SmokePing mais je n'ai pas l'historique du chemin utilisé (style
> traceroute).
>
> Une idée d'un produit si possible open-source ?
>
> Bonne journée !
>
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/
> <https://emea01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.frnog.org%2F=04%7C01%7C%7C637b87bf2bf743dab07008d8e52616d6%7C84df9e7fe9f640afb435%7C1%7C0%7C637511299033607239%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000=K0vnb9mMu4U33R%2BqsDp4gGDLGHG91EVXBuaSyWNdOhc%3D=0>
>
>

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

Re: [FRnOG] [TECH] Supervision latence et traceroute tout en un

[Fabien H]

Bonjour Sebastien,

mtr sous linux !

Ou éventuellement WinMTR sous Windows

Le ven. 12 mars 2021 à 08:08, Sébastien 65  a écrit :

> Bonjour à tous,
>
> Existe-t-il un outil avec une interface web permettant de visualiser la
> latence et le chemin emprunté pour joindre une destination ?
>
> Je cherche une interface capable de me donner la variation sur la latence
> ainsi que le changement de chemin.
>
> J'utilise SmokePing mais je n'ai pas l'historique du chemin utilisé (style
> traceroute).
>
> Une idée d'un produit si possible open-source ?
>
> Bonne journée !
>
> ---
> 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

[Fabien H]

Oui j'ai vu après désolé.. Allez vendu !

Merci pour vos retours

Fabien

Le jeu. 4 mars 2021 à 10:59, David Ponzone  a
écrit :

> Fabien,
>
> Réglable par dipswitch, fallait juste cliquer sur le lien et descendre un
> peu :)
>
> Pour l’autotoneg, ça semble rudimentaire: 1000 forcé (autoneg off) ou négo
> 100/1000 (autoneg on), et ça semble concerné que le côté fibre.
> Je suppose qu’il est en autoneg forcé côté Cuivre, mais c’est plus trop un
> problème de nos jours.
>
> Les docs FS….. mais 24€ quoi.
>
> > Le 4 mars 2021 à 10:45, Fabien H  a écrit :
> >
> > Merci pour vos réponses rassurantes.
> >
> > Je suppose que la gestion de la négo côté fibre est paramétrable ? De
> > mémoire par exemple jouer sur le nonegotiate / speed / duplex
> >
> > Si le port fibre tombe, je suppose que le port cuivre tombe aussi ?
>
>

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

Re: [FRnOG] [TECH] Convertisseur Fibre 1G LC - Cuivre en DC

[Fabien H]

Merci pour vos réponses rassurantes.

Je suppose que la gestion de la négo côté fibre est paramétrable ? De
mémoire par exemple jouer sur le nonegotiate / speed / duplex

Si le port fibre tombe, je suppose que le port cuivre tombe aussi ?

Le jeu. 4 mars 2021 à 09:55, Damien DUJARDIN  a
écrit :

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

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

[FRnOG] [TECH] Convertisseur Fibre 1G LC - Cuivre en DC

[Fabien H]

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] [MISC] Notre meilleur argument pour vendre du FTTO

[Fabien H]

> Le problème est le suivant, selon moi: client pas up, sous traitant pas
> facturé.
> ++
>
>
L'idée est bonne mais si c'est pour débrancher l'abonné d'à côté parce
qu'il n'y a plus de capacité, ça n'est pas satisfaisant ! Et pour détecter
ce genre de pratiques, le seul moyen est que l'abonné débranché ce plaigne..

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

[FRnOG] [TECH] SIP OWF : Appels vers numéros M2M à 14 chiffres

[Fabien H]

Bonjour,

Savez vous si nativement les trunks SIP fournis en interco voix par OWF
permettent d'appeler les numéros M2M à 14 chiffres de la forme 07... ?

Merci,
Fabien

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

Re: [FRnOG] [TECH] Codecs VoIP sur OVH

[Fabien H]

Oui ! Enfin mettre un serveur SIP derrière du NAT quand on a la main sur
l'hébergement, c'est quand même chercher un peu les problèmes dès le début
:-)

Le sam. 5 déc. 2020 à 11:51, David Ponzone  a
écrit :

> > Le 5 déc. 2020 à 11:19, Fabien H  a écrit :
> > Alors je défends un peu le concept parce qu'on en déploie quand même pas
> > mal,  il n'y a pas de port à ouvrir, et la plupart du temps, on ne
> vérifie
>
> Si tu veux que le serveur SIP soit derrière du NAT, si.
> Et si serveur et client sont derrière du NAT, c’est quand même une sacré
> merde, et ça fait du support.
>
>
>

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

Re: [FRnOG] [TECH] Codecs VoIP sur OVH

[Fabien H]

> Justement, sur le routeur il faut désactiver ALG ET ouvrir un million de
> ports ET tester, ET appeler le tech-support au Maghreb (ici c'est à
> Bangalore), et recommencer, etc etc. Avec un protocole moderne, on n'a pas
> à se faire chier pour que çà marche. Le simple fait qu'il y ait une option
> "nat=yes" est un indicateur que c'est de la daube. Pour http, il n'y a pas
> de cas spécial qui emmerde tout le monde à traverser NAT.
>
>
Alors je défends un peu le concept parce qu'on en déploie quand même pas
mal,  il n'y a pas de port à ouvrir, et la plupart du temps, on ne vérifie
pas le SIP ALG et ça fonctionne. Tu poses juste un téléphone sur le LAN du
client qui va s'enregistrer sur l'Asterisk quelque part sur Internet, et ça
marche. Je suis d'accord que c'est moche d'avoir à développer un logiciel
qui contourne un problème d'implémentation du NAT mais dans les faits, ça
marche très bien nous concernant.. En attendant de trouver mieux, on fait
avec ça

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

Re: [FRnOG] [TECH] Codecs VoIP sur OVH

[Fabien H]

> Le 04/12/2020 à 19:04, Michel Py a écrit :
> >> Oliver varenne a écrit :
> >> Tu trouves que c'est la négo de codec du SIP qui est pourrie ?
> >> Moi je trouve que c'est le SIP tout court! Un truc incapable
> >> de passer du NAT en natif à une époque où TOUT est natté...
> > +1, hélas.
> >
>
>
Vous êtes dur avec SIP. OK le NAT n'est pas natif au protocole, mais
l'option nat=yes sur un compte SIP sur Asterisk par exemple fonctionne
bien, NAT ou pas (SIP ALG à désactiver sur le routeur internet bien sur)

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

Re: [FRnOG] [TECH] CISCO REP vs LACP

[Fabien H]

>
> > Par exemple est-ce que la redondance de FW (ASA ou autre) est possible
> sans un L2 ?
>
> Exemple parfait de ce que les vieux comme moi considèrent fondamentalement
> défectueux. Je suppose que tu veux le même VLAN / subnet des deux cotés,
> possiblement avec VRRP / HSRP et un heartbeat et un lien entre les deux
> pour synchroniser l'état (stateful firewall) entre les deux; c'est un
> paratonnerre à emmerdes : le jour ou ton lien tombe, tu te retrouves avec
> deux cotés qui deviennent actifs en même temps et autres joyeusetés qui
> prennent des lustres à consolider quand çà remonte.
>
>
Certes. (Bon sur un ASA, quand le L2 remonte, c'est pas trop grave, ça se
passe assez bien).

Mais du coup ça veut dire qu'on abandonne les archis redondantes de FW ou
autres ? Ou alors il faut le faire en L3 ?

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

Re: [FRnOG] [TECH] CISCO REP vs LACP

[Fabien H]

Pourquoi pas mais est-ce que un PCA/PRA peut le faire sans L2 ?
Par exemple est-ce que la redondance de FW (ASA ou autre) est possible sans
un L2 ?


Le sam. 21 nov. 2020 à 15:29, Radu-Adrian Feurdean <
fr...@radu-adrian.feurdean.net> a écrit :

> On Fri, Nov 20, 2020, at 14:36, Fabien H wrote:
> > Bonjour,
> >
> > On aimerait remplacer le LACP sur nos 2 liens L2 interDC de type wave par
> > CISCO REP (Resilient Ethernet Protocol).
>
> Vendredi c'est passe, mais j'essaye quand-meme:
>
> Si au lieu de continuer avec le concept (que je suis pas le seul a
> considerer comme fondamentalement defectueux) du niveau 2 etendu entre
> l'ensemble des sites, tu commences a migrer vers une archi au niveau 3
> (IP), ou un certain nombre de problemes classiques du niveau 2 n'existent
> plus ? Comme ca un lien inter-DC c'est juste un point-a-point, et tu peux
> ajouter autant que tu veux.
>
>
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/
>

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

Re: [FRnOG] [TECH] CISCO REP vs LACP

[Fabien H]

D'après Cisco entre 50 et 200ms. Il y'a un heartbeat en broadcast sur un
VLAN réservé REP :

https://www.cisco.com/c/en/us/td/docs/switches/lan/cisco_ie4010/software/release/15-2_4_EC/configuration/guide/scg-ie4010_5000/swrep.html#pgfId-1015270



Le ven. 20 nov. 2020 à 23:41, Michel Py 
a écrit :

> > Fabien H a écrit :
> > REP avant tout pour le délai de convergence : <100ms vs 1s pour le LACP
> en fast convergence et 30s en slow
>
> Cà converge à quelle vitesse quand le lien est physiquement "up" mais
> qu'aucun trafic ne passe ?
> Le test de convergence en débranchant le câble, c'est un peu facile. Il y
> a des paquets REP toutes les 100ms ?
>
> Michel.
>
>

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

Re: [FRnOG] [TECH] CISCO REP vs LACP

[Fabien H]

Romain,
Merci pour ce retour précis, avec une conf en bonus !

Michel, REP avant tout pour le délai de convergence : <100ms vs 1s pour le
LACP en fast convergence et 30s en slow

Et le fait que j'ai un lien de backup avec un débit different du nominal.



Le ven. 20 nov. 2020 à 23:08, Michel Py 
a écrit :

> > Fabien H a écrit :
> > On aimerait remplacer le LACP sur nos 2 liens L2 interDC de type wave
> par CISCO REP (Resilient Ethernet Protocol).
>
> Par curiosité, pourquoi ? LACP çà marche pourtant bien.
>
> Michel.
>
>

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

[FRnOG] [TECH] CISCO REP vs LACP

[Fabien H]

Bonjour,

On aimerait remplacer le LACP sur nos 2 liens L2 interDC de type wave par
CISCO REP (Resilient Ethernet Protocol).

https://gblogs.cisco.com/fr/reseaux/rep-resilient-ethernet-protocol-maintenant-sur-switchs-compacts/

Les tests faits en maquette en branchant 2 SW entre eux sur 2 liens sont
assez concluants : temps de convergence très court (<100ms),le débit et le
support des liens (Cuivre, SFP) peuvent être différents.

Le seul point négatif mais pas forcément c'est que le balancing entre le
lien nominal et le backup est choisi à la conception manuellement et par
VLAN.

Est-ce que certains d'entre vous l'utilisent en production ? RAS ?

Merci
Fabien

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

Re: [FRnOG] Re: [MISC] DSAV Project: sérieux ou scam ?

[Fabien H]

En fait ils envoient une requête DNS concernant un domaine dont ils
détiennent le NS. Ils regardent pour voir si la requête DNS arrive bien
jusqu'au NS du domaine.

Le mar. 13 oct. 2020 à 11:49, Paul Rolland (ポール・ロラン) 
a écrit :

> Bonjour,
>
> On Tue, 13 Oct 2020 10:40:22 +0200
> Stephane Bortzmeyer  wrote:
>
> > On Tue, Oct 13, 2020 at 10:34:44AM +0200,
> >  David Ponzone  wrote
> >  a message of 10 lines which said:
> >
> > > J’ai reçu un mail de DSAV Project (venant d'un labo d’une université
> > > US dans l’Utah), qui me semble surprenant.
> > > D’autres ont reçu un mail de leur part affirmant avoir détecté une
> > > faille n’existant à priori pas ?
> >
> > Ici aussi. Je me bats avec Scapy pour essayer de vérifier leurs
> > affirmations.
>
> C'est quelle partie de l'affirmation que tu cherches a verifier ?
> Moi, je lis : "... indicating that our spoofed queries successfully
> penetrated the network", et c'est cette partie-la qui m'intrigue...
>
> Sachant que la source a ete spoofee, peu de chance qu'ils puissent utiliser
> les reponses pour verifier que la query a bien penetree... et donc, c'est
> quoi la methode de detection ? L'absence d'ICMP "admin filtered" ?
>
> Paul
>
>
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/
>

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

Re: [FRnOG] [MISC] DSAV Project: sérieux ou scam ?

[Fabien H]

Bonjour David,

Idem.

C'est possible que la faille existe chez nous sur les serveurs indiqués,
car on ne filtre pas les paquets provenant d'Internet avec en IP source une
de nos IP (je sais c'est mal mais c'est pas anodin comme filtrage)



Le mar. 13 oct. 2020 à 10:35, David Ponzone  a
écrit :

> J’ai reçu un mail de DSAV Project (venant d'un labo d’une université US
> dans l’Utah), qui me semble surprenant.
> D’autres ont reçu un mail de leur part affirmant avoir détecté une faille
> n’existant à priori pas ?
> Je vais les contacter pour avoir la méthode et la trace.
>
>
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/
>

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

[FRnOG] [TECH] Contact téléphonique Peering OVH

[Fabien H]

Bonjour,

nous avons été obligé de fermer notre session BGP en interco directe OVH
sur FranceIX en fin de matinée, et depuis nous n'avons plus de connectivité
sur une partie d'OVH. Différents tests faits sans résultat..

J'ai essayé le mail de peeringDB et le numéro de téléphone mais pas de
réponse.

Est-ce que si quelqu'un de OVH passe par là il peut me contacter merci !

Cordialement,
Fabien

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

Re: [FRnOG] [MISC] Saisi de l'ARCEP ?

[Fabien H]

Bonjour,

Idem !! Quand le lien va bien, pas de problème, mais dès qu'il tombe en
panne ... On a 2 liens > 3 semaines de ticket et ce n'est pas résolu !

Et le client qui me dit qu'il reçoit des offres Fibre OBS et qu'il en a
vraiment marre  !! (bien entendu je n'irai pas jusqu'à faire le lien entre
à la panne et le démarchage, je pense que c'est purement le hasard, et de
toute façon, ils démarchent très régulièrement par fax avec leurs offres
fibre)

Fabien

Le mer. 30 sept. 2020 à 14:14, Lucas Viallon  a
écrit :

> Bonjour,
>
> Je ne sais pas si c'est que pour nous, mais depuis 3 à 4 mois le support
> GAMOT d'Orange
> pour les Adsl/Vdsl, c'est vraiment invivable 
>
> Bon certe c'est du GP, mais quand même ... des coupures de 15j a plusieurs
> semaines ..
> 3 voir 4 tickets pour avoir la résolution ...
> J'ai 90% de mes tickets qui sont à >10j de résolution.
>
> Bref, on perd des clients car ils pensent qu'aller directement chez OBS le
> délais sera beaucoup plus courts.
>
> Les courriers à Orange, cela sert à rien, cela reste lettre morte.
>
> ALors je cherche a savoir si on peut notifier l'Arcep des
> dysfonctionnements qui crées une concurrence déloyale.
>
> merci pour vos conseils
> Lucas
>
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/
>

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

Re: [FRnOG] [TECH] UDP - DDOS : Solution globale possible ?

[Fabien H]

>
> Alors comment faire ?
> Une solution facile est d'embarquer ta propre pile TCP modernisée dans ton
> logiciel client qui lui va encapsuler le tout dans de l'UDP en sortie pour
> limiter l'overhead.
>
>
OK et donc QUIC en est un exemple

Du coup les fournisseurs type Netflix recherchent avec l'UDP un certaine
réactivité / diminution de la latence ? Parce qu'avec l'augmentation des
débits des liens Internet, l'overhead TCP devient moins problématique ?

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

Re: [FRnOG] Re: [TECH] UDP - DDOS : Solution globale possible ?

[Fabien H]

Aie

Par contre, ils ont refait dans HTTP/3 les mécanismes de protection
d'usurpation d'IP et de retransmission de TCP ?

Si c'est le cas, c'est un peu balot ..


Le jeu. 3 sept. 2020 à 10:16, Philippe Bourcier  a
écrit :

> Re,
>
> > @Stephane : OK pour BCP 38 effectivement !
>
> +1 pour BCP, ca fait déjà plus de 20 ans qu'on en parle... et ce n'est
> toujours pas fait partout.
>
> >> @Stephane, oui pour DNS, mais malheureusement l'imagination est sans
> >> limite pour trouver des nouveaux services d'amplification ..
>
> C'est pas pour casser tes rêves, Fabien, mais la prochaine mouture de HTTP
> (HTTP/3) risque bien
> d'être en UDP... Ce sera potentiellement le début de la fin de TCP sur
> Internet vu à quel point
> ce seul protocole est ultra-majoritaire et va continuer de l'être.
>
>
> Cordialement,
> --
> Philippe Bourcier
> web : http://sysctl.org
> blog : https://www.linkedin.com/today/author/philippebourcier
>
> 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/

[FRnOG] Re: [TECH] UDP - DDOS : Solution globale possible ?

[Fabien H]

@Stephane : OK pour BCP 38 effectivement !

Le jeu. 3 sept. 2020 à 10:04, Fabien H  a écrit :

> @Stephane, oui pour DNS, mais malheureusement l'imagination est sans
> limite pour trouver des nouveaux services d'amplification ..
>
> Le jeu. 3 sept. 2020 à 10:02, Stephane Bortzmeyer  a
> écrit :
>
>> On Thu, Sep 03, 2020 at 09:48:42AM +0200,
>>  Fabien H  wrote
>>  a message of 45 lines which said:
>>
>> > Ma question est simple et innocente : si tous les opérateurs
>> > mondiaux (et notamment les hébergeurs de serveurs VPS mais pas que)
>> > se mettaient d'accord sur des ACL (voir QoS rate limit sur certains
>> > flux UDP) bien pensées à appliquer en routeurs de bordure, peut-être
>> > pourrait on endiguer le phénomène ?
>>
>> Si, déjà, ils pouvaient appliquer BCP 38, on résoudrait une grande
>> partie du problème.
>>
>> Pour le reste, les limiteurs de trafic, outre la charge qu'ils
>> représentent pour les routeurs (car il faut un état, ce qui rend le
>> routeur vulnérable à une autre DoS), sont difficiles à régler : le
>> seuil sera trop haut pour la majorité des utilisateurs et trop bas
>> pour ceux qui font de l'UDP intensif.
>>
>> > Cela parait donc compromis. Mais n'y a t'il vraiment aucune solution
>> > technique simple et efficace si tout le monde se mettait d'accord en
>> > permettant malgré tout l'utilisation raisonnée des services UDP sur
>> > Internet ?
>>
>> L'IA ?
>>
>> > L'évolution du protocole UDP est bien entendue exclue, ça parait
>> totalement
>> > impossible.
>>
>> D'UDP oui, mais pas du DNS. DoT, DoH et le futur DoQ limitent pas
>> mal le problème.
>>
>

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

[FRnOG] Re: [TECH] UDP - DDOS : Solution globale possible ?

[Fabien H]

@Stephane, oui pour DNS, mais malheureusement l'imagination est sans limite
pour trouver des nouveaux services d'amplification ..

Le jeu. 3 sept. 2020 à 10:02, Stephane Bortzmeyer  a
écrit :

> On Thu, Sep 03, 2020 at 09:48:42AM +0200,
>  Fabien H  wrote
>  a message of 45 lines which said:
>
> > Ma question est simple et innocente : si tous les opérateurs
> > mondiaux (et notamment les hébergeurs de serveurs VPS mais pas que)
> > se mettaient d'accord sur des ACL (voir QoS rate limit sur certains
> > flux UDP) bien pensées à appliquer en routeurs de bordure, peut-être
> > pourrait on endiguer le phénomène ?
>
> Si, déjà, ils pouvaient appliquer BCP 38, on résoudrait une grande
> partie du problème.
>
> Pour le reste, les limiteurs de trafic, outre la charge qu'ils
> représentent pour les routeurs (car il faut un état, ce qui rend le
> routeur vulnérable à une autre DoS), sont difficiles à régler : le
> seuil sera trop haut pour la majorité des utilisateurs et trop bas
> pour ceux qui font de l'UDP intensif.
>
> > Cela parait donc compromis. Mais n'y a t'il vraiment aucune solution
> > technique simple et efficace si tout le monde se mettait d'accord en
> > permettant malgré tout l'utilisation raisonnée des services UDP sur
> > Internet ?
>
> L'IA ?
>
> > L'évolution du protocole UDP est bien entendue exclue, ça parait
> totalement
> > impossible.
>
> D'UDP oui, mais pas du DNS. DoT, DoH et le futur DoQ limitent pas
> mal le problème.
>

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

Re: [FRnOG] [TECH] UDP - DDOS : Solution globale possible ?

[Fabien H]

Pourquoi pas pour le VoIP mais ce n'est pas le service UDP qui m'inquiète
le plus car il est rarement utilisé pour les DDOS ( surement pour des
raisons de protocole justement ?)

Le problème ce sont tous les autres services UDP exotiques qui deviennent à
la mode pour faire les DDOS car il y'en a pas mal qui font des bonnes
amplifications. Par exemple maintenant ils utilisent des serveurs memcache
ouverts..Donc demain n'importe quelle nouvelle application qui sert en UDP
pourra servir pour l'amplification DDOS ..

@David : Oui je sais mais je tente quand même .. arriver à un accord global
de l'ensemble des acteurs de l'internet c'est surement croire au père noël.
Ou alors il faut que les GAFA imposent et tout le monde sera obligé de
suivre (exemple : durée de validité de certificat récemment)





Le jeu. 3 sept. 2020 à 09:57, Mathias  a
écrit :

> Bonjour,
>
> Le respect de la neutralité du net me semble essentielle, mais tu
> abordes de vrai problèmes.
>
> Certains services sont aujourd'hui en UDP, mais gagneraient à passer en
> TCP. Par exemple la VoIP que tu cites, la partie signalisation n'a que
> peu d'intérêt en UDP et gagnerait grandement en utilisant TCP voir même
> TLS (mais là, je rêve pour la mise en oeuvre à grande échelle).
>
> Une évolution protocolaire intéressante est SCTP, mais la mise en oeuvre
> est rare.
>
> Bonne journée
>
> Mathias
>
> Le 03/09/2020 à 09:48, Fabien H a écrit :
> > Bonjour,
> >
> > je rebondis sur le sujet précedent avec ce sujet : j'ai peur de lancer un
> > gros troll mais pour être sur que c'est techniquement impossible je
> demande
> > quand même :
> >
> > Les attaques DDOS les plus méchantes se font en UDP pour les raisons
> qu'on
> > connait : usurpation de l'IP source car pas de contrôle de sa validité
> sur
> > ce protocole + amplification sur les services ouverts sur Internet
> >
> > Ma question est simple et innocente : si tous les opérateurs mondiaux (et
> > notamment les hébergeurs de serveurs VPS mais pas que)  se mettaient
> > d'accord sur des ACL (voir QoS rate limit sur certains flux UDP)  bien
> > pensées à appliquer en routeurs de bordure, peut-être pourrait on
> endiguer
> > le phénomène ?
> >
> > Bien sur cela va à l'encontre de la neutralité du net, et l'utilisateur
> qui
> > veut utiliser des services UDP (VoIP, NTP, ..) chez un autre opérateur
> > risque de ne plus avoir accès aux services.
> >
> > Cela parait donc compromis. Mais n'y a t'il vraiment aucune solution
> > technique simple et efficace si tout le monde se mettait d'accord en
> > permettant malgré tout l'utilisation raisonnée des services UDP sur
> > Internet ?
> >
> > L'évolution du protocole UDP est bien entendue exclue, ça parait
> totalement
> > impossible.
> >
> > Si vous avez des remarques sur le sujet..
> >
> > Merci,
> > Fabien
> >
> > ---
> > 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] UDP - DDOS : Solution globale possible ?

[Fabien H]

Bonjour,

je rebondis sur le sujet précedent avec ce sujet : j'ai peur de lancer un
gros troll mais pour être sur que c'est techniquement impossible je demande
quand même :

Les attaques DDOS les plus méchantes se font en UDP pour les raisons qu'on
connait : usurpation de l'IP source car pas de contrôle de sa validité sur
ce protocole + amplification sur les services ouverts sur Internet

Ma question est simple et innocente : si tous les opérateurs mondiaux (et
notamment les hébergeurs de serveurs VPS mais pas que)  se mettaient
d'accord sur des ACL (voir QoS rate limit sur certains flux UDP)  bien
pensées à appliquer en routeurs de bordure, peut-être pourrait on endiguer
le phénomène ?

Bien sur cela va à l'encontre de la neutralité du net, et l'utilisateur qui
veut utiliser des services UDP (VoIP, NTP, ..) chez un autre opérateur
risque de ne plus avoir accès aux services.

Cela parait donc compromis. Mais n'y a t'il vraiment aucune solution
technique simple et efficace si tout le monde se mettait d'accord en
permettant malgré tout l'utilisation raisonnée des services UDP sur
Internet ?

L'évolution du protocole UDP est bien entendue exclue, ça parait totalement
impossible.

Si vous avez des remarques sur le sujet..

Merci,
Fabien

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

Re: [FRnOG] [BIZ] Editeur de VM Centrex complet & multi-tenant

[Fabien H]

Il y'a peut être incompréhension : qu'est ce que tu appelles Centrex ? Avec
ton Asterisk, comment tu fais pour proposer à tes clients un extranet
client pour gérer leur "IPBX virtuel" et leur téléphones ? Tu l'as
développé ? Il est riche ? Quid de l'application de gestion sur smartphone
(ou à minima de l'interface web responsive compatible mobile) qui est
surement gadget mais qui fait souvent mouche ..


Le jeu. 2 juil. 2020 à 17:31, Michel Py 
a écrit :

> > Olivier Lange a écrit :
> > Je rejoins certains commentaire... Il vaut mieux faire de la VM hébergée
> > et dédiée par client que de vouloir bidouiller avec du Centrex.  A mon
> avis
>
> Je plussoie. En tant que client, je me suis débarrassé de Centrex il y a 3
> ans, çà coutait un bras (plusieurs centaines de lignes) et j'ai mis un
> Asterisk fait maison hébergé en interne. Si je n'avais pas la compétence
> pour le faire je me serais quand même débarrassé de Centrex. Bon chacun a
> des cas particuliers, mais l'usine à gaz Centrex multi-tenant çà ma parait
> pas une bonne idée non plus.
>
> Michel.
>
>

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

Re: [FRnOG] [BIZ] Editeur de VM Centrex complet & multi-tenant

[Fabien H]

 L'autre critère important est l'hébergement en propre en coeur de réseau.

Ipconnect semble effectivement intéressant
Alphalink ne collera pas à mon avis si l'environnement Centrex est hébergé
chez eux et s'ils proposent tous les à côté (préfixe de portabilité
alphalink, ..)

Centile peut faire l'affaire, je vais voir les aspects commerciaux.

Cordialement

Le jeu. 2 juil. 2020 à 17:17, Olivier Lange  a écrit :

>
>
> Le jeu. 2 juil. 2020 à 11:13, Fabien H  a écrit :
>
>> Le multi-tenant sur 1 seule VM (ou 2 ou 3 max) est par contre pour moi un
>> critère important : Asterisk ou Freeswitch scalent bien en multi client,
>> c'est ce que j'utilise actuellement. Mais j'ai besoin d'enrichir l'offre.
>> Par exemple : Le modèle 3CX je le mets de côté à cause du simple tenant ,
>> pour moi il n'est pas orienté opérateur.
>>
>
> Tout dépends ta clientèle. SI tu cible du client avec 2-3-5 postes, ok,
> pourquoi pas. Si tu cible du client a 50-X postes, pour moi, tu n'aura
> jamais autant de fonction qu'une VM dédié au client (que ce soit du
> freepbx, du wildix, du 3X, de l'asterisk, ou autre).
>
> Mais en tout cas, pour avoir fait l'analyse il y a quelques temps, le vrai
> multi-tenant (donc pas le truc bidouiller sur du Xivo ou du Freepbx, qui
> est une gageur a tenir), ca n'existe pas. Et mieux vaut se rabatre sur un
> opérateur de gros qui le fait (ipconnect l'a proposé plus haut, sinon tu as
> alphalink avec Broadcloud, etc...). Après, si tu veux tout maitriser, tu
> peux tenter d'intégrer Broadcloud (je parle pas coté fonctionnalité, que je
> trouve catastrophique...) mais la, va falloir sortir un petit chèque avec
> plusieurs 0!
>
> Olivier
>

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

Re: [FRnOG] [BIZ] Editeur de VM Centrex complet & multi-tenant

[Fabien H]

Le multi-tenant sur 1 seule VM (ou 2 ou 3 max) est par contre pour moi un
critère important : Asterisk ou Freeswitch scalent bien en multi client,
c'est ce que j'utilise actuellement. Mais j'ai besoin d'enrichir l'offre.
Par exemple : Le modèle 3CX je le mets de côté à cause du simple tenant ,
pour moi il n'est pas orienté opérateur.

Le jeu. 2 juil. 2020 à 17:02, Olivier Lange  a écrit :

>   Je rejoins certains commentaire... Il vaut mieux faire de la VM hébergée
> et dédiée par client que de vouloir bidouiller avec du Centrex.  A mon avis
>
> D'autant plus que au vu de tes demandes ("fonctionnalités, provisionning
> des téléphones, extranet bien fourni pour le client (horaires, gestion
> touches, gestion annuaire partagé, gestion nouvelles touches téléphone, ..)
> " , si tu ne veux pas t'en occuper, redirige toi vers un prestataire
> Centrex en marque blanche directement, tu y gagnera du temp (moins
> d'argent). Faire du Centrex, c'est un vrai métier, et demande de
> l'implication, car les enjeu et risques sont énorme. Et finalement, c'est
> largement plus simple / rapide / efficace, de faire de la VM hébergé, avec
> la sécurité qui va bien (VPN notamment).
>
> Olivier
>
>
> Le jeu. 2 juil. 2020 à 10:51, Fabien H  a écrit :
>
>> Essentiellement pour des questions de temps pour obtenir un système bien
>> rodé à tous les niveaux : fonctionnalités, provisionning des téléphones,
>> extranet bien fourni pour le client (horaires, gestion touches, gestion
>> annuaire partagé, gestion nouvelles touches téléphone, ..)
>>
>>
>>
>> Le jeu. 2 juil. 2020 à 16:42, Sébastien Lesimple <
>> sebastien.lesim...@iguanetel.fr> a écrit :
>>
>> > Question bête mais pourquoi tu ne le fais pas toi-même?
>> > Il y a quantité de solutions open source pour ne pas dépendre d'un
>> tiers.
>> > Et encore une approche Centrex, ce n'est pas la bonne methode d'après
>> moi
>> > mais bon, chacun vois midi à sa porte.
>> > Seb
>> >
>> > Le 02/07/2020 à 15:32, Fabien H a écrit :
>> >
>> > Bonjour,
>> >
>> > Nous sommes à la recherche d'une solution de VM Centrex si possible avec
>> > les critères suivants :
>> >
>> > - architecture simple (1 ou 2 VM pour la redondance) hébergé dans notre
>> > coeur de réseau opérateur
>> > - multi-tenant
>> > - avec un extranet client complet et riche
>> > - basé sur un produit OpenSource type Asterisk ou Freeswitch
>> > - si possible fait par une PME française pour la réactivité
>> > - avec un système de prix qui ne soit pas totalement délirant
>> >
>> > Il est possible que je crois encore au père-noël, mais j'ai déjà vu
>> passer
>> > des PME qui proposent il me semble.
>> >
>> > Merci,
>> > Fabien
>> >
>> > ---
>> > Liste de diffusion du FRnOGhttp://www.frnog.org/
>> >
>> >
>> >
>>
>> ---
>> Liste de diffusion du FRnOG
>> http://www.frnog.org/
>>
>

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

Re: [FRnOG] [BIZ] Editeur de VM Centrex complet & multi-tenant

[Fabien H]

Essentiellement pour des questions de temps pour obtenir un système bien
rodé à tous les niveaux : fonctionnalités, provisionning des téléphones,
extranet bien fourni pour le client (horaires, gestion touches, gestion
annuaire partagé, gestion nouvelles touches téléphone, ..)



Le jeu. 2 juil. 2020 à 16:42, Sébastien Lesimple <
sebastien.lesim...@iguanetel.fr> a écrit :

> Question bête mais pourquoi tu ne le fais pas toi-même?
> Il y a quantité de solutions open source pour ne pas dépendre d'un tiers.
> Et encore une approche Centrex, ce n'est pas la bonne methode d'après moi
> mais bon, chacun vois midi à sa porte.
> Seb
>
> Le 02/07/2020 à 15:32, Fabien H a écrit :
>
> Bonjour,
>
> Nous sommes à la recherche d'une solution de VM Centrex si possible avec
> les critères suivants :
>
> - architecture simple (1 ou 2 VM pour la redondance) hébergé dans notre
> coeur de réseau opérateur
> - multi-tenant
> - avec un extranet client complet et riche
> - basé sur un produit OpenSource type Asterisk ou Freeswitch
> - si possible fait par une PME française pour la réactivité
> - avec un système de prix qui ne soit pas totalement délirant
>
> Il est possible que je crois encore au père-noël, mais j'ai déjà vu passer
> des PME qui proposent il me semble.
>
> Merci,
> Fabien
>
> ---
> Liste de diffusion du FRnOGhttp://www.frnog.org/
>
>
>

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

[FRnOG] [BIZ] Editeur de VM Centrex complet & multi-tenant

[Fabien H]

Bonjour,

Nous sommes à la recherche d'une solution de VM Centrex si possible avec
les critères suivants :

- architecture simple (1 ou 2 VM pour la redondance) hébergé dans notre
coeur de réseau opérateur
- multi-tenant
- avec un extranet client complet et riche
- basé sur un produit OpenSource type Asterisk ou Freeswitch
- si possible fait par une PME française pour la réactivité
- avec un système de prix qui ne soit pas totalement délirant

Il est possible que je crois encore au père-noël, mais j'ai déjà vu passer
des PME qui proposent il me semble.

Merci,
Fabien

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

Re: [FRnOG] [TECH] Policy-map output CISCO qui me rend fou !

[Fabien H]

Salut,

je me trompe peut-être mais il me semble que sur une interface L3 sur le
routeur CISCO, tu ne peux que marquer le DSCP, pas le COS qui est niveau
2.. Même si la commande set cos apparait dans la policy map..





Le sam. 16 mai 2020 à 11:38, Sébastien 65  a écrit :

> Hello,
>
> Petite prise de tête du moment avec le marquage de paquet sur un CISCO
> 891F en sortie !
>
> Je marque les paquets en COS3 pour tout le trafic sauf mon trafic VoIP qui
> est en COS5.
>
> Si je fais un ping depuis le 891F en console ou SSH vers l'IP d'interco
> (par exemple: ping 10.0.1.2 source gigabitEthernet 8.10) le paquet n'est
> pas marqué, il reste en DSCP CS0 eu lieu de CS3 !
>
> Si je fais un ping depuis un PC du LAN du 891F vers l'IP d'interco le
> paquet est bien marqué en DSCP CS3, ainsi que le reste du trafic. Je ne
> vois rien partir en CS0 lorsque le LAN fait du trafic vers le WAN !
>
> J'ai également fait un test en branchant un PC avec Wireshark sur
> l'interface GigabitEthernet8.10 pour vérifier la sortie du field DSCP !
>
> voici la conf :
> !
> policy-map LAN
>  class VOICE-IN
>   set dscp ef
>  class OTHER_TRAFFIC
>   set dscp cs3
>  class class-default
>   set cos 3
> !
> policy-map WAN-OUT
>  class VOICE
>   set cos 5
>  class OTHER_TRAFFIC
>   set cos 3
>  class class-default
>   set cos 3
> !
> interface GigabitEthernet8.10
>  encapsulation dot1Q 10
>  ip address 10.0.1.1 255.255.255.252
>  no ip redirects
>  no ip unreachables
>  no ip proxy-arp
>  ip nat outside
>  ip virtual-reassembly in
>  service-policy output WAN-OUT
> !
> interface Vlan1
>  ip address 192.168.1.254 255.255.255.0
>  no ip redirects
>  no ip unreachables
>  no ip proxy-arp
>  ip nat inside
>  ip virtual-reassembly in
>  service-policy input LAN
> !
> ip access-list extended OTHER_TRAFFIC
>  permit ip 192.168.1.0 0.0.0.255 any
>  permit ip 10.0.1.0 0.0.0.3 any
> !
>
> Pourquoi le ping depuis le CPE ne passe pas la class OTHER_TRAFFIC ou bien
> class class-default ?
>
> Merci pour l'aide 
>
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/
>

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

Re: [ALERT] RE: [FRnOG] Re: [ALERT] Coupures câbles dans le sud de Paris

[Fabien H]

Faudrait peut-être y'aller doucement sur les infos "off" des mails
précedents.. ?  désolé pour le ton moralisateur, je ne suis pas
spécialement contre la liberté d'expression, mais cette liste est indexée
sur archive et sur google.

Et même si ça parait évident pour nous qui sommes du milieu, cela ne l'est
pas forcément pour la personne lambda qui peut glaner des infos ici ou là
et avoir des idées .. Enfin je dis ça je dis rien (je n'ai pas regardé les
articles de presse, j'éspère qu'ils ont fait attention également à ne pas
être trop précis)





Le mer. 6 mai 2020 à 11:58, Théo Laban  a écrit :

> La liste des DC's étant facilement accessible et publique il est donc
> facile de voir les chambres aux alentours et de faire opérer la magie de la
> pince monseigneur.
> En france, de mon expérience, les chambres ne sont pas sécurisées et non
> monitorees et chacun fait un peu ce qu'il veut...
>
> Théo
>
> Le mer. 6 mai 2020 à 11:16, M D  a écrit :
>
> > Bonjour,
> >
> > D'après les infos que j'ai pu recouper, cette coupure est dans une
> chambre
> > qui se trouve dans les égouts. Donc facile d'accès il fallait juste
> savoir
> > ou elle était.
> >
> > Bon courage aux intervenants.
> > MD
> >
>

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

[FRnOG] [TECH] Re: CISCO - Route d'entrée dans un VRF depuis le routeur lui-même

[Fabien H]

Petite correction qui a son  importance je pense : rajouter un deny all à
la fin du prefix list !

ip prefix-list VRF_TEST_TO_GLOBAL seq 5 permit 1.2.3.4/32
ip prefix-list VRF_TEST_TO_GLOBAL seq 10 deny 0.0.0.0/0 le 32


Le sam. 4 avr. 2020 à 17:25, Fabien H  a écrit :

> Re-bonjour,
>
> une personne m'a orienté sur cette documentation :
> https://www.cisco.com/c/en/us/support/docs/ip/ip-routing/200158-Configure-Route-Leaking-between-Global-a.html
>
> Et j'ai ensuite dérivé sur la commande route-replicate que j'ai appliqué à
> la table de routage global ( global-address-family ipv4), et ça fonctionne
> parfaitement, les routes BGP du VRF TEST se retrouvent bien dans la table
> globale !
>
> Un grand merci à la communauté !
>
> Fabien
>
> global-address-family ipv4
>   route-replicate from vrf TEST unicast all route-map VRF_TEST_TO_GLOBAL
>
> ip prefix-list VRF_TEST_TO_GLOBAL seq 5 permit 1.2.3.4/32
>
> route-map VRF_TEST_TO_GLOBAL permit 10
>  match ip address prefix-list VRF_TEST_TO_GLOBAL
>
>
>
> Le sam. 4 avr. 2020 à 15:38, Fabien H  a écrit :
>
>> Correction sur la présentation de la configuration pas très claire car
>> problème de retour à la ligne.. :
>>
>> ip route vrf TEST 192.168.1.1 255.255.255.255 GigabitEthernet0/0/0.3950
>>> 192.168.1.1 global name ROUTE_SORTIE_VRF_TEST
>>>
>>
>>
>>> => Je sais que cette route de sortie fonctionne
>>>
>>
>>
>> ip route 1.2.3.4 255.255.255.255 GigabitEthernet0/0/0.3949 10.10.10.1
>>> name ROUTE_ENTREE_VRF_TEST
>>>
>>
>>
>>> => Cette route ne fonctionne pas car 10.10.10.1 est sur le même routeur
>>> que 1.2.3.4/32, cela fonctionne si 10.10.10.1 est sur un routeur
>>> distant connecté à GigabitEthernet0/0/0.3949
>>>
>>
>>
>>
>> Le sam. 4 avr. 2020 à 15:31, Fabien H  a écrit :
>>
>>> Bonjour,
>>>
>>> J'essaye de faire en sorte que 2 IP dans et hors VRF sur un même routeur
>>> se voient et se pingent.
>>>
>>> 192.168.1.1 (Hors VRF) <-> 1.2.3.4 (VRF TEST)
>>>
>>> On part du principe que 1.2.3.4 sera plus tard dynamique en BGP (et non
>>> pas en Loopback comme actuellement. Je sais que 1.2.3.4 est public :-)
>>> c'est juste pour tests )
>>>
>>> Je cherche donc un moyen de faire une route d'entrée dans le VRF TEST
>>> mais pas en indiquant directement l'interface qui Loopback3949 (IP 1.2.3.4)
>>> est destination (cette méthode marche) car demain mon IP 1.2.3.4 sera une
>>> ou plusieurs routes BGP dynamiques. Je fait donc une route d'entrée VRF via
>>> une autre interface dans le VRF TEST  GigabitEthernet0/0/0.3949 10.10.10.1
>>> (voir conf ci-dessous)
>>>
>>> Mais comme attendu, ça ne fonctionne pas car le routeur s'attend à ce
>>> que 10.10.10.1 soit une GW qui est distante, hors routeur.
>>>
>>> Avez-vous une méthode simple uniquement par route statique pour arriver
>>> à faire une route d'entrée dans un VRF sur le routeur lui-même, sans avoir
>>> besoin d'aller faire l'entrée de VRF sur un routeur distant pour revenir
>>> ensuite ?
>>>
>>> Merci,
>>> Fabien
>>>
>>>
>>> ip vrf TEST
>>>
>>>
>>> ! IN VRF TEST
>>>
>>> interface Loopback3949
>>>  description IN_VRF_LOOPBACK
>>>  ip vrf forwarding TEST
>>>  ip address 1.2.3.4 255.255.255.255
>>> end
>>>
>>> interface GigabitEthernet0/0/0.3949
>>>  description IN_VRF_GIGABIT_ETHERNET
>>>  encapsulation dot1Q 3949
>>>  ip vrf forwarding TEST
>>>  ip address 10.10.10.1 255.255.255.0
>>> end
>>>
>>> !! OUT VRF TEST
>>>
>>> interface GigabitEthernet0/0/0.3950
>>>  description OUT_VRF_GIGABIT_ETHERNET
>>>  encapsulation dot1Q 3950
>>>  ip address 192.168.1.254 255.255.255.0
>>> end
>>>
>>> ip route vrf TEST 192.168.1.1 255.255.255.255 GigabitEthernet0/0/0.3950
>>> 192.168.1.1 global name ROUTE_SORTIE_VRF_TEST => Je sais que cette route de
>>> sortie fonctionne
>>>
>>
>>
>>> ip route 1.2.3.4 255.255.255.255 GigabitEthernet0/0/0.3949 10.10.10.1
>>> name ROUTE_ENTREE_VRF_TEST => Cette route ne fonctionne pas car 10.10.10.1
>>> est sur le même routeur que 1.2.3.4/32, cela fonctionne si 10.10.10.1
>>> est sur un routeur distant connecté à GigabitEthernet0/0/0.3949
>>>
>>
>>
>

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

[FRnOG] [TECH] Re: CISCO - Route d'entrée dans un VRF depuis le routeur lui-même

[Fabien H]

Re-bonjour,

une personne m'a orienté sur cette documentation :
https://www.cisco.com/c/en/us/support/docs/ip/ip-routing/200158-Configure-Route-Leaking-between-Global-a.html

Et j'ai ensuite dérivé sur la commande route-replicate que j'ai appliqué à
la table de routage global ( global-address-family ipv4), et ça fonctionne
parfaitement, les routes BGP du VRF TEST se retrouvent bien dans la table
globale !

Un grand merci à la communauté !

Fabien

global-address-family ipv4
  route-replicate from vrf TEST unicast all route-map VRF_TEST_TO_GLOBAL

ip prefix-list VRF_TEST_TO_GLOBAL seq 5 permit 1.2.3.4/32

route-map VRF_TEST_TO_GLOBAL permit 10
 match ip address prefix-list VRF_TEST_TO_GLOBAL



Le sam. 4 avr. 2020 à 15:38, Fabien H  a écrit :

> Correction sur la présentation de la configuration pas très claire car
> problème de retour à la ligne.. :
>
> ip route vrf TEST 192.168.1.1 255.255.255.255 GigabitEthernet0/0/0.3950
>> 192.168.1.1 global name ROUTE_SORTIE_VRF_TEST
>>
>
>
>> => Je sais que cette route de sortie fonctionne
>>
>
>
> ip route 1.2.3.4 255.255.255.255 GigabitEthernet0/0/0.3949 10.10.10.1 name
>> ROUTE_ENTREE_VRF_TEST
>>
>
>
>> => Cette route ne fonctionne pas car 10.10.10.1 est sur le même routeur
>> que 1.2.3.4/32, cela fonctionne si 10.10.10.1 est sur un routeur distant
>> connecté à GigabitEthernet0/0/0.3949
>>
>
>
>
> Le sam. 4 avr. 2020 à 15:31, Fabien H  a écrit :
>
>> Bonjour,
>>
>> J'essaye de faire en sorte que 2 IP dans et hors VRF sur un même routeur
>> se voient et se pingent.
>>
>> 192.168.1.1 (Hors VRF) <-> 1.2.3.4 (VRF TEST)
>>
>> On part du principe que 1.2.3.4 sera plus tard dynamique en BGP (et non
>> pas en Loopback comme actuellement. Je sais que 1.2.3.4 est public :-)
>> c'est juste pour tests )
>>
>> Je cherche donc un moyen de faire une route d'entrée dans le VRF TEST
>> mais pas en indiquant directement l'interface qui Loopback3949 (IP 1.2.3.4)
>> est destination (cette méthode marche) car demain mon IP 1.2.3.4 sera une
>> ou plusieurs routes BGP dynamiques. Je fait donc une route d'entrée VRF via
>> une autre interface dans le VRF TEST  GigabitEthernet0/0/0.3949 10.10.10.1
>> (voir conf ci-dessous)
>>
>> Mais comme attendu, ça ne fonctionne pas car le routeur s'attend à ce que
>> 10.10.10.1 soit une GW qui est distante, hors routeur.
>>
>> Avez-vous une méthode simple uniquement par route statique pour arriver à
>> faire une route d'entrée dans un VRF sur le routeur lui-même, sans avoir
>> besoin d'aller faire l'entrée de VRF sur un routeur distant pour revenir
>> ensuite ?
>>
>> Merci,
>> Fabien
>>
>>
>> ip vrf TEST
>>
>>
>> ! IN VRF TEST
>>
>> interface Loopback3949
>>  description IN_VRF_LOOPBACK
>>  ip vrf forwarding TEST
>>  ip address 1.2.3.4 255.255.255.255
>> end
>>
>> interface GigabitEthernet0/0/0.3949
>>  description IN_VRF_GIGABIT_ETHERNET
>>  encapsulation dot1Q 3949
>>  ip vrf forwarding TEST
>>  ip address 10.10.10.1 255.255.255.0
>> end
>>
>> !! OUT VRF TEST
>>
>> interface GigabitEthernet0/0/0.3950
>>  description OUT_VRF_GIGABIT_ETHERNET
>>  encapsulation dot1Q 3950
>>  ip address 192.168.1.254 255.255.255.0
>> end
>>
>> ip route vrf TEST 192.168.1.1 255.255.255.255 GigabitEthernet0/0/0.3950
>> 192.168.1.1 global name ROUTE_SORTIE_VRF_TEST => Je sais que cette route de
>> sortie fonctionne
>>
>
>
>> ip route 1.2.3.4 255.255.255.255 GigabitEthernet0/0/0.3949 10.10.10.1
>> name ROUTE_ENTREE_VRF_TEST => Cette route ne fonctionne pas car 10.10.10.1
>> est sur le même routeur que 1.2.3.4/32, cela fonctionne si 10.10.10.1
>> est sur un routeur distant connecté à GigabitEthernet0/0/0.3949
>>
>
>

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

[FRnOG] [TECH] Re: CISCO - Route d'entrée dans un VRF depuis le routeur lui-même

[Fabien H]

Correction sur la présentation de la configuration pas très claire car
problème de retour à la ligne.. :

ip route vrf TEST 192.168.1.1 255.255.255.255 GigabitEthernet0/0/0.3950
> 192.168.1.1 global name ROUTE_SORTIE_VRF_TEST
>


> => Je sais que cette route de sortie fonctionne
>


ip route 1.2.3.4 255.255.255.255 GigabitEthernet0/0/0.3949 10.10.10.1 name
> ROUTE_ENTREE_VRF_TEST
>


> => Cette route ne fonctionne pas car 10.10.10.1 est sur le même routeur
> que 1.2.3.4/32, cela fonctionne si 10.10.10.1 est sur un routeur distant
> connecté à GigabitEthernet0/0/0.3949
>



Le sam. 4 avr. 2020 à 15:31, Fabien H  a écrit :

> Bonjour,
>
> J'essaye de faire en sorte que 2 IP dans et hors VRF sur un même routeur
> se voient et se pingent.
>
> 192.168.1.1 (Hors VRF) <-> 1.2.3.4 (VRF TEST)
>
> On part du principe que 1.2.3.4 sera plus tard dynamique en BGP (et non
> pas en Loopback comme actuellement. Je sais que 1.2.3.4 est public :-)
> c'est juste pour tests )
>
> Je cherche donc un moyen de faire une route d'entrée dans le VRF TEST mais
> pas en indiquant directement l'interface qui Loopback3949 (IP 1.2.3.4) est
> destination (cette méthode marche) car demain mon IP 1.2.3.4 sera une ou
> plusieurs routes BGP dynamiques. Je fait donc une route d'entrée VRF via
> une autre interface dans le VRF TEST  GigabitEthernet0/0/0.3949 10.10.10.1
> (voir conf ci-dessous)
>
> Mais comme attendu, ça ne fonctionne pas car le routeur s'attend à ce que
> 10.10.10.1 soit une GW qui est distante, hors routeur.
>
> Avez-vous une méthode simple uniquement par route statique pour arriver à
> faire une route d'entrée dans un VRF sur le routeur lui-même, sans avoir
> besoin d'aller faire l'entrée de VRF sur un routeur distant pour revenir
> ensuite ?
>
> Merci,
> Fabien
>
>
> ip vrf TEST
>
>
> ! IN VRF TEST
>
> interface Loopback3949
>  description IN_VRF_LOOPBACK
>  ip vrf forwarding TEST
>  ip address 1.2.3.4 255.255.255.255
> end
>
> interface GigabitEthernet0/0/0.3949
>  description IN_VRF_GIGABIT_ETHERNET
>  encapsulation dot1Q 3949
>  ip vrf forwarding TEST
>  ip address 10.10.10.1 255.255.255.0
> end
>
> !! OUT VRF TEST
>
> interface GigabitEthernet0/0/0.3950
>  description OUT_VRF_GIGABIT_ETHERNET
>  encapsulation dot1Q 3950
>  ip address 192.168.1.254 255.255.255.0
> end
>
> ip route vrf TEST 192.168.1.1 255.255.255.255 GigabitEthernet0/0/0.3950
> 192.168.1.1 global name ROUTE_SORTIE_VRF_TEST => Je sais que cette route de
> sortie fonctionne
>


> ip route 1.2.3.4 255.255.255.255 GigabitEthernet0/0/0.3949 10.10.10.1 name
> ROUTE_ENTREE_VRF_TEST => Cette route ne fonctionne pas car 10.10.10.1 est
> sur le même routeur que 1.2.3.4/32, cela fonctionne si 10.10.10.1 est sur
> un routeur distant connecté à GigabitEthernet0/0/0.3949
>

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

[FRnOG] [TECH] CISCO - Route d'entrée dans un VRF depuis le routeur lui-même

[Fabien H]

Bonjour,

J'essaye de faire en sorte que 2 IP dans et hors VRF sur un même routeur se
voient et se pingent.

192.168.1.1 (Hors VRF) <-> 1.2.3.4 (VRF TEST)

On part du principe que 1.2.3.4 sera plus tard dynamique en BGP (et non pas
en Loopback comme actuellement. Je sais que 1.2.3.4 est public :-) c'est
juste pour tests )

Je cherche donc un moyen de faire une route d'entrée dans le VRF TEST mais
pas en indiquant directement l'interface qui Loopback3949 (IP 1.2.3.4) est
destination (cette méthode marche) car demain mon IP 1.2.3.4 sera une ou
plusieurs routes BGP dynamiques. Je fait donc une route d'entrée VRF via
une autre interface dans le VRF TEST  GigabitEthernet0/0/0.3949 10.10.10.1
(voir conf ci-dessous)

Mais comme attendu, ça ne fonctionne pas car le routeur s'attend à ce que
10.10.10.1 soit une GW qui est distante, hors routeur.

Avez-vous une méthode simple uniquement par route statique pour arriver à
faire une route d'entrée dans un VRF sur le routeur lui-même, sans avoir
besoin d'aller faire l'entrée de VRF sur un routeur distant pour revenir
ensuite ?

Merci,
Fabien


ip vrf TEST


! IN VRF TEST

interface Loopback3949
 description IN_VRF_LOOPBACK
 ip vrf forwarding TEST
 ip address 1.2.3.4 255.255.255.255
end

interface GigabitEthernet0/0/0.3949
 description IN_VRF_GIGABIT_ETHERNET
 encapsulation dot1Q 3949
 ip vrf forwarding TEST
 ip address 10.10.10.1 255.255.255.0
end

!! OUT VRF TEST

interface GigabitEthernet0/0/0.3950
 description OUT_VRF_GIGABIT_ETHERNET
 encapsulation dot1Q 3950
 ip address 192.168.1.254 255.255.255.0
end

ip route vrf TEST 192.168.1.1 255.255.255.255 GigabitEthernet0/0/0.3950
192.168.1.1 global name ROUTE_SORTIE_VRF_TEST => Je sais que cette route de
sortie fonctionne
ip route 1.2.3.4 255.255.255.255 GigabitEthernet0/0/0.3949 10.10.10.1 name
ROUTE_ENTREE_VRF_TEST => Cette route ne fonctionne pas car 10.10.10.1 est
sur le même routeur que 1.2.3.4/32, cela fonctionne si 10.10.10.1 est sur
un routeur distant connecté à GigabitEthernet0/0/0.3949

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

Re: [FRnOG] [TECH] AOC ou DAC, et question existentielle sur la position idéale d'un ToR

[Fabien H]

> Pour les DAC, c'est pas la meme histoire, meme si en 10G il faut utiliser
des quantites non-negligeables pour que ca justifie les desavantages.

Quels sont les désavantages des câbles DAC par rapport à du LC ? J'aurai vu
au contraire un avantage c'est qu'on enlève la partie active (GBIC
Optique), donc moins de risque de panne ?



Le mer. 19 févr. 2020 à 14:34, Sébastien VIGNERON  a écrit :

> Bonjour,
>
> Les DAC (donc cuivre) ont l'avantage d'être généralement moins cher mais
> en effet la section du câble peut vite rentrer en jeu, surtout dans des
> armoires à forte densité en serveur.
> Récemment nous avons commencé la construction d'un petit cluster CEPH en
> 25G et j'ai trouvé que les DAC 25G ont une section de câble presque plus
> fine que nos anciens DAC 10G. Mais je me trompe peut-être.
>
> Longueur DAC 25G : 1m et 2m
> Longueur DAC 10G : 2m et 5m
>
> Je n'ai vu qu'une seule fois de l'AOC (donc fibre, je ne serais pas de jeu
> de mots sur l'autre usage bien connu de ce sigle) car généralement utilisé
> pour les liaisons >= 7 m.
>
> Ma préférence reste sur les modules optiques + fibres optiques séparées
> car tu peux commander directement les modules pour tes différents
> constructeurs au lieu de devoir recoder les modules des DAC pour que cela
> fonctionne. Et de plus, tout est dans la finesse du trait (la FO de
> quelques mm versus le câble DAC).
>
> Cordialement / Best regards,
>
> Sébastien.
>
> > Le 19 févr. 2020 à 14:18, Alexis Lameire  a
> écrit :
> >
> > Bonjour David,
> >
> > J'aime bien le MoR, c'est pas tant un soucis de longueur de câble (tu
> > peut t'en sortir avec 3M sur du 42U et donc resté en DAC). Par contre,
> > sur des baies étroite, ça te permet de répartir le nombre de câble qui
> > part en haut et en bas.
> >
> > Le gain en câble management est pas négligeable, et 2/3U ne change pas
> > vraiment la donne quand il faut racker des serveurs un peu lourd en
> > haut des baies !
> >
> > Pour les AoC j'ai l'impression que ça a été surtout conçu pour faire
> > des truc sales en inter baie !
> >
> > Le mer. 19 févr. 2020 à 12:56, David Ponzone 
> a écrit :
> >>
> >> Je découvre les câbles optiques actifs et je me demande ce que ça vaut.
> >> Si certains ont un retour d’expérience, entre autres comparativement à
> un DAC, pour de l’intra-baie…
> >>
> >> D’ailleurs, en parlant d’intra-baie, est-ce que certains préfèrent
> mettre leurs switchs ToR au milieu de la baie, pour raccourcir la longueur
> moyenne des câbles et donc n’utiliser que des câbles de quasiment la même
> longueur ?
> >>
> >> Merci
> >>
> >>
> >> ---
> >> Liste de diffusion du FRnOG
> >> http://www.frnog.org/
> >
> >
> > ---
> > Liste de diffusion du FRnOG
> > http://www.frnog.org/
>
>
>
> Cordialement / Best regards,
>
> Sébastien VIGNERON
> CRIANN,
> Ingénieur / Engineer
> Technopôle du Madrillet
> 745, avenue de l'Université
> 76800 Saint-Etienne du Rouvray - France
> tél. +33 2 32 91 42 91
> fax. +33 2 32 91 42 92
> http://www.criann.fr
> mailto:sebastien.vigne...@criann.fr
> support: supp...@criann.fr
>
>
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/
>

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

Re: [FRnOG] [TECH] RTBH : Propager une route BGP Null0 sur un routeur CISCO depuis une VM Linux

[Fabien H]

Bonjour,
pour vous faire un retour:

access-list compiled => Turbo ACL => Cela a effectivement largement allégé
le CPU (à mon avis, je suis retombé au niveau de CPU d'avant les ACL)

Lors d'un DDOS, ACL sur une interface IN est encore plus efficace qu'une
route BGP envoyée en RTBH, mais forcément la gestion des ACL est moins
souple et dynamique que du RTBH.

Merci à tous pour les informations.

Fabien


Le jeu. 9 janv. 2020 à 20:05, Michel Py 
a écrit :

> >> Vérifie si t’as pas des routes statiques vers une interface Broadcast
> (c’est le mal)
>
> +1
>
> ip route 0.0.0.0 0.0.0.0 g1/0 c'est une catastrophe.
> Il faut faire : ip route 0.0.0.0 0.0.0.0 x.x.x.x
>
> Aussi voir si t'as pas un problème de flooding / unresolved unicast, c'est
> un classique sur certains IX. Différence entre le timeout de CAM (300
> secondes) et le timeout de ARP (4 heures) et dans une situation asymétrique
> on se retrouve avec des centaines de mégabits qui ne te sont pas destinés.
> Sur un 7301 çà m'étonnerait que çà touche le CPU, ceci dit.
>
> Tans que t'y es : sur l'ACL entrante, deny de tout ce qui n'est pas tes
> préfixes dans l'adresse de destination. C'est plus propre.
>
> > Bcp de unsupported et de redirect aussi
>
> Moi j'ai 0 dans les redirect. Les Unsupp'ted çà fait longtemps que j'ai
> abandonné.
>
> T'as quoi dans BGP using  total bytes of memory ?
> (sh ip bgp summary)
>
> Et dans sh mem (le début) ?
>
> Michel.
>
>
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/
>

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

Re: [FRnOG] [TECH] RTBH : Propager une route BGP Null0 sur un routeur CISCO depuis une VM Linux

[Fabien H]

> La moitié de ton problème c'est que le 7301 est limité à 1GO de mémoire,
> même si çà rentre encore, 1GO c'est pas suffisant aujourd'hui pour faire du
> full-feed.
>
>
>
>
Surtout quand il y' a 2 full feed :-)

Sinon sh ip arp  => Pas d'incomplete

statiques vers Interfaces de broadcast : à priori non

 sh cef not-cef-switched  => semble bon ( beaucoup de unsupported ?)

IPv4 CEF Packets passed on to next switching layer
Slot  No_adj No_encap Unsupp'ted Redirect  Receive  Options   Access
Frag
RP 0   0  2029794728 55438199 941978023  1043853 1962
 11048

Merci

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

Re: [FRnOG] [TECH] RTBH : Propager une route BGP Null0 sur un routeur CISCO depuis une VM Linux

[Fabien H]

On le remplacement est prévu .. prochainement :-)

Oui c'est normalement OK pour l'IP CEF j'ai re-vérifié

Merci pour les conseils ..

Le jeu. 9 janv. 2020 à 18:02, David Ponzone  a
écrit :

> H un 7301 en 2020 ? :)
>
> Tu peux casser ta tirelire et passer sur un ASR d’occase please ? T’en a
> pour 1000-1500€ et t’es peinard pour un moment.
>
> CPU élevé, qui ne semble pas venir d’un process en particulier, si mes
> souverains sont bons, ça signifie qu’il y a beaucoup d’interrupt.
> Pas grand chose à faire.
> Je suppose que CEF est bien activé partout ?
> 12.4(24)T1, c’est pas tout jeune non plus, y a pas un upgrade que tu peux
> faire ?
> (Et perso, j’ai jamais été fan des versions T sur un routeur core, sauf
> exception)
>
> > Le 9 janv. 2020 à 17:44, Fabien H  a écrit :
> >
> > On s'éloigne un peu du sujet là .. on va peut être arreter là ? :-)
> >
> > La nuit ça descend à 40% environ.
> >
> > Le CISCO est : Cisco IOS Software, 7301 Software
> (C7301-ADVIPSERVICESK9-M),
> > Version 12.4(24)T1,
> >
> > Voici sh proc cpu sorted quand très peu de trafic  :
> >
> > CPU utilization for five seconds: 48%/29%; one minute: 39%; five minutes:
> > 39%
> > PID Runtime(ms) Invoked  uSecs   5Sec   1Min   5Min TTY Process
> >   5  184144078492973711  19806 13.83%  3.30%  2.39%   0 Check
> heaps
> >  19  1503589012  3790327737  0  2.00%  1.94%  1.92%   0 ARP Input
> >  41   92475484875177219  12300  1.35%  1.34%  1.35%   0
> Per-Second
> > Jobs
> >  5017633504 1563995  11274  0.31%  0.03%  0.00%   0
> Per-minute
> > Jobs
> > 139 7214400  3940881273  0  0.31%  0.31%  0.31%   0 HQF
> Shaper
> > Backg
> >  81   433478028  2143248657202  0.31%  0.29%  0.30%   0 IP Input
> >  3775907128 9515323   7977  0.23%  0.12%  0.11%   0 Net
> > Background
> > 1072836212887526851324  0.15%  0.20%  0.21%   0 CEF: IPv4
> > proces
> > 187  2169791288   436003744   4976  0.07%  0.71%  0.98%   0 BGP
> Router
> > 162   202814048   358970281564  0.07%  0.11%  0.12%   0 BGP I/O
> > 274 176 483364  0.07%  0.01%  0.00%   3 Virtual
> > Exec
> >  78 494392040813941121  0.07%  0.00%  0.00%   0 ADJ
> > resolve proc
> >  4820483456  700584 18  0.07%  0.03%  0.04%   0 Net Input
> > 11211092668   692332804 16  0.07%  0.07%  0.07%   0 TCP Timer
> >  14   0   1  0  0.00%  0.00%  0.00%   0 IPC Seat
> > Manager
> >  13   9819655914386  1  0.00%  0.00%  0.00%   0 IPC
> > Deferred Por
> >  12  12069655914409  2  0.00%  0.00%  0.00%   0 IPC
> > Periodic Tim
> >  11   0   1  0  0.00%  0.00%  0.00%   0 IPC Zone
> > Manager
> >
> >
> > Le jeu. 9 janv. 2020 à 17:21, Michel Py <
> mic...@arneill-py.sacramento.ca.us>
> > a écrit :
> >
> >>> Paul Rolland a écrit :
> >>> Ton CPU est a 70% d'usage ??? Je sais pas ce que c'est comme modele et
> >> de quand il date,
> >>
> >> C'est un AGS ? ;-)
> >>
> >> J'ai du full-feed sur une bouse antique (c3825), et mon CPU est à 4%. Si
> >> un full-feed tombe (je fais clear ip BGP x.x.x.x pour simuler) pendant
> >> quelques secondes j'ai 80% mais dès que la session est remontée le CPU
> >> redescends.
> >>
> >> Fabien, t'est sur que c'est le control-plane BGP qui bouffe le CPU ? çà
> >> descend pendant la nuit quand il y a moins de trafic ?
> >>
> >> Michel.
> >>
> >>
> >> ---
> >> 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] RTBH : Propager une route BGP Null0 sur un routeur CISCO depuis une VM Linux

[Fabien H]

On s'éloigne un peu du sujet là .. on va peut être arreter là ? :-)

La nuit ça descend à 40% environ.

Le CISCO est : Cisco IOS Software, 7301 Software (C7301-ADVIPSERVICESK9-M),
Version 12.4(24)T1,

Voici sh proc cpu sorted quand très peu de trafic  :

CPU utilization for five seconds: 48%/29%; one minute: 39%; five minutes:
39%
 PID Runtime(ms) Invoked  uSecs   5Sec   1Min   5Min TTY Process
   5  184144078492973711  19806 13.83%  3.30%  2.39%   0 Check heaps
  19  1503589012  3790327737  0  2.00%  1.94%  1.92%   0 ARP Input
  41   92475484875177219  12300  1.35%  1.34%  1.35%   0 Per-Second
Jobs
  5017633504 1563995  11274  0.31%  0.03%  0.00%   0 Per-minute
Jobs
 139 7214400  3940881273  0  0.31%  0.31%  0.31%   0 HQF Shaper
Backg
  81   433478028  2143248657202  0.31%  0.29%  0.30%   0 IP Input
  3775907128 9515323   7977  0.23%  0.12%  0.11%   0 Net
Background
 1072836212887526851324  0.15%  0.20%  0.21%   0 CEF: IPv4
proces
 187  2169791288   436003744   4976  0.07%  0.71%  0.98%   0 BGP Router
 162   202814048   358970281564  0.07%  0.11%  0.12%   0 BGP I/O
 274 176 483364  0.07%  0.01%  0.00%   3 Virtual
Exec
  78 494392040813941121  0.07%  0.00%  0.00%   0 ADJ
resolve proc
  4820483456  700584 18  0.07%  0.03%  0.04%   0 Net Input
 11211092668   692332804 16  0.07%  0.07%  0.07%   0 TCP Timer
  14   0   1  0  0.00%  0.00%  0.00%   0 IPC Seat
Manager
  13   9819655914386  1  0.00%  0.00%  0.00%   0 IPC
Deferred Por
  12  12069655914409  2  0.00%  0.00%  0.00%   0 IPC
Periodic Tim
  11   0   1  0  0.00%  0.00%  0.00%   0 IPC Zone
Manager


Le jeu. 9 janv. 2020 à 17:21, Michel Py 
a écrit :

> > Paul Rolland a écrit :
> > Ton CPU est a 70% d'usage ??? Je sais pas ce que c'est comme modele et
> de quand il date,
>
> C'est un AGS ? ;-)
>
> J'ai du full-feed sur une bouse antique (c3825), et mon CPU est à 4%. Si
> un full-feed tombe (je fais clear ip BGP x.x.x.x pour simuler) pendant
> quelques secondes j'ai 80% mais dès que la session est remontée le CPU
> redescends.
>
> Fabien, t'est sur que c'est le control-plane BGP qui bouffe le CPU ? çà
> descend pendant la nuit quand il y a moins de trafic ?
>
> Michel.
>
>
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/
>

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

Re: [FRnOG] [TECH] RTBH : Propager une route BGP Null0 sur un routeur CISCO depuis une VM Linux

[Fabien H]

Non, il ne l'a pas !

Je vais appliquer en soirée pour voir merci.

Mais nos routeurs sont un peu chargés d'habitude environ 60-65% à cause des
sessions BGP..



Le jeu. 9 janv. 2020 à 12:48, Paul Rolland (ポール・ロラン) 
a écrit :

> Hello,
>
> On Thu, 9 Jan 2020 12:41:39 +0100
> Fabien H  wrote:
>
> > J'ai appliqué l'ACL suivante sur plusieurs interfaces (transitaires +
> GIX)
> > du routeur CISCO :
> >
> > ip access-list extended INTERNET_TRANSIT_IN
> >   deny  udp any eq ntp host A.B.C.D
> >   permit ip any any
> >
> > Pour un trafic équivalent à hier, le CPU a pris un bon 5% mais ça reste
> > tout à fait correct, je suis à 70% environ
>
> Ton CPU est a 70% d'usage ???
> Je sais pas ce que c'est comme modele et de quand il date, mais regarde si
> ton IOS a la commande :
>
> access-list compiled
>
> et assure-toi que c'est applique.
>
> Paul
>
>
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/
>

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

Re: [FRnOG] [TECH] RTBH : Propager une route BGP Null0 sur un routeur CISCO depuis une VM Linux

[Fabien H]

Juste pour faire un retour sur les perfs :

J'ai appliqué l'ACL suivante sur plusieurs interfaces (transitaires + GIX)
du routeur CISCO :

ip access-list extended INTERNET_TRANSIT_IN
  deny  udp any eq ntp host A.B.C.D
  permit ip any any

Pour un trafic équivalent à hier, le CPU a pris un bon 5% mais ça reste
tout à fait correct, je suis à 70% environ






Le mer. 8 janv. 2020 à 13:08, David Ponzone  a
écrit :

> Ben ouais quand même, faut bien filtrer des petits trucs :)
> Sur un Cisco, c’est pas géré par le CPU normalement, depuis quelques
> années maintenant.
>
> > Le 8 janv. 2020 à 12:47, Fabien H  a écrit :
> >
> > Bonne remarque !
> >
> > Pendant l'attaque, je n'ai pas eu l'idée de regarder, j'ai préférer
> > vérifier le RTBH. Je ferais la prochaine fois..
> >
> > La question est juste de savoir si c'est une pratique qui se fait
> > régulièrement sur un routeur de bordure de mettre une ACL extended sur
> les
> > interfaces des transitaires ou alors si c'est pas conseillé..
> >
> > Merci
> >
> > Le mer. 8 janv. 2020 à 12:35, David Ponzone  a
> > écrit :
> >
> >> Ca donne quoi un sh proc c ?
> >>
> >>> Le 8 janv. 2020 à 12:27, Fabien H  a écrit :
> >>>
> >>> Bonjour,
> >>> bonne année à la communauté FRNOG :-)
> >>>
> >>> Je suis toujours sur mes histoires de DDOS : Le RTBH fonctionne, mais
> je
> >>> trouve que mes routeurs de bordure montent un peu trop en CPU à mon
> gout
> >>> (encore pas mal de pertes de paquets sur les paquets traversant).
> >>>
> >>> Je voulais juste savoir sur du CISCO, s'il est judicieux de mettre un
> ACL
> >>> IN (étendue) sur les interfaces des transitaires du style :
> >>>
> >>> deny udp port source 123 ip dest A.B.C.D
> >>> permit any any
> >>>
> >>> Est-ce que c'est mieux d'un point de vue performance et mitigation vu
> que
> >>> le paquet est droppé en entrée par rapport à une route Null 0 ? Ou
> alors
> >> à
> >>> l'inverse l'ACL va entrainer une surcharge CPU qui va le faire
> >> s'effondrer ?
> >>>
> >>> Merci,
> >>>
> >>> Fabien
> >>>
> >>>
> >>>
> >>>
> >>> Le mar. 24 déc. 2019 à 07:41, Michel Py <
> >> mic...@arneill-py.sacramento.ca.us>
> >>> a écrit :
> >>>
> >>>>>>> Alarig Le Lay a écrit :
> >>>>>>> Dans ce cas je préfère faire du flowspec, je trouve ça plus propre.
> >>>>
> >>>>>> Moi aussi, mais à part le problème d'avoir le matos récent qui le
> >> fait,
> >>>> va donc trouver un transitaire qui ferait
> >>>>>> çà en amont pour toi :-(  Déjà en trouver qui connaissent quelque
> >>>> choses aux communautés c'est pas évident.
> >>>>
> >>>>> Yannis Aribaud a écrit :
> >>>>> Hurricane Electric propose le support de flowspec en option sur leurs
> >>>> offres de transit. Mais ça coûte une blinde !
> >>>>
> >>>> C'est bon à savoir que quelqu'un le propose, mais malheureusement
> c'est
> >> le
> >>>> genre de chose qui ne vaut le coup de déployer que si tout le monde ou
> >>>> presque le propose. C'est lamentable, mais çà ne vaut pas la peine de
> >> payer
> >>>> si on a 4 ou 5 transits et que HE est le seul à proposer l'option :-(
> >>>> Intellectuellement, HE a mon support.
> >>>>
> >>>> Malheureusement, flowspec c'est quelque chose que j'aimerais bien
> >>>> implémenter mais que je n'ai pas le pognon de le faire.
> >>>> Encore une fois : ROI = zéro.
> >>>> En plus, avec les vendeurs qui demandent une license extra pour le
> >> faire...
> >>>> Bientôt, il faudra avoir une license pour aller pisser quand on
> >> configure
> >>>> un routeur.
> >>>>
> >>>> Michel.
> >>>>
> >>>>
> >>>> ---
> >>>> 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] RTBH : Propager une route BGP Null0 sur un routeur CISCO depuis une VM Linux

[Fabien H]

OK mais pour vous ce quoi le mieux ? Transitaire avec Arbor ou transitaire
avec RTBH et tu gères tes annonces /32 en interne ?

J'aurai tendance à dire Arbor parce que c'est quand même reconnu et je
suppose que la mitigation est très rapide et efficace dans la plupart des
cas ..

Le mer. 8 janv. 2020 à 19:10, Michel Py 
a écrit :

> > David Ponzone a écrit :
> > Sauf que maintenant le transitaire Tier2 un peu gros va essayer de te
> fourguer
> > du Arbor, et n’a donc aucun intérêt à avoir du RTBH à la papa/maman :)
>
> C'est clair, et justement quand tu es en phase de renouvellement du
> contrat tu leur dis que tu réduis le commit et le prix parce qu'ils n'ont
> pas ce que tu veux. Si tu as le choix, un transitaire çà se remplace, et
> c'est toujours bon de leur expliquer que les cimetières sont remplis de
> gens indispensables.
>
> Michel.
>
>

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

Re: [FRnOG] [TECH] RTBH : Propager une route BGP Null0 sur un routeur CISCO depuis une VM Linux

[Fabien H]

J'ai essayé avec le transitaire, mais sans donner son nom (ça va être
facile à trouver :-) ) , il propose un serveur blackhole sur lequel on
ouvre une session BGP et je n'arrive pas  jusqu'à maintenant à ouvrir cette
session (Problème de MD5..)

Je vais me re-concentrer dessus..


Le mer. 8 janv. 2020 à 17:13, Michel Py 
a écrit :

> > David Ponzone a écrit :
> > Ben déjà les IP RFC1918 et assimilées.
>
> David m'a enlevé les mots de la bouche !
>
> Fabien, il faut que tu travailles avec tes transitaires pour que le RTBH
> soit fait chez eux. Il y en a certains qui acceptent des préfixes /32 avec
> la bonne communauté et qui bloquent en amont.  C'est dans le besoin qu'on
> reconnait ses amis, un transitaire qui ne comprend pas le besoin de fournir
> ce genre de service en standard faut lui expliquer qu'il ferait mieux de se
> remuer le c.
>
> Michel.
>
>

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

Re: [FRnOG] [TECH] RTBH : Propager une route BGP Null0 sur un routeur CISCO depuis une VM Linux

[Fabien H]

OK merci pour ce 2eme retour.

Sans forcément donner toutes les ficelles : Je pensais qu'en tant
qu'opérateur, on fournissait un internet sans filtrage particulier, j'ai du
mal à imaginer ce qu'on peut filtrer en IN et OUT sans aller à l'encontre
de l'internet ouvert ?

C'est peut-être en lien avec les activités illégales type DDOS justement ?
Difficile avec des ACL simples permit/deny de filtrer je trouve..



Le mer. 8 janv. 2020 à 16:54, Michel Py 
a écrit :

> > Fabien H a écrit :
> > La question est juste de savoir si c'est une pratique qui se fait
> > régulièrement sur un routeur de bordure de mettre une ACL extended
> > sur les interfaces des transitaires ou alors si c'est pas conseillé..
>
> Pour moi c'est systématique. In et out. Avec un routeur pas trop pourri
> c'est géré par le hard, donc normalement une ACL sur une interface ne
> devrait pas tuer le CPU. Après comme disait David, sh proc cpu.
>
> Michel.
>
>

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

Re: [FRnOG] [TECH] RTBH : Propager une route BGP Null0 sur un routeur CISCO depuis une VM Linux

[Fabien H]

Ouf ça me rassure.

Donc je vais préparer l'ACL extended et l'appliquer en soirée pour voir..



Le mer. 8 janv. 2020 à 13:08, David Ponzone  a
écrit :

> Ben ouais quand même, faut bien filtrer des petits trucs :)
> Sur un Cisco, c’est pas géré par le CPU normalement, depuis quelques
> années maintenant.
>
> > Le 8 janv. 2020 à 12:47, Fabien H  a écrit :
> >
> > Bonne remarque !
> >
> > Pendant l'attaque, je n'ai pas eu l'idée de regarder, j'ai préférer
> > vérifier le RTBH. Je ferais la prochaine fois..
> >
> > La question est juste de savoir si c'est une pratique qui se fait
> > régulièrement sur un routeur de bordure de mettre une ACL extended sur
> les
> > interfaces des transitaires ou alors si c'est pas conseillé..
> >
> > Merci
> >
> > Le mer. 8 janv. 2020 à 12:35, David Ponzone  a
> > écrit :
> >
> >> Ca donne quoi un sh proc c ?
> >>
> >>> Le 8 janv. 2020 à 12:27, Fabien H  a écrit :
> >>>
> >>> Bonjour,
> >>> bonne année à la communauté FRNOG :-)
> >>>
> >>> Je suis toujours sur mes histoires de DDOS : Le RTBH fonctionne, mais
> je
> >>> trouve que mes routeurs de bordure montent un peu trop en CPU à mon
> gout
> >>> (encore pas mal de pertes de paquets sur les paquets traversant).
> >>>
> >>> Je voulais juste savoir sur du CISCO, s'il est judicieux de mettre un
> ACL
> >>> IN (étendue) sur les interfaces des transitaires du style :
> >>>
> >>> deny udp port source 123 ip dest A.B.C.D
> >>> permit any any
> >>>
> >>> Est-ce que c'est mieux d'un point de vue performance et mitigation vu
> que
> >>> le paquet est droppé en entrée par rapport à une route Null 0 ? Ou
> alors
> >> à
> >>> l'inverse l'ACL va entrainer une surcharge CPU qui va le faire
> >> s'effondrer ?
> >>>
> >>> Merci,
> >>>
> >>> Fabien
> >>>
> >>>
> >>>
> >>>
> >>> Le mar. 24 déc. 2019 à 07:41, Michel Py <
> >> mic...@arneill-py.sacramento.ca.us>
> >>> a écrit :
> >>>
> >>>>>>> Alarig Le Lay a écrit :
> >>>>>>> Dans ce cas je préfère faire du flowspec, je trouve ça plus propre.
> >>>>
> >>>>>> Moi aussi, mais à part le problème d'avoir le matos récent qui le
> >> fait,
> >>>> va donc trouver un transitaire qui ferait
> >>>>>> çà en amont pour toi :-(  Déjà en trouver qui connaissent quelque
> >>>> choses aux communautés c'est pas évident.
> >>>>
> >>>>> Yannis Aribaud a écrit :
> >>>>> Hurricane Electric propose le support de flowspec en option sur leurs
> >>>> offres de transit. Mais ça coûte une blinde !
> >>>>
> >>>> C'est bon à savoir que quelqu'un le propose, mais malheureusement
> c'est
> >> le
> >>>> genre de chose qui ne vaut le coup de déployer que si tout le monde ou
> >>>> presque le propose. C'est lamentable, mais çà ne vaut pas la peine de
> >> payer
> >>>> si on a 4 ou 5 transits et que HE est le seul à proposer l'option :-(
> >>>> Intellectuellement, HE a mon support.
> >>>>
> >>>> Malheureusement, flowspec c'est quelque chose que j'aimerais bien
> >>>> implémenter mais que je n'ai pas le pognon de le faire.
> >>>> Encore une fois : ROI = zéro.
> >>>> En plus, avec les vendeurs qui demandent une license extra pour le
> >> faire...
> >>>> Bientôt, il faudra avoir une license pour aller pisser quand on
> >> configure
> >>>> un routeur.
> >>>>
> >>>> Michel.
> >>>>
> >>>>
> >>>> ---
> >>>> 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] RTBH : Propager une route BGP Null0 sur un routeur CISCO depuis une VM Linux

[Fabien H]

Bonne remarque !

Pendant l'attaque, je n'ai pas eu l'idée de regarder, j'ai préférer
vérifier le RTBH. Je ferais la prochaine fois..

La question est juste de savoir si c'est une pratique qui se fait
régulièrement sur un routeur de bordure de mettre une ACL extended sur les
interfaces des transitaires ou alors si c'est pas conseillé..

Merci

Le mer. 8 janv. 2020 à 12:35, David Ponzone  a
écrit :

> Ca donne quoi un sh proc c ?
>
> > Le 8 janv. 2020 à 12:27, Fabien H  a écrit :
> >
> > Bonjour,
> > bonne année à la communauté FRNOG :-)
> >
> > Je suis toujours sur mes histoires de DDOS : Le RTBH fonctionne, mais je
> > trouve que mes routeurs de bordure montent un peu trop en CPU à mon gout
> > (encore pas mal de pertes de paquets sur les paquets traversant).
> >
> > Je voulais juste savoir sur du CISCO, s'il est judicieux de mettre un ACL
> > IN (étendue) sur les interfaces des transitaires du style :
> >
> > deny udp port source 123 ip dest A.B.C.D
> > permit any any
> >
> > Est-ce que c'est mieux d'un point de vue performance et mitigation vu que
> > le paquet est droppé en entrée par rapport à une route Null 0 ? Ou alors
> à
> > l'inverse l'ACL va entrainer une surcharge CPU qui va le faire
> s'effondrer ?
> >
> > Merci,
> >
> > Fabien
> >
> >
> >
> >
> > Le mar. 24 déc. 2019 à 07:41, Michel Py <
> mic...@arneill-py.sacramento.ca.us>
> > a écrit :
> >
> >>>>> Alarig Le Lay a écrit :
> >>>>> Dans ce cas je préfère faire du flowspec, je trouve ça plus propre.
> >>
> >>>> Moi aussi, mais à part le problème d'avoir le matos récent qui le
> fait,
> >> va donc trouver un transitaire qui ferait
> >>>> çà en amont pour toi :-(  Déjà en trouver qui connaissent quelque
> >> choses aux communautés c'est pas évident.
> >>
> >>> Yannis Aribaud a écrit :
> >>> Hurricane Electric propose le support de flowspec en option sur leurs
> >> offres de transit. Mais ça coûte une blinde !
> >>
> >> C'est bon à savoir que quelqu'un le propose, mais malheureusement c'est
> le
> >> genre de chose qui ne vaut le coup de déployer que si tout le monde ou
> >> presque le propose. C'est lamentable, mais çà ne vaut pas la peine de
> payer
> >> si on a 4 ou 5 transits et que HE est le seul à proposer l'option :-(
> >> Intellectuellement, HE a mon support.
> >>
> >> Malheureusement, flowspec c'est quelque chose que j'aimerais bien
> >> implémenter mais que je n'ai pas le pognon de le faire.
> >> Encore une fois : ROI = zéro.
> >> En plus, avec les vendeurs qui demandent une license extra pour le
> faire...
> >> Bientôt, il faudra avoir une license pour aller pisser quand on
> configure
> >> un routeur.
> >>
> >> Michel.
> >>
> >>
> >> ---
> >> 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] RTBH : Propager une route BGP Null0 sur un routeur CISCO depuis une VM Linux

[Fabien H]

Bonjour,
bonne année à la communauté FRNOG :-)

Je suis toujours sur mes histoires de DDOS : Le RTBH fonctionne, mais je
trouve que mes routeurs de bordure montent un peu trop en CPU à mon gout
(encore pas mal de pertes de paquets sur les paquets traversant).

Je voulais juste savoir sur du CISCO, s'il est judicieux de mettre un ACL
IN (étendue) sur les interfaces des transitaires du style :

deny udp port source 123 ip dest A.B.C.D
permit any any

Est-ce que c'est mieux d'un point de vue performance et mitigation vu que
le paquet est droppé en entrée par rapport à une route Null 0 ? Ou alors à
l'inverse l'ACL va entrainer une surcharge CPU qui va le faire s'effondrer ?

Merci,

Fabien




Le mar. 24 déc. 2019 à 07:41, Michel Py 
a écrit :

> >>> Alarig Le Lay a écrit :
> >>> Dans ce cas je préfère faire du flowspec, je trouve ça plus propre.
>
> >> Moi aussi, mais à part le problème d'avoir le matos récent qui le fait,
> va donc trouver un transitaire qui ferait
> >> çà en amont pour toi :-(  Déjà en trouver qui connaissent quelque
> choses aux communautés c'est pas évident.
>
> > Yannis Aribaud a écrit :
> > Hurricane Electric propose le support de flowspec en option sur leurs
> offres de transit. Mais ça coûte une blinde !
>
> C'est bon à savoir que quelqu'un le propose, mais malheureusement c'est le
> genre de chose qui ne vaut le coup de déployer que si tout le monde ou
> presque le propose. C'est lamentable, mais çà ne vaut pas la peine de payer
> si on a 4 ou 5 transits et que HE est le seul à proposer l'option :-(
> Intellectuellement, HE a mon support.
>
> Malheureusement, flowspec c'est quelque chose que j'aimerais bien
> implémenter mais que je n'ai pas le pognon de le faire.
> Encore une fois : ROI = zéro.
> En plus, avec les vendeurs qui demandent une license extra pour le faire...
> Bientôt, il faudra avoir une license pour aller pisser quand on configure
> un routeur.
>
> Michel.
>
>
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/
>

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

Re: [FRnOG] [TECH] RTBH : Propager une route BGP Null0 sur un routeur CISCO depuis une VM Linux

[Fabien H]

Mauvais transitaire, je voulais dire que le paquet arrive par la GW du
transitaire qui n'est pas celle défini dans la table de routage pour le
réseau source du paquet

OK compris, donc sur les interfaces transitaire, on oublie uRPF.

Le ven. 20 déc. 2019 à 10:01, David Ponzone  a
écrit :

> Définis « mauvais transitaire » ? :)
>
> > Le 20 déc. 2019 à 09:57, Fabien H  a écrit :
> >
> > Bonjour Michel (quand il fera jour outre-atlantique :-) )
> >
> > J'ai regardé un peu uRPF, effectivement, c'est très intéressant
> > effectivement !
> >
> > Par contre juste une question qui me chagrine, en environnement
> multi-homé,
> > multi-transitaire avec ton préfixe /22 annoncé sur tous les transitaires,
> > sans local pref sur le sortant vers tel ou tel transitaire, il n'y a pas
> un
> > risque que le paquet arrive "de bonne foi" par le mauvais transitaire ?
> >
>
>

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

Re: [FRnOG] [TECH] RTBH : Propager une route BGP Null0 sur un routeur CISCO depuis une VM Linux

[Fabien H]

Bonjour Michel (quand il fera jour outre-atlantique :-) )

J'ai regardé un peu uRPF, effectivement, c'est très intéressant
effectivement !

Par contre juste une question qui me chagrine, en environnement multi-homé,
multi-transitaire avec ton préfixe /22 annoncé sur tous les transitaires,
sans local pref sur le sortant vers tel ou tel transitaire, il n'y a pas un
risque que le paquet arrive "de bonne foi" par le mauvais transitaire ?






Le jeu. 19 déc. 2019 à 21:27, Michel Py 
a écrit :

> > Fabien H a écrit :
> > announce route A.B.C.D/32 next-hop 10.10.2.41 community 65532:666
>
> Change 65532 pour quelque chose d'autre. Réservé pour Michel/CBBC :P
> A éviter aussi : 65332 (team Cymru)
>
> Ne pas oublier :
>
> interface null 0
>  no ip unreachables
>
> > Pas de problème de peformance si le routeur envoie d'abord vers 192.0.2.1
> > puis cherche la route 192.0.2.1 vers Null 0 ?
>
> Non, c'est la bonne manière.
>
> Tu as quoi pour sh ip route 0.0.0.0 ? tu utilises la route par défaut ?
>
> Prochaine étape : uRPF sur l'interface externe.
>
> Michel.
>
>
>

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

Re: [FRnOG] [TECH] RTBH : Propager une route BGP Null0 sur un routeur CISCO depuis une VM Linux

[Fabien H]

C'est OK pour la communauté et le no-export addditive.

Oui du coup, j'ai enlevé le set ip next-hop pour que réellement le next hop
soit celui envoyé par exaBGP 10.10.2.41

Et ensuite je rajoute sur le CISCO une route statique 10.10.2.41/32 vers
Null0 (qui est plus spécifique que le réseau directly connected 10.10.2.0/24
)

Merci encore




Le jeu. 19 déc. 2019 à 22:05, Michel Py 
a écrit :

> > Fabien H
> > exaBGP
> > announce route A.B.C.D/32 next-hop 10.10.2.41
>
> Mets une communauté 65000:666
>
> > route-map ANTIDDOS_IN permit 10
> >  no set ip next-hop 192.0.2.1
>
> "no" ?
>
> match community 65000:666
> SET COMMUNITY NO-EXPORT ADDITIVE
>
> Tant que tu n'es pas près à annoncer ce préfixe à tes transitaires avec la
> bonne communauté, il faut qu'il soit en no-export.
> Les fuitages de BGP, çà commence toujours avec quelqu'un qui a oublié
> no-export
>
>

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