date:20170809

Re: [FRnOG] [TECH] Souci de configuration d’IP de management sur un chassis virtuel d’EX2200

2017-08-09 Par sujet Guillaume Barrot

"Ceci étant dit mon proTIPS du jour => Ne pas utiliser ces maudites
interfaces de management.

Utilise une @IP dans un vlan inband pour le management courant, et paye toi
le (non)-luxe de câbler tes ports serial sur un switch console, lui même
connecté sur un réseau OOB en cas de gros crash."

+1.
Avoir une console OOBM n'est pas un luxe, c'est du bon sens, à moins de
vivre à moins de 5m du stack de switch, et de ne pas avoir de production
H24 dessus (genre du lab quoi). Sinon, console obligatoire car quand le VC
torche, c'est quasiment le seul moyen de réparer vite.
Et je précise que ce n'est pas lié à Juniper, tous les technos de stack
sont équivalentes là dessus (coucou le VSS de Cisco ...)

Le 8 août 2017 à 21:52, Raphael Mazelier  a écrit :

> Bonsoir,
>
> Ce que tu souhaites faire n'est pas possible à ma connaissance.
>
> L'option master-only n'est à priori pas compatible avec le virtual-chassis
> des EX. Elle fonctionne sur du cluster SRX, ou du MX avec dual-RE.
>
> Sur EX tu peux avoir une @IP flottante entre tous les membres de ton VC
> via l'interface vme. Elle regroupe toutes les me du VC et ne répond que sur
> le switch qui est master (et donc possède la RE-master).
>
> Tu ne peux pas mixer vme et me ; aka mettre une @IP sur vme.0 et une autre
> @IP sur me.0.
>
> Tu peux en revanche configurer une @IP différente par membre de switch sur
> chaque me0. Voir la KB15556. Ceci étant de souvenir tu arriveras quoi qu'il
> arrive sur la RE-master. Ce qui n'est pas illogique car Juniper considère
> que tant que le VC est consistant tu as une seule entité à manager.
>
> Ceci étant dit mon proTIPS du jour => Ne pas utiliser ces maudites
> interfaces de management.
>
> Utilise une @IP dans un vlan inband pour le management courant, et paye
> toi le (non)-luxe de câbler tes ports serial sur un switch console, lui
> même connecté sur un réseau OOB en cas de gros crash.
>
> Cela t'évitera quelques incidents sympas (j'ai expérimenté et bien
> d'autres aussi). Ou si tu tiens vraiment à utiliser ces interfaces prend
> bien garde à les brancher sur un réseau très maîtrisé ; une interface L3
> par exemple :)
>
> Je suis assez critique de Juniper (mais les autres ne font guère mieux)
> sur ce point. Le design des ces interfaces (me, fxp0 ou autre) a toujours
> été broken. Il serait bien plus intéressant d'avoir un vrai module de
> management indépendant de l’équipement réseau (ala ILO/Drac par exemple).
>
>
>
> --
> Raphael Mazelier
>
>
> On 07/08/2017 17:14, Alarig Le Lay wrote:
>
>> Bonjour,
>>
>> J’ai un VC avec deux EX2200 en JunOS 15.1R5.5 : sw-junip-ex2200-01 et
>> sw-junip-ex2200-02
>> Mon but est d’avoir une IP par EX pour accéder à chaque membre même en
>> cas de
>> coupure du lien de VC et une IP globale pour administrer le cluster.
>>
>> Le plan est très simple :
>> 172.16.0.1/24   sw-junip-ex2200-01
>> 172.16.0.2/24   sw-junip-ex2200-02
>> 172.16.0.3/24   cluster
>>
>> Pour configurer les IPs de chaque membre, j’ai utilisé les groupes :
>> alarig@sw-junip-ex2200-01# show groups
>> member0 {
>> when {
>> member member0;
>> }
>> interfaces {
>> me0 {
>> unit 22 {
>> family inet {
>> address 172.16.0.1/24;
>> }
>> }
>> }
>> }
>> }
>> member1 {
>> when {
>> member member1;
>> }
>> interfaces {
>> me0 {
>> unit 22 {
>> family inet {
>> address 172.16.0.2/24;
>> }
>> }
>> }
>> }
>> }
>> alarig@sw-junip-ex2200-01# show apply-groups
>> apply-groups [ member1 member0 ];
>>
>> Et pour l’IP de management du cluster, je l’ai mise en master-only
>> directement
>> sur l’interface :
>> alarig@sw-junip-ex2200-01# show interfaces me0
>> vlan-tagging;
>> unit 0 {
>> vlan-id 0;
>> family inet;
>> }
>> unit 22 {
>> vlan-id 22;
>> family inet {
>> address 172.16.0.3/24 {
>> master-only;
>> }
>> }
>> }
>>
>> Mes IPs dans la configuration 'groups' sont bien prises en compte car
>> cela se
>> voit si je | display inheritance :
>> alarig@sw-junip-ex2200-01# show interfaces me0 | display inheritance
>> vlan-tagging;
>> unit 0 {
>> vlan-id 0;
>> family inet;
>> }
>> unit 22 {
>> vlan-id 22;
>> family inet {
>> address 172.16.0.3/24 {
>> master-only;
>> }
>> ##
>> ## '172.16.0.1/24' was inherited from group 'member0'
>> ##
>> address 172.16.0.1/24;
>> }
>> }
>>
>> Seulement, avec cette configuration je n’ai que 172.16.0.1 qui répond.
>> Savez-vous d’où cela peut venir ?
>>
>> Merci pour vos conseils,
>>
>>
>
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/
>



-- 
Cordialement,

Guillaume BARROT

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

Re: [FRnOG] [MISC] bloc d'IP à céder

2017-08-09 Par sujet David Ponzone

C’est vrai que ça tourne un peu en rond le débat.
Et pour rappel, le RIPE (par décision des membres suite à un débat houleux) a 
décidé de laisser la possibilité à une entité juridique d’ouvrir de multiples 
LIR et de récupérer un /22 à chaque fois.
A priori, dans le monde libre, quand on est pas d’accord avec le choix de 
majorité, on se tait et on attend le prochain vote (et éventuellement on anime 
le débat/lobbying d’ici là).

Sur la monétisation des IP, le RIPE le fait de toute façon, en permettant 
d’avoir un autre /22 pour 1800€/an.
Donc si un mec est pressé ou surtout s’il a besoin de plus, il va faire ses 
courses ailleurs.
De plus, l’augmentation du prix de l’IP sur ce marché « gris » est probablement 
la meilleure incentive qu’on puisse imaginer pour pousser  les ISP à migrer en 
v6.

