Re: [FRnOG] [ALERT] OVH down ?

[Raphael Mazelier]

Le 29/07/15 22:22, Frederic Dhieux a écrit :


Et OVH a souvent fait preuve d'une certaine transparence appréciable
quand ils font des erreurs.


Et sur ce coup la encore. Le commentaire d'octave est d'ailleurs assez 
savoureux.




C'est surtout les clients qui se scandalisent alors qu'ils payent une
misère tous les mois pour plein de services que je critique :)



+1

Cela me fait toujours rire les clients qui se plaignent que leurs 
services hébergés sur un seul serveur chez un hébergeur (lowcost ou pas) 
est down, et que c'est inadmissible. Si leurs services étaient si 
critique il faudrait peut etre penser à les redonder sérieusement. C'est 
à dire sur différents DCs et possiblement chez deux hébergeurs.




--
Raphael Mazelier



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

Re: [FRnOG] [TECH] Routeur intermediaire pour aiguiller le trafic vers différentes adsl

[Raphael Mazelier]

Le 31/07/15 15:59, Julien Escario a écrit :


Marrant c'est exactement la logique qui fait que Cisco fait encore du chiffre.
Y'en a pas d'autre. #trolldi



Pas que. Certaines gammes cisco sont très bien.
Maintenant sur ce besoin spécifique c'est vrai que n'importe quel petite 
box sous linux, bsd ferait aussi bien le boulot, voir mieux.


--
Raphael Mazelier


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

Re: [FRnOG] [TECH] Re: VRF et PPP

[Raphael Mazelier]

Le 29/07/15 06:25, Youssef Bengelloun-Zahr a écrit :

Hello,

Il peut y avoir toutes sortes de bonnes / mauvaises raisons à cela.



Je peux comprendre le concept de dédier une interface pour le 
management. En revanche si on fait ça il faut pousser le concept 
jusqu'au bout, et donc dédier une vrf à cela. Mais une vrai vrf qui peut 
gérer tout le trafic de management. Hors donc à ma connaissance ce n'est 
pas encore tout à fait au point chez les différents constructeurs.


--
Raphael Mazelier



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

Re: [FRnOG] [TECH] Routeurs pour relier 3 sites en 10Gbps

[Raphael Mazelier]

Le 10/11/15 21:58, j...@igwan.net a écrit :

Le 2015-11-10 16:00, Radu-Adrian Feurdean a écrit :

IPv6 ca fonctionne correctement, pas de choses bizarres ?


L'impossibilité de faire de la résolution de next-hop BGP à partir de
routes OSPFv3 (bug qui traîne depuis plus de 5 ans...)

http://forum.mikrotik.com/viewtopic.php?t=42268

Le truc de base.

On a testé. C'est un no-go pour nous question IPv6.



Je viens de lire, l'ipv6 avec des routes statiques, quelle rigolade.
Et évidement pas de support d'ISIS (pour moi ça c'est un nogo pour un 
core network). Dommage car le matériel a vraiment l'air intéressant et 
d'un bon rapport qualité prix, mais l'OS pas encore au niveau.
D'ailleurs pourquoi ne pas opensourcer ces plateformes ? ca serait 
tellement plus malin de la part de microtik.


--
Raphael Mazelier



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

Re: [FRnOG] [TECH] Routeurs pour relier 3 sites en 10Gbps

[Raphael Mazelier]

Sur ce point précis je confirme. Dans toutes les boites ou je suis 
passé, il était inconcevable d'allouer deux IP pubs a chaque CPEs, 
quelque soit le mode d'interco. En ppoX pas de soucis, mais en statique 
non plus. Et tout les CPE utilisés accepté ce genre de truc (ça revient 
juste a router une loopback, truc pas impossible).




Le 12/11/15 14:08, David Ponzone a écrit :

On retombe sur un débat qui a déjà eu lieu ici plusieurs fois (on est coincés 
dans une boucle temporelle ?) mais dans ce cas, tu peux mettre un /30 en 
RFC1918 sur le WAN et une IP publique en /32 sur le CPE.
Ca marche pas chez tout le monde, mais ça marche chez Cisco, et chez Mikrotik.
Ca marche aussi sur Technicolor (conf pas simple).
Et probablement pour d’autres.

Ceci dit, je préfère aussi le /31 sur le WAN :)



--
Raphael Mazelier


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

Re: [FRnOG] [TECH] Failover en cas de défaillance routeur BGP

[Raphael Mazelier]

D'une maniéré générale il est considéré comme bonne pratique, que les 
routes présentes dans les protocoles de routage dynamique le soit par 
redistribution (soit de statique, soit de connected).



Le 02/11/15 16:23, David Ponzone a écrit :

redistribute static

Attention à filtrer vers tes transitaires pour ne pas leur renvoyer tes /32 :)



--
Raphael Mazelier


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

Re: [FRnOG] [TECH] Failover en cas de défaillance routeur BGP

[Raphael Mazelier]

Le 03/11/15 09:58, Jérôme BERTHIER a écrit :


BFD ne serait pas plus adapté pour faire ça ?



BFD aide a une détection ultra rapide, mais en général ta session IBGP 
doit tomber car ta loopback a disparu de ton IGP. Donc un IGP bien tuné 
est le premier truc à faire.


--
Raphael Mazelier


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

Re: [FRnOG] [TECH] Failover en cas de défaillance routeur BGP

[Raphael Mazelier]

Le 03/11/15 15:18, Fabien H a écrit :


@Raphael

Oui c'est ça, les /32 sont envoyés sur différents équipements : LNS, FW
puis par exemple sur le LNS, il y'a une interface avec un masque en /31





Dans ce cas le mieux c'est que tes équipements FW/LNS annoncent leurs 
préfixes aux deux routeurs via le protocole de ton choix (BGP est 
souvent un bon choix).



--
Raphael Mazelier


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

Re: [FRnOG] [TECH] Bouquin pour se former sur l'automatisation réseau

[Raphael Mazelier]

Bonjour,

C'est un sujet à la mode, et pour le coup ce n'est pas une mode 
passagère. Je ne suis toutefois pas certain qu'il existe un livre tout 
en un.


En revanche il existe des ressources sur le grand nain ternet, à 
commencer par l'indispensable ipspace, et des ressources plus 
spécialisées tel https://pynet.twb-tech.com/ que tu as du trouver.


Et bien sur comme mentionné par mes collègues, tu peux acheter chez 
Oreilly un certain nombre d'excellents bouquins sur python.


Tu pourras aussi regarder la documentation de Juniper PyEZ , et celle du 
module Junos Ansible, si tu travaille avec ce constructeur.


Pour les autres constructeurs je suis moins au fait, mais je sais que 
des gens très bien on travaillé sur une couche d'abstraction 
multi-vendeur (poke criteo team).


Dans tous les cas je suis disponible pour en discuter, car c'est un 
sujet qui me tiens à cœur.


Le 05/11/15 15:38, Louis a écrit :

Bonjour la mailing-list,

je recherche un bouquin pour se former sur l'automatisation réseau : techno
NETCONF, PYTHON, ANSIBLE et j'en passe.

Le but est de mettre en place de l'automatisation de configuration normée
(toujours identiques aux descriptions de ports, vlans et IP près).

Vous avez des idées?



--
Raphael Mazelier


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

Re: [FRnOG] [TECH] Juniper NFX 250

[Raphael Mazelier]

Le 04/11/15 13:57, Jérôme BERTHIER a écrit :


A priori, il va y avoir aussi quelques nouveautés prochainement sur la
gamme sécurité.



Tout à fait. L'adoption de la norme RoHS2 a effectivement précipité le 
départ d'un certain nombre de modèle chez Juniper. Sont concerné les 
gammes EX, SRX, et NS (mais bon Netscreen c'est fini).


Coté SRX il y a des nouveaux modèles en préparation pour combler les 
vides laissés, avec des performances meilleures, et une gamme que je 
trouve rationalisée.


(comme d'habitude plus de détail chez les sales juniper).

--
Raphael Mazelier


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

Re: [FRnOG] [TECH] Failover en cas de défaillance routeur BGP

[Raphael Mazelier]

Back to basic.

Ton AS ne devrait jamais être disjoint.
Dépendant de ta localisation de tes deux datacenters, le mieux c'est 
quand même de prendre une dark. Si tu ne peux pas tu utilise deux l2l, 
voir un l2l avec backup sur Gre.


2eme point : on redit, tu fait tourner un IGP entre des deux routeurs 
(Ospf, Isis) juste pour les loopbacks de tes routeurs (et les intercos 
si tu veux). Et tu montes tes sessions Ibgp entre ces loopbacks de 
sortes que te sessions IBGP ne doivent jamais tombés (sauf si faillure 
du routeur, mais faillure de path). Et dans ton IBGP tu mets ce que tu 
veux, tes mores specifics (dans ton cas tes /32).




Le 02/11/15 10:23, Fabien H a écrit :

Mais d'ailleurs, 2 lan2lan de 2 fournisseurs différents en place sur le
même SW de part et d'autre ne risquent pas de mal fonctionner ? C'est
transparent ?

Le 2 novembre 2015 09:50, Clement Cavadore  a écrit :


On Mon, 2015-11-02 at 09:41 +0100, Oceanet - Cédric BASSAGET wrote:

Ça c'est la solution quand y'a des sous ;)


Faut se donner les moyens de ses ambitions...  Surtout vu les prix
moyens des lan2lan datacenter-datacenter, de nos jours :-)

--
Clément Cavadore




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




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

Re: [FRnOG] [MISC] RE: switch OS open source ?

[Raphael Mazelier]

Je suis intimement persuadé que le marché du switch va se trouver 
profondément modifié par les switchs "compatible", comme le fut le 
marché des ordinateurs avec les compatible PC (toute proportion gardé) 
en son temps.


La plupart des constructeurs commencent à proposer des switchs ONIE basé 
sur du merchant silicon.


On devrait se retrouver avec une situation avec d'un coté :

- les vendeurs de silicium (marvel, broadcom, intel)
- les vendeurs de logiciels (cumulus, pica8, dell, juniper, etc...)
- et des solutions intégrés

Enfin j’espère :)

PS : dans un autre registre tu peux regarder ces switchs basés sous 
FreeBsd : http://www.smartcom.bg/our-products/


--
Raphael Mazelier

Le 06/11/15 09:36, Sebastien Maillet a écrit :

Bonjour,

Oui, tu peux regarder du côté de:

http://www.penguincomputing.com/products/network-switches/
http://www.qct.io/Product/Networking/Bare-Metal-Switch-c77c75c159
http://www.edge-core.com/prodCat.asp?c=1


Sinon, jeter un œil aussi à ce lien pour la partie OS:
http://opennetlinux.org/

J'ai commencé à m'y intesser mais n'ai pas encore eu le temps de tester/valider.
Ce sera chose faite pour S1 2016 normalement.
Si tu avances dans ton projet et que tu as la possibilité de partager ton 
expérience, je suis preneur.

Merci.



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

Re: [FRnOG] [TECH] Failover en cas de défaillance routeur BGP

[Raphael Mazelier]

Question : tes /32 correspondent a quoi ? des IPs de services sur des 
serveurs ?


Et sinon oui tu mes les /32 sur tes deux routeurs avec des poids différents.



Le 03/11/15 15:06, Montgomery SIMONPIETRI a écrit :

Hmmm l'autre option peut être encore plus simple serait simplement de
mettre un poids supérieur à BGP dans la route.


Sur R1 :

ip route 5.6.7.1 255.255.255.555 4.4.4.4 name ROUTE_32_R2 250


Si la route BGP disparait (poids de 20 par défaut je crois) alors cest la
statique qui prendrait le relais...

2015-11-03 15:03 GMT+01:00 Montgomery SIMONPIETRI <
montgom...@simonpietri.net>:


Exact ! Il faut inverser la condition ;)

2015-11-03 15:01 GMT+01:00 Fabien H :


Oui, c'est tout à fait ça !

Peut-être juste inverser la condition c'est à dire installer la route
quand R2 n'est pas reachable plutot que quand il est reachable mais
apparemment c'est faisable :

track 456 list boolean and
  object 123 not

Ca commence à être tiré par les cheveux .. ! A voir


Le 3 novembre 2015 14:47, Montgomery SIMONPIETRI <
montgom...@simonpietri.net> a écrit :


Il faudra sans doute dupliquer les routes sur les deux routeurs, mais en
ajoutant du tracking ip sla pour etre sur de les mettre dans la table
uniquement en cas de failover.

Sur R1 :

ip sla 123
  icmp-echo IP_LAN_R2 source-ip IP_LAN_R1
  frequency 5
ip sla schedule 123 life forever start-time now

track 123 ip sla 123 reachability
  delay down 25

ip route 5.6.7.1 255.255.255.555 4.4.4.4 name ROUTE_32_R2 track 123


Et vice-versa sur R2.
Est-ce que je suis à côté ?

Montgomery



2015-11-03 14:28 GMT+01:00 Fabien H :


Bonjour,

merci, si j'ai bien compris, cette solution s'approche un peu du
redistribute en EIGRP mais en BGP. C'est effectivement à tester.

Mais je bloque toujours sur le besoin de failover Routeur BGP.

Si R1 tombe, ses routes disparaissent de la table de R2, et du coup R2
ne pourra pas assurer le failover de R1 pour les routes en /32...

Le 3 novembre 2015 14:16, Montgomery SIMONPIETRI <
montgom...@simonpietri.net> a écrit :


Bonjour,

Est-ce que vous avez pensé à mettre une solution avec du "redistribute
static route-map" pour éviter d'annoncer les /32 et du prepend sur les
prefix a backuper ?



Du style :

ip route 1.2.3.4 255.255.255.0 4.4.4.4 name ROUTE_PRIM_R1 tag 999
ip route 5.6.7.8 255.255.255.0 4.4.4.4 name ROUTE_PRIM_R2 tag 999

