Re: [FRnOG] [TECH] [Orange] Adresse IPv6 du résolveur DNS

[Olivier Benghozi]

La Livebox «v4» annonce en DHCPv4 un DNS IPv4 privé (l'adresse de la box coté 
LAN) et en RA + DHCPv6 (flag Other Config du RA à 1) un DNS IPv6 link-local (la 
link-local de la box coté LAN).
Il s'agit apparemment  d'un dnsmasq version 2.78 sur la box.

Les deux adresses répondent.



> Le 8 sept. 2019 à 18:58, Stephane Bortzmeyer  a écrit :
> 
> Là, comme ça, je n'ai pas d'accès chez Orange, donc je vais utiliser
> les frnogiens pour tester.
> 
> Il parait (ce n'est pas confirmé) qu'Orange (filaire, pas 4G) envoie
> (par RA ?) une adresse IPv6 d'un résolveur DNS, que cette adresse est
> de type locale au lien (genre fe80::a63e:51ff:fe77:e26) et qu'elle ne
> répond pas, perturbant la résolution DNS. C'est ce qu'on dit, mais je
> fact-checke.
> 
> Vrai ou faux ? Quelqu'un chez Orange peut-il regarder ?
> 


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

Re: [FRnOG] [TECH] AS32 bit private range et SNMP

[Olivier Benghozi]

Tu vois bien que cet oid est défini (bêtement) dans la MIB standard BGP4-MIB 
comme Integer32, cad un entier signé sur 32 bits.
Tu n'as donc aucune chance d'y voir une valeur positive supérieure à 2^31-1 
(2147483647) autrement que comme valeur négative.
C'est donc sans aucun rapport avec le constructeur.

Bien sûr tu pourrais remplacer Integer32 par Unsigned32 pour cet oid 
bgpPeerRemoteAs dans ton fichier BGP4-MIB.

Mais note que dans BGP4V2-MIB il existe déjà à la place un bgp4V2PeerRemoteAs 
de type InetAutonomousSystemNumber défini comme Unsigned32 dans 
INET-ADDRESS-MIB.
Et qu'il y a l'équivalent dans BGP4-V2-MIB-JUNIPER (jnxBgpM2PeerRemoteAs), pris 
en charge par ailleurs par observium.

Donc encore plus incroyable: tu désactives la MIB BGP4-MIB pour ce routeur dans 
observium, ou tu fais une view pour exclure les oid BGP4-MIB dans ton routeur.

Bref, le bug est dans la MIB d'origine (des entiers signés pour des valeurs 
sans signe, quelle bonne idée).


> Le 4 sept. 2019 à 01:34, Guillaume Barrot  a 
> écrit :
> 
> Sur un équipement dont je tairai l'équipementier, par respect pour son
> honneur technique, je fais face à ce magnifique bug :
> 
> Session BGP
> 
> Peer AS  InPkt OutPktOutQ   Flaps Last
> Up/Dwn State|#Active/Received/Accepted/Damped...
> x.x.x.x *420001   *1811   1734   0   013:12:59
> Establ
> y.y.y.y  *420002*  22981  21976   0   0 6d 23:42:02
> Establ
> 
> et quand on veut remonter ça en SNMP, on obtient :
> 
> bgpPeerRemoteAs.198.19.174.9 = *-94967295*
> bgpPeerRemoteAs.198.19.174.11 = *-94967294*
> 
> Bref, les plages d'AS privés 32 bit (42 - 4294967294) remontent en
> SNMP en valeur négative sur la MIB standard.
> 
> J'aurai tendance à penser que la limitation vient de la MIB en elle même,
> mais je n'ai pas d'autres fournisseurs sous la main pour valider cette
> théorie.
> Donc si de bonnes ames peuvent regarder sur du Cisco, Juniper, Brocade,
> whatever si ils reproduisent le "bug" je serai intéressé du résultat pour
> savoir ce qu'il va falloir corriger.
> 
> Pour info, en Netconf, 0 issue, la valeur 32 bit remonte bien.
> Mais bon Observium / Librenms ne fonctionnent pas en netconf, alors SNMP
> c'est quand même pratique.


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

Re: [FRnOG] [TECH] UDP Storm 1 vs Mikrotik 0

[Olivier Benghozi]

Je vote pour des paquets IP avec TTL à 1

> Le 20 juil. 2018 à 20:10, David Ponzone  a écrit :
> 
> Contexte: un Mikrotik (RB3011 dernier firmware) qui termine des sessions PPPoE
> J’ai vu un flux de paquets UDP venant de l’IP publique d’un des clients 
> PPPoE, port source aléatoire, allant tous vers une IP publique d’un abonné 
> Timewarner.
> Débit du flux: autour de 90Mbps
> [...]
> Soit soit j’aurais dû en fait vérifier une 4ème fois, soit des mecs ont 
> trouvé une attaque UDP qui font mal au serveur PPPoE du Mikrotik et ne vont 
> pas plus loin.


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

Re: [FRnOG] [TECH] Les AS privés dans les AS-PATH

[Olivier Benghozi]

> Le 5 juin 2018 à 12:27, Frederic Dhieux  a écrit :
> 
> sauf que c'est arrivé parfois aussi à des gros
> FAI français par exemple qui découpent leur réseau par zones comme ça et
> oublient le remove-private-as

Le supernet reste généralement annoncé, donc joignable.

Et comme des très gros filtrent désormais (au moins NTT, GTT, AT), ceux qui 
annoncent de la merde seront immédiatement impactés en cas d'injoignabilité.
Par conséquent tout le monde peut désormais filtrer sans scrupule.


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

Re: [FRnOG] [TECH] Les AS privés dans les AS-PATH

[Olivier Benghozi]

Hello,

> Le 4 juin 2018 à 16:22, Julien Escario  a écrit :
> 
> Suite à la mise en place de sessions BGP avec Qrator Radar, ils me remontent
> pas mal de routes en bogons à cause d'AS-PATH contentant des AS privés (donc
> la tranche 64512-65534).
> 
> Vous filtrez ça ?

Tout à fait, tout comme plusieurs fournisseurs de transit. Voir annonce et 
discussion sur NANOG initiée par Job Snijders (NTT):
http://seclists.org/nanog/2016/Jun/56 


> J'ai lu que sur Cisco, il y a une commande pour virer les private AS des
> AS-PATH mais je n'ai pas trouvé sur mes krotik. Si quelqu'un a le filtre
> magique, je prends.

C'est pour le sortant. Ça fait clairement partie des best practices de 
l'activer, ça éviter d'annoncer de la daube.


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

Re: [FRnOG] [TECH] Juniper MX204

[Olivier Benghozi]

C'est 400Gb/s dans chaque sens.
Donc en principe tu attribues les vitesses port par port pour arriver à 400 max 
(100 / 40 / 4x10 pour les QSFP+/28, et 10 pour les SFP+)...
Sauf que visiblement si les ports QSFP+/28 sont tous les quatre configurés à 
une même vitesse (tous à 100 ou tous à 40/4x10), alors les 8 SFP+ sont 
désactivés.
Donc par exemple pour maximiser le nombre de ports 10G, il faut configurer un 
port QSFP28 en 100G et les trois autres en 4x10 (ce qui fait 20 ports 10G avec 
les 8 SFP+).

En tous cas les possibilités sont décrites à la section "Table 4: Port 
Configuration at PIC Level in MX204 Routers" de:
https://www.juniper.net/documentation/en_US/junos/topics/concept/port-speed-capability-mx204router.html
 


C'est tellement simple qu'ils ont fait une page pour vérifier:
https://apps.juniper.net/home/port-checker/ 


Concernant les ports SFP+/SFP, ils peuvent être configurés en 1G, dit la doc.

> Le 25 avr. 2018 à 18:48, Yannis Aribaud  a écrit :
> 
> On ne peut pas utiliser tous les ports du routeur à leur capa max en même 
> temps (800Gbps max donc logique). Plus précisément, si on utilise les ports 
> QSFP28 en 100Gb ben on ne peut pas utiliser les SFP+. Les ports QSFP28 ne 
> peuvent pas faire du 25Gb. Si on utilise les ports QSFP28 en 4x10G alors on 
> ne peut utiliser qu'un seul port SFP+ (pb de mac) ou alors il faut modifier 
> une option qui permet d'utiliser tous les ports en 10Gb (4x10Gb pour les 
> QSFP28) mais impossible de faire du 1Gb sur les SFP+.


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

Re: [FRnOG] [TECH] Juniper MX204

[Olivier Benghozi]

> Le 25 avr. 2018 à 19:02, Yannis Aribaud  a écrit :
> 
> Sauf que "no limit (datasheet performances)" ben je trouve les datasheet 
> performances absolument nulle part.

Comme d'hab, que ce soit chez Jun, chez Cisco, ou ailleurs. Mais enfin en 
pratique le chip dedans est maintenant largement déployé, c'est donc que la 
courbe de pps selon la taille des paquets doit être convenable.


> Et ça ne répond pas à la question est-ce software ou hardware ? On peut 
> upgrade par la suite en achetant la licence qui va bien ou faut changer le 
> châssis ?

C'est une licence, c'est pas une limite hardware.


> Le 25 avril 2018 18:56 "Raphael Maunier"  > a écrit:
> 
>> MX204 2M fib / 6M rib & 32 vrf
>> MX204-IR No fib/rib limit (datasheet performances) but 32 vrf
>> MX204-R No limit


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

Re: [FRnOG] [TECH] Upgrade 100FX vers 1000SX

[Olivier Benghozi]

Le mode conditioning patch cord s'utilise en émission uniquement, SM vers MM ; 
il sert à décaler le core de la SM vers le bord plutôt qu'au centre là où il 
touche le core de la MM, afin de limiter le nombre de modes, et d'éviter que 
les quelques modes envoyés au centre de la MM par le laser (1310nm) se 
retrouvent complètement décalés à l'arrivée (ce qui n'arrive pas sur les 
distances d'utilisation normales en MM si on utilise classiquement une LED 
(850nm)).

Bien expliqué ici:
https://www.youtube.com/watch?v=t3BX-ExA8T4 



> Le 19 janv. 2018 à 10:12, Michel Hostettler 
>  a écrit :
> 
>> Attention les jarretières de conditionnement de mode se sont pas 
>> symétriques, il y a un coté "équipement" et un coté "fibre".
> 
> Comment se connecte la fibre MMF en réception alors que l'émission s'effectue 
> en SMF ?
> 
> (1) Le connecteur devrait être changé, n'est-ce pas ?
> (2) La photodiode de réception est-elle indépendante du mode, MMF ou SMF ?


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

Re: [FRnOG] [TECH] Problème d'accès a certains site web

[Olivier Benghozi]

Oui les deux sont utiles et se placent sur l'interface multibind.

Dans ce cas le tcp mss replace s'applique aux SYN sortants (vers Internet), 
DONC est efficace sur le trafic TCP entrant (vers le PPP).

Le clear-df n'est appliqué en fait que pour les paquets sortants 
(virtuellement) de l'interface multibind, cad vers les clients PPP (donc les 
problèmes potentiels légitimes soulevés par Vincent ne sont pas susceptibles 
d'être rencontrés). En présence de mss adjust il n'y a plus grosso modo que des 
UDP et GRE à traiter par ce biais en les fragmentant.

> Le 18 janv. 2018 à 14:29, Kevin Thiou  a écrit :
> 
> Merci du retour Olivier, tu sembles avoir une grande expérience des Smartedge.
> 
> Donc au final sur l'interface multibind il faut appliquer les deux paramètres 
> ?
> 
> Et si je comprends bien le tcp mss replace s'applique aux paquets sortant et 
> si gros paquets en entrée le clear-df permettra la fragmentation. j'ai bon ?
> 


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

Re: [FRnOG] [TECH] Problème d'accès a certains site web

[Olivier Benghozi]

Très juste concernant le TCP, mais en réalité il faut faire les deux (sur 
Smartedge), parce qu'il n'y a pas que du TCP (surtout avec les conneries de 
Google à la sauce QUIC, ou l'EDNS avec DNSSEC, etc).
Ce clear-df autorise surtout le routeur à fragmenter vers le client ce qui ne 
passe pas les 1492 plutôt que d'envoyer un ICMP qui sera bouffé par le premier 
filtrage venu (ou tout simplement pas envoyé pour cause de rate-limit des 
paquets à exception).

Pour le "mss adjust sur template PPP", là tu parles de ton experience sur Cisco 
je pense :)
Sur Smartedge c'est sur "interface multibind".

Au fait, quand on fait du L2TP sur Smartedge, le MSS adjust n'est appliqué que 
dans un seul sens, à savoir sur les SYN client-PPP vers Internet, et pas 
l'inverse (en réalité le code est malfichu, le paquet L2TP est vu comme "un 
paquet UDP" et donc ça passe à travers).
Donc il y a intérêt à ce que le CPE du client renvoie bien des ICMP must 
fragment au client, ou qu'il fasse du mss adjust lui-même.
Ou faire aussi du MSS adjust sur les interfaces core du Smartedge.

> Le 18 janv. 2018 à 12:44, David Ponzone  a écrit :
> 
> La solution élégante consiste généralement à mettre un TCP MSS à 1420 sur le 
> template PPP du LNS.



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

Re: [FRnOG] [TECH] Problème d'accès a certains site web

[Olivier Benghozi]

Ça existe depuis la fin des années 90.

> Le 18 janv. 2018 à 09:35, David Ponzone  a écrit :
> 
> Marrant que Redback/Ericsson ait rendu l'accès à un clear DF aussi simple.
> Quelqu'un a déjà essayé de faire la même chose avec une route-map sur un LNS 
> Cisco ?
> 


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

Re: [FRnOG] [TECH] Problème d'accès a certains site web

[Olivier Benghozi]

> Le 18 janv. 2018 à 11:04, Vincent Bernat  a écrit :
> 
> C'est un brin court-terme comme solution. Cela casse toute tentative de
> PMTUD qui fonctionne. Du coup, tout le monde va envoyer des paquets à

Le PMTUD, quand tu as des clients PPP, tu sais que tu ne peux en aucun cas 
compter sur le fait que ça fonctionne sur Internet.
Et ce n'est pas nouveau, c'est comme ça depuis toujours.
La RFC est belle, c'était pas bête comme idée, et même des fois ça marche ; 
mais la réalité c'est qu'il ne faut pas compter dessus.

Donc pour que ça fonctionne il y a MSS Adjust pour le TCP, et clear-DF (et/ou 
ppp mtu adaptive sur Cisco) pour le reste.


> Sans compter que cette solution ne fonctionne pas du tout en IPv6.

Notre ami ayant ici affaire à de vrais clients, je crois que l'IPv6 il s'en 
tape :)
Ceci dit en IPv6, pour tout ce qui n'est pas TCP, on est amené à annoncer une 
MTU pourrie dans les RA.


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

Re: [FRnOG] [TECH] Re: Trafic input délirant sur Equinix-IX PA3

[Olivier Benghozi]

Je pense que ces switches ne font pas d'hébergement :P

> Le 16 janv. 2018 à 02:41, Michel Py  a 
> écrit :
> 
> Equinix étant et IX et Datacenter, tu penses que l'infra de la partie IX est 
> indépendante de celle de la partie Datacenter ?


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

Re: [FRnOG] [TECH] Re: Trafic input délirant sur Equinix-IX PA3

[Olivier Benghozi]

Comme on a une session avec Dropbox, c'est pas un problème de trafic 
asymétrique ni d'aging (le BGP, ça keepalive).
Donc soit c'est buggé, soit quelque chose remplit les tables MAC de ces 
switches.

> Le 15 janv. 2018 à 22:13, David Ponzone  a écrit :
> 
> Intéressant, je ne vois pas du tout de trafic vers Dropbox.
> Pas vers 162.125.67.0/24 en tout cas.
> Mais je suis à PA3.
> Les fuites seraient locales au switch sur lequel on est connecté ?
> Tu sembles ne rien voir vers Nameshield par exemple alors que j'en vois plein.
> 
> Le 15 janv. 2018 à 21:13, GUILLOT Florent a écrit :
> 
>> Quelques exemples de paquets reçus à tord:
>> 
>> La quasi-totalité va chez Dropbox. Et en volume, au nez, ça vient beaucoup 
>> de chez Wifirst. 


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

Re: [FRnOG] [TECH] Re: Trafic input délirant sur Equinix-IX PA3

[Olivier Benghozi]

Là c'est du Force10 en niveau 2, donc 0 complexité.
C'est donné pour 768k MACs max, et a priori l'archi est dédiée.
Donc si ça bave c'est soit mal configuré (aging trop faible), soit buggé, soit 
les deux.

> Le 16 janv. 2018 à 01:17, Michel Py  a 
> écrit :
> 
>> David Ponzone a écrit :
>> Le subnet d'interco, c'est un /23.
>> Y a quoi dans la CAM de leur switch à part max 512 MAC ?
> 
> Il y a toute leur infra, tous les VLANs privés, VPLS, MPLS, VRF, tout quoi.
> Bon je connais pas leur infra, mais ils ont surement plusieurs domaines de 
> VRF, et tout çà ca se mélange doucement les pédales dans leur switch. Dans un 
> gros chassis Nexus, il s'en passe des choses.



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

Re: [FRnOG] [TECH] Re: Trafic input délirant sur Equinix-IX PA3

[Olivier Benghozi]