> Le 10 août 2017 à 13:43, Michel Py  a 
> écrit :
> 
>> Josselin Lecocq a écrit :
>> C'est quand même un beau scandale le trading d'IPv4... Je sais qu'on est pas 
>> vendredi, mais il faudrait que plusieurs
>> opés se regroupent et commencent à annoncer via BGP les inetnum transférés 
>> selon des méthodes mafieuses, afin de les
>> rendre inutilisables, puisque le RIPE a cessé de faire son job. Je suis 
>> assez curieux des conséquences légales,
>> étant entendu que nul ne peut prétendre à être propriétaire de ces 
>> ressources. Ce ne sont que des numéros ! Vous
>> achetez à prix d'or le droit d'utiliser des vulgaires numéros... Autre 
>> chose, pourquoi payer de tels tarifs alors
>> qu'on peut se contenter de créer des LIR à la volée et obtenir à chaque fois 
>> un /22 ? Je sais qu'il faut attendre 2
>> ans avant de pouvoir faire un transfert, mais même au bout de cette durée, 
>> l'opération n'est-elle pas plus rentable ?
>> Bref, il est vraiment temps que tout le monde se sorte les doigts du c*l et 
>> qu'on passe tous en IPv6...
> 
> Ben justement c'est pas trolldi et le troll de la liste du FRnOG c'est moi, 
> et je suis fatigué de lire ce genre de connerie pendant la semaine.
> 
> Philippe, merci de blacklister ce troll. Il y a des limites à la connerie; 
> RIPE est une organisation mafieuse, tout le monde le sait, ARIN aussi, 
> d'ailleurs.
> 
> C'est pas l'Internet des bisounours, ici. Les connards qui se plaignent que 
> "life is not fair", on en à rien à foutre ni à perdre le temps de lire leurs 
> conneries que certains d'entre nous, y compris moi, ont écrit il y a 20 ans. 
> Le troll de "IPv6 c'est pour l'année prochaine", on a déjà donné au bureau 
> depuis 20 ans.
> 
> 
> Michel.
> 
> 
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/


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

RE: [FRnOG] [MISC] bloc d'IP à céder

2017-08-09 Par sujet Michel Py

> Josselin Lecocq a écrit :
> C'est quand même un beau scandale le trading d'IPv4... Je sais qu'on est pas 
> vendredi, mais il faudrait que plusieurs
> opés se regroupent et commencent à annoncer via BGP les inetnum transférés 
> selon des méthodes mafieuses, afin de les
> rendre inutilisables, puisque le RIPE a cessé de faire son job. Je suis assez 
> curieux des conséquences légales,
>  étant entendu que nul ne peut prétendre à être propriétaire de ces 
> ressources. Ce ne sont que des numéros ! Vous
> achetez à prix d'or le droit d'utiliser des vulgaires numéros... Autre chose, 
> pourquoi payer de tels tarifs alors
>  qu'on peut se contenter de créer des LIR à la volée et obtenir à chaque fois 
> un /22 ? Je sais qu'il faut attendre 2
>  ans avant de pouvoir faire un transfert, mais même au bout de cette durée, 
> l'opération n'est-elle pas plus rentable ?
>  Bref, il est vraiment temps que tout le monde se sorte les doigts du c*l et 
> qu'on passe tous en IPv6...

Ben justement c'est pas trolldi et le troll de la liste du FRnOG c'est moi, et 
je suis fatigué de lire ce genre de connerie pendant la semaine.

Philippe, merci de blacklister ce troll. Il y a des limites à la connerie; RIPE 
est une organisation mafieuse, tout le monde le sait, ARIN aussi, d'ailleurs.

C'est pas l'Internet des bisounours, ici. Les connards qui se plaignent que 
"life is not fair", on en à rien à foutre ni à perdre le temps de lire leurs 
conneries que certains d'entre nous, y compris moi, ont écrit il y a 20 ans. Le 
troll de "IPv6 c'est pour l'année prochaine", on a déjà donné au bureau depuis 
20 ans.


Michel.


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

Re: [FRnOG] [TECH] Boucle de routage chez Free

2017-08-09 Par sujet Erik LE VACON

Bonjour,

Même constat depuis une freebox fibré à Paris intra-muros. Ce n'est donc pas 
local.

On Wed, 9 Aug 2017 11:32:11 +0200
Yoann Gini  wrote:

> Salut la liste
> 
> Ça fait un sacré moment que j’ai pas posté ici.
> 
> Si des gens de Free sont dans le coin, on dirait bien que vous avez une 
> boucle de routage :
> 
> 11:08 % traceroute community.ubnt.com   
> traceroute to ubnt.lithium.com (208.74.207.27), 64 hops max, 52 byte packets
> 1  192.168.72.1 (192.168.72.1)  2.547 ms  2.082 ms  6.342 ms
> 2  gns13-1-88-122-221-254.fbx.proxad.net (88.122.221.254)  6.159 ms  5.677 ms 
>  5.749 ms
> 3  213.228.33.62 (213.228.33.62)  9.498 ms  7.640 ms  7.208 ms
> 4  marseille-6k-1-v806.intf.routers.proxad.net (212.27.51.117)  8.621 ms  
> 7.313 ms  7.955 ms
> 5  marseille-crs8-2-be1000.intf.routers.proxad.net (78.254.249.170)  9.750 ms 
>  9.607 ms  7.997 ms
> 6  p11-crs16-1-be1104.intf.routers.proxad.net (194.149.160.109)  17.741 ms  
> 19.721 ms  20.279 ms
> 7  bzn-9k-4-be1004.intf.routers.proxad.net (78.254.249.2)  17.965 ms  17.953 
> ms  17.876 ms
> 8  p11-crs16-1-be1000.intf.routers.proxad.net (78.254.249.1)  22.839 ms  
> 23.822 ms  23.110 ms
> 9  bzn-9k-4-be1004.intf.routers.proxad.net (78.254.249.2)  20.628 ms  18.947 
> ms  18.664 ms
> 10  p11-crs16-1-be1000.intf.routers.proxad.net (78.254.249.1)  19.976 ms  
> 24.859 ms  24.101 ms
> 11  bzn-9k-4-be1004.intf.routers.proxad.net (78.254.249.2)  19.856 ms  21.244 
> ms  19.278 ms
> 12  p11-crs16-1-be1000.intf.routers.proxad.net (78.254.249.1)  25.042 ms  
> 23.694 ms  25.044 ms
> 13  bzn-9k-4-be1004.intf.routers.proxad.net (78.254.249.2)  20.650 ms  19.009 
> ms  22.353 ms
> 14  p11-crs16-1-be1000.intf.routers.proxad.net (78.254.249.1)  23.984 ms  
> 23.177 ms  24.617 ms
> 15  bzn-9k-4-be1004.intf.routers.proxad.net (78.254.249.2)  21.874 ms  21.243 
> ms  19.886 ms
> 16  p11-crs16-1-be1000.intf.routers.proxad.net (78.254.249.1)  24.927 ms  
> 23.344 ms  23.068 ms
> 17  bzn-9k-4-be1004.intf.routers.proxad.net (78.254.249.2)  22.551 ms  20.594 
> ms  21.819 ms
> 18  p11-crs16-1-be1000.intf.routers.proxad.net (78.254.249.1)  21.109 ms  
> 23.774 ms  24.283 ms
> 19  bzn-9k-4-be1004.intf.routers.proxad.net (78.254.249.2)  21.330 ms  22.648 
> ms  20.576 ms
> 20  p11-crs16-1-be1000.intf.routers.proxad.net (78.254.249.1)  29.488 ms  
> 22.731 ms  25.217 ms
> 21  bzn-9k-4-be1004.intf.routers.proxad.net (78.254.249.2)  22.856 ms  21.562 
> ms  21.477 ms
> 22  p11-crs16-1-be1000.intf.routers.proxad.net (78.254.249.1)  21.225 ms  
> 23.216 ms  22.879 ms
> 23  bzn-9k-4-be1004.intf.routers.proxad.net (78.254.249.2)  22.329 ms  23.512 
> ms  21.795 ms
> 24  p11-crs16-1-be1000.intf.routers.proxad.net (78.254.249.1)  28.117 ms  
> 24.574 ms  29.357 ms
> 25  bzn-9k-4-be1004.intf.routers.proxad.net (78.254.249.2)  22.233 ms  23.041 
> ms  23.991 ms
> 26  p11-crs16-1-be1000.intf.routers.proxad.net (78.254.249.1)  25.561 ms  
> 24.446 ms  24.513 ms
> 27  bzn-9k-4-be1004.intf.routers.proxad.net (78.254.249.2)  22.758 ms  22.693 
> ms  27.851 ms
> 28  p11-crs16-1-be1000.intf.routers.proxad.net (78.254.249.1)  31.784 ms  
> 27.828 ms  24.811 ms
> 29  bzn-9k-4-be1004.intf.routers.proxad.net (78.254.249.2)  23.421 ms  23.260 
> ms  25.871 ms
> 30  p11-crs16-1-be1000.intf.routers.proxad.net (78.254.249.1)  30.191 ms  
> 30.455 ms  26.118 ms
> 31  bzn-9k-4-be1004.intf.routers.proxad.net (78.254.249.2)  23.985 ms  24.525 
> ms  27.055 ms
> 32  p11-crs16-1-be1000.intf.routers.proxad.net (78.254.249.1)  33.479 ms  
> 30.765 ms  24.101 ms
> 33  bzn-9k-4-be1004.intf.routers.proxad.net (78.254.249.2)  26.122 ms  24.954 
> ms  24.705 ms
> 34  p11-crs16-1-be1000.intf.routers.proxad.net (78.254.249.1)  27.571 ms  
> 30.398 ms  25.849 ms
> 35  bzn-9k-4-be1004.intf.routers.proxad.net (78.254.249.2)  25.176 ms  25.783 
> ms  25.290 ms
> 36  p11-crs16-1-be1000.intf.routers.proxad.net (78.254.249.1)  26.148 ms  
> 31.318 ms  24.943 ms
> 37  bzn-9k-4-be1004.intf.routers.proxad.net (78.254.249.2)  24.750 ms  25.464 
> ms  25.112 ms
> 38  p11-crs16-1-be1000.intf.routers.proxad.net (78.254.249.1)  28.020 ms  
> 30.092 ms  25.317 ms
> 39  bzn-9k-4-be1004.intf.routers.proxad.net (78.254.249.2)  25.031 ms  26.330 
> ms  25.588 ms
> 40  p11-crs16-1-be1000.intf.routers.proxad.net (78.254.249.1)  25.580 ms  
> 29.971 ms  32.891 ms
> 41  bzn-9k-4-be1004.intf.routers.proxad.net (78.254.249.2)  25.776 ms  27.241 
> ms  26.563 ms
> 42  p11-crs16-1-be1000.intf.routers.proxad.net (78.254.249.1)  31.939 ms  
> 28.811 ms  32.688 ms
> 43  bzn-9k-4-be1004.intf.routers.proxad.net (78.254.249.2)  26.299 ms  25.824 
> ms  26.010 ms
> 44  p11-crs16-1-be1000.intf.routers.proxad.net (78.254.249.1)  33.424 ms  
> 30.990 ms  31.167 ms
> 45  bzn-9k-4-be1004.intf.routers.proxad.net (78.254.249.2)  28.013 ms  26.853 
> ms  27.196 ms
> 46  p11-crs16-1-be1000.intf.routers.proxad.net (78.254.249.1)  30.694 ms  
> 29.900 ms  33.605 ms
> 47  bzn-9k-4-be1004.intf.routers.proxad.net (78.254.249.2)

Re: [FRnOG] [BIZ] bloc d'IP à céder

2017-08-09 Par sujet Sébastien Lesimple

Pas de quoi s’offusquer, c'est la loi de l'offre et la demande.
Ressource "rare" = tarif en proportion de la rareté et de l'importance
de la demande.

Le RIPE a crée le IPv4 Transfer Listing Service

justement pour limiter la "bordélisation" du marché de la ressource, et
en cela il fait sont job de gestionnaire.
Le prix fixé de gré à gré répondant à un besoin, le RIPE laisse le
marché s'organiser lui-même, là encore il n'a pas a encadrer les prix,
ce n'est pas son role.

Bref, vulgaires numéros certes mais vu le nombre d'AS v4 Only, ils ont
encore de beaux jours devant eux...

Seb.


On 09/08/2017 11:00, Josselin Lecocq wrote:
> C'est quand même un beau scandale le trading d'IPv4...
>
> Je sais qu'on est pas vendredi, mais il faudrait que plusieurs opés se
> regroupent et commencent à annoncer via BGP les inetnum transférés selon
> des méthodes mafieuses, afin de les rendre inutilisables, puisque le
> RIPE a cessé de faire son job. Je suis assez curieux des conséquences
> légales, étant entendu que nul ne peut prétendre à être propriétaire de
> ces ressources. Ce ne sont que des numéros ! Vous achetez à prix d'or le
> droit d'utiliser des vulgaires numéros...
>
> Autre chose, pourquoi payer de tels tarifs alors qu'on peut se contenter
> de créer des LIR à la volée et obtenir à chaque fois un /22 ? Je sais
> qu'il faut attendre 2 ans avant de pouvoir faire un transfert, mais même
> au bout de cette durée, l'opération n'est-elle pas plus rentable ?
>
> Bref, il est vraiment temps que tout le monde se sorte les doigts du c*l
> et qu'on passe tous en IPv6...
>
>
> Josselin Lecocq
> Quantic Telecom
>
>
>
> Le 09/08/2017 à 10:42, David Ponzone a écrit :
>> Laurent.
>>
>> Il me semble quand même que quand tu achètes un /21, tu n'as pas le même 
>> prix par IP que quand tu achètes un /16.
>>
>>
>> David Ponzone
>>
>>
>>
>>> Le 9 août 2017 à 02:09, Laurent Seror  a écrit :
>>>
>>> Hello,
>>>
>>> On utilise Kamorama pour nos "achats" d'ips. Voici leur analyse du marché
>>> en tant que broker, que je trouve intéressant de partager avec vous dans ce
>>> thread.
>>>
>>> <<
>>> We are most frequently asked the question, what are IPv4 addresses selling
>>> for?
>>>
>>> A Class B, which is the most common block size that Kalorama deals with,
>>> has appreciated 20-30% in the last 60 days with buyers and sellers meeting
>>> in the range of $12 to $14 an address.  Outliers exist, but the majority of
>>> buy/sell interest is in this price zone.  As we see new Class B supply
>>> continuing to enter the transfer market, we don¹t expect additional price
>>> increases in 2017.
>>>
>>> Larger blocks, which are significantly scarcer, are currently getting
>>> attention above $15 per address.  Assuming under-utilized large blocks will
>>> continue to be brought to market in order to cash in on the value while
>>> it¹s there, we believe larger blocks, such as /10s and /12s, could peak in
>>> price between $17 and $22 within the next 6-9 months.  Our outlook is that
>>> large, contiguous blocks from the private sector may no longer be available
>>> in the transfer market some time in 2018.
>>> Un /21 "propre" vaut environ 25000$ pas 40k$
>>>
>>> Et cela avec la marge du broker incluse.
>>>
>>> L.
>>>
>>> Le mar. 8 août 2017 à 18:01, Michel Py 
>>> a écrit :
>>>
> Xavier Beaudouin a écrit :
> Disons ... que bon le fait que l'espace legacy (aka IPv4) étant arrivé a
 saturation, toutes les bidouilles