access-list 70 permit 5.6.7.8 0.0.0.255 #SUR R1

access-list 70 permit 1.2.3.4 0.0.0.255 #SUR R2

route-map BACKUP-PREPEND permit 10
  match ip address 70
  set as-path prepend 1234

route-map BACKUP-PREPEND permit 20

route-map TAGGED-STATIC permit 10
  match tag 999

router bgp 1234
  redistribute static route-map TAGGED-STATIC
  neighbor PEER_ADDRESS route-map BACKUP-PREPEND out





2015-11-02 9:16 GMT+01:00 Fabien H :


Bonjour la liste,

J'ai une question BGP à vous soumettre :

En 2 mots : Nous sommes opérateur internet avec 2 localisations : Nous
avons 2 routeurs BGP de bordure reliés en IBGP via un L2L.
Sur chaque routeur BGP, nous avons au moins un transitaire.

Tout fonctionne parfaitement !

Actuellement, nous avons un prefixe "localisé" sur le routeur 1 (en
utilisant une route Null0) et un préfixe localisé sur le routeur 2
(idem
route Null0).
Puis pour chaque IP /32 dans le prefixe, nous avons des routes
statiques
sur le routeur BGP concerné.

- Ma question : Nous aimerions mettre en place un failover BGP
automatique
en cas de défaillance matérielle totale d'un des routeurs BGP.

La solution que j'imaginais est de mettre en place, pour un même
prefixe,
une route Null0 sur les 2 routeurs en même temps.

Sur les tests que j'ai fait, ça marche si on duplique la route Null0
sur
les 2 routeurs et si on duplique aussi les routes statiques des IP/32.
=> Si un routeur BGP tombe, l'autre va normalement prendre le relais
sans
problème.

Le seul cas qui pose problème, c'est si les 2 routeurs BGP
fonctionnement
mais que le L2L tombe.

Dans ce cas, un paquet va continuer à arriver par le transit sur le
routeur
BGP concerné, puis la route statique correspondant à l'IP sera
appliquée,
mais l'IP de GW étant normalement accessible via le L2L sur un VLAN
donné,
le routage ne fonctionnera pas car le L2L est tombé.

Ca avait l'air d'être pourtant la bonne méthode .. Avez-vous une
solution à
ce problème ?

Merci,
Bonne journée,
Fabien

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














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




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

Re: [FRnOG] [TECH] Failover en cas de défaillance routeur BGP

[Raphael Mazelier]

Le 03/11/15 17:35, David Ponzone a écrit :

Si tu optes pour iBGP, oublie pas de bien monter tes sessions de tous tes 
LNS/FW/… vers tes 2 routeurs!



Oui ça va mieux en le disant :)

--
Raphael Mazelier


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

Re: [FRnOG] [TECH] Juniper NFX 250

[Raphael Mazelier]

Plof,

Sur le papier ce genre de petit boitier réseau/serveur est très 
intéressant, si le pricing et licensing est adapté.


Je vois plein d'application, comme :
- vrai srx multi tenant
- si vmx, routeur intermédiaire sympa
- contrôleur sdn

Malheureusement pour le moment le datasheet est effectivement confus (ca 
ne parle pas de Mpls ?) Est ce que les licences vsrx, vmx seront 
incluses (et si oui comment ?).


D'un autre coté tu prend n'importe quel serveur avec des cartes Intels 
10G et tu auras la même chose. L'avantage d'avoir un boitier brandé 
Juniper va être faible a part si c'est très bien vendu/packagé.


On sent que Juniper est en pleine transformation de son modèle 
économique, c'est bien ça avance, mais c'est encore en construction.


Peut être plus d'infos avec les sales ou sur j-nsp, à suivre.


Le 03/11/15 19:14, Jérôme Nicolle a écrit :

Plop,

Je viens de voir passer l'annonce du Juniper NFX 250 (0).

Ça a l'air sympa comme bécane : c'est un serveur à base de Xeon, avec
des interfaces SFP/SFP+ et RJ45, et ça tourne un hyperviseur à base de
Windriver Linux pour héberger du vSRX (ou peut être aussi du vMX ?) et
potentiellement des solutions tierces.

Aucune idée du prix pour l'instant, et le modèle de licence vSRX / vMX
m'a l'air particulièrement illisible et inadapté aux petits réseaux.

Avez-vous des infos ou avis sur ce genre de produits ? En gros, ça coute
combien pour utiliser ça comme CPE un peu avancé ?

@+

(0) http://www.juniper.net/us/en/products-services/routing/nfx250/




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

Re: [FRnOG] [TECH] Design réseau L2

[Raphael Mazelier]

Le 08/10/15 06:03, Pascal Gay a écrit :


Trill est propriétaire chez chacun des fournisseurs ;il n'y z guère plus que 
Brocade d'ailleurs à le pousser Cisco et Juniper sont partis sur autre chose) 
mais VXLAN est standard et interopérable certains clients français l'utilisent 
beaucoup en interconnexion de DC



Trill a effectivement implémenté/déformé à la sauce Cisco (FabricPath) 
et Juniper (Qfabric). Et puis est arrivé la virtualisation/cloud et 
toutes les technologies d'overlay. Vxlan en fait partie, mais c'est 
quand même complétement différent, car on parle d'encapsuler du L2 over 
udp (sans parler du traffic de broadcast, ou c'est pire car mappé sur du 
mulicast...).


On s’éloigne du sujet car on parle plutôt de technos datacenter.

Dans le cas de Jeremie :

1) Le meilleur, plus souple, plus simple, plus cher : boucle optique qui 
backhaul vers tes routeurs
2) Backbone mpls supportant vpls (ou autre), mais il te faut des 
routeurs sur chaque pop, assez cher et complexe, mais bonne flexibilité.

3) Une boucle L2 avec ou sans STP (comme un IX à l'ancienne quoi).
Sans doute le moins cher, plus simple, mais le moins résilient.

Cdt,

--
Raphael Mazelier


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

Re: [FRnOG] [MISC] Fwd: [address-policy-wg] 2015-05 New Policy Proposal (Revision of Last /8 Allocation Criteria)

[Raphael Mazelier]

Hello,

Je trouve personnellement que cela est une bonne chose.

La limitation a un dernier /22 avait pour conséquence de multiplier les 
demandes pour devenir LIR pour chaque client (même s'il n’était pas lui 
même opérateur) afin de posséder son petit bout d'internet.

Cela augmentait la dispersion des ressources. (nombre de routes, as)

L'autre soucis que je voyais était pour les nouveaux opérateurs qui font 
de l'access. Le fait de ne plus pouvoir obtenir de nouveaux blocs IPs 
amenait non pas l'ivp6, mais plutôt des solutions bancales comme le cgn 
(ou l'achat de bloc ipv4). Après tout s'il reste encore des ipv4s, 
autant les donner a ceux qui ont réellement besoin ?




--
Raphael Mazelier

Le 20/10/15 16:20, Radu-Adrian Feurdean a écrit :

Bonjour,

Une nouvelle proposition vient d'etre publie, avec le but de modifier
les regles d'allocation d'adresses IPv4 dans la region gere par RIPE
NCC.
Resume:
  - Actuellement il est possible d'avoir une seule allocation, /22
  - La proposition vise a permettre l'allocation de /22 supplémentaires
  tous les 18 mois (a moins qu'il y aura suffisamment de vois pour
  demander plus ou moins de temps), jusqu'a l'epuisement du stock.
  ...sous quelques conditions.

La proposition est dans la phase de discussion, qui s'effectue sur la
liste "Address Policy Working Group" (liste ouverte, mais discussion en
anglais).
Si vous avec une opinion sur cette proposition (j'espere positive :) en
tant qu'un de ceux qui ont cree la proposition) vous pouvez aller faire
entendre votre voix (ce que j'espere surtout si vous trouvez que c'est
une bonne idee).




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

Re: [FRnOG] [BIZ] Mise en place de serveurs en anycast sur différents continents

[Raphael Mazelier]

Pardonnez la question, mais pour que l'anycast soit pleinement
efficace, il ne faut avoir une unicité des transit sur tous les pops ?




Sinon, les localprefs transit<peering

En effet si tu annonces ton bloc d'anycast par transitaire 1 et 2 à New 
York, et par transitaire 2 et 3 à Paris (par exemple), il n'y a rien qui 
te dit que ton trafic fr n'entre pas par transitaire 1 à New York, et 
donc fasse le tour de la planète. Il y a moyen de ruser et de tenter de 
limiter la portée de tes annonces (via les communautés proposé par tes 
transitaires), mais cela reste aléatoire.


--
Raphael Mazelier


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

Re: [FRnOG] [BIZ] Mise en place de serveurs en anycast sur différents continents

[Raphael Mazelier]

Le 08/10/15 17:45, Frederic Dhieux a écrit :




Après sinon prendre du hosting pur à chaque endroit et prendre du Level
3 en direct sur chaque PoP, mais ça va me coûter cher en cross connects,
logistique, gestion administrative et non bundleisé.



Très cher. Déjà aux US les prix de l'hébergement et des cross-connects 
sont plus cher qu'en France, mais dès qu'on attaque l’Asie les prix 
flambent. Vu qu'il s'agit d'un besoin récurrent cela pourrait être 
intéressant de monter une collaboration/association de petits 
opérateurs/hébergeurs pour répondre à ce besoin afin de mutualiser les 
couts fixe, mais je rêve sans doute.


--
Raphael Mazelier


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

Re: [FRnOG] [TECH] Re: Filtrage anti-5060to5060 sur clients Livebox Pro

[Raphael Mazelier]

Le 07/10/15 17:34, David Ponzone a écrit :

Episode 2:

A nouveau, plus de communications SIP possible depuis le client, malgré mon 
changement de port source sur l’équipement du client.
Ca a donc tenu quelques heures.
J’ai rechangé le port source en mettant un port aléatoire entre 5500 et 5900, 
et ça remarche.

Il y a quelque chose de pourri au royaume de Livebox…

Quelqu’un sait s’il y a une sorte d’IDS intégré à la Livebox Pro v3, qui 
pourrait éventuellement prendre certains paquets SIP entre les 2 équipements 
pour une attaque ?
J’ai pas d’autres idées pour le moment.



J'ai pas suivi le thread, mais oui je me rappelle de source sur que la 
livebox fait des trucs très laid avec le sip.
Question : est ce que le port destination est 5060 ou pas ? parce que 
des alg sip pourri j'en ai vu des tonnes.


--
Raphael Mazelier


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

Re: [FRnOG] [TECH] Re: Filtrage anti-5060to5060 sur clients Livebox Pro

[Raphael Mazelier]

Le 07/10/15 17:49, David Ponzone a écrit :

Ouais, 5060 en destination.

Moi aussi j’en ai vu des pourris, mais qui te massacrent ton trafic tout de 
suite, pas qui attendent vicieusement quelques heures en te laissant croire que 
ça marche nickel :)



Malheureusement cela existe. Il est fort probable que la livebox ait 
laissé l'alg sip d'activé par défaut (ou tuné en fonction de leurs 
besoins). Si tu veux t'assurer que cela vient de la livebox il te 
faudrait pouvoir utiliser un port destination différent de 5060.




--
Raphael Mazelier


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

Re: [FRnOG] [TECH] CPE avec VRF

[Raphael Mazelier]

Le 26/08/15 18:40, eandre a écrit :

Oui mais quand le BB est déjà full MPLS ?

Sinon à l’ancienne :

Chaque CPE = 2 tunnels GRE vers une concentration et marquage VRF pour chacun d’eux 
(donc on monte des tunnels à travers le MPLS) ou comment passer de A2A à du HS 
:)




Ou encore des tunnels l2tp.
C'est encore plus pratique/homogène quand on opère déjà des LNS.

--
Raphael Mazelier


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

Re: [FRnOG] [TECH] Ip d'interco bgp

[Raphael Mazelier]

Le 14/09/15 21:41, Johann a écrit :

Ne pas annoncer ses IP d'interconnexion dans la DFZ demande à avoir un bloc


J'ai pas dit que cela devait être forcement le cas en nominal, certain 
le font (jaguar de souvenir), d'autre (moi le premier) non. En revanche 
avoir un /24 en stock qui peut servir en cas de besoin, et le dédier 
temporairement à tel ou tel besoin c'est quand même bien pratique. 
(surtout quand il s'agit de dépanner un client).


--
Raphael Mazelier


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

Re: [FRnOG] [MISC] FRNOG 25.0 - BETA

[Raphael Mazelier]

Le 11/09/15 17:19, Romain Guichard a écrit :

Je pense que vous surestimez grandement la volonté de la majorité des
étudiants. La plupart se contentent très bien des polycopiés de cours et
n'ont aucune envie d'aller approfondir certains sujets.
Les ingés réseau formés n'auront pas tous la capacité/volonté de participer
au FRnOG.



Je partage ce constat. Mais cela s'explique assez facilement par le fait 
que ces métiers se sont démocratisés et ouvert aux plus grand nombres. 
D’où un certain nivellement par le bas.
Il y a autant de bons éléments qui sortent qu'à notre époque, mais la 
proportion est plus faible. Pour résumé avant pour faire du système 
ou/et du réseau il fallait être vraiment passionné, maintenant c'est un 
métier comme un autre.



Quant aux étudiants qui arrivent jusqu'au FRnOG (la plupart ignorent son
existence, soyez en conscient), ce sont ceux qui ont à la fois eu la chance
d'avoir choisi leur formation (meme à bac+3/4, certains ne savent pas trop
où ils sont et pourquoi ils y sont), qui sont passionnés par leurs études
et qui ont l'envie d'aller plus loin.