Quels pingers?
Une session BGP ça keepalive classiquement toutes les 30 à 60 secondes (donc un 
TCP dans les deux sens), et si pas de BGP, pas de traf.
Il est vrai qu'en cas de BGP uniquement avec des RS, et de flux asymétriques, 
tu peux avoir des switches qui ne voient passer du traf que dans un seul sens 
en dehors des ARP.
C'est pour ça qu'il faut configurer le MAC aging à 4h sur un IX, pour 
correspondre à la valeur d'expiration du cache ARP par défaut la plus longue et 
pourtant répandue, cad Cisco (bien que ce soit une valeur débile).

> Le 15 janv. 2018 à 20:56, Raphael Mazelier  a écrit :
> 
> Ce n'est pas le problème habituel de l'unknown unicast sur les IX dont le 
> trafic est fortement asymétrique ? (Equinix-IX paris étant majoritairement un 
> IX de backup).
> 
> Parce que bon des pingers c'est pas très dur à mettre en place...


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

Re: [FRnOG] [TECH] Re: Trafic input délirant sur Equinix-IX PA3

[Olivier Benghozi]

Quand c'est plein, c'est plein, il n'y a rien à réduire mais il y a le matos à 
ferrailler car hors d'âge.

> Le 15 janv. 2018 à 22:48, Michel Py  a 
> écrit :
> 
> Augmenter l'expiration de la CAM çà peut être une arme à double tranchant : 
> l'origine du problème pouvant être que la CAM est trop petite et que le 
> trafic délirant que tu vois est peut-être à cause que l'infra n'arrive pas à 
> créer les nouvelles entrées dans la CAM parce que la CAM est pleine. Si 
> c'était le cas, il faut au contraire réduire le délai d'expiration de la CAM.


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

Re: [FRnOG] [TECH] Re: Perte de tous mes clients BSOD

[Olivier Benghozi]

En effet, plusieurs liens à 0 traf (tous connectés chez eux sur un seul ASR9000 
à TH2 ; d'autres liens branchés sur un autre PE à TH2 fonctionnent).
HS de 11h40 à 12h30.

> Le 12 janv. 2018 à 12:31, Pierrick Tassin  a écrit :
> 
> Livraison de collecte sur TH2.
> Incident depuis 11h40...
> 
> - Mail original -
> De: "BM" 
> À: "Kevin Thiou" , frnog-t...@frnog.org
> Envoyé: Vendredi 12 Janvier 2018 12:25:41
> Objet: Re: [FRnOG] [TECH] Re: Perte de tous mes clients BSOD
> 
> Cela sent l'incident backbone.
> Est-ce que vos livraisons de collecte sont aussi sur Telehouse2
> 
> Le 12/01/2018 à 12:17, Kevin Thiou a écrit :
>> Je viens de perdre SFFibre dédié et CLan aussi
>> 
>> C'est TRolldi
>> 
>> Le 12 janvier 2018 à 12:06, Kevin Thiou  a écrit :
>> 
>>> j'ai perdu tout mes clients BSOD a 11h50, suis-je le seul ?


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

Re: [FRnOG] [TECH] Equipements pour liens MACSEC P2P

[Olivier Benghozi]

Le macsec semble supporté sur EX3400.

> Le 25 août 2017 à 13:17, Raphael Maunier  a écrit :
> 
> Bah tu peux faire un port destination TAP sur un QFX5100 et un EX4600 :)
> 
> J’ai des 5100 dans mon lab, je vais tester en mettant 2*QFX10K en routeur BGP 
> avec un lien 10G ( voir meme 40 ) en transport sur les 2*5100.
> 
> On verra bien ce que ça donne avec plusieurs scénarios de tests
> 
> 
>> On 25 Aug 2017, at 13:09, Nicolas Herreyre  
>> wrote:
>> 
>> Effectivement, la solution de mettre un EX4600 par extrémité (et de ne
>> pas les mutualiser) semble techniquement faisable, même si 2 ports
>> consommés sur 24 c'est un peu du gaspillage.
>> 
>> Line rate 10G pas trop complexe et pas cher.
>> 
>> Celui qui me sort un switch macsec 10G 8 ports avec un form factor de
>> TAP, je suis preneur ;)
>> 
>> 
>> 
>> Le 24 août 2017 à 21:59, Raphael Maunier  a écrit :
>>> Heu ...
>>> 
>>> Pas vraiment, la plupart des sw récent supportent mac-sec en HW.
>>> Tu as plusieurs méthodes pour le configurer avec plus ou moins niveau
>>> d'encryption.
>>> J'avais teste mac-sec sur des liens 1g , je n'avais pas vraiment de pertes
>>> de performance. Tu risques de perdre en Débit Avec l'overhead mais pas au
>>> point de dégrader les performances drastiquement
>>> 
>>> Par curiosite je vais tester Avec un injecteur de traffic afin de voir la
>>> perte en latence et en debit sur des ports 10G
>>> 
>>> https://www.juniper.net/documentation/en_US/junos/topics/concept/macsec.html
>>> 
>>> Envoyé de mon iPhone
>>> 
>>> Le 24 août 2017 à 18:11, Erik LE VACON  a écrit :
>>> 
>>> Bonjour,
>>> Je crains qu'à de tels débits, les problèmes émergent de par le budget
>>> semble t-il contraint.
>>> La latence de traitement CPU-only via un boitier comme indiqué, mais à cout
>>> modique donc potentiellement non équipé de FPGAs/ASICs dédiés, va exploser,
>>> donc les 10gbps utiles ne seront jamais atteints (génération de problèmes et
>>> de comportements équivalents à ceux rencontrés couramment sur les "bigfat
>>> WANs" en intercontinental et difficultés à "remplir le pipe").
>>> 
>>> Plus précisément, et à titre d'exemple, les Thales Mistral couramment
>>> rencontrés, se limitent à 100mbps dans bcp de cas.
>>> En revanche, leur gamme Thales Datacryptor semble monter à 10gbps, mais il
>>> faudrait tester et vérifier si les specs d'interop sont compatibles avec le
>>> besoin précis
>>> Quant au prix, je crains qu'il faille sacrifier au moins 1 bras (mais
>>> peut-être possible de négo vu le besoin et le volume).
>>> 
>>> My two.
>>> 
>>> 
>>> 
>>> On Thu, 24 Aug 2017 17:08:40 +0200
>>> Nicolas Herreyre  wrote:
>>> 
>>> Hello la liste,
>>> 
>>> 
>>> Je vous lis souvent et apprends beaucoup de vos échanges, mais là, je
>>> 
>>> me lance! : j'aurais aimé vos retours d'expériences et conseils avisés
>>> 
>>> sur une infra backbone de liens point à point à securiser.
>>> 
>>> 
>>> En gros, on dispose d'une dizaine de liens 10G ethernet nationaux,
>>> 
>>> type BusinessEthernet ou LAN2LAN entre nos routeurs PE, et on aimerait
>>> 
>>> chiffrer le tout avec MACSEC sans changer nos carte de PE (car ca
>>> 
>>> coûte 2 bras).
>>> 
>>> 
>>> L'idée, c’était de pouvoir insérer un mini équipement/switch, avec 2
>>> 
>>> ports MACSEC ready, entre nos PE et le switch opérateur, pour pas trop
>>> 
>>> cher, sur la 20aine d'extrémités, un truc fiable ;)
>>> 
>>> 
>>> Avez vous des références pile-poil designer pour faire cela ?
>>> 
>>> 
>>> Merci bien!
>>> 
>>> 
>>> --
>>> 
>>> Nicolas.
>>> 
>>> 
>>> 
>>> ---
>>> 
>>> Liste de diffusion du FRnOG
>>> 
>>> http://www.frnog.org/
>>> 
>>> 
>>> 
>>> --
>>> Erik LE VACON 
>>> 
>>> 
>>> ---
>>> Liste de diffusion du FRnOG
>>> http://www.frnog.org/
>> 
>> 
>> ---
>> Liste de diffusion du FRnOG
>> http://www.frnog.org/
> 
> 
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/


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

Re: [FRnOG] [ALERT] Problème SFR ?

[Olivier Benghozi]

Tout à fait, ça semble HS sur plusieurs sites.

> Le 18 août 2017 à 13:53, Emmanuel D.  a écrit :
> 
> Nous rencontrons un problème de connectivité depuis peu avant 13h00 sur 4
> liens SFR partant de Telehouse2 et Interxion 5.
> La couche physique (link up) et ethernet (via CDP) semble OK mais l'IP est
> KO.
> 
> Est-ce que vous constateriez des problèmes similaires de votre côté ?


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

Re: [FRnOG] [TECH] Questions Nexus 3000

[Olivier Benghozi]

T'as pas saisi le point, Michel.

Le point c'est :
Si tu utilises un protocole pour propager les définitions de vlans et 
associations automagiques sur les trunks ; propriétaire ou pas [VTP, GVRP, 
MVRP] ; 
alors quand ça va t'exploser entre les mains pour une raison ou une autre, ce 
sera triste mais inévitable.

Sans rapport avec Cisco ou proprio ou pas.


> Le 8 juil. 2017 à 05:42, Michel Py  a 
> écrit :
> 
>>> Raphael Mazelier a écrit :
>>> 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.
> 
>> Frédéric GANDER a écrit :
>> +
>> c'est une aberration d'activer ca par défaut en dehors du context entreprise
>> voir pme et encore... sur un catalyst c'est la première chose à déactiver
> 
> 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.
> 
> 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.


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

Re: [FRnOG] [MISC] Avis sur l'exchange NL-IX

[Olivier Benghozi]

Depuis un an à Paris, et ça marche bien.

Ils ont fait des choses différentes avec leur route-server: pas de communautés 
BGP mais un clicotron web bien foutu pour décider avec qui on peere ou pas 
(incluant la possibilité de choisir selon les villes où peerent les membres, et 
donc la latence) ; pas mal pour distinguer les sessions des membres selon les 
points de présence.

> Le 9 juin 2017 à 11:47, Youssef Bengelloun-Zahr  a écrit :
> 
> Bonjour Sebastien,
> 
> On les a raccordé sur Amsterdam depuis plusieurs années. Ca juste marche et
> le support est réactif en cas de soucis, ce qui est très rare.
> 
> Ils ont une belle croissance, et ne sont plus juste cantonnés sur la
> Hollande.
> 
> Pas plus d'arguments pour ma part. HTH.
> 
> @+
> 
> 
> 
> Le 9 juin 2017 à 10:55, Sébastien Lesimple 
> a écrit :
> 
>> Bonjour tous!
>> 
>> J'ai eu quelques contacts avec NL-IX ces derniers temps.
>> 
>> Quelqu'un a des retours d'expérience à proposer?
>> Avec quelques arguments, ça aide à se faire une idée :)
>> 
>> Merci!
>> Seb.
>> 
>> 
>> ---
>> 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] [MISC] Question théorique BGP / session iBGP doublées

[Olivier Benghozi]

Je pense que Michel a oublié de mettre ça dans "misc" pour troller, tout 
simplement.

> Le 17 mars 2017 à 18:08, Radu-Adrian Feurdean 
>  a écrit :
> 
> Beurk !


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

Re: [FRnOG] [TECH] Préfixe BGP Orange/FranceIX

[Olivier Benghozi]

Faudrait savoir :P

> Le 11 mars 2017 à 12:50, Stephane Bortzmeyer  a écrit :
> 
> Non. Pour la plupart des noeuds anycast locaux, il existe une route
> par défaut, qui permet d'attraper des cas comme ça.



> Le 11 mars 2017 à 12:42, Stephane Bortzmeyer  a écrit :
> 
> [...] Ne pas avoir de route par défaut évite donc de répondre aux requêtes 
> qui usurpent
> l'adresse IP source d'une machine quelconque de l'Internet.




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

Re: [FRnOG] [TECH] Préfixe BGP Orange/FranceIX

[Olivier Benghozi]

Ça semble un peu naïf comme design à première vue...

> Le 10 mars 2017 à 23:44, Fabien DEDENON <daf.fr...@gmail.com> a écrit :
> 
> C’est bien connu, dns nécessite du routage symétrique ! :)
>> 
>> 
>> Le 10 mars 2017 à 23:39, Olivier Benghozi <olivier.bengh...@wifirst.fr> a 
>> écrit :
>> 
>> Dans leur design on dirait qu'ils n'ont pas jugé utile d'avoir la DFZ (ni 
>> même une route par défaut visiblement) sur chacune de leurs instances 
>> implantées sur les IXs, pour gérer les cas comme celui-ci (en l'occurrence, 
>> du préfixe qui vient chercher un service sur un IX sans y être annoncé, mais 
>> présent dans la DFZ malgré tout via ses transits).


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

Re: [FRnOG] [TECH] Préfixe BGP Orange/FranceIX

[Olivier Benghozi]

C'est clair.

Le service d.root-servers.net est notamment opéré par Packet Clearing House, 
donc il faut aller sur leur looking glass voir s'ils ont la route retour (vers 
193.57.185.30) sur leur instance au Lyonix:

% Network not in table

En fait ils n'ont cette route sur aucune instance (sauf une).
Dans leur design on dirait qu'ils n'ont pas jugé utile d'avoir la DFZ (ni même 
une route par défaut visiblement) sur chacune de leurs instances implantées sur 
les IXs, pour gérer les cas comme celui-ci (en l'occurrence, du préfixe qui 
vient chercher un service sur un IX sans y être annoncé, mais présent dans la 
DFZ malgré tout via ses transits).

En tous cas rien à voir avec Orange, c'est pas leur problème (ni du Lyonix, ni 
du FranceIX...).


Le seul bout de réseau de PCH qui connaisse cette route, c'est visiblement là 
où se trouve leur site web, à savoir à Equinix Palo Alto (donc un bout de 
réseau qui fait autre chose que du DNS):

BGP routing table entry for 193.57.185.0/24
Paths: (1 available, best #1, table Default-IP-Routing-Table)
  2914 5511 3215 201072


Comme PCH gère le D mais aussi le E et le L, ce doit être pareil avec eux (sauf 
si ça va vers une instance ailleurs que sur un IX).


> Le 10 mars 2017 à 16:43, Vincent PAGES  a écrit :
> 
> Ca ressemble à un problème de route retour non ?


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

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

[Olivier Benghozi]

Dans JunOS par défaut seules les routes apprises en BGP sont envoyées à un peer 
eBGP.

> Le 23 déc. 2016 à 10:08, Clement Cavadore  a écrit :
> 
> (ca m'est arrivé il n'y a pas si longtemps que cela avec la mise en
> service d'un Juniper raccordé à FranceIX: Apparamment c'est le
> comportement par défaut chez JunOS, que d'originer en BGP les blocs
> directly connected -> Faut faire attention, il suffit de le savoir). 


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

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

[Olivier Benghozi]

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

> Le 23 déc. 2016 à 19:05, Raphael Mazelier  a écrit :
>> 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.


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

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

[Olivier Benghozi]

Avant je ne dis pas, mais en 2016 les choses semblent à peu près claires.

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 sur la distance administrative de l'eBGP en Cisco (plus basse que la plupart 
des autres protocoles, donc plus prioritaire), la best practice est de la 
remonter au même niveau que l'iBGP (ce qui est le cas par défaut en JunOS 
d'ailleurs).

Sur ces deux points c'est ce que disait déjà Cisco en 2006: 
https://www.ripe.net/participate/meetings/regional-meetings/manama-2006/BGPBCP.pdf
 



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.

Quant au JunOS qui annoncerait des routes direct/connected par défaut en BGP? 
C'est pas la default policy, il reste à voir s'il n'y aurait pas une policy 
foireuse dans l'affaire, plutôt :)


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 23 déc. 2016 à 11:15, David Ponzone  a écrit :
> 
> Ouais mais bon, ça veut dire que les mecs mettent des filtres qu’au niveau de 
> la redistribution IGP-EGP, et pas au niveau du peer EBGP.
> Si tu commences par mettre tes filtres outbound EBGP en place, c’est pas 
> grave si ton constructeur trouve rigolo de redistribuer RIP2 vers BGP par 
> défaut :)
> 
>> Le 23 déc. 2016 à 11:08, Radu-Adrian Feurdean 
>>  a écrit :
>> 
>> On Thu, Dec 22, 2016, at 17:26, David Ponzone wrote:
>>> Hmmm les valeurs par défaut de Cisco, tout un roman.
>> 
>> De memoire sur Brocade c'etait pareil il y a quelques annees (quand
>> c'etait MFN/Abovenet qui avait annonce le reseau d'Equinix-IX) .
>> Probablement chez d'autres aussi.


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

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

[Olivier Benghozi]

Stéphane, on t'cause !

