Re: [FRnOG] Re: [ALERT] impots.gouv.fr / AS 34177 (Celeste)

[jehan procaccia INT]

aie, on serait attaqués ... hier dans paris on a reçu de maniere 
simultané "une alerte extrement grave" à propos du perimetre des JO


on aurai pu croire a une attaque , mais apparement c'est volontaire:

https://rmcsport.bfmtv.com/jeux-olympiques/securite/alerte-extremement-grave-un-message-fr-alert-envoye-sur-des-telephones-a-paris_AN-202405130849.html

A propos des DNS impots.gouv.fr ce n'est pas le moment qu'ils se 
plantent, je suis surpris qu'ils ne soient hebergés que dans un seul AS 
d'operateur privé . Cela ne depend pas de la DINUM les services 
numeriques des impots ? une université ou centre de recherche public ne 
pourrait pas etre secondaire !?


On 13/05/2024 16:55, Stephane Bortzmeyer wrote:

On Mon, May 13, 2024 at 08:42:46AM +0200,
  Stephane Bortzmeyer  wrote
  a message of 34 lines which said:


Depuis hier soir (signalements en


), impots.gouv.fr a un
problème DNS (les résolveurs renvoient SERVFAIL). Vu que cela
n'affecte qu'une partie des opérateurs français

Le problème semble fini. L'examen des mesures Atlas n'indique pas un
problème lié à certains AS (chez les BOFS, des sondes y arrivent et
d'autres pas) donc je penche plutôt maintenant pour une attaque par
déni de service.


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

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

Re: [FRnOG] [MISC] Fwd: France-IX launches its new Transit IP service!

[jehan procaccia INT]

​merci pour les retours publics sur la liste et les privés,
j'ai maintenant une bien meilleure idée des tarifs courants de transit .
je pense donc etre dans des conditions relativement correctes,
je fais du BGP4 sans burst (car 1G sur port 1G) avec en // un peering 
FranceIX, a mon avis pas optimisé car je peer qu'avec les Route Servers.
je n'ai pas encore essayé de faire du peering pair a pair chez eux, je 
ne sais pas comment aborder les peers pour ce genre de ralation billaterales

et est-ce que ça vaut le coup et avec lesquels ?

jehan

On 16/03/2024 18:34, David Ponzone wrote:

Et si je peux me permettre d’ajouter 2/3 trucs:

-tu ne précises pas si c’est du transit « classique » ou BGP4. Si BGP4, alors 
en fonction du type de traffic, il pourrait être intéressant d’aller chercher 
du peering. C’est pas forcément moins cher de nos jours, mais c’est meilleur en 
qualité, c’est plus facile de gérer les pics, et comme c’est parfois 50% du 
trafic, ça fait un peu de redondance sur le trucs importants (Google, AWS, 
Netflix, Apple, Microsoft, FB, Akamai,….tout ça quoi)

-faut voir aussi le prix du burst. Certains transits ont un tarif outrageux dès 
qu’on dépasse le commit. La norme de nos jours est d’avoir un prix du Mbps 
over-commit égal au prix under-commit (0,5€/Mbps dans ton cas)

Comme Jérôme, à 500€ le 1G, j’irais pas chercher à faire baisser, on rentre en 
zone grise. Sauf si tu passes sur un commit plus gros (certains transits se 
mettent en slip pour te vendre un port 10G, je donne pas de nom, tout le monde 
le connaît, c’est un vrai ouragan commercial…ah merde...)

David


Le 16 mars 2024 à 17:58, Jérôme Nicolle  a écrit :

Salut Jehan,

Sujet intéressant mais opaque et complexe.

En fonction des volumes et des options (anti-ddos, allocations de blocs, 
sessions eBGP multihop pour le RTBH…) en France métropolitaine tu vas être 
entre 0,1 et 3€/Mbps (commit mini 1G, 'faut pas déconner). Attention, si tu 
payes des cacahuètes t'as souvent du transit de qualité discutable. Genre juste 
la moitié du monde IPv6.

En APAC ou dans les îles d'Outre-Mer, t'es plutôt à entre 3 et 15€/Mbps, parce 
que comme Pierre-Yves l'a très bien expliqué dans ses deux dernières 
présentations au FRnOG, les câbles sous-marins, c'est chiant.

Le 13/03/2024 à 21:34, jehan procaccia INT a écrit :

j'aimerai savoir quand notre contrat va arriver a terme s'il faut chercher 
ailleurs/renegocier, ou si finalement les prix sont uniformes sur la place 
parisienne (DC3) par exemple aujourd'hui je suis a 500€ HT pour 1G, est-ce 
normal ou je me fais avoir ...? quelle est la tendance ?

T'es dans les clous à ce prix là, pour une qualité moyenne à bonne. Si tu 
essayes de raboter là dessus je penses que tu vas commencer à taper dans le 
mauvais - en tout cas pour certains trafics.

Et franchement sur DC3 tu vas avoir deux voire trois acteurs qui se démarquent 
sur le qualitatif ET le prix pour du trafic francophone. Pas besoin de chercher 
loin.

@+

--
Jérôme Nicolle
+33 6 19 31 27 14
+590 690 22 87 14


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



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

Re: [FRnOG] [MISC] Fwd: France-IX launches its new Transit IP service!

[jehan procaccia INT]

Bonsoir

je rebondis sur cet ancien thread

je suis peut-être naïf , mais pourquoi est-ce si difficile de connaitre 
le prix du transit IP , chaque fournisseur fait à la tête du client ?


s'il existe qq part un "catalogue" de prix , même grossier/moyen des 
prix du transit IP en France, je suis preneur .


j'aimerai savoir quand notre contrat va arriver a terme s'il faut 
chercher ailleurs/renegocier, ou si finalement les prix sont uniformes 
sur la place parisienne (DC3) par exemple aujourd'hui je suis a 500€ HT 
pour 1G, est-ce normal ou je me fais avoir ...? quelle est la tendance ?


Merci

PS: l'info FranceIX ci-dessous, me donne deja une idée de l'etat des lieux

La bonne reference de l'epoque, mais  il y a 10 ans : 
https://drpeering.net/white-papers/Internet-Transit-Pricing-Historical-And-Projected.php


un hebergeur qui affiche son catalogue: 
https://www.nforce.com/IP-Transit/IP-Transit-starting-at-135.00-euro-Per-1-month/24


avez vous mieux ?


On 30/06/2023 20:53, Titouan Planson Jeullain wrote:

Bonsoir,

Aux dernières nouvelles, les tarifs sont les suivants :
- 500 Mbps> 120 € /mois.
- 1G --> 221 € /mois.
Des FAS s’ajoutent aussi de mémoire.


Titouan


On 30 Jun 2023, at 8:24 PM, Raphael Mazelier  wrote:

On 30/06/2023 20:04, Hugues Voiturier wrote:

Avant France-IX te tirait un vlan vers Orange, maintenant ils ont carrément un 
AS dédié au transit IP avec Orange en uplink.

ah oui c'est très différent en effet. Je serais curieux des tarifs tiens.

--
Raphael Mazelier


---
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] Re: ACL check

[jehan procaccia INT]

le premier marche sur Apple :-(

le second semble repondre tres bien au besoin, mais effectivement .exe 
Windows et from .ru


ça fait flipper de lui donner a manger nos regles

j'espere encore autre chose ... quitte a demander a Cisco, je reste 
surpris qu'il n'y ait pas ça sur etagere !?


On 13/12/2023 19:41, David Ponzone wrote:

https://apps.apple.com/fr/app/network-mom-acl-analyzer/id1472093792?mt=12

https://aclcheck.ru/en/

Pour le second, comme c’est un EXE Windows, faudrait peut-être le 
tester dans une sandbox….



Le 13 déc. 2023 à 18:51, jehan procaccia INT 
 a écrit :


Bonjour

je reviens sur cette vielle recherche [1] d'outils de 
verificationqu'un trafic match ou pas une ACL cisco .


le "Access List Checker" de cisco est maintenant "/Retired and 
Decommissioned/"


https://www.cisco.com/c/en/us/support/web/retired-tools.html

est-ce que qq'un entre temps aurait trouvé/developpé un "checker" d'ACL ?

Merci .


On 17/05/2019 18:28, jehan procaccia INT wrote:

Bonjour,

je cherche un outil afin de verifier quelle ACE d'une ACL cisco 
match un patern de trafic


bref a verifier le bon fonctionnement de mon ACL !

il y a bien des outils en ligne

http://www.netfishers.onl/armp

https://cway.cisco.com/tools/accesslist/

http://acl.frenzy.cz/

mais je n'ai pas necessairement confiance ...

j'aimerai plutot un outil qui tourne localement sur ma machine

j'ai bien trouvé https://code.google.com/archive/p/acl-check/ a 
compiler sois meme, mais les sources ne sont plus disponibles :-( .


connaissez vous un equivalent ?

Merci



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



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

[FRnOG] [TECH] Re: ACL check

[jehan procaccia INT]

Bonjour

je reviens sur cette vielle recherche [1] d'outils de verificationqu'un 
trafic match ou pas une ACL cisco .


le "Access List Checker" de cisco est maintenant "/Retired and 
Decommissioned/"


https://www.cisco.com/c/en/us/support/web/retired-tools.html

est-ce que qq'un entre temps aurait trouvé/developpé un "checker" d'ACL ?

Merci .


On 17/05/2019 18:28, jehan procaccia INT wrote:

Bonjour,

je cherche un outil afin de verifier quelle ACE d'une ACL cisco match 
un patern de trafic


bref a verifier le bon fonctionnement de mon ACL !

il y a bien des outils en ligne

http://www.netfishers.onl/armp

https://cway.cisco.com/tools/accesslist/

http://acl.frenzy.cz/

mais je n'ai pas necessairement confiance ...

j'aimerai plutot un outil qui tourne localement sur ma machine

j'ai bien trouvé https://code.google.com/archive/p/acl-check/ a 
compiler sois meme, mais les sources ne sont plus disponibles :-( .


connaissez vous un equivalent ?

Merci



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

[FRnOG] [ALERT] http SD* et cisco CVE-2023-20198

[jehan procaccia INT]

Je m'interroge sur l'usage des interfaces [web|API|SD*]  prônées par les 
constructeurs


n'est-ce pas une exposition supplementaires majeure ? Ces outils (chez 
cisco DNA/Catalyst-center, SD-Acces/Wan ...)  utilisent-ils le service 
http/https ?


cf le CVE en cours qui semble faire de serieux degats :

https://www.it-connect.fr/cyberattaque-plus-de-34-000-equipements-cisco-pirates-avec-cette-nouvelle-faille-zero-day/

https://sec.cloudapps.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-iosxe-webui-privesc-j22SaA4z

https://blog.talosintelligence.com/active-exploitation-of-cisco-ios-xe-software/



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

Re: [FRnOG] [MISC] Reunion FRnOG 38 - EOL

[jehan procaccia INT]

Merci philippe

c'est effectivement bien pratique pour presenter rapidement le concept 
d'Open Networking , notament ici a nos etudiants


c'est bien en ligne sur: 
https://www.dailymotion.com/video/x8oshok?playlist=x7zxgw


On 12/10/2023 14:17, Philippe Bourcier wrote:

Bonjour,

En général, on ne publie pas les vidéos des sponsors, mais comme on me 
la demande, je m'occupe de la publier dans la soirée...



P.

October 12, 2023 10:50 AM, "jehan procaccia INT" 
 wrote:



Bonjour

je ne vois pas la presentation de Pine-networks / IP-infusion , la 
premiere dans la calendrier de

vendredi dernier

est-ce un oublie ou bien ils ne souhaitent pas diffuser ?

Merci

On 07/10/2023 19:27, Philippe Bourcier wrote:


Bonsoir,

Les vidéos et slides des présentations de la réunion FRnOG 38 d'hier 
sont disponibles ici :

- https://www.frnog.org/?page=meetings
- Videos : https://www.dailymotion.com/playlist/x7zxgw

Merci à tous les speakers et aux membres présents à cette réunion.

Pour ceux qui veulent savoir, l'inscription a 10€ a vraiment bien 
fonctionnée. On est passé de plus
de 30% de no-shows à moins de 20% (ce qui est un ratio dans la norme 
pour ce type d'event). On n'a
pas perdu en nombre de participants présents, au contraire. Bref, 
que du positif, donc ca passe en

prod.

Cordialement,
--
Philippe Bourcier
https://twitter.com/irukanji_invest
https://www.linkedin.com/in/philippebourcier

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


Cordialement,
--
Philippe Bourcier
https://twitter.com/irukanji_invest
https://www.linkedin.com/in/philippebourcier/


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



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

Re: [FRnOG] [MISC] Reunion FRnOG 38 - EOL

[jehan procaccia INT]

Bonjour

je ne vois pas la presentation de Pine-networks / IP-infusion , la 
premiere dans la calendrier de vendredi dernier


est-ce un oublie ou bien ils ne souhaitent pas diffuser ?

Merci

On 07/10/2023 19:27, Philippe Bourcier wrote:

Bonsoir,

Les vidéos et slides des présentations de la réunion FRnOG 38 d'hier sont 
disponibles ici :
  - https://www.frnog.org/?page=meetings
  - Videos : https://www.dailymotion.com/playlist/x7zxgw

Merci à tous les speakers et aux membres présents à cette réunion.

Pour ceux qui veulent savoir, l'inscription a 10€ a vraiment bien fonctionnée. 
On est passé de plus de 30% de no-shows à moins de 20% (ce qui est un ratio 
dans la norme pour ce type d'event). On n'a pas perdu en nombre de participants 
présents, au contraire. Bref, que du positif, donc ca passe en prod.


Cordialement,
--
Philippe Bourcier
https://twitter.com/irukanji_invest
https://www.linkedin.com/in/philippebourcier/


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



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

Re: [FRnOG] [TECH] FreeBox pro admin depuis le LAN

[jehan procaccia INT]

oui, d'autant plus qu'il y avait deja 2 tirroirs optiques d'anciennes 
offres FTTO dans l'appart (Ielo et SFR ou completel, je ne sais plus),  
meme l'ONT et le SFP etaient encore là .


Ielo dont je suis tres content par ailleurs sur d'autres sites, mais là 
le jour de l'emenagement ils ne prenaient pas en compte leur presence 
prealable et m'onnonçaient +3 mois d'installation de la fibre sans rien 
vouloir entendre de ce que je voyais . Donc on a pris celui qui degaine 
le plus vite et cela a été free (au moment où ils lançaient l'offre pro) 
, couvert par une livebox (ftth aussi) qq semaines apres, ce qui me 
permet de jongler sur les 2, mais je suis d'accord tout est question de 
rapport cout / qualité . Avec 2 ftth + secours 4G , on survit .


 c'est vendredi ...

On 29/09/2023 17:19, Quentin Leconte, SHPV via frnog wrote:

Bonsoir,

Vraie question, si vous êtes en plein Paris, il y a pléthore d’offres de 
connectivité permettant une vraie GTR 4H, toutes aussi concurrentielles les 
unes que les autres (et pas une pseudo GTI).

Pourquoi avoir fait le choix de Free Pro en entreprise, plutôt qu’une offre 
FTTO ?

Faire des (fausses) économies ?

Quentin.


Le 29 sept. 2023 à 17:13, jehan procaccia INT  a 
écrit :

effectivement, apres lecture de 
https://support-pro.free.fr/comment-raccorder-mon-modem-4g/

c'est bien sur un SFP 1G complementaire aux ports LAN qu'il faut brancher le 
modem 4G

un wireshark me montre maintenant une stabilité dans le serveur DHCP qui semble 
bien callé sur celui de la Box, mais tant que le lien fibre ne revient pas, je 
ne peut rien modifier (range dhcp, forwarding de ports, firewall ...)

10 jours que mon uplink fibre est down, 3 fois que soit disant un tech est venu 
(au PMI peut-etre ? ) , mais je n'ai vue personne en bout de chaine sur ma PTO, 
j'attend toujours un diagnostic, sans savoir sur la panne est sur le reseau de 
transport ou la distribution en colonne montante apres le PMI . Finalement avec 
une Freebox particulier je suis me servis qu'avec la version PRO et celle ci  
en plein Paris !

Merci Free.


On 29/09/2023 13:35, David Ponzone wrote:
Voilà.

Après, la description du problème est bizarre, car le routeur 4G fourni par 
Free est censé être branché sur un port (WAN je suppose) de la Freebox, donc en 
aucun cas il ne devrait pouvoir distribuer des IP au LAN….
Ca serait pas plutôt un mauvais branchement (routeur 4G sur un port LAN de la 
Freebox) et que par chance inouï (2 DHCP concurrents sur le LAN), ça marche 
comme ça depuis ?
Après, je dis peut-être des conneries, je connais pas le fonctionnement du 
backup auto de la Freebox Pro, mais je doute qu’ils imposent un changement des 
IP sur le LAN de leurs clients lors de la bascule.
Ca leur garantirait des appels en support en masse.


Le 29 sept. 2023 à 13:29, Philippe ASTIER  a 
écrit :

Ce qui fonctionne très bien, c’est de mettre ton propre routeur derrière la 
Freebox Pro.
Tu feras ce que tu veux de ton DHCP (ou autre), et en cas de bascule, seule ton 
IP publique change.


Le 29 sept. 2023 à 13:14, David Ponzone  a écrit :

Free, même Pro, ne va pas rentrer dans le marché du CPE configurable (donc 
cassable) par le client.
Leur marché, c’est le CPE avec un process industriel, que le client ne peut pas 
défoncer, parce que ce même client ne paie pas assez cher pour imaginer avoir 
un mec au support qui va corriger ses conneries, sachant que pendant ce temps, 
ce même client va râler en criant partout que c’est intolérable cette qualité 
de service déplorable, et qu’il comprend pas pourquoi y a pas un mec qui vient 
lui apporter sous 1 heure un nouveau routeur en Aston Martin avec un café.

Pour garder le contrôle, il vaut/faut généralement mieux mettre son matériel, 
et oublier les box triple/quadruple/jesaispascombien-play.


Le 29 sept. 2023 à 12:49, jehan procaccia INT  a 
écrit :

Bonjour

est-il possible d'administrer une freebox Pro depuis le LAN ? (comme on le fait 
avec les freebox de particuliers, delta etc ... via  un acces 
https://192.168.1.254) ?

apparement seuls l'acces "SAAS"  sur https://pro.free.fr/account/#/ semble etre 
autorisé !?

c'est problematique quand l'uplink fibre est down et qu'on fonctionne sur le 
secours 4G , c'est alors le dhcp du boitier 4G qui fournit des IP aux clients 
dans un subnet different (250 sur le 3eme triplet) . J'aimerai pouvoir gerer le 
dhcp quand on est dans un etat degradé.



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

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


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



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



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

Re: [FRnOG] [TECH] FreeBox pro admin depuis le LAN

[jehan procaccia INT]

effectivement, apres lecture de 
https://support-pro.free.fr/comment-raccorder-mon-modem-4g/


c'est bien sur un SFP 1G complementaire aux ports LAN qu'il faut 
brancher le modem 4G


un wireshark me montre maintenant une stabilité dans le serveur DHCP qui 
semble bien callé sur celui de la Box, mais tant que le lien fibre ne 
revient pas, je ne peut rien modifier (range dhcp, forwarding de ports, 
firewall ...)


10 jours que mon uplink fibre est down, 3 fois que soit disant un tech 
est venu (au PMI peut-etre ? ) , mais je n'ai vue personne en bout de 
chaine sur ma PTO, j'attend toujours un diagnostic, sans savoir sur la 
panne est sur le reseau de transport ou la distribution en colonne 
montante apres le PMI . Finalement avec une Freebox particulier je suis 
me servis qu'avec la version PRO et celle ci  en plein Paris !


Merci Free.

On 29/09/2023 13:35, David Ponzone wrote:

Voilà.

Après, la description du problème est bizarre, car le routeur 4G fourni par 
Free est censé être branché sur un port (WAN je suppose) de la Freebox, donc en 
aucun cas il ne devrait pouvoir distribuer des IP au LAN….
Ca serait pas plutôt un mauvais branchement (routeur 4G sur un port LAN de la 
Freebox) et que par chance inouï (2 DHCP concurrents sur le LAN), ça marche 
comme ça depuis ?
Après, je dis peut-être des conneries, je connais pas le fonctionnement du 
backup auto de la Freebox Pro, mais je doute qu’ils imposent un changement des 
IP sur le LAN de leurs clients lors de la bascule.
Ca leur garantirait des appels en support en masse.


Le 29 sept. 2023 à 13:29, Philippe ASTIER  a 
écrit :

Ce qui fonctionne très bien, c’est de mettre ton propre routeur derrière la 
Freebox Pro.
Tu feras ce que tu veux de ton DHCP (ou autre), et en cas de bascule, seule ton 
IP publique change.


Le 29 sept. 2023 à 13:14, David Ponzone  a écrit :

Free, même Pro, ne va pas rentrer dans le marché du CPE configurable (donc 
cassable) par le client.
Leur marché, c’est le CPE avec un process industriel, que le client ne peut pas 
défoncer, parce que ce même client ne paie pas assez cher pour imaginer avoir 
un mec au support qui va corriger ses conneries, sachant que pendant ce temps, 
ce même client va râler en criant partout que c’est intolérable cette qualité 
de service déplorable, et qu’il comprend pas pourquoi y a pas un mec qui vient 
lui apporter sous 1 heure un nouveau routeur en Aston Martin avec un café.

Pour garder le contrôle, il vaut/faut généralement mieux mettre son matériel, 
et oublier les box triple/quadruple/jesaispascombien-play.


Le 29 sept. 2023 à 12:49, jehan procaccia INT  a 
écrit :

Bonjour

est-il possible d'administrer une freebox Pro depuis le LAN ? (comme on le fait 
avec les freebox de particuliers, delta etc ... via  un acces 
https://192.168.1.254) ?

apparement seuls l'acces "SAAS"  sur https://pro.free.fr/account/#/ semble etre 
autorisé !?

c'est problematique quand l'uplink fibre est down et qu'on fonctionne sur le 
secours 4G , c'est alors le dhcp du boitier 4G qui fournit des IP aux clients 
dans un subnet different (250 sur le 3eme triplet) . J'aimerai pouvoir gerer le 
dhcp quand on est dans un etat degradé.



---
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] FreeBox pro admin depuis le LAN

[jehan procaccia INT]

Bonjour

est-il possible d'administrer une freebox Pro depuis le LAN ? (comme on 
le fait avec les freebox de particuliers, delta etc ... via  un acces 
https://192.168.1.254) ?


apparement seuls l'acces "SAAS"  sur https://pro.free.fr/account/#/ 
semble etre autorisé !?


c'est problematique quand l'uplink fibre est down et qu'on fonctionne 
sur le secours 4G , c'est alors le dhcp du boitier 4G qui fournit des IP 
aux clients dans un subnet different (250 sur le 3eme triplet) . 
J'aimerai pouvoir gerer le dhcp quand on est dans un etat degradé.




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

Re: [FRnOG] [ALERT] Renater (et autres ?) Down ?

[jehan procaccia INT]

Bonsoir,

confirmation coté NOC renater /
/

/--
N°Ticket  : 4965634
Type de ticket    : INCIDENT
Etat du ticket    : Ouvert
--
Emetteur  : NOC-RENATER
Elément concerné  : REN
Service(s) impacté(s) :
--
Début Incident    :  CET/CEST
--
Date/Heure Ouverture (du ticket)  : 12/07/2023 16:43:06 CET/CEST
--

Description de l'incident :
Perturbation sur l'ensemble du réseau Renater /


On 12/07/2023 16:30, jehan procaccia INT wrote:

Bonjour,

notre reseau (AS 2094) sur renater (AS 2200) et collecte (AS 2072) on 
un comportement erratique veres renater / Internet (ovh par exemple)


qq'un a t-il connaissance de pb en cours ?

apparement le NOC Renater signal un soucis, sans preciser lequel .

Jehan .


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

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

[FRnOG] [ALERT] Renater (et autres ?) Down ?

[jehan procaccia INT]

Bonjour,

notre reseau (AS 2094) sur renater (AS 2200) et collecte (AS 2072) on un 
comportement erratique veres renater / Internet (ovh par exemple)


qq'un a t-il connaissance de pb en cours ?

apparement le NOC Renater signal un soucis, sans preciser lequel .

Jehan .


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

[FRnOG] [TECH] catalyst vs nexus dans DC spine / leaf

[jehan procaccia INT]

Bonjour,

nous souhaitons passer sur une architecture spine/leaf dans notre 
(modeste, 20 baies) DC .


nous connaissons bien par ailleurs (distributions prises batiments / 
acces) les catalyst 9500 en coeur et 9200/9300 en acces.


Maintenant coté DC , tout le monde chez cisco ne semble jurer que par la 
gamme Nexus . N'est il pas possible de faire du spine en catalyst 9500 
ou 9300, et des leaf en catalyst 9300 voire 9200 ? supportent t-ils 
l'achitecture spine/leaf - fabric IP / vxlan  , bref on aimerai se 
debaraser de notre vieille archi core / access en spanning tree dans le DC.


à la lecture des references ci-dessous [1] , j'en conclu ces differences 
majeures entre catalyst et nexus dans le DC :


1) de l'administration SD etendue entre Datanceters (ACI) vs peut-etre 
du DNA pour les CAT 9K

2) NX-OS vs IOS-XE
3) des performances de commutation optimale  => sub-microsecond vs 4us 
en CAT 9K
4) dispose de LSE (leaf-and-spine engine) ASIC avec buffering vs UADP 
3.0 ASIC et buffering equivalent en CAT

5) support de FCoE en Nexus vs ports Ethernet sur CAT 9k