Oui. Et je trouve cela bien. Même pour les gens qui font du réseaux, 
Frnog reste une communauté qui traite de sujet relativement spécifique 
(opérateur). Une majorité d'ingénieur réseaux ne vont pas trouver 
d'informations très pertinente pour eux sur cette liste.


Cela ne remets pas en question le fait qu'il faille améliorer la 
passation de connaissance, ceux qui me connaisse savent que je déplore 
un peu l'état de celle ci dans le domaine. Mais je ne penses pas que ce 
rôle soit dévolu à Frnog. Du moins pas la liste. La communauté ? peut 
être. Je serais le premier a être partant pour la création d'un vrai 
livre opérationnel sur les réseaux.



--
Raphael Mazelier


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

Re: [FRnOG] [TECH] Ip d'interco bgp

[Raphael Mazelier]

Le 15/09/15 00:51, Frederic Dhieux a écrit :


C'est moche et ça va faire râler du monde, mais au pire dans l'urgence
de la situation prendre un subnet d'interco dans RFC1918 c'est peut-être
un moindre mal le temps de trouver une solution plus propre et pérenne.



Oui tout à fait. Je n'avez pas mentionné dans mon premier mail mais 
c'est un des idée qui m'est venu a l'esprit.


--
Raphael Mazelier


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

Re: [FRnOG] [TECH] Ip d'interco bgp / Solution IELO

[Raphael Mazelier]

Le 15/09/15 11:20, Cédric Tabary a écrit :


On a décidé de griller le "last /22" que le RIPE nous a alloué pour les interco 
BGP à risque et on ne l'annoncera pas. On pourra éventuellement annoncer des plus 
spécifiques (/23 ou /24) si on en a besoin.

Ca permet de ne pas en venir à des solutions du type interco en RFC1918, que je 
trouve vraiment sale.



Yep voila. Pour le rfc1918 en temporaire ça passe (mais on sait tous que 
le temporaire est définitif et inversement).


--
Raphael Mazelier


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

Re: [FRnOG] [TECH] Appliance filtrage URL/Firewall

[Raphael Mazelier]

Et bien, faire un dd de l'iso de pfsense vers une clé usb, ouvrir un
boitier soekris et brancher la clé, faire le premier boot/install avec
le câble serial quivabien, c'est très rapide  :-) (et ça Juste Fonctionne™)

Hors délai de livraison d'un soekris et configuration initiale du FW
bien sûr.



Plutôt prendre une alix apu. mais sinon +1 pour pfsense cela sera 
beaucoup plus simple et pérenne qu'une boiboite constructeur (dans ses 
tarifs).



--
Raphael Mazelier


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

Re: [FRnOG] [TECH] Ip d'interco bgp

[Raphael Mazelier]

Le 14/09/15 21:08, Johann a écrit :

Hello,

Ca veut dire qu'ils ont moyen de connaître rapidement tes nouvelles IP
d'interconnexion.
Demande à tes transitaires de filtrer tout le trafic à DESTINATION des IP
d'interconnexion (Uniquement. Pas du trafic qui passe) sauf leur routeur
adjacent et le tien. Ou à minima le trafic ICMP/UDP pour bloquer tout type
de traceroute sur la partie interco. Puis rechange d'IP d'interconnexion.

Ca devrait te laisser un peu de répit sur ce vecteur d'attaque. On a fait
cela avec un client qui était dans la même situation que toi.



Bah oui c'est pas la mort de filtrer les ips d'interco(s), voir de pas 
les annoncer du tout dans la DFZ. Cela demande peut être un peu de re 
factoring sur le réseau de ton transitaire, mais bon franchement rien 
d'infaisable. Que cogent ne le fasse pas c'est compréhensible, ielo je 
suis plus dubitatif.


--
Raphael Mazelier


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

Re: [FRnOG] [TECH] Ip d'interco bgp

[Raphael Mazelier]

Ça peut servir à ce que ton client joigne son routeur depuis l'internet
public en dehors de ses ips (en cas de problem d'annonce, par exemple).



Tout à fait. Avec une default vers ton transitaire, cela peut faire un 
accès quand ton bgp est tout pété.


--
Raphael Mazelier


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

Re: [FRnOG] [TECH] Isp full ipv6

[Raphael Mazelier]

Le 25/09/15 20:58, Olivier CALVANO a écrit :


Mon soucis est plutôt simple, le réseau est composé de 3320 abonnés avec
une box maison basé sur Linux.

Jusqu'ici pas de soucis, le hic c'est que les adresses ipv4 doivent être
rendu à l'opérateur qui fournissait l'accès internet car financièrement ce
n'est pas viable (pas de bgp l'opérateur refuse, coût transit très chère et
ils veulent profiter de changement de contrat pour intégrer un coût de
location pour chaque IPv4)

Du coup on réfléchi pour tout passer en IPv6 directement mais j'avoue ne
pas tout maîtriser encore à ce niveau la.



C'est une problématique intéressante et qui sera de plus en plus 
d'actualité. On peut résumer ton besoin en disant que tu doit fournir un 
accès internet sur tes liaisons access quelque soit la technologie.


Visiblement l'option classique qui est de délivrer une ipv4 publique à 
chaque client/cpe est trop chère (je ne dirais jamais assez qu'il s'agit 
d'un cout à intégrer, 10 euros l'ip fixe (en moyenne) ce n'est pas un 
coup exorbitant pour un abonné, mais on a tellement été habitué a ne pas 
le prendre en compte...)


Il te reste donc des solutions de nat, car malheureusement le contenu 
internet reste à 99% du v4. Et donc à faire du CGN (carrier grade nat, 
un gros mot pour juste dire que le nat s’effectue dans le core, et non 
coté cpe).


Deux grand choix : soit tu décide de faire de l'ipv6 sur tes cpe, et 
donc tu te tourne vers du NAT64/DNS64, ou tu reste sur du v4 et tu fais 
du nat444. Les deux ont des avantages et des inconvénients, même si 
globalement je pense que rester sur du nat444 est plus simple (mais 
moins rigolote).


Dans les deux cas il existe des appliances qui peuvent faire le boulot 
(A10 au hasard), ou bien tu peux faire ta solution custom.


Dans tout les cas c'est faisable et déjà largement déployé, donc 
n’hésite pas sur si ta as besoin d'aide sur les détails.


--
Raphael Mazelier



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

Re: [FRnOG] [TECH] IP transit / Free et ou Orange

[Raphael Mazelier]

Le 30/09/15 16:09, Clement Cavadore a écrit :


Je te conseillerais plutôt de te rabattre sur un des acteurs localement
présent, et ayant une bonne connectivité vers Free/Orange, si c'est ce
que tu recherches... mais ne sachant pas sur quel DC tu te trouves, je
ne peux pas te conseiller qui que ce soit (mais j'imagine qu'ils ne
manqueront pas de te contacter off liste :-))



Certainement. Ceci dit orange arrive maintenant à proposer du C3215E a 
des prix qui sont certes chers, mais pas non plus complétement déconnant.


--
Raphael Mazelier


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

Re: [FRnOG] [MISC] Architecte OSS

[Raphael Mazelier]

Le 30/09/15 15:58, slesim...@laposte.net a écrit :

Heu rassurez-moi on est bien sur la ML des opérateurs de réseau français 
n'est-ce pas?
Personne n'a jamais travaillé sur ces sujets?!
Allez déconnez pas j'en connais au moins une bonne douzaine d'entres vous qui 
l'ont fait dans le passé chez divers opérateurs...



Pour ceux qui ne connaissent pas les termes, OSS chez les opérateurs :

https://fr.wikipedia.org/wiki/Operations_Support_System

et BSS :

https://fr.wikipedia.org/wiki/Business_Support_System


--
Raphael Mazelier


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

Re: [FRnOG] [TECH] overthebox

[Raphael Mazelier]

Sauf à utiliser Multipath TCP, qui est *précisément* fait pour fonctionner
sur des technos très différentes (genre, VDSL + 3G).



Je viens de regarder plus en détail la solution d'ovh. C'est une belle 
intégration d'un classique vpn over mptcp. Effectivement avec mptcp tu 
es moins impacté par la différence de latence, ceci dit de mes tests 
cela restait assez moche (openvpn-tcp over mptcp). L'utilisation d'un 
proxy socks transparent est assez maline.


Ceci étant dit cela reste un très beau "bricolage" :)


--
Raphael Mazelier


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

Re: [FRnOG] [TECH] overthebox

[Raphael Mazelier]

Le 25/09/15 10:57, Clément Breuil a écrit :

Sinon il y a ceci => https://github.com/zehome/MLVPN



Oui il existe de multiple solution pour faire de la pseudo agrégation de 
lien (lacp over tunnel, mlppp, etc...). Et mlvpn est une des solutions 
opensource les plus intégrés/simple.


Rappelons que cela ne fonctionne correctement que si les différents 
liens agrégés sont fortement similaires (notamment en terme de 
latences), et que le débit agrégé est a peu près égal à 1.9 * la bp du 
lien le plus faible.


Pour le dire autrement, agréger des liens *dsl du même fai, cela va 
plutôt bien marcher, en revanche avec de multiple fai (ou techno, genre 
cuivre) cela va être très moyen.


Une autre question a se poser, c'est à ton vraiment besoin d'agréger ? 
une simple répartition sur les deux liens ne serait elle pas suffisante ?


Et bien sur c'est reculer pour mieux sauter, la fibre étant la seule 
solution d'avenir :)




Cdt,

--
Raphael Mazelier


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

Re: [FRnOG] [MISC] ZNE-ZABPQ

[Raphael Mazelier]

Ouch cela me rappelle quelques mauvais souvenirs à parser ces fichiers 
pour générer les informations de taxation arrière...


Bon réveillon à tous.


Le 31/12/15 16:09, Sebastien Lecomte a écrit :

Salut David,

Moi, je m'interroge plutôt sur la raison de sa présence... :-)

Puisqu'à moins que cela n'ait changé, ces informations étaient payante
(base G'NUM) :

http://www.arcep.fr/index.php?id=8765



--
Raphael Mazelier


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

Re: [FRnOG] [MISC] AS Ranking

[Raphael Mazelier]

Le fait d’être tiers 1 ou pas, est finalement assez peu intéressant pour 
le client. Ce qui importe finalement c'est que ton transitaire ait des 
tuyaux non saturés et courte vers les destinations qui t'importe (payant 
ou pas le tuyau).


Le 01/12/15 12:05, David Ponzone a écrit :

Il y avait eu des discussions récemment sur quel AS était Tier 1 ou pas.

J’ai trouvé ce classement qui a le mérite d’être actualisé dynamiquement:

http://as-rank.caida.org/?mode0=as-ranking=50=1


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




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

Re: [FRnOG] [TECH] VPN MPLS couche 2 ou 3

[Raphael Mazelier]

Le 24/11/15 10:55, Jocelyn Lagarenne a écrit :


je ne suis pas expert du tout sur le sujet, mais la question a éveillé ma
curiosité, et je suis tombé la dessus avec mon ami google qui m'a permis de
mieux comprendre la réponse de Raphael :
http://www.juniper.net/techpubs/en_US/junos13.2/topics/concept/mpls-ex-series-vpn-layer2-layer3.html

je ne sais pas si tu avais vu cette documentation que je trouve synthetique
et assez clair sur la difference entre les 2



Oui le tableau récapitulatif à la fin aide bien à comprendre les 
différences fondamentales entre les deux modes. Très bon pointeur.


--
Raphael Mazelier


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

Re: [FRnOG] [TECH] VPN MPLS couche 2 ou 3

[Raphael Mazelier]

Le 23/11/15 23:56, Bruno LEAL DE SOUSA a écrit :

Bonjour à tous,
Je bosse actuellement sur le choix d'une solution MPLS pour interconnecter
plusieurs sites ( 1 siège, 2 sites de prod et 2 magasins).

J'ai vu qu'il existe essentiellement 2 familles de VPN WAN. Les VPN IP
(couche 3) et les VPN Ethernet (couche 2).



Outre les considérations commerciales, le point essentiel est bien celui 
ci :


- as tu besoin d'un lan étendu ? L2 donc.

ou

- est ce que tes applicatifs fonctionnent correctement de manière routé 
? L3. Dans ce cas tu auras des subnets différents sur chaque site. Si 
cela ne pose pas de problèmes c'est sans doute une meilleure solution.



Cdt,

--
Raphael Mazelier


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

Re: [FRnOG] [TECH] normalisation des communautés BGP de trou noir

[Raphael Mazelier]

Bonjour,

Cela serait tellement une bonne chose. Malheureusement les trois 
transitaires que j'utilise ont une communauté différente pour le rtbh 
(voir pour certain impose de peerer avec un routeur dédié a cela).

Et pour le coup cela ne ressemble pas du tout à ASN:666.

Cdt,

--
Raphael Mazelier

Le 13/01/16 03:37, Michel Py a écrit :

Bonjour à tous,

Est-ce quelqu'un aurait des liens sur le sujet ? Par exemple dans le cas ou un 
client envoie à son(ses) FAI certains préfixes à router dans null0 pour mitiger 
une DDOS, est-ce qu'il y a un standard sur la communauté à utiliser ?

Pour le next-hop il semblerait que 192.0.2.1 soit généralisé, et j'ai vu 
plusieurs ASN:666 (dont je me sers moi-même), est-ce qu'il y a un effort de 
normalisation ?

Michel.


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




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

Re: [FRnOG] [TECH] Quelqu'un pour hoster mon AS ?

[Raphael Mazelier]

Hello,

Tu as des IPs ? fort bien.

As tu une architecture physique (des routeurs) qui vont avec ?

- si oui bah tu prendre deux transitaires au hasard.
- si non il faut te trouver quelqu'un qui va hoster ton service et 
annoncer tes IPs (et éventuellement ton AS si tu le souhaite).


--
Raphael Mazelier