> Le 22 déc. 2016 à 11:23, Clement Cavadore  a écrit :
> 
> 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.
> 
> Clément Cavadore
> 
> On Thu, 2016-12-22 at 10:06 +, Aurélien Poret wrote:
>> Salut,
>> 
>> Je remonte le sujet. Parce que j'ai ouvert le ticket a Equinix et ils ne 
>> semblent pas au courant.
>> Avez-vous ouvert des tickets pour les soucis sur Equinix-IX ?
>> 
>> Le moderator ne laisse pas passe les mails sur la ML du coup c'est un peu 
>> l'obscurité totale...
>> 
>> Vous avez remonté vos sessions?
>> 
>> 
>> Cordialement,
>> 
>> Aurélien Poret |  Datacenter And Network Manager
>> Ikoula - 34 rue du Pont ASSY - 51100 REIMS - France
>> Tel : +33 3 51 00 92 51 | Mobile : +33 6 10 61 00 37 |  www.ikoula.com
>> 
>> Ikoula, c'est deux divisions
>> Express Hosting : Des solutions d'hébergements packagées et flexibles allant 
>> du nom de domaine aux serveurs dédiés physiques ou virtuels disponibles en 
>> 15 min.
>> Enterprise Services : Spécialiste de l'infogérance, du cloud computing et 
>> des plateformes collaboratives, Ikoula assure en 24/7 sur site, la haute 
>> disponibilité de vos applications et garantit votre tranquillité.
>> 
>> -Message d'origine-
>> De : frnog-requ...@frnog.org [mailto:frnog-requ...@frnog.org] De la part de 
>> Emmanuel Lacour
>> Envoyé : mercredi 21 décembre 2016 18:54
>> À : frnog@frnog.org
>> Objet : Re: [FRnOG] [TECH] Pb pour joindre différents sites Web
>> 
>> Le 21/12/2016 à 18:49, Jean-Francois Maeyhieux a écrit :
>>> Bonsoir,
>>> 
>>>   même probleme pour nous pour 2 gros clients:
>>> - même CDN
>>> - même hébergement sur Equinix PA3
>>> - début de l'incident: 16h30
>>> - fin de l'incident: 18h30
>> 
>> 
>> idem sur toute la ligne.
>> 
>> 
>> ---
>> Liste de diffusion du FRnOG
>> http://www.frnog.org/
>> 
>> 
>> ---
>> Liste de diffusion du FRnOG
>> http://www.frnog.org/
> 
> 
> 
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/


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

Re: [FRnOG] [TECH] Amplificateur optique 1270 nm

[Olivier Benghozi]

PDFA ou SOA.

En SOA par exemple :
https://lmgtfy.com/?q=soa+1260+optical 


Ou en PDFA:
https://lmgtfy.com/?q=pdfa+1260+optical+amplifier 





> Le 20 déc. 2016 à 13:41, Michel Hostettler 
>  a écrit :
> 
> Bonjour,
> 
> Dans un montage théorique, j'ai eu besoin d'utiliser un amplificateur optique 
> en ligne 1270 nm, 2,5 Gbit/s, de gain 10 dB.
> 
> Est-ce que cela existe ? Ou est-ce impossible ?
> 
> J'écris bien amplificateur optique, et non un dispositif Optique Electrique 
> Optique.
> 
> Merci pour vos avis éclairés,


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

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

[Olivier Benghozi]

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.

> Le 11 nov. 2016 à 17:35, Raphael Mazelier  a écrit :
> 
> 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).


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

Re: [FRnOG] [MISC] Rapport ARCEP sur problème IPv6

[Olivier Benghozi]

L'adressage interne de la boite que personne n'a envie de changer selon 
l'adressage des liens externes, c'est un problème clairement généralisé.
Du coup on va immanquablement voir du NPTv6 lorsque l'IPv6 se retrouvera en 
entreprise.

> Le 3 oct. 2016 à 13:21, Pierre Colombier  a écrit :
> 
> Le problème avec IPV6, c'est surtout les mauvaises habitudes prises avec le 
> nat depuis 15 ans.
> 
> Le réseau d'entreprise "tout ouvert derrière une box qui fait nat" en IPv6, 
> c'est le carnage...
> 
> Et il y en a combien des comme ça ?


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

Re: [FRnOG] [ALERT] Incident SFR

[Olivier Benghozi]

Même en 3BXL ça fait longtemps qu'on est au delà des 512k routes IPv4 hors VRF 
du dimensionnement par défaut de la TCAM.

> Le 15 sept. 2016 à 14:25, Radu-Adrian Feurdean 
>  a écrit :
> 
> On Thu, Sep 15, 2016, at 11:27, Jérôme Nicolle wrote:
>> Oui enfin la root-cause c'est surtout qu'ils tournent encore de vielles
>> broles à 100W/10Gbps, et avec un CPU trop court pour faire tourner des
>> route-filter stricts sur toutes les sessions, tu crois pas ?
> 
> Mois ca me fait penser a du SUP720(-3B) + manque (ou inadequation) de
> max-prefix.


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

Re: [FRnOG] [TECH] SFP encoding

[Olivier Benghozi]

SolidOptics:
http://solid-optics.com/tools/multi-fiber-tool/so-multi-fiber-tool-id1768.html 


Flexoptix et leur Gearbox:
https://www.flexoptix.net/en/produkte/transceiver-accessories/flexbox-v3-transceiver-programmer.html
 

(ou un de leurs distributeurs PacketGear:
https://shop.packetgear.com/produkte/transceiver-accessories/gear-box-transceiver-programmer-v3.html
 

 )


Pas sûr que ces boites veuillent bien reprogrammer une optique qui n'est pas de 
chez eux cependant.



> Le 31 août 2016 à 13:22, Pierre Colombier  a écrit :
> 
> Bonjour,
> 
> J'ai encore un équipement qui reffuse d'employer un SFP sous prétexte qu'il 
> n'est pas de la bonne marque.
> 
> C'est franchement pénible et j'aurais tendence à bannir le produit (voir le 
> constructeur) mais en attendant je suis quand même ennuyé.
> 
> Vu le nombre de types de SFP et de marques, je ne vais quand même pas en 
> stocker un de chaque... :(
> 
> Je voulais savoir si il est possible de les reprogrammer simplement sans 
> avoir un hardware très spécifique
> 
> (par exemple avec une carte réseau sfp et le logiciel qui va bien).
> 
> 


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

Re: [FRnOG] [TECH] Bientôt le week-end, un débat sur l'adressage des routeurs

[Olivier Benghozi]

Très juste: outre le support incertain coté hard/soft, c'est la merde à 
débugger.

Avec "C'est mal" on est plus dans le dogmatisme que dans le pragmatique.
Alors que "ça juste marche à coup sûr dans des réseaux de toute taille à 
travers le monde quoi que Stéphane Bortzmeyer en dise après lecture des RFC 
dans le marc de café", ça c'est pragmatique :)


> Le 23 juil. 2016 à 09:56, Vincent Bernat  a écrit :
> 
> Le 22 juillet 2016 11:55 CEST, Stephane Bortzmeyer  :
> 
>>> Cela ne permet pas seulement d'économiser des IP publiques, cela
>>> simplifie grandement la configuration.
>> 
>> Oui, mais ma question ne portait pas sur le fait d'utiliser des
>> interfaces non numérotées (c'est déjà décidé) mais sur le fait de
>> n'avoir qu'une seule adresse IP publique pour tous les routeurs.
> 
> Yep, c'était uniquement une remarque annexe.
> 
> Sur le sujet, entre avoir 5 IP privées dans le traceroute et 5 fois la
> même IP, je préfère avoir 5 IP privées. Si ce n'est pas ton AS, tu peux
> toujours savoir à qui sont ces 5 IP en regardant la première IP publique
> (doit pas avoir grand monde qui fait des intercos entre AS en adressage
> privé). Si c'est ton AS, tu as les reverses pour savoir qui est
> qui. Alors que si tu as une "fabrique IP" avec 100 routeurs qui se
> partagent l'IP et de l'ECMP en pagaille, ça va être coton de
> diagnostiquer.



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

Re: [FRnOG] [TECH] ifupdown et DHCPv6

[Olivier Benghozi]

Il est impossible de configurer SIMPLEMENT quoi que ce soit sous debian.

(j'ai le droit, c'est vendredi)

> Le 22 avr. 2016 à 13:37, Pierre Colombier  a écrit :
> 
> je voudrais savoir si il existe une façon de configurer SIMPLEMENT un client 
> DHCPv6 avec ifupdown sous debian dans /etc/network/interface/


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

Re: [FRnOG] [MISC] wikipedia

[Olivier Benghozi]

Pas forcément du zèle, d'ailleurs.

Il ne faut pas attribuer à la malveillance ce qui peut s'expliquer par 
l'incompétence.


> Le 10 mars 2016 à 20:27, Vincent Bernat  a écrit :
> 
> En réponse à "Supprimer la page FRnOG serait une preuve d'une grande
> méconnaissance du fonctionnement de l'internet par les administrateurs
> de wikipedia".
> 
> Il n'y a aucun zèle propre au Wikipedia francophone. La règle des
> sources existe également sur le Wikipedia anglophone:
> 
> https://en.wikipedia.org/wiki/Wikipedia:Verifiability#Reliable_sources
> 
> ❦ 10 mars 2016 18:54 +0100, hugues VOITURIER  :
> 
>> Y'a vraiment des mecs qui se prennent pas pour de la merde… 
>> 
>> "Être cité ne suffit pas aux critères de Wikipédia ; il est demandé
>> des sources centrées, ou au moins substantielles sur le sujet ; ne pas
>> comprendre ça, c’est faire preuve d’une grande méconnaissance du
>> fonctionnement de Wikipédia par les acteurs du fonctionnement de
>> l’internet, et c’est vraiment dommage."


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

Re: [FRnOG] [MISC] wikipedia

[Olivier Benghozi]

Très juste.
Et concernant ce quarteron de chefaillons enragés, preuve est faite que placer 
un autocollant avec de la dorure sur un tréteau n'en fait pas un cheval de 
course.

> Le 10 mars 2016 à 15:16, Jérémie Bouillon  a écrit :
> Merci de ne pas confondre contributeur et AdjudantChaifJeSuisLePlusBô. Ce 
> n'est vraiment pas gentil pour les milliers de contributeurs.
> 
> Le 10/03/2016 14:37, Vincent Bernat a écrit :
>> Insulter copieusement les contributeurs bénévoles de Wikipedia ne va
>> pas aider des masses.


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

Re: [FRnOG] [MISC] wikipedia

[Olivier Benghozi]

aH bah, je constate que Docteur Tocard est arrivé à ses fins, car son bouffon 
de collègue Professeur Lavermine a finalement supprimé l'article ce matin (en 
tripatouillant leurs propres règles tordues et avec une bonne dose de mauvaise 
fois pitoyable).
Wikipedia France semble en effet être atteint d'une grave maladie parasitaire: 
infestation de désœuvrés ergoteurs pontifiants, admins ou pseudo-justiciers.


> Le 8 mars 2016 à 12:29, Manu <m...@formidable-inc.net> a écrit :
> J'ai pas osé.. mais s'il y a bien un souci parfois avec Wikipedia, ce sont 
> ces admin :-) Il faut juste faire en sorte que l'article soit un peu propre 
> avec quelques références. Et trouver un utilisateur avec plus de 50 modif qui 
> donne son avis.
> 
> Le 08/03/2016 12:09, Olivier Benghozi a écrit :
>> Il arrive en effet que sur Wikipedia certains cancrelats glaireux
>> psychorigides, pédants et donneurs de leçons, tout auréolés de leur
>> prétendue distinction de "mainteneur", prodigues en critiques mais stériles
>> en constructivité, viennent démontrer leur médiocrité en se comportant tels
>> un guichetier qui ferait la grève du zèle.


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

Re: [FRnOG] [ALERT] leak du préfixe de France-IX Marseille

[Olivier Benghozi]

Avec un /24 à un bout du /21 et un /23 à l'autre bout, c'est sûr que ça ne 
facilite pas l'annonce d'un simple /22 sur Internet pour ce qui ne relève pas 
des LANs de peering.
Une best practice, c'est de ne pas annoncer les ranges de LANs de peering d'une 
part, et de les filtrer en entrée d'autre part.
Après, dans le cas d'espèce, les choix d'IPs de l'IX n'aident pas :)
(  stafaute  )

> Le 9 mars 2016 à 12:08, Arnaud Fenioux  a écrit :
> 
> Salut Jérome,
> 
> Ce n'est pas un leak, je te rappelle que les pfx de FranceIX (l'IXP) sont :
> 37.49.232.0/24 et 37.49.236.0/23
> Comme indiqué la :https://www.peeringdb.com/private/exchange_view.php?id=359
> et  sur https://www.peeringdb.com/private/exchange_view.php?id=880
> 
> Le /21 c est le super-net avec nos PFX d'infra et de LAN. La question
> devrait etre "est-ce une best practice d'annoncer que les IXP annonces
> leurs LAN" ?
> 
> C est a discu-troller, mais en tout cas on est pas les seuls a faire comme 
> ca...
> 
> Arnaud
> 
> 2016-03-09 11:57 GMT+01:00 Jérôme Nicolle :
>> Bonjour,
>> 
>> Dites donc, je vois deux AS qui leakent 37.49.232.0/21 (France-IX
>> Marseille) là.
>> 
>> Les #NetOps de AS29075 (IELO) et AS197133 (Mediactive) sont priés de
>> corriger leurs filtres. On annonce _*PAS*_ un préfixe de LAN d'IX SVP.
>> 
>> Merci.
>> 
>> --
>> Jérôme Nicolle
>> 06 19 31 27 14
>> 
>> 
>> ---
>> 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] [MISC] wikipedia

[Olivier Benghozi]

Il arrive en effet que sur Wikipedia certains cancrelats glaireux
psychorigides, pédants et donneurs de leçons, tout auréolés de leur
prétendue distinction de "mainteneur", prodigues en critiques mais stériles
en constructivité, viennent démontrer leur médiocrité en se comportant tels
un guichetier qui ferait la grève du zèle.

Bref, pour résumer on a Docteur Tocard qui vient foutre sa merde parce
qu'il s'ennuie pendant les vacances scolaires.

Comme dans les arts martiaux il faut utiliser la force de l'adversaire
contre lui-même, donc il faudrait que tu ailles (aussi) écrire afin que ça
rentre dans les bonnes cases du règlement de Docteur Tocard :P


Le 8 mars 2016 à 09:19, Philippe Bourcier  a écrit :

>
> Bonjour,
>
> Si des personnes avec un peu de talent d'écriture veulent bien s’atteler à
> la tâche, il semblerait que l'article wikipedia sur FRnOG soit sur le point
> de disparaître (bon, il n'est pas super bien écrit), ce qui serait bien
> dommage, je trouve :
> https://fr.wikipedia.org/wiki/FRnOG
>
> Je pense qu'il manque des références au France-IX et à la participation à
> la poussée des IX en France (via les IX updates lors des réunions)... mais
> bon j'estime que je ne suis pas le mieux placé pour écrire l'article (et
> surtout je suis pas un écrivain né, autant utiliser les talents de gens
> meilleurs que moi :)).
>
> Bonne prose :)
>
>
> Cordialement,
> --
> Philippe Bourcier
> web : http://sysctl.org/
> blog : https://www.linkedin.com/today/author/2298865
>
>
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/
>

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

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

[Olivier Benghozi]

> Le 28 févr. 2016 à 11:06, Stephane Bortzmeyer  a écrit :
> On Sun, Feb 28, 2016 at 12:13:56AM +0100, 
> christophe.casale...@digital-network.net 
>  wrote 
> 
>>> Ah, je faisais partie du groupe de travail IPng à l'époque
>> 
>> Je sais. Et j'espère que tu t'autoflagelles tous les jours pour ce crime.
> 
> Il est moins grave que le fait de massacrer l'Unicode des autres lors
> des résponses. Il faut dire que c'est cohérent : si on ne sait pas
> faire d'IPv6, il n'y a pas de raison qu'on connaisse UTF-8, non plus.

C'était donc ça, c'est clair à présent. Tu as délibérément introduit du troll 
dans ces specs sans doutes déjà merdiques à la base. Je ne te félicite pas.
Un groupe multicast par host? De l'ICMP pour remplacer ARP? Du Hob-by-Hop? Le 
DNS oublié dans le RA? Un next-header de type fragment? La temporary address? 
L'IPv6 mobility? T'as dû bien te marrer, c'est forcé :P


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

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

[Olivier Benghozi]

Ça a surtout du sens avec des Route Reflectors, je pense. Voire pour 
loadbalancer entre des PE dans un réseau.

Dans le cas d'espèce les routes externes ne sortiront de la VRF vers l'i-MP-BGP 
que si elles sont best, RD différent ou pas...

> Le 19 janv. 2016 à 19:54, Radu-Adrian Feurdean 
>  a écrit :
> 
> - Internet dans un VRF, avec un RD different pour les deux routeurs.
> SUP720 s'abstenir.


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

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

[Olivier Benghozi]

Je pense qu'une default static sur un transit, ce n'est pas forcément un bon 
plan. Tu ne sais jamais trop si tu es branché sur un port de routeur en direct 
ou via un switch intermédiaire (auquel cas le port ne tombe pas même s'il n'y a 
plus personne de l'autre coté), ou même simplement si le routeur d'en face a 
encore toute sa tête (son control place, quoi :) ).
Un plan à blackhole, je trouve :P

Se faire annoncer une default me semble plus pertinent.

> Le 19 janv. 2016 à 14:25, Pierre-Yves Maunier  a 
> écrit :
> 
> La solution la plus propre serait d'avoir au moins 2 transitaires sur
> chaque routeur pour éviter ce désagrément. (genre les 2 meme transitaires a
> chaque fois sur les 2 si tu ne veux pas les multiplier).
> 
> Sinon route par défaut. Eventuellement statique vers le transitaire local
> et annoncée en iBGP a son copain d'à côté.
> Comme ca chaque routeur aurait dans sa table de routage :
> 
> 
> 0.0.0.0/0 -> static/5 next-hop transitaire localement raccordé
>bgp/170 next-hop mon pote iBGP qui enverra vers son
> transit localement raccordé
> 
> quand tu coupes le BGP, ca utilisera la default statique.
> Si tu coupes l'interfaces, la statique tombe et ca utilisera celle apprise
> en iBGP.
> 
> Le 19 janvier 2016 à 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,
>> --
>> Aurélien
>> 
>> 
>> ---
>> 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] Redistribution de routes iBGP

