Re: [FRnOG] [TECH] Problème EQUNIX GIX Paris
Erratum : Abos dynamiques,pas statiques :) Le jeu. 15 juin 2017 à 23:49, Pierre LANCASTRE a écrit : > +1 > J comprends toujours pas pourquoi ils mettent par défaut des timers si bas > (généralement 5 min) alors que les timers arp sont a 20 min par défaut. Et > baisser les timers arp est souvent une mauvaise idée. > Sur du vieux matos en cas de burst ca drop , limitations sur le arp > inspection Cisco par exemple,etc > Pour revenir au timer des tables de mac, ca peut aussi poser problème avec > du multicast. Déjà eu le cas avec des abos statiques vers des machines qui > ne faisaient que du arp toutes les 20 min. Au bout de 5 min, expiration des > mac adress --> flood des flux sur tous les ports du vlan. > Et généralement les switchs savent gèrer au moins 8k mac. Faut pas hésiter > à augmenter les timers :) > > --- > Pierre Lancastre > Ingénieur Réseaux et Sécurité > *-* SENSS - AS59798 *-* > +33 7 64 07 26 11 > > Le 15 juin 2017 21:47, "Raphael Mazelier" a écrit : > >> >> >> On 15/06/2017 19:57, footp...@gmail.com wrote: >> >>> Bonjour, >>> Mh, mais ces gens là ont bien des sessions BGP avec des routes connected >>> non ? >>> >>> Et du coup du traffic sourcé par leur port, au moins des ACK ? >>> >>> >> Lis le document. C'est très bien expliqué même si difficile à comprendre >> de prime abord. >> >> Le problème peut arriver si un peer A envoi du trafic à un autre peer B >> sans que A et B aient de sessions BGP (ils peerent juste avec les RS sinon >> en effet il y aurait un peu de traf BGP bi-directionnel) et que B utilise >> un autre path. Si A a un table ARP avec un timer un peu long (genre 4h) il >> connaît la mac de B pendant ce temps, pas la peine de faire de une requête >> ARP. Si le switch a un timer de mac-address-table inférieur (et c'est >> souvent le cas), pendant le delta, le switch n'a pas le choix et doit >> flooder. Comme personne ne lui répond il n'a aucun moyen de savoir comment >> associer la bonne mac au bon port. >> >> De la nécessité de mettre des pingers sur les IX (ce qui est peut être le >> cas je dis pas, c'est peu être autre chose). >> >> L'unknown unicast toujours un plaisir. (hein jph) >> J'ai eu des archis L2 bien flat ou j'avais jusqu'à 1Gbps ce qui m'a un >> peu obligé à revoir mes timers :) >> >> -- >> Raphael Mazelier >> >> >> --- >> Liste de diffusion du FRnOG >> http://www.frnog.org/ >> > -- Cordialement / Best regards Pierre Lancastre Ingénieur Réseaux et Sécurité *-* SENSS - AS59798 *-* +33 7 64 07 26 11 --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Problème EQUNIX GIX Paris
+1 J comprends toujours pas pourquoi ils mettent par défaut des timers si bas (généralement 5 min) alors que les timers arp sont a 20 min par défaut. Et baisser les timers arp est souvent une mauvaise idée. Sur du vieux matos en cas de burst ca drop , limitations sur le arp inspection Cisco par exemple,etc Pour revenir au timer des tables de mac, ca peut aussi poser problème avec du multicast. Déjà eu le cas avec des abos statiques vers des machines qui ne faisaient que du arp toutes les 20 min. Au bout de 5 min, expiration des mac adress --> flood des flux sur tous les ports du vlan. Et généralement les switchs savent gèrer au moins 8k mac. Faut pas hésiter à augmenter les timers :) --- Pierre Lancastre Ingénieur Réseaux et Sécurité *-* SENSS - AS59798 *-* +33 7 64 07 26 11 Le 15 juin 2017 21:47, "Raphael Mazelier" a écrit : > > > On 15/06/2017 19:57, footp...@gmail.com wrote: > >> Bonjour, >> Mh, mais ces gens là ont bien des sessions BGP avec des routes connected >> non ? >> >> Et du coup du traffic sourcé par leur port, au moins des ACK ? >> >> > Lis le document. C'est très bien expliqué même si difficile à comprendre > de prime abord. > > Le problème peut arriver si un peer A envoi du trafic à un autre peer B > sans que A et B aient de sessions BGP (ils peerent juste avec les RS sinon > en effet il y aurait un peu de traf BGP bi-directionnel) et que B utilise > un autre path. Si A a un table ARP avec un timer un peu long (genre 4h) il > connaît la mac de B pendant ce temps, pas la peine de faire de une requête > ARP. Si le switch a un timer de mac-address-table inférieur (et c'est > souvent le cas), pendant le delta, le switch n'a pas le choix et doit > flooder. Comme personne ne lui répond il n'a aucun moyen de savoir comment > associer la bonne mac au bon port. > > De la nécessité de mettre des pingers sur les IX (ce qui est peut être le > cas je dis pas, c'est peu être autre chose). > > L'unknown unicast toujours un plaisir. (hein jph) > J'ai eu des archis L2 bien flat ou j'avais jusqu'à 1Gbps ce qui m'a un peu > obligé à revoir mes timers :) > > -- > Raphael Mazelier > > > --- > Liste de diffusion du FRnOG > http://www.frnog.org/ > --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Problème EQUNIX GIX Paris
On 15/06/2017 19:57, footp...@gmail.com wrote: Bonjour, Mh, mais ces gens là ont bien des sessions BGP avec des routes connected non ? Et du coup du traffic sourcé par leur port, au moins des ACK ? Lis le document. C'est très bien expliqué même si difficile à comprendre de prime abord. Le problème peut arriver si un peer A envoi du trafic à un autre peer B sans que A et B aient de sessions BGP (ils peerent juste avec les RS sinon en effet il y aurait un peu de traf BGP bi-directionnel) et que B utilise un autre path. Si A a un table ARP avec un timer un peu long (genre 4h) il connaît la mac de B pendant ce temps, pas la peine de faire de une requête ARP. Si le switch a un timer de mac-address-table inférieur (et c'est souvent le cas), pendant le delta, le switch n'a pas le choix et doit flooder. Comme personne ne lui répond il n'a aucun moyen de savoir comment associer la bonne mac au bon port. De la nécessité de mettre des pingers sur les IX (ce qui est peut être le cas je dis pas, c'est peu être autre chose). L'unknown unicast toujours un plaisir. (hein jph) J'ai eu des archis L2 bien flat ou j'avais jusqu'à 1Gbps ce qui m'a un peu obligé à revoir mes timers :) -- Raphael Mazelier --- Liste de diffusion du FRnOG http://www.frnog.org/
RE: [FRnOG] [TECH] Problème EQUNIX GIX Paris
>> Arnaud Turpin a écrit : >> Nous avons un comportement bizarre sur le GIX Equinix PA2. >> On reçoit du traffic 20/30 Mbps qui ne nous concerne pas, vous avez aussi le >> même problème ? > Jean-Philippe a écrit : > Ca ne ressemblerait pas à un problème de Unknown Unicast, a cause d'un trafic > asymétrique. > Le 'switch' n'ayant plus la correspondance de la mac de destination ( de > 195.42.145.60 > ou 195.42.145.63 ) avec un port précis, il forward sur tous les ports du Vlan. Des fois aussi le switch se mélange les pinceaux entre plusieurs VLANs; çà fait longtemps que j'ai pas vu, mais c'est pas impossible. Comme suggéré avant : il faut savoir de quelle MAC adresse çà vient. Michel. --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Problème EQUNIX GIX Paris
Bonjour, > Le 15 juin 2017 à 17:24, Jean-Philippe a écrit : > > > Ca ne ressemblerait pas à un problème de Unknown Unicast, a cause d'un trafic > asymétrique. > > Le 'switch' n'ayant plus la correspondance de la mac de destination ( de > 195.42.145.60 ou 195.42.145.63 ) avec un port précis, il forward sur tous les > ports du Vlan. > Mh, mais ces gens là ont bien des sessions BGP avec des routes connected non ? Et du coup du traffic sourcé par leur port, au moins des ACK ? Cordialement, -- Aurélien --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Problème EQUNIX GIX Paris
Hello, Ca ne ressemblerait pas à un problème de Unknown Unicast, a cause d'un trafic asymétrique. Le 'switch' n'ayant plus la correspondance de la mac de destination ( de 195.42.145.60 ou 195.42.145.63 ) avec un port précis, il forward sur tous les ports du Vlan. Il me semble que ce souci arrive particulièrement sur Equinix-IX avec des paquets aller via Equinix-X et retour via franceIX. Certains IX ont des serveurs qui génèrent continuellement des ping vers tous le subnet d'interco de peers pour garder la connaissance de chaque MAC/PORT D'ailleurs : https://fr.slideshare.net/apnic/unknown-unicast-traffic-and-ping-pollers ++ JPh Le 15/06/2017 à 14:48, David Ponzone a écrit : Oui j’ai comme toi, je vois du traffic Unicast vers des MAC/IP qui ne sont pas à nous. Comme adresse MAC destination, j’ai celles qui correspondent à 195.42.145.60 ou 195.42.145.63 et d’autres. Quelqu’un a activé le mode hub sur le switch d’Equinix-IX ? Le 15 juin 2017 à 13:31, Arnaud Turpin a écrit : Bonjour Nous avons un comportement bizarre sur le GIX Equinix PA2. On reçoit du traffic 20/30 Mbps qui ne nous concerne pas, vous avez aussi le même problème ? Date first seen Duration Proto Src IP Addr:Port Dst IP Addr:Port PacketsBytes Flows 2017-06-15 13:12:45.396 106.772 TCP 193.55.120.26:80-> 146.255.174.94:54206 531500 27.8 M 1 2017-06-15 13:14:21.116 0.000 UDP 172.217.19.229:443 -> 146.255.170.154:64428 100 6200 1 2017-06-15 13:14:21.314 0.000 TCP 193.109.81.33:3101 -> 156.133.50.177:56905 100 4000 1 2017-06-15 13:14:21.388 0.000 TCP 195.42.145.141:179 -> 195.42.144.104:8163 100 4000 1 2017-06-15 13:12:41.265 107.036 TCP37.59.11.22:56097 -> 146.255.174.146:61774291001.2 M 1 2017-06-15 13:14:21.570 0.000 TCP 66.249.93.222:44218 -> 146.255.171.73:80 100 5200 1 2017-06-15 13:14:21.611 0.000 TCP 173.194.76.154:443 -> 46.21.116.98:60648 100 5200 1 2017-06-15 13:14:21.673 0.000 UDP 193.93.124.21:161 -> 194.117.246.80:42671 10026700 1 2017-06-15 13:14:19.371 2.385 TCP 176.142.138.17:54706 -> 146.255.171.81:44320011600 1 2017-06-15 13:14:21.886 0.000 TCP 80.214.79.207:12212 -> 146.255.171.160:80 100 4000 1 2017-06-15 13:14:22.084 0.000 TCP 77.154.204.154:23207 -> 212.63.232.97:443100 4000 1 2017-06-15 13:14:22.545 0.000 TCP 80.214.79.207:12211 -> 146.255.171.160:80 100 4000 1 2017-06-15 13:14:22.964 0.000 TCP 80.248.212.200:8786 -> 81.92.116.8:80 100 15 1 2017-06-15 13:14:23.074 0.000 TCP 81.244.211.43:3912 -> 81.92.115.138:80 100 4000 1 2017-06-15 13:14:17.98410.915 UDP 172.217.19.227:443 -> 146.255.175.209:57874 1000 949600 1 2017-06-15 13:14:23.445 0.000 TCP5.49.206.58:53642 -> 81.92.115.206:80 100 5200 1 2017-06-15 13:14:23.665 0.000 TCP 91.197.232.109:39200 -> 194.117.247.183:22 100 6000 1 2017-06-15 13:14:23.668 0.000 TCP 91.197.232.109:59423 -> 194.117.247.185:22 100 6000 1 2017-06-15 13:14:23.864 0.000 TCP 216.58.213.131:443 -> 85.115.60.201:44881 100 147000 1 2017-06-15 13:14:23.974 0.000 TCP 89.91.30.153:56036 -> 146.255.170.114:62112 100 5200 1 2017-06-15 13:14:23.977 0.000 TCP 188.125.80.144:443 -> 146.255.174.70:62812 10015700 1 2017-06-15 13:14:24.071 0.000 TCP 195.42.144.98:179 -> 195.42.145.141:55921 100 6700 1 2017-06-15 13:14:24.526 0.089 TCP 178.33.22.97:443 -> 146.255.175.135:58371 200 298000 1 2017-06-15 13:14:24.704 0.000 TCP 89.91.82.228:60085 -> 217.70.184.11:143100 146000 1 2017-06-15 13:14:24.919 0.000 TCP 216.58.201.234:80-> 46.21.116.98:60743 10019900 1 2017-06-15 13:14:25.147 0.000 TCP 37.187.132.217:443 -> 146.255.174.70:17833 100 142000 1 2017-06-15 13:14:25.166 0.000 TCP 176.163.36.227:50635 -> 193.25.198.218:80 10035900 1 2017-06-15 13:14:25.334 0.000 TCP176.151.239.150:53321 -> 217.70.180.135:80 100 5200 1 2017-06-15 13:14:25.774 0.000 TCP 54.192.77.157:443 -> 185.11.160.0:4481 100 148000 1 2017-06-15 13:10:17.636 291.876 TCP 178.33.71.43:1935 -> 146.255.174.104:41246 5500 902900 1 2017-06-15 13:14:26.02723.615 TCP 80.215.11.111:42514 -> 213.215.28.11:993 2200 154500 1 2017-06-15 13:14:26.18014.501 TCP 80.169.233.26:443 -> 185.3.44.201:20910 200 103600 1 2017-06-15 13:14:26.290 0.000 UDP 176.155.54.4
Re: [FRnOG] [TECH] Problème EQUNIX GIX Paris
Hello, J'ai eu ce truc là sur Equinix Ashburn il y a 7 mois avec du traffic qui ne correspondais pas a l'AS de mon taf-1 (ni les IP). Ces infos étaient remontées via mes collecteurs netflow et confirmées via les graphes librenms. Je n'ai jamais su pourquoi, mais c'est soit un switch qui s'est tranformé en hub soit autre chose... Xavier --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Problème EQUNIX GIX Paris
Oui j’ai comme toi, je vois du traffic Unicast vers des MAC/IP qui ne sont pas à nous. Comme adresse MAC destination, j’ai celles qui correspondent à 195.42.145.60 ou 195.42.145.63 et d’autres. Quelqu’un a activé le mode hub sur le switch d’Equinix-IX ? > Le 15 juin 2017 à 13:31, Arnaud Turpin a écrit : > > Bonjour > > Nous avons un comportement bizarre sur le GIX Equinix PA2. > On reçoit du traffic 20/30 Mbps qui ne nous concerne pas, vous avez aussi le > même problème ? > > > Date first seen Duration Proto Src IP Addr:Port Dst IP > Addr:Port PacketsBytes Flows > 2017-06-15 13:12:45.396 106.772 TCP 193.55.120.26:80-> > 146.255.174.94:54206 531500 27.8 M 1 > 2017-06-15 13:14:21.116 0.000 UDP 172.217.19.229:443 -> > 146.255.170.154:64428 100 6200 1 > 2017-06-15 13:14:21.314 0.000 TCP 193.109.81.33:3101 -> > 156.133.50.177:56905 100 4000 1 > 2017-06-15 13:14:21.388 0.000 TCP 195.42.145.141:179 -> > 195.42.144.104:8163 100 4000 1 > 2017-06-15 13:12:41.265 107.036 TCP37.59.11.22:56097 -> > 146.255.174.146:61774291001.2 M 1 > 2017-06-15 13:14:21.570 0.000 TCP 66.249.93.222:44218 -> > 146.255.171.73:80 100 5200 1 > 2017-06-15 13:14:21.611 0.000 TCP 173.194.76.154:443 -> > 46.21.116.98:60648 100 5200 1 > 2017-06-15 13:14:21.673 0.000 UDP 193.93.124.21:161 -> > 194.117.246.80:42671 10026700 1 > 2017-06-15 13:14:19.371 2.385 TCP 176.142.138.17:54706 -> > 146.255.171.81:44320011600 1 > 2017-06-15 13:14:21.886 0.000 TCP 80.214.79.207:12212 -> > 146.255.171.160:80 100 4000 1 > 2017-06-15 13:14:22.084 0.000 TCP 77.154.204.154:23207 -> > 212.63.232.97:443100 4000 1 > 2017-06-15 13:14:22.545 0.000 TCP 80.214.79.207:12211 -> > 146.255.171.160:80 100 4000 1 > 2017-06-15 13:14:22.964 0.000 TCP 80.248.212.200:8786 -> > 81.92.116.8:80 100 15 1 > 2017-06-15 13:14:23.074 0.000 TCP 81.244.211.43:3912 -> > 81.92.115.138:80 100 4000 1 > 2017-06-15 13:14:17.98410.915 UDP 172.217.19.227:443 -> > 146.255.175.209:57874 1000 949600 1 > 2017-06-15 13:14:23.445 0.000 TCP5.49.206.58:53642 -> > 81.92.115.206:80 100 5200 1 > 2017-06-15 13:14:23.665 0.000 TCP 91.197.232.109:39200 -> > 194.117.247.183:22 100 6000 1 > 2017-06-15 13:14:23.668 0.000 TCP 91.197.232.109:59423 -> > 194.117.247.185:22 100 6000 1 > 2017-06-15 13:14:23.864 0.000 TCP 216.58.213.131:443 -> > 85.115.60.201:44881 100 147000 1 > 2017-06-15 13:14:23.974 0.000 TCP 89.91.30.153:56036 -> > 146.255.170.114:62112 100 5200 1 > 2017-06-15 13:14:23.977 0.000 TCP 188.125.80.144:443 -> > 146.255.174.70:62812 10015700 1 > 2017-06-15 13:14:24.071 0.000 TCP 195.42.144.98:179 -> > 195.42.145.141:55921 100 6700 1 > 2017-06-15 13:14:24.526 0.089 TCP 178.33.22.97:443 -> > 146.255.175.135:58371 200 298000 1 > 2017-06-15 13:14:24.704 0.000 TCP 89.91.82.228:60085 -> > 217.70.184.11:143100 146000 1 > 2017-06-15 13:14:24.919 0.000 TCP 216.58.201.234:80-> > 46.21.116.98:60743 10019900 1 > 2017-06-15 13:14:25.147 0.000 TCP 37.187.132.217:443 -> > 146.255.174.70:17833 100 142000 1 > 2017-06-15 13:14:25.166 0.000 TCP 176.163.36.227:50635 -> > 193.25.198.218:80 10035900 1 > 2017-06-15 13:14:25.334 0.000 TCP176.151.239.150:53321 -> > 217.70.180.135:80 100 5200 1 > 2017-06-15 13:14:25.774 0.000 TCP 54.192.77.157:443 -> > 185.11.160.0:4481 100 148000 1 > 2017-06-15 13:10:17.636 291.876 TCP 178.33.71.43:1935 -> > 146.255.174.104:41246 5500 902900 1 > 2017-06-15 13:14:26.02723.615 TCP 80.215.11.111:42514 -> > 213.215.28.11:993 2200 154500 1 > 2017-06-15 13:14:26.18014.501 TCP 80.169.233.26:443 -> > 185.3.44.201:20910 200 103600 1 > 2017-06-15 13:14:26.290 0.000 UDP 176.155.54.49:61117 -> > 146.255.170.154:49484 100 3800 1 > > > + > Arnaud > > --- > Liste de diffusion du FRnOG > http://www.frnog.org/ --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Problème EQUNIX GIX Paris
Tu as la MAC source ? > Le 15 juin 2017 à 13:31, Arnaud Turpin a écrit : > > Bonjour > > Nous avons un comportement bizarre sur le GIX Equinix PA2. > On reçoit du traffic 20/30 Mbps qui ne nous concerne pas, vous avez aussi le > même problème ? > > > Date first seen Duration Proto Src IP Addr:Port Dst IP > Addr:Port PacketsBytes Flows > 2017-06-15 13:12:45.396 106.772 TCP 193.55.120.26:80-> > 146.255.174.94:54206 531500 27.8 M 1 > 2017-06-15 13:14:21.116 0.000 UDP 172.217.19.229:443 -> > 146.255.170.154:64428 100 6200 1 > 2017-06-15 13:14:21.314 0.000 TCP 193.109.81.33:3101 -> > 156.133.50.177:56905 100 4000 1 > 2017-06-15 13:14:21.388 0.000 TCP 195.42.145.141:179 -> > 195.42.144.104:8163 100 4000 1 > 2017-06-15 13:12:41.265 107.036 TCP37.59.11.22:56097 -> > 146.255.174.146:61774291001.2 M 1 > 2017-06-15 13:14:21.570 0.000 TCP 66.249.93.222:44218 -> > 146.255.171.73:80 100 5200 1 > 2017-06-15 13:14:21.611 0.000 TCP 173.194.76.154:443 -> > 46.21.116.98:60648 100 5200 1 > 2017-06-15 13:14:21.673 0.000 UDP 193.93.124.21:161 -> > 194.117.246.80:42671 10026700 1 > 2017-06-15 13:14:19.371 2.385 TCP 176.142.138.17:54706 -> > 146.255.171.81:44320011600 1 > 2017-06-15 13:14:21.886 0.000 TCP 80.214.79.207:12212 -> > 146.255.171.160:80 100 4000 1 > 2017-06-15 13:14:22.084 0.000 TCP 77.154.204.154:23207 -> > 212.63.232.97:443100 4000 1 > 2017-06-15 13:14:22.545 0.000 TCP 80.214.79.207:12211 -> > 146.255.171.160:80 100 4000 1 > 2017-06-15 13:14:22.964 0.000 TCP 80.248.212.200:8786 -> > 81.92.116.8:80 100 15 1 > 2017-06-15 13:14:23.074 0.000 TCP 81.244.211.43:3912 -> > 81.92.115.138:80 100 4000 1 > 2017-06-15 13:14:17.98410.915 UDP 172.217.19.227:443 -> > 146.255.175.209:57874 1000 949600 1 > 2017-06-15 13:14:23.445 0.000 TCP5.49.206.58:53642 -> > 81.92.115.206:80 100 5200 1 > 2017-06-15 13:14:23.665 0.000 TCP 91.197.232.109:39200 -> > 194.117.247.183:22 100 6000 1 > 2017-06-15 13:14:23.668 0.000 TCP 91.197.232.109:59423 -> > 194.117.247.185:22 100 6000 1 > 2017-06-15 13:14:23.864 0.000 TCP 216.58.213.131:443 -> > 85.115.60.201:44881 100 147000 1 > 2017-06-15 13:14:23.974 0.000 TCP 89.91.30.153:56036 -> > 146.255.170.114:62112 100 5200 1 > 2017-06-15 13:14:23.977 0.000 TCP 188.125.80.144:443 -> > 146.255.174.70:62812 10015700 1 > 2017-06-15 13:14:24.071 0.000 TCP 195.42.144.98:179 -> > 195.42.145.141:55921 100 6700 1 > 2017-06-15 13:14:24.526 0.089 TCP 178.33.22.97:443 -> > 146.255.175.135:58371 200 298000 1 > 2017-06-15 13:14:24.704 0.000 TCP 89.91.82.228:60085 -> > 217.70.184.11:143100 146000 1 > 2017-06-15 13:14:24.919 0.000 TCP 216.58.201.234:80-> > 46.21.116.98:60743 10019900 1 > 2017-06-15 13:14:25.147 0.000 TCP 37.187.132.217:443 -> > 146.255.174.70:17833 100 142000 1 > 2017-06-15 13:14:25.166 0.000 TCP 176.163.36.227:50635 -> > 193.25.198.218:80 10035900 1 > 2017-06-15 13:14:25.334 0.000 TCP176.151.239.150:53321 -> > 217.70.180.135:80 100 5200 1 > 2017-06-15 13:14:25.774 0.000 TCP 54.192.77.157:443 -> > 185.11.160.0:4481 100 148000 1 > 2017-06-15 13:10:17.636 291.876 TCP 178.33.71.43:1935 -> > 146.255.174.104:41246 5500 902900 1 > 2017-06-15 13:14:26.02723.615 TCP 80.215.11.111:42514 -> > 213.215.28.11:993 2200 154500 1 > 2017-06-15 13:14:26.18014.501 TCP 80.169.233.26:443 -> > 185.3.44.201:20910 200 103600 1 > 2017-06-15 13:14:26.290 0.000 UDP 176.155.54.49:61117 -> > 146.255.170.154:49484 100 3800 1 > > > + > Arnaud > > --- > Liste de diffusion du FRnOG > http://www.frnog.org/ --- Liste de diffusion du FRnOG http://www.frnog.org/