Le 18/01/16 13:57, Guillaume a écrit :

Bonjour,

J'ai souscris un compte RIPE et LIR.
J'ai une /22 en IPv4 et une /29 IPv6, maintenant pour les utiliser il faut
qu'un hébergeur host mon AS.
Vous savez ou je peux trouver ça ??

Merci d'avance.

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




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

Re: [FRnOG] [TECH] Redistribution de routes iBGP

[Raphael Mazelier]

Théoriquement chaqun de tes routeurs tu devrais avoir pour chaque pfx 
deux paths, le préféré vers TransitX et l'autre vers TransitY 
(possiblement via ton routeur voisin).
Si tu coupe une session de transit, chaque routeur devrait déjà avoir 
les chemins dans la RIB vers l'autre, pas la peine que ton autre routeur 
les ré annonce en IBGP.
En revanche ce qui peut se passer lors de gros changement de route de ce 
style, c'est des lenteur de changement RIB->FIB.


--
Raphael Mazelier


Le 19/01/16 10:11, Aurélien a écrit :

Bonjour,

J’ai une question sur une situation toute bête que j’ai sur un AS:

Mettons que j’aie (pour simplifier) 2 routeurs, un IGP (ospf en
l’occurence, mais ça importe peu) qui récupère les routes connectées
sur chaque routeur (R1 et R2), de l’iBGP entre les loopbacks, et un
transit avec une full view sur chaque routeur. Chaque routeur a aussi
des sessions avec des clients (genre annonce de la route par défaut,
sur AS privé).

Ce qui me fait donc sur R1, une fois que tout est up, dans les ~200k
routes préférées via mon transit local, et donc de par le fait, R2 qui
m’annonce ~360k routes IPv4 (la full view moins les routes qu’il
préfère passer par R1).

Mon problème survient quand je coupe l’un de ces transits, mettons sur
R1. La session BGP est coupée, et je withdraw mes annonces de routes à
R2. R2 qui du coup va progressivement m’annoncer le reste de la full
view reçue via son transit.

Le problème, c’est que pendant cette période de convergence, je peux
facilement me retrouver avec des paquets qui m’arrivent de mes
downstreams sur R1, et pour lesquels du coup je n’ai plus de route de
sortie (plus de route par mon transitaire, et R2 ne m’a pas encore
annoncé la route obtenue via son transit).

Comme j’ai des routeurs qui carburent au PowerPC, ils ne jouent pas
très vite avec les routes, ce qui n’arrange pas le souci.

Est-ce que quelqu’un a déjà eu ce genre de souci ? Est-ce qu’il existe
des solutions de configuration pour contourner ou minimiser ce type de
problème ? (Evidemment, on peut le minimiser en mettant un Xeon dans
le routeur, on est d’accord).

Merci de vos lumières,

Cordialement,




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

Re: [FRnOG] [TECH] Recherche modèle ADSL2+ simple, fiable et pas (trop) cher

[Raphael Mazelier]

Le 04/02/2016 15:20, David Ponzone a écrit :

Speedtouch ST536.
Ca se trouve encore, à moins de 20€.
Jamais eu de problème avec.




A part la cli ST qui est ... particulière, pour le prix c'est clairement 
un bon choix. Après on trouve des stocks de cisco 877 d'occasions pour 
très peu cher. CPE qui reste une référence, mais effectivement attention 
vu qu'ils sont EOL.



--
Raphael Mazelier


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

Re: [FRnOG] [TECH] Recherche modèle ADSL2+ simple, fiable et pas (trop) cher

[Raphael Mazelier]

Et il y a toujours le joli ascii-art au login :)

Le 04/02/2016 15:57, David Ponzone a écrit :

Ah le CLI Speedtouch, je devrais donner des cours :)
Des heures de prise de tête sans doc….
On devrait même utiliser ça pour détecter un bon candidat à l’embauche.

Mais une fois que ça marche, ça bouge plus, et la même conf passe direct sur 
les modèles récents Technicolor.



Oui la conf par défaut est un peu trop verbeuse. Mais une fois compris 
on est d'accord c'est bien. Ca gérè tout les protocoles d'autoprov 
aussi; ce qui est un vrai plus.



--
Raphael Mazelier


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

Re: [FRnOG] [ALERT] réseau OVH en carafe ?

[Raphael Mazelier]

Le 12/02/2016 11:11, Clement Cavadore a écrit :

Bon, on est dans les suppositions et l'hypothétique, mais j'imagine que:

D'une part, OVH possèderait plusieurs "catégories" de routeurs:
- Des routeurs fullview (type ASR), gérant la DFZ (570k routes)
- Des routeurs partial view (type 6k), en distribution, ayant les/des 
routes peerings + default (pour ce qui est transit)

D'autre part, j'imagine que suite au leak (et à l'absence de max-prefix
sur la session de peering), certains routeurs "partial view" se sont
retrouvés submergés de routes, car recevant la DFZ, alors que ce n'était
pas prévu. Du coup, dépassant leurs capacités hardware, ils sont passés
en routage software, et un redémarrage a été requis pour que la
situation se stabilise.

Bref, l'erreur aura été ici dans le cas d'OVH, d'oublier le max prefix.
Ce genre d'erreur peut arriver même aux meilleurs...

Il me semble d'ailleurs que le même genre d'incident est arrivé à Free
il y a quelques années, causé non pas par un max prefix, mais plutot par
l'ajout d'une communauté BGP erronée sur un lien de transit.




Ah zut tu m'as devancé, j'ai la même analyse :)

--
Raphael Mazelier


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

Re: [FRnOG] [ALERT] réseau OVH en carafe ?

[Raphael Mazelier]

Le 12/02/2016 10:48, David Ponzone a écrit :


Dans le cas précis de l’AS 31500, il annonce en temps normal environ 117 routes 
sur un point de peering.
Et donc il s’est mis à annoncer peut-être tout Internet, donc 570 000 routes, à 
OVH.
2 problèmes possibles:
-le routeur d’OVH là-bas n’était pas capable de gérer un full-feed (inquiétant…)


Je ne pense pas que le routeur de peering d'ovh ou le DEC-IX est relié 
soient des 6K, en revanche si la politique de redistribution est de 
laisser passer toutes les routes provenant des peerings partout sur le 
backbone, kaboom sur les vieux equipements.



et/ou
-si pour une raison X ou Y dans l’algo de sélection du best-path (un peu long à 
décrire ici, mais généralement, on met des poids forts sur les routes venant 
des peering pour les privilégier puisque pas chères), les routeurs d’OVH 
partout en France se sont mis
à envoyer une grosse partie du trafic vers le DECIX, peut-être que les liaisons 
vers Francfort n’étaient pas dimensionnées pour supporter ça (c’est même quasi 
sûr).




Oui le classique peer qui devient transit :) (et Octave a clairement 
statué qu'il y avait eu boulette de pas mettre un max pref pour limiter 
la casse) Et oui en général la politique de sélection en sortie (en 
simplifié) est pni > peer > transit. Donc tout le trafic hors pni a été 
aspiré par le gentil peer russe, qui d'un coup a complétement saturé 
(logique).


--
Raphael Mazelier


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

Re: [FRnOG] [TECH] Facebook pour petits AS

[Raphael Mazelier]

A noter aussi que l'anycasting de leur serveur dns (a.ns.facebook.com 
69.171.239.12) est très aléatoire. Par exemple depuis mon AS pro en ce 
moment j'arrive a singapour...


--
Raphael Mazelier

Le 25/02/2016 21:41, Raphael Mazelier a écrit :

Depuis mon chez moi (Free/NC) avec un unbound et

forward-zone:
 name: "."
 forward-addr: 8.8.8.8 (ou le resolveur de Free/NC).

dans mon unbound.conf

13  ae20.bb02.ams2.tfbnw.net (31.13.27.68)  80.745 ms
msw1ak.01.ams2.tfbnw.net (204.15.20.159)  76.958 ms
msw1al.01.ams2.tfbnw.net (173.252.66.126)  76.2 ms
14  edge-star-mini-shv-01-ams2.facebook.com (31.13.64.36)  76.26 ms
74.283 ms ae1.pr01.ams2.tfbnw.net (31.13.29.91)  72.748 ms

J’atterris a Amsterdam.

Sans forward-zone, c'est à dire que je remonte au root dns :

7  ae11.bb03.atn1.tfbnw.net (31.13.31.172)  151.861 ms  145.369 ms
be11.bb01.atn1.tfbnw.net (31.13.25.142)  144.119 ms
  8  ae4.dr03.atn2.tfbnw.net (74.119.77.37)  143.187 ms
ae2.dr08.atn1.tfbnw.net (74.119.76.95)  142.593 ms
ae0.dr03.atn2.tfbnw.net (31.13.26.69)  144.251 ms

Atlanta surement.

A noter que depuis l'AS de mon travail c'est le même soucis, et je
confirme que nos ranges d'IPs sont correctement renseignés dans GeoIP ou
Quova...

Donc je ne sais pas ce que fait la geoloc de facebook mais il y a
quelque chose de cassé dans leur système...

--
Raphael Mazelier

Le 25/02/2016 21:16, Philippe Bourcier a écrit :


Bonsoir,