[Olivier Benghozi]

C'est bien comme ça que ça marche. Les routes iBGP best font que la route eBGP 
correspondante (si elle existe) ne sera pas annoncée vers le peer iBGP (et ne 
sera pas celle poussée en FIB).

L'objectif serait de s'assurer que les deux routeurs ont toutes les routes des 
deux transits...
Dans ce cas, pour annoncer à coup sûr la best external aux peers (même si ce 
n'est pas la best "overall" du routeur) - et ainsi faire comme ce que la RFC 
prévoyait au départ (mais que personne ne fait par défaut parce que ça 
multiplie le nombre de routes échangées), il faut utiliser une commande pour 
modifier ces annonces coté iBGP:
- bgp advertise-best-external chez Cisco en IOS, advertise best-external en 
IOS-XR
- advertise-external + advertise-inactive chez Juniper
- advertise-external chez ALU

De cette façon les deux routeurs ont tous les deux toutes les routes des deux 
transits en RIB, en permanence (en RIB ou dans la table BGP qui va bien, 
d'ailleurs).

Quoi qu'il en soit, s'ils ont un CPU de tortue rhumatisante, best external ou 
bonne vieille default annoncée par chaque transit, ça sera quand même lent :)
En effet, on a beau advertiser la best external ou avoir une default external, 
si la best est en iBGP alors il faut bien attendre que le routeur d'à coté qui 
aurait perdu son transit envoie un withdraw pour invalider sa route, et qu'on 
puisse utiliser l'external coté FIB.
Par contre le routeur qui a perdu son transit aura déjà toutes les routes de 
son pote (ou une default) sans attendre que l'autre se décide à lui annoncer 
les routes manquantes, à la suite de son propre withdraw.

Mais comme au final, plus un routeur (moisi ou pas d'ailleurs) connait de 
routes et plus il est lent à converger, la default aurait tendance à être plus 
pertinente dans des conditions de CPU perrave...


Conclusion: si pas besoin d'avoir toutes les routes, fais-toi annoncer fullview 
+ default, et filtre à /22 voire /20 et plus large (ou bien filtre sur les 
communities placées par tes transits selon ce que tu veux, pourquoi pas); voire 
default seulement si pas de contre-indication pour ton usage.
Vu que les solutions miraculeuses, y en a pas trop.


> Le 19 janv. 2016 à 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.
> 
>> Le 19 janv. 2016 à 12:42, Raphael Mazelier  a écrit :
>> 
>> 
>> 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,
>>> 
>> 
>> 
>> 

Re: [FRnOG] [BIZ] Boitier CWDM

[Olivier Benghozi]

En CWDM, on a eu plusieurs AFOP sans problème (via Infractive) en 8 canaux.
En DWDM on a maintenant plusieurs Cube Optics (qui appartient maintenant à 
Huber+Suhner) en 16 canaux, pas de pb non-plus.

> Le 5 nov. 2015 à 23:27, Jeremy  a écrit :
> 
> Bonjour les barbus,
> 
> Petite question, qu'est que vous utilisez fréquemment comme boitier CWDM 
> passif avec un bon rapport qualité prix ?
> On cherche à mettre 8 waves pour nos besoins propres, mais même si je connais 
> la techno cwdm, je n'ai jamais pu tester plusieurs marques.
> 
> Merci pour vos retours,
> Jérémy


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

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

[Olivier Benghozi]

Non il ne fait pas de RPF, étant entendu qu'on parle de réseau sur le trajet 
qui fait passer du vrai trafic, et non pas de beigebox sous minux hébergée sous 
la table de la cuisine :P
Ou disons, d'infrastructure très spécifique.

Et en effet les sources privées sont naturellement filtrées à l'entrée.

Ceci étant dit je pense qu'en l'occurrence le client de Cédric se moquait de 
toutes façons des traceroutes dans l'immédiat, ayant un service à faire tourner.


> Le 17 sept. 2015 à 14:55, Stephane Bortzmeyer  a écrit :
> Cédric Tabary  wrote 
> 
>> D'autre part ca génère des paquets ICMP (au traceroute par exemple)
>> en IP source RFC1918 qui passent par Internet donc potentiellement
>> filtrés
> 
> Euh, si le réseau sur le trajet fait du RPF, le bloc d'interco
> non-1918 mais non annoncé sera autant filtré que des adresses RFC
> 1918, non ?


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

[FRnOG] [JOBS] WIFIRST recherche un Ingénieur Réseau

[Olivier Benghozi]

Hello,

je recherche un ingé réseau, donc profil réseaux / télécoms, plutôt de junior à 
confirmé mais nous sommes ouverts.
L'offre qu'on a publiée est ici: 
http://www.wifirst.fr/sites/wifirst/files/pdf/recrutement/wifirst_ii_janv15.pdf 


Contact RH pour ce poste: sebastien.bron...@wifirst.fr 



Ci-dessous un résumé.

Responsabilités:
- Intervenir sur les infrastructures backbone IP supportant nos services, en 
participant à la réalisation des évolutions techniques & fonctionnelles et à 
l'intégration et l'exploitation des infrastructures
- Etre en charge de la refonte des architectures et ingénieries des LAN de nos 
différents sites clients
- Participer à nos projets de mise en place et déploiement de fibre optique 
pour raccorder en propre un certain nombre de nos sites clients

Environnement et compétences:
- Toutes les architectures techniques réseau mises en œuvre par WIFIRST sont 
conçues et intégrées en interne. L'infrastructure backbone (totalement 
redondée, répartie sur plusieurs datacenters) est conçue, mise en place et 
opérée par nos équipes.
- L'Ingénieur Infra Réseau occupe une place centrale et stratégique au sein de 
la Direction Technique.
- Univers technologique (et compétences appréciées) : commutation (datacenter, 
campus), routage (L2TP, MPLS, Juniper, Ericsson, ...), firewall (Fortinet...)
- Création de poste
- Positionnement "cœur de réseau" au sein de la Direction Technique

Contrat en CDI à Paris 8e, début de mission dès que possible.
Rémunération : package selon profil


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

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

[Olivier Benghozi]

Zayo France? Jaguar? Telia? NTT?

> Le 14 sept. 2015 à 20:18, David Ponzone  a écrit :
> 
> Je comprends que ça fasse du boulot à IELO, mais c’est pas la fin du monde, 
> et ça doit leur faire mal aussi, c’est un intérêt mutuel.
> Beaucoup de routeurs ? Euh, même à un routeur par transitaire et un routeur 
> par IX, ça en fait pas 40 je pense.
> 
> Cogent a pas une offre anti-DDoS ?
> 
> Sinon, c’est peut-être le moment de chercher des transitaires peut-être un 
> peu plus chers, mais qui te laissent pas te demmerder (si ça existe).
> 
> 
> Le 14 sept. 2015 à 20:00, Jeremy  a écrit :
> 
>> Salut,
>> 
>> Oui, on a essayé, le mec change la destination de son attaque au bout de 5 
>> minutes après changement d'IP.
>> Chez IELO, ils peuvent difficilement filtrer leur bloc d'interco, c'est 
>> souvent galère à faire car beaucoup de routeurs.
>> Chez Cogent, ils peuvent rien faire a priori, c'est hors process d'après le 
>> support.
>> 
>> Bref, belle galère.
>> Jérémy
>> 
>> Le 14/09/2015 19:51, David Ponzone a écrit :
>>> Tu peux éclaircir un détail.
>>> Tu dis que les attaques arrivent vers les IP d’interco.
>>> Si oui, si tu renumérotes une des interco, tu dois être tranquille pendant 
>>> quelques minutes/heures.
>>> (les IP d’interco sont dans les blocs de vos transitaires j’imagine ?)
>>> Tu as essayé, c’est effectivement le cas ?
>>> 
>>> Tu peux toujours demander à tes upstream de filtrer le plus en amont 
>>> possible les paquets vers les IP d’interco. Ce n’est pas, à priori, 
>>> dramatique si les IP d’interco sont filtrées.
>>> 
>>> Après, sans assistance de tes transitaires, je vois mal comment tu vas t’en 
>>> sortir.
>>> Parmi ceux-ci, j’en connais au moins un, Magic On Line, qui a les 
>>> compétences nécessaires en interne pour t’aider.
>>> 
>>> Le 14 sept. 2015 à 19:01, Jeremy  a écrit :
>>> 
 Salut les barbus,
 
 Depuis quelques jours, on essuie des attaque vers les 40-50 Gb/s contre 
 les IP d'interco BGP qu'on a avec nos transitaires.
 Ces derniers ayant leurs propres limites, bah on est un peu dans le noir 
 là...
 
 Est ce que quelqu'un a une solution magique ? et/ou un transitaire qui est 
 capable d'annoncer notre réseau sans se faire bombarder ses prefix de 
 routage (et présent sur franceIX) ?
 
 Merci.
 Jérémy


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

Re: [FRnOG] [BIZ] Opérateur pour résidence étudiante

[Olivier Benghozi]

Wifirst.

http://www.wifirst.fr/ http://www.wifirst.fr/


 Le 6 févr. 2015 à 15:33, Louis luigi.1...@gmail.com a écrit :
 
 Bonjour,
 
 je recherche un opérateur qui pourrait fournir un service Triple-Play
 (offre clef en main) dans des résidences étudiantes en région parisienne.
 Avez-vous des idées d'opérateur que l'on pourrait solliciter?
 
 Le câblage actuel desservant chaque chambre depuis les locaux techniques
 est le suivant :
 - câblage cuivre RJ45 cat 5 ou 6 selon bâtiment
 - câblage cuivre RJ11 interne (pas de raccordement à l'extérieur sur le
 réseau FT)
 - câblage coaxial prise TV relié à l'antenne collective
 
 Les pré-requis sont les suivants :
 - internet avec bande passante garantie par chambre
 - l'opérateur doit pouvoir gérer des abonnements d'une durée minimum de 3
 mois
 - disponibilité du service immédiate dès la souscription de l'étudiant via
 un portail
 - service client français / anglais 24/7 avec intervention sur site rapide
 en cas de panne
 - service wifi avec authentification utilisateur
 - support des équipements ne supportant pas les portails captifs : exemple
 console de jeu
 - offre TV enrichie par rapport à la TNT en option
 - téléphonie illimitée vers fixes à l'international en option avec
 fourniture du combiné
 - Population mineure à gérer avec filtrage de contenu
 - Service sur site d'impression et copieur à péage (en réseau) / scanner
 vers mail
 - fourniture, gestion et installation de l'infrastructure nécessaire au
 service (baies, switches, bornes wi-fi, copieur...)
 - Connectivité fibre inter-résidence non existante
 - Suivi du Capacity Planning / SLA des accès internet
 
 Merci d'avance de votre contribution
 
 ---
 Liste de diffusion du FRnOG
 http://www.frnog.org/


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

Re: [FRnOG] [TECH] Cisco commande block multicast/unicast phénomène étrange

[Olivier Benghozi]

Pourquoi pas normal?
J'imagine qu'il y a du spanning-tree (par défaut, bonne idée d'ailleurs), donc 
il faut RTFM:
http://www.cisco.com/c/en/us/support/docs/lan-switching/spanning-tree-protocol/12013-17.html#portfastcommand
 
http://www.cisco.com/c/en/us/support/docs/lan-switching/spanning-tree-protocol/12013-17.html#portfastcommand

1) un nouveau port (non-edge) est up dans le vlan, un TCN est généré, les MAC 
sont expirées.
2) en principe il y a donc pendant quelques secondes de l'unknown unicast en 
masse, c'est rapidement réappris, et c'est réglé.
Sauf qu'ont été configurés moults filtrages peu pertinents, du coup cet unknown 
unicast est filtré et donc le réapprentissage se passe mal (comme expliqué par 
David).

Conclusion la conf est mauvaise et par conséquent:
- sur les ports access vers des hosts, il faut configurer un spanning-tree 
portfast. J'imagine que ce ne doit pas être le cas.
- quand on filtre unknown-unicast, on a des ennuis. switchport block est à 
virer.
- storm-control ET switchport block ? Le storm-control est la bonne démarche, 
pas le block.



 Le 30 déc. 2014 à 00:52, David Ponzone david.ponz...@gmail.com a écrit :
 
 Ben à y regarder de plus près, le block unicast pourrait être responsable de 
 ton problème en fait.
 
 Par défaut, les unknown unicast sont forwardés sur tous les ports d’un 
 Catalyst, ce qui permet de trouver rapidement les hôtes « silencieux » dont 
 l’adresse MAC n’est plus dans la table des adresses MAC (car expirée).
 Avec le block, les unknown unicast sont filtrés.
 Donc pour que le paquet soit forwardé, il faudra attendre que l’adresse MAC 
 de l’hôte destination soit de nouveau présente dans la table MAC.
 Cela ne pourra arriver que quand l’hôte destination aura essayer d’envoyer un 
 paquet unicast (pas unknown) ou broadcast.
 En fonction de ce que font tes machines, il se peut que tu aies à attendre 2 
 ou 3 secondes avant qu’un tel paquet soit émis.
 
 Dans ton cas précis, pourquoi cela arrive quand tu modifies la conf d’un port 
 ?
 Cela semblerait signifier que quand tu changes la conf d’un port, le switch 
 fait un clear mac address-table.
 A priori, pas normal.
 Tu peux facilement vérifier en faisant un show mac address-table juste avant 
 de modifier un port et juste après.
 
 En espérant que ça te donne des pistes.
 
 Le 29 déc. 2014 à 21:00, Antoine Durant antoine.duran...@yahoo.fr a écrit :
 
 Je connais pas CCO, je vais regarder...
 
 Et d'après toi il faut utiliser ou pas le block multi/uni cast sur les 
 uplinks ?
 
 De : David Ponzone david.ponz...@gmail.com
 À : Antoine Durant antoine.duran...@yahoo.fr 
 Cc : frnog-t...@frnog.org frnog-t...@frnog.org 
 Envoyé le : Lundi 29 décembre 2014 20h25
 Objet : Re: [FRnOG] [TECH] Cisco commande block multicast/unicast phénomène 
 étrange
 
 Faut plutôt utiliser les outils CCO en fait.
 
 
 
 Le 29 déc. 2014 à 20:21, Antoine Durant antoine.duran...@yahoo.fr a écrit :
 
 Non je trouve rien sur google...
 
 Oupss ! switch 2960 avec IOS 15 (les deux avec le même IOS)
 
 Cisco IOS Software, C2960 Software (C2960-LANBASEK9-M), Version 15.0(2)SE5, 
 RELEASE SOFTWARE (fc1)
 
 De : David Ponzone david.ponz...@gmail.com
 À : Antoine Durant antoine.duran...@yahoo.fr 
 Cc : frnog-t...@frnog.org frnog-t...@frnog.org 
 Envoyé le : Lundi 29 décembre 2014 20h15
 Objet : Re: [FRnOG] [TECH] Cisco commande block multicast/unicast phénomène 
 étrange
 
 Quels switchs ?
 Quel IOS/CatOS ?
 T’as vérifié sur le site de Cisco s’il y avait un bug connu ?
 
 Le 29 déc. 2014 à 20:06, Antoine Durant antoine.duran...@yahoo.fr a écrit 
 :
 
 Bonjour,
 
 J'utilise la conf ci-dessous sur deux switch Cisco. J'ai un phénomène 
 étrange qui se produit !!!
 
 ip dhcp snooping vlan 10-12
 no ip dhcp snooping information option
 ip dhcp snooping
 !
 interface GigabitEthernet0/1
 switchport trunk allowed vlan 10,11,12
 switchport mode trunk
 switchport nonegotiate
 switchport block multicast
 switchport block unicast
 ip arp inspection trust
 storm-control broadcast level 80.00
 storm-control multicast level 80.00
 ip dhcp snooping trust
 !
 
 Lorsque je configure un port sur le switch N°1 le ping ne passe plus 
 (pendant quelque seconde) sur les machines du second switch. En gros les 
 machines sur le second switch ne sont plus joignable pendant quelque 
 seconde !
 
 Même phénomène si je configure un port sur le switch N°2, les machines du 
 switch N°1 tombent...
 
 Le problème survient lorsque j'active les commandes suivantes sur les 
 uplink :
 
 switchport block multicast
 switchport block unicast
 
 Sans, je n'ai pas de problème tout fonctionne... J'ai l'intention de 
 désactiver cela de mes uplinks mais en revanche de le laisser sur les 
 ports ou il y a pas de trunk (machines).
 
 Est-ce un comportement normal ??


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

Re: [FRnOG] [TECH] Brancher le laptop en datacenter : USB3 to SFP

[Olivier Benghozi]

Un routeur c'est pas un équipement terminal.

 Le 12 déc. 2014 à 13:57, Raphaël Jacquot sxp...@sxpert.org a écrit :
 
 On 10.12.2014 14:33, Michel Hostettler wrote:
 Bonjour,
 Je n'ai pas suivi le fil depuis le début.
 Il semble que la prise RJ45 se raréfie compte tenu de l'épaisseur
 réduite des ordinateurs portables. L'Ethernet dans les stations
 terminales aurait tendance à disparaître, au profit de Wi-Fi.
 
 le jour ou $ConstructeurDeRouteur mets un port wifi / bluetooth pour le 
 management
 de ses bestioles, on en reparle ;-)


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