Merci pour vos conseils et/ou retour d'experience sur ces 2 grandes 
familles de switch en DC .


Ps: chez nous pas besoin de FCOE et coté perf on a pas besoin de 
descendre à la micro-seconde de commutation, environement 
academique/recherche mono site , bref on aimerai pouvoir le faire en 
catalyst car plus naturel pour nous et a priori moins onereux .


[1]
https://www.reddit.com/r/Cisco/comments/mqe4yd/nexus_vs_catalyst_any_limitations_as_a_tor/ 



https://askanydifference.com/difference-between-cisco-catalyst-and-nexus-with-table/

https://www.cablesandkits.com/learning-center/cisco-catalyst-vs-nexus-switches



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

Re: [FRnOG] [TECH] Renater down minuit 24-25/04/23

[jehan procaccia INT]

Bonsoir,

nouveau pb renater ce soir (3 mai) autour de 23H, mais apparement cela 
remonte ...


curieux ces évenements, des travaux en cours ou de réelles pannes ?

Jehan .

On 25/04/2023 12:11, Guillaume via frnog wrote:

Bonjour,

Souci constaté cette nuit entre 22h30 et 1h30 de connectivité vers le 
réseau du Rectorat de Nantes


gu!llaume


Le 25/04/2023 à 11:59, jehan procaccia INT a écrit :

Bonjour,

nous avons subi une coupure majeure de Renater sur nos reseaux 
academiques cette nuit autour de minuit (entre 22H30 et 1H20)


pas d'autre communication pour l'instant , mais les weathermaps 
montrent depuis ce matin un trafic retablit .


https://www.renater.fr/documentation/ressources-multimedia/weathermap/metropole/ 



j'aurai aimé savoir si cela a impacté d'autres personnes que nous ?

Jehan . 



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



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