C'est un peu étrange comme solution, car le 8.8.8.8 implémente l'EDNS
client IP...
(https://www.ietf.org/archive/id/draft-vandergaast-edns-client-subnet-02.txt)



Donc : 1.2.3.4 (ton network pas encore reconnu par le GeoDNS FB
(sûrement basé sur MaxMind/GeoIP ou Quova)) ==> DNS Google ==> DNS
Facebook (qui voit arriver la requête depuis le DNS google, mais "de la
part de 1.2.3.4")

Il est fortement probable que le DNS Facebook implémente aussi EDNS
client IP, c'est quand même justement fait pour les gens qui font du
GeoDNS.

Du coup, soit tu vas avoir le même résultat qu'avant... soit ils font en
sorte que "si l'IP n'est pas dans GeoIP, alors on geoloc sur l'IP du DNS
Google"... j'ai envie de dire : pourquoi pas... Mais perso je n'aurais
pas implémenté ce genre de logique, préférant faire confiance à la db de
geoloc (qui faute d'avoir le pays exacte, a toujours au moins le bon
continent (pas trop difficile, grâce aux RIRs)).

Bref, pour résoudre ton problème, je pense que le mieux c'est de
vérifier que dans GeoIP et Quova ton IP est bien détectée au bon endroit
et si c'est le cas, c'est sûrement uniquement une question de semaines
avant que celle de FB soit OK. Dans le cas contraire, contacter
directement MaxMind et Quova pour être rapidement intégré (ils font une
MAJ par mois).


Cordialement,
Philippe Bourcier





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



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

Re: [FRnOG] [TECH] Facebook pour petits AS

[Raphael Mazelier]

Depuis mon chez moi (Free/NC) avec un unbound et

forward-zone:
name: "."
forward-addr: 8.8.8.8 (ou le resolveur de Free/NC).

dans mon unbound.conf

13  ae20.bb02.ams2.tfbnw.net (31.13.27.68)  80.745 ms 
msw1ak.01.ams2.tfbnw.net (204.15.20.159)  76.958 ms 
msw1al.01.ams2.tfbnw.net (173.252.66.126)  76.2 ms
14  edge-star-mini-shv-01-ams2.facebook.com (31.13.64.36)  76.26 ms 
74.283 ms ae1.pr01.ams2.tfbnw.net (31.13.29.91)  72.748 ms


J’atterris a Amsterdam.

Sans forward-zone, c'est à dire que je remonte au root dns :

7  ae11.bb03.atn1.tfbnw.net (31.13.31.172)  151.861 ms  145.369 ms 
be11.bb01.atn1.tfbnw.net (31.13.25.142)  144.119 ms
 8  ae4.dr03.atn2.tfbnw.net (74.119.77.37)  143.187 ms 
ae2.dr08.atn1.tfbnw.net (74.119.76.95)  142.593 ms 
ae0.dr03.atn2.tfbnw.net (31.13.26.69)  144.251 ms


Atlanta surement.

A noter que depuis l'AS de mon travail c'est le même soucis, et je 
confirme que nos ranges d'IPs sont correctement renseignés dans GeoIP ou 
Quova...


Donc je ne sais pas ce que fait la geoloc de facebook mais il y a 
quelque chose de cassé dans leur système...


--
Raphael Mazelier

Le 25/02/2016 21:16, Philippe Bourcier a écrit :


Bonsoir,

C'est un peu étrange comme solution, car le 8.8.8.8 implémente l'EDNS
client IP...
(https://www.ietf.org/archive/id/draft-vandergaast-edns-client-subnet-02.txt)


Donc : 1.2.3.4 (ton network pas encore reconnu par le GeoDNS FB
(sûrement basé sur MaxMind/GeoIP ou Quova)) ==> DNS Google ==> DNS
Facebook (qui voit arriver la requête depuis le DNS google, mais "de la
part de 1.2.3.4")

Il est fortement probable que le DNS Facebook implémente aussi EDNS
client IP, c'est quand même justement fait pour les gens qui font du
GeoDNS.

Du coup, soit tu vas avoir le même résultat qu'avant... soit ils font en
sorte que "si l'IP n'est pas dans GeoIP, alors on geoloc sur l'IP du DNS
Google"... j'ai envie de dire : pourquoi pas... Mais perso je n'aurais
pas implémenté ce genre de logique, préférant faire confiance à la db de
geoloc (qui faute d'avoir le pays exacte, a toujours au moins le bon
continent (pas trop difficile, grâce aux RIRs)).

Bref, pour résoudre ton problème, je pense que le mieux c'est de
vérifier que dans GeoIP et Quova ton IP est bien détectée au bon endroit
et si c'est le cas, c'est sûrement uniquement une question de semaines
avant que celle de FB soit OK. Dans le cas contraire, contacter
directement MaxMind et Quova pour être rapidement intégré (ils font une
MAJ par mois).


Cordialement,
Philippe Bourcier





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

Re: [FRnOG] [TECH] Redistribution de routes iBGP

[Raphael Mazelier]

Oui oui tout à fait.
J'avais mal interprété le problème.

Et comme vous l'avez tous suggéré il existe plusieurs palliatifs :

 - faire en sorte de ré-annoncer dans IBGP les routes externes non 
préférés,
 - mettre des defaults statiques (et les annoncer dans IBGP), si l'on 
est sur que le port flap en même temps que la session,
 - se faire annoncer une default par les transitaires, ce qui reste le 
plus propre.
 - ou comme vous le remarquiez, si cela converge si lentement que cela, 
il faut faire un choix entre la diversité des routes et la rapidité, aka 
filtrer le nombre de route. As ton vraiment besoin d'une full ?


Et au final dans ce genre de setup si on veut faire une maintenance 
programmé sur un routeur, ou un transit, le mieux est peut être 
d'assécher le trafic avant ? (alors évidement en cas d'incident...)




Le 19/01/16 13:58, David Ponzone a écrit :

Raphael,

Pour moi, si A reçoit une route de Transit1 (eBGP) et de B (iBGP), et que la 
route venant de B est la meilleure, il ne redistribue pas la route qu’il a eu 
de Transit1 à B.
C’est peut-être variable en fonction des implémentations et/ou de la conf.




--
Raphael Mazelier


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

Re: [FRnOG] [TECH] miroir d'un port trunk sur Juniper ex4600

[Raphael Mazelier]

Le 25/03/2016 15:55, David Ponzone a écrit :



Blague à part, je connais pas bien les EX, mais c’est normal que le port de 
sniffing soit en mode access ?




Ah oui tiens bonne remarque. Le port de réception ne devrait pas avoir 
de configuration. (pas de family inet). Je doute que cela change quoi ce 
soit ceci dit.


--
Raphael Mazelier


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

Re: [FRnOG] Re: [TECH] "vous n'avez qu'Ã activer ipv6"

[Raphael Mazelier]

Le 02/03/2016 09:47, Nicolas Parpandet a écrit :


Le peering ipv6 entre cogent et google n'est pas actif, et ce n'est pas au 
programme !!,
du coup au lieu de passer par ailleurs !??, bah ça passe pas ...



Voir la discussion en cours sur Nanog à ce sujet.
C'est affligeant de voir qu'on en est encore à se battre sur ce genre de 
sujet en 2016, surtout qu'il ne doit pas s'agir de volume énorme.
En tout cas si on veut avoir une vrai connectivité ipv6 ce n'est 
visiblement pas du coté de Cogent qu'il faut se tourner...



--
Raphael Mazelier


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

Re: [FRnOG] Re: [TECH] "vous n'avez qu'Ã activer ipv6"

[Raphael Mazelier]

Le 02/03/2016 10:43, slesim...@laposte.net a écrit :

En même temps on parle de gestion d'AS là donc si un upstream te file pas ce 
dont tu as besoin, c'est pas en changer ou changer les routes pref qui va poser 
un problème insurmontable.



Non bien sur. Mais c'est un bon révélateur de comment est considéré ipv6 
par les service providers en général. C'est un plus, pas bien dur à 
activer et qui passe à la toute fin des priorités.


--
Raphael Mazelier


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

Re: [FRnOG] [MISC] Telehouse & les cross-connects

[Raphael Mazelier]

Le 30/03/2016 15:44, Clement Cavadore a écrit :



Qu'en pensez-vous, clients existants ?
En ce qui me concerne, mettre un FAS + récurent "raisonnable" sur la
pose + présence d'un cable dans le faux plancher ne me choquerait pas,
ainsi qu'une facturation à l'acte (câblage/décablage en MMR). Mais une
facturation à la paire, c'est vraiment quelque chose que je trouve
vraiment abusé.



Je vois deux soucis personnellement :

1) le soucis technique : on aura beau dire ce que l'on veut, le passage 
par une MMR est un gage de non fiabilité. Donc la ou on gagnait du temps 
à TH2, une fibre posé, ca marche, maintenant on va devoir faire comme 
partout ailleurs (debug des deux demi-crossco, etc...)


2) le problème financier. Je pense comme toi Clément, un FAS par câble, 
et un récurrent par câble serait largement suffisant.



--
Raphael Mazelier


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

Re: [FRnOG] [TECH] Collecteurs IPFIX en logiciel libre

[Raphael Mazelier]

Le 26/04/2016 à 09:32, Stephane Bortzmeyer a écrit :



Qu'est-ce que vous utilisez/recommandez en ce moment comme collecteurs
IPFIX avec deux exigentes importantes :

- vraiment IPFIX, pas Netflow (version >= 10)
- logiciel libre, tournant sur Unix

À part pmacct <http://www.pmacct.net/>, ya quoi ?



Nfsen, mais pmacct est vraiment le meilleur logiciel à ce niveau selon 
moi. Stable, flexible, avec multiples plugins de sorties.

L'auteur est de plus très sympa et réactif.

--
Raphael Mazelier


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

Re: [FRnOG] [TECH] TRILL vs. SPB

[Raphael Mazelier]

Hello,

A mon sens tu as deux grandes questions a te poser avant de choisir 
telle ou telle technologie de "fabric ethernet".


1) Est ce que tu veux réellement une architecture de type "fabric 
ethernet" ? comme l'on dit mes camarades c'est certes (beaucoup ?) plus 
simple, mais moins fiable et moins scalable qu'une fabric IP.


2) Si oui, pose toi la question : avec quelle constructeur de matériel 
veut tu travailler. Chaque constructeur a implémenté sa solution de 
fabric ethernet à sa sauce (FabricPath, QFabric/VCF, Trill, SPB), avec 
c'est à mentionner des constructeur qui utilisent des standards, et 
d'autres non. Et d'autres ont choisi d'autre approches (comme Arista).


--
Raphael Mazelier

Le 15/04/2016 00:19, Jean-Christophe Valiere a écrit :

Salut,

C'est dans le cadre d'un Datacenter.
Au début, étais plutôt TRILL me semblait plus pertinent mais plus je vois de 
doc et plus je penche pour SPB ...




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

Re: [FRnOG] [TECH] TRILL vs. SPB

[Raphael Mazelier]

L'Ethernet opérateur est une technologie L2VPN, plus évolutive et moins 
dispendieuse que MPLS ou PPPoE.
IP est soit une technologie L3VPN (assez peu utilisée avec L2TP) ou une 
technologie non VPN, multipoint à multipoint.



Quelle est le rapport avec le sujet ? on parle de réseau "datacenter", 
on ne parle pas du tout de mpls, pppoe ou l2tp ?!


L'objectif d'un réseau "datacenter" est de fournir une connectivité à 
ses serveurs (quel que soit la technologie sous-jacente utilisée).


--
Raphael Mazelier


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

Re: [FRnOG] [TECH] Téléphones IP was: Sotfphone au lieu de hardphone derrière livebox business 132

[Raphael Mazelier]

On 08/02/2017 19:33, Michel 'ic' Luczak wrote:

Et sinon Linksys^WCisco Small Business? J’en garde un bon souvenir d’avant le 
rachat.

++ ic



De souvenir c'était ex-sipura ? très bonne stack, bon autoprov, un peu 
rapport qualité prix. Snom aussi très bien.

Grandstream ca me fait faire un bon de 12 ans en arriere :)

--
Raphael Mazelier


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

Re: [FRnOG] [TECH] Sotfphone au lieu de hardphone derrière livebox business 132

[Raphael Mazelier]

Moi j'ai une question con (comme d'habitude) : c'est quoi comme marque de 
téléphone IP que les opérateurs installent, ces jours-ci ? ou est-ce que le 
client a le choix entre plusieurs modèles ?

J'ai 200 téléphones à changer a la fin de l'année, je m'oriente vers du 
Grandstream.



Si tu as un peu de budget Polycom reste une valeur sure. Indestructible 
et compliant.



--
Raphael Mazelier


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

[FRnOG] [JOBS] Ingénieur Réseaux et Systèmes (eTF1)

[Raphael Mazelier]

Bonjour la liste,

Je recrute dans mon équipe la personne qui deviendra le futur référent 
réseau de la plateforme eTF1. Je cherche quelqu’un de curieux, qui peut 
à la fois s’épanouir dans le réseau et le système, car même si la 
première composante du poste est le réseau, rien n’est cloisonné, et le 
candidat sera amené à faire du système, de l'automatisation et plus si 
affinité.


Il n’est évidement pas nécessaire de maîtriser toutes les technologies 
cités (çà serait compliqué) mais plutôt d’être capable de se former.


Niveau salaire, on sera dans les prix du marché selon le profil (oui je 
sais ça va faire grincer certain, mais je ne pourrais pas proposer le 
même salaire à quelqu’un qui a 3 ou 8 ans d’expérience par exemple). 
J’ai une fourchette maximum que je pourrais donner en PV.


Les locaux sont à Boulogne Billancourt (Tour TF1), pas de télétravail 
(enfin pas de manière régulière, même si cela pourrait évoluer).


La place est à mon sens intéressante car il y a des belles 
infrastructures, on délivre beaucoup de vidéos, de beaux chantiers et 
une équipe sympa (un peu en mode startup au sein d’un grand groupe).


J'étudie toutes les réponses et je suis disponible pour en discuter en PV.

Cdt,


Ci après la fiche de poste :

<—-
*Ingénieur Réseaux (et Système)*

__Profil__
 - au moins une 1ere expérience significative
 - très bonne connaissance du réseau (routage, switching, 
load-balancing, firewalling)

 - bonne connaissance des systèmes linux
 - capable de prendre en charge les sujets de manière autonome
 - team player/open mind
 - bonus : connaître les environnements web/haute dispo

__Technos__
 - maîtrise des fondamentaux du réseau:
- L2 : switching, vlan, etc...
- L3 : techno de routages, BGP, IGP, Ipsec, etc..
- FW : très bonne connaissance générique
- LB : très bonne connaissance générique
- matériel : Switch/Routeur HP, FW Stonesoft, LB citrix
 - bonne connaissances de Linux (99% du parc des serveurs)
 - connaissances des technos web (nginx, haproxy, varnish, etc)
 - connaissances d'au moins un langage de scripting (python par 
exemple), capacité à tout automatiser


__Missions__
 - Etre le référent du réseau eTF1, (réseau type CDN, avec un peu de 
trafic)

- ingénierie et MCO du réseau, évolution du design
- gestion de l'AS, peering, transit, relation opérateur
- automatisation des éléments du réseau
 - participer à l'opérationnel quotidien de l’équipe (gestion du RUN en 
rotation)

 - être transverse réseau/système
 - participer à l'astreinte du service

__Société__
eTF1 : filiale de TF1 en charge de toute la partie digitale du groupe. 
(site web et vidéo) au sein de la DTD (70 personnes environ, 50 dev, 20 
transverses) dans l’équipe IOPS (12 personnes) => équipe qui gère les 
infrastructures systèmes, réseaux, stockages, vidéo et production 
applicative.

—->


--
Raphael Mazelier


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

Re: [FRnOG] [MISC] FRNOG 27.0 - RC 2

[Raphael Mazelier]

On 01/10/16 16:24, Philippe Bourcier wrote:



J'ai une demande un peu particulière, je cherche quelqu'un qui aurait
migré une infra (de bonne taille, pas 3 baies...) en matos ONIE (sous
NOS Linux, genre Cumulus/OpenSwitch/...), que ce soit en access ou en
edge (Spotify-style) et qui pourrait venir en parler à la prochaine
réunion frnog lors d'une table-ronde sur le sujet.



Juste un détail mais il me semble que l'infra edge spotify est sur de 
l'Arista. Meme si EOS est un NOS linux based, le matériel ne supporte 
pas ONIE afaik.


Ceci étant excellent sujet. J'espere que tu trouvera des personnes pour 
ce retour d'expérience.


--
Raphael Mazelier


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

Re: [FRnOG] [BIZ] CDN pour streaming live

[Raphael Mazelier]

Il faut que tu te pose la question sur quels devices/formats tu veux 
diffuser (HLS/HDS/Dash/SmoothStreaming ?)


N'importe quel CDN digne de ce nom a des solutions de streaming video 
qui peuvent générer du multi-format à partir d'une seul source d'ingest.
(même si la tendance est de converger vers dash et des players html5, 
sauf quelques devices propriétaires).


Les grands critères de choix sont le prix, la couverture géographique, 
l’interfaçage (gui/cli/api), le reporting.


Akamai est celui qui propose le plus d'option, fastly est un acteur qui 
monte. Les gros sont EdgeCast, Limelight, L3, sans oublier CloudFront 
d'Amazon.


Tu as l’embarras du choix :)

Après tu peux le faire toi même (avec vlc par exemple ) ; tu perds tout 
l'avantages des CDNs, mais c'est clairement moins cher si ton besoin est 
faible.


--
Raphael Mazelier

On 10/10/2016 15:41, Stéphane Karges wrote:

hello tout le monde,

pour faire du streaming comme ca audio ou video tu as 2 possibilités.

1 - icecast prend la version KH si tu veux faire du FLV.
2 - vlc server.

perso la solution 1 est pas mal en fait tu envoi ton flux sur le server qui est 
chez un hébergeur et c’est lui qui va prendre la charge.

après tu a interoute qui fait ca tres bien (moins cher que akamai) ils utilises 
icecast KH (https://karlheyes.github.io/ <https://karlheyes.github.io/>)

Stéphane




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

Re: [FRnOG] [TECH] Feedback JUNIPER Virtual-Chassis

[Raphael Mazelier]

Dans mon job-1 j'ai beaucoup pratiqué les virtual-chassis Juniper. (une 
bonne quarantaine de VC dans des configurations allant d'un simple paire 
de 2x2200, au 8x3300, en passant par du 8xmixed 4200/4550).