> de l'humanité pour rester sur ce genre de techno legacy a son reflet au
 niveau du RIPE.
> Voila, je sais que ça ne fait pas avancer le smilblick mais c'est un
 fait (désolant certes, mais vrai).

 C'est la même chose chez ARIN... Dans tout les cas on savait depuis
 longtemps qu'il y aurait un marché noir des IPv4, donc autant en faire un
 marché gris et le controller.

 Michel.


 ---
 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] Boucle de routage chez Free

2017-08-09 Par sujet Erik LE VACON

A priori c'est dans leur DC à Bezons que ca se passe.
Sur test rapide, ca impacte la route vers 208.74.207.X

On Wed, 9 Aug 2017 11:37:11 +0200
Erik LE VACON  wrote:

> Bonjour,
> 
> Même constat depuis une freebox fibré à Paris intra-muros. Ce n'est donc pas 
> local.
> 
> On Wed, 9 Aug 2017 11:32:11 +0200
> Yoann Gini  wrote:
> 
> > Salut la liste
> > 
> > Ça fait un sacré moment que j’ai pas posté ici.
> > 
> > Si des gens de Free sont dans le coin, on dirait bien que vous avez une 
> > boucle de routage :
> > 
> > 11:08 % traceroute community.ubnt.com   
> > traceroute to ubnt.lithium.com (208.74.207.27), 64 hops max, 52 byte packets
> > 1  192.168.72.1 (192.168.72.1)  2.547 ms  2.082 ms  6.342 ms
> > 2  gns13-1-88-122-221-254.fbx.proxad.net (88.122.221.254)  6.159 ms  5.677 
> > ms  5.749 ms
> > 3  213.228.33.62 (213.228.33.62)  9.498 ms  7.640 ms  7.208 ms
> > 4  marseille-6k-1-v806.intf.routers.proxad.net (212.27.51.117)  8.621 ms  
> > 7.313 ms  7.955 ms
> > 5  marseille-crs8-2-be1000.intf.routers.proxad.net (78.254.249.170)  9.750 
> > ms  9.607 ms  7.997 ms
> > 6  p11-crs16-1-be1104.intf.routers.proxad.net (194.149.160.109)  17.741 ms  
> > 19.721 ms  20.279 ms
> > 7  bzn-9k-4-be1004.intf.routers.proxad.net (78.254.249.2)  17.965 ms  
> > 17.953 ms  17.876 ms
> > 8  p11-crs16-1-be1000.intf.routers.proxad.net (78.254.249.1)  22.839 ms  
> > 23.822 ms  23.110 ms
> > 9  bzn-9k-4-be1004.intf.routers.proxad.net (78.254.249.2)  20.628 ms  
> > 18.947 ms  18.664 ms
> > 10  p11-crs16-1-be1000.intf.routers.proxad.net (78.254.249.1)  19.976 ms  
> > 24.859 ms  24.101 ms
> > 11  bzn-9k-4-be1004.intf.routers.proxad.net (78.254.249.2)  19.856 ms  
> > 21.244 ms  19.278 ms
> > 12  p11-crs16-1-be1000.intf.routers.proxad.net (78.254.249.1)  25.042 ms  
> > 23.694 ms  25.044 ms
> > 13  bzn-9k-4-be1004.intf.routers.proxad.net (78.254.249.2)  20.650 ms  
> > 19.009 ms  22.353 ms
> > 14  p11-crs16-1-be1000.intf.routers.proxad.net (78.254.249.1)  23.984 ms  
> > 23.177 ms  24.617 ms
> > 15  bzn-9k-4-be1004.intf.routers.proxad.net (78.254.249.2)  21.874 ms  
> > 21.243 ms  19.886 ms
> > 16  p11-crs16-1-be1000.intf.routers.proxad.net (78.254.249.1)  24.927 ms  
> > 23.344 ms  23.068 ms
> > 17  bzn-9k-4-be1004.intf.routers.proxad.net (78.254.249.2)  22.551 ms  
> > 20.594 ms  21.819 ms
> > 18  p11-crs16-1-be1000.intf.routers.proxad.net (78.254.249.1)  21.109 ms  
> > 23.774 ms  24.283 ms
> > 19  bzn-9k-4-be1004.intf.routers.proxad.net (78.254.249.2)  21.330 ms  
> > 22.648 ms  20.576 ms
> > 20  p11-crs16-1-be1000.intf.routers.proxad.net (78.254.249.1)  29.488 ms  
> > 22.731 ms  25.217 ms
> > 21  bzn-9k-4-be1004.intf.routers.proxad.net (78.254.249.2)  22.856 ms  
> > 21.562 ms  21.477 ms
> > 22  p11-crs16-1-be1000.intf.routers.proxad.net (78.254.249.1)  21.225 ms  
> > 23.216 ms  22.879 ms
> > 23  bzn-9k-4-be1004.intf.routers.proxad.net (78.254.249.2)  22.329 ms  
> > 23.512 ms  21.795 ms
> > 24  p11-crs16-1-be1000.intf.routers.proxad.net (78.254.249.1)  28.117 ms  
> > 24.574 ms  29.357 ms
> > 25  bzn-9k-4-be1004.intf.routers.proxad.net (78.254.249.2)  22.233 ms  
> > 23.041 ms  23.991 ms
> > 26  p11-crs16-1-be1000.intf.routers.proxad.net (78.254.249.1)  25.561 ms  
> > 24.446 ms  24.513 ms
> > 27  bzn-9k-4-be1004.intf.routers.proxad.net (78.254.249.2)  22.758 ms  
> > 22.693 ms  27.851 ms
> > 28  p11-crs16-1-be1000.intf.routers.proxad.net (78.254.249.1)  31.784 ms  
> > 27.828 ms  24.811 ms
> > 29  bzn-9k-4-be1004.intf.routers.proxad.net (78.254.249.2)  23.421 ms  
> > 23.260 ms  25.871 ms
> > 30  p11-crs16-1-be1000.intf.routers.proxad.net (78.254.249.1)  30.191 ms  
> > 30.455 ms  26.118 ms
> > 31  bzn-9k-4-be1004.intf.routers.proxad.net (78.254.249.2)  23.985 ms  
> > 24.525 ms  27.055 ms
> > 32  p11-crs16-1-be1000.intf.routers.proxad.net (78.254.249.1)  33.479 ms  
> > 30.765 ms  24.101 ms
> > 33  bzn-9k-4-be1004.intf.routers.proxad.net (78.254.249.2)  26.122 ms  
> > 24.954 ms  24.705 ms
> > 34  p11-crs16-1-be1000.intf.routers.proxad.net (78.254.249.1)  27.571 ms  
> > 30.398 ms  25.849 ms
> > 35  bzn-9k-4-be1004.intf.routers.proxad.net (78.254.249.2)  25.176 ms  
> > 25.783 ms  25.290 ms
> > 36  p11-crs16-1-be1000.intf.routers.proxad.net (78.254.249.1)  26.148 ms  
> > 31.318 ms  24.943 ms
> > 37  bzn-9k-4-be1004.intf.routers.proxad.net (78.254.249.2)  24.750 ms  
> > 25.464 ms  25.112 ms
> > 38  p11-crs16-1-be1000.intf.routers.proxad.net (78.254.249.1)  28.020 ms  
> > 30.092 ms  25.317 ms
> > 39  bzn-9k-4-be1004.intf.routers.proxad.net (78.254.249.2)  25.031 ms  
> > 26.330 ms  25.588 ms
> > 40  p11-crs16-1-be1000.intf.routers.proxad.net (78.254.249.1)  25.580 ms  
> > 29.971 ms  32.891 ms
> > 41  bzn-9k-4-be1004.intf.routers.proxad.net (78.254.249.2)  25.776 ms  
> > 27.241 ms  26.563 ms
> > 42  p11-crs16-1-be1000.intf.routers.proxad.net (78.254.249.1)  31.939 ms  
> > 28.811 ms  32.688 ms
> > 43  bzn-9k-4-be1004.intf.routers.proxad.net (78.254.249.2)  26.299 ms  
>