[FRnOG] [TECH] Renater down minuit 24-25/04/23

[jehan procaccia INT]

Bonjour,

nous avons subi une coupure majeure de Renater sur nos reseaux 
academiques cette nuit autour de minuit (entre 22H30 et 1H20)


pas d'autre communication pour l'instant , mais les weathermaps montrent 
depuis ce matin un trafic retablit .


https://www.renater.fr/documentation/ressources-multimedia/weathermap/metropole/

j'aurai aimé savoir si cela a impacté d'autres personnes que nous ?

Jehan .


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

Re: [FRnOG] [ALERT] Tout RENATER au tapis ...

[jehan procaccia INT]

oui, le site renater repond a nouveau et du coup on peut lire les 
weathermap


https://www.renater.fr/weathermap/weathermap_metropole

https://www.renater.fr/sites/default/files/weathermap/weathermap_idf.html

le DNS repond aussi

/# dig @ns1.renater.fr. -t A www.renater.fr +short
ix1-pv-lbl-vip-194-57-3-7.renater.fr.
194.57.3.7/

jehan .

Le 17/06/2022 à 10:39, Rémy Grünblatt a écrit :


C'est bon, ça revient.

Rémy

On 17/06/2022 10:18, Charles ENEL-REHEL wrote:

Bonjour ;

Tout RENATER semble KO nationalement depuis 10h00 environ. Me trompe ?

Charles.

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



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

Re: [FRnOG] [ALERT] Tout RENATER au tapis ...

[jehan procaccia INT]

cela depend des services et/ou region .

sur notre reseau de collecte à Evry, le noeud Renater de l'Université 
est bien UP [1]  , pas de soucis de routage localement .


mais je confirme que les services (eduroam, dns, site web, weathermap ) 
sont injoignables .


memee en ipv6

/# ping ns1.renater.fr.
PING ns1.renater.fr.(ns1.renater.fr (2001:660:3001:4002::2)) 56 data bytes
^C
--- ns1.renater.fr. ping statistics ---
6 packets transmitted, 0 received, *100% packet loss*, time 5097ms/

Jehan .


/[1]
# traceroute -I www.franceIX.fr
traceroute to www.franceIX.fr (37.49.234.79), 30 hops max, 60 byte packets
...
 5  vl414-te0-0-0-0-ren-nr-evry-rtr-091.noc.renater.fr 
(193.51.181.222)  1.180 ms  1.187 ms  1.194 ms
 6  xe-1-0-17-ren-nr-evry-rtr-091.noc.renater.fr (193.51.180.226)  
7.533 ms  7.250 ms  7.245 ms
 7  et-3-1-1-ren-nr-paris1-rtr-131.noc.renater.fr (193.55.204.194)  
2.180 ms  2.145 ms  2.140 ms
 8  et-2-0-0-ren-nr-lyon1-rtr-131.noc.renater.fr (193.51.180.167)  
6.709 ms  6.697 ms  6.699 ms

 9  zayo.peers.rezopole.net (77.95.71.60)  7.293 ms  7.229 ms 7.212 ms
10  ae8.ter3.eqx2.par.core.as8218.eu (83.167.55.98)  7.309 ms 7.278 ms  
7.280 ms
11  ae24.tcr1.rb.par.core.as8218.eu (83.167.56.140)  7.332 ms 7.330 ms  
7.327 ms
12  et-1-0-0.tcr2.rb.par.core.as8218.eu (83.167.55.149)  7.402 ms  7.413 
ms  7.326 ms
13  ae5.ter1.itx1.par.core.as8218.eu (83.167.56.191)  7.567 ms  7.569 
ms  7.487 ms
14  xe-0-0-2.ter1.itx5.par.core.as8218.eu (83.167.55.101) 7.552 ms  
7.545 ms  7.532 ms
15  franceix_services2.par.franceix.net (37.49.236.242)  8.163 ms  8.446 
ms  8.025 ms

16  fw-th2-v99.franceix.net (37.49.234.5)  7.521 ms  7.529 ms 7.509 ms
17 www.franceix.net (37.49.234.79)  7.767 ms *  7.771 ms/

Le 17/06/2022 à 10:27, Emmanuel Lacour a écrit :

Le 17/06/2022 à 10:18, Charles ENEL-REHEL a écrit :

Bonjour ;

Tout RENATER semble KO nationalement depuis 10h00 environ. Me trompe ?



ici on a des clients Renater injoignables et je n'arrive pas non plus 
à accéder à leur site ;)



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

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

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

[jehan procaccia INT]

les soudures avancent ... annonce de mon operateur ce soir:

/More links should be in service now, the technicians are more than 
halfway done on repairing the fiber splices and they are currently 
working on the last portion of the cut to bring back up the remaining 
links,/

bon courage aux travailleurs de la nuit .
Le 05/05/2020 à 11:48, jehan procaccia INT a écrit :

de mon coté (Evry) avec  peerings Zayo a DC3 les liens sont restés UP
mais le nombre de routes reçus de ma full table est passé de ~800K 
routes a 99 routes !

du coup  le trafic chute a presque zero .

j'essais de rerouter sur mon 2em peering FranceIX qui semble avoir 
plus de routes ...


on sais où cela s'est passé precisement ?

PS: REnater nous envois aussi un ticket Down sur la liaison 
Cachan-Evry , heureusement qu'ils en ont 2 autres  vers Evry.


Le 05/05/2020 à 10:13, Clement Cavadore a écrit :

On Tue, 2020-05-05 at 10:08 +0200, Clement Cavadore wrote:

Hello,

J'ai constaté pour info de nombreuses liaisons impactées par un
fibercut vers 9h30 ce matin, chez plusieurs opérateurs différents.
A mon avis ca va être la boucherie !
Rien que chez Hivane, ca a coupé plein de liens différents:
https://twitter.com/HivaneNetwork/status/125758117193813606

Pardon, il fallait lire:

https://twitter.com/HivaneNetwork/status/1257581171938136064


Clément


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






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

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

[jehan procaccia INT]

de mon coté (Evry) avec  peerings Zayo a DC3 les liens sont restés UP
mais le nombre de routes reçus de ma full table est passé de ~800K 
routes a 99 routes !

du coup  le trafic chute a presque zero .

j'essais de rerouter sur mon 2em peering FranceIX qui semble avoir plus 
de routes ...


on sais où cela s'est passé precisement ?

PS: REnater nous envois aussi un ticket Down sur la liaison Cachan-Evry 
, heureusement qu'ils en ont 2 autres  vers Evry.


Le 05/05/2020 à 10:13, Clement Cavadore a écrit :

On Tue, 2020-05-05 at 10:08 +0200, Clement Cavadore wrote:

Hello,

J'ai constaté pour info de nombreuses liaisons impactées par un
fibercut vers 9h30 ce matin, chez plusieurs opérateurs différents.
A mon avis ca va être la boucherie !
Rien que chez Hivane, ca a coupé plein de liens différents:
https://twitter.com/HivaneNetwork/status/125758117193813606

Pardon, il fallait lire:

https://twitter.com/HivaneNetwork/status/1257581171938136064


Clément


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

[jehan procaccia INT]

Le 27/09/2019 à 09:17, Duchet Rémy a écrit :

avec 8Go de ram => c'est bon pour 3 full tables ?

J'ai déjà eu plusieurs ASR1001X, avec 8 Go RAM qui tournent sans soucis avec 
plus que 3 full views.
Un ASR1001X, neuf (chez CISCO) c'est largement moins que 10k.
Et ici, c'est pas réputé pour être bon marché.. (CH).

c'est un ASR1002-X que j'ai , mais apparement l'ugrader en memoire + 3 
SPA 10G + licence routage +10G cisco me couterai du coup plus chere que 
d'acheter un materiel neuf ! => un ASR 9001 dispose de base de 4 x 10 GE 
SFP+ et il me couterai finalement moins chere aujourd'hui que d'acheter 
l'upgrade 3x10G sur le 1002X .


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 .


merci pour vos conseils .

PS: l'ASR920 ou cisco 9500 sont hors jeu pourquoi ? memoire ? cpu ? 
features BGP ? car en terme de ports 10G tout est là .



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

Re: [FRnOG] [TECH] Routeur 3 full tables BGP et 10G

[jehan procaccia INT]

Le 26/09/2019 à 23:06, Michel Py a écrit :

Dans ces conditions, n'est-il pas plus avantageux de partir sur un nouveau 
routeur nativement
multi 10G avec une capacité memoire suffisante, mais alors quel modele ?

Je plussoie ce qu'on écrit Alarig et Olivier : ASR 9001 en broke. A partir de 
$7K ici. Et t'en prends 2.

Michel.


oui avec un cisco 9001 on passe de +40K€ a 25K€ sur les prix public ...

https://www.cdw.com/product/cisco-asr-9001-router-rack-mountable/2754318

https://www.optinoc.com/produit/cisco-asr-9001chassis/

avec 8Go de ram => c'est bon pour 3 full tables ?

quelles sont les bonnes references de broker avec SAV en 
France/ile-de-France?


on peut le remettre en garantie cisco smartnet ?

Merci .



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

[FRnOG] [TECH] Routeur 3 full tables BGP et 10G

[jehan procaccia INT]

Bonjour,

j'ai demandé un devis pour upgrader mon cisco ASR 1002x avec 2 ports 10G 
et la capacité de tenir 3 full tables (2 et 1/2 plus exactement car un 
peering France-ix << full table !)


Bilan : 2 cartes SPA 10G + 16 GB Ram + XFP LR + upgrade licence debit >> 
au budget envisagé (plusieurs Dizaines de K€ !)


Dans ces conditions, n'est-il pas plus avantageux de partir sur un 
nouveau routeur nativement multi 10G avec une capacité memoire 
suffisante, mais alors quel modele ?


mon reseau est full cisco, il serait preferable de reprendre un cisco; 
ASR920 ? , 9500 ? sont-ils hors jeux a cause de la memoire pour les full 
tables (BGP v4 et v6 ) , un autre type d'ASR ?


sinon juniper ou autre constructeur fiable  ?

Merci pour vos conseils .


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

Re: [FRnOG] [MISC] Solution de virtualisation

[jehan procaccia INT]

Le 28/05/2019 à 11:05, Alexandre DERUMIER a écrit :

oui, passage à LXC depuis la version4.
il y a pas mal d'embrouille avec le passage de openvz/virtuozzo 7. (avec 
virtuozzo pour la partie commercial, et openvz la partie opensource)
je n'ai plus l'historique en tête, mais je sais qu'il y avait également la 
problématique
qu'openvz était un gros patch kernel out of tree, qui ne fonctionnait que sur 
les kernel redhat 2.6.32.


Maintenant avec openvz7 on est en 3.10.x ... le projet est bien suivit 
et patch regulierement son noyau (14 mai dernier avec les dernieres 
failles annoncées) . Cela reste effectivement "out of tree", mais il y a 
de moins en moins de patchs a integrer maitenant et evidement 
openvz/virtuozzo le fait pour vous .  Les developpeurs contribuent aussi 
largement au kernel linux : 
https://fr.slideshare.net/openvz/whats-missing-from-upstream-kernel-containers-kir-kolyshkin


bref le projet est bien actif et operationel . j'ai eu dernierement une 
discussion sur la mailing list openvz au sujet de la comparaison avec 
LXC et proxmox, je reste surpris sur la valeur ajouté des container 
openvz vs LXC :


https://lists.openvz.org/pipermail/users/2019-April/007590.html

je suis effectivement tres satisfait des containers openvz 7, mais ne 
connaisant pas LXC je ne peux juger .


je pense qu'il existe une certaine communauté en FR , les stats ovz7 
nous mettent en 2eme position derniere les US:


http://stats7-web.openvz.org/index.php?view=location

certes il n'y a pas grand monde, car les stats d'usage ovz6 sont encore 
ailleurs


https://stats.openvz.org/

il me semble qu'il y a une migration de ovz6 vers ovz7 depuis 1 ou 2 
ans, mais que l'instauration d'une distribution dediée (virtuozzo 7 
basée sur centos 7) à probablemnt refroidit les sysadmin pro .deb .



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

Re: [FRnOG] [MISC] Solution de virtualisation

[jehan procaccia INT]

ce long thread fait la part belle aux traditionnels  proxmox, xen, 
openstack ...

en terme de diversité, je ne vois personne parler de openVZ 7 / virtuozzo
c'est tres interessent en terme de container legers (vrais containers ~= 
VM , pas des microcontainers applicatifs type docker ...) tout en 
gardant une bonne isolation et des parametrages de ressources fins 
(memoire, cpu, disk, quota, netfilter etc ... )

par ailleurs pour de la virtu plus lourde et traditionnelle il y a KVM .
serai-je le seul a utiliser openvz7  !?

jehan .

Le 27/05/2019 à 17:36, Michel Py a écrit :

Emmanuel Jacquet a écrit :
Est ce que qqun possède ou a testé une solution à base d'Hyper-V ?

Un peu, mais la license est trop chère pour faire plus que du bricolage.

Michel.




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

[FRnOG] [TECH] ACL check

[jehan procaccia INT]

Bonjour,

je cherche un outil afin de verifier quelle ACE d'une ACL cisco match un 
patern de trafic


bref a verifier le bon fonctionnement de mon ACL !

il y a bien des outils en ligne

http://www.netfishers.onl/armp

https://cway.cisco.com/tools/accesslist/

http://acl.frenzy.cz/

mais je n'ai pas necessairement confiance ...

j'aimerai plutot un outil qui tourne localement sur ma machine