Globalement je peux dire que nous n'avons pas eu tant de problème que 
ça, et cela nous a sauvé quelques fois (mais aussi posé quelques prises 
de tête).


Je peux confirmer que :

- il faut bien évidement faire du preprovisionned
- le snmp devient problématique des que l'on dépasse 4 membres (les cpu 
des EX et l'implémentation étant en carton)
- l'insertion d'un module XFP/SFP+ dans les 4200 est risqué (ça se passe 
bien une fois sur deux)


Je peux conseiller :

- ne pas tenter d'ISSU (sous peine d'avoir quelques issues :)
- ne pas dépasser 4/5 membres par VC (après les différents démon de 
forwarding commencent à prendre beaucoup de CPU, surtout si on beaucoup 
de broadcast/unknown unicast)
- ne pas mixer les modèles (ça marche, mais il faut au moins deux 
membres d'un même modèle pour une bascule de RE cohérente). D'une 
manière générale plutôt une mauvaise idée.
- faire très attention au polling, mais ce n'est pas lié au VC, plutôt 
aux EX (enfin disons que le nombre d'interface empire le problème). A ce 
sujet librenms/observium est affreux en terme de polling (vu qu'il walk 
tout comme une brute). J'ai un patch qui traîne si vous voulez.


Reste que les technologies de stacks sont à mon sens à éviter si on a le 
temps de faire autrement. Des switchs indépendants avec du MC-LAG au 
besoin, le tout piloté habilement, sont une architecture bien plus robuste.




On 26/10/2016 18:47, Inulogic - Gurvan Rottier-Ripoche wrote:


Bonjour la liste,

J'utilise depuis quelques temps la techno Juniper Virtual-Chassis sur des
switchs entrées de gamme EX2200-EX3300 (techno de Stack chez Juniper). Je
trouve la techno assez fiable.

Y'a t'il du monde qui a du recul / un feedback sur VirtualChassis (en bien
ou pas bien :)) ?



--
Raphael Mazelier



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

Re: [FRnOG] [TECH] Gateway GSM / VoIP

[Raphael Mazelier]

On 27/10/2016 14:47, Joël DEREFINKO wrote:

Bonjour,

Merci pour vos retours.
Je crois que je vais expliquer mon projet pour éviter tout malentendu :)

Le but n'est pas de monter un hérisson, mais simplement ponctuellement de 
pouvoir passer des appels de test vers notre service depuis chaque opérateur 
mobile.
Par exemple, toute notre flotte mobile est chez SFR, et plutôt que d'avoir 3 
mobiles qui trainent dans un tiroir pour tester de temps en temps 
l'accessibilité de notre service depuis Orange/BT/Free, poser ce boitier dans 
un coin, composer une extension et joindre notre service via l'une des SIM du 
boitier.



Oh les hérissons, que de souvenirs :)
Sinon n'importe quelle cartes openvox, sangoma et un asterisk et c'est plié.


--
Raphael Mazelier


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

Re: [FRnOG] [TECH] BGP advertise route

[Raphael Mazelier]

On 24/10/2016 15:24, Vincent Bernat wrote:

 ❦ 24 octobre 2016 14:54 +0200, mich...@domore.fr :


je souhaite pouvoir annoncer en eBGP une route /23.

Dans mon IGP, je ne reçois qu'une route d'un hôte en /32 appartenant
au réseau que je souhaite annoncer.

J'ai ajouté une route /23 gw null0 distance 250 afin que la réseau
soit annoncé à mon peer BGP.

Je ne trouve pas cette solution très "propre".



Il s'agit du classique sujet de la déclaration des supernets de son AS.
Il existe au moins deux écoles.

La 1ere, la plus simple, est de déclarer les supernets en route static 
discard sur tout les routeurs edge et les redistribuer dans ebgp (avec 
contrôle bien évidement, avec des communautés par exemple). L'avantage 
c'est que c'est simple et efficace, et que le trafic non légitime (aka 
sans more specific) est droppé en bordure. Le problème avec cette 
approche est que si un edge se retrouve isolé il continue d'annoncer les 
supernets inconditionnellement (ce qui peut s’avérer très fâcheux).


La seconde méthode est de déclarer ces supernets sur au moins deux 
routeurs non edge (toujours via des static discard) et de les 
redistribuer via ibgp aux edges. On peut utiliser des RS pour cela si on 
en a. L'avantage c'est que si un edge se retrouve isolé il n'annonce 
plus rien à l'extérieur (ce qui est bien mieux :). L'inconvénient c'est 
que les routeurs qui annoncent les supernets vont attirer le trafic 
résiduel (ce qui peut être problématique suivant le volume surtout pour 
des RS offpath). On peut toutefois pallier ce problème en rusant un peu.


--
Raphael Mazelier


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

Re: [FRnOG] [TECH] Nagios (etait: Supervision réseau)

[Raphael Mazelier]

On 21/11/2016 10:30, David Ponzone wrote:

Ah non, c’est pas sympa ça.
Je me disais que j’allais passer du temps sur Sensu, tranquille, sans devoir 
faire de comparaison avec un autre NMS, et tu me rappelles l’existence de 
check_mk….
Bon, quelqu’un a comparé Sensu et check_mk ? :)



Ce sont deux outils/projets complètements différents.

Check_mk est un complément d'un moteur type nagios (nagios, shinken, 
icinga1 ou 2), ou un framework de checks comme j'aime le présenter. 
Attention je ne parle pas des projets qui gravitent autour de check_mk 
(livestatus, wato, etc...) qui sous entendent qu'il s'agit d'une 
solution de monitoring complète, alors que ce n'est pas vraiment le cas. 
C'est plutôt un ensemble de composant (fort bien pensés) gravitant 
autour de écosystème nagios.


Sensu de son coté se place en remplacement du cœur nagios, c'est à dire 
qu'il s'agit en gros d'un scheduleur/récepteur de checks qui déclenche 
des actions le cas échéant. L'architecture est bien plus moderne, et 
surtout le fait que les clients "s'autodéclare" sont un peu la killer 
feature quand tu monitores du cloud.


Ceci étant les deux projets sont complémentaires, tu peux utiliser des 
checks nagios avec sensu, voir même des check_mk via sensu en tordant un 
peu le modèle.



--
Raphael Mazelier


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

Re: [FRnOG] [TECH] Supervision réseau

[Raphael Mazelier]

On 21/11/2016 14:52, Guillaume Barrot wrote:

Observium sur des équipements réseaux équipés d'une CPU décente, ça passe
(oubliez les stacks de Juniper par exemple).
La méthode de polling est brutale.
LibreNMS > même défauts et qualités.



Yep principale qualité c'est user-friendly et complet pour superviser 
les équipements réseaux. Principal défaut le poller, et dans une 
certaine mesure la qualité du code (qui rend à mon sens le projet très 
peu maintenable et extensible).


--
Raphael Mazelier


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

Re: [FRnOG] [BIZ] Transport Paris -> AWS Sydney (Direct Connect)

[Raphael Mazelier]

On 17/11/2016 10:46, Guillaume L. wrote:

Bonjour,

Avez-vous des contacts pour mettre en place un lien Paris (Equinix PA2/PA3)
vers le DC AWS de Sydney ?

C'est pour du Direct Connect.

Nos recherches actuelles n'ayant pas encore données de résultats, je fais
appel à vos contacts et/ou expériences sur ce sujet :)



J'imagine que tu as regardé 
https://aws.amazon.com/directconnect/partners/#apac


sinon demande à telecity ils ont une offre (mais je ne sais pas pour 
sydney). Enfin reacher l'australie c'est l'enfer en général (et très cher).



--
Raphael Mazelier


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

Re: [FRnOG] [TECH] Pb Juniper Ex4500 avec Netconf

[Raphael Mazelier]

Même analyse que Guillaume, j'ai aussi vu des trucs étrange avec les 
vlan-range.



On 15/11/2016 09:26, Guillaume Barrot wrote:

modif de vlans (en masse en prime), ça pue le recalcul spanningtree frelaté
(modif de vlan > changement de topologie > recalcul spt).

Tente le même modif en CLI, et je pense que tu verras les mêmes effets (ie
pas de rapport direct avec Netconf, plutot le fait que les modifs soient
faites en masse)




--
Raphael Mazelier


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

Re: [FRnOG] [MISC] [semi-troll] Pallier aux bêtises des pieds nickelés qui gèrent le DNS chez Orange.

[Raphael Mazelier]

On 18/11/2016 18:43, David Ponzone wrote:

Oui largement suffisant pour tes besoins persos.
Sur un Linux, c’est également simple (quand je dis simple, je veux dire que 
l’install et le setup de base prend exactement 1 min).
Il y a un package pour Synology aussi.
Sous OSX, facile aussi.


Au niveau de la fiabilité de DNS on a eu notre lot d'incident ces 
derniers temps...


Une installation d'unbound (le meilleur resolveur à mon sens en ce 
moment), 2 minutes de configuration et te voila déjà débarrassé des 
resolveurs de tes fai(s) qui font soit des choses bizarres, soit tombent 
en carafes.



D'ailleurs pour revenir sur l'attaque de Dyn je me demande pourquoi les 
gros resolveurs n'utilisent pas un stale cache (et je ne suis 
visiblement pas le seul voir 
https://pdfs.semanticscholar.org/16f5/2ba58eabf88044b99717947019cf2e554288.pdf 
et https://people.mpi-sws.org/~francis/hotnets06-simple.pdf).


Cela briserait certes certaines propriétés du protocole tel qu'il a été 
pensé à l’origine, mais pour un gain véritable de résilience en cas de 
grosse panne/attaque de serveurs faisant autorité.



--
Raphael Mazelier


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

Re: [FRnOG] [TECH] Pb Juniper Ex4500 avec Netconf

[Raphael Mazelier]

On 10/11/2016 21:42, sbu12...@gmail.com wrote:

Bonjour,
Quelqu'un as-t-il déjà eu des souci avec l'utilisation de NETCONF sur un
vChassi de Juniper EX4500?
Essentiellement lors des commit, qui génèrent des curiosités avec les LAG
voire même sur la partie commut. proprement dite.
Les logs ne crachent pas grand-chose, mais lors des commit en NETCONF nous
avons exactement, au même moment, des pertes de paquet, jusqu'aux machines
qui y sont connectés. Théoriquement c'est parfaitement dissocié mais là ça
ne semble pas si simple.
Si qqun a déjà vu ce phénomène.


Étrange, étrange.

J'ai fait beaucoup de netconf(pyez) sur des VC de 4550/4200 ou autres et 
je n'ai jamais constaté ce genre de soucis.


Au moment du commit il reste du cpu pour le reste ?
d'ailleurs sur tout ce qui est soft (Lacp par exemple) le manque de CPU 
ça peut provoquer des soucis sur EX (comme je le disais Pierre). Sur le 
forwarding je suis extrêmement perplexe. Il faudrait que le commit est 
une incidence sur le Trio ? a la limite quand tu reprogramme tout je 
veux bien (gros commit avec changement de paramètre physique sur les 
interfaces ou autres).
Ça apparaît à chaque fois ? sur quel type de commit/changement ? que dit 
le jtac ? (on est vendredi :).


--
Raphael Mazelier


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

Re: [FRnOG] Re: [MISC] [semi-troll] Pallier aux bêtises des pieds nickelés qui gèrent le DNS chez Orange.

[Raphael Mazelier]

On 20/11/2016 12:15, Stephane Bortzmeyer wrote:


La proposition « stale bread is better than no bread » n'est pas un
RFC publié, avec tous les détails traités. C'est une idée en cours de
discussion. Je répondrai donc « bonne question ».



Oui c'est le principal problème que je vois.
En même temps mettre une valeur arbitrairement assez haute pour le stale 
cache (24h par exemple) me semble un compromis.
Dis autrement cela force les gens qui veulent invalider une délégation à 
le faire proprement (et ne pas juste éteindre les serveurs). Sinon ils 
attendent un peu...


--
Raphael Mazelier


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

Re: [FRnOG] [TECH] Supervision réseau

[Raphael Mazelier]

On 20/11/2016 17:07, Hugues VOITURIER wrote:

+1 pour observium :)


Oui c'est joli, mais c'est affreux en terme de performance.
Ça fait le taf pour tout ce qui est graphing si on a des devices pas 
trop capricieux, niveau monitoring/alerting mieux vaut autre chose 
(nagios like ou zabbix).


--
Raphael Mazelier


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

Re: [FRnOG] [TECH] Pb Juniper Ex4500 avec Netconf

[Raphael Mazelier]

On 12/11/2016 02:22, Olivier Benghozi wrote:

Il n'y a pas de Trio dans un EX (sauf l'EX9200 qui est un MX rebadgé).
Dans un EX4500 il y a un Marvell Prestera.



J'étais bien réveillé encore quand j'ai écrit ça :) c'est pas comme si 
je le savais pas en plus vu le nombre de log que ça écrit avec MRVL dedans.



--
Raphael Mazelier


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

Re: [FRnOG] [TECH] AS-stats sur routeur Juniper

[Raphael Mazelier]

Bonjour,

Oui cela ressemble bien à une configuration de flow valide. J'avais ça 
chez moi sur un mx en non inline :


forwarding-options {
sampling {
input {
rate 1000;
}
family inet {
output {
flow-server X.X.X.Z {
port 5678;
source-address X.X.X.X;
version 5;
}
}
}
}
}

avec sampling sur les interfaces.

Le problème c'est que tu as un m10i. De souvenir sur m10i tu peux soit 
le faire en soft ou en inline avec une MS-PIC.