Re: [FRnOG] [BIZ] bloc d'IP à céder

2017-08-09 Par sujet David Ponzone

Laurent.

Il me semble quand même que quand tu achètes un /21, tu n'as pas le même prix 
par IP que quand tu achètes un /16.


David Ponzone



> Le 9 août 2017 à 02:09, Laurent Seror  a écrit :
> 
> Hello,
> 
> On utilise Kamorama pour nos "achats" d'ips. Voici leur analyse du marché
> en tant que broker, que je trouve intéressant de partager avec vous dans ce
> thread.
> 
> <<
> We are most frequently asked the question, what are IPv4 addresses selling
> for?
> 
> A Class B, which is the most common block size that Kalorama deals with,
> has appreciated 20-30% in the last 60 days with buyers and sellers meeting
> in the range of $12 to $14 an address.  Outliers exist, but the majority of
> buy/sell interest is in this price zone.  As we see new Class B supply
> continuing to enter the transfer market, we don¹t expect additional price
> increases in 2017.
> 
> Larger blocks, which are significantly scarcer, are currently getting
> attention above $15 per address.  Assuming under-utilized large blocks will
> continue to be brought to market in order to cash in on the value while
> it¹s there, we believe larger blocks, such as /10s and /12s, could peak in
> price between $17 and $22 within the next 6-9 months.  Our outlook is that
> large, contiguous blocks from the private sector may no longer be available
> in the transfer market some time in 2018.
>>> 
> 
> Un /21 "propre" vaut environ 25000$ pas 40k$
> 
> Et cela avec la marge du broker incluse.
> 
> L.
> 
> Le mar. 8 août 2017 à 18:01, Michel Py 
> a écrit :
> 
>>> Xavier Beaudouin a écrit :
>>> Disons ... que bon le fait que l'espace legacy (aka IPv4) étant arrivé a
>> saturation, toutes les bidouilles
>>> de l'humanité pour rester sur ce genre de techno legacy a son reflet au
>> niveau du RIPE.
>>> Voila, je sais que ça ne fait pas avancer le smilblick mais c'est un
>> fait (désolant certes, mais vrai).
>> 
>> C'est la même chose chez ARIN... Dans tout les cas on savait depuis
>> longtemps qu'il y aurait un marché noir des IPv4, donc autant en faire un
>> marché gris et le controller.
>> 
>> Michel.
>> 
>> 
>> ---
>> Liste de diffusion du FRnOG
>> http://www.frnog.org/
>> 
> 
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/


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

[FRnOG] [TECH] Boucle de routage chez Free

2017-08-09 Par sujet Yoann Gini

Salut la liste

Ça fait un sacré moment que j’ai pas posté ici.

Si des gens de Free sont dans le coin, on dirait bien que vous avez une boucle 
de routage :

11:08 % traceroute community.ubnt.com   
traceroute to ubnt.lithium.com (208.74.207.27), 64 hops max, 52 byte packets
1  192.168.72.1 (192.168.72.1)  2.547 ms  2.082 ms  6.342 ms
2  gns13-1-88-122-221-254.fbx.proxad.net (88.122.221.254)  6.159 ms  5.677 ms  
5.749 ms
3  213.228.33.62 (213.228.33.62)  9.498 ms  7.640 ms  7.208 ms
4  marseille-6k-1-v806.intf.routers.proxad.net (212.27.51.117)  8.621 ms  7.313 
ms  7.955 ms
5  marseille-crs8-2-be1000.intf.routers.proxad.net (78.254.249.170)  9.750 ms  
9.607 ms  7.997 ms
6  p11-crs16-1-be1104.intf.routers.proxad.net (194.149.160.109)  17.741 ms  
19.721 ms  20.279 ms
7  bzn-9k-4-be1004.intf.routers.proxad.net (78.254.249.2)  17.965 ms  17.953 ms 
 17.876 ms
8  p11-crs16-1-be1000.intf.routers.proxad.net (78.254.249.1)  22.839 ms  23.822 
ms  23.110 ms
9  bzn-9k-4-be1004.intf.routers.proxad.net (78.254.249.2)  20.628 ms  18.947 ms 
 18.664 ms