j'ai bien trouvé https://code.google.com/archive/p/acl-check/ a compiler 
sois meme, mais les sources ne sont plus disponibles :-( .


connaissez vous un equivalent ?

Merci



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

[FRnOG] [JOBS] Telecom SudParis recrute un-e ingénieur plateforme / recherche THD

[jehan procaccia INT]

Bonjour,

Un poste d’ingénieur plateforme / recherche est proposé par l’équipe 
THD, au sein du département RST de Télécom SudParis pour une durée de 2 
ans (renouvelable) à compter du 1er juin 2019.

Le descriptif du poste est accessible à cette adresse :
https://www.telecom-sudparis.eu/recrutement/

english: https://www.telecom-sudparis.eu/en/about-us/recruitment/

Les candidatures doivent nous parvenir avant le 3 mai 2019.

*Eléments à envoyer pour postuler*
Merci de nous faire parvenir un CV et une lettre de motivation.
*Nom et adresse d'envoi du dossier de candidature*
- Par mail: recruteme...@imtbs-tsp.eu
ou
- Par courrier: Télécom SudParis - DRH - Caroline COQUET - 9 rue Charles 
Fourier - 91011 EVRY cedex



Bien cordialement,


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

[FRnOG] [MISC] mooc THD FTTH

[jehan procaccia INT]

Bonjour,

juste avant le weekend , mise en avant du MOOC THD / FTTH

https://www.fun-mooc.fr/courses/course-v1:MinesTelecom+04031+session01/about

où sont présentés toutes les technologies Fibres,cables, FTTH ,
deploiement , reglementaires etc .. s'appuyant en partie sur notre
plateforme THD et nos enseignants:
https://www.telecom-sudparis.eu/wp-content/uploads/2017/04/THD.pdf

c'est commencé depuis 3 semaines, mais il est assez aisé de rattraper
les premières semaines , surtout pour des gens du métiers .

Bonne lecture .


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

Re: [FRnOG] [TECH] Liste subnet IP des ISP FR

[jehan procaccia INT]

Le 05/10/2016 11:42, Laurent CARON a écrit :

On 05/10/2016 11:36, jehan procaccia INT wrote:
je ne sais pas si le projet est réalisable, mais serait-il possible 
de constituer une liste (peut-être pas exhaustive ...)
des subnets IP de ISP français a des fins de contrôle d’accès 
firewall (ACL autorisant seulement les internautes FR)  ?


j'ai trouvé cette page : http://ipinfo.io/countries/fr
piste suivie: 
http://serverfault.com/questions/351123/need-to-find-users-of-asn-in-my-country 


et http://www.team-cymru.org/IP-ASN-mapping.html
une requete en cli en donne +1200 ASN FR :
$ whois -h cc2asn.com FR | wc -l
1217

sinon http://www.cidr-report.org/as2.0/bgp-originas.html
les recherches semble fastidieuses
si vous avez mieux ?


Bonjour,

http://www.ipdeny.com/ipblocks/data/aggregated/fr-aggregated.zone
http://www.ipdeny.com/ipv6/ipaddresses/blocks/fr.zone

Loin d'être parfait...mais une piste pour commencer.


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



oui pas mal ces listes sur http://www.ipdeny.com/ipblocks/ , en plus 
régulièrement mises a jours :

Zone files last updated: Wed Oct 5 12:07:23 UTC 2016
je suis d'accord que ce n'est pas LA bonne solution, mais je veux juste 
faire un filtrage grossier, meme plus grossier que cette liste tout FR
je voudrai limiter l'acces aux gros ISP (orange, free, sfr, bouygues) 
afin d'avoir une ACL limitée en taille,

mais même parmi eux il y a des ranges de subnets et souvent plusieurs ASN
cette liste d'ASN + subnets IP des 4 opérateurs nationaux est-elle déjà 
agrégée qq part avant que je me lance dans une liste maison ?

a partir ce ça par exemple : http://www.nirsoft.net/countryip/fr_total.html

Merci .


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

[FRnOG] [TECH] Liste subnet IP des ISP FR

[jehan procaccia INT]

je ne sais pas si le projet est réalisable, mais serait-il possible de 
constituer une liste (peut-être pas exhaustive ...)
des subnets IP de ISP français a des fins de contrôle d’accès firewall 
(ACL autorisant seulement les internautes FR)  ?


j'ai trouvé cette page : http://ipinfo.io/countries/fr
piste suivie: 
http://serverfault.com/questions/351123/need-to-find-users-of-asn-in-my-country

et http://www.team-cymru.org/IP-ASN-mapping.html
une requete en cli en donne +1200 ASN FR :
$ whois -h cc2asn.com FR | wc -l
1217

sinon http://www.cidr-report.org/as2.0/bgp-originas.html
les recherches semble fastidieuses
si vous avez mieux ?

Merci .


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

Re: [FRnOG] [TECH] adresses IP publiques pour telephone clients des operateurs mobile FR

[jehan procaccia INT]

RIPE DB, certes , mais quels critères de recherche ?

sur un abonnement free pour lequel j'ai pu récupérer l'ip publique 
(mon-ip.com)

je retrouve bien

$ whois 37.161.170.44
inetnum: *37.160.0.0 - 37.163.255.255*
netname:MOBILE-USERS-BLOCK
descr:  Free Mobile SAS

Mais comment faire pour les autres ?
et chez free, est-ce le seul bloc disponible !? (ici  4 x /16 pas mal , 
ca fait ~ 2 million 600 mil adresses ...)


Le 29/04/2016 10:24, Michael Hallgren a écrit :

Le 2016-04-29 10:05, jehan procaccia INT a écrit :

bonjour,


Bonjour,



je cherche a connaitre les préfixes IP utilisés pour le routage data
des opérateurs mobile FR (free, sfrp, orange bouygues )
existe il une publication (arcep ou les opérateurs eux même ?) qui
référence les IP publiques qu'ils utilisent pour leur Nat des
téléphones clients ?


RIPE DB, normalement.



merci .

Jehan .


mh




---
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] adresses IP publiques pour telephone clients des operateurs mobile FR

[jehan procaccia INT]

bonjour,

je cherche a connaitre les préfixes IP utilisés pour le routage data des 
opérateurs mobile FR (free, sfrp, orange bouygues )
existe il une publication (arcep ou les opérateurs eux même ?) qui 
référence les IP publiques qu'ils utilisent pour leur Nat des téléphones 
clients ?

merci .

Jehan .


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

Re: [FRnOG] [TECH] outils de cartographie , map, et connexions réseau fibre optique MAN

[jehan procaccia INT]

j'ai reçus d'autres propositions off list, j'en fais part à la communauté

NetGeo
arcgis

quelques liens traitants du même sujet , je ne suis pas le seul a poser 
la question ...


https://lafibre.info/techniques-deploiement/logiciels-metier-etudesdeploiement-fo/
http://fr.viadeo.com/fr/groups/detaildiscussion/?containerId=00216xbn9cnlac90&action=messageDetail&messageId=002143amd9dvrx8v&forumId=002sxa932v82x7i

Qgis apparemment bien référencé
http://www.comsof.com/blog/planning-fttx-networks-with-qgis
http://gis.stackexchange.com/questions/20533/design-fiberoptic-network-in-qgis

un autre
http://www.geomap-imagis.com/telecom/

Mais je reste preneur d'autres suggestions s'il en existe ?

Merci .

Le 21/03/2016 22:51, Jacques VUVANT a écrit :


Qgis est un logiciel libre pour la partie fibre. Pour le reste tu peux 
adapter.


Jacques

Le 22 mars 2016 08:42, "jehan procaccia INT" 
mailto:jehan.procac...@int-evry.fr>> a 
écrit :


bonjour,

je recherche un logiciel de cartographie pour notre réseau
Metropolitain . voici les caractéristiques
1) câbles types 12, 72, 144 FO  suivant les tronçons
2) possibilité de référencement des branchements sur matériels
actifs (couleur tube/ couleur paire / fibre, type connecteur)
3) armoires de brassage avec jarretières
4) application sur fond de carte, idéalement type openstreetmap
5) idéalement logiciel libre, mais je suis preneur aussi de
solution commerciales
6) autres que Excel et/ou visio

je suis curieux de connaitre ce que les opérateurs ou autres MAN
de collecte locale utilisent ?

Merci .

jehan .


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




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

[FRnOG] [TECH] outils de cartographie , map, et connexions réseau fibre optique MAN

[jehan procaccia INT]

bonjour,

je recherche un logiciel de cartographie pour notre réseau Metropolitain 
. voici les caractéristiques

1) câbles types 12, 72, 144 FO  suivant les tronçons
2) possibilité de référencement des branchements sur matériels actifs 
(couleur tube/ couleur paire / fibre, type connecteur)

3) armoires de brassage avec jarretières
4) application sur fond de carte, idéalement type openstreetmap
5) idéalement logiciel libre, mais je suis preneur aussi de solution 
commerciales

6) autres que Excel et/ou visio

je suis curieux de connaitre ce que les opérateurs ou autres MAN de 
collecte locale utilisent ?


Merci .

jehan .


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

Re: [FRnOG] [TECH] Deni de service en src 192.168.1 sur Cisco ASR / 6500

[jehan procaccia INT]

Le 30/07/2015 10:13, David Ponzone a écrit :

Tu parles de son système ?
Mais il est root dessus, il fait ce qu’il veut.
effectivement , J'ai enfin localisé grâce aux netflows et graphs cacti 
en # de paquets le source du tcp syn flood  que je subissais.
cela aura été fastidieux du fait de l'intermittence et de la faible 
durée du flood à chaque occurences


une machine ouverte en ssh a été usurpée (brute force du password root, 
un fail2ban aurait été une bonne prévention locale ... )
téléchargement par le "pirate" d'un binaire depuis un site chinois, 
binaire qui génère le synflood,
j'y ai bien retrouvé la chaine de caratere (string sur le binaire) 
192.168.1.101 (source des paquets forgés)  dedans
bref une brèche  classique et simple, mais qui m'aura pris pas mal de 
temps pour remonter à la source ,

 .


Sous Linux, c’est même encore plus trivial et ça peut être causé par un conf 
mal faite:
ifconfig eth0 157.159.1.X netmask 255.255.255.0
ifconfig eth1 192.168.1.101 netmask 255.255.255.0
route add default gw 157.159.1.1
ping -s 192.168.1.101 157.159.1.1

oui, j'ai meme trouvé encore plus simple avec hping , option -a ou --spoof !


Maintenant, tu y es presque.
Tu a pas l’adresse MAC source des paquets dans Netflow ? Je me souviens plus.
je n'ai pas réussi a l'avoir dans mon netflow, mais cela semble 
paramétrable dans le "flow record" avec un "match" qui va bien , cf:

http://www.cisco.com/c/en/us/products/collateral/switches/catalyst-6500-series-switches/white_paper_c11-652021.html#_Toc287071073