Tu as regardé si le démon sampled (ou l'autre cflowd je ne sais jamais) 
s’exécutait bien ? Essaye un truc du style :


forwarding-options {
sampling {
input {
family inet {
rate 1000;
}
}
output {
cflowd X.X.X.Z {
port 9996;
source-address X.X.X.X;
version 5;
}
}
}
}


Question : un m10i ? tu as une raison de garder un tel équipement ? OK 
c'est increvable mais bon niveau support ça va commencer à devenir 
compliqué, sans compter la place et l’électricité.





On 31/10/2016 02:00, Philippe Bonvin wrote:

Bonjour la liste,


J'essaie vainement de configurer un routeur Juniper M10i pour exporter des 
NetFlow pour AS-stats (https://github.com/manuelkasper/AS-Stats).



--
Raphael Mazelier


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

Re: [FRnOG] [BIZ] Cherche FAI Marseille

[Raphael Mazelier]

Je valide Pacwan. Petite société à taille humaine composé d'excellent 
professionnels des telecoms. Je suis forcement partial puisque je 
connais bien. Sinon dans le sud tu as aussi forcement Jaguar.


On 02/11/2016 15:55, Christophe Casalegno wrote:

On vient de signer de la fibre pour de nouveaux bureaux chez PacWan,
c'est un acteur local. (www.pacwan.net). Je ne peux pas encore faire de
retour qualité, ce n'est pas encore en prod, mais le fait qu'ils soient
présents comme nous sur le Datacenter Realtor de TDF était un signe
engageant ;)



--
Raphael Mazelier


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

Re: [FRnOG] [TECH] AS-stats sur routeur Juniper

[Raphael Mazelier]

Si c'est possible, je me rappelle avoir fait ça dans le passé :)

Après pourquoi changer ? bah justement parce que c'est du vieux matériel 
; que le support devient parcellaire, et que le rapport 
poids/encombrement/puissance est très mauvais.


Je préférerais avoir un routeur soft, qu'un vieux routeur hard mais 
c'est personnel.



On 01/11/2016 14:08, Philippe Bonvin wrote:

Bonjour à tous,

Merci pour vos réponses.

En fait ce routeur a une CFEB-E Multiservices et un RE-1800, je dois dire qu'il 
se porte plutôt bien malgré son age !
Ni la place ni l'électricité ont été un problème jusqu'à maintenant donc pas de 
raison de le changer, tout simplement.

J'ai ni cflowd ni sampled dans les process.
J'ai également essayé de faire un "set output cflowd x.y.z.a" mais il le converti 
automatiquement en "flow-server".

La documentation de Juniper sur le flow-monitoring n'est pas très claire je 
trouve, d'autant plus que j'avais essayé de le configurer en inline, sans 
succès.

Bon...pas de flow monitoring sur ce routeur ?

Philippe



--
Raphael Mazelier


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

Re: [FRnOG] [TECH] Pb pour joindre différents sites Web

[Raphael Mazelier]

Normalement il y a du nexthopself, et rien n'est redistribué vers l'IGP (dans 
lequel on ne trouve que les intercos IGP et les loopbacks qui permettent de 
monter les sessions iBGP).



Et encore les intercos c'est discutable.



Et puis comme dit David, quand on fait une policy/une route-map vers 
l'extérieur, on n'annonce rien par défaut. Et on annonce uniquement les routes 
taggées avec certaines communautés BGP.
Bien entendu qu'on filtre ce qu'on reçoit, genre les bogons, ses propres routes 
(cf le route serveur d'Equinix) et les préfixes des points d'échange - a minima 
ceux auxquels on participe.


Oui les constructeurs devraient faire tout leurs exemples en ce sens, 
c'est pourtant assez peu le cas.




Visiblement vus les impacts, il y a pas mal d'ingénieries et de confs conçues par Kevin 
Pradesh de QuickShitPrestaConsulting, à base de configurations "naïves".
Loin de moi l'idée de donner des leçons, mais c'est compliqué le réseau, c'est 
un métier (et ceci-dit tout le monde peut se tromper, l'erreur est humaine, il 
n'y a que ceux qui ne font rien qui font bien, etc).


Le truc c'est que visiblement il n'y a pas encore assez de bonne 
documentation/formation sur les best practices de comment faire du 
réseau dans la vrai vie. On a tous plus ou moins appris sur le tas avec 
les exemples des autres.


Le réseau c'est un métier mais j'ai toujours trouvé qu'on n'en 
facilitait pas l'accès...



--
Raphael Mazelier


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

Re: [FRnOG] [TECH] Pb pour joindre différents sites Web

[Raphael Mazelier]

On 23/12/2016 21:58, Vincent Bernat wrote:


J'espère un jour publier un exemple commenté de conf JunOS complète pour des
border routers (avec des transitaires, des peerings, des exemples de
politique de routage). Pour le moment, je dois encore travailler dessus. Ce
serait effectivement appréciable que cela existe.



Si je peux contribuer ça serait avec plaisir. J'ai moi même pas mal 
d'exemple en stock que je voudrais partager.
Il y a tant de détail qui peuvent se discuter (tiens un truc me vient en 
tête le NHS, faut il le faire aveuglement ou de manière plus subtile, 
d'ou annoncer ses supernets, que mettre dans son IGP, faire des VRFs ou 
pas, mettre Internet dans une VRF, etc..)


--
Raphael Mazelier


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

Re: [FRnOG] [TECH] Pb pour joindre différents sites Web

[Raphael Mazelier]

On 23/12/2016 23:10, Olivier Benghozi wrote:

Quand on active un OSPF ou un ISIS sur une interface, le subnet d'interco se 
retrouve dans l'IGP de fait.




Certes bien mais ce n'est pas une fatalité. J'aime bien mon IGP quand il 
n'y a que les loopbacks cela donne un coté clair.



--
Raphael Mazelier


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

Re: [FRnOG] [TECH] Pb pour joindre différents sites Web

[Raphael Mazelier]

Multiple fail en fait.

L'Afnic qui annonce un rogue c'est moche mais ça arrive...
A défaut de correctement contrôler ses annonces, on peut au moins mettre 
les gardes fous courants (ne pas annoncer les bogons, les 1918, les Ixs, 
etc...). A noter quand même que sous Junos  il y a moult templates très 
bien fait en circulation qui s'assurent que ce genre de chose n'arrive 
pas. (a part quand on est transitaire il faut un peu le faire exprès 
pour ne pas n'annoncer que ces supernets).


Equinix-ix qui ne filtre pas son propre subnet d'IX sur ses RS(encore 
que ce point n'a pas été vérifié, peut etre que seul on été impacté les 
personnes qui peer avec l'afnic sur Equinix-ix ?)


Le reste relève de la bonne gestion locale

Accepter un subnet d'un IX bof, ne pas faire de nhs dans sont AS bof 
(enfin c'est discutable), redistribuer aveuglement bof bof...


Bref c'est autant de la faute de l'Afnic que des AS impactés.

--
Raphael Mazelier

On 22/12/2016 11:23, Clement Cavadore wrote:

Le probleme est que l'AFNIC annonce le /23 de l'Equinix depuis hier
soir, et que pour ceux qui ne font pas de next-hop-self, la route en BGP
est préférée aux autres.

=> Filtrez les subnets de l'IXP en bordure/BGP (ce que tout bon netadmin
devrait faire, par défaut), et vous n'aurez pas/plus de soucis.




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

Re: [FRnOG] RE: [TECH] Pb pour joindre différents sites Web

[Raphael Mazelier]

On 22/12/2016 18:05, Aurélien Poret wrote:

Je suis d'accord avec Stephane, Y a eu d'autre chose.
J'ai eu des impact que sur certains protocole.  Sonde et ICMP ok... DNS non 
OK

J'ai bien le NHS sur mon réseau. Et j'avais bien la route qui va bien.

Par contre en face chez SFR (entre autre) ca semblait pas revenir correctement.
Donc on a été impacté quand même...



Malheureusement tu ne maîtrise pas comment cela se passe chez les autres...

--
Raphael Mazelier


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

Re: [FRnOG] [TECH] Solution Anti DDOS

[Raphael Mazelier]

Oui c'est vraiment pas cher; et ca permet de détecter des DDOS assez 
basiques. Et de lancer un peu de mitigation custom le cas échéant.


En tout cas pour une console de flow rapide ca vaut le prix.

Cdt,

--
Raphael Mazelier


On 29/03/2017 09:49, Alexandre DERUMIER wrote:

sinon, pas trop cher mais pas opensource

Wanguard

https://www.andrisoft.com/






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

Re: [FRnOG] [TECH] Matériel pour LNS/LAC

[Raphael Mazelier]

On 05/04/2017 11:07, Sébastien Lesimple wrote:


Je pense que je vais être sage et partir sur du Cisco 7301 éprouvé selon vos 
expériences!

Le besoin est celui exprimé par Jérôme !



Une solution non évoquée et qui permet de commencer sans frais (bien que 
le 72/3xx ne coûte plus rien) est de partir sur une solution full 
software sous linux/freebsd.


Il y a différentes solutions qui fonctionnent bien (openl2tp par 
exemple) et qui scalent pas si mal (surtout dans cette ère du tout vm). 
Après honnêtement ce sera sans doute plus compliqué à mettre en place au 
début, mais certainement gagnant sur le long terme.


--
Raphael Mazelier


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

Re: [FRnOG] [FRNOG][TECH] Quagga migre en FRR

[Raphael Mazelier]

C'est chouette, par contre, FRR c'est plutôt con comme acronyme pour
un daemon de routage. J'imagine même pas les résultats d'une recherche
"frr bgp" par exemple...



C'est définitivement une excellente nouvelle de voir un projet de 
routage libre renaître de ces cendres. Les nouveautés sont tellement 
attendues (LDP, add-path, ISIS). On pourra peut être prétendre un jour 
avoir une pseudo stack MPLS.



Deux questions toutefois :

- pourquoi FRR ? à part jeu de mot c'est effectivement confusant :)
- pourquoi partir de quagga ? j'imagine que le code patché était déjà 
important, mais bird (et surtout le futur bird 2.0) me semble une bien 
meilleure base.


--
Raphael Mazelier


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

Re: [FRnOG] [FRNOG][TECH] Quagga migre en FRR

[Raphael Mazelier]

C'est chouette, par contre, FRR c'est plutôt con comme acronyme pour
un daemon de routage. J'imagine même pas les résultats d'une recherche
"frr bgp" par exemple...



C'est définitivement une excellente nouvelle de voir un projet de 
routage libre renaître de ces cendres. Les nouveautés sont tellement 
attendues (LDP, add-path, ISIS). On pourra peut être prétendre un jour 
avoir une pseudo stack MPLS.



Deux questions toutefois :

- pourquoi FRR ? à part jeu de mot c'est effectivement confusant :)
- pourquoi partir de quagga ? j'imagine que le code patché était déjà 
important, mais bird (et surtout le futur bird 2.0) me semble une bien 
meilleure base.


--
Raphael Mazelier


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

Re: [FRnOG] [FRNOG][TECH] Quagga migre en FRR

[Raphael Mazelier]

On 07/03/2017 18:27, Guillaume Barrot wrote:


Pour avoir testé les deux récemment, c'est surtout de la guerre de chapelle
entre les pro Bird, et les pro Quagga.


Je ne voulais froisser personne en posant cette question (meme si je 
m'apercois que j'ai fait un imper). J'ai géré mon premier véritable AS 
avec un pII sous zebra en 2002 :)



Les deux se comportent plutôt pas mal, et je pense qu'en dehors du cas
particulier des routes servers _ où BIRD s'impose surtout par ses capacités
de filtering _ , il n'y a plus vraiment de différence de perf entre les
deux, que ce soit en temps de convergence, temps de compute, etc.
Il faut avouer que le matériel récent joue aussi beaucoup dans un lissage
des perfs.



Je serais tout de meme curieux d'avoir des benchs de temps de 
"convergence" d'une full actuellement avec les deux, meme si cela doit 
etre surtout lié à netlink.




Bird semble vraiment centré sur le routing, alors que Quagga devient plus
un gros control plane complet (y compris du proto orienté L2, genre LLDP).


True.

Pour moi les principales différences, au délà des protocoles supportés, 
et des détails techniques internes (qui me font préferer bird) sont 
l'expressivité du langage de configuration et l'utilisation massives des 
tables dans bird. Dans un cas on est limité par ce qu'il est 
prévu/possible de configurer, dans l'autre cas on est plus dans de la 
programmation.  (un peu comme cisco vs juniper, en pire)


Il me semble donc plus simple d'appréhender quagga quand on est 
débutant. Mais il me parait plus aisé d'utiliser bird pour mes 
uses-cases tordus.


Maintenant le support d'ISIS, LDP, RSVP et autre protocole un peu 
indispensable risque de faire la différence (dans un sens ou l'autre).
C'est quand meme un peu la loose qu'en 2017 on est pas une stack MPLS 
libre digne de ce nom (au moins un control plane).

Meme s'il parait que MPLS c'est mort :)


Pour reprendre un posteur régulier de la liste, qui se reconnaîtra, mais un
moment faut arrêter avec les IGP de mamie (OSPF) et prendre un vrai
protocole d'homme avec des poils quoi (IS-IS, évidemment).



Ahaha je ne sais pas qui à dit ca mais je ne peux qu'approuver :)


--
Raphael Mazelier



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

Re: [FRnOG] [TECH][BIZ] Open Networking : fournisseurs et NOS ?

[Raphael Mazelier]

Bonsoir,

Je serais extrêmement intéressé par tout retour également.
Surtout sur la partie comparaisons prix/fonctionnalités des NOS.


On 09/03/2017 14:14, Jérôme Nicolle wrote:

Bonjour,

Un de mes projets en cours va être l'occasion de tester du matériel Open
Networking, nommément des switchs EdgeCore 10/40/100G et les différents
NOS qui tournent dessus.

Deux questions :
- Connaissez vous un distributeur, si possible en France, capable de me
fournir des switchs EdgeCore et des licences pour les NOS (au moins
cumulus, ocnos et pica8) ?
- Savez vous s'il existe un comparatif des caractéristiques réellement
implémentées et fonctionnelles des différents NOS ?

Merci !



--
Raphael Mazelier


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

Re: [FRnOG] [TECH] Matcher simplement IP => AS

[Raphael Mazelier]

On 10/03/2017 18:44, Nathan delhaye wrote:

Hello,

Est-ce que l'un d'entre vous connais un soft/script permettant de matcher
_SIMPLEMENT_ et gratuitement des IP vers un AS number?

J'ai entre 100 et 200 IP uniques a valider par secondes, ce qui exclus un
whois lookup.

Bien entendu, je pourrais me faire mon usine a gaz a base de dump régulier
de fulltable + agrégation, mais je me doute que je ne suis pas le premier à
avoir la problématique donc il doit bien exister quelque chose dans le
genre.

Je sais qu'il existe la DB ISP de Maxmind, mais payer 25$ par mois pour des
données publiques, ça me fait chier :)

A+



Bonne question. Personnellement j'ai fait comme tout le monde ma propre 
solution. Router => export via pmacct => amqp => 30 lignes de python/go 
pour faire une api.


--
Raphael Mazelier


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

Re: [FRnOG] [TECH] Matcher simplement IP => AS

[Raphael Mazelier]

On 10/03/2017 18:51, Alarig Le Lay wrote:


Hello,

Quick and dirty :
regis ~ # birdc show route primary for 89.234.186.1 | grep AS | cut -d '[' -f 3 
| cut -d ']' -f 1 | sed 's/[ie?]//'
AS204092



Pas mal :)
par contre ca tiendra pas 200 requêtes/seconde. Dans ce cas tu es obligé 
de travailler sur un dump quelconque.



--
Raphael Mazelier


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

Re: [FRnOG] [TECH] Matcher simplement IP => AS

[Raphael Mazelier]

On 10/03/2017 21:10, Samuel PIRON wrote:

Bonjour,

En webservices, il y a https://iptoasn.com/ (par
https://twitter.com/jedisct1) qui pourrais faire l'affaire.
Il fournit aussi les bases mises à jour régulièrement, en format texte
et facilement parsable.








Eh parfait ça ! tu peux installer le truc chez toi et download les maj 
régulièrement. (en plus codé par par Franck Denis ça doit pas être top 
mal :)


--
Raphael Mazelier


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

Re: [FRnOG] [TECH] Ping depuis ibgp/ospf quagga

[Raphael Mazelier]

On 11/08/2017 14:10, Antoine DURANT wrote:


Le préfixe A.A.A.A/24 est directement connecté à quagga2 via son upstream. 
Depuis quagga2 je peux effectivement pinguer A.A.A.A


Quand tu dis directement connecté, tu veux dire que c'est vraiment un 
subnet rattaché à une interface de ton quagga2 ?



Depuis qagga1 qui ne connait pas A.A.A.A/24 via son upstream il le connait via 
ibgp/ospf.


Question si c'est le cas, ce subnet connected est redistribué uniquement 
dans ibgp (ou dans ospf aussi ? visiblement ibgp)


A.A.A.0/24 est physiquement dans la table de routage de quagga1 mais il ne peut 
pas pinguer A.A.A.A même en utilisant la dummy du ibgp.


tcpdump est ton ami.

Avec quelle @IP source/dest le paquet icmp de A => B arrive sur B et 
comment il ressort sur B et arrive sur A (ou pas d'ailleurs).



--
Raphael Mazelier


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

Re: [FRnOG] [TECH] Avis sur switch juniper ex3300

[Raphael Mazelier]

On 13/07/2017 11:51, Jean-Baptiste COUPIAC wrote:


On utilise des EX3300 depuis quelques années à présent.
Aucun soucis, fiable, et surtout JunOS , avec son commit confirmed.

Niveau prix, un EX3300 en 48T, c'est moins de 1400€, donc plutôt bon marché


J'ai déjà eu l'occasion de le dire mais dans Job-1 on était utilisateur 
massif des ex3300 dans des configurations variés (du switch standalone, 
au VCs de 8 membres avec multiples ajouts/reconf).


Globalement le rapport qualité prix est excellent.
Je mentirais si je disais que dans le tas on a pas eu des soucis; mais 
j'en reprendrais sans hésiter (je ne dirais pas ça de toute la gamme EX, 
les nouveaux n'étant toujours pas sec)
Un des soucis agaçant reste le snmp qui peut bouffer tout le cpu de la 
RE surtout sur les gros VCs.


--
Raphael Mazelier


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

Re: [FRnOG] [TECH] UCARP/VRRP avec Debian problème

[Raphael Mazelier]

On 07/07/2017 19:33, David Ponzone wrote:

Je sais pas si c’est encore d’actualité, mais en cherchant vite fait pour aider 
Sébastien, j’ai trouvé ça concernant uCARP:

http://www.syawar.com/2013/01/16/ucarp-prevent-re-assertion-of-original-master/ 
<http://www.syawar.com/2013/01/16/ucarp-prevent-re-assertion-of-original-master/>

A priori, le monsieur a aussi eu besoin de déclarer les 2 en SLAVE pour que ça 
tombe en marche, avec un inconvénient.




Cela vaut ce que vaut comme retour, mais j'avais eu exactement le meme 
genre de soucis quand j'avais évaluer ucarp à l'époque. Après avoir lu 
le code source en partie j'avais conclu sur le fait que cela ne faisait 
pas ce qui était annoncé. Étonnant pour un truc codé par Franck Denis 
mais bref j'étais passé sur keepalived. (et pourtant j'étais fan du 
truc, simple et efficace sur le papier).


Sinon s'il y a des gens aventureux ils peuvent tester mon essai d'un 
démon de HA : https://github.com/ut0mt8/simple-ha-go ; ça marchait pour 
moi :)