Re: [FRnOG] [TECH] BGP Hijacking

[Olivier Benghozi]

Hello,

quelques commentaires:

 Le 21 nov. 2014 à 15:46, Jérôme Nicolle jer...@ceriz.fr a écrit :
 Clearer une session permet de rendre la route plus récente chez ton
 peer, donc potentiellement de redéclencher un best-path-selection, ce
 qui peut suffire si les autres critères de sélection sont équivalents.
 Mais c'est rarement le cas.

Par défaut, en eBGP sur la plupart des routeurs, route plus récente = route 
moins préférée. Donc action contre-productive.
Cf (par exemple):
http://www.cisco.com/c/en/us/support/docs/ip/border-gateway-protocol-bgp/13753-25.html
 
http://www.cisco.com/c/en/us/support/docs/ip/border-gateway-protocol-bgp/13753-25.html
 item 10.
http://www.juniper.net/techpubs/en_US/junos13.3/topics/reference/general/routing-ptotocols-address-representation.html
 
http://www.juniper.net/techpubs/en_US/junos13.3/topics/reference/general/routing-ptotocols-address-representation.html
 item 11


 - Regrouper tes services critiques (DNS, mail, frontaux web) sur un /24
 (en fait un ou deux /25) de ton réseau et désagréger cette annonce (et
 uniquement celle ci). Tu peux proposer à tes peers directs de désagréger
 le /25 afin de garantir qu'il sera préféré et jamais hijacké, mais tu ne
 peux pas balancer le /25 sur des route-server ou des transits qui sont
 censés le filtrer.

En fait tout le monde (de sensé) est censé filtrer plus petit qu'un /24, sauf 
accords particuliers entre AS.
Donc ça semble compliqué.
Du coup et par ailleurs les best practices bortzmeyeriennes (bortzmeyeristes?) 
suggèrent a priori plutôt de distribuer ses DNS dans des /24 séparées (cela-dit 
même des gens très biens ne le font pas).



a+
Olivier


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

Re: [FRnOG] [TECH] Lien optique qui clignote.

[Olivier Benghozi]

Pas besoin d'atténuation en LX/LH ni en LR: les optiques émettent moins fort 
que ce qu'elles peuvent recevoir au max.
Par contre des SFP avec DOM permettent de connaitre la puissance reçue, comme 
l'écrit David.


Le 14 oct. 2014 à 12:47, Sebastien Lesimple slesim...@laposte.net a écrit :

 Et tu as reçu tes mesures lors de la livraison de tes FO?
 Tu as éventuellement besoins d'un atténuateur tout simplement.
 
 Le 14 oct. 2014 à 12:36, David Ponzone david.ponz...@gmail.com a écrit :
 
 2 suggestions:
 
 1) si tes SFP le permettent, vérifie la puissance du signal reçu pendant la 
 coupure et compare avec le reste du temps
 2) au prix d’un SFP, achète du SPARE!
 
 My 0,02€
 
 
 Le 14 oct. 2014 à 12:30, Pierre Colombier pcdw...@pcdwarf.net a écrit :
 
 Bonjour,
 
 j'ai une liaison optique en 1000Base LX d'environ 300m sur de la fibre 
 monomode qui s'est mise à tomber une à deux fois par jours sans raison 
 apparente pendant des durées variant de quelques secondes à plusieurs 
 heures.
 
 Vendredi le lien est tombé plusieurs heures.
 J'ai débranché/rebranché les fibres, retiré et replacé le module SFP, 
 rebooté les switches
 ça n'est pas revenu.
 Et puis magiquement, c'est revenu 2 heures plus tard sans toucher à rien.
 J'ai à nouveau trituré toutes les connectiques, retiré et remis les modules 
 SFP, c'est toujours bien revenu tout de suite.
 
 Je ne dispose pas d'appareils de mesure pour contrôler moi même les fibres 
 mais j'ai un crayon laser.
 Si j'en juge par la forte brillance du point rouge en sortie de fibres 
 (assez fort pour projeter une grosse tache rouge sur le mur à 1 mètre de 
 distance), la fibre n'est pas coupée, les soudures sont OK et on est très 
 très loin des limites en termes d'atténuation.
 
 Est-il possible que ce soit juste un module SFP qui déconne par moments, 
 indépendamment du fait qu'on le débranche/rebranche ?
 
 
 Note : il y a deux liens avec du spanning tree donc il n'y a rien de 
 critique pour le moment.
 Par contre, toutes les fibres font partie du même câble et je suis un peu 
 inquiet.
 En tout cas, j'aimerai comprendre ce qui se passe.
 
 Si certains ont des idées / suggestions de manipes , je suis preneur.
 
 D'avance merci.
 
 Pierre Colombier.
 


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

Re: [FRnOG] [TECH] Problème FranceIX/Atrato ?

[Olivier Benghozi]

Bon, donc Atrato non-plus ils maxpréfixent pas avec leurs clients transits: 
http://www.renesys.com/2014/09/why-the-internet-broke-today/

Le 18 sept. 2014 à 11:59, Olivier Benghozi olivier.bengh...@wifirst.fr a 
écrit :

 Sep 18 08:56:54: [0009]: %BGP-6-INFO: 37.49.236.9 send NOTIFICATION: 6/1 
 (cease: max number of prefixes reached) with 7 byte data. mxReadMs=31124
 
 Des erreurs ont été commises :)
 Mais peut-être que dans ta conf aussi, si je peux me permettre: sans max-pref 
 raisonnable sur un point d'échange on est assez vite embarrassé, a priori :P
 
 Le 18 sept. 2014 à 09:08, Jerome SCHEVINGT jerome...@phibee-telecom.net a 
 écrit :
 
 Bonjour,
 
 Depuis quelques minutes, nous avons du couper nos sessions FranceIX car une
 partie de nos flux, notamment vers Orange, c'est mis a passer via Atrato.
 
 Quelqu'un a eu le même symptôme/problème ?
 
 Cordialement
 Jerome
 


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

Re: [FRnOG] [TECH] Problème FranceIX/Atrato ?

[Olivier Benghozi]

Sep 18 08:56:54: [0009]: %BGP-6-INFO: 37.49.236.9 send NOTIFICATION: 6/1 
(cease: max number of prefixes reached) with 7 byte data. mxReadMs=31124

Des erreurs ont été commises :)
Mais peut-être que dans ta conf aussi, si je peux me permettre: sans max-pref 
raisonnable sur un point d'échange on est assez vite embarrassé, a priori :P

Le 18 sept. 2014 à 09:08, Jerome SCHEVINGT jerome...@phibee-telecom.net a 
écrit :

 Bonjour,
 
 Depuis quelques minutes, nous avons du couper nos sessions FranceIX car une
 partie de nos flux, notamment vers Orange, c'est mis a passer via Atrato.
 
 Quelqu'un a eu le même symptôme/problème ?
 
 Cordialement
 Jerome


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

Re: [FRnOG] [TECH] RFC 7342: Practices for Scaling ARP and ND in Large Data Centers

[Olivier Benghozi]

Pas mal d'OSPF v2/v3 par ici (NSSA nosummary), pour annoncer des VIPs.

Y compris pour faire de l'anycast + ECMP d'ailleurs (fermes de récurseurs DNS 
sans LB/haproxy).


Le 28 août 2014 à 16:20, Pierre-Yves Maunier pymaunier+li...@gmail.com a 
écrit :

 Le 28 août 2014 15:35, Stephane Bortzmeyer bortzme...@nic.fr a écrit :
 
 
 Annoncer les /32 et /128 en OSPF ? Pas bête mais inhabituel. Qui fait
 cela ?
 
 
 On a mis ça en place chez Iguane quand j'y étais (en BGP) et chez Daily on
 utilise ça aussi.
 
 Avec des petits tweaks, tu peux même faire de l'ECMP sur ton serveur,
 pratique quand il est raccordé à 2 routeurs avec re-routage si un routeur
 fail.


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

Re: [FRnOG] [TECH] RFC 7342: Practices for Scaling ARP and ND in Large Data Centers

[Olivier Benghozi]

VRRP ça n'annonce pas trop des VIPs, ça permet plutôt aux serveurs d'avoir un 
nexthop qui marche tout le temps.


Le 28 août 2014 à 16:26, David Ponzone david.ponz...@gmail.com a écrit :

 Juste pour ma culture G, c’est quoi l’avantage par rapport à VRRP ?
 
 Le 28 août 2014 à 16:20, Pierre-Yves Maunier pymaunier+li...@gmail.com a 
 écrit :
 
 Le 28 août 2014 15:35, Stephane Bortzmeyer bortzme...@nic.fr a écrit :
 
 
 Annoncer les /32 et /128 en OSPF ? Pas bête mais inhabituel. Qui fait
 cela ?
 
 
 On a mis ça en place chez Iguane quand j'y étais (en BGP) et chez Daily on
 utilise ça aussi.
 
 Avec des petits tweaks, tu peux même faire de l'ECMP sur ton serveur,
 pratique quand il est raccordé à 2 routeurs avec re-routage si un routeur
 fail.
 
 Pierre-Yves


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

Re: [FRnOG] [TECH] Switch brocade fcx

[Olivier Benghozi]

Les ports de stack sur les 4x10G par défaut sont les 1 et 2. Donc x/2/1 et 
x/2/2.

Ceci dit, on lit ici que tu as inséré tes optiques sur le bandeau de 4x1GE du 
haut au lieu des 4x10GE juste en dessous.

Le 30 juil. 2014 à 21:53, Jeremy li...@freeheberg.com a écrit :

 Salut les barbus,
 
 Je cherche un coup de main pour configurer des saloperie de switch brocade 
 FCX qui me bouffent la vie depuis quelques jours.
 Le concept de stacking qui pourrait être séduisant sur le papier est 
 incompréhensible. J'ai une carte 4x10G qui semble reconnu comme des ports 1G 
 comme le suggère cette réponse du cli :
 
 equinix-val59-10G#sh media ethernet 1/1/1
 Port  1/1/1: Type  : 1G M-LX(SFP)
 Vendor: BrocadeVersion: 1.0
 Part# : 10G-SFPP-LR+-SOSerial#: SOP131L2340
 
 equinix-val59-10G#sh media ethernet 1/1/4
 Port  1/1/4: Type  : 1G M-LX(SFP)
 Vendor: BrocadeVersion: 1.0
 Part# : 10G-SFPP-LR+-SOSerial#: SOP131L2339
 
 D'ailleurs, mes optiques sont sur 1/2/1 et 1/2/4, je ne comprend pas pourquoi 
 il les voit sur 1/1/1 et 1/1/4. Encore un coup du stack unit 1 ?
 
 Bref, si quelqu'un a déjà eu à faire à ces bêtes là, ou qui veux une bonne 
 bière la semaine prochaine lorsque je vais repasser à paris, ça serais très 
 sympa.


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

Re: [FRnOG] [TECH] VLAN maximum sur une interface eth linux

[Olivier Benghozi]

On n'a pas bien les yeux en face des trous à cette heure dans ce thread :)
802.1ad - Q-in-Q
802.3ad - LAG avec LACP
Sans rapport.


Le 16 avr. 2014 à 00:17, Ludovic LACOSTE ludoviclaco...@hotmail.com a écrit :

 Du bonding sur une seule interface, je savais pas, le réseau et les normes 
 ont décidément bien change depuis qu'on a des hommes de valeurs.
 D'ailleurs, que disent les vrais hommes de valeurs depuis que tu le supplais ?
 
 Ludovic
 
 De : Nathan delhayemailto:cont...@nathan-delhaye.fr
 Envoyé : ‎15/‎04/‎2014 23:35
 À : Ludovic LACOSTEmailto:ludoviclaco...@hotmail.com
 Cc : Surya ARBYmailto:arbysu...@yahoo.fr; 
 frnog@frnog.orgmailto:frnog@frnog.org
 Objet : Re: [FRnOG] [TECH] VLAN maximum sur une interface eth linux
 
 Bien sûr. C'est même le principe du truc.
 
 On fera effectivement souvent ça sur des interfaces en
 teaming/bonding/whateveryoucallit parce que quand t'as 16M de vlan c'est
 que tu dois avoir un peu de trafic quand même et/ou que tu veux
 probablement un minimum de redondance.
 
 Mais sous linux ton interface bond qui résulte de ton bonding (qui peut
 aggréger eth0, eth1, eth3...) c'est une seule interface pour le kernel.
 
 
 
 
 Le 15 avril 2014 23:07, Ludovic LACOSTE ludoviclaco...@hotmail.com a
 écrit :
 
 Du 802.1ad avec une seule interface réseau, c'est donc possible ?
 
 Envoyé à partir de mon Windows Phone
 
 De : Surya ARBYmailto:arbysu...@yahoo.fr
 Envoyé : ‎15/‎04/‎2014 22:59
 À : Ludovic LACOSTEmailto:ludoviclaco...@hotmail.com; frnog@frnog.org
 mailto:frnog@frnog.org
 Objet : Re: [FRnOG] [TECH] VLAN maximum sur une interface eth linux
 
 802.1ad
 
 On 15/04/2014 22:36, Ludovic LACOSTE wrote:
 C'est quoi le numéro RFC/IETF/ISO du protocole QinQ ?
 
 Ludovic
 
 De : Nathan delhayemailto:cont...@nathan-delhaye.fr
 Envoyé : ‎15/‎04/‎2014 22:08
 À : Simon Perreaultmailto:simon.perrea...@viagenie.ca
 Cc : MMmailto:mm...@palpix.com; frnog@frnog.orgmailto:frnog@frnog.org
 
 Objet : Re: [FRnOG] [TECH] VLAN maximum sur une interface eth linux
 
 Oui bien sûr ça dépend du protocole. Linux lui-même n'impose aucune
 limite.
 
 Effectivement. Par exemple, le QinQ est très bien géré par linux, donc ca
 fait au moins : 4096*4096 : 16777216 sous interfaces. Je suis pas sûr que
 t'ai besoin de plus... Mais je peux me tromper ;)
 
 --
 Nathan Delhaye
 
 ---
 Liste de diffusion du FRnOG
 http://www.frnog.org/
 
 ---
 Liste de diffusion du FRnOG
 http://www.frnog.org/
 
 
 
 ---
 Liste de diffusion du FRnOG
 http://www.frnog.org/
 
 ---
 Liste de diffusion du FRnOG
 http://www.frnog.org/
 
 
 
 
 --
 Nathan Delhaye
 06 69 27 64 25
 0805 696 494
 
 ---
 Liste de diffusion du FRnOG
 http://www.frnog.org/


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

Re: [FRnOG] [TECH] [Clim] Ce qui s'est vraiment passé à TH2

[Olivier Benghozi]

Le 8 avr. 2014 à 13:31, Frédéric Perrod frede...@perrod.org a écrit :

 Tu es sûr de ça?
 Je vois bien des câbles qui traversent l'Europe et des câbles qui traversent 
 les Etats-Unis, par contre je vois rien sur les cartes pour une traversée 
 Europe-Asie par voie terrestre.

Pas compliqué...

http://submarinenetworks.com/systems/asia-europe-africa/hscs/era-hscs-eurasia-highway
http://submarinenetworks.com/systems/asia-europe-africa/rjcn/rjcn-tea-network


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

Re: [FRnOG] [TECH] - Hijack IndoSat / AS4761

[Olivier Benghozi]

Hello,

Le 2 avril 2014 23:41, Youssef Bengelloun-Zahr yous...@720.fr a écrit :

Nous aussi apparemment à 18h27 et 20h12 UTC pour un de nos préfixes.


Ici plutôt entre 20h30 et 23h selon BGPmon...



 Les alertes BGPmon ont été levées apparement .


A également été levé tout doute quant à la médiocrité des tocards d'Indosat
(vu que ça fait quand même deux fois).


Olivier

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

Re: [FRnOG] [TECH] MLVPN ?

[Olivier Benghozi]

En revanche, ce sont les FAI qui interdisent l'utilisation de lignes ADSL
grand public pour un usage collectif.


Le 1 mars 2014 12:41, Gwilhom ml-fr...@gwilhom.fr a écrit :

 Le 28/02/2014 15:58, Yoann Gini a écrit :

  Salut la liste,

 Via ma question d’accès Internet pour Nice je viens de découvrir le
 principe du MLVPN.

 Ça m’intéresse grandement pour un autre client. J’aurais aimé avoir vos
 retours sur cet outil. Pour ? Contre ? Caractéristique des machines à
 chaque bout ? Est-ce que certains hébergeurs lowcost (Kimsufi / Dedibox)
 interdisent ce genre d’usage ? etc.

 C’est pour une résidence d’étudiant qui a 3 accès ADSL pour 50 personnes
 (entre deux et trois terminaux par personne).

 Cordialement,
 Y.


 Bonjour,

 Les hébergeurs (kimsufi et online) ne l'interdisent pas tu peux te faire
 plaisir :)

 --
 Gwilhom


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


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

Re: [FRnOG] [MISC] Amplifications NTP

[Olivier Benghozi]

Sans compter les Juniper dont le client ntp fait aussi spontanément serveur 
alors que tu lui avais pas demandé, et qui tournent des xntpd antédiluviens 
parfaitement adaptés à relayer du DDoS.