je regrette qu'il n'y ait pas d'outils plus adéquate (que des graphes 
visuels)  pour localiser ce genre d'attaque sur les équipements actifs .
depuis j'ai mis en place sur mon coeur de reseau (6500) une policy qui 
devrait rate limiter ce genre de flux, mais malheureusement je n'arrive 
pas a matcher le flux ,
la policy ne police jamais rien, les compteurs sont tj a zero meme quand 
il y a eu un tcp syn flood en cours depuis 192.168.1.101 :-(


6509E#show policy-map interface gigabitEthernet 2/12
 GigabitEthernet2/12
  Service-policy input: police-192-168-1-traffic

Class-map: identify-192-168-1-traffic (match-all)
  0 packets, 0 bytes
  5 minute offered rate  bps,*drop rate  bps*
  Match: access-group 123

Class-map: identify-80-syn-traffic (match-all)
  0 packets, 0 bytes
  5 minute offered rate  bps,*drop rate  bps*
  Match: access-group 125

Class-map: class-default (match-any)
  0 packets, 0 bytes
  5 minute offered rate  bps, drop rate  bps
  Match: any
0 packets, 0 bytes
5 minute rate 0 bps

peut-etre que j'ai regardé trop tard, au dela des 5mn l'intervalle "5 
minute offered rate" ?
J'ai essayer 2 class-map qui devraient matcher des paquets source en 
192.168.1.101, et l'autre qui match a destination du port 80 avec le 
flag syn :



6509E#show class-map identify-80-syn-traffic
 Class Map match-all identify-80-syn-traffic (id 39)
   Match access-group  125

6509E#show access-lists 125
Extended IP access list 125
10 permit tcp any any eq www syn

6509E#show access-lists 123
Extended IP access list 123
10 permit ip 192.168.1.0 0.0.0.255 any

manifestement, n'y l'un , n'y l'autre ne match :-(
Si certains d'entre vous utilise ce genre de policy (rate limite) avec 
succes, je suis preneur d'info .


au dela du cas d'ecole, je pense que je vais dropper tout RFC1918 qui 
n'a pas lieu d’être, cela aura été une bonne leçon .


Merci .


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

Re: [FRnOG] [TECH] Deni de service en src 192.168.1 sur Cisco ASR / 6500

[jehan procaccia INT]

Le 30/07/2015 08:41, David Ponzone a écrit :

Encore une fois, je ne sais pas si c’est ta phrase qui est mal tournée, mais ce 
n’est pas parce que tu n’as pas de route vers un subnet que tu ne vas pas 
recevoir de paquets venant de ce subnet.
Les routes définissent par où tu vas envoyer tes paquets vers cette IP (et donc 
tes réponses).

OK, je me met à la place du "pirate",
comment depuis mon client linux par exemple, sur mon réseau public 
157.159.1.0/24 qui a une gateway en 157.159.1.1 sur une interface vlan 
correspondant a ce reseau sur le 6500,  je peux configurer sur ce vlan + 
subnet ip public (donc a une gateway qui repond en 157.159.1.1 )  une 
adresse 192.168.1.101 !?, le systeme va me jeter !? le subnet IP ne 
correspond  pas a ma gateway , bref comment le "pirate" arrive a joindre 
ma gateway publique du 6500 avec un subnet IP qui ne match pas ce que 
dessert le vlan .




Pour empêcher des paquets qui ont 192.168.1.101 comme source, il faut mettre un:

ip access-list standard anti-mechants
  deny 10.0.0.0 0.255.255.255
  deny 192.168.0.0 0.0.255.255
  deny 172.16.0.0 0.15.255.255
  permit any

Oui, je sais bien que c'est la bonne solution
Mon objectif immédiat n'est pas de droper ce trafic, mais de 
l'identifier, je veux trouver la source, si je le drop je n'aurais plus 
de traces .


(http://www.cisco.com/c/en/us/support/docs/ip/access-lists/43920-iacl.html)

et tu appliques ceci sur TOUTES tes interfaces INGRESS, donc toutes les 
interfaces sur lesquelles sont connectés des équipements que tu ne maitrises 
pas:
-internet
-clients
-machines d’étudiants fous sous Windows ou geeks sous Linux

D’ailleurs, sur les interfaces INGRESS internes (clients/utilisateurs) tu peux 
même être encore plus restrictif en autorisant seulement tes propres IP.
Sur les INGRESS externes, tu peux en plus interdire tes propres IP.

Encore plus drastique , mais effectivement plus sure , je vais y réfléchir .


Désolé si je répète un truc déjà fait, mais j’ai eu un doute en te lisant.

pas de problèmes, moi même j'y perd mon latin .

Merci .


Le 29 juil. 2015 à 23:43, jehan procaccia IMT  a 
écrit :

comment des paquets (forgés probablement) avec une src en 192.168.1.101 peuvent 
t-il aboutir sur mon coeur de reseau alors que je n'ai pas de gateway ni de 
route pour ce reseau 192.168.1.0/24 !?
cela m’intéresse .




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

Re: [FRnOG] [TECH] Deni de service en src 192.168.1 sur Cisco ASR / 6500

[jehan procaccia INT]

Le 28/07/2015 15:05, Dominique Rousseau a écrit :

Le Tue, Jul 28, 2015 at 02:58:45PM +0200, jehan procaccia INT 
[jehan.procac...@int-evry.fr] a écrit:

c'est ce que je capture en faisant un port mirroring (session
monitor en termes cisco) sur l'interface que je suspectais
donc pas vraiment "apres" mon 6500 , mais plutôt dedans .

Si c'est sur l'interface de sortie, vers ton ASR, c'est du "apres".
OK, c'est effectivement APRES, donc la MAC capturée doit correspondre a 
l'adresse MAC de mon interface de sortie normalement, ici le Giga 2/21 
(la G2/16 etant la destination du port mirroring où se trouve mon 
PC/TCPDUMP)


6509E-B007#show monitor
Session 1
-
Type   : Local Session
Source Ports   :
Both   : Gi2/21
Destination Ports  : Gi2/16

6509E-B007#show interface g 2/21 | include  line | address
GigabitEthernet2/21 is up, line protocol is up (connected)
  Hardware is C6k 1000Mb 802.3, address is 001f.6ca4.b194 (bia 
001f.6ca4.b194)


or, voici le rappel de type de capture du synflood :

11:56:50.943052 *10:bd:18:e4:80:80* > 00:07:7d:33:9f:00, ethertype 
802.1Q (0x8100), length 66: vlan 8, p 0, ethertype IPv4, (tos 0x0, ttl 
121, id 13137, offset 0, flags [DF], proto TCP (6), length 48)
192.168.1.101.4007 > 119.28.3.29.80: Flags [S], cksum 0x7576 (correct), 
seq 2748456345, win 65535, options [mss 1460,nop,nop,sackOK], length 0


la mac 10:bd:18:e4:80:80 n'est pas celle de l'interface g 2/21 
(001f.6ca4.b194) mais celle de de la giga 2/22 (reseau downlink vers 
"clients" )


6509E-B007#show interfaces gigabitEthernet 2/22
GigabitEthernet2/22 is up, line protocol is up (connected)
  Hardware is C6k 1000Mb 802.3, address is *10bd.18e4.8080* (bia 
10bd.18e4.8080)


Helas, comme plein d'interfaces sur mon 6500 ont aussi la MAC 
*10bd.18e4.8080 *je ne suis pas avancé pour identifier l'interface 
source du syn flood .


Ceci s'explique apparement d'apres la judicieuse remarque de David Ponzone

Le 28/07/2015 14:55, David Ponzone a écrit :
> C’est étrange en effet, mais lis ça, ca explique peut-être le truc:
> 
http://www.cisco.com/c/en/us/support/docs/switches/catalyst-6000-series-switches/41263-catmac-41263.html


effectivement à la lecture de cette doc il semble "normal" qu'il y a la 
meme MAC sur +sieurs Interfaces et on ne peut pas y faire grand chose :-(


"As a result, you cannot have a unique MAC address per interface. This 
is a hardware limitation of the Supervisor Engine II and will not be 
fixed in a future software release. "


je suis en Sup2T , je ne sais pas si cette limitation Sup engine II 
correspond ... mais je constate bien ce pb .


Bref, il n'est vraiment pas évident de pister un flux sur ces 
équipements, il faudrait presque pouvoir éteindre une a une les 
interfaces au moment du flood, mais avec +128 interfaces et des flood 
sporadiques qui ne durent que qq minutes, ce n'est vraiment pas facile .



avec 2 cartes 48 ports 1G et 1 carte 16 * 10G cela ne va pas etre
facile de faire du port mirroring sur chaque port !

[...]

avez vous une idée pour identifier l'interface source de mon 6500
qui génère ce trafic.

Vu le nombre de ports que tu indiques, il y'en a où ton 6500 fait du
switching, et d'autres où il route, je suppose.
Si tu te limites aux ports qui font du routage, ça te donne quoi ?

Ils routent quasiment tous, j'ai un uplink vers l'ASR puis operateurs, 
et un downlink vers un reseau "client", le reste c'est mon LAN de campus 
avec une dizaine de batiments en Fibre et et une dizaine de switch 
directement raccordés en 1G et 10G  dans le datacenter qui font usage 
d'interfaces switchport cuivre mais toutes ratachées a des interfaces 
vlan qui routent .


plus théoriquement, je m'interroge toujours sur la source du flood ?!

comment des paquets (forgés probablement) avec une src en 192.168.1.101 
peuvent t-il aboutir sur mon coeur de reseau alors que je n'ai pas de 
gateway ni de route pour ce reseau 192.168.1.0/24 !?
peut-être qu'une réponse a cette question m'aiguillera sur une piste 
plus prometteuse .


Merci .



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

Re: [FRnOG] [TECH] Deni de service en src 192.168.1 sur Cisco ASR / 6500

[jehan procaccia INT]

Le 28/07/2015 14:30, Dominique Rousseau a écrit :

Le Tue, Jul 28, 2015 at 12:14:46PM +0200, jehan procaccia INT 
[jehan.procac...@int-evry.fr] a écrit:

J'ai finit par mettre une ACL qui filtre tout 192.168.0.0/16
malheureusement cela passe toujours ! :-(
et pour cause, je pensais avoir identifié l'interface source sur mon
6500 , or je m???aperçois que l'adresse MAC identifié comme source
du pb est affectée a plusieurs interfaces du 6500 !?

rappel de type de capture du synflood :

11:56:50.943052 *10:bd:18:e4:80:80* > 00:07:7d:33:9f:00, ethertype
802.1Q (0x8100), length 66: vlan 8, p 0, ethertype IPv4, (tos 0x0,
ttl 121, id 13137, offset 0, flags [DF], proto TCP (6), length 48)
*192.168.1.101*.4007 > 119.28.3.29.80: Flags [S], cksum 0x7576
(correct), seq 2748456345, win 65535, options [mss
1460,nop,nop,sackOK], length 0

La MAC est donc *10:bd:18:e4:80:80

Mais ça, c'est (si j'ai bien compris) ce que tu captures *APRES* ton
6500, qui doit effectuer du routage, et c'est donc son adresse MAC que
tu vois.

[...]
c'est ce que je capture en faisant un port mirroring (session monitor en 
termes cisco) sur l'interface que je suspectais

donc pas vraiment "apres" mon 6500 , mais plutôt dedans .

Ce qu'il faudrait, c'est réussir à identifier la source *AVANT* le 6500.

oui, c'est bien ce que je recherche


As-tu moyen de placer de quoi faire un tcpdump sur les "entrées" de ton
6500 ?
avec 2 cartes 48 ports 1G et 1 carte 16 * 10G cela ne va pas etre facile 
de faire du port mirroring sur chaque port !
ce qui me perturbe fortement, c'est pourquoi des interfaces du 6500 ont 
la meme adresse MAC !?


GigabitEthernet*2/19* is up, line protocol is up (connected)
  Hardware is C6k 1000Mb 802.3, address is *10bd.18e4.8080* (bia 
10bd.18e4.8080)

GigabitEthernet*2/22 *is up, line protocol is up (connected)
  Hardware is C6k 1000Mb 802.3, address is *10bd.18e4.8080* (bia 
10bd.18e4.8080)


au dela d'une ACL en IN sur l'interface suspectée

6509E-B007#show access-lists 122
Extended IP access list 122
10 deny ip 192.168.1.0 0.0.0.255 any log-input
30 permit ip any any (413 matches)

interface GigabitEthernet2/22
ip access-group 122 in

j'ai monté ensuite un rate-limit afin de voir plus finement si je peux 
matcher et controler ce trafic sur cette interface


6509E-B007#show policy-map police-192-168-1-traffic
  Policy Map police-192-168-1-traffic
Class identify-192-168-1-traffic
  police flow mask src-only 32000 10 conform-action transmit 
exceed-action drop


6509E-B007#show class-map identify-192-168-1-traffic
 Class Map match-all identify-192-168-1-traffic (id 37)
   Match access-group  123

6509E-B007#show access-lists 123
Extended IP access list 123
10 permit ip 192.168.1.0 0.0.0.255 any

Helas, cela ne match rien, meme a un momment ou j'ai vu les effets de 
bord du synflood sur l'ACL 112 de mon ASR  qui n'arrivent plus a Loger 
quand cela se produit



6509E-B007#show policy-map interface gigabitEthernet 2/22
 GigabitEthernet2/22
  Service-policy input: police-192-168-1-traffic
*Class-map: identify-192-168-1-traffic (match-all)**
**  0 packets, 0 bytes*
  5 minute offered rate  bps, drop rate  bps
  Match: access-group 123

Class-map: class-default (match-any)
  581 packets, 83110 bytes
  5 minute offered rate  bps, drop rate  bps
  Match: any
581 packets, 83110 bytes
5 minute rate 0 bps

avez vous une idée pour identifier l'interface source de mon 6500 qui 
génère ce trafic.
la difficulté est qu'il y a des burst de synflood qui ne durent que qq 
minites de façon aleatoire toutes les 3 ou 4H => pas facile de suivre le 
flux 


Merci .


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

Re: [FRnOG] [TECH] Deni de service en src 192.168.1 sur Cisco ASR / 6500

[jehan procaccia INT]

J'ai finit par mettre une ACL qui filtre tout 192.168 .0.0/24
malheureusement cela passe toujours ! :-(
et pour cause, je pensais avoir identifié l'interface source sur mon 
6500 , or je m’aperçois que l'adresse MAC identifié comme source du pb 
est affectée a plusieurs interfaces du 6500 !?


rappel de type de capture du synflood :

11:56:50.943052 *10:bd:18:e4:80:80* > 00:07:7d:33:9f:00, ethertype 
802.1Q (0x8100), length 66: vlan 8, p 0, ethertype IPv4, (tos 0x0, ttl 
121, id 13137, offset 0, flags [DF], proto TCP (6), length 48)
*192.168.1.101*.4007 > 119.28.3.29.80: Flags [S], cksum 0x7576 
(correct), seq 2748456345, win 65535, options [mss 1460,nop,nop,sackOK], 
length 0


La MAC est donc *10:bd:18:e4:80:80

*6509E-B007#show interfaces gigabitEthernet 2/19
GigabitEthernet2/19 is up, line protocol is up (connected)
  Hardware is C6k 1000Mb 802.3, address is *10bd.18e4.8080* (bia 
10bd.18e4.8080)


GigabitEthernet2/20 is down, line protocol is down (notconnect)
  Hardware is C6k 1000Mb 802.3, address is *10bd.18e4.8080* (bia 
10bd.18e4.8080)


6509E-B007#show interfaces gigabitEthernet 2/22
GigabitEthernet2/22 is up, line protocol is up (connected)
  Hardware is C6k 1000Mb 802.3, address is *10bd.18e4.8080 *(bia 
10bd.18e4.8080)

*
*je pensais avoir indetifié la source sur gigabitEthernet 2/22 , mais g 
2/19, g2/20 etc ... ont aussi 10bd.18e4.8080*??


*je crois que j'ai trop la tête dans le guidon sur cette affaire ... 
j'ai oublié une évidence ? ce sont des MAC adresse d'interface cisco 
virtuelle ? vlan ? j'ai du HSRP , peut-etre un effet de bord ?

bref avez vous une piste pour retrouver l'interface source de ce trafic !?

Merci .*

*Le 24/07/2015 16:30, David Ponzone a écrit :

Mais filtre tout le rfc1918 ( sauf le légitime) en entrée du 6500!

David Ponzone



Le 24 juil. 2015 à 16:25, jehan procaccia INT 
mailto:jehan.procac...@int-evry.fr>> a 
écrit :



Le 24/07/2015 15:32, Nicolas Strina a écrit :

On 24 juil. 2015, at 14:04, Clement Cavadore  wrote:

Re,

On Fri, 2015-07-24 at 14:58 +0200, jehan procaccia INT wrote:

apres analyse pcap du trafic incriminé, extrait :
des milliers de paquets avec le Flag S (Sync)  cf :
(...)

http://albanianwizard.org/how-to-read-tcpdump-output-tcpdump-advanced-use.albanianwizard
montre qu'il s'agit vraisemblablement d'un SynFlood attack

je me lance alors dans l'espoir d'intercepter ça avec les outils
cisco
http://www.sans.org/security-resources/idfaq/syn_flood.php
http://ccie-or-null.net/tag/cisco-tcp-intercept/
http://www.ciscopress.com/articles/article.asp?p=345618&seqNum=3

Helas, sur mon 6500E pas de commande ip tcp intercept  :-( !
ça sort d'où cette commande ? n'est pas disponible par défaut ?

Probablement disponible sur une autre plateforme que les 6k5.

Non, mais plus sérieusement, tu devrais poser sur ton ASR une ACL
ingress sur l'interface vers ton réseau interne, n'autorisant que les
subnets IP qu'elle est supposée recevoir, à savoir les réseaux publics
passant par ce routeur. Et du coup, tu peux te passer de ton ACL egress.

Sinon voir avec ton upstream ? Ca me parait une bonne solution si tu as des 
soucis aussi important et aussi longtemps ..
Le transitaire doit aussi assurer la “sécurité” des clients dans une moindre 
mesure ..


Le probleme est que je suis l'upstream ! voici un aperçu ASCII du 
schema reseau:


Source Synflood <=> Autonomous system (au sens politique/domain de 
vlans) Etudiants (4500) *<=> Mon Core 6509E <=> Mon ASR <=>* MAN-Evry 
<=> Renater <=> Internet


j'aimerai bien intercepter le Synflood au plus tot (amont) sur mon 
6509E .
je suis surpris que le 6500 (le "couteau suisse" cisco ) ne gere pas 
le /ip tcp intercept/ tel que définit ici et là :

http://www.sans.org/security-resources/idfaq/syn_flood.php
http://ccie-or-null.net/tag/cisco-tcp-intercept/
http://www.ciscopress.com/articles/article.asp?p=345618&seqNum=3
sinon, peut-etre une autre commande ? y-a-t-il un correspondant Cisco 
dans la salle ?


Merci .



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

Re: [FRnOG] [TECH] Deni de service en src 192.168.1 sur Cisco ASR / 6500

[jehan procaccia INT]

Le 24/07/2015 15:32, Nicolas Strina a écrit :

On 24 juil. 2015, at 14:04, Clement Cavadore  wrote:

Re,

On Fri, 2015-07-24 at 14:58 +0200, jehan procaccia INT wrote:

apres analyse pcap du trafic incriminé, extrait :
des milliers de paquets avec le Flag S (Sync)  cf :
(...)

http://albanianwizard.org/how-to-read-tcpdump-output-tcpdump-advanced-use.albanianwizard
montre qu'il s'agit vraisemblablement d'un SynFlood attack

je me lance alors dans l'espoir d'intercepter ça avec les outils
cisco
http://www.sans.org/security-resources/idfaq/syn_flood.php
http://ccie-or-null.net/tag/cisco-tcp-intercept/
http://www.ciscopress.com/articles/article.asp?p=345618&seqNum=3

Helas, sur mon 6500E pas de commande ip tcp intercept  :-( !
ça sort d'où cette commande ? n'est pas disponible par défaut ?

Probablement disponible sur une autre plateforme que les 6k5.

Non, mais plus sérieusement, tu devrais poser sur ton ASR une ACL
ingress sur l'interface vers ton réseau interne, n'autorisant que les
subnets IP qu'elle est supposée recevoir, à savoir les réseaux publics
passant par ce routeur. Et du coup, tu peux te passer de ton ACL egress.

Sinon voir avec ton upstream ? Ca me parait une bonne solution si tu as des 
soucis aussi important et aussi longtemps ..
Le transitaire doit aussi assurer la “sécurité” des clients dans une moindre 
mesure ..


Le probleme est que je suis l'upstream ! voici un aperçu ASCII du schema 
reseau:


Source Synflood <=> Autonomous system (au sens politique/domain de 
vlans) Etudiants (4500) *<=> Mon Core 6509E <=> Mon ASR <=>* MAN-Evry 
<=> Renater <=> Internet


j'aimerai bien intercepter le Synflood au plus tot (amont) sur mon 6509E .
je suis surpris que le 6500 (le "couteau suisse" cisco ) ne gere pas le 
/ip tcp intercept/ tel que définit ici et là :


http://www.sans.org/security-resources/idfaq/syn_flood.php
http://ccie-or-null.net/tag/cisco-tcp-intercept/
http://www.ciscopress.com/articles/article.asp?p=345618&seqNum=3

sinon, peut-etre une autre commande ? y-a-t-il un correspondant Cisco 
dans la salle ?


Merci .

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

Re: [FRnOG] [TECH] Deni de service en src 192.168.1 sur Cisco ASR / 6500

[jehan procaccia INT]

apres analyse pcap du trafic incriminé, extrait :

...
03:17:16.861782 IP 192.168.1.101.pwgpsi > 113.10.190.164.http: Flags 
[S], seq 223483717, win 65535, options [mss 1460,nop,nop,sackOK], length 0
03:17:16.861790 IP 192.168.1.101.3403 > 113.10.190.164.http: Flags [S], 
seq 2632565066, win 65535, options [mss 1460,nop,nop,sackOK], length 0
03:17:16.861796 IP 192.168.1.101.3403 > 113.10.190.164.http: Flags [S], 
seq 3264797709, win 65535, options [mss 1460,nop,nop,sackOK], length 0
03:17:16.861803 IP 192.168.1.101.3403 > 113.10.190.164.http: Flags [S], 
seq 3264797709, win 65535, options [mss 1460,nop,nop,sackOK], length 0
03:17:16.861810 IP 192.168.1.101.3403 > 113.10.190.164.http: Flags [S], 
seq 3264797709, win 65535, options [mss 1460,nop,nop,sackOK], length 0
03:17:16.861817 IP 192.168.1.101.3403 > 113.10.190.164.http: Flags [S], 
seq 2632565066, win 65535, options [mss 1460,nop,nop,sackOK], length 0
03:17:16.861824 IP 192.168.1.101.dssiapi > 113.10.190.164.http: Flags 
[S], seq 3682841697, win 65535, options [mss 1460,nop,nop,sackOK], length 0
03:17:16.861831 IP 192.168.1.101.remote-winsock > 113.10.190.164.http: 
Flags [S], seq 3359203881, win 65535, options [mss 1460,nop,nop,sackOK], 
length 0
03:17:16.861838 IP 192.168.1.101.remote-winsock > 113.10.190.164.http: 
Flags [S], seq 3359203881, win 65535, options [mss 1460,nop,nop,sackOK], 
length 0
03:17:16.861844 IP 192.168.1.101.remote-winsock > 113.10.190.164.http: 
Flags [S], seq 2971501483, win 65535, options [mss 1460,nop,nop,sackOK], 
length 0
03:17:16.861852 IP 192.168.1.101.remote-winsock > 113.10.190.164.http: 
Flags [S], seq 2971501483, win 65535, options [mss 1460,nop,nop,sackOK], 
length 0
03:17:16.861858 IP 192.168.1.101.ati-ip-to-ncpe > 113.10.190.164.http: 
Flags [S], seq 2500809523, win 65535, options [mss 1460,nop,nop,sackOK], 
length 0
03:17:16.861865 IP 192.168.1.101.ati-ip-to-ncpe > 113.10.190.164.http: 
Flags [S], seq 2657654922, win 65535, options [mss 1460,nop,nop,sackOK], 
length 0
03:17:16.861872 IP 192.168.1.101.ati-ip-to-ncpe > 113.10.190.164.http: 
Flags [S], seq 2661998392, win 65535, options [mss 1460,nop,nop,sackOK], 
length 0
03:17:16.861879 IP 192.168.1.101.mqe-agent > 113.10.190.164.http: Flags 
[S], seq 1759456840, win 65535, options [mss 1460,nop,nop,sackOK], length 0
03:17:16.861885 IP 192.168.1.101.iee-qfx > 113.10.190.164.http: Flags 
[S], seq 3559881937, win 65535, options [mss 1460,nop,nop,sackOK], length 0

...

des milliers de paquets avec le Flag S (Sync)  cf : 
http://albanianwizard.org/how-to-read-tcpdump-output-tcpdump-advanced-use.albanianwizard

montre qu'il s'agit vraisemblablement d'un SynFlood attack

je me lance alors dans l'espoir d'intercepter ça avec les outils cisco
http://www.sans.org/security-resources/idfaq/syn_flood.php
http://ccie-or-null.net/tag/cisco-tcp-intercept/
http://www.ciscopress.com/articles/article.asp?p=345618&seqNum=3

Helas, sur mon 6500E pas de commande *ip tcp intercept :-( !

*/6509E(config)#ip tcp intercept//
//  ^//
//% Invalid input detected at '^' marker./*

*ça sort d'où cette commande ? n'est pas disponible par défaut ?*

*Merci .
*
*Le 24/07/2015 12:24, David Ponzone a écrit :
Si tu commençais par ajouter dans SPOOFING-IN un deny sur tout ce qui 
est RFC1918 et autres saloperies qui n’a rien à faire là.

Mais idéalement, il faut mettre ça en ingress de ton réseau.
A ce moment là, les logs, ça devient inutile (ou un luxe que tu ne 
peux plus te permettre).



Le 24 juil. 2015 à 11:30, jehan procaccia INT 
mailto:jehan.procac...@int-evry.fr>> a 
écrit :




Le 23/07/2015 18:40, David Ponzone a écrit :

Il serait peut-être temps de mettre des ACL ingress pour filtrer tout ce qui 
n’a rien à faire là (RFC1918, etc…), ou mieux: n’autoriser que ce qui doit 
arriver par l’interface en question si possible.
j'avais pourtant déjà mis du uRPF et des access-group en IN et OUT 
sur le Edge (ASR)


interface GigabitEthernet0/0/2
 
* ip access-group SPOOFING-IN in**
** ip access-group 112 out*
 ip flow ingress (j'ai aussi un netflow collector via nfsen ...)
 ip flow egress
* ip verify unicast reverse-path**
*
asr1-evry#show access-lists SPOOFING-IN  (je deny en IN des IP de mon 
network qui seraient spoofées depuis l'exterieur !)

Standard IP access list SPOOFING-IN
20 deny   X.Y.0.0, wildcard bits 0.0.255.255
30 permit any (2658219251 matches)

asr1-evry#show access-lists 112 (ACL en out qui m'a permis de 
detecter le pb par effet de bord ...)

Extended IP access list 112
10 deny ip 192.168.1.0 0.0.0.255 any log-input (44452922 
matches)  => mon pb du moment
20 deny ip 192.168.0.0 0.0.255.255 any log (4847 matches) => il 
faut que j'ajoute les autres subnet RFC1918 

40 permit ip any any (1058619881 matches)

mais effectivement je ne filtre pas les RFC1918 sur le Core (6500)
il va falloir que

Re: [FRnOG] [TECH] Deni de service en src 192.168.1 sur Cisco ASR / 6500

[jehan procaccia INT]

Le 23/07/2015 18:40, David Ponzone a écrit :

Il serait peut-être temps de mettre des ACL ingress pour filtrer tout ce qui 
n’a rien à faire là (RFC1918, etc…), ou mieux: n’autoriser que ce qui doit 
arriver par l’interface en question si possible.
j'avais pourtant déjà mis du uRPF et des access-group en IN et OUT sur 
le Edge (ASR)


interface GigabitEthernet0/0/2
 
* ip access-group SPOOFING-IN in**
** ip access-group 112 out*
 ip flow ingress (j'ai aussi un netflow collector via nfsen ...)
 ip flow egress
* ip verify unicast reverse-path**
*
asr1-evry#show access-lists SPOOFING-IN  (je deny en IN des IP de mon 
network qui seraient spoofées depuis l'exterieur !)

Standard IP access list SPOOFING-IN
20 deny   X.Y.0.0, wildcard bits 0.0.255.255
30 permit any (2658219251 matches)

asr1-evry#show access-lists 112 (ACL en out qui m'a permis de detecter 
le pb par effet de bord ...)

Extended IP access list 112
10 deny ip 192.168.1.0 0.0.0.255 any log-input (44452922 matches)  
=> mon pb du moment
20 deny ip 192.168.0.0 0.0.255.255 any log (4847 matches) => il 
faut que j'ajoute les autres subnet RFC1918 

40 permit ip any any (1058619881 matches)

mais effectivement je ne filtre pas les RFC1918 sur le Core (6500)
il va falloir que je vérifie comment améliorer ces filtrages .

Concernant la charge d'un ASR pour 50Kps qui sature a cause des ACL en 
mode "LOG" ,
je pense probablement que c'est cet aspect LOG qui sature et non le 
forward de 50Kps sur une telle bête de course

d'ailleurs les messages sur la console indiquent bien ça:

Jul 22 10:19:43 157.159.8.3 1852677: Jul 22 06:47:33.609: 
%IOSXE-3-PLATFORM: F0: cpp_cp: QFP:0.0 Thread:025 
TS:00025904738204986240 %*PKTLOG-3-PKTLOG_IPC_SEND_FAILED*: IPv4 ACL log 
Tail Drop


je serait bien tenté de retirer l'option LOG de mon ACL outgress, mais 
inversement, sans ça je n'aurai pas été alerté de la présence de trafics 
illégitimes .
un vrais IDS sur le LAN serait peut-etre plus approprié, mais mettre une 
boites noires a  sur un LAN comprenant plusieurs dizaine 
d'interfaces 10G et Centaines 1G me parait budgétairement inabordable . 
On avait bien un carte FWSM (firewall module) dans le 6500E , mais elle 
est deprecated ...


je vais m'orienter vers une application des traditionnels filtres 
in/outgress sur mon Core 6500E


http://www.cisco.com/c/en/us/support/docs/ip/access-lists/43920-iacl.html
http://www.techrepublic.com/article/prevent-ip-spoofing-with-the-cisco-ios/
https://www.revelify.com/ingress-and-egress-filtering-with-acls/

Merci pour les conseils .

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

Re: [FRnOG] [TECH] Deni de service en src 192.168.1 sur Cisco ASR / 6500

[jehan procaccia INT]

Le 23/07/2015 10:42, Clement Cavadore a écrit :


5) comment remonter et identifier la source du pb, probablement un
PC/portable mal configuré infecté et qui se crois sur une livebox ou
autre subnet home office !?
Essaye de choper l'adresse MAC via ton port mirroring, et remonte le
réseau L2 jusqu'à trouver le port de switch auquel cette MAC est
rattachée ?


Merci pour vos réponses
je comprend mieux maintenant comment ce trafic peut-etre etre routé 
malgres mes efforts pour le dropper !


apres avoir remonté la source jusqu'a mon coeur de reseau (6500) grace 
au port miroring sur ASR (SPAN) cf

http://www.cisco.com/c/en/us/support/docs/routers/asr-1000-series-aggregation-services-routers/116212-configure-asr-00.html
nouveau port miroring sur 6500 , cf
http://www.cisco.com/c/en/us/support/docs/switches/catalyst-6500-series-switches/10570-41.html#anc45

j'ai du encore luter avec tcpdump car l'interface  en question est un 
trunk et il a fallu jouer avec la prise en charge des vlan dans le filtre:


# tcpdump -nnv   -e "udp or (vlan and (udp or tcp) and src net 
192.168.0.0/22)" -i em2 -w capture-g2-21-6509-2015-07-23-17H00-192.168.cap

# tcpdump -nnve -r capture-g2-21-6509-2015-07-23-17H00-192.168.cap

j'ai capturé donc ce genre de trame

17:17:12.612962 *10:bd:18:e4:80:80* > 00:07:7d:33:9f:00, ethertype 
802.1Q (0x8100), length 66: vlan 8, p 0, ethertype IPv4, (tos 0x0, ttl 
116, id 11394, offset 0, flags [DF], proto TCP (6), length 48)
*192.168.1.101*.3751 > 104.37.247.30.80: Flags [S], cksum 0x3f63 
(correct), seq 2737270860, win 65535, options [mss 1460,nop,nop,sackOK], 
length 0


où j'ai enfin un match entre l'adresse IP  et une @MAC .

=> j'esperais trouver ça bcp plus facilement avec un
6509E#show arp | incl 192.168.1.101
mais curieusement, cela ne donne jamais rien ,
meme #show mac address-table | incl 10:bd:18:e4:80:80 ne donne rien !?
heureusement qu'il y a tcpdump a coté des équipements cisco ...

Maintenant , il faut que je poursuive vers l'interface source de cette 
MAC , évidement c'est un downlink qui sort de mon LAN , derrière lequel 
je pas la main, je vais poursuivre avec l’enquête avec les admins de 
cette interco .


Je reste quand meme surpris qu'un flood de paquets arrive a mettre a 
genoux un ASR1002 :-( !
on vois sur le graph en nombre de paquets ci-dessous les 2 periodes 
"blanches" ou mon routeur ne repondais quasiment plus (en tout cas au 
moins plus au requetes snmp sources de ce graph)


ASR1002 - Unicast Packets - Gi0/0/2

Merci pour vos conseils .

jehan .

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

[FRnOG] [TECH] Deni de service en src 192.168.1 sur Cisco ASR / 6500

[jehan procaccia INT]

bonjour,

je constate sur mon routeur Edge (type ASR 1002)  de campus, un trafic 
illégitime (je suppose), par intermittence qui sature les performances 
du routeur (et/ou switch coeur de LAN en amont)

et a pour fâcheux effet de bord de ralentir tous les trafics du campus .
voici le genre de message que je reçois par centaines en qq secondes sur 
la console de l'ASR quand cela se produit:



Jul 22 10:19:43 157.159.8.3 1852677: Jul 22 06:47:33.609: 
%IOSXE-3-PLATFORM: F0: cpp_cp: QFP:0.0 Thread:025 
TS:00025904738204986240 %PKTLOG-3-PKTLOG_IPC_SEND_FAILED: IPv4 ACL log 
Tail Drop
Jul 22 10:19:43 157.159.8.3 1852678: Jul 22 06:47:33.611: 
%FMANFP-6-IPACCESSLOGP: F0: fman_fp_image:  list 112 denied tcp 
192.168.1.101(1897) -> 198.148.92.247(80), 1 packet
Jul 22 10:19:43 157.159.8.3 1852679: Jul 22 06:47:33.611: 
%FMANFP-6-IPACCESSLOGP: F0: fman_fp_image:  list 112 denied tcp 
192.168.1.101(1836) -> 198.148.92.247(80), 1 packet

...

j'ai en effet une ACL en sortie de site qui interdit tout trafic RFC 
1918 (ici précisément 192.168.0.0 0.0.255.255)  vers any


asr1-evry#show *access-lists 112*
Extended IP access list 112
10 deny ip 192.168.0.0 0.0.255.255 any log (201942501 matches)
20 permit ip any any (3326764632 matches)

interface GigabitEthernet0/0/2
ip *access-group 112 out*

faute d'outils de capture de trafic intrinsec aux équipements réseaux :-(
j'ai pu quand même "mirrorer" mon interface vers une autre et analyser a 
coup de tcpdump le trafic à la recherche de cette IP src 192.168.1.101
cf bon exemple de méthode sur ASR : 
http://www.cisco.com/c/en/us/support/docs/routers/asr-1000-series-aggregation-services-routers/116212-configure-asr-00.html
ainsi j'ai retrouvé l'adresse MAC correpondante à l'IP 192.168.1.101 et 
grâce a cette MAC pu remonter au 6500 coeur de reseau du LAN en amont de 
cet ASR

bref maintenant je pense avoir isoler le switch où la source aboutit.

Questions :
1) je croyais que les @IP RFC1918 étaient par défaut non routées sur les 
équipements réseau !? je me trompe ?


2) j'ai en plus sur l'ASR une route statique qui renvoit 192.168.0.0 
vers Null0 (trou noir)

ip route 192.168.0.0 255.255.0.0 Null0
comment se fait-il qu'en plus de 1) j'ai encore ces paquets ayant pour 
src 192.168.1.101 renvoyés vers mon interface de sortie opérateur (ici 
g0/0/2) ?


3) avez vous une autre méthode (que mon ACL 112 et route statique vers 
Null0)  pour droper ce trafic  ?


4) comment une ip src en 192.168.1.101 peut elle arriver a envoyer du 
trafic vers mon 6500 alors qu'il n'y a pas de gateway/interface de 
routage sur le subnet 192.168.1.0/24

6509E#show ip route 192.168.1.0
% Network not in table

seul un vlan dispose d'un subnet en 192.168*.0*.0/24  (!= 192.168*.1 *)
6509E#show ip route 192.168.0.0
Routing entry for 192.168.0.0/24, 2 known subnets
  Attached (2 connections)
  Variably subnetted with 2 masks
  Redistributing via ospf 1
C192.168.0.0/24 is directly connected, Vlan901
L192.168.0.2/32 is directly connected, Vlan901

5) comment remonter et identifier la source du pb, probablement un 
PC/portable mal configuré infecté et qui se crois sur une livebox ou 
autre subnet home office !?