10  p11-crs16-1-be1000.intf.routers.proxad.net (78.254.249.1)  19.976 ms  
24.859 ms  24.101 ms
11  bzn-9k-4-be1004.intf.routers.proxad.net (78.254.249.2)  19.856 ms  21.244 
ms  19.278 ms
12  p11-crs16-1-be1000.intf.routers.proxad.net (78.254.249.1)  25.042 ms  
23.694 ms  25.044 ms
13  bzn-9k-4-be1004.intf.routers.proxad.net (78.254.249.2)  20.650 ms  19.009 
ms  22.353 ms
14  p11-crs16-1-be1000.intf.routers.proxad.net (78.254.249.1)  23.984 ms  
23.177 ms  24.617 ms
15  bzn-9k-4-be1004.intf.routers.proxad.net (78.254.249.2)  21.874 ms  21.243 
ms  19.886 ms
16  p11-crs16-1-be1000.intf.routers.proxad.net (78.254.249.1)  24.927 ms  
23.344 ms  23.068 ms
17  bzn-9k-4-be1004.intf.routers.proxad.net (78.254.249.2)  22.551 ms  20.594 
ms  21.819 ms
18  p11-crs16-1-be1000.intf.routers.proxad.net (78.254.249.1)  21.109 ms  
23.774 ms  24.283 ms
19  bzn-9k-4-be1004.intf.routers.proxad.net (78.254.249.2)  21.330 ms  22.648 
ms  20.576 ms
20  p11-crs16-1-be1000.intf.routers.proxad.net (78.254.249.1)  29.488 ms  
22.731 ms  25.217 ms
21  bzn-9k-4-be1004.intf.routers.proxad.net (78.254.249.2)  22.856 ms  21.562 
ms  21.477 ms
22  p11-crs16-1-be1000.intf.routers.proxad.net (78.254.249.1)  21.225 ms  
23.216 ms  22.879 ms
23  bzn-9k-4-be1004.intf.routers.proxad.net (78.254.249.2)  22.329 ms  23.512 
ms  21.795 ms
24  p11-crs16-1-be1000.intf.routers.proxad.net (78.254.249.1)  28.117 ms  
24.574 ms  29.357 ms
25  bzn-9k-4-be1004.intf.routers.proxad.net (78.254.249.2)  22.233 ms  23.041 
ms  23.991 ms
26  p11-crs16-1-be1000.intf.routers.proxad.net (78.254.249.1)  25.561 ms  
24.446 ms  24.513 ms
27  bzn-9k-4-be1004.intf.routers.proxad.net (78.254.249.2)  22.758 ms  22.693 
ms  27.851 ms
28  p11-crs16-1-be1000.intf.routers.proxad.net (78.254.249.1)  31.784 ms  
27.828 ms  24.811 ms
29  bzn-9k-4-be1004.intf.routers.proxad.net (78.254.249.2)  23.421 ms  23.260 
ms  25.871 ms
30  p11-crs16-1-be1000.intf.routers.proxad.net (78.254.249.1)  30.191 ms  
30.455 ms  26.118 ms
31  bzn-9k-4-be1004.intf.routers.proxad.net (78.254.249.2)  23.985 ms  24.525 
ms  27.055 ms
32  p11-crs16-1-be1000.intf.routers.proxad.net (78.254.249.1)  33.479 ms  
30.765 ms  24.101 ms
33  bzn-9k-4-be1004.intf.routers.proxad.net (78.254.249.2)  26.122 ms  24.954 
ms  24.705 ms
34  p11-crs16-1-be1000.intf.routers.proxad.net (78.254.249.1)  27.571 ms  
30.398 ms  25.849 ms
35  bzn-9k-4-be1004.intf.routers.proxad.net (78.254.249.2)  25.176 ms  25.783 
ms  25.290 ms
36  p11-crs16-1-be1000.intf.routers.proxad.net (78.254.249.1)  26.148 ms  
31.318 ms  24.943 ms
37  bzn-9k-4-be1004.intf.routers.proxad.net (78.254.249.2)  24.750 ms  25.464 
ms  25.112 ms
38  p11-crs16-1-be1000.intf.routers.proxad.net (78.254.249.1)  28.020 ms  
30.092 ms  25.317 ms
39  bzn-9k-4-be1004.intf.routers.proxad.net (78.254.249.2)  25.031 ms  26.330 
ms  25.588 ms
40  p11-crs16-1-be1000.intf.routers.proxad.net (78.254.249.1)  25.580 ms  
29.971 ms  32.891 ms
41  bzn-9k-4-be1004.intf.routers.proxad.net (78.254.249.2)  25.776 ms  27.241 
ms  26.563 ms
42  p11-crs16-1-be1000.intf.routers.proxad.net (78.254.249.1)  31.939 ms  
28.811 ms  32.688 ms
43  bzn-9k-4-be1004.intf.routers.proxad.net (78.254.249.2)  26.299 ms  25.824 
ms  26.010 ms
44  p11-crs16-1-be1000.intf.routers.proxad.net (78.254.249.1)  33.424 ms  
30.990 ms  31.167 ms
45  bzn-9k-4-be1004.intf.routers.proxad.net (78.254.249.2)  28.013 ms  26.853 
ms  27.196 ms
46  p11-crs16-1-be1000.intf.routers.proxad.net (78.254.249.1)  30.694 ms  
29.900 ms  33.605 ms
47  bzn-9k-4-be1004.intf.routers.proxad.net (78.254.249.2)  27.738 ms  29.187 
ms  27.088 ms
48  p11-crs16-1-be1000.intf.routers.proxad.net (78.254.249.1)  30.896 ms  
34.492 ms  31.424 ms
49  bzn-9k-4-be1004.intf.routers.proxad.net (78.254.249.2)  27.896 ms  27.557 
ms  28.009 ms
50  p11-crs16-1-be1000.intf.routers.proxad.net (78.254.249.1)  36.304 ms  
30.434 ms  31.510 ms
51  bzn-9k-4-be1004.intf.routers.proxad.net (78.254.249.2)

Re: [FRnOG] [BIZ] bloc d'IP à céder

2017-08-09 Par sujet Laurent Seror

Paradoxalement, un /16 est plus cher par IP qu'un /21 car les gros blocs
contigus sont beaucoup plus rares. Pareil un PI, vaudra plus cher qu'un PA
mais moins cher qu'un LEGACY. Enfin des adresses jamais annoncées sur
Internet en théorie sont un peu plus chers car "propres" (pas dans du RBL
ou un logiciel de filtrage qui demande des efforts pour deblacklister les
ips).

Je suis d'accord avec le fait que les ips devraient être données
gratuitement à ceux qui les utilisent et retirées à ceux qui les stockent
pour rien. Malheureusement, l'argent règne sur ce monde... Si les RIR
forçaient les échanges à se faire en mode gratuit, l'argent s'échangerait
sous le manteau, sous forme de prestation de conseils ou autre, et cela ne
changerait rien à la situation.

Enfin, oui, IPv6 arrive mais c'est lent et quand je vois la mémoire max
d'un routeur, je sens comme une arnaque qui guette les service providers...

L.
L.

Le mer. 9 août 2017 à 10:42, David Ponzone  a
écrit :

> Laurent.
>
> Il me semble quand même que quand tu achètes un /21, tu n'as pas le même
> prix par IP que quand tu achètes un /16.
>
>
>
>

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

Re: [FRnOG] [BIZ] bloc d'IP à céder

2017-08-09 Par sujet Francois Demeyer


> Le 9 août 2017 à 11:41, Sébastien Lesimple  
> a écrit :
> 
> Le prix fixé de gré à gré répondant à un besoin, le RIPE laisse le
> marché s'organiser lui-même, là encore il n'a pas a encadrer les prix,
> ce n'est pas son role.
> 
Ne serait-ce pas justement le concept de « marché »  appliqué a ce type de 
ressource qui pique un peu ? ;-)

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

Re: [FRnOG] [BIZ] bloc d'IP à céder

2017-08-09 Par sujet David CHANIAL

Bonjour à tous !

> On 9 Aug 2017, at 11:48, Francois Demeyer  wrote:
> Ne serait-ce pas justement le concept de « marché »  appliqué a ce type de 
> ressource qui pique un peu ? ;-)

Bien sûr que non (sauf sur un plan idéologique dans un monde aseptisé).

Je pense que sur le plan quantitatif, la majorité des IPv4 sont associés à un 
service (une connexion internet, un hébergement de site internet, un SSL, un 
serveur, une VM, …).
Le fait est que la très grande majorité de ces services est lucrative, et 
ajoute de plus en plus le coût de l’IPv4 comme un coût apparent - et à part 
entière.

