Re: [FRnOG] [TECH] Problème EQUNIX GIX Paris

2017-06-15 Par sujet Pierre LANCASTRE
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

2017-06-15 Par sujet Pierre LANCASTRE
+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

2017-06-15 Par sujet Raphael Mazelier



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

2017-06-15 Par sujet Michel Py
>> 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

2017-06-15 Par sujet footplus
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

2017-06-15 Par sujet Jean-Philippe

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 

Re: [FRnOG] [TECH] Problème EQUNIX GIX Paris

2017-06-15 Par sujet Xavier Beaudouin
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

2017-06-15 Par sujet David Ponzone
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

2017-06-15 Par sujet David Ponzone
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/