Merci .

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

Re: [FRnOG] [MISC] RIPE NCC et legacy ressources

[jehan procaccia INT]

Le 04/04/2015 20:21, Jean-Edouard Babin a écrit :

J'abonde aussi dans le sens de devenir LIR et de prendre le controle de vos 
IP/votre AS.
Sinon la seconde option serait de demandé à renater (qui visiblement, gère déjà 
votre AS) de prendre votre /16 (avec les précautions décrite par Jérôme)
En revanche je ne comprend pas le "EARLY-REGISTRATION", le status de votre 
allocation est LEGACY, il restera LEGACY.

---
Liste de diffusion du FRnOG
http://www.frnog.org/
ces dernieres années nous sommes passé dans la base RIPE par du PA (j'ai 
alors repositionné PI, car nous somme "maintainer") puis 
"EARLY-REGISTRATION", maintenant LAGACY ...
on souhaite conserver notre "Independance" (PI, Provider Independant) et 
pouvoir annoncer de maniere autonome nos subnets a differents operateurs 
sans etre soumis a des problématique d'agregation, voire d'origine , on 
a eu des soucis de routage quand a une periode Renater "originait" (au 
sens bgp) notre /16 . Lors d'unemaintenance programmée sur notre interco 
Renater nous avons volontairement annoncé notre réseau via une seconde 
sortie (NeoTelecom, zayo maintenant) afin que notre trafic ne sit pas 
impacté le temps de la manipe.A cause de cette "origine statique" 
Renater aspirait alors notre trafic vers une mauvaise gateway .
On reste très fidèle a Renater en terme de transit, qualité et services, 
mais on souhaite disposer de cette option de routage alternative quand 
cela nous est utile (parfois meme pour des besoins pédagogiques !) .