C’est peut-être regrettable, mais c’est un fait.
Si l’IPv4 a un coût (direct ou indirect) pour son utilisateur final, et qu’il 
est prêt à la payer, il est normal que les hébergeurs, les éditeurs SaaS, FAI 
et autres acteurs, cherchent à en stocker pour être disposé à en revendre. 
Forcément, ressources en quantités limitées => demande forte => le prix 
unitaire augmente.

Mais avoir un prix unitaire de plus en plus élevé n’est-il pas le bon moyen 
pour inciter au développement des alternatives que l’on prétend plus viables et 
moins couteuses ?

Et puis de toute façon, si tu enlèves le concept de “marché” ; quel moyen 
équitable et juste proposes-tu de mettre en place ? Ne plus donner d’IPv4, en 
donner sous conditions ? Lesquelles ? Fermer les yeux sur un marché noir ?

Ceux qui militent contre la situation/position actuelle du RIPE, ont-ils 
participé aux discussions et aux votes du RIPE ? Proposent-ils tout ou partie 
de leurs services personnels et professionnels sur de l’IPv6 only ?

Je ne demande qu’à changer d’avis, et si y a de meilleurs alternatives et 
viables qui ont étés ou qui peuvent-êtres proposées, je serais ravis de les 
connaitre et d’en débattre.

Cordialement,
— 
David

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

Re: [FRnOG] [BIZ] bloc d'IP à céder

2017-08-09 Par sujet Josselin Lecocq

C'est quand même un beau scandale le trading d'IPv4...

Je sais qu'on est pas vendredi, mais il faudrait que plusieurs opés se
regroupent et commencent à annoncer via BGP les inetnum transférés selon
des méthodes mafieuses, afin de les rendre inutilisables, puisque le
RIPE a cessé de faire son job. Je suis assez curieux des conséquences
légales, étant entendu que nul ne peut prétendre à être propriétaire de
ces ressources. Ce ne sont que des numéros ! Vous achetez à prix d'or le
droit d'utiliser des vulgaires numéros...

Autre chose, pourquoi payer de tels tarifs alors qu'on peut se contenter
de créer des LIR à la volée et obtenir à chaque fois un /22 ? Je sais
qu'il faut attendre 2 ans avant de pouvoir faire un transfert, mais même
au bout de cette durée, l'opération n'est-elle pas plus rentable ?

Bref, il est vraiment temps que tout le monde se sorte les doigts du c*l
et qu'on passe tous en IPv6...


Josselin Lecocq
Quantic Telecom



Le 09/08/2017 à 10:42, David Ponzone a écrit :
> Laurent.
> 
> Il me semble quand même que quand tu achètes un /21, tu n'as pas le même prix 
> par IP que quand tu achètes un /16.
> 
> 
> David Ponzone
> 
> 
> 
>> Le 9 août 2017 à 02:09, Laurent Seror  a écrit :
>>
>> Hello,
>>
>> On utilise Kamorama pour nos "achats" d'ips. Voici leur analyse du marché
>> en tant que broker, que je trouve intéressant de partager avec vous dans ce
>> thread.
>>
>> <<
>> We are most frequently asked the question, what are IPv4 addresses selling
>> for?
>>
>> A Class B, which is the most common block size that Kalorama deals with,
>> has appreciated 20-30% in the last 60 days with buyers and sellers meeting
>> in the range of $12 to $14 an address.  Outliers exist, but the majority of
>> buy/sell interest is in this price zone.  As we see new Class B supply
>> continuing to enter the transfer market, we don¹t expect additional price
>> increases in 2017.
>>
>> Larger blocks, which are significantly scarcer, are currently getting
>> attention above $15 per address.  Assuming under-utilized large blocks will
>> continue to be brought to market in order to cash in on the value while
>> it¹s there, we believe larger blocks, such as /10s and /12s, could peak in
>> price between $17 and $22 within the next 6-9 months.  Our outlook is that
>> large, contiguous blocks from the private sector may no longer be available
>> in the transfer market some time in 2018.

>>
>> Un /21 "propre" vaut environ 25000$ pas 40k$
>>
>> Et cela avec la marge du broker incluse.
>>
>> L.
>>
>> Le mar. 8 août 2017 à 18:01, Michel Py 
>> a écrit :
>>
 Xavier Beaudouin a écrit :
 Disons ... que bon le fait que l'espace legacy (aka IPv4) étant arrivé a
>>> saturation, toutes les bidouilles
 de l'humanité pour rester sur ce genre de techno legacy a son reflet au
>>> niveau du RIPE.
 Voila, je sais que ça ne fait pas avancer le smilblick mais c'est un
>>> fait (désolant certes, mais vrai).
>>>
>>> C'est la même chose chez ARIN... Dans tout les cas on savait depuis
>>> longtemps qu'il y aurait un marché noir des IPv4, donc autant en faire un
>>> marché gris et le controller.
>>>
>>> Michel.
>>>
>>>
>>> ---
>>> 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] [BIZ] bloc d'IP à céder

2017-08-09 Par sujet Colin J. Brigato

> C’est peut-être regrettable, mais c’est un fait.
> Si l’IPv4 a un coût (direct ou indirect) pour son utilisateur final, et qu’il 
> est prêt à la payer, il est normal que les hébergeurs, les éditeurs SaaS, FAI 
> et autres acteurs, cherchent à en stocker pour être disposé à en revendre. 
> Forcément, ressources en quantités limitées => demande forte => le prix 
> unitaire augmente.

On reconnait immédiatement la patte PragmatiqueChanial™ dans la réflexion.
J’ai du mal à comprendre en revanche qu’il soit nécessaire dans ce
contexte. Il y aurait un marché lucratif pour ce qui est sensé être de
la ressource limitée partagée ? Avec moins d’exagération, c’est du
déja vu de longtemps dans le même contexte, tout bêtement avec le nom
de domaine, non ?

(ca sent la sortie du [BIZ] un peu).

Bien cordialement,

- Colin J. βrigato -
¥ngénieur Σystème & Δirecteur de Projet
✆ 06 43 19 33 49


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

Re: [FRnOG] [TECH] Boucle de routage chez Free

2017-08-09 Par sujet Yoann Gini

Il semblerait que quelqu’un ait lu. C’est maintenant corrigé.

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

Re: [FRnOG] [BIZ] bloc d'IP à céder

2017-08-09 Par sujet Olivier WARIN

Le 09/08/2017 11:49, « frnog-requ...@frnog.org au nom de Laurent Seror » 
 a écrit :



>Enfin, oui, IPv6 arrive mais c'est lent et quand je vois la mémoire max
>d'un routeur, je sens comme une arnaque qui guette les service providers...

Hello Laurent,


Un MX80 ca tient









 4M IPv4 / 3M IPv6 RIB routes
 1M IPv4/6 per FIB






Un MX240










 23M IPv4 / 9M IPv6 RIB routes
 5 M IPv4/6 per FIB






Leur routeurs "recents" ont droit a 64Go, rien a voir avec les 2Go d’un MX80 
qui tient quand meme aujourd’hui une full view v4 (680k prefix) et v6 (45k 
prefix) et laisse potentiellement gérer une croissance de 40% du nombre de 
routes annonces…



Bien a toi, 

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

