RE: [FRnOG] [TECH] Pertes de paquets en UDP depuis SFR/NC vers ONLINE-DC3 depuis 1 semaine
Bonjour, Même problème constaté -Message d'origine- De : frnog-requ...@frnog.org [mailto:frnog-requ...@frnog.org] De la part de Denis VINCIGUERRA Envoyé : jeudi 2 février 2017 11:23 À : frnog-t...@frnog.org Objet : [FRnOG] [TECH] Pertes de paquets en UDP depuis SFR/NC vers ONLINE-DC3 depuis 1 semaine Bonjour, Depuis 1 semaine (plus précisément depuis le 26/01 entre 22h et 0h), j'ai remarqué des gros problèmes entre mon bureau (connexion SFR thd) et l’hébergeur ONLINE, et ce toute la journée et toute la nuit. En faisant divers tests, j'ai pu remarquer que seul le trafic UDP était impacté dans le sens SFR => ONLINE. Pas de chance, j'utilise UDP pour monter un VPN entre les 2. J'ai remarqué un problème similaire sur des cameras "cloud" qui montent un VPN sur UDP vers l'infra du constructeur qui est... chez Online également. Après avoir envoyé différents résultats de tests à Online, ils me disent que le problème a été remonté par plusieurs clients mais est chez SFR/NC et me renvoient vers leur support, sans vouloir donner + de précisions, malgré avoir insisté. J'ai contacté le support SFR mais j'attends encore leur retour et je désespère d'avance face au fait qu'on va me demander de rebooter mon ordinateur, de faire un reset to factory defaults de la box, etc etc... Quelqu'un de la ML serait chez SFR/NC (ou chez ONLINE d'ailleurs) et pourrait regarder ? Sinon que me conseillez-vous de faire dans ce genre de cas (hormis tunnelliser sur TCP en attendant des jours meilleurs :) ) Voici ci joint des MTR d'un site à l'autre, en ICMP et UDP. Si je ne me trompe pas, on voit les pertes de paquet au niveau de entre 172.19.132.118 (wtf?) et numericable.bb1.dc3.poneytelecom.eu dans le sens SFR => ONLINE, et seulement en UDP. SFR -> ONLINE: aucune probleme sur ICMP mais 20% de pertes sur UDP # mtr -c 50 -s 1300 --report 212.83.x.x # IP Online HOST: firewall-bureau Loss% Snt Last Avg Best Wrst StDev 1.|-- box0.0%500.4 0.4 0.3 0.4 0.0 2.|-- ??? 100.0500.0 0.0 0.0 0.0 0.0 3.|-- pal1rj-ge-2-1-0.200.numer 0.0%506.9 8.0 6.7 11.3 1.0 4.|-- 172.19.132.118 0.0%50 11.7 11.3 8.3 15.1 1.5 5.|-- numericable.bb1.dc3.poney 0.0%509.9 11.3 9.9 16.7 1.1 6.|-- 45x-s43-1-a9k1.dc3.poneyt 0.0%50 14.6 13.3 10.2 19.7 2.4 7.|-- 212.83.x.x 0.0%50 11.3 10.7 9.5 11.6 0.6 # mtr -c 50 -s 1300 -u --report 212.83.x.x # IP Online HOST: firewall-bureau Loss% Snt Last Avg Best Wrst StDev 1.|-- box0.0%500.4 0.4 0.4 0.9 0.1 2.|-- ??? 100.0500.0 0.0 0.0 0.0 0.0 3.|-- pal1rj-ge-2-1-0.200.numer 0.0%506.9 7.9 6.7 9.8 0.8 * 4.|-- 172.19.132.118 0.0%50 12.3 11.5 9.1 17.8 1.6* * 5.|-- numericable.bb1.dc3.poney 16.0%50 10.4 11.3 10.0 15.3 1.0* 6.|-- 45x-s43-1-a9k1.dc3.poneyt 18.0%50 15.8 14.0 10.3 33.9 4.4 7.|-- ??? 100.0500.0 0.0 0.0 0.0 0.0 ONLINE => SFR: quasiment aucune perte sur ICMP et quasiment aucune perte sur UDP # mtr -c 50 -s 1300 --report 109.12.x.x # IP SFR HOST: serveur Loss% Snt Last Avg Best Wrst StDev 1.|-- firewall-hebergeur 0.0%500.1 0.1 0.1 0.3 0.0 2.|-- 62-210-188-1.rev.poneytel 0.0%501.3 2.5 0.7 7.2 1.7 3.|-- a9k2-45x-s43-1.dc3.poneyt 0.0%500.7 0.8 0.7 2.0 0.3 4.|-- lag-online-2.dc3-2.rt.hop 0.0%500.3 0.4 0.3 1.3 0.1 5.|-- lag-pop-std-1.dc3-1.rt.ho 0.0%500.6 0.7 0.6 2.2 0.3 6.|-- sfr.std-1.rt.hopus.net 0.0%504.8 2.9 1.0 5.0 1.2 7.|-- 226.122.3.109.rev.sfr.net 0.0%505.2 5.4 3.5 7.6 1.1 8.|-- 241.122.3.109.rev.sfr.net 0.0%505.7 4.7 3.0 6.7 1.2 9.|-- 193.224.65.86.rev.sfr.net 0.0%503.3 3.4 3.1 4.6 0.2 10.|-- 195-132-10-228.rev.numeri 2.0%502.9 2.9 2.8 3.1 0.0 11.|-- ??? 100.0500.0 0.0 0.0 0.0 0.0 # mtr -c 50 -s 1300 -u --report 109.12.x.x # IP SFR HOST: serveur Loss% Snt Last Avg Best Wrst StDev 1.|-- firewall-hebergeur 0.0%500.2 0.1 0.1 0.2 0.0 2.|-- 62-210-188-1.rev.poneytel 0.0%505.0 3.4 0.7 15.3 3.2 3.|-- a9k2-45x-s43-1.dc3.poneyt 0.0%500.8 0.9 0.7 2.2 0.4 4.|-- lag-online-2.dc3-2.rt.hop 0.0%500.4 0.4 0.3 0.7 0.1 5.|-- lag-pop-std-1.dc3-1.rt.ho 0.0%500.8 0.8 0.6 2.9 0.5 6.|-- sfr.std-1.rt.hopus.net 0.0%503.0 2.9 0.9 5.2 1.2 7.|-- 226.122.3.109.rev.sfr.net 0.0%503.7 5.3 3.3 7.2 1.1 8.|-- 241.122.3.109.rev.sfr.net 0.0%504.7 4.8 2.8 6.8 1.2 9.|--
RE: [FRnOG] [TECH] Problème de disparition de conf sur Cisco 3560G après panne électrique
Bonjour, j'ai eu ce comportement sur une stack de 3750 JD -Message d'origine- De : frnog-requ...@frnog.org [mailto:frnog-requ...@frnog.org] De la part de Frederic Dhieux Envoyé : lundi 27 février 2017 17:44 À : frnog-t...@frnog.org Objet : [FRnOG] [TECH] Problème de disparition de conf sur Cisco 3560G après panne électrique Hello, Ce matin j'ai quelques baies qui sont tombées électriquement (c'est la vie). Mais par contre chose très surprenante, mes deux 3560G en tête de baie ne sont pas revenus avec le courant bien qu'ils aient booté. Après quelques échanges avec le support du DC (un peu occupé par l'événement) et le déplacement d'un tech sur place, on a finalement constaté la même panne sur les deux 3560G : Reset complet de la conf, plus de config.text, plus de private-config.text, vlan.dat remis à zéro sur la flash. Alors bien sûr si un mec me disait ça l'instinct me dirait que la conf n'a pas été enregistrée, mais ces 3560G sont là depuis plus de 4 ans, ils ont eu de multiples reload d'upgrade d'OS, la conf est bien récupérée entièrement par rancid (la conf enregistrée, pas la running) et j'ai bien la belle trace de mon "dir flash:" tout rempli dans le même log rancid. La question étant : Est-ce que ça vous est déjà arrivé sur ce type d'équipement ? Parce que le même problème sur 2 équipements en même temps de voir disparaître sa conf sur une panne électrique, j'avoue ça me sidère un peu quand même niveau probabilité. Ca tourne sur du 15.0 dernière version depuis un moment, pas de manip depuis un moment non plus, tout était clean sans rien en pending... Un bon lundi de merde sous la bénédiction de Saint Murphy quoi :) Fred --- Liste de diffusion du FRnOG http://www.frnog.org/ smime.p7s Description: S/MIME cryptographic signature
[FRnOG] [TECH] postfix - archivage des queues pour rejeu en cas d'incident
Bonjour à tous, Je souhaiterai mettre en place sur mes frontaux postfix un système de sauvegarde des emails afin d'être capable de rejouer certains mails sur quelques jours. Il existe une option alway_bcc mais cette option duplique le mail vers une autre boite ce qui n'est pas exactement mon objectif (rendant le rejeu laborieux) Si quelqu'un a une idée voir même une solution je suis plus que preneur. Merci JD --- Liste de diffusion du FRnOG http://www.frnog.org/
RE: [FRnOG] [TECH] postfix - archivage des queues pour rejeu en cas d'incident
Bonjour, En effet notre souhait est de pouvoir rejouer l'intégralité des emails même ceux délivrés afin de pallier le manque de solidité d'une infra. Aujourd'hui nous gardons les emails pendant 4 jours si le serveur ne répond pas mais notre objectif est d'être capable de rejouer les emails lorsque la boite destination a été pleine ou que le serveur renvoyait un rejet de l'email (blacklist du serveur d'émission, faux positif en spam ou en virus ou autre problème de ce type). Certains emails ne peuvent pas ou ne doivent pas être perdus ... Cordialement J.Delmas -Message d'origine- De : David Ponzone [mailto:david.ponz...@gmail.com] Envoyé : lundi 12 juin 2017 16:30 À : François Ranchin Cc : DELMAS JACQUES; frnog-t...@frnog.org Objet : Re: [FRnOG] [TECH] postfix - archivage des queues pour rejeu en cas d'incident A mon avis, Jacques devait avoir une idée précise derrière la tête, ou avoir un client avec un besoin particulier. Jacques, tu peux en dire plus ? > Le 12 juin 2017 à 16:15, Francois Ranchin <f...@fyrou.net> a écrit : > > Salut David > > On 12 Jun 2017, at 4:19, David Ponzone wrote: > >> François, >> >> Ça fait un baille :) >> >> Dans la demande d'origine de Jacques, j'ai personnellement compris qu'il >> voulait être capable de rejouer tous les mails, même ceux correctement >> délivrés. >> Dans ton idée, ne subsiste-t-il pas un problème car entre la fin d'un find >> et le suivant (donc intervalle d'exécution+durée d'exécution en gros), il y >> a des mails qui vont arriver en queue et qui pourraient être perdus en cas >> de problème sur la machine. >> > > > Oui tout à fait. Bah comme il a des disques sécurisés si sa CM crame c'est > pas génant :) Apres c'est plus un pb d'archi ou d'infra générale de solidité > de ses serveurs que de rejouage. > > > Bisou > > > --- > Liste de diffusion du FRnOG > http://www.frnog.org/ smime.p7s Description: S/MIME cryptographic signature
RE: [FRnOG] [TECH] postfix - archivage des queues pour rejeu en cas d'incident
Bonjour, Merci pour vos réponses cette liste est vraiment épatante ! Par rejouer j'envisage en effet la possibilité de réinjecter dans la queue certains mails (par exemple une boite mail pleine sur laquelle les mails n'ont pas été délivrés ou encore un serveur qui crash, la possibilité de réinjecter les mails reçus depuis le dernier backup). Cordialement J.D -Message d'origine- De : Phil Regnauld [mailto:regna...@x0.dk] Envoyé : jeudi 8 juin 2017 09:37 À : DELMAS JACQUES Cc : frnog-t...@frnog.org Objet : Re: [FRnOG] [TECH] postfix - archivage des queues pour rejeu en cas d'incident DELMAS JACQUES (jacques.delmas) writes: > > Je souhaiterai mettre en place sur mes frontaux postfix un système de > sauvegarde des emails afin d'être capable de rejouer certains mails sur > quelques jours. Salut, Définir "rejouer" ? Réinjecter dans la queue des mails ? > Il existe une option alway_bcc mais cette option duplique le mail vers une > autre boite ce qui n'est pas exactement mon objectif (rendant le rejeu > laborieux) Avec formail (qui fait partie de procmail) et un always_bcc vers un Maildir, c'est assez trivial d'archiver et expirer automatiquement (find . -type f -mtime +7d -delete, par exemple). > Si quelqu'un a une idée voir même une solution je suis plus que preneur. Comme décrit ci-dessous, sinon un quelconque filtre milter devrait faire l'affaire (ou un content_filter à la amavisd avec deux smtpd (un pre-filter, un post-filter, mais c'est plus de boulot et IO/2) http://www.findbestopensource.com/product/milter-archiver "Rejouer" est le mot clé. P. --- Liste de diffusion du FRnOG http://www.frnog.org/
RE: [FRnOG] [ALERT] domaine.fr HS
+1 -Message d'origine- De : frnog-requ...@frnog.org De la part de Alexandre Tran Envoyé : vendredi 4 janvier 2019 18:16 À : frnog-al...@frnog.org Objet : [FRnOG] [ALERT] domaine.fr HS Bonjour, Quelqu'un de la liste rencontre des soucis chez l'hébergeur domaine.fr? leur site .biz et .info sont hackés apparement, impossible de faire une résolution sur les domaines hébergés chez eux Alex --- Liste de diffusion du FRnOG http://www.frnog.org/ smime.p7s Description: S/MIME cryptographic signature
RE: [FRnOG] [TECH] problème pour délivrer des emails vers protection.outlook.com
A priori plein d’adresses Exemple : 104.47.10.36 104.47.1.36 104.47.6.36 104.47.14.36 104.47.9.36 104.47.25.36 …. Jacques De : David Ponzone [mailto:david.ponz...@gmail.com] Envoyé : mardi 25 février 2020 16:08 À : DELMAS JACQUES Cc : frnog-t...@frnog.org Objet : Re: [FRnOG] [TECH] problème pour délivrer des emails vers protection.outlook.com Ca aiderait si tu nous donnais des IP chez MS qui t’ont répondu ça :) Pour ma part, aucun problème de chez nous vers outlook.com<http://outlook.com> Le 25 févr. 2020 à 16:01, DELMAS JACQUES mailto:jacques.del...@univ-lyon1.fr>> a écrit : Bonjour, Nous n'arrivons plus à envoyer de mails vers les serveurs de Microsoft depuis 11h20 aujourd'hui. Leurs serveurs nous répondent 451 4.7.500 A priori cela veut dire que leurs serveurs sont saturés mais de manière aussi longue cela me surprend J'ai vérifié sur leur SNDS RAS sur nos IPs. Je suis le seul dans ce cas ? Merci Jacques --- Liste de diffusion du FRnOG http://www.frnog.org/ --- Liste de diffusion du FRnOG http://www.frnog.org/
RE: [FRnOG] [TECH] problème pour délivrer des emails vers protection.outlook.com
Tout est passé d’un seul coup …. 400 mails en 1 minute . (Va comprendre). Jacques De : David Ponzone [mailto:david.ponz...@gmail.com] Envoyé : mardi 25 février 2020 16:42 À : DELMAS JACQUES Cc : frnog-t...@frnog.org Objet : Re: [FRnOG] [TECH] problème pour délivrer des emails vers protection.outlook.com Et un exemple de domaine client, car chez MS, tous les MX n’acceptent pas de mail pour tous leurs clients. Le 25 févr. 2020 à 16:36, DELMAS JACQUES mailto:jacques.del...@univ-lyon1.fr>> a écrit : A priori plein d’adresses Exemple : 104.47.10.36 104.47.1.36 104.47.6.36 104.47.14.36 104.47.9.36 104.47.25.36 …. Jacques De : David Ponzone [mailto:david.ponz...@gmail.com] Envoyé : mardi 25 février 2020 16:08 À : DELMAS JACQUES mailto:jacques.del...@univ-lyon1.fr>> Cc : frnog-t...@frnog.org<mailto:frnog-t...@frnog.org> Objet : Re: [FRnOG] [TECH] problème pour délivrer des emails vers protection.outlook.com<http://protection.outlook.com/> Ca aiderait si tu nous donnais des IP chez MS qui t’ont répondu ça :) Pour ma part, aucun problème de chez nous vers outlook.com<http://outlook.com/> Le 25 févr. 2020 à 16:01, DELMAS JACQUES mailto:jacques.del...@univ-lyon1.fr>> a écrit : Bonjour, Nous n'arrivons plus à envoyer de mails vers les serveurs de Microsoft depuis 11h20 aujourd'hui. Leurs serveurs nous répondent 451 4.7.500 A priori cela veut dire que leurs serveurs sont saturés mais de manière aussi longue cela me surprend J'ai vérifié sur leur SNDS RAS sur nos IPs. Je suis le seul dans ce cas ? Merci Jacques --- Liste de diffusion du FRnOG http://www.frnog.org/ --- Liste de diffusion du FRnOG http://www.frnog.org/
[FRnOG] [TECH] problème pour délivrer des emails vers protection.outlook.com
Bonjour, Nous n'arrivons plus à envoyer de mails vers les serveurs de Microsoft depuis 11h20 aujourd'hui. Leurs serveurs nous répondent 451 4.7.500 A priori cela veut dire que leurs serveurs sont saturés mais de manière aussi longue cela me surprend J'ai vérifié sur leur SNDS RAS sur nos IPs. Je suis le seul dans ce cas ? Merci Jacques --- Liste de diffusion du FRnOG http://www.frnog.org/
[FRnOG] RE: [TECH] q-in-q n9k
Re, J'aime me répondre à moi-même ! Le SP-TAG c'est à priori le ethertype-QinQ donc jusque-là rien d'incohérent dans la doc hors mis ma manière de la lire Bonne soirée Jacques -Message d'origine- De : frnog-requ...@frnog.org [mailto:frnog-requ...@frnog.org] De la part de DELMAS JACQUES Envoyé : jeudi 25 juin 2020 12:23 À : frnog@frnog.org Objet : [FRnOG] [TECH] q-in-q n9k Bonjour à Chacun, Petite question sur la gestion du q-in-q dans les nexus n9k On peut lire dans la doc https://www.cisco.com/c/en/us/td/docs/switches/datacenter/nexus9000/sw/93x/interfaces/configuration/guide/b-cisco-nexus-9000-nx-os-interfaces-configuration-guide-93x/b-cisco-nexus-9000-nx-os-interfaces-configuration-guide-93x_chapter_01010.html Multiple selective Q-in-Q tags are not supported. That is, Q-in-Q does not support multiple SP tags on a single interface. Mais en même temps dans la doc il y a switch# sh run int e1/1 interface Ethernet1/1 switchport switchport mode trunk switchport trunk native vlan 2 switchport vlan mapping 3-400 dot1q-tunnel 400 switchport vlan mapping 401-800 dot1q-tunnel 401 switchport vlan mapping 801-1200 dot1q-tunnel 10 switchport vlan mapping 1201-1600 dot1q-tunnel 1400 switchport vlan mapping 1601-2000 dot1q-tunnel 9 switchport vlan mapping 2001-2400 dot1q-tunnel 3000 switchport vlan mapping 2401-2800 dot1q-tunnel 2099 switchport vlan mapping 2801-3200 dot1q-tunnel 2800 switchport vlan mapping 3201-3600 dot1q-tunnel 3967 switchport vlan mapping 3601-4000 dot1q-tunnel 600 switchport trunk allowed vlan 2,9-10,400-401,600,1400,2099,2800,3000,3967 En gros dans mon cas je voudrais (car non géré dans vmware) pouvoir balancer des vlans customers dans différents vlans opérateurs ... Si quelqu'un a un retour d'expérience sur le sujet ... Mon projet et de faire cela avec des nexus N9K-C9396PX en 9.3 Merci jacques --- Liste de diffusion du FRnOG http://www.frnog.org/ --- Liste de diffusion du FRnOG http://www.frnog.org/
[FRnOG] [TECH] q-in-q n9k
Bonjour à Chacun, Petite question sur la gestion du q-in-q dans les nexus n9k On peut lire dans la doc https://www.cisco.com/c/en/us/td/docs/switches/datacenter/nexus9000/sw/93x/interfaces/configuration/guide/b-cisco-nexus-9000-nx-os-interfaces-configuration-guide-93x/b-cisco-nexus-9000-nx-os-interfaces-configuration-guide-93x_chapter_01010.html Multiple selective Q-in-Q tags are not supported. That is, Q-in-Q does not support multiple SP tags on a single interface. Mais en même temps dans la doc il y a switch# sh run int e1/1 interface Ethernet1/1 switchport switchport mode trunk switchport trunk native vlan 2 switchport vlan mapping 3-400 dot1q-tunnel 400 switchport vlan mapping 401-800 dot1q-tunnel 401 switchport vlan mapping 801-1200 dot1q-tunnel 10 switchport vlan mapping 1201-1600 dot1q-tunnel 1400 switchport vlan mapping 1601-2000 dot1q-tunnel 9 switchport vlan mapping 2001-2400 dot1q-tunnel 3000 switchport vlan mapping 2401-2800 dot1q-tunnel 2099 switchport vlan mapping 2801-3200 dot1q-tunnel 2800 switchport vlan mapping 3201-3600 dot1q-tunnel 3967 switchport vlan mapping 3601-4000 dot1q-tunnel 600 switchport trunk allowed vlan 2,9-10,400-401,600,1400,2099,2800,3000,3967 En gros dans mon cas je voudrais (car non géré dans vmware) pouvoir balancer des vlans customers dans différents vlans opérateurs ... Si quelqu'un a un retour d'expérience sur le sujet ... Mon projet et de faire cela avec des nexus N9K-C9396PX en 9.3 Merci jacques --- Liste de diffusion du FRnOG http://www.frnog.org/