--
Raphael Mazelier


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

Re: [FRnOG] [TECH] Questions Nexus 3000

[Raphael Mazelier]

On 09/07/2017 02:54, Guillaume Barrot wrote:


Ouais enfin n'oublions pas que SpanningTree, ISIS ... tout ça c'est DEC.
Le FC, Brocade. Etc.



On a dit la même chose je crois. Mon point était de dire qu'on a souvent 
copier des protocoles propriétaires Cisco (ou autres) pour les 
normaliser, plus par facilité qu'autre chose. Cisco et les autres 
poussent leurs propres technologies/protocoles plus dans une logique de 
locking des utilisateurs que dans une vraie réflexion de fond sur les 
besoins du réseau de nos jours.


Malheureusement pour eux l'opensource comme ailleurs va gagner. Ça 
prendra juste un peu plus de temps qu'ailleurs mais c'est inéluctable.


Et peut être que ces sociétés vont comprendre qu'elles devraient se 
recentrer sur ce qu'elles font bien : du hard high-end et de l'intégration.


--
Raphael Mazelier


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

Re: [FRnOG] [TECH] Questions Nexus 3000

[Raphael Mazelier]

On 06/07/2017 21:23, Michel Py wrote:



C'est pas un peu usine à gaz sur les bords pour remplacer deux commandes qui 
marchaient depuis la nuit des temps en IOS et que Cisco a pas jugé bon 
d'implémenter en NXOS ?



VTP sérieusement ? je n'envisage même pas que l'on puisse utiliser cela 
en prod; cela c'est toujours terminé en désastre par chez moi.


Non franchement l'automatisation des équipements réseaux ce n'est plus 
optionnel. En revanche ce qui est plus discutable c'est l'implémentation.


Sur les différentes gamme de nexus c'est assez disparate. (pour ne pas 
dire plus). Arista, Juniper et autre nouveau NOS sont bien plus avancé 
sur le sujet.


--
Raphael Mazelier


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

Re: [FRnOG] [TECH] Questions Nexus 3000

[Raphael Mazelier]

On 08/07/2017 05:42, Michel Py wrote:


Ben justement je suis "enterprise" maintenant et sur le réseau de prod 
principal (on en a plusieurs petits ou c'est physiquement séparé pas, dans la même salle, 
et toussa) qui est à ce jour 100% Catalyst çà me fait bien chier de devoir mettre encore 
une autre usine à gaz parce que sur certains Nexus, Cisco a désactivé VTP client. Encore 
une niaiserie de leur marketing à la con.
Les enfants, le réseau çà existait avant l'Internet et il reste encore quelques 
vieux cons qui se rappellent ce que c'était avant. Je me rappelle de mon 
premier commutateur, avant que Cisco ne l'appelle Catalyst : c'était un Grand 
Junction, çà coutait la peau du c.., on pouvait avoir que 1 MAC adresse par 
port 10 mégas sauf pour LE port 100 mégas, et il y avait pas VTP.



On tous commencé avant internet je te rassure, ça n’empêche pas de vivre 
avec son temps, surtout quand les nouvelles options proposées sont plus 
malines.


Si tu es full cisco il y a plein d'autre options pour du campus.


Si il n'y avait pas VTP, EIGRP, VPST, ISL, HSRP, et autres "merdes 
propriétaires" inventées par Cisco je me demande bien qui aurait inventé dot1q, 
VRRP, et autres.



Alors la c'est extrêmement discutable. Il est indéniable que Cisco a été 
vecteur d'innovation dans le réseau. Mais s'il n'avait pas été la 
quelqu'un l'autre fait différemment et on aurait peut être des 
protocoles mieux foutu ? Dans bien des cas on a normalisé un protocole 
propriétaire cisco quasi à l'identique. Bien ou pas ?


--
Raphael Mazelier


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

Re: [FRnOG] [TECH] Optimisation bgp avec 2 transits

[Raphael Mazelier]

On 15/07/2017 11:44, Antoine DURANT wrote:



Comment feriez vous dans cette configuration ?



Relire l'algorithme de path selection de bgp.

http://packetlife.net/media/library/1/BGP.pdf par exemple (parce que 
packetlife fait de beaux cheatsheets)


--
Raphael Mazelier


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

Re: [FRnOG] [MISC] Forage à PA3

[Raphael Mazelier]

On 25/07/2017 17:02, Hugues VOITURIER wrote:

À mon avis ils veulent nous faire une Online et construire un abri anti 
atomique sous le DC :D



Ou plus probablement ils sont à la recherche de quelques fibres qu'ils 
ont égarés ;)


Perso si j'étais encore à PA3 je serais pas plus rassuré que ça...

--
Raphael Mazelier


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

Re: [FRnOG] [TECH] Gérer le cas d'une rupture de liaison entre deux routeurs d'un même AS

[Raphael Mazelier]

Quelle est la façon "propre" de faire cela ? Cad d'avoir deux sites avec leur 
propres transit, habituellement connectés mais qui puissent se comporter comme deux iles 
le temps que l'on répare ?


Comme l'a justement dit Guillaume ce cas ne doit pas arriver. Ton ibgp 
ne doit pas casser.


Soit tu prend deux AS distincts/indépendants et qui donc peuvent vivre 
leurs vies (et cela peut faire sens), soit tu redondes tes liens 
correctement.


Évidement le soucis c'est que tu n'as pas les même @IP des deux cotés, 
(c'est plutôt sain comme pratique pour la redondance), mais je conçois 
que cela peux poser problème. (a part si tu veux anycaster certain 
services mais c'est un autre sujet).


Après si tu veux conserver un seul AS et que tu n'as pas de vrai budget 
fibres tu peux tenter des trucs étranges/sales :


Tu peux par exemple annoncer ton superblock des deux cotés et choisir un 
sous block par site, originate que du site en question en ebgp et ibgp, 
de sorte qu'en cas de split brain chaque site n'annonce que le 
superblock et son sous-block. Et tu retombe dans le cas ou tu dédie des 
plages spécifiques à chaque site, donc autant les rendre complètement 
indépendants et demander un 2eme ASn.


Les vrais questions que tu dois te poser en tout cas : à quoi sert ton 
multi-site actuel ? full redondance ? aucune dépendance entre les sites 
? n'as tu vraiment pas de budget pour une lambda ou dark ? (parce que 
c'est franchement peu cher en RP).



PS : tu peux aussi en effet faire du backup sur GRE (j'ai déjà fait en 
désespoir de cause entre paris et nyc *fear*) mais c'était vraiment un 
palliatif temporaire.




--
Raphael Mazelier


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

Re: [FRnOG] [TECH] optique DWDM pour une Lambda inter DC de Lambda Paris

[Raphael Mazelier]

On 05/07/2017 18:28, Souhayel BELHAJ wrote:

Bonjour,

Solid-Optics ça fonctionne plutôt bien.



Yep solid-optics, pure-optics, ou du skylane (via infractive par ex).
J'ai eu des soucis en revanche avec un site chinois en deux lettres.

--
Raphael Mazelier


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

Re: [FRnOG] [TECH] optique DWDM pour une Lambda inter DC de Lambda Paris

[Raphael Mazelier]

On 05/07/2017 22:07, Michel Py wrote:


Tu pourrais préciser quel genre de soucis ? J'ai pas encore acheté du DWDM chez 
eux mais je m'approvisionne régulièrement pour les optiques grises et les 
cables.



Sur du consommable (du gris et du DAC) pas énormément de soucis, un taux 
de panne raisonnable.


Sur du *wdm en revanche un festival, mauvais codage, mauvaise longueur 
d'onde, sensibilité en rx foireuse, etc... j'en passe et des meilleures. 
Ceci étant ils m'ont toujours repris les optiques, mais le temps passé 
en debug, allez-retour au DC, en colis vers la chine et en discussion 
avec le support n'a pas compensé le meilleur prix initial.


--
Raphael Mazelier


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