Re: [FRnOG] [TECH] Tunnel L2 sur liens fibre L3
Un petit retour : Merci à tous, J'ai mis en place les service instance sur les 2 CPE et l'ASR de coeur, et ça a parfaitement fonctionné :-) Je n'ai pas encore fait de test de débit, mais sur du bridge, je suis confiant !! Petite subtilité : Sur les Cisco 1921, il faut utiliser les derniers firmwares (Version 15.7(3)M2 par exemple), car sur les versions 12, les service instance ne sont pas implémentés. Voici pour mémoire la conf simple : VLAN Client à propager : 1 VLAN Opérateur des 2 liens que se voient en L2 : 1000 et 2000 CPE sites 1 et 2 : bridge-domain 1 mac aging-time 600 interface GigabitEthernet0/0 no ip address service instance 1 ethernet encapsulation dot1q 3 rewrite ingress tag pop 1 symmetric bridge-domain 1 interface GigabitEthernet0/1 no ip address service instance 1 ethernet encapsulation dot1q 1 rewrite ingress tag pop 1 symmetric bridge-domain 1 Routeur Core ASR : bridge-domain 1000 mac aging-time 600 interface GigabitEthernet0/0/1 no ip address service instance 1000 ethernet encapsulation dot1q 1000 second-dot1q 3 rewrite ingress tag pop 1 symmetric bridge-domain 1000 ! service instance 2000 ethernet encapsulation dot1q 2000 second-dot1q 3 rewrite ingress tag pop 1 symmetric bridge-domain 1000 ! ! Bonne soirée, Fabien Le mer. 12 juin 2019 à 20:31, Radu-Adrian Feurdean < fr...@radu-adrian.feurdean.net> a écrit : > On Wed, Jun 12, 2019, at 11:10, Fabien H wrote: > > Oui, c'est ma collecte. > > > > Le but est de fournir au client un port Ethernet L2 en mode trunk sur > > chacun de ses sites. Il pourra donc faire passer tous les VLAN qu'il > > souhaite sans restriction. > > Commence deja par augmenter le MTU cote collecte et cote feuille. Mets une > valeur "assez haute" si possible la maximale admise par les STAS Orange (de > memoire un peu moins de 1800 pour optique, un peu moins de 1600 pour > cuivre). > > Cote CPE, le 1921 c'est limite, mais une fois la fragmentation eliminee > (MTU superieur a 1540) tu peux esperer de gagner encore quelques Mbps. Mais > pense a changer. Peut-etre tu vas tomber sur un modele qui fait le L2vpn de > facon plus simple. > > > Après le but serait de faire remonter ce "trunk" via le lien opérateur au > > niveau routeur de coeur ASR pour bridger avec l'autre lien. Donc au > niveau > > routeur de coeur, je vais me retrouver avec le VLAN opérateur + les sous > > vlan du client dans les trames (= QinQ). Donc pour le service instance, > > impossible d'utiliser un QinQ avec un vlan défini à l'avance ? > > Le CELAN n'etant pas limitatif au nombre de niveau de VLANs, tu peux avoir > - 1 niveau de 802.1q cote LAN CPE > - 2 niveaux de 802.1q cote WAN CPE > - 3 niveaux de 802.1q cote porte de collecte. Tu dois remonter les 2 > premiers pour faire le EVC > > Mais c'est crade. Quand tu commences a avoir beaucoup de liens ca devient > ingerable. L'approche CPE-vers-CPE est la bonne, mais il faut trouver le > bon CPE. > > > En gros la question est : est-ce que je peux à la fois bridger en coeur > de > > réseau les L2 du client configurés en mode trunk avec service instance, > et > > à la fois définir sur ce même Vlan opérateur un niveau 3 (configuré en > > QinQ) ? > > Techniquement tu peux, mais : > - ce n'est pas la meilleure idee > - est-tu sur de vouloir le faire ? > > En effet faudra qu'on coupe de factures a ton employeur pour tout ca :P > > > --- > Liste de diffusion du FRnOG > http://www.frnog.org/ > --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [Tech] BGP préférence de lien
Oui tout à fait, c'était l'objet de mon mail : on ne peut pas influencer l'entrant si un ASN sur le chemin de ton trafic entrant utilise un localpref vers tel ou tel partenaire, même si tu utilises l'AS Prepend pour tenter de l'influencer. Le lun. 20 mai 2019 à 14:07, Pierre Jouet a écrit : > Fabien, > > C'est un attribut local qui n'est pas propagé à un peer eBGP, et tu ne > peux rien faire avec pour influencer ton traffic entrant. > > il faut prepend l'AS-PATH, la local pref va te servir à sélectionner ton > transitaire pour le traf sortant. > > P > > On Mon, 20 May 2019 at 13:56, Fabien H wrote: > >> A priori, tu ne peux pas influencer le trafic entrant si le local pref est >> utilisé par un de tes transitaires ou en amont d'un de tes transitaires, >> car le localpref est prioritaire sur l'AS PATH : >> >> >> https://www.cisco.com/c/en/us/support/docs/ip/border-gateway-protocol-bgp/13753-25.html#anc2 >> >> >> >> Le lun. 20 mai 2019 à 13:45, Denis Fondras a écrit : >> >> > On Mon, May 20, 2019 at 11:04:36AM +0200, David Ponzone wrote: >> > > En entrée, c’est très différent, car ce sont 2 transitaires >> différents, >> > donc >> > > il faut influencer tout internet pour qu’un soit privilégié plutôt que >> > > l’autre. >> > > >> > > Généralement, on prepend l’as-path vers le transitaire qu’on veut >> moins >> > > privilégier. >> > > >> > >> > J'utilise une autre méthode (celle qui vous oblige à ajouter de la RAM >> > dans vos >> > routeurs) qui permet de s'affranchir des gens qui jouent avec localpref. >> > >> > >> > --- >> > Liste de diffusion du FRnOG >> > http://www.frnog.org/ >> > >> >> --- >> Liste de diffusion du FRnOG >> http://www.frnog.org/ >> > --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [Tech] BGP préférence de lien
Arf, j'avais mal compris (comme David ?) : Pour moi "s'affranchir" voulait dire "passer outre" le localpref, donc ça m'intriguait ! OK oui tourné comme ça, rien à dire de plus.. Le lun. 20 mai 2019 à 14:40, Denis Fondras a écrit : > > Localpref, en eBGP pour du traffic entrant ? > > Tu expliques ? > > > > J'écris si mal que ça ? o_O > > Si un réseau de transit change localpref, le prepend ne sera probablement > pas > respecté. > > Je ne sais pas comment m'exprimer plus clairement (peut-être avec un > dessin ?) > > > --- > Liste de diffusion du FRnOG > http://www.frnog.org/ > --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [Tech] BGP préférence de lien
Le problème de désagreger un préfixe, c'est que si tu tombes sur un transitaire qui aggrège les prefixes dans sa table de routage (comme SFR je crois), tu peux casser ton routage entrant. Et le temps de convergence, en cas de panne du transitaire sur lequel tu as mis un préfixe plus précis, sera plus long. Le lun. 20 mai 2019 à 14:32, Arnaud Launay a écrit : > Le Mon, May 20, 2019 at 01:53:10PM +0200, David Ponzone a écrit: > > > J'utilise une autre méthode (celle qui vous oblige à ajouter de la RAM > dans vos > > > routeurs) qui permet de s'affranchir des gens qui jouent avec > localpref. > > Localpref, en eBGP pour du traffic entrant ? > > Tu expliques ? > > Si je comprends bien (avec le gros hint sur la ram), il désagrège > son préfixe, et comme c'est le plus précis qui gagne... > > Arnaud. > > > --- > Liste de diffusion du FRnOG > http://www.frnog.org/ > --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [Tech] BGP préférence de lien
A priori, tu ne peux pas influencer le trafic entrant si le local pref est utilisé par un de tes transitaires ou en amont d'un de tes transitaires, car le localpref est prioritaire sur l'AS PATH : https://www.cisco.com/c/en/us/support/docs/ip/border-gateway-protocol-bgp/13753-25.html#anc2 Le lun. 20 mai 2019 à 13:45, Denis Fondras a écrit : > On Mon, May 20, 2019 at 11:04:36AM +0200, David Ponzone wrote: > > En entrée, c’est très différent, car ce sont 2 transitaires différents, > donc > > il faut influencer tout internet pour qu’un soit privilégié plutôt que > > l’autre. > > > > Généralement, on prepend l’as-path vers le transitaire qu’on veut moins > > privilégier. > > > > J'utilise une autre méthode (celle qui vous oblige à ajouter de la RAM > dans vos > routeurs) qui permet de s'affranchir des gens qui jouent avec localpref. > > > --- > Liste de diffusion du FRnOG > http://www.frnog.org/ > --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] VPLS multisites transparent aux VLAN du client (QinQ) et gestion boucles/trafic BUM
Question bête : pourquoi est-ce un problème de faire du LACP sur 2 LAN2LAN, à partir du moment où tout fonctionne bien en L2 sur chacun des liens individuellement ? > > Pour la rigolade, j'ai vu des gens qui voulaient faire du LACP/PortChannel > sur 2 LAN2LAN de 2 operateurs differents. Ils ont rapidement compris qu'il > vaut mieux commencer une migration vers du L3, malgre la difficulte. > > > --- Liste de diffusion du FRnOG http://www.frnog.org/
[FRnOG] [MISC] Webservice incidents boucle locale Orange ?
Bonjour, Client OWF CELAN, nous cherchons un moyen d'avoir l'information d'un éventuel incident sur la boucle locale pour un lien donné (par numéro de prestation), ou sur une zone géographique donnée, ou au pire par identifiant de DSLAM. Après avoir parcouru les différents webservices OWF, je n'ai pas trouvé ce type de service, est-ce que vous avez une idée ? Un site web officiel Orange peut faire l'affaire, s'il est fiable, et plus précis que ce site web qui est plus orienté grand public : https://suivi-des-incidents.orange.fr/infos-incident-local-internet-TV-telephone-fixe Merci, Cordialement, Fabien --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [MISC] Postes IP WiFi
Intéressant témoignage, quels téléphones CISCO, quels controleurs wifi et quels AP ? Mise à jour de firmware obligatoire sur les 3 ? Le sam. 28 sept. 2019 à 13:30, Olivier Vailleau a écrit : > Bonjour à tous, > Je vous trouve particulièrement rermontés contre le Wifi pour la ToIP.. > J'ai eu le plaisir de bosser dans un gros bâtiment (5 niveaux de 20 000m²) > totalement couvert en Wifi Cisco. > Les terminaux cisco wifi, malgré leur coté fragile sur la première gamme, > fonctionnaient très bien. Je crois qu'on en avait 800. > Alors certes, ca a un coût, il faut bien quadriller avec des AP corrects > (400 sur ce bâtiment) , les gérer avec des contrôleurs wifi qui vont bien. > mais avec cela, aucun souci de roaming, de couverture, etc > La solution était fiable. vraiment fiable.. elle est implémentée dans un > hôpital, avec toute les contraintes qu'on peu imaginer en terme de dispo, > de pollution electromagnétique, etc... > > Quand au DECT, définitivement, ca perturbe le matériel biomédical et ca > grille (plus) les neurones (que le wifi). > > Sinon, là, @Job actuel, sur les petits sites, on utilise des ipbx Damalisk > : Ca tournotte bien, c'est imaginé/dessiné en france, en bourgogne, même si > c'est assemblé ailleurs. La boite est réactive, et c'est un asterisk > embarqué. > Dans certains cas, on les relie en TrunkSIP à notre IPBX "pincipal" > Alcatel. > Olivier. > > > > --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [MISC] Webservice incidents boucle locale Orange ?
OK ça marche, je surveillerai la prochaine fois, merci Le sam. 28 sept. 2019 à 13:52, David Ponzone a écrit : > Avant même le test en fait! > Dès que tu as cliqué sur la réf de ton lien. > > David Ponzone > > > > Le 28 sept. 2019 à 13:36, Fabien H a écrit : > > C'est bien cela que je cherche ! > > Donc sur l'espace Opérateurs, e-SAV Test, tu vois à l'issue du diagnostic > si le lien est concerné par un incident générique ? > > Si c'est le cas, je suis confus, j'ai raté cela lors du dernier incident > générique ! > > Merci > > Le sam. 28 sept. 2019 à 13:25, David Ponzone a > écrit : > >> Je suis pas sûr de comprendre ce que tu cherches. >> En tant que client CELAN, si tu fais un test de lien sur e-SAV, tu vois >> automatiquement si ton lien est concerné par un incident génétique. >> >> Si tu veux savoir si un service que tu ne vends pas à ton client est >> concerné par un incident générique, je ne pense pas que ça soit possible :) >> >> David Ponzone >> >> >> >> > Le 28 sept. 2019 à 12:56, Fabien H a écrit : >> > >> > Bonjour, >> > >> > Client OWF CELAN, nous cherchons un moyen d'avoir l'information d'un >> > éventuel incident sur la boucle locale pour un lien donné (par numéro de >> > prestation), ou sur une zone géographique donnée, ou au pire par >> > identifiant de DSLAM. >> > >> > Après avoir parcouru les différents webservices OWF, je n'ai pas trouvé >> ce >> > type de service, est-ce que vous avez une idée ? >> > >> > Un site web officiel Orange peut faire l'affaire, s'il est fiable, et >> plus >> > précis que ce site web qui est plus orienté grand public : >> > >> > >> https://suivi-des-incidents.orange.fr/infos-incident-local-internet-TV-telephone-fixe >> > >> > Merci, >> > Cordialement, >> > Fabien >> > >> > --- >> > Liste de diffusion du FRnOG >> > http://www.frnog.org/ >> > --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [MISC] Webservice incidents boucle locale Orange ?
C'est bien cela que je cherche ! Donc sur l'espace Opérateurs, e-SAV Test, tu vois à l'issue du diagnostic si le lien est concerné par un incident générique ? Si c'est le cas, je suis confus, j'ai raté cela lors du dernier incident générique ! Merci Le sam. 28 sept. 2019 à 13:25, David Ponzone a écrit : > Je suis pas sûr de comprendre ce que tu cherches. > En tant que client CELAN, si tu fais un test de lien sur e-SAV, tu vois > automatiquement si ton lien est concerné par un incident génétique. > > Si tu veux savoir si un service que tu ne vends pas à ton client est > concerné par un incident générique, je ne pense pas que ça soit possible :) > > David Ponzone > > > > > Le 28 sept. 2019 à 12:56, Fabien H a écrit : > > > > Bonjour, > > > > Client OWF CELAN, nous cherchons un moyen d'avoir l'information d'un > > éventuel incident sur la boucle locale pour un lien donné (par numéro de > > prestation), ou sur une zone géographique donnée, ou au pire par > > identifiant de DSLAM. > > > > Après avoir parcouru les différents webservices OWF, je n'ai pas trouvé > ce > > type de service, est-ce que vous avez une idée ? > > > > Un site web officiel Orange peut faire l'affaire, s'il est fiable, et > plus > > précis que ce site web qui est plus orienté grand public : > > > > > https://suivi-des-incidents.orange.fr/infos-incident-local-internet-TV-telephone-fixe > > > > Merci, > > Cordialement, > > Fabien > > > > --- > > Liste de diffusion du FRnOG > > http://www.frnog.org/ > --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [MISC] Postes IP WiFi
OK merci. Je vois que les 7925 sont en End Of Life, donc actuellement la même infra se ferait en 8821 le produit de remplacement. Le dim. 29 sept. 2019 à 01:24, Olivier Vailleau a écrit : > Fabien, > Je suis bien en difficulté pour te répondre de façon précise car ce > n'était pas ma partie. > Les postes étaient des 7921 puis des 7925.J'ai particulièrement apprécié > la qualité sonore des vieux 7921. > En ce qui concerne les contrôleurs, je peux juste te dire que ce sont ceux > qui se montent en carte dans les chassis cisco 6500. Il contrôlaient des AP > cisco mais je n'ai aucune référence là dessus. (ap blanc, carré aux coins > arrondis, légèrement bombé, avec un cercle qui change de couleur selon > l'état de la borne). > > Je me rappelle que nous avions 3 contrôleurs répartis dans des châssis > différents (salles serveurs séparées) et qu'on avait croisé l'affectation > des bornes aux controlleurs pour que la perte d'un contrôleur ne fasse > disparaitre qu'une AP sur 2 . De cette façon, le maillage wifi restait > correct. > > Je ne me rappelle pas qu'il y ai eu des maj de firmware.. en tout cas, > rien qui pouvait arrêter le service car on ne pouvait pas (samu, urg, > cardio intensive, etc..) > > Le sam. 28 sept. 2019 à 13:42, Fabien H a écrit : > >> Intéressant témoignage, >> >> quels téléphones CISCO, quels controleurs wifi et quels AP ? >> >> Mise à jour de firmware obligatoire sur les 3 ? >> >> >> Le sam. 28 sept. 2019 à 13:30, Olivier Vailleau < >> olivier.vaill...@gmail.com> >> a écrit : >> >> > Bonjour à tous, >> > Je vous trouve particulièrement rermontés contre le Wifi pour la ToIP.. >> > J'ai eu le plaisir de bosser dans un gros bâtiment (5 niveaux de 20 >> 000m²) >> > totalement couvert en Wifi Cisco. >> > Les terminaux cisco wifi, malgré leur coté fragile sur la première >> gamme, >> > fonctionnaient très bien. Je crois qu'on en avait 800. >> > Alors certes, ca a un coût, il faut bien quadriller avec des AP corrects >> > (400 sur ce bâtiment) , les gérer avec des contrôleurs wifi qui vont >> bien. >> > mais avec cela, aucun souci de roaming, de couverture, etc >> > La solution était fiable. vraiment fiable.. elle est implémentée dans un >> > hôpital, avec toute les contraintes qu'on peu imaginer en terme de >> dispo, >> > de pollution electromagnétique, etc... >> > >> > Quand au DECT, définitivement, ca perturbe le matériel biomédical et ca >> > grille (plus) les neurones (que le wifi). >> > >> > Sinon, là, @Job actuel, sur les petits sites, on utilise des ipbx >> Damalisk >> > : Ca tournotte bien, c'est imaginé/dessiné en france, en bourgogne, >> même si >> > c'est assemblé ailleurs. La boite est réactive, et c'est un asterisk >> > embarqué. >> > Dans certains cas, on les relie en TrunkSIP à notre IPBX "pincipal" >> > Alcatel. >> > Olivier. >> > >> > >> > >> > >> >> --- >> Liste de diffusion du FRnOG >> http://www.frnog.org/ >> > --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Routeur 3 full tables BGP et 10G
Excusez-moi je déterre le sujet : Donc finalement un ASR 9001 tient sans problème les 3 full table avec ses 8 Go de RAM ? Et en cas de disparition d'un gros peer distant (transitaire,..), pas de lag/perte de paquets constaté sur le routage lors du recalcul des routes ? Le dim. 29 sept. 2019 à 10:55, Radu-Adrian Feurdean < fr...@radu-adrian.feurdean.net> a écrit : > > > On Sat, Sep 28, 2019, at 19:55, jehan procaccia INT wrote: > > > c'est embetant quand on reseau full cisco de partir sur un autre > > equipementier, en terme de maintenance, habitudes des equipes techniques > > et outils de monitoring/backups/gestion de contrats ... mais cela merite > > reflexion . > > Par contre, comme asr9k (ainsi que les NCS) sont bases sur IOS-XR, dpdv > habitudes c'est comme un nouveau constructeur ou presque. (premiere tache > sur XR pour un habitue IOS classique : trouver l'equivalent du "write mem" > :P) > > > PS: l'ASR920 ou cisco 9500 sont hors jeu pourquoi ? memoire ? cpu ? > > features BGP ? car en terme de ports 10G tout est là . > > ASR920 c'est 20k routes en FIB, et le CPU faut pas lui demander grand > chose. > Le 9500 (Cayalyst je suppose) c'est une gamme "desktop". Mon avis perso, > c'est que Cisco se donne beaucoup de mal pour la rendre SP-unfriendly. > Featureset, capacite FIB, cpu, je doute qu' il y a grand chose qui > correspond pour faire "bordure internet" > > > --- > Liste de diffusion du FRnOG > http://www.frnog.org/ > --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Routeur 3 full tables BGP et 10G
Disons dans le pire des cas : Timeout sur timer (sans BFD) ? Vous pensez qu'un ASR 9001 peut lagguer violemment au point d'interrompre le routage dans ce cas ? Le dim. 27 oct. 2019 à 11:29, Alarig Le Lay a écrit : > Le 27/10/2019 à 10:42, Fabien H a écrit : > > Et en cas de disparition d'un gros peer distant (transitaire,..), pas de > > lag/perte de paquets constaté sur le routage lors du recalcul des routes > ? > > J’ai envie de dire que ça dépend de comment ça coupe, de si tu fais du > BFD et de tes timers. > > -- > Alarig > > > --- > Liste de diffusion du FRnOG > http://www.frnog.org/ > --- Liste de diffusion du FRnOG http://www.frnog.org/
[FRnOG] [BIZ] Datacentre à Clermont Ferrand
Bonjour, je suis à la recherche d'un Datacentre à Clermont Ferrand proche des SRTHD Orange et ou Orange a déjà livré des fibres car nous devons ouvrir une porte de collecte. Je ne trouve pas beaucoup d'infos sur l'existant, je vois IBO ..? Le besoin : 1/2 baie Transit IP + une tranche IPv4 /25 ou /26 serait idéal Merci, Fabien --- Liste de diffusion du FRnOG http://www.frnog.org/
[FRnOG] [TECH] RTBH : Propager une route BGP Null0 sur un routeur CISCO depuis une VM Linux
Bonsoir, Le titre résume ce que j'ai besoin de faire : Pendant une attaque DDOS vers une seule IP, selon l'intensité de l'attaque il est parfois difficile d'attaquer un routeur de bordure en telnet pour y insérer une route Null 0 J'aimerai donc injecter via une session BGP une route Null0 sur nos routeurs de bordure. J'ai essayé avec exaBGP qui semblait vraiment adapté mais la commande à envoyer autorise uniquement un next-hop de type IP ! : announce route X.Y.Z.A/32 next-hop Bird, je ne trouve pas d'exemple parlant pour envoyer une route Null 0. Avez-vous déjà fait ça avec un démon BGP sous Linux ? Merci, Cordialement, Fabien --- 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
Cisco IOS Software, 7301 Software (C7301-ADVIPSERVICESK9-M), Version 12.4(24)T1, RELEASE SOFTWARE (fc3) show ip bgp neighbors 10.10.2.40 10.10.2.40 = IP de la VM exaBGP Le jeu. 19 déc. 2019 à 20:59, Michel Py a écrit : > > Fabien H a écrit : > > @Michel, > > J'obtiens toujours l'erreur NEXT_HOP non-local sur le neighbor sur le > CISCO :-( > > OutboundInbound > > Local Policy Denied Prefixes:--- > > route-map: 797007 0 > > NEXT_HOP non-local: n/a 1 > > Total: 797007 1 > > Quel routeur, quelle version d'IOS, quelle est la commande que tu tapes > pour obtenir ce qui est au-dessus ? > > 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
Ca y'est j'ai réussi :-) J'ai juste annoncé avec un next hop qui est directly connected au routeur CISCO mais pas sur le routeur CISCO et la route s'est bien installée : exaBGP announce route A.B.C.D/32 next-hop 10.10.2.41 community 65532:666 CISCO #show ip bgp A.B.C.D/32 BGP routing table entry for A.B.C.D /32, version 0 Paths: (1 available, no best path) Not advertised to any peer 65000 192.0.2.1 (inaccessible) from 10.10.2.40 (10.10.2.40) Origin IGP, localpref 100, valid, external Community: 65532:666 no-export #show ip route 192.0.2.1 Routing entry for 192.0.2.1/32 Known via "static", distance 1, metric 0 (connected) Redistributing via bgp 60718 Routing Descriptor Blocks: * directly connected, via Null0 Route metric is 0, traffic share count is 1 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 ? Merci Le jeu. 19 déc. 2019 à 21:10, Fabien H a écrit : > % Network not in table > > La route n'est pas installée.. > > > > Le jeu. 19 déc. 2019 à 21:08, Michel Py < > mic...@arneill-py.sacramento.ca.us> a écrit : > >> Si tu fais sh ip bgp x.x.x.x/32 (l'addresse que tu bloques) tu as quoi ? >> >> --- 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
Bonsoir David, comme d'habitude, réponse plus vite que l'éclair ! Alors je n'avais pas essayé ça parce que ma route est refusée par le routeur CISCO si le next hop n'existe pas sur le routeur CISCO (erreur NEXT_HOP non-local) J'ai essayé malgré tout de créer une route vers Null0 sur le CISCO pour le Next Hop mais pas mieux Local Policy Denied Prefixes:--- route-map: 827333 0 NEXT_HOP non-local: n/a 2 Merci Le jeu. 19 déc. 2019 à 19:12, David Ponzone a écrit : > Tu envoies la route avec un next-hop bidon et tu routes le next-hop sur le > Cisco vers Null0. > > David Ponzone > > > > > Le 19 déc. 2019 à 19:09, Fabien H a écrit : > > > > Bonsoir, > > > > Le titre résume ce que j'ai besoin de faire : > > > > Pendant une attaque DDOS vers une seule IP, selon l'intensité de > l'attaque > > il est parfois difficile d'attaquer un routeur de bordure en telnet pour > y > > insérer une route Null 0 > > > > J'aimerai donc injecter via une session BGP une route Null0 sur nos > > routeurs de bordure. > > > > J'ai essayé avec exaBGP qui semblait vraiment adapté mais la commande à > > envoyer autorise uniquement un next-hop de type IP ! : announce route > > X.Y.Z.A/32 next-hop > > > > Bird, je ne trouve pas d'exemple parlant pour envoyer une route Null 0. > > Avez-vous déjà fait ça avec un démon BGP sous Linux ? > > > > Merci, > > Cordialement, > > > > Fabien > > > > --- > > 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
Super un grand merci à la communauté pour les réponses !! @Michel : J'avais pas pensé au route-map qui change le next-hop je vais tester rapidement.. @Paul : A mon avis, la condition c'est une route directly Connected @Alexis : Même principe que Michel : route-map mais pour changer l'interface, je vais tester aussi Vous me sauvez ma soirée :-) Le jeu. 19 déc. 2019 à 19:26, Michel Py a écrit : > >> Fabien H a écrit : > >> J'ai essayé avec exaBGP qui semblait vraiment adapté mais la commande à > envoyer autorise > >> uniquement un next-hop de type IP ! : announce route X.Y.Z.A/32 > next-hop > > C'est tout a fait adapté, c'est ce que je fais. > > > David Ponzone a écrit : > > Tu envoies la route avec un next-hop bidon et tu routes le next-hop sur > le Cisco vers Null0. > > Pas bidon, il y a une adresse pratiquement standard : 192.0.2.1 > > Fabien, regarde l'exemple ici : > http://arneill-py.sacramento.ca.us/cbbc/ > > 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
@Michel, j'ai donc testé comme ceci comme dans CBBC : ... neighbor 10.10.2.40 route-map ANTIDDOS_IN in ... ... route-map ANTIDDOS_IN permit 10 match ip address prefix-list ANTIDDOS_IN set community no-export additive set ip next-hop 192.0.2.1 ! ... ip route 192.0.2.1 255.255.255.255 Null0 name ANTI_DDOS_BLACKHOLE Malgré tout quand je pousse ma route depuis exaBGP : announce route A.B.C.D/32 next-hop 192.0.2.1 J'obtiens toujours l'erreur NEXT_HOP non-local sur le neighbor sur le CISCO :-( OutboundInbound Local Policy Denied Prefixes:--- route-map: 797007 0 NEXT_HOP non-local: n/a 1 Total: 797007 1 Une idée ? Merci Le jeu. 19 déc. 2019 à 19:26, Michel Py a écrit : > >> Fabien H a écrit : > >> J'ai essayé avec exaBGP qui semblait vraiment adapté mais la commande à > envoyer autorise > >> uniquement un next-hop de type IP ! : announce route X.Y.Z.A/32 > next-hop > > C'est tout a fait adapté, c'est ce que je fais. > > > David Ponzone a écrit : > > Tu envoies la route avec un next-hop bidon et tu routes le next-hop sur > le Cisco vers Null0. > > Pas bidon, il y a une adresse pratiquement standard : 192.0.2.1 > > Fabien, regarde l'exemple ici : > http://arneill-py.sacramento.ca.us/cbbc/ > > 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
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/
Re: [FRnOG] [TECH] RTBH : Propager une route BGP Null0 sur un routeur CISCO depuis une VM Linux
#show ip route 192.0.2.1 Routing entry for 192.0.2.1/32 Known via "static", distance 1, metric 0 (connected) Redistributing via bgp ASN Routing Descriptor Blocks: * directly connected, via Null0 Route metric is 0, traffic share count is 1 Bon finalement je pense que cette fois c'est bon ! exaBGP announce route A.B.C.D/32 next-hop 10.10.2.41 CISCO ip route 10.10.2.41 255.255.255.255 Null0 name ANTIDDOS_BLACKHOLE route-map ANTIDDOS_IN permit 10 no set ip next-hop 192.0.2.1 Ce qui donne : show ip route A.B.C.D/32 Routing entry for A.B.C.D/32 Known via "bgp ASN", distance 20, metric 0 Tag 65000, type external Last update from 10.10.2.41 00:03:15 ago Routing Descriptor Blocks: * 10.10.2.41, from 10.10.2.40, 00:03:15 ago Route metric is 0, traffic share count is 1 AS Hops 1 Route tag 65000 show ip route 10.10.2.41 Routing entry for 10.10.2.41/32 Known via "static", distance 1, metric 0 (connected) Redistributing via bgp ASN Routing Descriptor Blocks: * directly connected, via Null0 Route metric is 0, traffic share count is 1 Merci beaucoup pour ton aide et celles des autres juste avant ! Bonne fin de journée / soirée Fabien Le jeu. 19 déc. 2019 à 21:45, Michel Py a écrit : > > A noter que j'ai encore un problème : La route BGP ci-dessous > > ne s'installe pas car 192.0.2.1 est inaccessible à priori > > sh ip route 192.0.2.1 ? > > --- 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
C'est noté merci pour les conseils. A noter que j'ai encore un problème : La route BGP ci-dessous ne s'installe pas car 192.0.2.1 est inaccessible à priori #show ip bgp A.B.C.D/32 BGP routing table entry for A.B.C.D /32, version 0 Paths: (1 available, no best path) Not advertised to any peer 65000 192.0.2.1 (inaccessible) from 10.10.2.40 (10.10.2.40) Origin IGP, localpref 100, valid, external Community: 65532:666 no-export # show ip bgp A.B.C.D/32 n'affiche ni 192.0.2.1, ni Null 0 :-( sh ip route 0.0.0.0 m'indique l'IP d'un de mes transitaires qui m'envoie la route par défaut 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
% Network not in table La route n'est pas installée.. Le jeu. 19 déc. 2019 à 21:08, Michel Py a écrit : > Si tu fais sh ip bgp x.x.x.x/32 (l'addresse que tu bloques) tu as quoi ? > > --- 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
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
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] AOC ou DAC, et question existentielle sur la position idéale d'un ToR
> 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
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
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
> 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
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
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
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
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
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
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
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
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
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/
[FRnOG] [TECH] CISCO - Route d'entrée dans un VRF depuis le routeur lui-même
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
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
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
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/
Re: [FRnOG] [TECH] Policy-map output CISCO qui me rend fou !
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
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/
Re: [FRnOG] [TECH] UDP - DDOS : Solution globale possible ?
> > 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/
[FRnOG] Re: [TECH] UDP - DDOS : Solution globale possible ?
@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 ?
@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 ?
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 ?
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] Re: [TECH] UDP - DDOS : Solution globale possible ?
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/
Re: [FRnOG] [MISC] DSAV Project: sérieux ou scam ?
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/
Re: [FRnOG] Re: [MISC] DSAV Project: sérieux ou scam ?
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/
[FRnOG] [TECH] Contact téléphonique Peering OVH
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 ?
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] [BIZ] Editeur de VM Centrex complet & multi-tenant
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/
[FRnOG] [BIZ] Editeur de VM Centrex complet & multi-tenant
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] [BIZ] Editeur de VM Centrex complet & multi-tenant
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
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/
Re: [FRnOG] [BIZ] Editeur de VM Centrex complet & multi-tenant
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] [TECH] Codecs VoIP sur OVH
> 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] Codecs VoIP sur OVH
> 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
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/
[FRnOG] [TECH] SIP OWF : Appels vers numéros M2M à 14 chiffres
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/
[FRnOG] [TECH] CISCO REP vs LACP
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] [TECH] CISCO REP vs LACP
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/
Re: [FRnOG] [TECH] CISCO REP vs LACP
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
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
> > > 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] [MISC] Notre meilleur argument pour vendre du FTTO
> 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/
Re: [FRnOG] [TECH] Broadband Access Aggregation and DSL Configuration
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] [ALERT] Soucis sur FranceIX + AWS ?
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/
[FRnOG] [MISC] Liste de diffusion simple clients
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] [MISC] Liste de diffusion simple clients
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
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/
Re: [FRnOG] [MISC] Liste de diffusion simple clients
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] [TECH] Broadband Access Aggregation and DSL Configuration
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] Broadband Access Aggregation and DSL Configuration
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
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] Subnet ip publique sur LAN
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] Supervision latence et traceroute tout en un
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
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/
[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/
Re: [FRnOG] [TECH] Ping / traceroute vers Orange depuis ce matin 10H
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] Convertisseur Fibre 1G LC - Cuivre en DC
Bonjour, je suis à la recherche d'un convertisseur fiable pour brancher une porte de collecte monomode LC 1G sur un routeur CISCO avec port Cuivre 1G. Je ne peux pas utiliser nos SW CISCO pour faire la conversion pour des raisons d'isolation des VLAN qui y transitent. Avez-vous des références très fiables (uptime et non buggé) et pas trop trop cher ? Alim 220V Merci, Fabien --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Convertisseur Fibre 1G LC - Cuivre en DC
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
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] Rx max sur SFP 10G LR
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] [TECH] Rx max sur SFP 10G LR
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/
Re: [FRnOG] [TECH] Suggestions sur routeur VPN IPSEC
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] Rejet d'emails par outlook.com
+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] [TECH] Rejet d'emails par outlook.com
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] [MISC] Logiciel d'inventaire orienté objet
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
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/
[FRnOG] [TECH] Convertisseur 10G BiDi vers 10G LR ou SR ou BaseT
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/
Re: [FRnOG] [TECH] Convertisseur 10G BiDi vers 10G LR ou SR ou BaseT
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/
Re: [FRnOG] [TECH] Convertisseur 10G BiDi vers 10G LR ou SR ou BaseT
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
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/
[FRnOG] [TECH] Stratégie redondance/branchement switchs coeur de réseau
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] Stratégie redondance/branchement switchs coeur de réseau
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