http://www.gossamer-threads.com/lists/nsp/juniper/49151

Quelle blague.


Le 1 févr. 2014 à 15:16, Frederic Dhieux frede...@syn.fr a écrit :

 Il y a 2-3 semaines un serveur chez un client dont le ntp était ouvert par 
 erreur a été utilisé pour de l'amplification, c'était effectivement assez 
 visible en volume sortant chez nous et plutôt agressif.
 
 Sans Netflow on ne l'aurait surement pas vu avant un moment...
 
 Ecritel y'a une semaine, Colt ces derniers jours, il y a peut-être des gens 
 qui trouvent le marché de l'anti-DDoS en France pas assez florissant en ce 
 moment :p
 
 Frédéric
 
 Le 01/02/2014 14:55, David Ramahefason a écrit :
 COLT en souffre sur Paris depuis qq jours.
  -- 
 David Ramahefason
 
 
 Le 1 février 2014 at 14:54:36, Thierry Wehr (t.w...@widevoip.com) a écrit:
 
 Hello tous
 
 certaines infrastructures doivent prendre très chère avec les amplifications 
 NTP en cours !
 
 a+
 Thierry
 ---
 Liste de diffusion du FRnOG
 http://www.frnog.org/
 
 ---
 Liste de diffusion du FRnOG
 http://www.frnog.org/
 
 
 ---
 Liste de diffusion du FRnOG
 http://www.frnog.org/


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

Re: [FRnOG] [TECH] Session Transit Client sur Route Serveur ?

[Olivier Benghozi]

Bonjour,

eBGP multihop pour du transit, en tant que client je passe mon chemin si un 
fournisseur tente de me fourguer ça.


Par contre ce qui existe et que j'ai vu, c'est d'agréger des clients sur un 
switch local, avec un LAG entre ton routeur et le switch, ledit routeur n'étant 
pas forcément sur le même site. Un vlan par client, traversant le switch. Ça 
nécessite quelques lambdas dédiés sur au moins une FON.

Naturellement, comme tout raccordement indirect (et ce serait le cas aussi avec 
de l'ebgp multihop d'ailleurs), c'est certes moins cher pour le fournisseur 
mais moins bien qu'un raccordement direct.
D'une part en cas de coupure d'un coté du switch, le BGP ne tombe pas 
immédiatement de l'autre coté puisque tu ne vois pas le lien.
D'autre part ton routeur priorise le trafic BGP spontanément, mais pas le 
switch si tu ne fais pas de QoS dessus. Comme tu as plus de capa entre ton 
routeur et le switch qu'il n'y en a entre le switch et le client, si le port du 
client sature et que le BGP n'est pas priorisé sur ce lien, risque de flap de 
session.
Enfin il faut dimensionner ton LAG correctement.

Avantage: rien de spécial à faire coté client.


Si jamais il te commande deux liens sur deux sites différents pour redonder, 
arrange toi quand même pour que ça n'arrive pas sur le même routeur au final...
Si ton client est compétent et qu'il voit qu'il a deux fois le même router-id 
sur ses sessions eBGP, il ne va pas être content.


Olivier


Le 31 janv. 2014 à 04:34, Olivier CALVANO o.calv...@gmail.com a écrit :

 Bonjour,
 
 Besoin d'un conseil technique ;=)
 
 Pour le moment, quand j'ai un client qui veut du transit BGP full table, je
 fais la session BGP
 directement sur le routeur ou il est connecté (mon routeur a lui ses
 sessions avec mes routes serveurs).
 
 Lors d'un meeting, certain m'ont dit qu'eux avait maintenant des routes
 serveurs dédiés aux clients
 transit et que la session BGP en elle même n'était plus sur le routeur ou
 etait connecté le client, ce qui permettait de limiter la présence de
 gros routeurs sur chaque site.
 
 J'étudie donc maintenant l'intérêt de cette solution et si elle est
 réellement intéressante/possible.
 
 Qu'en pensez vous ?
 Au niveau configuration client, cela veut dire que l'on doit passer des
 commandes comme bgp-multihop, router en ip route les IPs des routes
 serveurs etc correct ?
 
 Merci d'avance
 
 Amicalement
 Olivier
 
 ---
 Liste de diffusion du FRnOG
 http://www.frnog.org/


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

Re: [FRnOG] [TECH] Routage dynamique

[Olivier Benghozi]

Il y a quelques temps j'avais assisté chez Brocade à une présentation 
intéressante de François Devienne de Border 6.

Et en effet, pour ce qui est du trafic sortant, c'est en gros ce que font les 
boites magiques en annonçant en interne des préfixes des AS cibles avec un 
nexthop approprié vers le lien qu'on veut utiliser (en fait des préfixes deux 
fois plus petits donc plus spécifiques, ce qui permet de continuer à voir 
l'annonce d'origine dans la RIB pour réagir si nécessaire si elle vient à 
changer).

La décision est prise selon des mesures snmp, netflow, des tests de ping et 
peut-être de service, des éléments configurés de type capacité, coût des liens, 
latence, etc...


Pour le trafic entrant naturellement c'est autre chose, c'est forcément du 
prepend et des communautés BGP proposées par le fournisseur de transit (donc il 
s'agit de changer des confs de routeurs edge par script).



Le 20 déc. 2013 à 12:43, Denis Fondras xx...@ledeuns.net a écrit :

 Bonjour,
 
 Est-ce que ce genre de chose n'est pas une mission pour ExaBGP  ?
 
 Denis
 
 
 Le 20/12/2013 10:19, Pierre-Yves Maunier a écrit :
 Bonjour Gautier,
 
 
 Deja il y a qqchose qui me choque dans ton énoncé :
 
 prepend et a destination de
 
 
 Generalement tu prepend ton AS sur tes policies out pour tenter de
 contrôler le trafic entrant et non le trafic sortant.
 
 Pour contrôler ton trafic sortant, les BCP recommandent l'utilisation de
 local pref et med sur tes policies in.
 
 Le faire automatiquement, a coup de scripts avec du expect ou de rancid
 (jlogin/clogin) tu peux faire des choses mais attention, un script qui va
 modifier ta façon de router, tu as intérêt a bien le blinder pour ne pas
 peter ton réseau si ton script plante.
 
 
 Il existe des solutions payantes mais assez onéreuse de mémoire.
 
 
 PS : désolé pour les accents manquants par moments, clavier qwerty powered
 
 
 Le 19 décembre 2013 12:21, Gautier Avril
 gautier.av...@bretagnetelecom.coma écrit :
 
 A l'heure actuelle, on a plusieurs transitaire et on essayer de jouer sur
 du prepend pour gerer le traffic à destination de tel AS en fonction de la
 qualité que l'on observe avec nos différents transitaires (basé sur du
 smokeping essentiellement).
 
 Globalement, on est sur une situation assez stable, mais il peut arriver
 que l'un de nos transitaires connaisse une problème vers certains AS,
 auquel cas une petite opération manuelle permet d'améliorer les chose (a
 moitié me direz vous, car on ne maitrise pas le traffic dans les deux sens).
 
 La question que je me pose est : existe t'il une méthode pour faire cela
 de façon dynamique, si possible assez standardisée?


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

Re: [FRnOG] [TECH] Juniper NSM

[Olivier Benghozi]

De mon point de vue J-Web n'est pas vraiment inutilisable. Hyper lent, avec des 
morceaux de conf qui ne s'affichent subitement plus quand ce qui est configuré 
dépasse ce que le développeur a prévu pour J-Web.
Par contre la CLI est excellente.

C'est le contraire sur les Fortinet par exemple: une GUI plutôt très bien 
faite, et une CLI pourrie.

Bon ça ne répond pas à la question d'origine sur une interface pour administrer 
en masse.


Le 4 oct. 2013 à 09:54, Raphael Mazelier r...@futomaki.net a écrit :
 A noter que pour les SRX l'interface J-WEB est vaguement utilisable. C'est 
 pas génial mais elle a moins le mérite de respecter l'arborescence de la 
 configuration cli.



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

Re: [FRnOG] [TECH] Juniper NSM

[Olivier Benghozi]

N'est pas vraiment utilisable, voulais-je dire :)
Bref c'est naze.

Le 5 oct. 2013 à 16:40, Olivier Benghozi olivier.bengh...@wifirst.fr a écrit :

 De mon point de vue J-Web n'est pas vraiment inutilisable. Hyper lent, avec 
 des morceaux de conf qui ne s'affichent subitement plus quand ce qui est 
 configuré dépasse ce que le développeur a prévu pour J-Web.
 Par contre la CLI est excellente.
 
 C'est le contraire sur les Fortinet par exemple: une GUI plutôt très bien 
 faite, et une CLI pourrie.
 
 Bon ça ne répond pas à la question d'origine sur une interface pour 
 administrer en masse.
 
 
 Le 4 oct. 2013 à 09:54, Raphael Mazelier r...@futomaki.net a écrit :
 A noter que pour les SRX l'interface J-WEB est vaguement utilisable. C'est 
 pas génial mais elle a moins le mérite de respecter l'arborescence de la 
 configuration cli.
 
 


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

Re: [FRnOG] [TECH] Utilisez-vous la fonction proxy ARP ?

[Olivier Benghozi]

Hello,

Pour ce qui est du proxy ARP local, dans les cas d'isolation de clients à
l'accès quand ils partagent un même subnet IP par exemple, pour contrôler
le trafic entre eux (ou tout simplement le permettre sans créer un domaine
de broadcast, mais ça ne concerne pas le LAN).

Et donc, en LAN avec private vlan, en DSL (MER, pas PPP), en FTTx...

-- 
Olivier Benghozi
Wifirst
 Le 23 sept. 2013 10:36, Michel Hostettler 
michel.hostett...@telecom-paristech.fr a écrit :

 Bonjour,

 Utilisez-vous encore la fonction proxy ARP aujourd'hui, dans vos réseaux
 LAN, ou bien est-elle seulement un cas d'école ?

 Si d'aventure vous aviez une raison de le faire, pourriez-vous SVP la
 formuler ?

 Merci beaucoup,
 cordialement,
 Michel Hostettler


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


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

Re: [FRnOG] [TECH] Utilisez-vous la fonction proxy ARP ?

[Olivier Benghozi]