[FRnOG] [TECH] ASR920 / IPv6 / Neighbor Discovery / Static route

2017-08-09 Par sujet Aurélien

Bonjour à tous,

Je fais appel à vous parce que j'ai une configuration IPv6 qui marche
bizarrement sur un ASR920, j'aimerais savoir si j'ai mal fait un truc ou
bien si c'est un bug.

Rapidement, mon setup: Un routeur avec du MPLS, des VRF, l'une d'entre
elles qui contient l'address family IPv6 en plus de la V4 (je ne rentre pas
trop dans les détails, mais c'est assez classique, l'ASR920 étant un de mes
PE).

Tout mon réseau IPv4 marche bien, l'IPv6 aussi sur toutes mes
connexions/VRF jusqu'ici.

Mon interface:

interface GigabitEthernet0/0/0
 description Customer: 
 vrf forwarding VRF1
 ip address 10.0.0.2 255.255.255.248
 negotiation auto
 ipv6 address 2001:db8::2/125
 vrrp 20 address-family ipv4
  priority 200
  address 10.0.0.1 primary
  exit-vrrp
 vrrp 20 address-family ipv6
  priority 200
  address FE80::1234:1 primary
  address 2001:db8::1/125
  exit-vrrp
end

ipv6 route vrf VRF1 2001:db8:1::/48 2001:db8::4

Mes VRRP v6 fonctionnent (un routeur master, l'autre backup).
Je peux joindre les IPv6 du subnet SAUF 2001:db8::4 depuis un routeur
distant (et donc pas non plus le subnet 2001:db8:1::/48).

En lançant un debug ipv6 nd, et en confirmant au sniffer et avec les tables
neighbor, je me rends compte que mon ASR n'envoie jamais de NS vers
pour 2001:db8::4
quand j'ai du trafic adressé à cette IP ou à 2001:db8:1::/48, et droppe les
paquets.

Si je retire la route statique ipv6, bim, ça refonctionne (j'ai une
sollicitation NS sur réception du traffic, et une entrée neighbor est
ajoutée).

Sinon, si je fais un ping vrf VRF1 ipv6 2001:db8::4 directement depuis le
routeur, indépendamment de la route statique, la NS est faite également.

Avez-vous déjà eu ce genre de comportement ? Est-ce que j'ai mal configuré
un truc à votre avis ?

Ma version:
Cisco IOS XE Software, Version 03.18.02.S - Standard Support Release
Cisco IOS Software, ASR920 Software (PPC_LINUX_IOSD-UNIVERSALK9_NPE-M),
Version 15.6(2)S2, RELEASE SOFTWARE (fc3)

Merci,
Cordialement,
-- 
Aurélien

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

[FRnOG] [TECH] Re: ASR920 / IPv6 / Neighbor Discovery / Static route

2017-08-09 Par sujet Aurélien

Re-bonjour,

Réponse à moi-même: c'est un bug.

Une autre source m'a pointé vers ce bug Cisco, qui semble correspondre:
IOS-XE: IPv6 forwarding issue caused by Neighbor Discovery / CSCvb84066

Désolé pour le bruit,
Bonne soirée,

2017-08-09 16:04 GMT+02:00 Aurélien :

> Bonjour à tous,
>
> Je fais appel à vous parce que j'ai une configuration IPv6 qui marche
> bizarrement sur un ASR920, j'aimerais savoir si j'ai mal fait un truc ou
> bien si c'est un bug.
>
> Rapidement, mon setup: Un routeur avec du MPLS, des VRF, l'une d'entre
> elles qui contient l'address family IPv6 en plus de la V4 (je ne rentre pas
> trop dans les détails, mais c'est assez classique, l'ASR920 étant un de mes
> PE).
>
> Tout mon réseau IPv4 marche bien, l'IPv6 aussi sur toutes mes
> connexions/VRF jusqu'ici.
>
> Mon interface:
>
> interface GigabitEthernet0/0/0
>  description Customer: 
>  vrf forwarding VRF1
>  ip address 10.0.0.2 255.255.255.248
>  negotiation auto
>  ipv6 address 2001:db8::2/125
>  vrrp 20 address-family ipv4
>   priority 200
>   address 10.0.0.1 primary
>   exit-vrrp
>  vrrp 20 address-family ipv6
>   priority 200
>   address FE80::1234:1 primary
>   address 2001:db8::1/125
>   exit-vrrp
> end
>
> ipv6 route vrf VRF1 2001:db8:1::/48 2001:db8::4
>
> Mes VRRP v6 fonctionnent (un routeur master, l'autre backup).
> Je peux joindre les IPv6 du subnet SAUF 2001:db8::4 depuis un routeur
> distant (et donc pas non plus le subnet 2001:db8:1::/48).
>
> En lançant un debug ipv6 nd, et en confirmant au sniffer et avec les
> tables neighbor, je me rends compte que mon ASR n'envoie jamais de NS vers
> pour 2001:db8::4 quand j'ai du trafic adressé à cette IP ou à
> 2001:db8:1::/48, et droppe les paquets.
>
> Si je retire la route statique ipv6, bim, ça refonctionne (j'ai une
> sollicitation NS sur réception du traffic, et une entrée neighbor est
> ajoutée).
>
> Sinon, si je fais un ping vrf VRF1 ipv6 2001:db8::4 directement depuis le
> routeur, indépendamment de la route statique, la NS est faite également.
>
> Avez-vous déjà eu ce genre de comportement ? Est-ce que j'ai mal configuré
> un truc à votre avis ?
>
> Ma version:
> Cisco IOS XE Software, Version 03.18.02.S - Standard Support Release
> Cisco IOS Software, ASR920 Software (PPC_LINUX_IOSD-UNIVERSALK9_NPE-M),
> Version 15.6(2)S2, RELEASE SOFTWARE (fc3)
>
> Merci,
> Cordialement,
> --
> Aurélien
>
>


-- 
Aurélien Guillaume

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

Re: [FRnOG] [TECH] Souci de configuration d’IP de management sur un chassis virtuel d’EX2200

Re: [FRnOG] [MISC] bloc d'IP à céder

RE: [FRnOG] [MISC] bloc d'IP à céder

Re: [FRnOG] [TECH] Boucle de routage chez Free

Re: [FRnOG] [BIZ] bloc d'IP à céder

Re: [FRnOG] [TECH] Boucle de routage chez Free

Re: [FRnOG] [BIZ] bloc d'IP à céder

[FRnOG] [TECH] Boucle de routage chez Free

Re: [FRnOG] [BIZ] bloc d'IP à céder

Re: [FRnOG] [BIZ] bloc d'IP à céder

Re: [FRnOG] [BIZ] bloc d'IP à céder

Re: [FRnOG] [BIZ] bloc d'IP à céder

Re: [FRnOG] [BIZ] bloc d'IP à céder

Re: [FRnOG] [TECH] Boucle de routage chez Free

Re: [FRnOG] [BIZ] bloc d'IP à céder

[FRnOG] [TECH] ASR920 / IPv6 / Neighbor Discovery / Static route

[FRnOG] [TECH] Re: ASR920 / IPv6 / Neighbor Discovery / Static route

17 matches

Site Navigation

Mail list logo

Footer information