bref, il nous semble indispensable de rester PI,
1) est-ce que devenir membre RIPE remet en cause cet etat de fait ?
2) ne rien faire (autruche) , est il risqué ?
3) cela ne coute pas rien .. 1600$ d'annual free .
enfin, ce qui m'a aussi un peu alerté c'est ce "vieil" article poussé 
par notre amis S.Bortzmeyer il y a qq années :

http://www.computerworld.com/article/2514777/internet/protect-your-pre-1997-ip-address.html
a méditer .

Jehan .



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

[FRnOG] [MISC] RIPE NCC et legacy ressources

[jehan procaccia INT]

bonjour,

nous disposons d'un réseau /16 depuis la fin des années 1980's debut 
90's (attribution Inria via internic à l'epoque je crois ...?)
il a été transféré à l'ARIN jusqu'en 2004 , puis , jusqu’à maintenant, 
apparait dans la base RIPE .
RIPE nous sollicite afin de devenir membre pour formaliser 
l'appartenance de ce réseau à leur RIR de ce que je crois comprendre de:

https://www.ripe.net/lir-services/resource-management/legacy-resources/ripe-ncc-services-to-legacy-internet-resource-holders

je ne dois pas etre le seul a etre sollicité par cette démarche du RIPE ?
si c'est le cas, que recommandez vous parmi les propositions faites :

As specified in section 2.0 of the new policy, each legacy Internet resource 
holder has the following options:

- Extend the existing contract by registering their legacy Internet resources 
(if already a RIPE NCC member)
- Become a member of the RIPE NCC
- Engage via a sponsoring LIR
- Engage directly with the RIPE NCC
- Opt not to establish a formal relationship with the RIPE NCC


nous souhaitons conserver notre indépendance, et surtout notre statut de 
Early Registration (ERX) et Provider Independant.
disposant de 2 ISP (dual homing BGP)  il est important pour nous de 
pouvoir annoncer nos routes comme bon nous semble à différents opérateurs .


Merci pour vos remarques, conseils .

Jehan .


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

Re: [FRnOG] Re: [ALERT] Nouvelle faille openssl

[jehan procaccia INT]

Bonsoir,

le script nmap fonctionne tres bien et est tres efficace pour scanner en 
masse , merci ,
maintenant je m'interroge sur sa capacité a tester d'autres services 
ssl/tls que https/443 ?
serait-il capable de trouver une vulnérabilité dans openssh (22) imaps 
(993), smtps (465) , ldaps (636) ?
des scan 443 ont révélés la faille sur des serveurs non encore updatés, 
mais sur les ports 22,993,465 et 636 je n'ai encore rien trouvé sur de 
tels serveurs.
soit le script n'est pas adapté, soit ces autres services utilisent une 
autre librairie ?


Jehan .

Le 09/04/2014 17:02, Nicolas GOLLET a écrit :

Bonjour à tous,

pour scanner rapidement si vous avez des équipements/serveurs vulnérable il
existe un script nmap pour ça sur leur svn :)
https://svn.nmap.org/nmap/scripts/ssl-heartbleed.nse

exemple : nmap -p 443 --script ssl-heartbleed.nse 192.168.1.0/24

Un service en ligne a aussi ouvert : http://filippo.io/Heartbleed/
(source dispo en python sur github)

Nicolas




2014-04-09 16:52 GMT+02:00 Stephane Bortzmeyer :


On Tue, Apr 08, 2014 at 09:56:41PM +0200,
  Stephane Bortzmeyer  wrote
  a message of 13 lines which said:


Et n'oubliez pas que vos routeurs Juniper ont OpenSSL...

Pour Cisco :


http://blogs.cisco.com/security/openssl-heartbleed-vulnerability-cve-2014-0160-cisco-products-and-mitigations/


---
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] Terminal de paiement électronique et Completel

[jehan procaccia INT]