Non, pas vraiment; en fait il y a, pour simplifier, un domaine de broadcast par 
paire Host/Gateway, avec un seul vlan et un seul subnet pour tout le monde; les 
clients ne se voient pas entre eux directement (fonction private vlan) mais ils 
voient tous la gateway, qui est le seul équipement à envoyer des trames 
broadcasts (et multicasts) vers les clients et à recevoir les leurs.
Si un client veut parler à un autre client du même vlan et même subnet, seule 
la gateway répondra en ARP et verra donc passer tous les paquets entre les deux 
clients (du moins les paquets qu'elle autorisera).

Le 23 sept. 2013 à 13:01, Michel Hostettler 
michel.hostett...@telecom-paristech.fr a écrit :

 Bonjour Olivier,
 
 Merci pour cette réponse.
 
 Le schéma suivant pourrait-il être conforme à votre description.
 
 Les 2 groupes d'utilisateur partagent le même sous-réseau #2, mais ils ont 
 des domaines de broadcast différents. Le routeur peut contrôler les trafics.
 
 Cordialement,
 Michel
 
 
 - Mail original -
 De: Olivier Benghozi olivier.bengh...@wifirst.fr
 À: Michel Hostettler michel.hostett...@telecom-paristech.fr
 Cc: frnog-t...@frnog.org
 Envoyé: Lundi 23 Septembre 2013 11:53:46
 Objet: Re: [FRnOG] [TECH] Utilisez-vous la fonction proxy ARP ?
 
 
 
 Hello,
 
 Pour ce qui est du proxy ARP local, dans les cas d'isolation de clients à 
 l'accès quand ils partagent un même subnet IP par exemple, pour contrôler le 
 trafic entre eux (ou tout simplement le permettre sans créer un domaine de 
 broadcast, mais ça ne concerne pas le LAN).
 
 Et donc, en LAN avec private vlan, en DSL (MER, pas PPP), en FTTx...
 
 
 --
 Olivier Benghozi
 Wifirst
 
 Le 23 sept. 2013 10:36, Michel Hostettler  
 michel.hostett...@telecom-paristech.fr  a écrit :
 
 
 Bonjour,
 
 Utilisez-vous encore la fonction proxy ARP aujourd'hui, dans vos réseaux LAN, 
 ou bien est-elle seulement un cas d'école ?
 
 Si d'aventure vous aviez une raison de le faire, pourriez-vous SVP la 
 formuler ?
 
 Merci beaucoup,
 cordialement,
 Michel Hostettler
 
 
 ---
 Liste de diffusion du FRnOG
 http://www.frnog.org/
 Proxy ARP.pptx


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

Re: [FRnOG] [MISC] 10G l3/l4 firewall

[Olivier Benghozi]

La GUI web est bien foutue, et quand le numéro de révision de l'OS est élevé ça 
marche bien.
À côté de ça, la CLI est abominable (et on n'y coupe pas pour les fonctions 
avancées comme le routage dynamique), et quand l'OS est trop récent, c'est 
trop buggé (mais ce n'est pas une exclusivité).

Le 24 juin 2013 à 22:17, Mattieu Baptiste mattie...@gmail.com a écrit :

 Perso, aucune idée pour Fortinet, mais tant que tu te limites à du filtrage
 L4, ils ont pas mauvaise réputation.


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

Re: [FRnOG] [TECH] Test bandwidth IPERF/CISCO bisarre

[Olivier Benghozi]

Et en augmentant le burst?

Le 16 juin 2013 à 10:01, Antoine Durant antoine.duran...@yahoo.fr a écrit :

 Bonjour,
  
 Je ne sais pas et ne comprend pas le phénomène justement...
  
 Même un test avec iperf en UDP ne me permet pas de monter à 10M.
  
 Les RFC ne m'aide pas du tout dans ce cas la... J'ai l'impression que le 
 switch se bride tout seul à 4.10Mbps au lieu du 10M configuré dans la police 
 !!
  
 wget http://10.0.0.110/200M.bin -O /dev/null on 192.168.0.170 :
 
 Avec service-policy : 513KB/s (~4.10 Mbps  10Mbps)
 Sans service-policy : 11.2MB/s (~90 Mbps = 100Mbps)
 
 service-policy 1000 = 10,00 Mbps
  
 Une solution ? Avez vous une conf sur switch cisco qui fonctionne ??
 


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

Re: [FRnOG] [TECH] Limitation trafic entre deux MAC sur 2960

[Olivier Benghozi]

Visiblement tu matches dans ta classmap une ACL IP numéro 100 alors que tu as 
défini par ailleurs une CAR ACL numéro 100.

Et puis il faut RTFM naturellement: 
http://www.cisco.com/en/US/docs/switches/lan/catalyst2960/software/release/12.2_58_se/configuration/guide/swqos.html#wp1044737
La commande qui y est documentée est mac access-list extended blabla...


Le 12 juin 2013 à 14:53, Antoine Durant antoine.duran...@yahoo.fr a écrit :

 J'ai la version suivante : Cisco IOS Software, C2960 Software 
 (C2960-LANBASEK9-M), Version 12.2(55)SE1, RELEASE SOFTWARE (fc1)
  
 J'ai essayé la configuration suivante mais cela ne marche pas...
  
 class-map match-all LIMIT-TRAFFIC
  match access-group 100
 !
 policy-map LIMIT-TRAFFIC
  class LIMIT-TRAFFIC
   police 100 1 exceed-action drop
 !
 interface FastEthernet0/11
  service-policy input LIMIT-TRAFFIC
 !
 access-list rate-limit 100 0040.63dd.e086
 


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

Re: [FRnOG] [TECH] Limitation trafic entre deux MAC sur 2960

[Olivier Benghozi]

match access-group name maclist1, peut-être ?

Le 12 juin 2013 à 17:22, Antoine Durant antoine.duran...@yahoo.fr a écrit :

 Je me suis déjà appuyé sur le lien que tu donnes. Par contre cela ne 
 fonctionne pas chez moi lors du match access-group:
  
 switch(config)#mac access-list extended maclist1
 switch(config-ext-macl)#permit host b827.ebcd.a814 host 0040.63dd.e086
 switch(config-ext-macl)#exit
 switch(config)#class-map macclass1
 switch(config-cmap)#match access-group maclist1
  ^
 % Invalid input detected at '^' marker.
 switch(config-cmap)#
 
 De : Olivier Benghozi olivier.bengh...@wifirst.fr
 À : Antoine Durant antoine.duran...@yahoo.fr; frnog-t...@frnog.org 
 frnog-t...@frnog.org 
 Envoyé le : Mercredi 12 juin 2013 17h13
 Objet : Re: [FRnOG] [TECH] Limitation trafic entre deux MAC sur 2960
 
 Visiblement tu matches dans ta classmap une ACL IP numéro 100 alors que tu as 
 défini par ailleurs une CAR ACL numéro 100.
 
 Et puis il faut RTFM naturellement: 
 http://www.cisco.com/en/US/docs/switches/lan/catalyst2960/software/release/12.2_58_se/configuration/guide/swqos.html#wp1044737
 La commande qui y est documentée est mac access-list extended blabla...
 
 
 Le 12 juin 2013 à 14:53, Antoine Durant antoine.duran...@yahoo.fr a écrit :
 
  J'ai la version suivante : Cisco IOS Software, C2960 Software 
  (C2960-LANBASEK9-M), Version 12.2(55)SE1, RELEASE SOFTWARE (fc1)
   
  J'ai essayé la configuration suivante mais cela ne marche pas...
   
  class-map match-all LIMIT-TRAFFIC
   match access-group 100
  !
  policy-map LIMIT-TRAFFIC
   class LIMIT-TRAFFIC
   police 100 1 exceed-action drop
  !
  interface FastEthernet0/11
   service-policy input LIMIT-TRAFFIC
  !
  access-list rate-limit 100 0040.63dd.e086
  
 
 
 ---
 Liste de diffusion du FRnOG
 http://www.frnog.org/
 


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

Re: [FRnOG] [MISC] SFR passe la fibre à 300Mbps

[Olivier Benghozi]

Le 7 juin 2013 à 18:02, Jérôme Nicolle jer...@ceriz.fr a écrit :
 Le 06/06/2013 00:11, Solarus a écrit :
 Pardon j'ai dis DSLAM, mais je voulais dire PE(LNS).
 
 SFR utilise essentiellement des Ericsson Smart Edge (ex redback) en LNS.

À ma connaissance SFR utilise essentiellement des SmartEdge comme PTA  LAC: 
pour terminer du PPP, et éventuellement l'encapsuler dans du L2TP vers un 
client collecte.
En revanche comme indiqué dans la page commerciale de Cisco, c'est pour l'IPv6 
que SFR utilise des LNS ASR1000 Cisco (le tunnel L2TP monté à cet effet par la 
9box qui fait LAC contient donc une session PPP IPv6CP).


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

Re: [FRnOG] [TECH] Peering et attaques

[Olivier Benghozi]

Chez Cogent?

C'est sûrement le contraire non ? :)

Le 16 mai 2013 à 09:36, Jérémy Martin li...@freeheberg.com a écrit :
 Ca coutera toujours moins cher que de passer en port 10G.


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

Re: [FRnOG] [TECH] Routeur(s) d'origine

[Olivier Benghozi]

Si c'est un atomic aggregate, l'update contient l'attribut AGGREGATOR avec le 
router-id et l'AS du routeur ayant créé l'agrégat.
Comme l'aspath, c'est manipulable sur un Juniper par exemple.
mauvais esprit Ou alors on tombe sur un bug Brocade et l'attribut est présent 
mais vide /mauvais esprit.

Sinon, pas d'infos dans l'update.


Le 1 févr. 2013 à 17:56, Stephane Bortzmeyer bortzme...@nic.fr a écrit :
 La question est « soit une annonce BGP reçue en un point
 d'observation, peut-on retrouver le routeur d'origine, i.e. le premier
 routeur qui a annoncé cette route sans l'avoir apprise par BGP (il a
 pu l'apprendre par un IGP ou en iBGP, ou bien avoir été configuré
 manuellement) ? »


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

Re: [FRnOG] [MISC] Routeurs BGP : Conseil de topologie

[Olivier Benghozi]

Mais ne fait pas passer une goutte de trafic. Donc c'est un peu différent.

Le 4 nov. 2012 à 16:48, Arnaud Fenioux a écrit :
 Clair!
 et bird il tourne tres bien dans pas mal de GIX, et pas que Français, Gnak!


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

Re: [FRnOG] [TECH] Authentification administrateur radius sur smartedge

[Olivier Benghozi]

La doc vient avec le dictionnaire radius, pourtant.
Deux VSA VendorSpecific Integer: 72 TTY-Level-Start  73 TTY-Level-Max, à 
mettre à 15 (par exemple et pour faire simple).


-- 
Olivier Benghozi
Wifirst

Le 31 oct. 2012 à 13:10, Raphael Mazelier a écrit :

 J'ai une question technique pour une fois :)
 Tout nos équipements réseaux utilisaient tacacs+ pour authentifier les accès 
 administrateurs.
 Je suis en train de tout passer sous radius pour des raisons 
 d’homogénéisation.
 Pour des équipements cisco, juniper, et même extreme (modulo quelques 
 recherches et quelques attributs) pas de problème.
 
 En revanche je butte sur la configuration des mes redback/ericson smartedge.
 J'arrive bien à m'authentifier via mon radius (freeradius) mais je n'ai aucun 
 privilèges.
 J'imagine qu'il faut rajouter un attribut spécifique redback pour lui 
 spécifier qu'on a les bons privilèges.
 
 Il n'existe quasiment aucune document sur le net, et la doc de référence est 
 plus que laconique sur le sujet.


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

Re: [FRnOG] [TECH] Incident Interoute

[Olivier Benghozi]

Idem par ici et aux mêmes heures. Premier retour du support grotesque de type 
RAS actuellement.

Le 18 oct. 2012 à 15:22, Minux a écrit :
 C'est précisément, à la minute, les mêmes horaires de coupure que nous 
 enregistrons...
 Case ouvert chez Interoute, en attente d'un retour.


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

Re: [FRnOG] [TECH] Annonces BGP / désagrégation de préfixe

[Olivier Benghozi]

Bonjour,

Le 17 sept. 2012 à 00:46, Gille Fergusson a écrit :
 Ca c'est sur mais ca m'énnerve aussi de devoir demander un /24 juste pour 1
 ou 2 IP pour lesquelles j'ai
 cette problématique


Y a plus de PI au RIPE depuis vendredi, donc cette possibilité n'en est plus 
une...


 Pour ca, il faut qu'ils annoncent eux mes blocs au monde entier puis que je
 refasse les annonces désagrégées en interne
 entre SFR et nous ?
 
 Cela risque d'être laborieux pour qu'SFR comprenne la problématique et
 surtout trouve la bonne
 personne pour faire les modifs dans le BGP (la dernière fois, ca a pris 3
 mois !).

Comme indiqué notamment par Frederic et Clement, un fournisseur de transit 
filtre habituellement /25 et plus petit en standard, donc pas moyen de faire 
autrement que d'aller discuter avec ton fournisseur pour qu'il te laisse 
annoncer des routes plus petites qui resteront chez lui (en plus du /24 qui lui 
sera réannoncé à l'extérieur).


 non non, ils ne filtrent pas.
 On rajoute des blocs régulièrement sans rien leur dire et les annoncent
 passent sans problème

Il est certainement erroné de penser que SFR ne filtre rien: a minima ils 
filtrent les bogons (comme toi), et les /25 et plus petits en font partie sur 
Internet.


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

Re: [FRnOG] [TECH] Re: Compte à rebours des 400 000

[Olivier Benghozi]

Le 18 août 2012 à 15:51, Nicolas DEFFAYET a écrit :

 Le filtrage sur le minimum allocation size des RIR n'est plus possible
 malheureusement car l'ARIN et le RIPE ont réduit leur minimum allocation
 size à /24 pour leur blocs IANA.
 
 Personnellement, je réfléchi plus à la construction de prefix-list
 basées sur la criticité que par rapport à la taille du prefix. Après une
 prefix-list de 250 lignes, c'est rien. Pour rappel de nombreux réseaux
 générent des prefix-lists automatiquement depuis les AS-MACRO pour tous
 leurs peerings.

Je voulais dire que ce n'était pas raisonnablement maintenable.
Par ailleurs tu soulignes que ce n'est même plus vraiment envisageable, donc 
bref, sans objet.
Bon ensuite je ne vais pas troller sur la validité, l'utilité, la pertinence, 
la transparence, la fraicheur des informations d'AS-SET (AS-MACRO ayant changé 
de nom), et sur le risque d'automatiser des mises à jours de prefixlist à 
grande échelle (cf Level 3) car trolldi c'était hier :)


 La plate-forme Cisco 6500/7600 est utilise par énormément de réseaux
 (quelque soit la taille, y compris des gros) comme routeur edge pour

Tout à fait, ça s'est vendu comme des ptits pains dans les années 2000, et de 
nombreux réseaux y compris internationaux ont été montés avec ces équipements. 
J'ai pu constater que le MX lui avait grosso modo succédé avec l'évolution des 
besoins et des débits, par exemple chez les opérateurs de transit.


 livrer leur clients. Je ne les voit pas changer du jour au lendemain
 tous leurs routeurs car la DFZ ne rentre plus dans la TCAM de leur
 routeur edge. Beaucoup vont déployer des route-servers et ils vont donc
 monter les sessions BGP en multi-hop avec leur client.


Ceux qui ne peuvent pas faire autrement bricoleront un truc, comme toujours.
D'ailleurs la livraison de transit (ou de collecte, ou même de L3VPN) via un 
switch intermédiaire d'agrégation en L2 (ou comme point de démarcation, façon 
sucre optique de luxe), pour des petites capa, ça existe déjà.


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

Re: [FRnOG] [TECH] Re: Compte à rebours des 400 000

[Olivier Benghozi]

Salut,

Le 17 août 2012 à 23:53, Jérôme Nicolle a écrit :
 Moi, ça va, mon réseau à la maison est en routage software. Mais quid
 des 3BXL en prod, que va t il se passer quand on dépassera les 512k
 routes, sur les réseaux qui auront oublié de repartitionner la TCAM ?

Bin, comme quand on a dépassé les 192k quand les gens avaient des 3B en prod, 
c'était en 2005...
Certains auront anticipé, d'autres pas; ça ne s'arrête pas forcément de marcher 
subitement, en principe certains préfixes ne sont juste pas descendus en tcam 
et ne sont plus joignables. Comme on ne peut pas choisir lesquels, ça peut être 
rapidement amusant, on verra quels sont les clow^H^H^Hmalchanceux impactés ; 
mais ça peut aussi bien passer inaperçu quelques temps.


 On a quand même pas mal de mauvais élèves dans la zone FR. Un exemple au
 TOP20 :
 
 AS15557   1215  552 663 54.6% LDCOMNET Societe 
 Francaise du
 Radiotelephone S.A
Avec tous les rachats, les 150 backbones et l'historique, il est vrai que ce 
doit être particulier à gérer.


 Alors, quand est ce qu'on fait le ménage sur nos annonces ?
C'est vrai que pour un trolldi, c'était drôlement calme jusqu'à présent :)


 Bon, techniquement, 410k, 450k, 500k routes, ça ne fait pas une grande
 importance : les vielles brolles de BigIron et SUP720-3B sont déjà
 hors-ligne, ou hors de la DFZ, mais ça ne doit pas coûter pas grand
 chose de limiter l'inflation, non ?
J'ai vu pas mal de propositions qui envisageaient grosso modo de filtrer 
fortement les routes reçues et de rajouter une default.
Ça va du faut filtrer tout ce qui est plus petit qu'un /21 à voilà les 
allocations selon les pools IANA, faut prévoir 250 lignes de prefixlist, et 
bien sûr on peut tenir compte de peering/je garde, transit/je filtre et je 
default au moins partiellement.
Note que ça ne colle pas pour les fournisseurs de transits, très moyennement 
pour les hébergeurs, et pas trop mal pour les réservoirs d'eyeballs (qui 
auraient encore des trucs à base de TCAM pour la DFZ).



 En fait, la question se pose surtout pour ceuw qui tournent en 3BXL et
 2T, et qui ont quelques 100k routes par ci par là en MPLS. Ce serait
 interessant de savoir qui peut être impacté par la limite des 1M
 cumulées, sachant qu'au moins 25186 l'a dépassée depuis longtemps.

Ceux qui ont vraiment tout plein beaucoup de routes ont dû lâcher les archis à 
base de TCAM. Indépendamment du nombre de routes, ce qui s'est vendu comme des 
ptits pains après l'époque du 6500, ce sont les MX de Juniper. Pas de TCAM 
là-dedans pour la FIB, plusieurs millions de routes supportées.
D'ailleurs en matière de VPNv4, sur les 6500 dans la TCAM, par défaut (et 
jusqu'à ce que le Per-VRF Label soit disponible -quoique expérimental- sur 
6500), une route VPNv4 compte double (une entrée dans la partie IPv4, une dans 
la partie MPLS), tout comme une route IPv6 (et une route VPNv6 compte triple).


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

Re: [FRnOG] [BIZ] Optiques AVAGO gratuites

[Olivier Benghozi]

Pourquoi malheureusement? Vues les parts de marché de Cisco, c'est bien 
légitime de s'attendre à ce que des ingés sachent faire quelque chose sur ces 
équipements-là en sortant de l'école.

Ceci-dit, il me semble que les constructeurs qui ne pratiquent pas ce type de 
lobbying n'ont juste pas encore compris que c'était leur intérêt.
Les chinois, je ne dis pas, ils se battent sur un autre terrain.
Alcatel, je ne dis pas, je ne sais pas à quand remonte leur dernière bonne 
décision.

Mais Juniper, voire Brocade, franchement?
Comme ils lisent la liste, ils peuvent peut-être commenter.


Le 11 août 2012 à 12:59, William Gacquer a écrit :

 Bonjour,
 
 qui dit cours dit TD et TP donc matos.
 Cisco fait du lobbying et trust les écoles et universités. Les autres ne 
 proposent quasiment rien. J'ai tenté de bouger Alcatel par exemple. C'est 
 pure perte de temps.
 
 Donc oui, malheureusement, il y a souvent des lignes de l'ios cisco dans les 
 cours.
 
 ( en outre, j'attends avec impatience le jour ou les constructeurs arrêteront 
 de copier l'ios cisco qui est un très mauvais langage.) 
 
 William Gacquer - Architecte Réseau
 
 
 Le 10 août 2012 à 17:57, Fabien Delmotte a écrit :
 
 Bonsoir,
 Je ne pensais pas que cours réseau impliquait slides Cisco, cela explique le 
 comportement des nouveaux inge réseaux .
 
 Fabien
 
 Envoyé de mon iPad
 
 Le 10 août 2012 à 17:08, Vincent Peyrouse vincent.peyro...@icloud.com a 
 écrit :
 
 Bonjour Patrick et bonjour à toute la ML,
 
 Je suis étudiant dans une école d'informatique (SUPINFO pour ceux qui 
 connaissent) et je dois donner des cours de réseau aux promotions suivantes 
 à la rentrée.
 
 Je pense que ça serait un petit plus de pouvoir leur montrer du matériel en 
 plus des slides cisco théoriques et de Packet Tracer.
 
 Donc je serai assez intéressé :)
 
 Cordialement,
 
 Vincent PEYROUSE,
 Étudiant SUPINFO Lyon en 3ème année
 
 PS: Désolé pour le double/triple mail Patrick (Apple et ses fichus alias...)
 
 Le 10 août 2012 à 13:13, Patrick Heintzmann patrick.heintzm...@zycko.com 
 a écrit :
 
 Bonjour,
 
 Je souhaite me « débarrasser » de vieilles optiques AVAGO.
 
 J'ai 9 GBICs en SX et un SFP cuivre.
 
 En sus, 2 * J485A de marque  HP et 1* J4858 de marque PROLABS.
 
 Priorité à la première réponse:)
 
 Bon mois d'Août.
 Patrick
 
 
 
 
 [Zycko]http://www.zycko.fr/
 
 [http://www.zycko.com/images/signature/FRANCE/i/august2012.png]http://fr.zycko.com/produits/meraki/
 
 
 
 
 Patrick Heintzmann
 
 
 
 
 Directeur général
 
 
 
 
 T:
 
 +33 1 80 77 02 73
 
 
 
 M:
 
 +33 6 80 99 31 49
 
 
 
 E:
 
 patrick.heintzm...@zycko.commailto:patrick.heintzm...@zycko.com
 
 
 
 W:
 
 www.zycko.frhttp://www.zycko.fr/
 
 
 
 Zycko TVhttp://fr.zycko.com/mediatheque/zycko-tv/
 
 
 
 
 
 
 ___
 
 This email is confidential and intended solely for the use of the 
 individual to whom it is addressed. Any views or opinions presented are 
 solely those of the author and do not necessarily represent those of Zycko 
 Limited. If you are not the intended recipient, be advised that you have 
 received this email in error and that any use, dissemination, forwarding, 
 printing, or copying of this email is strictly prohibited. If you have 
 received this email in error please notify Zycko Limited on +44 1285 
 868500.
 All emailed quotes are valid for 14 days, subject to availability, unless 
 otherwise stated.  All emailed quotes are subject to Zycko's standard 
 Terms and Conditions.
 
 This e-mail has been scanned for all viruses by Star Internet. The
 service is powered by MessageLabs. For more information on a proactive
 anti-virus service working around the clock, around the globe, visit:
 http://www.star.net.uk
 
 ---
 Liste de diffusion du FRnOG
 http://www.frnog.org/
 
 
 ---
 Liste de diffusion du FRnOG
 http://www.frnog.org/
 
 
 ---
 Liste de diffusion du FRnOG
 http://www.frnog.org/
 
 
 ---
 Liste de diffusion du FRnOG
 http://www.frnog.org/


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

Re: [FRnOG] [TECH] Préco pour un LNS - Solution libre ?

[Olivier Benghozi]

Hello,

Le 7 août 2012 à 16:36, Jérôme Nicolle a écrit :
 Une paire de SE100 sortirait à 14k€ semble t il (mais je veux bien qu'un
 pre-sales d'Ericsson lises ses mails). Une paire de serveurs
 raisonnablement configurés environ 800€ pièce. Sans tenir compte de
 l'encombrement et de la consommation moindre, c'est bien l'ordre de
 grandeur.


 Les feedbacks qu'on m'a fait jusque là sont plutôt dans l'autre sens :
 code Juniper pas sec pour les features associées au LNS, mais
 SE100/400/800 très bons pour peu qu'on aie des cartes récentes.

SE400/800, fin de vie.

Je confirme pour les SE600 avec des cartes actuelles, côté LNS ça juste marche 
sans soucis pour cet usage, milliers de sessions et des tas de Gb/s avec du 
MPLS, de la fullview, etc. On m'en avait dit du mal concernant les générations 
précédentes, mais jusqu'à présent ça tourne plutôt honnêtement.

Les problèmes les plus sérieux qu'on a pu voir ont été dans le code BGP, avec 
des correctifs comme il se doit.

Côté features, il y a des choses que les autres ne font pas, mais on reste 
parfois un peu en retrait par rapport à du Cisco (et du JunOS, mais pour faire 
LNS on me dit que c'est pas prêt).

-- 
Olivier Benghozi


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

Re: [FRnOG] [TECH] Cohabition HSRP + VRRP

[Olivier Benghozi]

Le 25 juin 2012 à 14:00, Stephane Bortzmeyer a écrit :
 Revoir la RFC 2338 http://www.faqs.org/rfcs/rfc2338.html 
 
 Deux RFC de retard :-) La 2338 avait été remplacée par la 3768,
 l'actuelle étant la 5798.

Bon, enfin pas si en retard que ça, quand tu vois que la RFC 5798 est signée 
par un gars d'Ericsson (ex-Redback) en 2010 et que leurs produits en 2012 font 
référence à la 2338...
Une RFC pas implémentée, ça reste virtuel :)


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

Re: [FRnOG] [TECH] Cohabition HSRP + VRRP

[Olivier Benghozi]

Bonjour,

 L'IP virtuelle est associée à l'adresse MAC hébergeant l'interface et

La RFC dit exactement le contraire.



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

Re: [FRnOG] [TECH] MP-BGP/Flowspec + ExaBGP

[Olivier Benghozi]

Frédéric Gabut de Neo Telecoms avait fait une présentation sur le sujet au 
dernier FRNOG, version Arbor+Juniper, par exemple. Mais les slides ne sont pas 
(encore) en ligne :P

Le 7 mars 2012 à 01:39, Greg VILLAIN a écrit :

 Howdy,
 Je debarque surement, mais je viens de lire des trucs sur Flowspec, ca a 
 l'air assez sympa... 
 http://www.slideshare.net/sfouant/an-introduction-to-bgp-flow-spec
 J'avais meme pas vu que c'etait RFC-ise. 
 Je sais pas si le sujet a deja ete couvert ici, mais ca coute rien d'en 
 parler. 
 Qui plus est, speciale casse-dedi a Thomas pour son 
 http://code.google.com/p/exabgp/ - j'ai presque eu envie de me relogguer sur 
 un brouteur. (non, j'deconne...)
 Paix et robustesse.


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

Re: [FRnOG] [TECH] MP-BGP/Flowspec + ExaBGP

[Olivier Benghozi]

Exactement.
C'était un message subliminal pour Philippe au sujet de www.frnog.org :)

Le 7 mars 2012 à 16:28, Jean Barbezat a écrit :

 this one : http://thomas.mangin.com/data/pdf/fgabut-flowspec-frnog-final.pdf ?
 
 2012/3/7 Olivier Benghozi olivier.bengh...@wifirst.fr:
 Frédéric Gabut de Neo Telecoms avait fait une présentation sur le sujet au 
 dernier FRNOG, version Arbor+Juniper, par exemple. Mais les slides ne sont 
 pas (encore) en ligne :P
 
 Le 7 mars 2012 à 01:39, Greg VILLAIN a écrit :
 
 Howdy,
 Je debarque surement, mais je viens de lire des trucs sur Flowspec, ca a 
 l'air assez sympa...
 http://www.slideshare.net/sfouant/an-introduction-to-bgp-flow-spec
 J'avais meme pas vu que c'etait RFC-ise.
 Je sais pas si le sujet a deja ete couvert ici, mais ca coute rien d'en 
 parler.
 Qui plus est, speciale casse-dedi a Thomas pour son 
 http://code.google.com/p/exabgp/ - j'ai presque eu envie de me relogguer 
 sur un brouteur. (non, j'deconne...)
 Paix et robustesse.


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

Re: [FRnOG] [TECH] VRRP et Quagga

[Olivier Benghozi]

Le 4 févr. 2012 à 22:30, Stephane Bortzmeyer a écrit :

 Antoine Durant antoine.duran...@yahoo.fr wrote 
 
 Faut-il activer un iBGP entre Routeur1 et Routeur2 ??
 
 Je ne comprends pas pourquoi. Si Routeur1 tombe, la session iBGP
 coupera et ce sera comme si elle n'avait pas été configurée.

Sauf que si le lien vers ISPA tombe (ou tout bêtement la session eBGP) et qu'il 
n'y a pas d'iBGP entre R1 et R2, il n'y aura plus rien du tout.
À moins de mettre une default de R1 vers R2 à la rigueur. Ou de faire du VRRP 
tracking éventuellement.
En même temps l'iBGP au sein d'un AS c'est un peu un principe de base dans ce 
contexte-là.


Olivier


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

Re: [FRnOG] [TECH] Compte à rebours des 400 000

[Olivier Benghozi]

Le 12 janv. 2012 à 06:17, Michel Py a écrit :
 Ben Carrier a écrit :
 D'après ce graphe http://bgp.potaroo.net/as6447/ il
 y a déjà plus de 400k entrées.
 
 Jérôme Nicolle a écrit:
 Dont une quantité non négligeable de /25 et plus long.
 
 Euh si j'ai bien compté c'est 97 en tout, ce qui EST négligeable.

Si on peut voir des /25 et plus longs là-dedans, c'est donc qu'on voit aussi 
des préfixes internes à cet AS de l'université de l'Orego ; par conséquent on 
compte également les /24 et plus gros strictement internes à ce réseau et non 
annoncés vers Internet.
C'est normal qu'en interne, un AS qui reçoit la full-view ait plus de routes en 
RIB que sur Internet.
Pour cet AS particulier ça m'a l'air en plus d'un bon sac de noeuds, l'univ a 
visiblement plusieurs AS publics et celui-ci n'annonce rien à l'extérieur. Note 
que pour un point d'échange ça serait légitime, mais ça n'est visiblement pas 
le cas.

-- 
Olivier


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

Re: [FRnOG] RFC 6382: Unique Per-Node Origin ASNs for Globally Anycasted Services

[Olivier Benghozi]

Les communautés BGP, c'est vrai que c'est transitif optionnel, mais c'est 
très fréquemment écrasé en entrée ou en sortie d'un AS, voire tout simplement 
pas transmis par défaut (IOS par exemple).
Du coup, pas trop utilisable pour cet usage.

Une autre possibilité serait d'avoir un AS unique prépendé un certain nombre de 
fois sur chaque site d'annonce, ce nombre identifiant le site d'origine. Mais 
ça serait crade, illisible, et rapidement limité/foireux vu que l'AS path, au 
delà de 255, ça se passe mal dans une bonne partie d'Internet. Donc non en fait 
:)



Le 25 oct. 2011 à 11:48, Stephane Bortzmeyer a écrit :

 Mais cette politique a aussi des défauts : lorsqu'un routeur BGP
 voit arriver une annonce pour un préfixe anycasté, il ne sait pas
 exactement de quel noeud elle vient. Cela peut compliquer le
 déboguage des problèmes.
 
 Une question pour les experts BGP. Pour identifier l'origine d'une
 annonce d'un service anycasté, plutôt que d'avoir un numéro d'AS par
 site, comme le propose le RFC, pourquoi ne pas ajouter une communauté
 identifiant ladite origine ?
 
 Je ne vois qu'un seul inconvénient, le risque que certaines « looking
 glasses » (par exemple la passerelle DNS de routeviews.org) affichent
 l'AS path mais pas les communautés.
 
 
 ---
 Liste de diffusion du FRnOG
 http://www.frnog.org/
 

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

Re: [FRnOG] SWITCH - question spanning-tree ports edge

[Olivier Benghozi]

Comme le fait justement remarquer Nicolas, bpdufilter en global ou par port n'a 
pas le même comportement.
Si bpdufilter par port est sauf exceptions un nid à emmerdes (puisqu'il 
équivaut à ne pas avoir de spanningtree sur le port), en global il est moins 
pire puisqu'il transmet 10 BPDU avant de filtrer. Mais il y a rarement 
d'intérêt à empêcher les clients de voir les bpdu.
bpduguard est par contre pertinent, sauf bien sûr face à un switch de blade 
center, où rootguard est la solution.

Le 23 sept. 2011 à 14:19, Damien Fleuriot a écrit :

 
 
 On 9/23/11 2:12 PM, Nicolas MICHEL wrote:
 UDLD sur du copper faut pas avoir de bol :)
 
 Pour approfondir un peu, un bpdufilter en global configuration va aussi
 te permettre de perdre ton portfast si le port reçoit un BPDU.
 BPDU gard et portfast pour moi en général :)
 
 Bon vendredi.
 
 
 Ici, portfast sur les ports access, portfast trunk sur les ports trunk
 non uplink.
 
 bpdufilter pour que les machines clientes ne voient rien, bpduguard pour
 que leur port tombe si ils font des conneries.
 
 En projet:
 - UDLD
 - DAI
 - DHCP snooping, c'est vrai que je l'avais pas mentionné mais ça serait
 vraiment une bonne idée
 
 
 Reste la question de: loopguard, intéressant ou pas, si oui sur quel
 type de port (edge, uplink) ...
 
 Sauf erreur, on ne peut pas avoir root et loop guard en même temps :/

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

Re: [FRnOG] SWITCH - question spanning-tree ports edge

[Olivier Benghozi]

Désactiver le spanning-tree sur ces ports, tu l'as déjà quasiment fait avec 
bdpu filter. Si un malcomprenant fait une boucle, le switch ne la verra pas et 
tu regretteras d'avoir placé cette commande :)
De façon générale, supprimer le spanning-tree sur les ports edge peut sembler 
une bonne idée jusqu'à ce que shit happens.

Le 23 sept. 2011 à 09:53, Damien Fleuriot a écrit :

 Hello tous,
 
 
 
 Un truc me turlupine depuis hier là.
 
 Sur nos cisco 2960, on met en place la config spanning-tree suivante
 pour les ports edge (y compris ports trunk arrivant sur des serveurs):
 
 - portfast
 - bpdu guard
 - bpdu filter
 - root guard
 
 Est-ce que finalement j'aurais pas intérêt à disable le spanning-tree
 sur mes ports edge ?
 
 Sachant que les ports non utilisés sont shutdown et dans un vlan
 suspendu, je ne vois pas de scénario catastrophe.
 
 Des avis ?
 ---
 Liste de diffusion du FRnOG
 http://www.frnog.org/
 

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

Re: [FRnOG] Re: SWITCH - question spanning-tree ports edge

[Olivier Benghozi]

Tu droppes les BPDU==ton spanning-tree actuel ne sert à rien :)
La bonne démarche est de virer cette commande pour commencer.
bpdu guard est suffisant, rootguard ne sert à rien du coup. Par contre 
attention aux blade-centers avec switch intégré: dans ce cas, pas de bpdu guard 
(sinon le port il va très vite se couper) mais rootguard à la place (et le 
rootbridge et son backup fixés en dur sur tes switches, avec priority 0 et 
4096).


Le 23 sept. 2011 à 10:33, Damien Fleuriot a écrit :

 Merci à tous pour les réponses, je vais jouer la prudence et conserver
 le STP ;)
 
 
 Concernant les ports edge, quelqu'un a une recommendation particulière
 entre root guard et loop guard ?
 
 D'un côté, on drop déjà les BPDU des ports edge alors le root guard
 c'est peut être un peu redondant.
 
 
 On 9/23/11 9:53 AM, Damien Fleuriot wrote:
 Hello tous,
 
 
 
 Un truc me turlupine depuis hier là.
 
 Sur nos cisco 2960, on met en place la config spanning-tree suivante
 pour les ports edge (y compris ports trunk arrivant sur des serveurs):
 
 - portfast
 - bpdu guard
 - bpdu filter
 - root guard
 
 Est-ce que finalement j'aurais pas intérêt à disable le spanning-tree
 sur mes ports edge ?
 
 Sachant que les ports non utilisés sont shutdown et dans un vlan
 suspendu, je ne vois pas de scénario catastrophe.
 
 Des avis ?
 ---
 Liste de diffusion du FRnOG
 http://www.frnog.org/
 

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

Re: [FRnOG] Anomalie sur AS15557 - Des infos ?

[Olivier Benghozi]

Apparemment il y a l'air d'y avoir de l'action, chez 15557: 
http://bgpupdates.potaroo.net/instability/bgpupd.html

Le 24 juin 2011 à 14:59, Renaud a écrit :

 
 
 Salut,
 
 Tu as quoi comme peer chez 15557 ? Chez nous rien d'anormal aujourd'hui.
 
 Renaud
 
 Le 24/06/2011 14:54, Jérôme Nicolle a écrit :
 
 Bonjour,
 
 J'ai des tétrachiées de bad magic number in chunk header sur les
 traces BGP de tous les cisco peerant avec 15557 depuis ce matin. Des
 anomalies du genre ont été constatées depuis le début de semaine, par
 période. Quelqu'un a une idée de ce qu'il se passe, et du temps que ça
 pourrait mettre à se stabiliser ?
 
 Merci !
 
 
 ---
 Liste de diffusion du FRnOG
 http://www.frnog.org/
 

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

Re: [FRnOG] Question sur l'option continue dans les route-map Cisco sur de l'outbound

[Olivier Benghozi]

T'as répondu toi-même à ta question: la doc parle de 12.4T, et tu indiques que 
tu tournes une 12.4.

Le 15 déc. 2010 à 13:05, Baptiste Malguy a écrit :

 Bonjour,
 
 J'ai une question bassement technique pour laquelle je me sens très con ce 
 matin : est-ce qu'une instruction continue dans une route-map utilisée en 
 outbound fonctionne _vraiment_ sur du Cisco ? Contexte du test: 7200 NPE-G1 
 avec un 12.4(21). A appliquer aussi sur des sup720 3BXL (mais pas encore 
 testé).
 
 Ca marche très bien sur une route-map en inbound, mais sur de l'outbound, 
 comme si l'instruction continue était absente.
 
 J'ai lu différentes remarques sur le net comme quoi ça marche/ça marche pas 
 selon les versions d'IOS. D'après ce lien, ça devrait être bon :
 http://www.cisco.com/en/US/docs/ios/12_4t/12_4t4/t_bgprco.html, mais non.
 
 Bref, dans la vraie vie, ça donne quoi ?
 
 PS : tout troll concernant un meilleur support des route-map chez d'autres 
 constructeurs restera sagement à la porte, et se consolera avec ses confrères 
 dehors ;-)
 
 -- 
 Baptiste MALGUY - www.malguy.net
 PGP fingerprint: 49B0 4F6E 4AA8 B149 B2DF  9267 0F65 6C1C C473 6EC2

Re: [FRnOG] mode de connexion multiplay

[Olivier Benghozi]

Normal, il n'y a pas d'Ethernet v6 :)
Ce qui est documenté c'est le NCP qui sert à faire passer de l'IPv6 dans du 
PPP, à savoir l'IPV6CP, ainsi que ce qui permet de donner une adresse publique 
au client, un DNS, etc (RS/RA, DHCPv6...).


Le 28 oct. 2010 à 21:29, Jacques VUVANT Gmail a écrit :

 En somme, le PPPoX a encore de beau jours devant lui.
 et le PPPoEv6 ? j'en ai pas beaucoup trouvé de documentation sur le net..
 
 Jacques
 
 -Message d'origine- From: Antoine Versini
 Sent: Friday, October 29, 2010 3:47 AM
 To: frnog@frnog.org
 Subject: Re: [FRnOG] mode de connexion multiplay
 
 On 10/28/10 17:31, Refuznikster wrote:
 On utilise encore une authentification chez le particulier en france
 pour l'adsl ?
 
 Oui, tout ce qui est produit sur des collectes type option 5 nécessite
 une authentification, ne serait-ce que pour les BAS des opérateurs de
 boucle locale qui doivent déterminer vers quel FAI faire suivre la
 requête car il leur faut obtenir le point de terminaison de la session.

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

Re: [FRnOG] trafic PANAP

[Olivier Benghozi]

En effet, rien de tel qu'un changement de communauté SNMP...
Il y a toujours dans les 80Gb/s.



Olivier Benghozi


Le 20 mai 2010 à 11:45, Yann Beulque a écrit :

 Il y a apparemment un souci sur le graph, ou sur panap ??
 
 Graph sur 1 mois : http://www.panap.fr/images/panap-aggregate-month.png
 Graph sur 1 semaine : http://www.panap.fr/images/panap-aggregate-week.png
 
 Yann Beulque
 
 
 Le 20 mai 2010 10:22, marc celier marc.cel...@gmx.fr a écrit :
 La courbe de trafic est a 2Gig environ, j'ai l'impression que l'appli graphe 
 ne fonctionne pas.
 
 
 http://www.panap.fr/
 
 quelqu'un a t'il une idée de la quantite de trafic au Panap.
 
 
 Merci.
 ---
 Liste de diffusion du FRnOG
 http://www.frnog.org/