Les avis et expériences semblent unanimes
j'ai effectivement demandé un routage via T0 et 3/4 des TPE semblent 
passer maintenant ...
pourtant completel m'assure ne pas compresser, ils utilisent du G711 sur 
les T2
maintenant il y a la conversion RJ -> optique, le mediagateway qui fait 
peut-etre de la paquetisation sans compter le transfert sur un autre 
reseau (SFR car les 0811. qu'appelle le TPE seraient chez SFR ...!?) 
qui fait lui aussi peut-etre de la compression+voIP, bref un 
enchainement d'obstacles à la fluidité d'un trafic data .


Je vais étudier l'option TPE via IP, commercialement c'est quand meme 
116EUR de FAS + 5EUR d'abonnement suplementaire par mois par rapport au 
traditionel RTC . Ce qui m'inquiete le plus c'est la securité IP, le 
revendeur n'a pas été clair sur l'adressage, qui fournis l'@IP moi ou la 
banque ?, une IP publique / privée ? , un VPN ?, tout ceci reste obscure 
pour un service monétique .


Merci pour vos conseils .

Le 17/06/2013 23:24, Adrien Pestel a écrit :


La Data (fax, Modem, TPE mais également télé alarme) encapsulée dans 
de la ToIP est très sensibles lors de la phase de paquetisation a la 
perte des dits paquets mais également a la compression.


De part la nature de son protocole de transport (UDP) cela le rend 
très fragile (pas de réémission en cas de perte de paquets). Idéal 
pour de la voix (faible latence), catastrophique pour la data (pas de 
garantie d'acheminement).


Si completel utilise un codec G729 c'est perdu de base.

Pour le reste les tests et résultats sont souvent très aléatoires.

Le mieux est de garder une T0 chez Orange ou de passer a un TPE IP.

Mes 2 cents.
Adrien

Le 17 juin 2013 22:23, "jehan procaccia INT" 
mailto:jehan.procac...@int-evry.fr>> a 
écrit :


bonjour,

depuis qu'on est passé a completel pour l'acheminement de nos
appels telephonique (autocom Matra 6500 <-> T2 sur MediaGateway
3200 en Fibres completel), tous nos terminaux de paiement
electroniques (TPE) derrière l'autocom (donc en SDA) échouent à
l'envoie des transactions bancaires. Suis-je un cas isolé, ou bien
existe t-il une réelle incompatibilité,
est-ce que qq'un a aussi subit ce genre de problème, a trouvé une
solution !?

Merci.


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




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

[FRnOG] [TECH] Terminal de paiement électronique et Completel

[jehan procaccia INT]

bonjour,

depuis qu'on est passé a completel pour l'acheminement de nos appels 
telephonique (autocom Matra 6500 <-> T2 sur MediaGateway 3200 en Fibres 
completel), tous nos terminaux de paiement electroniques (TPE) derrière 
l'autocom (donc en SDA) échouent à l'envoie des transactions bancaires. 
Suis-je un cas isolé, ou bien existe t-il une réelle incompatibilité,
est-ce que qq'un a aussi subit ce genre de problème, a trouvé une 
solution !?


Merci.


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

Re: [FRnOG] [TECH] multihome BGP avec annonces conditionnelles et statiques

[jehan procaccia INT]

bonjour,

la methode suivante fonctionne partiellement mieux:

router bgp ASNUM
neighbor x.x.x.x advertise-map QQ-PREFIX exist-map 1ST-ISP-UP
neighbor x.x.x.x advertise-map MY-PREFIXES non-exist-map 1ST-ISP-UP
neighbor x.x.x.x route-map MY-PREFIXES out

en mode nominal (ISP primaire UP) j'annonce bien mes QQ-PREFIX à l'ISP 
secondaire
en cas de perte de l'ISP primaire j'annonce bien dynamiquement tous mes 
prefixes MY-PREFIXES  à l'ISP secondaire
mais malheureusement je n'annonce plus les prefix QQ-PREFIX dans cette 
situation, en effet "exist-map 1ST-ISP-UP" n'est plus vrai, donc je 
suppose qu'il élimine les prefix QQ-PREFIX qui sont inclus dans 
MY-PREFIXES et n'annonce que le reste des MY-PREFIXES .


Bref c'est mieux, mais ce n'est pas encore satisfaisant pour assurer le 
trafic engineering attendu , en effet quand l'ISP primaire est tombé, 
les QQ-PREFIX qui profitaient d'un trafic engineering via les 2eme ISP 
se retrouvent coupé du monde car ils ne sont plus annoncés au 
secondaire, alors même que ce dernier (ISP 2) n'a subit aucune perte  !


J'ai bien entendu les differentes suggestions concernant l'AS-Prepend, 
j'avais commencé par ça, mais malheureusement ce n'est pas déterministe, 
il y aura toujours qq-part sur le chemin un ISP qui se foutra de la 
longueur de l'AS-PATH et favorisera son peering gratuit plutôt qu'un 
transit $$$
c'est du vecu, j'avais au moins 30% du trafic qui ne prenait pas le 
chemin retour attendu pas l'as-prepend :-( .


Si qq'un a encore une meilleur idée, je reste a l'écoute, je suis 
surpris que BGP ne sache pas gérer ça !?



Le 01/03/2013 20:05, Ccde Cissp a écrit :

Bonjour,

Effectivement, vue cette "histoire" de AND Logique entre les 
différentes maps définies. Vous pouvez par exemple tester:


1. Et là (je pense que) ce notre dernier espoir avec les annonces 
conditionnelles :-)


router bgp ASNUM
  neighbor x.x.x.x advertise-map QQ-PREFIX exist-map 1ST-ISP-UP
  neighbor x.x.x.x advertise-map MY-PREFIXES non-exist-map 1ST-ISP-UP
  neighbor x.x.x.x route-map MY-PREFIXES out

2. Sinon, il faut jouer avec l'AS  PATH PREPENDING ou toute autre 
chose influençant le trafic INBOUND autre que les annonces 
conditionnelles via des "advertise map"...



Bien cordialement,
Fethi


*De :* "touremoha...@gmail.com" 
*À :* jehan.procac...@int-evry.fr; frnog-t...@frnog.org
*Cc :* ccdeci...@yahoo.fr
*Envoyé le :* Vendredi 1 mars 2013 15h38
*Objet :* RE : Re: [FRnOG] [TECH] multihome BGP avec annonces 
conditionnelles et statiques


Bonjour,

Une piste peut eventuellement etre testee. Il s'agit de voir si on 
peut cumuler une exist-map et une non-exist-map pour le meme peer bgp.


Si on note A la liste des 55 prefixes annonces a l'ISP1 et B la liste 
des 5 prefixes annonces a l'ISP2.


On annonce inconditionnellement A a l'ISP1. On annonce B a l'ISP2 si 
exist-map XXX (a definir).
On annonce A et B si non-exist-map YYY (a definir). De sorte que si 
ISP1 down les 60 prefixes sont annonces a l'ISP2.


Une autre piste : utiliser as-path prepend.
On annonce A vers ISP1 sans modification.
On annonce B vers ISP2 sans modification.
On annonce A vers ISP2 avec un as-path prepend.
Internet recevra les prefixes (s'il nya pas d'alteration des ISP : 
summarization, modif ...) et l'ISP1 sera prefere pour la liste A et 
ISP2  pour la liste B. Si la session vers ISP1 est down alors l'ISP2 
sera prefere.


Bien sur, il ya d'autres pistes :).

Cordialement
Mohamed Toure



--
Envoyé de mon téléphone Nokia

--Message original--
De : jehan procaccia INT <mailto:jehan.procac...@int-evry.fr>>
To: "frnog-t...@frnog.org <mailto:frnog-t...@frnog.org>" 
mailto:frnog-t...@frnog.org>>

Cc: "Ccde Cissp" mailto:ccdeci...@yahoo.fr>>
Date: vendredi 1 mars 2013 12:25:54 GMT+0100
Subject: Re: [FRnOG] [TECH] multihome BGP avec annonces 
conditionnelles et statiques


Le 28/02/2013 22:45, Ccde Cissp a écrit :
> Hello,
>
> Je n'ai pas très bien compris votre question et je souhaite vous
> demander quelques informations:
>
>
>  1. Concernant votre conf: Pourquoi vous annoncer la même chose
> (MY-PREFIXES) au même neighbor (x.x.x.x) avec deux façon différentes
> alors que votre but ultime c'est d'annoncer " MY-PREFIXES" si et
> seulement si la condition "non-exist-map est vérifiée et donc la ligne :
>  "neighbor x.x.x.x advertise-map MY-PREFIXES non-exist-map 1ST-ISP-UP"
> suffira pour satisfaire votre 1ère condition.
>  ! La ligne de conf:  "neighbor x.x.x.x route-map MY-PREFIXES out": je
> ne vois pas son intérêt ici elle n'apporte rien vis à vis de vos 2
> con

Re: [FRnOG] [TECH] multihome BGP avec annonces conditionnelles et statiques

[jehan procaccia INT]

Le 28/02/2013 22:45, Ccde Cissp a écrit :

Hello,

Je n'ai pas très bien compris votre question et je souhaite vous 
demander quelques informations:



  1. Concernant votre conf: Pourquoi vous annoncer la même chose 
(MY-PREFIXES) au même neighbor (x.x.x.x) avec deux façon différentes 
alors que votre but ultime c'est d'annoncer " MY-PREFIXES" si et 
seulement si la condition "non-exist-map est vérifiée et donc la ligne :

 "neighbor x.x.x.x advertise-map MY-PREFIXES non-exist-map 1ST-ISP-UP"
suffira pour satisfaire votre 1ère condition.
 ! La ligne de conf:  "neighbor x.x.x.x route-map MY-PREFIXES out": je 
ne vois pas son intérêt ici elle n'apporte rien vis à vis de vos 2 
conditions que vous souhaitez mettre en oeuvre.
cette deuxième ligne est nécessaire, car sans elle je n'annonce pas 
MY-PREFIXES quand la condition est vraie (1st ISP is down)
c'est du vecu , certes empirique car je trouve ça aussi apparemment 
redondant, mais je constate que je n'annonce tj rien sans cette ligne 
meme si l'ISP primaire est down :-( .


2. Je vous conseille de faire un test/LAB avec seulement: "neighbor 
x.x.x.x route-map QQ-PREFIX out" et voir si l'interaction avec
 " neighbor x.x.x.x advertise-map MY-PREFIXES non-exist-map 
1ST-ISP-UP" est un AND LOGIC ou pas càd si le résultat de deux types 
d'annonce utilisés simultanément est l'annonce de l'intersection entre 
les deux ensemble "QQ-PREFIX" et "MY-PREFIXES" qui sera dans ce cas 
l'ensemble "QQ-PREFIX".

apparement c'est plutot un AND
j'ai mis en 2eme ligne "neighbor x.x.x.x route-map QQ-PREFIX out", tout 
en gardant en 1er ligne

 "neighbor x.x.x.x advertise-map MY-PREFIXES non-exist-map 1ST-ISP-UP"
quand l'ISP primaire est UP, rien n'est annoncée (j'aurai esperé voir 
QQ-PREFIX)

et quand l'ISP primaire est Down alors seulement QQ-PREFIX est annoncé:

Edge2#show ip bgp neighbors x.x.x.x advertised-routes
   Network  Next HopMetric LocPrf Weight Path
*> X.X.21.0/24  p.p.p.p2 32768 i

Edge2#show ip route X.X.21.0
Routing entry for X.X.21.0/24
  Known via "ospf 1", distance 110, metric 2, type extern 1
  Redistributing via bgp 
  Advertised by bgp  match internal external 1 & 2

ce n'est pas le resultat attendu, je voulais voir MY-PREFIXES annoncés 
au minimum et au mieux MY-PREFIXES + QQ-PREFIX (ps: l'unique /24 
QQ-PREFIX actuellement dans mon test/lab est contenu dans MY-PREFIXES, 
cela a peut-etre une incidence ?).


3. Remarque: Le résultat que vous avez pu voir et que vous avez décrit 
dans:

"neighbor x.x.x.x route-map QQ-PREFIX out
cette ligne écrase alors "neighbor x.x.x.x route-map MY-PREFIXES out"

serait du à un AND LOGIC entre les deux lignes de conf qui sont ici 
équivalentes de point de vue syntaxe. A vérifier, donc, que cet AND 
LOGIC n'existe pas entre deux syntaxes d'annonces différentes:


"neighbor x.x.x.x route-map QQ-PREFIX out"
et
 " neighbor x.x.x.x advertise-map MY-PREFIXES non-exist-map 1ST-ISP-UP"
malheureusement cet apparent "AND logic" semble exister dans ce cas 
d'apres l'experience ci-dessus


comment cumuler ces 2 lignes !?

Merci .


a mon avis le AND logic persistera, à confirmer car cela dépend du 
code constructeur.
Please ;) dites nous les résultats de vos tests. Si vos deux 
conditions ne seront pas vérifiées (fort probable), il faut intervenir 
des nouveaux ingrédients :)


Cordialement,
Fethi


*De :* jehan PRocaccia 
*À :* frnog-t...@frnog.org
*Envoyé le :* Jeudi 28 février 2013 13h09
*Objet :* [FRnOG] [TECH] multihome BGP avec annonces conditionnelles 
et statiques


Bonjour,

je suis "end user" avec 2 FAI, je souhaite annoncer quelques prefixes 
(5) au second FAI afin de favoriser le trafic entrant pour ces qq 
prefixes via le 2nd FAI (plutot que le FAI primaire) , tout en 
bénéficiant d'un mécanisme automatique d'annonce de tous mes prefixes 
(60) au secondaire en cas de défaillance totale du FAI primaire .
Je n'annonce pas tous mes préfixes aux 2 FAI en parallèle car je ne me 
sert du 2em FAI qu'en cas de backup et/ou de trafic engineering sur 
certains prefixes sélectionnés suivant les besoins du moment.
j'ai bien réussi dans le cadre de ce dual homing BGP a annoncer de 
manière conditionnelle tous mes prefixes au second FAI seulement quand 
le primaire est défaillant => annonce bgp au 2eme FAI conditionnée  
sur la présence ou non d'une route venant du FAI primaire.

En termes technique:

router bgp ASNUM
neighbor x.x.x.x advertise-map MY-PREFIXES non-exist-map 1ST-ISP-UP
neighbor x.x.x.x route-map MY-PREFIXES out
show route-map 1ST-ISP-UP
  Match clauses:
ip address (access-lists): 3
Standard IP access list 3
10 permit Y.Y.Y.Y, wildcard bits 0.0.0.7 log (4604 matches)

Y.Y.Y.Y = reseau interco avec FAI primaire et route-map MY-PREFIXES 
contiens tous mes prefix


Cette solution est satisfaisante, sauf que dans cette configuration, 
je n'arrive pas a annoncer au 2em FAI en complément mes q