Re: [FRnOG] [MISC] Microsoft (ASN 8075) sur AMS-IX

[Fabien VINCENT (FrNOG)]

Le 2017-07-10 18:45, Nicolas DEFFAYET a écrit :

> On Mon, 2017-07-10 at 12:08 +0200, David Ponzone wrote: 
> 
>> Juste pour info, c'est comme ça sur EQNX-IX, mais c'est normal: ils n'ont 
>> jamais annoncé  leurs routes par le MLPE.
> 
> Microsoft a pour politique de ne pas utiliser les route-servers, et ce
> quelque soit le point d'échange.
> 
> "Microsoft will not be peering with Route Servers going forward"
> 
> Pour l'établissement d'une session BGP directe avec Microsoft, il faut
> remplir leur formulaire disponible à l'adresse suivante:
> http://www.microsoft.com/peering

Un autre cas : avec des peerings sur les RS, si un gros peer arrive sur
l'IX, tu risques une saturation que tu ne pouvais pas toujours anticiper
(quelqu'un ici arrive à lire toutes les annonces de nouveau peer sur un
IX ? ). C'est parfois compliqué quand de gros ASes arrivent sur un IX et
te déséquilibrent d'un seul coup ton réseau (d'un Tier 1 ou d'un PNI,
tout ton traffic shifte sur l'IX sur un nouveau patch dans ton réseau
suivant les mécanismes choisis dans ton réseau pour les routes eBGP). 

Bref, pratique les RS pour démarrer, mais avec du volume, pas si simple
à gérer dans certains cas (en tout cas en mode open, j'annonce et je
recois tout). 

D'ailleurs, certains implémentent des très bonnes features ces derniers
temps sur les communities (extended ou large), avec l'annonce d'une
community tagguant le pays d'origine de l'AS. Ca permet de limiter ce
genre de désagrément quand tu peere sur un nombre conséquent d'IXes au
travers d'un contient ou au niveau mondial.

-- 
FABIEN VINCENT 
_@beufanet_
---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [BIZ] Solution Speedtest Interne

[Fabien VINCENT (FrNOG)]

Le 2017-10-12 17:33, Julien Manteau a écrit :


https://github.com/ndt-project/ndt

Branch HTML5

Julien

Le 12 oct. 2017 17:01, "David Ponzone"  a 
écrit :


Ouais ben une ACL devant et voilà :)
Le 12 oct. 2017 à 16:56, Hugues VOITURIER a écrit :

De mémoire il faut qu'il soit public dans ce cas, ce qui n'est pas 
forcément acceptable pour tout le monde.

Hugues,

On 12 Oct 2017, at 16:38, David Ponzone 

 wrote:


Si tu hébergeais ton propre serveur nPerf ?

https://www.nperf.com/fr/host-server/

Le 12 oct. 2017 à 16:19, Lucas Viallon a écrit :

Bonjour A tous,

J'ai un sujet qui revient régulièrement sur la table chez nous c'est le
calamiteux SpeedTest.
Outils d'une fiabilité très douteuse mais qui sert de référence a

 nos


clients.

Je cherche désespérément a mettre en place un outils type Speedtest en
interne dans notre réseau
mais j'avoue avoir du mal a trouver.

Actuellement, pour démontrer au client qu'il a bien le débit demandé,

 on


lui demande d'installer un btest et en face on a un mikrotik qui va lui
montrer le debit de sa liaison de façon + fiable.

On lui demande aussi parfois de faire un simple FTP sur notre serveur

 en


Up/Down.

Cela règle jusqu'ici 100% des doutes mais c'est lourd a gérer.

donc je me disais que si on mettait une interface web qui en 2s fait

 comme


SpeedTest mais en mode "interne" a notre réseau cela eliminerait pas

 mal de


temps de traitement.

Quelqu'un aurait un outils a nous conseiller ? opensource ou pas

merci d'avance pour vos conseils.

a+
Lucas

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

Projet intéressant ! Mais semble encore coller à des dépendances client 
java :( https://github.com/ndt-project/ndt/issues/208


On en avait parlé avec PYMaunier au dernier FrNog, sur un outil de 
collecte côté enduser assez KISS qui permettrait à des endusers de 
tester / reporter un path pourri. Ca semble simple avec du Java / 
"client lourd", mais faire un mtr / vrai speedtest au niveau stack 
réseau ou au plus proche depuis un browser reste à priori impossible 
sans passer par des artifices qui font que les résultats sont souvent 
peu accurates.


En tout cas merci pour le partage et si quelqu'un à des retours 
d'utilisation et si ca fait le kawa (et une doc la dessus à partager), 
je veux bien ;)


J'ai bien essayé mes vieux ping sweeper qui m'amusaient sur CORS, mais 
ca répond pas au besoin parfait ;)


--
FABIEN VINCENT
_@beufanet_


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

[FRnOG] [TECH] SIG / Carto

[Fabien VINCENT (FrNOG)]

Hello la liste,

Vous utilisez quoi comme soft de SIG pour la carto de déploiement de 
fibre optique ??


Je recherche quelque chose de simple, webui si possible, et autre que 
Google Earth mais qui sait importer/exporter du KMZ ;)


Merci d'avance pour vos feedbacks !

--
FABIEN VINCENT
_@beufanet_


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

Re: [FRnOG] [TECH] Outil d'analyse pour IP mix

[Fabien VINCENT (FrNOG)]

Le 2018-06-12 17:17, Arnaud BRAND a écrit :

> Merci à tous pour vos réponses !
> 
> On a donc :
> - AS-Stats : simple et efficace
> - Stack ELK + Grafana : plus compliqué mais puissant
> - Elastiflow : qui semble être une version packagée et plutôt sexy du 
> précédent, mais avec des besoins en ressources importants
> - Flowanalyzer : version packagée, mais semble disposer de moins de 
> fonctionnalités, aucune idée des besoins.
> 
> Apparemment Elastiflow a la bonté de permettre en plus de faire des AS 
> Lookups.
> Quelqu'un a essayé / sait comment le lookup est fait / sait si c'est efficace 
> ?
> 
> Sinon, comment faites-vous quand vos f. routeurs ne remplissent pas les 
> AS dans les flows (alors qu'ils ont une full-table en mémoire...) ?
> 
> Le 2018-05-30 12:24, Arnaud BRAND a écrit : 
> 
>> Bonjour la liste,
>> 
>> Je viens puiser dans ton infinie expérience J
>> 
>> Je cherche des outils/méthodes pour identifier les AS qui constituent
>> le gros mon transit.
>> Ce pour ajuster au mieux mon mix et fournir le meilleur service au
>> meilleur prix.
>> 
>> Bêtement, je partais sur des flow.
>> Pour la partie export des flows c'est trivial.
>> Mais pour la collecte/agrégation/classification, ça l'est nettement moins.
>> 
>> Quels outils/méthodes utilisez-vous ?
>> 
>> Merci pour vos retours et belle journée !
>> Arnaud
>> 
>> ---
>> Liste de diffusion du FRnOG
>> http://www.frnog.org/
> 
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/

Perso j'utilise nfacctd de pmacct. Ca rocks des ours et ca fait le job.
Suivant ton volume, un petit script qui parse la data agrégée in memory
et sort / structure les infos qui t'intéressent et tu pousses dans un
graphite + dashboard grafana pour le kikoulol. Ca marche mais le scale
est compliqué dès que tu balances du lourd niveau flows. L'avantage :
j'ai redémarré nfacctd qu'après chaque compil du master ;) c'est fiable
/ stable et Paolo Lucente qui dév le truc est toujours dispo pour aider.
Et ca fix les problèmes d'asn puisque le démon bgp fourni avec le
package complète les infos que je flag dans graphite (communities bgp
par exemple). Donc je fais confiance à nfacctd pour les netflows, et une
petite session BGP pour les data BGP. 

J'ai pas encore creusé mais ils ont add un démon bmp qui permettrait
encore de pousser le bouchon. 

Il faut quelques skills s/sysadmin/devops/ge pour s'en sortir mais
franchement c'est à la porté de n'importe quel barbu qui aime le
cambouis ;) 

Sinon faut demander à Monsieur Maunier si Kentik marche on premise
maintenant :p

-- 
FABIEN VINCENT 
_@beufanet_
---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [TECH] Automation: Ansible et ses alternatives

[Fabien VINCENT (FrNOG)]

Le 2018-08-14 14:47, Steeve BEAUVAIS - Société Serinya Telecom a écrit :

> Bonjour,
> 
> Je suis actuellement en train d'étudier Ansible afin d'automatiser
> certaines tâches sur plusieurs types de devices du genre Cisco (IOS et IOS
> XE) Huawei (Campus et CE), KVM et divers serveurs linux.
> 
> Je me suis penché au premier abord sur Ansible. Outils très puissant y'a
> pas à dire, mais le hic (car il y a toujours un hic) c'est l'API dispo sur
> la version tower qui coûte un voire 2 bras.
> Les autres fonctionnalités comme le dashboard etc ne m'intéressent pas,
> uniquement les playbooks et l'API
> 
> Utilisez-vous autre chose ou si vous utilisez Ansible de quelle manière?
> J'ai pu voir rapidement qu'il y avait Rudder et Puppet mais j'ai pas
> l'impression qu'ils soient aussi puissants.
> 
> Merci beaucoup par avance pour vos retours la liste :)
> 
> Cordialement,
> Steeve Beauvais
> 
> 
> 
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/

Salt Stack ?

-- 
FABIEN VINCENT 
_@beufanet_
---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [TECH] Re : [FRnOG] [TECH] Juniper Q-in-Q tunnel dans EVPN/VXLAN

[Fabien VINCENT (FrNOG)]

Le 2018-09-07 14:28, Olivier FRUQUET a écrit :


Salut,
Merci pour vos réponses.
Alors j'ai déjà essayé avec plusieurs ethertypes, j'avais fixé le 
0x88a8 partout mais ça n'a rien changé.
Oui j'ai une MTU déclarée élevée partout, j'affinerai un peu plus tard, 
là je veux juste que ça tombe en marche.
Juniper d'après ce que j'ai pu trouver en documentation taggues par 
défaut en 0x8100.
Un lien vers un schéma fait vite fait sur un tableau : 
https://image.noelshack.com/fichiers/2018/36/5/1536323250-schema-vxlan-olivier.jpg


@Fabien VINCENT : en gros j'ai un trunk C-VLAN vlan-id-list 1-4092 qui 
se fait tagguer par dessus en S-VLAN 1001 par les EX2300.

Je vais creuser un peu plus le pattern 4 de la doc Juni.
En gros les ports facing CE sur mes QFX ont la conf suivante :

set interfaces xe-0/0/0 description "*** Liaison FON vers CUST1001 
siege CPE port xe-0/1/3 ***;"

set interfaces xe-0/0/0 mtu 9216
set interfaces xe-0/0/0 flexible-vlan-tagging
set interfaces xe-0/0/0 encapsulation extended-vlan-bridge
set interfaces xe-0/0/0 unit 1001 vlan-id 1001

Ensuite j'ai la conf suivante pour VXLAN :

set vlans VLAN1001_CUST_QINQ interface xe-0/0/0.1001
set vlans VLAN1001_CUST_QINQ vlan-id 1001
set vlans VLAN1001_CUST_QINQ vxlan vni 1001
set vlans VLAN1001_CUST_QINQ vxlan ingress-node-replication

set protocols evpn encapsulation vxlan
set protocols evpn extended-vni-list all
set protocols evpn multicast-mode ingress-replication
set protocols l2-learning decapsulate-accept-inner-vlan

En me tagguant en 1001 un switch quelconque directement au cul d'un 
QFX, j'arrive à pinguer de l'autre côté, donc je suppose que la couche 
EVPN fonctionne bien, je n'ai pas testé du coup le flood and learn 
multicast.


J'ai essayé aussi avec le pattern 4 en pop and push mais pas mieux ...
La conf des ports de chaque EX2300 :

set interfaces xe-0/1/2 description "*** Liaison vers coeur client 
siege ***"

set interfaces xe-0/1/2 flexible-vlan-tagging
set interfaces xe-0/1/2 mtu 9216
set interfaces xe-0/1/2 encapsulation extended-vlan-bridge
set interfaces xe-0/1/2 unit 1001 vlan-id-list 1-4092
set interfaces xe-0/1/2 unit 1001 input-vlan-map push
set interfaces xe-0/1/2 unit 1001 output-vlan-map pop

set interfaces xe-0/1/3 description "*** Liaison FON vers QFX spine1 
***"

set interfaces xe-0/1/3 flexible-vlan-tagging
set interfaces xe-0/1/3 mtu 9216
set interfaces xe-0/1/3 encapsulation flexible-ethernet-services
set interfaces xe-0/1/3 unit 1001 encapsulation vlan-bridge
set interfaces xe-0/1/3 unit 1001 vlan-id 1001

J'ai testé tellement de choses que je me paume un peu, pour ça que j'ai 
besoin d'un oeil extérieur :)


Merci !
A plus
Olivier

Le jeu. 6 sept. 2018 à 23:19, Fabien VINCENT (FrNOG) 
 a écrit :


Le 2018-09-06 19:51, Sebastien Maillet a écrit :
Sinon, en fonction de l'implémentation du qinq sur ton équipement tu 
peux avoir des surprises si l'ethertype utilisé est 88a8 au lieu du 
8100 (tag Vlan).
Certains équipements ne reconnaissent pas l'ethertype 88a8 et du coup 
ne savent pas lire le tag Vlan juste derrière.
Pas sûr que ça vienne de ça mais ça vaut le coup de l'avoir en tête et 
vérifier ce point.

Sébastien

 Message original 
Objet : Re: [FRnOG] [TECH] Juniper Q-in-Q tunnel dans EVPN/VXLAN
De : Michel Hostettler
À : Olivier FRUQUET
Cc : Jugurta Yennek ,frnog-tech

J'me lance !
Vous êtes déclaré en jumbo frame ?
Michel

- Mail original -
De: "Olivier FRUQUET" 
À: "Jugurta Yennek" 
Cc: "frnog-tech" 
Envoyé: Jeudi 6 Septembre 2018 18:28:37
Objet: Re: [FRnOG] [TECH] Juniper Q-in-Q tunnel dans EVPN/VXLAN

Hello !
Yes MTU à 9216 sur toutes les interfaces.

Olivier

Le jeu. 6 sept. 2018 à 18:20, Jugurta Yennek  a 
écrit :


Hello Olivier,

A tout hasard tu es good au niveau MTU sur tout le chemin ?

Jugurta

On 06/09/2018 17:32, Olivier FRUQUET wrote: Bonjour à tous,

J'ai un petit souci dans une configuration EVPN VXLAN avec Juniper, 
j'aurai besoin d'un avis de pros !
Nous avons une IP fabric composée de deux routeurs MX204 en guise de 
coeur, 2 QFX5110 en rôle de Provider Edges et 2 petits EX2300 en CPE 
chez le

client.
Le but est de relier via une fibre noire le site 1 et le site 2 du 
client

avec tous ses vlans à l'intérieur d'un tunnel VXLAN, de manière
transparente, sans avoir besoin de déclarer au préalable les vlans du
client justement...
On s'est tournés vers le Q-in-Q encapsulé dans du VXLAN (je partais sur
l'idée que mes QFX matcheraient le S-VLAN 1001 avec tous les vlans du
client à l'intérieur pour envoyer sur un VXLAN VNI 1001), mais ça ne 
marche pas ... on a suivi la doc de Juniper : 
https://www.juniper.net/documentation/en_US/junos/topics/topic-map/evpn-vxlan-flexible-vlan-tag.html 
,

en vain.
Toute la partie BGP marche bien, quand je tag simple l'uplink de mon CE
vers le QFX en 1001 ça marche bien, par contre quand j'envoie du Q-in-Q
depuis le CE il n'y a plus rien qui passe ! J'ai utilisé le pattern N°3 

Re: [TECH] Re : [FRnOG] [TECH] Juniper Q-in-Q tunnel dans EVPN/VXLAN

[Fabien VINCENT (FrNOG)]

Le 2018-09-06 19:51, Sebastien Maillet a écrit :

> Sinon, en fonction de l'implémentation du qinq sur ton équipement tu peux 
> avoir des surprises si l'ethertype utilisé est 88a8 au lieu du 8100 (tag 
> Vlan).
> Certains équipements ne reconnaissent pas l'ethertype 88a8 et du coup ne 
> savent pas lire le tag Vlan juste derrière.
> Pas sûr que ça vienne de ça mais ça vaut le coup de l'avoir en tête et 
> vérifier ce point.
> Sébastien
> 
>  Message original 
> Objet : Re: [FRnOG] [TECH] Juniper Q-in-Q tunnel dans EVPN/VXLAN
> De : Michel Hostettler
> À : Olivier FRUQUET
> Cc : Jugurta Yennek ,frnog-tech
> 
> J'me lance !
> Vous êtes déclaré en jumbo frame ?
> Michel
> 
> - Mail original -
> De: "Olivier FRUQUET" 
> À: "Jugurta Yennek" 
> Cc: "frnog-tech" 
> Envoyé: Jeudi 6 Septembre 2018 18:28:37
> Objet: Re: [FRnOG] [TECH] Juniper Q-in-Q tunnel dans EVPN/VXLAN
> 
> Hello !
> Yes MTU à 9216 sur toutes les interfaces.
> 
> Olivier
> 
> Le jeu. 6 sept. 2018 à 18:20, Jugurta Yennek  a écrit :
> 
> Hello Olivier,
> 
> A tout hasard tu es good au niveau MTU sur tout le chemin ?
> 
> Jugurta
> 
> On 06/09/2018 17:32, Olivier FRUQUET wrote: Bonjour à tous,
> 
> J'ai un petit souci dans une configuration EVPN VXLAN avec Juniper, j'aurai 
> besoin d'un avis de pros !
> Nous avons une IP fabric composée de deux routeurs MX204 en guise de coeur, 2 
> QFX5110 en rôle de Provider Edges et 2 petits EX2300 en CPE chez le
> client.
> Le but est de relier via une fibre noire le site 1 et le site 2 du client
> avec tous ses vlans à l'intérieur d'un tunnel VXLAN, de manière
> transparente, sans avoir besoin de déclarer au préalable les vlans du
> client justement...
> On s'est tournés vers le Q-in-Q encapsulé dans du VXLAN (je partais sur
> l'idée que mes QFX matcheraient le S-VLAN 1001 avec tous les vlans du
> client à l'intérieur pour envoyer sur un VXLAN VNI 1001), mais ça ne marche 
> pas ... on a suivi la doc de Juniper :
> https://www.juniper.net/documentation/en_US/junos/topics/topic-map/evpn-vxlan-flexible-vlan-tag.html
>  ,
> en vain.
> Toute la partie BGP marche bien, quand je tag simple l'uplink de mon CE
> vers le QFX en 1001 ça marche bien, par contre quand j'envoie du Q-in-Q
> depuis le CE il n'y a plus rien qui passe ! J'ai utilisé le pattern N°3 de la 
> documentation Juniper.
> 
> Si quelqu'un l'a déjà fait ou aurait une idée je suis preneur..!
> Merci !
> Olivier
> 
> ---
> 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/ 

+1. Ou quand la norme (802.1ad) donne un nom commun (QinQ) qui ne
signifie plus la norme ;) 

Souvent les équipements tagguent 0x8100 par défaut partout cependant,
mais c'est customisable 0x8100 | 0x88a8 | 0x9100 

Je connais pas qinq sur Junip, mais comment tu taggues ton outer tag
(aka S-VLAN en 802.1ad) ? T'as quoi en dessous ? Du trunk ? 

Si tu fais du VxLAN en flood and learn unicast sans EVPN est ce que ca
marche ? 

J'ai déjà vu des bugs chez un autre constructeur ou quand tu passes le
port en QinQ, l'ASIC taggue x2 le traffic untagged donc tout est
possible ! T'as pas moyen de span le traffic ailleurs ? 

En regardant d'ailleurs les patterns Juniper, j'ai l'impression que tu
décris plutôt le cas n°4 

C-VLAN + tag S-VLAN/outer A => swap S-VLAN with VNI => tag S-VLAN/outer
B + C-VLAN 

En gros si tu QinQ tes VLANS customer dans ton VLAN qui te servira a
VxLAN, il faut que le mapping soit un pop/push outer VLAN <> VxLAN id. 

-- 
FABIEN VINCENT 
_@beufanet_
---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [TECH] Automatisation des comparaisons de "show ... blah blah"

[Fabien VINCENT (FrNOG)]

Le 2018-03-19 11:10, marc celier a écrit :

> Bonjour, 
> 
> Nous devons mener une maintenance sur l'ensemble du reseau, ce qui implique 
> un nombre important d'equipements. avant et apres la maintenance nous devons 
> executer un nombre important de commandes "show" et realiser des comparaisons 
> visuels pour detecter un eventuel changement ou dysfonctionnement. c'est pas 
> Top car on peut toujours manquer une info critique a cause de la masse de 
> donnees a comparer. 
> 
> J'imagine qu'il y a des outils comme Ansible ou la commande diff qui pourrait 
> etre un debut de piste, mais n'ayant jamais travaille avec ces outils je n'ai 
> pas une claire vision de la solution globale. si vous avez deja mis en place 
> quelque chose de similaire pouvez vous s'il vous plait partager votre 
> experience et pistes en la matiere (environnement Juniper et Arista) 
> 
> - execution des commandes show 
> - comparaison des commandes show 
> -generation d'un rapport sur les differences  
> 
> Je vous remercie par avance.

Pourquoi ne pas regarder du côté de streaming telemetry avec Pipeline
(gRPC) ? Pourquoi ne pas utiliser l'API JSON-RPC d'Arista ? Suivant les
protocoles il y a aussi OpenBMP. Côté receiver, tu as Pipeline ou pmacct
qui fait le café avec des dumps de rib bgp par exemple. Tout est
possible (suivi la release que tu tournes, le bling bling c'est surtout
sur les versions .0 ou un train qui n'a pas d'EMR) 

Bref, y a de quoi faire et sinon napalm doit pouvoir te le faire de
manière très simple et automatisé. Et je suis sur qu'il existe déjà
beaucoup de choses que tu recherches dedans. 

Sinon old mais toujours efficace : snmp si l'oid existe et est standard.


C'est un peu broadcast mon output, mais en même temps, ca dépend des
diff que tu veux faire et des CPU de tes équipements. Si tu as une
machine à laver ou un aspirateur, tu pourras pas get les mêmes choses
sans que ton control plane fasse "ouf" à la fin du show. Idem sur snmp
;) 

PS : attention les show run sur Arista, c'est un show run complet qui
est exécuté par la FastCli python avant de te retourner le show run int
machin/truc, mais en json/rpc ca fait moins mal et les CPU des Arista
généralement sont pas ceux d'antan ;)

-- 
FABIEN VINCENT 
_@beufanet_
---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [TECH] QinQ à géométrie variable et liens de collecte.

[Fabien VINCENT (FrNOG)]

Le 2019-03-25 17:03, Radu-Adrian Feurdean a écrit :


On Mon, Mar 25, 2019, at 16:52, Michel Hostettler wrote:


Un empilage de 0x8100 m'apparait assez peu normé.


Peu "norme" de point de vue normes, par contre tres courant chez les 
operateurs et les constructeurs (pour certains 0x8100 c'est default, 
avec possibilite de changer, chez d'autres - ou plutot sur d'autres 
plate-formes - avec des commandes differentes pour 0x8100 et 0x88A8).


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


On peut même trouver 0x9100 chez Cisco pour QinQ :D

En bref j'avais souvent l'habitude de dire QinQ propre (0x9100+0x8100), 
QinQ devenu le standard de facto (souvent avec VxLAN ou l'outer tag est 
pop pour être remplacé par VNI) (0x8100+0x8100). Le premier on oublie 
direct, le deuxième est le standard désormais de ce que j'ai pu toucher. 
J'aime à parler de Inner Vlan et Outer Vlan dans cette situation pour 
éviter de mélanger avec le standard IEEE.


En effet après il a la norme 802.11ad (0x88A8+0x8100) ou la en général 
on parle clairement de S-VLAN pour Service (0x88A8) et de C-VLAN pour 
Customer (0x8100)


Bref, c'est un joyeux bordel, sans compter que des fois quand tu fais du 
QinQ tu te retrouves avec des ASIC qui double taguent le native (il 
passe 0x0800 en 0x8100 avec Outer = Inner Tag).


Joie et bonheur quand tu te lances dans QinQ :D encore plus quand c'est 
aussi obscur que chez un opérateur (ca dépend aussi surement de ses 
équipements en face, pas toujours les mêmes je suppose).


--


--
FABIEN VINCENT
_@beufanet_


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

Re: [FRnOG] [ALERT] Amazon EC2 down ?

[Fabien VINCENT (FrNOG)]

Le 2019-02-07 16:06, open doc a écrit :

> j'ai pas réussi à avoir des infos, aucune info d'orange.
> 
> Merci Fabien VINCENT pour l'info.
> 
> Alex.
> 
> Le jeu. 7 févr. 2019 à 09:50, Fabien VINCENT (FrNOG)
>  a écrit : 
> Le 2019-02-07 09:31, Sebastien Coureau a écrit :
> 
> Hello,
> Sans garanties aucune, j'ai constaté des pbs chez Orange hier en fin de 
> journée (impossible de joindre cpanel.net via LB, mais OK en 4G SFR.
> 
> --
> Sébastien Coureau
> Graal Network
> 
> Le 6 févr. 2019 à 23:16, open doc  a écrit :
> 
> Bonjour,
> 
> je n'ai pas eu de réponse sur tweeter sur l'origine du problème.
> Quelqu'un aurait une info  ?
> 
> Alex.
> 
> Le mer. 6 févr. 2019 à 21:35, julien PAULI  a écrit :
> 
> Je confirme, ca remonte.
> 
> Julien
> 
> On Wed, Feb 6, 2019 at 9:34 PM Charley SEDEAU  wrote:
> 
> Effectivement, c'est de retour ici aussi depuis Orange (paris)
> 
> Je serais curieux de connaitre l'origine du problème si quelqu'un a des
> infos :)
> 
> - Charley SEDEAU
> 
> Le mer. 6 févr. 2019 à 21:31, open doc  a écrit :
> 
> Je vous confirme que cela vient tout juste de revenir pour les IP aux US.
> 
> Le mer. 6 févr. 2019 à 19:41, Faustin Lammler  a écrit :
> 
> Bonsoir,
> je suis le seul à avoir des problèmes avec le cloud de Amazon ?
> 
> Par exemple:
> - zulipchat.com
> - aws.amazon.com
> 
> J'ai beau faire des mtr depuis plusieurs POP, ça passe pas.
> 
> Faustin
> 
> ---
> 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/
> 
> Hello :
> 
> https://twitter.com/clementstenac/status/1093198377813188609?s=21
> 
> Not verified ;)
> 
> --
> FABIEN VINCENT
> _@beufanet_
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/

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

Je pense qu'il aurait fallu digger le looking glass d'OTI au moment de
l'incident ou même gratter du côté de chez BGPPlay sur RIPEstats. Mais
pas sur que ce soit visible si c'était localisé ;)

-- 
FABIEN VINCENT 
_@beufanet_
---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [ALERT] Amazon EC2 down ?

[Fabien VINCENT (FrNOG)]

Le 2019-02-07 09:31, Sebastien Coureau a écrit :

> Hello,
> Sans garanties aucune, j'ai constaté des pbs chez Orange hier en fin de 
> journée (impossible de joindre cpanel.net via LB, mais OK en 4G SFR.
> 
> -- 
> Sébastien Coureau
> Graal Network
> 
> Le 6 févr. 2019 à 23:16, open doc  a écrit :
> 
> Bonjour,
> 
> je n'ai pas eu de réponse sur tweeter sur l'origine du problème.
> Quelqu'un aurait une info  ?
> 
> Alex.
> 
> Le mer. 6 févr. 2019 à 21:35, julien PAULI  a écrit :
> 
> Je confirme, ca remonte.
> 
> Julien
> 
> On Wed, Feb 6, 2019 at 9:34 PM Charley SEDEAU  wrote:
> 
> Effectivement, c'est de retour ici aussi depuis Orange (paris)
> 
> Je serais curieux de connaitre l'origine du problème si quelqu'un a des
> infos :)
> 
> - Charley SEDEAU
> 
> Le mer. 6 févr. 2019 à 21:31, open doc  a écrit :
> 
> Je vous confirme que cela vient tout juste de revenir pour les IP aux US.
> 
> Le mer. 6 févr. 2019 à 19:41, Faustin Lammler  a écrit :
> 
> Bonsoir,
> je suis le seul à avoir des problèmes avec le cloud de Amazon ?
> 
> Par exemple:
> - zulipchat.com
> - aws.amazon.com
> 
> J'ai beau faire des mtr depuis plusieurs POP, ça passe pas.
> 
> Faustin
> 
> ---
> 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/ 

Hello : 

https://twitter.com/clementstenac/status/1093198377813188609?s=21 

Not verified ;)

-- 
FABIEN VINCENT 
_@beufanet_
---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [MISC] Retours d'expérience pour présentation sur IPv4/IPv6

[Fabien VINCENT (FrNOG)]

Le 2019-09-05 11:02, Cécile a écrit :

> Hello la liste !
> 
> Je vous lis depuis un moment, même si je ne comprends pas tout ce que vous 
> dites (mais j'essaye d'apprendre !), c'est à mon tour de vous demander de 
> l'aide:
> 
> Comme vous avez pu voir sur Twitter pour ceux qui me suivent, pour les cours 
> (Je suis en 2ème année de BTS SIO SISR, en alternance) je dois faire un 
> exposé en rapport avec l'informatique en général. Je me suis donc mis au défi 
> de présenter la « fin » d'IPv4 et les conséquences sur les entreprises et 
> opérateurs. Pour relever le défi, le public (ma classe) n'a jamais vu IPv6 ni 
> BGP...
> 
> Mon plan actuel est le suivant :
> 
> *   Introduction: Comment fonctionne internet ? (Ici j'explique le BGP, les 
> AS, le RIPE...)
> *   Quels problèmes se posent actuellement avec IPv4?
> *   La solution: IPv6...
> *   ...Mais une solution non exploitée
> *   Quels sont les éléments qui empêchent cette transition ?
> *   Retour d'expérience
> 
> J'ai donc besoin de vous pour compléter tous les retours d'expérience que 
> j'ai eue, surtout sur les points suivants :
> 
> *   Pourquoi IPv6 n'est pas implémenté ? (Que ce soit sur les box grand 
> public, en entreprises, chez les opérateurs...)
> *   A votre niveau, avez-vous implémenté IPv6 ?
> *   Les acteurs de l'internet ont-ils pris conscience des problèmes avec IPv4 
> ? Sont-ils préparés à la pénurie d'IPv4 ?
> *   Que pensez-vous de l'utilisation du CG-Nat par les opérateurs ?
> *   Les médias reflètent-il bien la vision des acteurs du réseau ? (Je pense 
> à cet article, qui avait fait grand débat : 
> https://www.lemagit.fr/actualites/252468059/Penurie-IPv4-comment-lInternet-europeen-sombre-dans-les-magouilles)
> *   Que pensez-vous de la revente d'IPv4 ? C'est un business comme un autre, 
> ou à la limite de la légalité ?
> 
> Si vous avez des commentaires, des retours d'expériences, et un avis à donner 
> en plus des questions, n'hésitez pas !
> 
> Merci d'avance pour vos réponses, et au plaisir de discuter avec vous au 
> FRnOG !
> 
> Cécile MORANGE
> 
> @AtaxyaNetwork
> 
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/

 Cécile, 

Je te conseille l'excellente présente de Geoff Huston au dernier RIPE : 

https://ripe78.ripe.net/presentations/41-2019-05-23-ipv6-fail.pdf

https://ripe78.ripe.net/archives/video/85 

Des exemples assez drôle 

-- 
FABIEN VINCENT 
_@beufanet_
---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [TECH] BGP best practice

[Fabien VINCENT (FrNOG)]

Le 11-12-2019 10:54, Raphael Mazelier a écrit :

On 11/12/2019 08:36, Antoine DURAND wrote: 


Hello,

Période calme pour moi avant les fêtes, je me remets sur la refonte de mon 
archi BGP...

Est-ce que vous supprimez la route par défaut 0.0.0.0/0 de vos routeurs BGP 
lorsque vous êtes en full-view ?

Il y a deux choses : accepter une route par défaut de tes transits (ça se 
discute) et avoir une default dans ta table.

J'avais l'habitude de garder une default statique vers l'un de mes transits sur 
mes edge, comme çà en cas de grosse foirade tes paquets peuvent quand même 
sortir, et tu peux te connecter sur ton edge sur l'ip d'une de tes intercos.

--

Raphael Mazelier

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


Tu peux aussi faire du Selective Route Download. Tu acceptes la default
dans BGP mais tu l'insères pas dans la RIB. Ca peut toujours servir
parfois. Perso, il y a plusieurs cas ou ça m'a aidé et rien ne t'empêche
ensuite de balancer dans une autre vrf la default apprise par BGP et
router le trafic vers un autre nexthop dans cette vrf pour y voir le
trafic concerné. Encore une fois, tout dépend de l'archi, de tes
besoins, et des évolutions futures. 


Bref c'est un choix d'architecture, mais comme dit Michel, c'est bien
pour uRPF de null router. Mais bon uRPF en multi-homed, bein  


Sur les route-map + prefix-list + filter list, c'est pareil. Sur FRR /
IOS tu peux choisir ce qui te convient le mieux, juste attention aux mix
AFI/SAFI IPv4 et IPv6 dans la même route-map (coucou les 6k). Pour ça
que des fois faire juste le "traffic engineering" et la manipulation du
best path dans ta route-map sans toucher aux préfixes (et donc mixer
AFI/SAFI) peut être intelligent. 


Sur IOS-XR ou d'autres c'est plus simple, il n'y a que des
routes-policies qui regroupent tout en AiO. C'est parfois mieux, mais
aussi casse gueule quand tu maîtrises pas toutes les features et les
règles implicites. 


Un truc que j'avais trouvé cool sur Arista EOS c'est les sub-route-map
pour faciliter le travail, ca te permet de chainer et faire du more
specific de manière fonctionnel et hihiérarchique pour chaque neighbor.
Je sais pas si c'est dispo dans FRR.

--
Fabien VINCENT 
_@beufanet_

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

[FRnOG] [TECH] RPKI / ROA maxLength

[Fabien VINCENT (FrNOG)]

Salut la liste, 


Quelqu'un a un avis sur maxLength des ROA ? Je pense au cas ou tu aurais
quand même un hijack quelque part et tu veux annoncer un more specific
pour mitiger l'impact. 


Vu que ROA = AS + Prefix + maxLength, est ce que si j'ai une /16 et que
je mets maxLength à /24 c'est pas bien ? 


Je vois partout dans la littérature que c'est mieux de faire l'exact
match, mais vu que bon RPKI / ROA+ROV c'est pas demain pour tout le
monde (malheureusement), je pose la question des annonces de more
specific quand quelqu'un fait n'importe quoi et que ca t'impacte, et
qu'il te reste plus que propager un more specific pour mitiger l'impact
sur tes Tier 1 qui droppent pas les RPKI invalid :p 


Un ou des avis éclairés ?

--
Fabien VINCENT 
_@beufanet_

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

Re: [FRnOG] [TECH] Retour expérience IPAM

[Fabien VINCENT (FrNOG)]

Le 06-01-2020 13:08, Florent CARRÉ a écrit :

Hello Christian et la liste,

Phpipam, bon un classique mais en plus récent et qui fait dcim en même
temps, c'est netbox: https://github.com/netbox-community/netbox

Netbox fait IPAM, mais en aucun cas gestion des DNS et du DHCP. Si tu 
veux le faire c'est possible et codable facilement avec leur API mais 
c'est pas natif.



Bonne journée

On Mon, Jan 6, 2020, 06:27 Christian Rolland  wrote:


Bonjour La Liste,

Meilleurs voeux pour 2020

Nous cherchons des retours d'expérience sur des IPAM présents sur le
marché français (mais pas EFFIP par pitié).
Gestion DNS multi-zones, DHCP,...

Si quelqu'un a une bonne expérience avec un produit, nous sommes 
preneurs.


Merci d'avance,

Christian ROLLAND
--
Christian ROLLANDESRF
Network AdministratorEuropean Synchrotron Radiation Facility
Phone : +33 (0)476 88 20 69  71 avenue des Martyrs
Email : roll...@esrf.eu  38000 GRENOBLE - FRANCE



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



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


--
Fabien VINCENT
_@beufanet_


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

Re: [FRnOG] [TECH] IOS-XR - syslog des low/alarm level

[Fabien VINCENT FrNOG via frnog]

Le 04-03-2020 15:20, Pierre Emeriaud a écrit :

Le mer. 4 mars 2020 à 12:22, Fabien VINCENT FrNOG via frnog
 a écrit :


Le 04-03-2020 11:52, Cécile Martron via frnog a écrit :
> Bonjour la liste,
>
>   Avez vous une idée de comment logger en syslog dans les ASR9k
> (IOS-XR) les low warning/alarm signal level des sfp ?
> Impossible de trouver la bonne config logging et sortir le PM pour ça
> c'est imbuvable...
> En vous remerciant sincèrement,
>
Normalement, ca marche tout seul ...

Pour ma part, j'ai juste une règle sur le logging pour un remote 
syslog
server pour les severity info et sur le remote server j'ai bien des 
logs

du genre :

  LC/0/16/CPU0:Mar  4 05:45:15.295 UTC: pfm_node_lc[294]:
%PLATFORM-SFP-2-LOW_RX_POWER_ALARM :
Clear|envmon_lc[168025]|0x102900b|TenGigE0/16/0/11


idem de mon coté, ça log également par lane sur les 100g, mais sans
préciser le port directement, pas pratique pour | i

LC/0/0/CPU0:Feb 25 22:57:56.036 UTC: pfm_node_lc[295]:
%PLATFORM-CFP-2-LANE_3_LOW_RX_POWER_ALARM :
Clear|envmon_lc[168022]|0x102b015|Port_21

quelle severity tu as mis ? (info ici).


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


Tiens c'est drole, sur QSFP-28/CPAK, ca loggue bien le port :

LC/0/8/CPU0:Mar  3 06:18:00.763 UTC: pfm_node_lc[292]: 
%PLATFORM-QSFP_PLUS-2-LANE_0_LOW_RX_POWER_ALARM : 
Set|envmon_lc[155735]|0x102c002|HundredGigE0/8/0/2
LC/0/0/CPU0:Mar  4 14:00:10.527 UTC: pfm_node_lc[292]: 
%PLATFORM-CPAK-2-LANE_0_LOW_RX_POWER_ALARM : 
Set|envmon_lc[159831]|0x1005007|HundredGigE0/0/0/7


--
Fabien VINCENT
_@beufanet_


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

Re: [FRnOG] [TECH] IOS-XR - syslog des low/alarm level

[Fabien VINCENT FrNOG via frnog]

Le 04-03-2020 20:34, Pierre Emeriaud a écrit :

Le mer. 4 mars 2020 à 16:20, Fabien VINCENT FrNOG via frnog
 a écrit :


Tiens c'est drole, sur QSFP-28/CPAK, ca loggue bien le port :


quelle platforme / carte / version ?

Chez moi c'est a9k / mod400 / 6.0.2 ou 6.5.3 à vérifier.



a9k en 6.5.3 Tomahawk / Skyhammer (100G/QSFP-28/CPAK) ou Typhoon 
(10G/SFP+)




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


--
Fabien VINCENT
_@beufanet_


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

Re: [FRnOG] [TECH] IOS-XR - syslog des low/alarm level

[Fabien VINCENT FrNOG via frnog]

Le 04-03-2020 11:52, Cécile Martron via frnog a écrit :

Bonjour la liste,

Avez vous une idée de comment logger en syslog dans les ASR9k
(IOS-XR) les low warning/alarm signal level des sfp ?
Impossible de trouver la bonne config logging et sortir le PM pour ça
c'est imbuvable...
En vous remerciant sincèrement,

Cécile

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


Normalement, ca marche tout seul ...

Pour ma part, j'ai juste une règle sur le logging pour un remote syslog 
server pour les severity info et sur le remote server j'ai bien des logs 
du genre :


 LC/0/16/CPU0:Mar  4 05:45:15.295 UTC: pfm_node_lc[294]: 
%PLATFORM-SFP-2-LOW_RX_POWER_ALARM : 
Clear|envmon_lc[168025]|0x102900b|TenGigE0/16/0/11


Tu as besoin de quoi d'autres ?

--
Fabien VINCENT
_@beufanet_


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

Re: [FRnOG] [TECH] Bonnes pratiques concernant "Management VLAN" ?

[Fabien VINCENT FrNOG via frnog]

Le 17-02-2020 21:53, DUVERGIER Claude a écrit :

Je me rends compte qu'il manque un paragraphe :

OK, je mets le LAN des postes clients dans un VLAN dédié (eg. VID 42) 
et

que pour administer les switchs il faille être dans le VLAN dédié (eg.
VID 1 pour simplifier). Dans quel VLAN dois-je mettre le port de mon
ordinateur, moi, le type qui va administer les switchs et vouloir 
surfer

sur Internet ?

Dans les 2 en non-taggés, avec un PVID par défaut sur VID 1 ?
Dans les 2 : en non taggé sur VID 42 et en taggé sur VID 1, avec une
configuration d'OS pour pouvoir émettre du trafic taggé vers VID 1 ? Ça
me parait lourd et peu commode.

--
Duvergier Claude

Le 17/02/2020 à 21:41, David Ponzone a écrit :

L’idéal, tu l’as compris, c’est de rien mettre dans le VLAN 1.
A mon avis personnel, en fonction de ton contexte pro, c’est quand 
même un peu parano :)


Passons ce détail, revenons à tes D-Link.
Tu dis que sur tes DGS, tu n’as plus de menu L2 
Features/VLAN/Management VLAN, pour choisir l’ID de ton VLAN de 
management ?
Je viens de vérifier la doc et tu sembles avoir raison: ils ont viré 
ça pour mettre tout leur merdier de Surveillance VLAN.

On sent le truc pour te vendre leurs solutions de caméras/NVR.

Ben 2 solutions:
1/ tu vires les DLink (à mon avis, la meilleure option, plus le temps 
passe, plus ces constructeurs font n’importe quoi)
2/ tu laisses un seul port dans le VLAN 1 untag et AUCUN autre, et tu 
le connectes à ton LAN de management


Le 17 févr. 2020 à 19:30, DUVERGIER Claude 
 a écrit :


Bonjour la liste,

Je configure le réseau de nouveaux locaux et je voulais en profiter 
pour

faire un truc "propre" qui me trotte dans la tête depuis un moment :

« Ne plus utiliser le VLAN de VID 1 pour le LAN. »

J'ai l'impression que ce VLAN est censée être réservé à 
l'administration
du réseau et que faire que les postes du LAN ne soient pas dedans 
serait

une bonne chose.
En fait de manière plus générique : ne pas avoir les postes clients 
et

les interfaces d'administration des switchs dans le même VLAN (que ça
soit VID 1, VID 42 ou autre).

Le site Ciscopress [1] conseille bien de changer le VID du management
VLAN pour autre chose que 1, mais seulement voilà :

Mes switchs sont des D-Link DGS-1210 série F [1] pour lesquels je me
suis dit : tu vires tous les ports du VLAN de VID 1 comme ça tu es 
sûr

de ne pas t'en servir... Sauf que l'interface web GUI du D-Link ne
permet plus (visiblement on pouvait sur d'anciens modèles) de choisir 
le
VID du "Management VLAN" et que donc si je vide le VID 1 je me 
retrouve

interdit d'accès à la web GUI (logique).

Est-ce que conserver le VID 1 pour le management VLAN (et mettre les
autres appareils sur d'autres VLAN) reste une bonne pratique ?
Ce qui me "dérange" c'est que, à l'achat, tout switch est en mode 
"tous

les ports dans VID 1 et management VLAN = VID 1" donc lors de la
première configuration les switchs neufs sont déjà dans le VLAN de
management...

Avez-vous des conseils à me faire (autre que changer de matériel) 
pour

la bonne gestion du management VLAN ?

Merci

[1] : 
http://www.ciscopress.com/articles/article.asp?p=2181837=11

[2] :
https://eu.dlink.com/uk/en/products/dgs-1210-series-gigabit-smart-plus-switches

--
DUVERGIER Claude


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






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


A mon avis, c'est parce que le CPU de ton control plane ne gère pas les 
paquets taggués. Donc ils forcent le VLAN1 qu'ils considérent vlan 
native. Le VLAN 1 je le vois toujours comme le native, parce que dans 
beaucoup d'implémentations, VLAN 1 même taggué dans la trame 802.1q = 
VLAN native = Ethernet 0x8000. Cisco, pour ne pas les citer, taggue les 
CDP/VTP en VLAN 1. Donc pour éviter le VLAN Hopping, c'est mieux de ne 
pas l'utiliser en taggué.


Après la je dirais que ca semble inhérent au produit, qui ne sait pas 
gérer des paquets 802.1q avec un type 0x8100 directement punté au CPU.  
Ou alors qui a fait un management plane cohérent sur tous les produits 
sans discussion de si le control plane le fait.


Donc la t'as pas vraiment le choix que de tagguer le 1 only, pour 
limiter à minima l'accès (plus ACL avec sécurité par l'obscurité), 
attention aux autres constructeurs sur une topologie comme ca.



--
Fabien VINCENT
_@beufanet_


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

Re: [FRnOG] [TECH] Changement Cisco ?

[Fabien VINCENT FrNOG via frnog]

Le 25-03-2020 14:05, Lucas Viallon a écrit :

Merci pour ta réponse,

Dans mon cas, j'ai vraiment tendance a rester cisco que je connais et 
dont

le taux de satisfaction chez nous et de l'ordre de 99%,
j'ai déjà essayé d'aller vers du juniper, du mikrotik ou du libre et
sincèrement je m'en suis toujours mordu les doigts.

Au niveau budget, je suis justement en train de le définir, on 
s'adaptera

mais on préférera payer un peu plus chère pour du cisco
que perdre du temps a retester d'autres plateformes

au vu des conseils, je pense commander un ASR en 9900 pour tester, on 
verra

bien

Le mer. 25 mars 2020 à 12:43, Jérôme Nicolle  a écrit 
:



Salut Lucas,

Le 25/03/2020 à 11:39, Lucas Viallon a écrit :
> Il y a quelqu'un qui a deja fait ce genre de changement ? vous etes
partie
> sur sur quelle gamme ?

Juniper MX / ACX / QFX le plus souvent, Arista ou Cumulus par 
ailleurs.


Su tu restes en Cisco, de toute façon tu vas changer d'OS en passant à
IOS-XR donc quitte à refaire tout ton design autant en profiter pour
regarder à coté. En fonction de ce que tu veux en faire, il peut y 
avoir

un réel intérêt à changer de fabricant.

N'oublies pas d'évaluer les NCS5500 aussi, ils en ont gros sous le 
pied.




+12 :) NCS55xx c'est un bon produit, qui peut être moins cher et moins 
all in the box que l'ASR. L'ASR ca reste un gros bouzin pour faire tout 
(et n'importe quoi des fois :)). NCS s'adapte très bien je pense en 
remplacement du Cat6K, surtout si tu n'as pas beaucoup de choses en FIB. 
Voir aussi 8K même si pas d'expérience / feedback dessus.


Sur ASR si tu as pas besoin de 100G, pas besoin de modularité, il y a le 
9001, mais attention en PPC donc qui va être rapidement deprecated 
niveau IOS-XR. Il y a des évolutions du 9901 et ca ne va pas s'arrêter 
la je pense (il y a un trou aujourd'hui entre le 1U fixed et les chassis 
10/12U minima)


Sinon Arista ca marche très très bien, avec un support vraiment au top, 
et est moins déroutant niveau CLI si tu fais de l'IOS (IOS-XR change pas 
mal quand même en terme de logique).


Bonnes recherches !


@+

--
Jérôme Nicolle
+33 6 19 31 27 14


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



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


--
Fabien VINCENT
_@beufanet_


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

Re: [FRnOG] [TECH] filtrage QinQ et C3064-X

[Fabien VINCENT FrNOG via frnog]

Le 01-05-2020 12:59, Denis Fondras a écrit :

Hello,

Je souhaite remplacer mes switches de collecte actuels (CTCU) par des 
Cisco

3064-X. Problème, je n'arrive pas à reproduire la conf actuelle.

J'ai des CPE qui encapsulent le trafic du client dans un (ou plusieurs) 
s-vlan
qui est propagé jusqu'aux routeurs de coeur (ou un autre site). Sur le 
port du
switch de collecte je n'accepte que les trames taggés avec le s-vlan 
spécifique
du client (ou si un petit malin remplace le CPE, tout son trafic non 
taggé sera

inclu d'office dans son s-vlan).

La conf actuelle côté client :
  switchport hybrid native vlan 1009
  switchport hybrid allowed vlan 101,1009
  switchport hybrid ingress-filtering
  switchport hybrid egress-tag all
  switchport hybrid port-type s-port
  switchport mode hybrid

Le port côté routeur autorise tous les numéros de s-vlan utilisé par 
les

clients.

Or sur le Cisco, j'ai l'impression que c'est portes ouvertes.

Ma conf Cisco :
  switchport mode dot1q-tunnel
  switchport trunk allowed vlan 101,1009
  no shutdown

Et là, je peux faire passer du trafic taggé avec n'importe quel numéro 
de s-vlan
ou non-taggé en mode YOLO. J'ai tenté plusieurs variations de la 
configuration

précédente mais sans succès.
Est-ce que vous savez si c'est possible ?

Merci
Denis


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


Le native vlan est pas supporté en plus du trunk allowed + mode 
dot1q-tunnel c'est ca ?


--
Fabien VINCENT
_@beufanet_


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

Re: [FRnOG] [TECH] filtrage QinQ et C3064-X

[Fabien VINCENT FrNOG via frnog]

Le 01-05-2020 16:27, Denis Fondras a écrit :

On Fri, May 01, 2020 at 02:45:33PM +0200, Fabien VINCENT (FrNOG) wrote:


Le native vlan est pas supporté en plus du trunk allowed + mode 
dot1q-tunnel

c'est ca ?



Voici la conf complète pour le lab:

interface Ethernet1/46
  description Port-CPE
  switchport mode dot1q-tunnel
  switchport access vlan 100
  switchport trunk allowed vlan 100
  spanning-tree port type edge
  spanning-tree bpdufilter enable
  l2protocol tunnel stp
  l2protocol tunnel allow-double-tag
  no shutdown

interface Ethernet1/48
  description Port-Routeur
  switchport mode dot1q-tunnel
  switchport trunk allowed vlan 100
  spanning-tree port type edge
  spanning-tree bpdufilter enable
  l2protocol tunnel stp
  l2protocol tunnel allow-double-tag
  no shutdown

Avec ça je m'attends à :
- le CPE n'a pas taggé le paquet, le switch le fait
- le trafic du svlan 101 venant du CPE n'entre pas dans le switch
- le routeur reçoit tous les paquets avec un tag s-vlan.
- les paquets sans s-vlan issus du routeur ne sont pas taggés (ou 
taggés en

  svlan1 au pire)

Or le routeur ne reçoit rien dans la situation actuelle comme si le 
switch se

disait que eth1/48 ne fait pas parti du s-vlan 100.



Pourquoi tu veux mettre un port (Eth1/48) vers ton router en mode 
dot1q-tunnel sur l'uplink en fait ? C'est un trunk/dot1q tunnel tout 
simple non ?





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


--
Fabien VINCENT
_@beufanet_


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

Re: [FRnOG] [TECH] Orange / Digital Ocean

[Fabien VINCENT FrNOG via frnog]

Le 05-05-2020 00:21, Sylvain Rabot a écrit :

Ok, donc si pas de trucs curieux dans le traceroute, une idée de la
cause de ce débit tout pourri depuis orange ?



Tu as le MTR dans l'autre sens ? Il peut y avoir beaucoup de raisons, et 
c'est pas forcément l'agrume en cause, surtout quand on fait la moitié 
du globe dans un sens, on est parfois surpris de voir le paquet revenir 
par l'autre côté :)


(sauf chez les Platistes qui ne croient pas en Internet sur la terre)

Comment fais tu tes tests de débit ? Si le MTR ne montre pas de loss 
end-to-end, alors la vérité est ailleurs.


On Tue, 5 May 2020 at 00:02, Hugues Voiturier 
 wrote:


Bonsoir,

La seule différence a mon sens, c’est que Level3 encapsule le traf 
dans un tunnel (probablement sur mpls) alors que ntt te montre ses 
hops.


Le ping varie assez peu et l’endpoint reste dans la même région (San 
Jose, USA)


My2C


Hugues
AS57199 - AS50628

On 4 May 2020, at 23:58, Sylvain Rabot  wrote:

Bonsoir,

Depuis chez moi (Orange fibre) le téléchargement du binaire suivant
https://pkgs.tailscale.com/stable/debian/pool/tailscale_0.98-0_armhf.deb
ce fait à 20~30 kB/s que ce soit en ipv4 ou ipv6.

Depuis une instance scaleway j'ai un débit "normal".

Le MTR depuis orange me donne l'impression de bouncer sur tous ce que
NTT à de routeurs:

  My traceroute  [v0.87]
bdx-mal-osmc1 (0.0.0.0)
   Mon May  4 23:45:06 2020
Resolver error: Received reply from unknown source: 
2a01:cb19:96e:9100::

  Packets
 Pings
HostLoss%
Snt   Last   Avg  Best  Wrst StDev
1. lan.home  0.0%
50.7   0.8   0.7   0.9   0.0
2. 80.10.239.121 0.0%
5  215.4 142.3   2.3 447.4 191.9
3. 80.10.154.14  0.0%
52.1   2.9   2.1   4.2   0.5
4. ae42-0.nipoi201.Poitiers.francetelecom.net0.0%
55.1   6.0   4.9   9.3   1.7
5. ae40-0.nipoi202.Poitiers.francetelecom.net0.0%
55.8   8.4   5.4  18.7   5.7
6. 193.252.137.14   50.0%
5   12.2  12.3  12.2  12.4   0.0
7. ae-26.r04.parsfr01.fr.bb.gin.ntt.net  0.0%
5   12.5  12.5  12.4  12.6   0.0
8. ae-23.r24.amstnl02.nl.bb.gin.ntt.net  0.0%
4   46.4  47.3  46.3  48.9   1.0
9. ae-3.r25.amstnl02.nl.bb.gin.ntt.net   0.0%
4   47.5  47.8  47.5  48.0   0.0
10. ae-5.r23.asbnva02.us.bb.gin.ntt.net   0.0%
4   95.6  94.8  94.4  95.6   0.0
11. ae-10.r22.snjsca04.us.bb.gin.ntt.net  0.0%
4  172.9 170.7 169.8 172.9   1.4
12. ae-40.r02.snjsca04.us.bb.gin.ntt.net  0.0%
4  158.1 158.3 158.1 158.4   0.0
13. ae-4.r06.plalca01.us.bb.gin.ntt.net   0.0%
4  159.6 159.8 159.6 160.1   0.0
14. ae-0.digital-ocean.plalca01.us.bb.gin.ntt.net 0.0%
4  169.6 169.8 169.6 170.0   0.0
15. ???
16. ???
17. ???
18. ???
19. 165.227.17.164   0.0%
4  179.4 179.6 179.4 180.2   0.0

Depuis Scaleway c'est beacoup "propre":

   My traceroute  [v0.87]
carnot (0.0.0.0)
  Mon May  4 21:49:16 2020
Keys:  Help   Display mode   Restart statistics   Order of fields   
quit


Packets   Pings
Host   Loss%
Snt   Last   Avg  Best  Wrst StDev
1. ???
2. 10.5.16.65   0.0%
60.5   0.6   0.3   1.5   0.0
3. 10.1.94.98   0.0%
60.8   0.6   0.5   0.8   0.0
4. 216-225-47-212.int.cloud.online.net  0.0%
60.7   0.6   0.4   0.7   0.0
5. 51.158.8.177 0.0%
60.7   0.6   0.4   0.8   0.0
6. lag-110.ear3.Paris1.Level3.net   0.0%
61.1   1.2   1.1   1.3   0.0
7. ae-10-3501.ear2.SanJose1.Level3.net 75.0%
5  147.1 147.1 147.1 147.1   0.0
8. 4.14.33.70   0.0%
5  147.5 147.6 147.5 147.7   0.0
9. ???
10. ???
11. 165.227.17.164   0.0%
5  147.9 148.1 147.8 149.1   0.0

Y aurait-il un problème entre Orange et NTT/Digital Ocean ?

Cordialement.

--
Sylvain Rabot 


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




--
Fabien VINCENT
_@beufanet_


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

Re: [FRnOG] [TECH] Peering ISP Français vers T-Systems/Deutsche Telekom (via Cogent)

[Fabien VINCENT FrNOG via frnog]

Le 20-03-2020 19:53, Francois RETAILLEAU a écrit :

Bonjour la liste,

En tant que client final d'ISP Français et utilisateur de solutions 
(VPN)
hébergées en Allemagne, derrière T-Systems par notre Groupe, on subit 
pas
mal le peering T-Systems - Cogent ou on tappe jusqu'à 50% de packet 
loss.


En général j'ai des liens FTTO et le support qui va avec, mais Covid-19
obligé, beaucoup de nouveaux utilisateurs télé-travaillent ce qui 
entraîne
une utilisation massive de connexion grand public pour (tenter) de 
monter

ses VPN ssl.


Visiblement Free, certains liens Altice (SFR et ce qui ressemble a des
anciens lien Neuf Telecom et certaines connexion grand public) semblent
utiliser Cogent pour atteindre l'AS de DT.

Forcément ça bloque.

Je m'efforce de designer autre chose pour contourner, mais pour cela il
faut que j'ai des billes sur la partie peering.
A savoir: est ce le trafic remis par Cogent à T-Systems qui bloque et 
donc

capacité T-Systems, ou bien celle de nos ISP Français vers Cogent ?

Pour cela, je ne sais pas comment troubleshooter et surtout trouver des
données / dashboards sure ce peerin qui pourrait faire avancer mon
argumentaire.

J'espère que ma demande est a peu près claire.

Merci a ceux qui répondront.

Bon weekend !

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


Alors déjà DTAG c'est compliqué, mais alors si tu passes par Cogent sur 
le chemin en plus ...


Bref comme déjà dit, il faut des MTR dans les 2 sens pour essayer de 
comprendre par ou tu passes.


Dans tous les cas, DTAG vs Cogent c'est pas nouveau, ca dure depuis au 
moins 2015 ?


--
Fabien VINCENT
_@beufanet_


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

Re: [FRnOG] [TECH] FRNOG [TECH] Fwd: Message important concernant les élections du RIPE

[Fabien VINCENT FrNOG via frnog]

Le 08-05-2020 20:23, Damien DUJARDIN a écrit :

Tu aurais du lire mieux (troll gratuit du vendredi)

Techniquement il utilise un bit réservé dans l'entête donc ça peut
fonctionner.


It MAY work ;) Ca me rappelle une histoire avec la réutilisation du bit 
CFI de 802.1q devenu DEI :)


Un véritable carnage dans les implémentations constructeurs (quand DEI 
est implémenté et qu'il fait des chocapic avec un vieux routeur en 
face). Les stacks réseaux, elles ont pas les durées de vie des k8s 
serverless in da cloud.


Bref, il serait peut être temps d'implémenter tout ce qu'il faut pour 
qu'IPv6 fonctionne correctement plutôt (je pense notamment aux moultes 
implémentations DNS reverse et autres). Il n'est certes pas parfait, 
mais IPv4 l'était-il ?


La Dual Stack ca existe et ca marche. Non sans problème, mais à un 
moment donné, t'imagines si on rénovait des 2CV depuis 80 ans ? Ca peut 
aussi marcher ! This industry SHOULD move :)




Par contre la modif est énorme puisque ce bit doit être pris en compte 
dans

tout ce qui manipule de l'ipv4.
C'est encore plus risqué que la transition ipv6 car le matériel non
compatible ne verra pas ce bit et routera donc vers la mauvaise cible. 
Bon

courage pour le troubleshoot.

Il relativise la modification en promettant immédiatement monts et
merveilles aux membres. Méthodes classique des politiciens.
Tous le marketing est bien rodé, il vend du rêve.
Je me suis arrêté de lire quand il a dit "vous n'aurez vos IPs que si 
je

suis élu"
Ça en dit tout sur le personnage.

Sinon d'après vous, on est sur quels profils du côté des votants, 
plutôt

technique ou plutôt managers politiciens ?

Pour ma part, c'est technique, et ça sera mon premier vote au RIPE

Que pensez vous des autres candidats (en dehors des iraniens bien sûr)?

Bonne soirée

Damien

Le ven. 8 mai 2020 à 20:00, Julien Escario  
a

écrit :


Il faudrait peut être expliquer pourquoi sa proposition est une
aberration totale ?

Si j'ai bien compris, le monsieur propose de jouer sur la 
représentation
de l'IP dans un paquet. En changeant [0-255].[0-255].[0-255].[0-255] 
en

[0-65535].[0-65535].
Ce qui est une connerie abominable au niveau technique puisque dans un
paquet, il n'y a aucun point, uniquement |0-F]{8} donc c'est 
strictement

la même chose.

J'ai arrêté ma lecture à ce stade tellement j'ai trouvé ça à des 
années

lumières de la connaissance technique qu'il faut pour causer de ça. Si
même moi, avec mes quelques notions de réseau je comprends ça (tout en
ramant pas mal pour suivre les prez des RIPE Meeting), le mec n'a 
juste

rien à faire ni au RIPE, ni à proposer un draft.

Juste ou j'aurais dû lire mieux ?

Julien

Le 08/05/2020 à 19:44, Hugues Voiturier a écrit :
> Est-ce que c’est un troll ?
>
> Dans le cas contraire, ce genre de propos est franchement indigne d’une
ML comme FRnOG…
>
> Hugues
> AS57199 - AS50628
>
>> On 8 May 2020, at 19:24, Bruno LEAL DE SOUSA 
wrote:
>>
>> Hello,
>>
>> Je ne connais pas ce fameux candidat mais au vu de la complexité
d'adoption
>> de l'IPv6 et de l'attachement à l'IPv4, proposer ce type de solution est
>> intelligent et encourageant !
>>
>> A suivre...
>>
>> Bruno LEAL DE SOUSA
>> 06.01.23.45.96
>>
>> Le ven. 8 mai 2020 à 15:42, Christophe PLESSIS  a
écrit :
>>
>>> Bonjour,
>>> Avez vous reçu cette information pour augmenter le nombre d’ipv4 ? Quel
>>> est votre avis ?
>>> A bon entendeur.
>>> Christophe
>>>
>>> De : Elad Cohen 
>>> Envoyé : vendredi 8 mai 2020 00:06
>>> À : contact 
>>> Objet : Message important concernant les élections du RIPE
>>>
>>> Bonjour,
>>>
>>> Je m'appelle Elad Cohen et je suis candidat au conseil
d'administration du
>>> RIPE lors des prochaines élections, qui auront lieu le 13 de ce mois.
>>>
>>> J'ai créé une solution technique avec laquelle il y aura plus de 4 294
967
>>> 296 adresses IPv4 pour les 5 registres Internet régionaux, y compris le
>>> RIPE, vous pouvez en savoir plus à ce sujet ici :
>>>
>>>
https://www.ripe.net/ripe/mail/archives/members-discuss/2020-April/003676.html
>>>
>>> Le problème « d'épuisement d'IPv4 » sera derrière nous et chaque membre
>>> RIPE recevra au moins un /21 d'adresses IPv4 gratuites si je suis élu.
>>> Personne d'autre ne mettra en œuvre ma solution technique, je vous
demande
>>> votre vote en ligne. Sans votre vote en ligne à la prochaine assemblée
>>> générale du RIPE, ma solution technique ci-dessus ne sera pas mise en
œuvre.
>>>
>>> Veuillez vous inscrire au vote en ligne pour les élections du RIPE en
>>> utilisant le lien suivant :
>>> https://www.ripe.net/s/gm-registration-may-2020
>>>
>>> Si vous rencontrez un problème pour vous inscrire au vote en ligne,
>>> veuillez envoyer un courrier électronique à a...@ripe.net>> a...@ripe.net>
>>>
>>> ---
>>>
>>> Outre la solution technique susmentionnée au problème de «
l'épuisement de
>>> l'IPv4 », il existe deux autres solutions techniques que je
m'efforcerai de
>>> mettre en œuvre si j'ai l'honneur d'être élu :
>>>
>>>
>>> Une solution technique 

Re: [FRnOG] Re: [TECH] UDP - DDOS : Solution globale possible ?

[Fabien VINCENT FrNOG via frnog]

Le 03-09-2020 13:56, Fabien VINCENT FrNOG  via frnog a écrit :

Le 03-09-2020 10:15, Philippe Bourcier a écrit :

Re,


@Stephane : OK pour BCP 38 effectivement !


+1 pour BCP, ca fait déjà plus de 20 ans qu'on en parle... et ce n'est
toujours pas fait partout.


@Stephane, oui pour DNS, mais malheureusement l'imagination est sans
limite pour trouver des nouveaux services d'amplification ..


C'est pas pour casser tes rêves, Fabien, mais la prochaine mouture de
HTTP (HTTP/3) risque bien
d'être en UDP... Ce sera potentiellement le début de la fin de TCP sur
Internet vu à quel point
ce seul protocole est ultra-majoritaire et va continuer de l'être.



Ha j'allais dire la même chose sur HTTP/3 (y a eu un très bon thread
sur NaNOG la dessus, hormis les trolls, sur la classification de
QUIC/HTTP/3 comme un DDoS chez Verizon si je me souviens bien, en gros
la personne regarde youtube sous Chrome et il obtient un débit tout
pourri)


Avec le lien et la correction, ce n'est pas Verizon, mais AT

https://www.mail-archive.com/nanog@nanog.org/msg105413.html



Bizarrement, je ne suis pas sur que TCP devienne la mode, je dirais
que c'est globalement l'inverse se produit. On utilise de plus en plus
UDP pour s'affranchir des problématiques de SlowStart (voir pour
encapsuler, cf VxLAN).

Bref, la fin d'UDP (et donc des DDoS avec spoof de la source) c'est
pas pour demain.

Globalement, il y a des choses à faire avec BCP 38, possiblement
FlowSpec (mais l'actualité va pas nous aider, et les mesures FlowSpec
inter AS, c'est compliqué IMHO), mais rien à mes yeux de globalement
applicable partout. Ca reste du bon vouloir des gens, et il est existe
quand même pas mal de moyens aujourd'hui de s'en prémunir (les gros
opérateurs proposant des services de miti auto).




Cordialement,
--
Philippe Bourcier
web : http://sysctl.org
blog : https://www.linkedin.com/today/author/philippebourcier

Cordialement,
--
Philippe Bourcier
web : http://sysctl.org/
blog : https://www.linkedin.com/today/author/philippebourcier


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


--
Fabien VINCENT
_@beufanet_


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

Re: [FRnOG] Re: [TECH] UDP - DDOS : Solution globale possible ?

[Fabien VINCENT FrNOG via frnog]

Le 03-09-2020 10:15, Philippe Bourcier a écrit :

Re,


@Stephane : OK pour BCP 38 effectivement !


+1 pour BCP, ca fait déjà plus de 20 ans qu'on en parle... et ce n'est
toujours pas fait partout.


@Stephane, oui pour DNS, mais malheureusement l'imagination est sans
limite pour trouver des nouveaux services d'amplification ..


C'est pas pour casser tes rêves, Fabien, mais la prochaine mouture de
HTTP (HTTP/3) risque bien
d'être en UDP... Ce sera potentiellement le début de la fin de TCP sur
Internet vu à quel point
ce seul protocole est ultra-majoritaire et va continuer de l'être.



Ha j'allais dire la même chose sur HTTP/3 (y a eu un très bon thread sur 
NaNOG la dessus, hormis les trolls, sur la classification de QUIC/HTTP/3 
comme un DDoS chez Verizon si je me souviens bien, en gros la personne 
regarde youtube sous Chrome et il obtient un débit tout pourri)


Bizarrement, je ne suis pas sur que TCP devienne la mode, je dirais que 
c'est globalement l'inverse se produit. On utilise de plus en plus UDP 
pour s'affranchir des problématiques de SlowStart (voir pour encapsuler, 
cf VxLAN).


Bref, la fin d'UDP (et donc des DDoS avec spoof de la source) c'est pas 
pour demain.


Globalement, il y a des choses à faire avec BCP 38, possiblement 
FlowSpec (mais l'actualité va pas nous aider, et les mesures FlowSpec 
inter AS, c'est compliqué IMHO), mais rien à mes yeux de globalement 
applicable partout. Ca reste du bon vouloir des gens, et il est existe 
quand même pas mal de moyens aujourd'hui de s'en prémunir (les gros 
opérateurs proposant des services de miti auto).





Cordialement,
--
Philippe Bourcier
web : http://sysctl.org
blog : https://www.linkedin.com/today/author/philippebourcier

Cordialement,
--
Philippe Bourcier
web : http://sysctl.org/
blog : https://www.linkedin.com/today/author/philippebourcier


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


--
Fabien VINCENT
_@beufanet_


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

Re: [FRnOG] [FRNOG][TECH] Network Access Control

[Fabien VINCENT FrNOG via frnog]

Hum, ça dépend ce qu'on entend par NAC. 802.1x ça juste marche dans la 
plupart des cas et ça fait le job de contrôle d'accès L2.


Maintenant, si tu veux partir sur plus complexe avec des produits avec 
clients lourds installés sur les postes qui vérifient l'état de 
l'antivirus, les MaJ appliquées et les logiciels installés, 
effectivement c'est souvent un peu lourd, et passer au firewall / VPN 
pour contrôler les flux IP c'est souvent suffisant.


Tout ça c'est dépendant d'une politique de sécurité. Si ton job c'est de 
verrouiller l'accès au réseau, alors 802.1x fait le café si tes 
équipements sont assez homogènes et supportent le 802.1x. Si ton job 
c'est de verrouiller l'accès aux services (aka du cloud over IP), alors 
oui un bon firewall/IPS/Détection d'applications et VPN fait le job.


Mais c'est clair que les produits de NAC et d'enforcement des postes de 
travail, c'est vite une usine à gaz, surtout en si tu as autre chose que 
du windose.


Fabien

Le 01-09-2020 17:34, A Gaillard a écrit :

Hello,

Même retour que Guillaume, le NAC c'est beau sur le papier.
En vrai à installer ça coute 2 bras, c'est hyper compliqué à gérer, dès 
que

t'as de l'historique (type vieux téléphones, vieilles caisses, vieilles
caméras, etc.) tu fais des exceptions qui cassent une bonne partie de 
la
plus-value sécurité. Et à gérer pendant la vie de la solution, tu as 
besoin
d'une équipe dédiée, à la fois technique pour comprendre ce qu'il se 
passe,
et capable de répondre aux "clients" interne lorsque madame michu 
n'arrive
pas à se brancher sur la prise RJ45 du bureau de Michel qui, lui, avait 
une

exception pour faire fonctionner son fax.

Les quelques clients qu'on a accompagné sur le sujet avait de belles
ambitions, mais s'en sont souvent arrêté à la moitié de la phase 1
lorsqu'ils n'ont pas fait retour arrière.

Je conseillerais donc d'éviter de partir dans ce genre de projet pour
éviter de perdre des sous en société de conseil, en gestion de projet, 
en
équipements, en support, en recrutement d'équipe, et au passage 
permettre

d'économiser 2 ans de la vie de plusieurs personnes :)


Adrien.

Le mar. 1 sept. 2020 à 16:20, Guillaume Tournat via frnog 


a écrit :


Bonjour,

Cela me parait un meilleur investissement de considérer que le LAN 
n'est

plus un réseau de confiance (approche Zero Trust)

et que l'utilisateur doive être connecté en VPN en interne comme en
externe (always on).

De ce fait, les accès sont systématiquement authentifiés. Hormis 
l'accès

vpn, tout autre flux => portail captif pour accès web.


Le 01/09/2020 à 15:57, Jerome Lien a écrit :
> Bonjour à tous,
>
> on se pose régulièrement la question d'ajouter un NAC dans notre
> réseau pour mieux gérer les accès wifi/utilisateurs, les branchements de
> tout et n'importe quoi sur les prises réseaux, les déplacements
> d'équipements sans prévenir et voire de la conf de vlan automatique ...
>
> Actuellement on gère +/- 100 vlan pour la segmentation pour + de 5000
IP's
>
> Je pense que certain d'entre vous on cela chez eux, des retours
> d'expériences à partager ?
>
> merci à tous,
> jérôme
>
> ---
> 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/


--
Fabien VINCENT
_@beufanet_


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

Re: [FRnOG] [FRNOG][TECH] Network Access Control

[Fabien VINCENT FrNOG via frnog]

Le 01-09-2020 20:46, Philippe Bourcier a écrit :

Bonsoir,

802.1x sans client lourd ca fonctionne parfaitement et ca se déploie
rapidement...
C'était mon approche favorite jusqu'au Covid.

Cela me parait un meilleur investissement de considérer que le LAN 
n'est plus un réseau de

confiance (approche Zero Trust)
et que l'utilisateur doive être connecté en VPN en interne comme en 
externe (always on).


Mais j'avoue que je trouve ca vraiment sexy comme approche de faire du
"tous en VPN", d'autant que les clients VPNs sont bien au point pour
ce qui est du suivi/validation des mises à jour AV/OS pré-connexion...
Je trouve que c'est une très bonne idée.


Oui encore faut il que ce soit transparent le plus possible pour 
l'utilisateur.


En 2008 je deployai des Juniper NetScreen SA Avec du Stormshield et des 
clés RSA SecureID. C'était cool, ça marchait bien... Pour un geek.


Le problème c'est qu'il faut que ce soit un max transparent pour le end 
user pour éviter le problème d'interface chaise clavier. Avec le 
télétravail post covid, je pense que les difficultés des services de 
support end user doivent s'être complexifiées.


Bref, encore une fois, je le vois pas sous cet angle. Pour moi, 
sécuriser un réseau physique = 802.1x. sécuriser un réseau logique / 
périmètre et des clients de plus en plus nomades (donc pas sur le réseau 
physique) = firewall / détection d'application / client vpn un peu plus 
lourd pour renforcer les mesures avant la connexion.


Rien n'empêche d'ajouter l'un a l'autre, 802.1x peut être transparent 
pour le end user.







Cordialement,
--
Philippe Bourcier
web : http://sysctl.org/
blog : https://www.linkedin.com/today/author/philippebourcier


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


--
Fabien VINCENT
_@beufanet_


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

Re: [FRnOG] [TECH] Drop des paquets L3VPN / Nexthop unusable : nolabel

[Fabien VINCENT FrNOG via frnog]

Hello,

Je suis pas sûr d'avoir tout saisi (avec des bouts de conf c'est tjs dur 
de debug)


Quelle est la config de ton process router OSPF ? De ta loopback1 ?

Tu redistribues ta loopback connected dans BGP l'AFI/SAFI IPV4/Unicast 
de ta VRF ? Du genre :


router bgp 199167
 address-family ipv4 vrf BACKBONE
  redistribute connected (route-map blabla)

Quelle est la config de tes VRF ?

Ta table de fwd mpls est vide ou pas ?

Le 02-10-2020 15:11, Nicolas Even a écrit :

Bonjour à tous,

Je me permets ce message car je bloque sur un problème technique que
je n'arrive pas à résoudre malgré mes efforts.
En gros, je n'arrive pas à faire fonctionner les L3VPN depuis et vers
un nouveau PE en cisco CSR1000-v.


J'ai deux routeurs connectés ainsi :

R1(P)  R2(PE)
Lo : 1.1.1.1/32Lo : 2.2.2.2/32
vlan2017 : 10.61.61.57/30 ---  Gi1 : 10.61.61.58/30
Lo1 (vrf BACKBONE) : 10.60.61.1/32 Lo1 (vrf BACKBONE) :
10.60.61.26/32


De chaque côté le routeur ospf est configuré.
Les interfaces sont configurées avec « mpls ip ».
Le mp-bgp est aussi configuré (comme tous les autres PE).
Je ne pas pinger la Lo1 de R2 depuis R1.


Sur R1 j'ai bien la route installée en vrf :

  R1#sh ip route vrf BACKBONE 10.60.61.26
  Routing Table: BACKBONE
  Routing entry for 10.60.61.26/32
Known via "bgp 199167", distance 200, metric 0, type internal
Last update from 2.2.2.2 01:21:18 ago
Routing Descriptor Blocks:
* 2.2.2.2 (default), from 2.2.2.2, 01:21:18 ago
Route metric is 0, traffic share count is 1
AS Hops 0
MPLS label: 186
MPLS Flags: MPLS Required



Mais la table mpls m'indique « drop » dans « Outgoing Interface ».

R1#sh mpls forwarding-table vrf BACKBONE 10.60.61.26
Local  Outgoing   Prefix   Bytes Label   Outgoing   
Next Hop

Label  Label  or Tunnel Id Switched  interface
None   18610.60.61.26/32[V]   \

   0 drop


Et Cef confirme le problème avec l'erreur « unusable : no label ».

R1#sh ip cef vrf BACKBONE 10.60.61.26 detail
10.60.61.26/32, epoch 0, flags [rib defined all labels]
  recursive via 2.2.2.2 label 186
nexthop 10.61.61.58 Vlan2017 unusable: no label


R1#sh mpls forwarding-table 10.61.61.58
Local  Outgoing   Prefix   Bytes Label   Outgoing   
Next Hop

Label  Label  or Tunnel Id Switched  interface
None   No Label   10.61.61.58/32   0 Vl2017 
10.61.61.58




Au niveau LDP, tout à l'air correct :

R1#sh mpls ldp discovery all
 Local LDP Identifier:
1.1.1.1:0
Discovery Sources:
Interfaces:

Vlan2017 (ldp): xmit/recv
LDP Id: 2.2.2.2:0


R2#sh mpls ldp discovery
 Local LDP Identifier:
2.2.2.2:0
Discovery Sources:
Interfaces:
GigabitEthernet1 (ldp): xmit/recv
LDP Id: 1.1.1.1:0


Est ce qu'une âme charitable saurait m'aiguiller sur le moyen de
régler ce problème ?

Merci.
Nicolas Even


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


--
Fabien VINCENT
_@beufanet_


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

Re: [FRnOG] [MISC] cas d'utilisation 5G

[Fabien VINCENT FrNOG via frnog]

Le 29-09-2020 12:57, David Ponzone a écrit :
Le 29 sept. 2020 à 12:44, Sébastien Lesimple 
 a écrit :



Exemple d'annonce par les politiques:
Dept 61, 100% éligible en 2023.



Alors je pense que je te bats.
Cédric O vient d’annoncer 550M€ pour couvrir 100% du territoire en 2025 
non ?


Sur ce sujet, Seb Soriano dit: "Nous serons aux rendez-vous du 8
mégabits pour tous en 2020, et du 30 mégabits pour tous fin 2022. Dans
le cadre du plan de relance, le gouvernement vient de décider d’aller
au bout du chantier de la fibre, en apportant cette technologie à tous
les Français d’ici 2025. C’est une grande nouvelle. Sur les cinq
dernières années, le secteur a construit 16 millions de lignes. La
moitié des foyers et des entreprises ont déjà été desservis par la
fibre. Il reste 20 millions de lignes à construire, sachant que le
secteur en réalise 4 à 5 millions par an. Cet objectif est tout à fait
à notre portée. »


La moitié des foyers et des entreprises ??? Mais d'où sort ce chiffre ? 
Ca sent la poudre de perlimpinpin, non ?




8Mbps pour tous en 2020…h….et 20 millions de lignes en 5 ans, ça
me semble ambitieux mais bon, je suis pas un spécialiste.


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


--
Fabien VINCENT
_@beufanet_


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

Re: [FRnOG] [TECH] SR(-TE) MPLS

[Fabien VINCENT FrNOG via frnog]

Je me réponds à moi même (personne ne fait de SR-(TE)-MPLS en FR ? Moi 
qui croyait que certains SP l'avaient déjà implémenté WW ^^)


Je me suis effectivement emmêlé les pinceaux (mode n00b), le principe de 
dynamic LSP avec coloration / on-demand semble uniquement possiblement 
avec un PCE type ODL, ou avec MP-BGP, mais pas directement possible avec 
l'IGP (OSPFv2 ici en l'occurrence). Quelqu'un pour me confirmer / 
infirmer ça ? Il est donc obligatoire de faire des interfaces tunnels, 
qu'elles soient automatiques (auto-tunnel P2P) ou statiques sans PCE ? 
Pas possible de faire du on-demand policy SR localement ?


Pour l'unnumbered, il y a bien une limitation qui faisait que cela ne 
fonctionnait pas comme voulu en statique, et c'est subtile :  Utiliser 
l'unnumbered sur l'interface Tunnel TE/MPLS en IOS-XE engendre une 
impossibilité de faire du dynamic dans les path options !

https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/seg_routing/configuration/xe-16-12/segrt-xe-16-12-book/sr-te-ospf.html#con_1056159

Voila, si des gens maquettent/font du SR avec des interfaces Tunnel 
MPLS-TE, ou avec des LSP on-demand, je suis intéressé par votre feedback 
ou par des corrections !


Le 21-09-2020 21:50, Fabien VINCENT FrNOG  via frnog a écrit :

Hello la liste,

J'ai un petit lab pour tester / appréhender un peu mieux la magic hype
de SR avec TE (Fwding MPLS) sur CSR1000v tournant sous IOS-XE/16.12
(Gibraltar) (pas si hype, mais mon idée chez SR-MPLS first, on verra
SRv6 avec XR plus tard :p)

SR basé sur IGP avec SR preferred fonctionne à priori parfaitement 
bien.


R1#show segment-routing attributes
ipv4
  sr_label_preferred : Yes
  explicit_null : No

R1#show mpls traffic-eng segment-routing summary
IGP Area[1]:  ospf 1  area 0, Strict SPF Disabled:
Nodes:
IGP Id: 192.168.0.0, MPLS TE Id: 192.168.0.0, OSPF area 0
   3 links with segment-routing adjacency SID
IGP Id: 192.168.0.1, MPLS TE Id: 192.168.0.1, OSPF area 0
   2 links with segment-routing adjacency SID
IGP Id: 192.168.0.2, MPLS TE Id: 192.168.0.2, OSPF area 0
   3 links with segment-routing adjacency SID
IGP Id: 192.168.0.4, MPLS TE Id: 192.168.0.4, OSPF area 0
   2 links with segment-routing adjacency SID
Prefixes:
 192.168.0.0/32, SID index: 1000
 192.168.0.1/32, SID index: 1
 192.168.0.2/32, SID index: 2
 192.168.0.4/32, SID index: 4
Total:
  Node Count : 4
  Adjacency-SID Count: 20
  Prefix-SID Count   : 4
Grand Total:
  Node Count : 4
  Adjacency-SID Count: 20
  Prefix-SID Count   : 4
  IGP Areas Count: 1

Que ce soit en mode auto tunnel P2P ou avec un tunnel pré-configuré en
unnumbered Loopback0, aucun soucis de forwarding MPLS / règles de TE,
je peux faire ce que je veux et ce qu'il me plaît, soit avec des
routes static + auto-tunnel + explicit path, soit en tunnel static +
explicit path comme ci dessous.

R1#sh ip explicit-paths name H2_VIA_R0
PATH H2_VIA_R0 (strict source route, path complete, generation 6)
1: next-address 192.168.0.0
2: next-address 192.168.0.2
10: next-label 2
20: next-label 20002

R1#sh mpls traffic-eng tunnels tunnel 2

Name: R1_t2   (Tunnel2) Destination: 
192.168.0.2

  Status:
Admin: up Oper: up Path: valid   Signalling: 
connected
path option 10, (SEGMENT-ROUTING) type explicit H2_VIA_R0 (Basis 
for Setup)


  Config Parameters:
Bandwidth: 0kbps (Global)  Priority: 6  6   Affinity: 
0x0/0x

Metric Type: IGP (interface)
Path Selection:
 Protection: any (default)
Path-selection Tiebreaker:
  Global: not set   Tunnel Specific: not set   Effective: min-fill 
(default)
Hop Limit: disabled [ignore: Explicit Path Option with all Strict 
Hops]

Cost Limit: disabled
Path-invalidation timeout: 1 msec (default), Action: Tear
AutoRoute: enabled  LockDown: disabled Loadshare: 0 [0] bw-based
auto-bw: disabled
Fault-OAM: disabled, Wrap-Protection: disabled, Wrap-Capable: No
  Active Path Option Parameters:
State: explicit path option 10 is active
BandwidthOverride: disabled  LockDown: disabled  Verbatim: disabled

  History:
Tunnel:
  Time since created: 13 minutes, 45 seconds
  Time since path change: 13 minutes, 11 seconds
  Number of LSP IDs (Tun_Instances) used: 11
Current LSP: [ID: 11]
  Uptime: 13 minutes, 11 seconds
  Tun_Instance: 11
  Segment-Routing Path Info (ospf 1  area 0)
Segment0[Node]: 192.168.0.0, Label: 26000
Segment1[Node]: 192.168.0.2, Label: 25002
Segment2[ - ]: Label: 2
Segment3[ - ]: Label: 20002

(Ne pas être trop exigeant sur les Node/Link/Label utilisés, c'est du
test, donc forcément pas toujours très propre)

En revanche, dès que j'essaie de configurer des politiques /
coloration pour privilégier la métrique TE over IGP, j'ai toujours 2
problèmes majeurs

R1#show segment-routing traffic-eng policy all

Name: foo (Color: 102 End-point: 192.168.0.2)
  Status:
Admin: up, Operational: down for 00

Re: [FRnOG] [TECH] SR(-TE) MPLS

[Fabien VINCENT FrNOG via frnog]

Pour être plus explicite, le problème vient de SR-TE policy sous IOS-XE. 
Je m'en vais tester sous IOS-XR en ce moment même mais voici le détail 
du problème :


R1#sh run | beg ^segment-routing t
segment-routing traffic-eng
 interface GigabitEthernet1
  metric 10
 interface GigabitEthernet2
  metric 100
 interface GigabitEthernet3
  metric 100
 logging policy status
 policy H2
  color 2 end-point 192.168.0.2
  binding-sid mpls 15002
  candidate-paths
   preference 200
dynamic
 metric
  type igp
!
   preference 100
dynamic
 metric
  type te
!
   !
  !
 !
!

Un check rapide de la politique retourne toujours le même problème :

R1#show segment-routing traffic-eng policy all

Name: H2 (Color: 2 End-point: 192.168.0.2)
  Status:
Admin: up, Operational: down for 00:26:35 (since 09-23 12:13:00.445)
  Candidate-paths:
Preference 200:
  Dynamic (inactive)
Inactive Reason: source address is not specified
Weight: 0, Metric Type: IGP
Preference 100:
  Dynamic (inactive)
Inactive Reason: source address is not specified
Weight: 0, Metric Type: TE
  Attributes:
Binding SID: 15002
  Allocation mode: explicit
  State: Init


En static / auto-tunnel (static route LSP) ca fonctionne sans soucis. 
Une idée de l'origine du "source address is not specified" ?


Encore merci pour les retours de certains en PV ;)

Le 23-09-2020 13:40, Fabien VINCENT FrNOG  via frnog a écrit :

Je me réponds à moi même (personne ne fait de SR-(TE)-MPLS en FR ? Moi
qui croyait que certains SP l'avaient déjà implémenté WW ^^)

Je me suis effectivement emmêlé les pinceaux (mode n00b), le principe
de dynamic LSP avec coloration / on-demand semble uniquement
possiblement avec un PCE type ODL, ou avec MP-BGP, mais pas
directement possible avec l'IGP (OSPFv2 ici en l'occurrence).
Quelqu'un pour me confirmer / infirmer ça ? Il est donc obligatoire de
faire des interfaces tunnels, qu'elles soient automatiques
(auto-tunnel P2P) ou statiques sans PCE ? Pas possible de faire du
on-demand policy SR localement ?

Pour l'unnumbered, il y a bien une limitation qui faisait que cela ne
fonctionnait pas comme voulu en statique, et c'est subtile :  Utiliser
l'unnumbered sur l'interface Tunnel TE/MPLS en IOS-XE engendre une
impossibilité de faire du dynamic dans les path options !
https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/seg_routing/configuration/xe-16-12/segrt-xe-16-12-book/sr-te-ospf.html#con_1056159

Voila, si des gens maquettent/font du SR avec des interfaces Tunnel
MPLS-TE, ou avec des LSP on-demand, je suis intéressé par votre
feedback ou par des corrections !

Le 21-09-2020 21:50, Fabien VINCENT FrNOG  via frnog a écrit :

Hello la liste,

J'ai un petit lab pour tester / appréhender un peu mieux la magic hype
de SR avec TE (Fwding MPLS) sur CSR1000v tournant sous IOS-XE/16.12
(Gibraltar) (pas si hype, mais mon idée chez SR-MPLS first, on verra
SRv6 avec XR plus tard :p)

SR basé sur IGP avec SR preferred fonctionne à priori parfaitement 
bien.


R1#show segment-routing attributes
ipv4
  sr_label_preferred : Yes
  explicit_null : No

R1#show mpls traffic-eng segment-routing summary
IGP Area[1]:  ospf 1  area 0, Strict SPF Disabled:
Nodes:
IGP Id: 192.168.0.0, MPLS TE Id: 192.168.0.0, OSPF area 0
   3 links with segment-routing adjacency SID
IGP Id: 192.168.0.1, MPLS TE Id: 192.168.0.1, OSPF area 0
   2 links with segment-routing adjacency SID
IGP Id: 192.168.0.2, MPLS TE Id: 192.168.0.2, OSPF area 0
   3 links with segment-routing adjacency SID
IGP Id: 192.168.0.4, MPLS TE Id: 192.168.0.4, OSPF area 0
   2 links with segment-routing adjacency SID
Prefixes:
 192.168.0.0/32, SID index: 1000
 192.168.0.1/32, SID index: 1
 192.168.0.2/32, SID index: 2
 192.168.0.4/32, SID index: 4
Total:
  Node Count : 4
  Adjacency-SID Count: 20
  Prefix-SID Count   : 4
Grand Total:
  Node Count : 4
  Adjacency-SID Count: 20
  Prefix-SID Count   : 4
  IGP Areas Count: 1

Que ce soit en mode auto tunnel P2P ou avec un tunnel pré-configuré en
unnumbered Loopback0, aucun soucis de forwarding MPLS / règles de TE,
je peux faire ce que je veux et ce qu'il me plaît, soit avec des
routes static + auto-tunnel + explicit path, soit en tunnel static +
explicit path comme ci dessous.

R1#sh ip explicit-paths name H2_VIA_R0
PATH H2_VIA_R0 (strict source route, path complete, generation 6)
1: next-address 192.168.0.0
2: next-address 192.168.0.2
10: next-label 2
20: next-label 20002

R1#sh mpls traffic-eng tunnels tunnel 2

Name: R1_t2   (Tunnel2) Destination: 
192.168.0.2

  Status:
Admin: up Oper: up Path: valid   Signalling: 
connected
path option 10, (SEGMENT-ROUTING) type explicit H2_VIA_R0 (Basis 
for Setup)


  Config Parameters:
Bandwidth: 0kbps (Global)  Priority: 6  6   Affinity: 
0x0/0x

Metric Type: IGP (interface)
Path Selection:
 Protection: an

[FRnOG] [TECH] SR(-TE) MPLS

[Fabien VINCENT FrNOG via frnog]

Hello la liste,

J'ai un petit lab pour tester / appréhender un peu mieux la magic hype 
de SR avec TE (Fwding MPLS) sur CSR1000v tournant sous IOS-XE/16.12 
(Gibraltar) (pas si hype, mais mon idée chez SR-MPLS first, on verra 
SRv6 avec XR plus tard :p)


SR basé sur IGP avec SR preferred fonctionne à priori parfaitement bien.

R1#show segment-routing attributes
ipv4
  sr_label_preferred : Yes
  explicit_null : No

R1#show mpls traffic-eng segment-routing summary
IGP Area[1]:  ospf 1  area 0, Strict SPF Disabled:
Nodes:
IGP Id: 192.168.0.0, MPLS TE Id: 192.168.0.0, OSPF area 0
   3 links with segment-routing adjacency SID
IGP Id: 192.168.0.1, MPLS TE Id: 192.168.0.1, OSPF area 0
   2 links with segment-routing adjacency SID
IGP Id: 192.168.0.2, MPLS TE Id: 192.168.0.2, OSPF area 0
   3 links with segment-routing adjacency SID
IGP Id: 192.168.0.4, MPLS TE Id: 192.168.0.4, OSPF area 0
   2 links with segment-routing adjacency SID
Prefixes:
 192.168.0.0/32, SID index: 1000
 192.168.0.1/32, SID index: 1
 192.168.0.2/32, SID index: 2
 192.168.0.4/32, SID index: 4
Total:
  Node Count : 4
  Adjacency-SID Count: 20
  Prefix-SID Count   : 4
Grand Total:
  Node Count : 4
  Adjacency-SID Count: 20
  Prefix-SID Count   : 4
  IGP Areas Count: 1

Que ce soit en mode auto tunnel P2P ou avec un tunnel pré-configuré en 
unnumbered Loopback0, aucun soucis de forwarding MPLS / règles de TE, je 
peux faire ce que je veux et ce qu'il me plaît, soit avec des routes 
static + auto-tunnel + explicit path, soit en tunnel static + explicit 
path comme ci dessous.


R1#sh ip explicit-paths name H2_VIA_R0
PATH H2_VIA_R0 (strict source route, path complete, generation 6)
1: next-address 192.168.0.0
2: next-address 192.168.0.2
10: next-label 2
20: next-label 20002

R1#sh mpls traffic-eng tunnels tunnel 2

Name: R1_t2   (Tunnel2) Destination: 
192.168.0.2

  Status:
Admin: up Oper: up Path: valid   Signalling: 
connected
path option 10, (SEGMENT-ROUTING) type explicit H2_VIA_R0 (Basis for 
Setup)


  Config Parameters:
Bandwidth: 0kbps (Global)  Priority: 6  6   Affinity: 
0x0/0x

Metric Type: IGP (interface)
Path Selection:
 Protection: any (default)
Path-selection Tiebreaker:
  Global: not set   Tunnel Specific: not set   Effective: min-fill 
(default)
Hop Limit: disabled [ignore: Explicit Path Option with all Strict 
Hops]

Cost Limit: disabled
Path-invalidation timeout: 1 msec (default), Action: Tear
AutoRoute: enabled  LockDown: disabled Loadshare: 0 [0] bw-based
auto-bw: disabled
Fault-OAM: disabled, Wrap-Protection: disabled, Wrap-Capable: No
  Active Path Option Parameters:
State: explicit path option 10 is active
BandwidthOverride: disabled  LockDown: disabled  Verbatim: disabled

  History:
Tunnel:
  Time since created: 13 minutes, 45 seconds
  Time since path change: 13 minutes, 11 seconds
  Number of LSP IDs (Tun_Instances) used: 11
Current LSP: [ID: 11]
  Uptime: 13 minutes, 11 seconds
  Tun_Instance: 11
  Segment-Routing Path Info (ospf 1  area 0)
Segment0[Node]: 192.168.0.0, Label: 26000
Segment1[Node]: 192.168.0.2, Label: 25002
Segment2[ - ]: Label: 2
Segment3[ - ]: Label: 20002

(Ne pas être trop exigeant sur les Node/Link/Label utilisés, c'est du 
test, donc forcément pas toujours très propre)


En revanche, dès que j'essaie de configurer des politiques / coloration 
pour privilégier la métrique TE over IGP, j'ai toujours 2 problèmes 
majeurs


R1#show segment-routing traffic-eng policy all

Name: foo (Color: 102 End-point: 192.168.0.2)
  Status:
Admin: up, Operational: down for 00:00:12 (since 09-21 19:33:11.215)
  Candidate-paths:
Preference 200:
  Dynamic (inactive)
Inactive Reason: source address is not specified
Weight: 0, Metric Type: IGP
Preference 100:
  Dynamic (inactive)
Inactive Reason: source address is not specified
Weight: 0, Metric Type: TE
  Attributes:
Binding SID: 16002
  Allocation mode: explicit
  State: Init

Sauf que je ne trouve aucune doc mentionnant ce problème de "source 
address" (voir de cspf failed ??). Ca me semble lié à l'unnumbered sous 
IOS-XE, mais soit je suis aveugle, soit j'ai le syndrome tête dans le 
guidon. Est ce que quelqu'un à déjà mis en place de la coloration de 
traffic / policy TE avec SR MPLS sous IOS-XE ? Y aun petit truc de 
config que j'ai zappé ?


Est ce que je me trompe de voie ? J'ai loupé une logique quelque part ?

Merci d'avance pour l'aide ;)

Je vais tenter sous IOSXRv, mais la RAM de mon laptop pourrait vous dire 
merci :)


++
--
Fabien VINCENT
_@beufanet_


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

Re: [FRnOG] [TECH] Choix de routeur en 2020

[Fabien VINCENT FrNOG via frnog]

Le 07-07-2020 09:13, Xavier Beaudouin a écrit :

Hello,


Le 7 juil. 2020 à 07:23, Xavier Beaudouin  a écrit :

Pour moi c'est vraiment un truc qui m'as arrêté sur les choix (ça et 
le

call-home,
nommé "smart licensing" qui est une bombe a retardement pour une 
infra).




Faut juste pas le mettre à jour en IOS 17, comme je l’ai dit tantôt :)


Tout a fait, mais bon un jour ils vont nous faire le coup de la mise a
jour obligatoire
en IOS 17 genre avec un tout nouveau modèle de cartes qu'ils 
distribuent...


Exemple avec l'IOS-XR 64Bits obligatoire alors que le 32Bit sur un
vrai OS RT (eg pas
un linux...) qui ne pouvais pas marcher sur certaines cartes.


Ca ca vient d'un choix d'architecture de cartes / CPU en PowerPC 
(ASR9001 / cartes typhoon) qui ne supportent QUE le x32 qu'ils ont en 
effet abandonné sur IOS-XR à partir de la v7. Ca rend effectivement le 
choix vers ASR9001 un peu obsolète si on se soucie de IOS-XR v7.


Je trouve que le passer en x64 était un choix meilleur pour l'écosystème 
et la cohérence avec l'autre gamme NCS, après comme toutes les 
évolutions, quand y en a pas on râle, quand y en a, on râle aussi. C'est 
vrai qu'on est sur FRnog :)




Cisco est le spécialiste des coups bas sur ses équipements. Exemple
j'ai un asr1001 (non -X)
dans ma cave ou a priori l'EFI/rommon est fracassée, il me faudrait le
.bin du rommon pour
pouvoir le remettre en marche, mais ça ne se trouve pas.

Dommage, il pourris, le spare est impossible a trouver sans le reste
du chassis. Ca fait chier.

Xavier


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


--
Fabien VINCENT
_@beufanet_


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

Re: [FRnOG] [TECH] Firewall chez OVH

[Fabien VINCENT FrNOG via frnog]

Le 12-06-2020 00:38, Charley SEDEAU a écrit :

Hello,

Pour moi ce pare-feu là ne s’active que pendant une mitigation DDoS, a
moins de posséder l’option pro qui permet de mettre les IP en 
mitigation

permanente..

J’ai mal compris le truc ?



Oui et non ;) Si tu as pas de règles c'est quand l'antiDDoS qui 
déclenche. Si tu as des règles (20 par IP de mémoire), tu passes tjs par 
l'antiddos (mitigation permanente)


Donc oui avec ca il est possible de faire un firewall chez OVH, par 
contre, je ne sais pas si ca marche avec le routage publique de vRack, à 
tester !


Mais le mieux ca reste quand même de maitriser un firewall (pfSense ou 
iptables roots style) pour ne pas être limité par les 20 règles …



- Charley

Le ven. 12 juin 2020 à 00:31,  a écrit :


Bonjour,

quid du vRack firewall pour ce besoin ?
  https://docs.ovh.com/fr/dedicated/firewall-network/


- Mail original -
De: "Olivier Lange" 
À: "Bruno LEAL DE SOUSA" 
Cc: "frnog-tech" 
Envoyé: Jeudi 11 Juin 2020 23:42:39
Objet: Re: [FRnOG] [TECH] Firewall chez OVH

Salut,

Tu prends une VM public cloud, et dessus tu installes pfsense ou 
routeros,

et tu la mets dans le cracks.

Où sinon tu mets des règles de dent sur tes interfaces public.

Olivier

Le jeu. 11 juin 2020 à 17:39, Bruno LEAL DE SOUSA <
bruno.ld.so...@gmail.com>
a écrit :

> Hello tout le monde !
>
> Je suis face à une petite problématique que beaucoup ont du avoir déjà...
> J'ai des serveurs dédiés chez OVH. Chaque serveur a donc une IP publique
et
> sont interconnectés sur un vlan grâce à leur solution vRack.
>
> Jusqu'à la tout est Ok ! Par contre pour des raisons de sécurité je ne
veux
> pas que me serveurs soient accessibles directement sur internet.. je
> voudrais les isoler derrière un Firewall typiquement afin de protéger le
> tout et d'ouvrir juste les ports nécessaires !
>
> En regardant les solutions possibles.. ou plutôt qui me viennent en tête
> j'avais par exemple le déploiement d'un firewall PfSense... mais pas
> possible sur un serveur dédié chez Ovh !
> La seule possibilité serait de prendre un serveur ESX ou une Infra vmware
> chez eux pour virtualiser le firewall ! Ça fait cher pour la conso que ça
> va représenter...
>
> Avez-vous des idées ?
>
> Merci beaucoup!
>
> Bruno LEAL DE SOUSA
> 06.01.23.45.96
>
> ---
> 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/



--
Fabien VINCENT
_@beufanet_


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

Re: [FRnOG] [TECH] 802.1x : FreeRADIUS OpenLDAP

[Fabien VINCENT FrNOG via frnog]

Je ne suis pas sur que FreeRadius sachent faire directement un attribut 
LDAP / OU => Radius VLAN ID dans ce cas précis, mais je n'ai jamais eu 
ce besoin directement.


Tu vas devoir passer par des groupes (huntgroups) pour matcher 
l'attribut ou l'OU et associer le VLAN ID dans ta config FreeRadius 
directement.


Dans mes souvenirs de FreeRadius, tu peux aussi faire ca dans le 
post-auth avec des if/else.


Si ca existe, je suis curieux de la méthode ! Donc n'hésites pas à 
partager ton feedback ;)


Le 07-01-2021 11:00, Christian VAN DER ZWAARD via frnog a écrit :

Si carrément.

Le but c’est d’avoir un numéro de VLAN par groupe sur l’annuaire LDAP
et qu’ensuite RADIUS récupère ce VLAN lors de la connexion de l’user
(qui est lui aussi dans l’annuaire).

--
Christian VAN DER ZWAARD
Le 7 janv. 2021 à 10:54 +0100, Adrien Rivas , a 
écrit :

Bonjour,

ça ne se joue pas justement au niveau des équipements sur la base de 
discriminants choisis tels que le groupe d'appartenance dans 
l'annuaire par exemple ?


J'ai fait ça avec de l'Aerohive, fortiswitch et AD Microsoft, tu 
choisis un vlan "poubelle" de base pour ceux qui ne sont pas 
"reconnus", et après selon que tu appartiens à un groupe ou à un 
autre, tu "montes en gamme"


> Le jeu. 7 janv. 2021 à 10:50, Christian VAN DER ZWAARD via frnog 
 a écrit :
> > J'utilise des switch Cisco 29xx et des points d’accès Wi-Fi Unify.
> > Mais ça importe peu pour l’instant car il faut déjà que je puisse récupérer 
le numéro de VLAN sur l’annuaire LDAP ^^
> >
> > --
> > Christian VAN DER ZWAARD
> > Le 7 janv. 2021 à 10:35 +0100, David Ponzone , a 
écrit :
> > > Sans indiquer ce que tu utilises comme switches, ça va pas être simple :)
> > >
> > > > Le 7 janv. 2021 à 10:31, Christian VAN DER ZWAARD via frnog 
 a écrit :
> > > >
> > > > Hello all,
> > > >
> > > > Je suis chargé de mettre en place de l’authentification et du VLAN 
assignment sur le réseau avec un serveur RADIUS et annuaire LDAP. J’ai choisi FreeRADIUS et 
OpenLDAP.
> > > > L’authentification fonctionne mais je sèche au niveau de l’attribution 
du VLAN.
> > > >
> > > > Je n’arrive pas à créer une nouvelle object class custom dans l’annuaire et je ne 
sais pas comment "dire" au RADIUS où il doit récupérer le numéro de VLAN.
> > > >
> > > > Je suis preneur si vous avez des liens intéressants à ce sujet.
> > > >
> > > > Merci d’avance pour vos réponses.
> > > >
> > > > Bien à vous,
> > >
> >
> > ---
> > Liste de diffusion du FRnOG
> > http://www.frnog.org/


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


--
Fabien VINCENT
_@beufanet_


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

Re: [FRnOG] [TECH] Cisco ASR, Arista 7150, OSPF et MTU

[Fabien VINCENT FrNOG via frnog]

Le 05-01-2021 13:57, Kevin Thiou a écrit :

Bonjour,

toujours dans mes problèmes de collecte sur cisco ASR.


Quel ASR ? Si c'est du IOS-XE ca devrait être la même MTU (mais je vois 
qu'apparement la MTU était manquante sur ton Arista).


Sur du IOS-XR, c'est parfois un peu plus tricky
https://www.cisco.com/c/en/us/support/docs/ios-nx-os-software/ios-xr-software/116350-trouble-ios-xr-mtu-00.html



J'essaie de faire en sorte de respecter les stas par exemple pour SFR
REFLEX il me faut une MTU à 2000 sur toute la chaîne.

Je collecte sur un Arista 7150, sur lequel la MTU est à 9124.
Le trafic est envoyé vers mes Cisco ASR (interco 10G entre Arista et 
CIsco)


J'ai essayé de passer la MTU entre le cisco et le arista à 9124.

Mais OSPF n'est pas content :

*DD MTU is too large*

La solution c'est de faire un *ip ospf ignore mtu*.
!! Si quelqu'un a une autre solution je suis preneur !!

et là j'ai un autre message d'erreur que je ne comprends pas trop :

adjacency dropped: nbr did not list our router ID, state was: EXCH 
START



Conf Cisco :
interface TenGigabitEthernet0/2/0
 mtu 9214
 no ip address
interface TenGigabitEthernet0/2/0.86
 encapsulation dot1Q 86
 ip address 172.16.70.76 255.255.255.254
 ip ospf network point-to-point
 no lldp transmit
 no lldp receive
!
router ospf 1
 router-id 2.2.2.2
 auto-cost reference-bandwidth 1000
 passive-interface default
 no passive-interface TenGigabitEthernet0/2/0.86
 network 172.16.70.76 0.0.0.1 area 0

Conf arista:
interface Vlan86
   ip address 172.16.70.77/31
   ip ospf network point-to-point
!
router ospf 1
   router-id 1.1.1.1
   auto-cost reference-bandwidth 1000
   passive-interface default
   no passive-interface Vlan86
   network 172.16.70.76/31 area 0.0.0.0
   max-lsa 12000
   graceful-restart
interface Ethernet39
   switchport trunk allowed vlan 14,86,88,216,221-222
   switchport mode trunk
   ip ospf mtu-ignore

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


--
Fabien VINCENT
_@beufanet_


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

Re: [FRnOG] [TECH] Sessions TCP restant ouvertes après un switch BGP

[Fabien VINCENT FrNOG via frnog]

Quand tu dis routeur C c'est du Juniper, il fait quoi ? Routeur ? 
Firewall ?


Ça ressemble à un grand classique d'une table de sessions quelque part 
sur une boite sur le chemin (firewall qui offloade le TCP dans un 
ASIC/NP, load-balancer quelque part) ?


Je ne connais pas assez bien Juniper pour t'aider mais je dirais que si 
il y a perte de la route, le routeur devrait switch le trafic sur le 
path suivant, mais si tu rajoutes le VPN et donc potentiellement des 
SA/SP dans la boucle, tu as peut être un offload des paquets à chiffrer 
ou tout simplement des sessions TCP sur un type firewall ?


T'as 2 trucs qui peuvent se télescoper la. Mais j'irais chercher de ce 
que côté la, surtout si en ICMP / UDP tu ne constates pas le soucis.


Le 01-02-2021 16:28, Mickael Hubert a écrit :


Bonjour à tous,
j'ai un petit souci de sessions TCP restant actives après un switch de 
BGP. Pour infos ces 2 sessions sont à l'intérieur de tunnels IPSEC VTI.
Je ne parle pas des sessions TCP du BGP en lui-même, mais de trafic TCP 
classique en fait.


L'infra :

Il y a 2 sessions BGP (1 par DC), les 2 connectées, avec une route map 
pour forcer le trafic a passer par un des 2 tunnels.
Le failover BGP se fait très bien, un nouveau trafic passera 
correctement par le tunnel encore UP (standy -> active).
Mais les sessions TCP déjà ouvertes entre le serveur C et les serveurs 
A ou B restent actives sur le serveur C. Pourtant, le routeur VPN C 
voit bien les sessions TCP comme closed.


Il faut attendre un timeout sur le serveur C pour qu'il initie de 
nouvelles sessions TCP, mais c'est 8 mins de downtime  chaud pour 
du failover ...


Pour info le serveur C c'est un SBC Oracle qui fait du SIP TCP (pas 
possible de repasser en SIP UDP, trop facile ;) )...

Le routeur VPN C c'est du Juniper.

Avez-vous déjà vu ce genre de phénomène ? J'imagine bien qu'il faut 
changer  le timer TCP sur l'Oracle, mais c'est à priori chaud pour mon 
client.
N'y a-t'il pas un moyen sur un Juniper de balancer du TCP/RST lors 
d'une coupure de VPN ou autre palliatif ?


Merci d'avance pour votre aide !

++


--
Fabien VINCENT
_@beufanet_
---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [TECH] choix transitaires

[Fabien VINCENT FrNOG via frnog]

quels sont vos retours d’expérience sur les
différents « gros » que sont lumen / gtt / telia ?


Cogent et Telia sont très compétents au niveau du support de mes 
souvenirs. Tu trouveras toujours des contre exemples, mais j'ai toujours 
eu du feedback cohérent lors de  mes questions, tant sur le support que 
le provisionning. Côté Lumen, on va dire que c'est un peu comme 
l'agrume. Avant de tomber sur la bonne personne tu auras rebooté ton 
routeur 12x. Tu auras attendu 4 mois ta livraison ;) Mais cela n'empêche 
pas que leur transit est "qualitatif", surtout pour du FR et surtout US. 
GTT je sais pas, j'ai souvenir du bon travail d'Interoute à l'époque, 
mais aujourd'hui je ne sais pas.


Comme l'a dit quelqu'un, il ne faut pas envisager que du T1. Il y a des 
très bons T2 ou parfois des opérateurs locaux qui sauront t'apporter 
autant de qualité / support et peut être seront + réactifs en cas de 
soucis (par exemple DDoS ou autre). Mais pour choisir un bon T2, il faut 
savoir qui sont tes clients pour savoir ce que tu cherches comme 
source/destination, et trouver le plus approprié. Les looking glass ou 
ripe atlas sont la pour faire un peu de recherche (souvent les T1 sont 
peu enclins à partager leurs politiques de peering/transit avec les 
autres, souvent sous NDA).



preneur…. J’hésite notamment à leur demander l’option d’un lien double
sur mes deux dc. Je me dis que le surcoût est peut être négligeable et
ça peut aider beaucoup en cas de souci…


Attention, lien double != routeur double. si en face c'est le même 
routeur, alors tu redondes que le fait du tech qui débranche le mauvais 
patch en MMR ;) souvent les maintenances vont par site, donc si ca casse 
tout casse sur le même site. Et souvent l'opérateur se cache bien de te 
le dire.



monté ma boîte y’a 10 ans si j’avais peur :D) mais est-ce que
justement certains tier1 gèrent mieux / plus de souplesse / meilleur
support force de conseils sur la partie bgp ?


une session BGP c'est une session BGP. C'est "standard". On pourrait 
ajouter RPKI et le respect des BCP38 dans la balance, mais franchement, 
on va dire que c'est la base que devrait être un T1 aujourd'hui. Voir 
mon conseil plus bas sur la partie BGP.



Pour ce qui est du ddos est-ce que certains ici traitent ça a
l’extérieur (type nawas / neustar / corero) ? J’essaye d’avoir une
bonne protection sans pour autant me faire exploser d’entrée de jeu au
niveau coûts alors que je ne fais que commencer cette activité (mais
je veux la débuter propre)… l’achat ou la prise en leasing de boîtiers
me semble pas adaptée au besoin.


De toute façon, dis toi que si ton DDoS est pas géré en amont, il faut 
le gérer chez toi. Ca suggère d'avoir beaucoup de capa entrante 
disponible. Certains DDoS aujourd'hui peuvent avoir des flows > 10Gbps 
(bon pas pour tout le monde heureusement). Mais globalement, pour 
démarrer, c'est toujours mieux d'avoir le moyen de déclencher une 
mitigation sur ton uplink en amont que d'essayer de le faire rentrer 
chez toi et le blackhole / flowspec. Quand tu auras gagné plein 
d'argent, tu pourras t'acheter une boite qui scrubbe ce trafic ou le 
divert.


Bon courage pour le démarrage de ton activité ! Il y a aussi sûrement 
plein de gens sur la liste qui ont les compétences de t'aider à démarrer 
je pense rapidement avec une assistance et éviter les écueils du transit 
/ monter une "infra BGP".



Le 11-06-2021 06:06, Romain BAFFERT a écrit :

Bonjour à tous,

(Disclaimer : bien qu’ayant pas mal d’expérience réseaux / Cablage /
infra / sécurité etc depuis une vingtaine d’années, je débute dans le
domaine telco / ISP en datacenter ;) )

Contexte : je bâtis notre offre opérateur / hébergeur et je pars sur
un principe (peut être idiot; arguments pour ou contres bienvenus) de
partir en mode « parano » ou « geek puriste » et de raccorder mon
infra sur deux dc différents avec un Tier1 différent sur chaque, en
doublant tout si possible.


Indépendamment de leurs politiques commerciales (ça semble être les
soldes en fin de trimestre, on me baisse le prix chaque semaine pour
que je commande ;) ) quels sont vos retours d’expérience sur les
différents « gros » que sont lumen / gtt / telia ? Y’a t’il de vraies
différences techniques / support / pratiques / relationnelles qui
excluent certains ? J’ai déjà exclu (a tord ou à raison ?) cogent par
les retours que j’en ai eu + le fait qu’ils n’ont pas tout internet
ipv6 et que ça sent mauvais de partie avec une rustine…

En gros ils me pondent tous des prix assez similaires et en pleine
dégringolade pour du giga de commit sur 10 giga. Si certains petits /
débutants ici ont des conseils suivant leur expérience je suis
preneur…. J’hésite notamment à leur demander l’option d’un lien double
sur mes deux dc. Je me dis que le surcoût est peut être négligeable et
ça peut aider beaucoup en cas de souci…

D’un point de vue contrat, vu que les prix dégringolent chaque année,
que négociez vous quand vous entrez chez un fournisseur ? Réévaluation

Re: [FRnOG] [MISC] SDN (Software Defined Networking): Bullshit ou réalité ?

[Fabien VINCENT FrNOG via frnog]

Le 21-05-2021 09:33, David Ponzone a écrit :

Chouette, une bataille d’acronyme.



Je ne crois pas avoir vu l'IBN :D



Et je crois que j’en ai un qui a été oublié……le vCPE!
Et le uCPE aussi.

Un bel article de 2019 bien bullshit avec des prospectives faites en 
2015:

https://blogdigital.beijaflore.com/vcpe-virtualisation-reseaux/


Le 21 mai 2021 à 09:22, Remi Desgrange  
a écrit :


Moi avec l'émergence du "edge computing" (aka, "le pc dans le placard, 
mais

géré par un cloud provider") j'attends le "SDN At The Edge" :-)

Tiens est-ce que les ROADM c'est du SDN ? Est-ce que des gens utilise 
ça en

vrais ?

On Fri, May 21, 2021 at 9:18 AM Nicolas Vuillermet 


wrote:




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


--
Fabien VINCENT
_@beufanet_


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

Re: [FRnOG] [MISC] SDN (Software Defined Networking): Bullshit ou réalité ?

[Fabien VINCENT FrNOG via frnog]

Bonjour,

Wikipedia non ? Pour éviter de lancer une trollchain :D

<...>
C'est un ensemble de technologies ayant comme points communs :
1. un contrôle centralisé des ressources réseau ;
2. une orchestration centralisée ;
3. une virtualisation des ressources physiques.
<...>

Le 2 a déjà été évoqué (ansible, automation tout ca tout ca). Le 3, tout 
le monde le voit tous les jours, bye bye le HW chiant, vive les VMs, les 
dockers les k8s. (bon ca tourne toujours sur un proc qui n'est pas 
quantique mais c'est abstrait c'est déjà ca)


Le 1 par contre c'est le truc le plus touchy et fourre tout. On te vend 
du SDx pour tout et n'importe quoi. En vrai, y a un vrai sujet de 
centralisation du control plane (voir du côté d'OpenFlow, de 
OpenDaylight, des technos comme SR ou des RR out of the path pour BGP). 
Bref, c'est plutôt un changement de paradigme du réseau dans la gestion 
de son controle plane de manière + centralisé. Il y a aussi le sujet de 
la désagrégation avec la séparation du HW et du SW avec les whitebox 
(Sonic ou même les constructeurs comme Arista/Nokia qui vendent des SW 
now sur du HW tier)


Donc pour moi SDN ca veut "rien dire". Parce que c'est un ensemble de 
technos que les marketeux ne comprendront pas ;) Et on peut pas leur en 
vouloir ! Heureusement ca n'a jamais remplacé le métier d'ingé' réseau 
;) Voir même ca l'a renforcé ! Plus qu'IPv6 :D


Juste mon avis, peu d'envie d'en débattre si j'ai raison ou pas, à part 
peut être avec un commercial qui vendrait une solution SDx ^^


Mon point de vue trollesque est : SDN c'est Still Does Nothing. Moi je 
travaille sur du RDN, Real Defined Network :p Tu trouveras personne qui 
a la même définition du SDN parce que ca ne représente rien de manière 
unitaire technologiquement parlant. On peut faire un peu la même chose 
avec le Zero Trust ces derniers mois ;)



Le 20-05-2021 12:54, Cécile MORANGE a écrit :

Hello la liste ! Je commence à me renseigner sur le SDN et je me suis
dit que ce serait sympa d'écrire un article sur mon blog
(blog.ataxya.net) à propos de ça. Vu que sur internet je trouve
beaucoup plus de présentations commerciales que d'avis réels sur la
solution, je me suis dit que j'allais demander à mon groupe d'expert
préféré ce qu'il pense de cette techno. Mes questions sont donc : -
Pourquoi passer au SDN ? - Il y a-t-il un réel intérêt de passer au
SDN ? (Hormis l'aspect commercial) - En avez-vous déjà mis en place ?
Comment ça s'est passé ? Avez-vous remarqué un réel changement dans la
façon de faire vos réseaux ? (et du gain de temps ?) - Pensez vous que
dans 5,10,20 ans, tous les réseaux seront du SDN ? Je suis à l'écoute
de tous vos retours, ça me permettra de mieux comprendre le SDN et
l'intérêt (s'il y en a un) !
(Je sens que je vais lancer un long thread plein de débats :D)
Merci d'avance !

Cordialement,


--
Fabien VINCENT
_@beufanet_


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

Re: [FRnOG] [TECH] Le prix des adresses IPv4

[Fabien VINCENT FrNOG via frnog]

C'est beaucoup plus large je pense, un extrait ici :

https://toonk.io/aws-and-their-billions-in-ipv4-addresses/

Je n'ai jamais cherché, mais peut être il est possible de savoir qui a 
des /8 sur les RIR ?


Le 29-06-2021 17:27, Vincent Habchi a écrit :

Apple, HP, Xerox ont des classes A je crois.

Plus le DoD.

Il doit y en avoir d’autres.

V.


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


--
Fabien VINCENT
_@beufanet_


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

Re: [FRnOG] [TECH] Re: VRF-Lite process OSPF

[Fabien VINCENT FrNOG via frnog]

De rien. Techniquement c'est cool, j'ai découvert un nouveau sujet grâce 
à toi ;) C'est tout ce que j'aime en réseau, il n'y a jamais de fin dans 
les apprentissages, même quand on commence à avoir des cheveux blancs xD


Le 02-07-2021 09:45, Kevin Thiou a écrit :


Je ne l'ai pas maquetté et je n'ai pas de quoi le maquetter rapidement.
C'est pour cela que j'ai posé la question car j'imaginais que quelqu'un 
aurait déjà tenté l'expérience.


Je me suis effectivement dit qu'avec un seul process OSPF il y aurait 
des problèmes de route dupliqué avec moulte vrf-lit accrochées.


Merci pour les retours, merci Fabien pour toutes ces bonnes raisons de 
ne pas (pouvoir) le faire.


Le ven. 2 juil. 2021 à 00:15, Fabien VINCENT FrNOG via frnog 
 a écrit :



Ma compréhension de ta question est un peu difficile sans
contexte/archi. Mais il peut y avoir des réponses simples et ta 
question

m'a intrigué (#LaPassion)

Un ID de process OSPF n'a d'existence que local (i.e. tu peux avoir 12 
à

un endroit et 15 à un endroit, ça empêchera pas une adjacence, dans la
plupart des cas). Tout comme les VRF-LITE d'ailleurs qui ne 
nécessitent

pas d'identifiant unique (coucou RD auto/default).

Maintenant si je devais le faire, je séparerai pour respecter le
raisonnement suivant :
- Séparation logique "humaine" plus claire, ça évite les erreurs bêtes
et le "fat-finger".
- Séparation "logicielle". Si tu dois clear ton process OSPF, tu 
cleares

pas toutes tes VRFs, mais un process qui tourne dans une VRF.
- Séparation OSPF plus explicite. Dans le cas du numéro, ça déclare un
process logiciel distinct (peut être que c'est virtuel, mais ca se
constate, cf le "sh proc cpu" ci dessous). Si il y a en qui crashe, 
tout

le monde n'est pas embarqué.

R3#sh proc cpu | i OSPF
386  10 606 16  0.00%  0.00%  0.00%   0 OSPF-1
Router
513   8 350 22  0.07%  0.00%  0.00%   0 OSPF-1
Hello
544   6 540 11  0.00%  0.00%  0.00%   0 OSPF-2
Router
582   0   1  0  0.00%  0.00%  0.00%   0 OSPF-2
Hello

Ensuite si on passe à est ce que c'est possible, j'ai été curieux et
j'ai testé sur IOS-XE 16.12.02 et ça ne semble pas possible de le 
faire

de toute façon :

R3(config)# vrf definition vrf1
R3(config-vrf)# address-family ipv4 unicast

R3(config-vrf-af)#vrf definition vrf2
R3(config-vrf)#address-family ipv4 unicast

R3(config-vrf-af)#router ospf 1
R3(config-router)#router-id 1.1.1.1

R3(config)#router ospf 1 vrf vrf1
%VRF specified does not match existing router

Même si tu essaies de créer une VRF sur le même process sans la VRF 
par

défaut:

R3(config-router)#no router ospf 1

R3(config)#router ospf 1 vrf vrf1
R3(config-router)#router-id 1.1.1.1
R3(config-router)#exit

R3(config)#router ospf 1 vrf vrf2
%VRF specified does not match existing router
R3(config)#

Le process est bien créé sur la vrf vrf1 cependant:
R3#sh ip ospf  | i ID|VRF
Routing Process "ospf 1" with ID 1.1.1.1
Domain ID type 0x0005, value 0.0.0.1
Connected to MPLS VPN Superbackbone, VRF vrf1

Mais il semble qu'il y ait une limitation qui semble liée aux VRF avec
l'usage de MPLS (cf le domain ID ? encore une découverte grâce à ta
question ! Je ne m'étais jamais demandé quel était l'usage de ce 
domain

ID, donc merci !)

Bref, moi je le ferai pas pour le raisonnement du début, et qui plus 
est

cela ne semble pas possible au moins sur un IOS-XE "récent".

Curieux de savoir sur quoi ça fonctionne si tu l'as maquetté et ce qui
t'amènerai à choisir cette solution.

@+

Le 01-07-2021 12:00, Kevin Thiou a écrit :

Pour clarifier,

quel avantage y a t il a créé un process ospf indépendant :
*router ospf 1*
*router ospf 2 vrf xyz*

plutôt que juste une instance ospf rattachée à la vrf mais dans le 
même

process :
*router ospf 1*
*router ospf 1 vrf xyz*

Le jeu. 1 juil. 2021 à 11:54, Kevin Thiou  a
écrit :


Bonjour,

Est-il nécessaire dans un environnement multi-VRF-Lite (pas de 
couche

MPLS) de dissocier les process OSPF pour chaque VRF sur les PE ?

Si oui pour quelle raison ?

Merci



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


--
Fabien VINCENT
_@beufanet_

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


--
Fabien VINCENT
_@beufanet_
---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [TECH] Re: VRF-Lite process OSPF

[Fabien VINCENT FrNOG via frnog]

Ma compréhension de ta question est un peu difficile sans 
contexte/archi. Mais il peut y avoir des réponses simples et ta question 
m'a intrigué (#LaPassion)


Un ID de process OSPF n'a d'existence que local (i.e. tu peux avoir 12 à 
un endroit et 15 à un endroit, ça empêchera pas une adjacence, dans la 
plupart des cas). Tout comme les VRF-LITE d'ailleurs qui ne nécessitent 
pas d'identifiant unique (coucou RD auto/default).


Maintenant si je devais le faire, je séparerai pour respecter le 
raisonnement suivant :
- Séparation logique "humaine" plus claire, ça évite les erreurs bêtes 
et le "fat-finger".
- Séparation "logicielle". Si tu dois clear ton process OSPF, tu cleares 
pas toutes tes VRFs, mais un process qui tourne dans une VRF.
- Séparation OSPF plus explicite. Dans le cas du numéro, ça déclare un 
process logiciel distinct (peut être que c'est virtuel, mais ca se 
constate, cf le "sh proc cpu" ci dessous). Si il y a en qui crashe, tout 
le monde n'est pas embarqué.


R3#sh proc cpu | i OSPF
 386  10 606 16  0.00%  0.00%  0.00%   0 OSPF-1 
Router
 513   8 350 22  0.07%  0.00%  0.00%   0 OSPF-1 
Hello
 544   6 540 11  0.00%  0.00%  0.00%   0 OSPF-2 
Router
 582   0   1  0  0.00%  0.00%  0.00%   0 OSPF-2 
Hello


Ensuite si on passe à est ce que c'est possible, j'ai été curieux et 
j'ai testé sur IOS-XE 16.12.02 et ça ne semble pas possible de le faire 
de toute façon :


R3(config)# vrf definition vrf1
R3(config-vrf)# address-family ipv4 unicast

R3(config-vrf-af)#vrf definition vrf2
R3(config-vrf)#address-family ipv4 unicast

R3(config-vrf-af)#router ospf 1
R3(config-router)#router-id 1.1.1.1

R3(config)#router ospf 1 vrf vrf1
%VRF specified does not match existing router

Même si tu essaies de créer une VRF sur le même process sans la VRF par 
défaut:


R3(config-router)#no router ospf 1

R3(config)#router ospf 1 vrf vrf1
R3(config-router)#router-id 1.1.1.1
R3(config-router)#exit

R3(config)#router ospf 1 vrf vrf2
%VRF specified does not match existing router
R3(config)#

Le process est bien créé sur la vrf vrf1 cependant:
R3#sh ip ospf  | i ID|VRF
 Routing Process "ospf 1" with ID 1.1.1.1
   Domain ID type 0x0005, value 0.0.0.1
 Connected to MPLS VPN Superbackbone, VRF vrf1

Mais il semble qu'il y ait une limitation qui semble liée aux VRF avec 
l'usage de MPLS (cf le domain ID ? encore une découverte grâce à ta 
question ! Je ne m'étais jamais demandé quel était l'usage de ce domain 
ID, donc merci !)


Bref, moi je le ferai pas pour le raisonnement du début, et qui plus est 
cela ne semble pas possible au moins sur un IOS-XE "récent".


Curieux de savoir sur quoi ça fonctionne si tu l'as maquetté et ce qui 
t’amènerai à choisir cette solution.


@+

Le 01-07-2021 12:00, Kevin Thiou a écrit :

Pour clarifier,

quel avantage y a t il a créé un process ospf indépendant :
*router ospf 1*
*router ospf 2 vrf xyz*

plutôt que juste une instance ospf rattachée à la vrf mais dans le même
process :
*router ospf 1*
*router ospf 1 vrf xyz*

Le jeu. 1 juil. 2021 à 11:54, Kevin Thiou  a 
écrit :



Bonjour,

Est-il nécessaire dans un environnement multi-VRF-Lite (pas de couche
MPLS) de dissocier les process OSPF pour chaque VRF sur les PE ?

Si oui pour quelle raison ?

Merci



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


--
Fabien VINCENT
_@beufanet_


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

[FRnOG] [MISC] Ubiquiti fuite de donnée plus importante qu'annoncé

[Fabien VINCENT FrNOG via frnog]

Hello,

Il ne faut pas non plus exagérer et rester factuel. Je ne souhaite pas 
prendre la défense d'une marque qui fait des plutôt bon produits, mais 
juste éviter de tout mélanger.


Personnellement, je n'ai jamais eu à avoir de compte ui pour configurer 
mes APs et mon contrôleur, auto hébergé. Peut être qu'il y a des cas 
produits ou c'est obligatoire. Mais ce n'est pas parce que tu 
centralises que tu donnes tes comptes à un provider.


Et puis honnêtement, celui qui ne s'est jamais fait troué lève la main ! 
Et sans être une cible de choix. A savoir qu'ils proposent également du 
2FA, ce qui n'est pas le cas de tout le monde !


Donc c'est pas parce que tu vas centraliser la gestion de ton wifi sur 
un contrôleur cloud, que tu peux en plus auto héberger (ou instantier 
chez toi), que tu cours à l'échec sécurité.


Bref, c'est moche pour eux. Mais c'est pas pour ca que la centralisation 
n'a que du mauvais.


Le 02-04-2021 14:47, Wallace a écrit :
Actualité du jour, une personne qui a participé aux audits de sécurité 
a

décidé de parler car la marque aurait sous-évalué les risques.

https://www.zdnet.com/article/whistleblower-claims-ubiquiti-networks-data-breach-was-catastrophic/

Content de pas avoir cédé à cette mode de centraliser les 
configurations

avec tout le monde et en plus sur AWS.


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


--
Fabien VINCENT
_@beufanet_


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

Re: [FRnOG] [TECH] Question bête Cisco IOS / BGP / Flapping / Dampening

[Fabien VINCENT FrNOG via frnog]

Le 02-03-2021 19:08, Michel Py via frnog a écrit :

Paul Rolland a écrit :
Le nombre de messages BGP recus ? sho ip b s (ou equiv) te donne ca,
ainsi que le nombre de messages en In Queue... ca peut etre une piste


Ben justement c'est ce que j'ai fait, sh ip bgp sum et regarder
l'évolution de MsgRcvd.


Ca serait pas plutôt InQ à regarder ?

J'ai déjà eu pas le passé des peers qui m'ont tapé suite à l'activation 
de BMP sur la session qui a pété des 7200 en face à cause du 
route-refresh demandé par le collector BMP pour construire l'ADJ-RIB-IN 
des routeurs avec du BMP dessus.


Dans mes souvenirs le peer l'avait catché avec le InQ qui s'accumulait 
et une charge CPU élevée.


Sinon je crois que tu peux faire un truc du genre :

access-list 100 permit ip host A.B.C.D host W.X.Y.Z
debug ip bgp update 100
debug ip bgp x.x.x.x update

Pour limiter ton debug ...


Et j'ai dépairé celui qui ne causait aucun problème, et en plus il lit
cette liste.
Aie Aie pas taper, pas taper. C'était pas vraiment le volume, plutôt
la nature de ce qui arrivait.

Ce n'est que plus tard que j'ai regardé debug, et comme beaucoup le
savent, debug sur un vieux bouc qui est déjà au taquet c'est
dangereux, vaut mieux avoir "u all" dans une autre session avec juste
à appuyer sur Entrée.

Michel.


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


--
Fabien VINCENT
_@beufanet_


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

Re: [FRnOG] [TECH] [SMTP] outlook.com bloque online.net ?

[Fabien VINCENT FrNOG via frnog]

Même soucis avec Scaleway il y a qq semaines/mois (même AS12876 
qu'Online of course).


Le truc débile dans ces cas là, je pense, c'est que les services qui se 
basent sur des RBL prennent le subnet complet annoncé / object route si 
une ou plusieurs IPs sont blacklistés. Bon bein si t'annonces un /16 ca 
fait 65000+ potentielles victimes d'un effet collatéral. J'ai hate de 
voir l'effet du passage à IPv6 pour la fin de vie des RBL ? :p


Sinon, la fois dernière, j'ai fait le formulaire + appui du support 
Scaleway, ca a roulé, en moins de 5 jours c'était fixé.


Bigup à SCW pour le fixe rapide et le bon échange côté support (c'est 
pas toujours le cas niveau suivi / compétence / rapidité du support pour 
tous ;)


Le 22-08-2021 20:01, Archange a écrit :

Le 22/08/2021 à 21:44, Pavel Polyakov via frnog a écrit :

Babz  wrote:


Je lis pas très bien le language Microsoft, mais je crois que ça veux
dire "va te faire foutre"

Non c'est bon tu peux répondre, un blaireau va prendre le relai et
enlever l'IP de la blacklist.

Ça marche très bien quand tu demandes pourquoi l'IP était dans la
blacklist en premier lieu. :)


Je suis passé par cette étape, j’ai eu le droit à :

because Hotmail customers have reported email from this IP as 
unwanted.


J’ai répondu que ça n’était pas possible puisque je possédais l’IP
depuis plus d’un an et qu’elle n’envoyait pas de mail avant le mail
même où j’ai eu le problème (le premier envoi depuis cette IP
comprenait une adresse @outlook). C’est là qu’on m’a demandé une
facture prouvant depuis quand je louais le serveur, et que je n’ai
plus eu de retours depuis que je l’ai envoyée (mais le problème
persiste donc)…

Et à chaque mail on a un nouveau mec en face (Varsha, Suresh, Anand…),
donc un bon suivi du ticket…

Bref, de temps en temps il faut probablement faire la procédure
plusieurs fois avant que ça finisse par fonctionner.


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


--
Fabien VINCENT
_@beufanet_


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

Re: [FRnOG] [TECH] Boîtiers de chiffrement sur câble Ethernet passant par milieu non fiable

[Fabien VINCENT FrNOG via frnog]

+1 sur le MACSec si ton switch le permet. Sur du Cat9200 tu peux faire 
du MACSec, mais ca te fait un x5 à x10 en budget ;)


Le chiffrement IPSec sinon. Mais tu as déjà quoté le prix ;)

Le 17-08-2021 19:35, Gregory CAUCHIE a écrit :

Thales (ex SAFEnet) propose ce genre de boîtier, mais le prix sera
surement trop élevé vu que la perf permet de monter à très haut débit
(quasi-)sans introduction de latence.

Autrement, pas possible de faire du MACsec entre tes switch ?

--
Grégory

On 17 Aug 2021, at 19:13, Benoit Chesneau  
wrote:


hrm pq ne pas mettre a un bout un simple proxy https et connecter les 
clients en https dessus? la connection seraient ainsi chiffrée de bout 
en bout. avec un boitier mikrotik a un bout. sinon deux boitiers 
mikrotik hex ou plus et un tunnel?


Benoît Chesneau, Enki Multimedia

On Tue, Aug 17, 2021 at 18:37, DUVERGIER Claude 
 wrote:



Bonjour la liste,

J'aurais besoin de relier au réseau LAN un petit local un peu 
excentré des autres locaux de l'immeuble.
Problème : je dois passer par les parties communes de l'immeuble pour 
les relier...


Les besoins de débit sont très faibles (du web sur 4/5 stations de 
travail) donc un simple câble RJ45 suffira, mais avoir mon LAN qui 
sort, en clair, de "ma propriété" n'est pas une option.


Je cherche donc 2 boîtiers à placer de part et d'autres du câble pour 
assurer un chiffrement des communications qui y transite.


La solution basique mais qui nécessite de la maintenance : 2x mini 
ordis avec 2 port Ethernet + du OPNsense qui chiffre/déchiffre le 
trafic (via IPSec, OpenVPN, etc.) pour faire routeur entre les 2.


Ça représente environ 560€ avec des APU2E0 de PC Engines, et moins si 
je trouve des ordis plus simples et/ou de récup'.


Sinon je fais un pont WiFi (via. 2 bornes Ubiquiti par exempe)... qui 
offre son chiffrement, mais c'est quand même ballot d'utiliser le 
802.11 juste pour sa capacité à chiffrer alors que j'ai la 
possibilité de tirer un câble cat 7. Là par contre le coût baisse trs 
fortement.


Mais je me dit que ça doit bien exister en boîtier tout fait/dédié, 
pour moins cher...


Le plus proche que j'ai trouvé via mon Google-fu c'est ce "IP-DOOR" 
de CXR Anderson Jacobson : 
https://www.cxr.com/documents/brochures/ip_door.pdf

Mais le produit ne semble plus en vente...

Bref : auriez-vous un produit magique similaire en tête ?

Merci

--
DUVERGIER Claude

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



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


--
Fabien VINCENT
_@beufanet_


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

Re: [FRnOG] [TECH] Problème IPv6 entre Google et Free (et peut-être d'autres)

[Fabien VINCENT FrNOG via frnog]

Il semble bien la chez OTI pourtant ;)

BGP IPv6 from Marseille, France to 2a00:1450:4007::
Path BGP Nexthop BGP Prefix  AS Path
1   2001:67c:128c::30   2a00:1450:4007::/48 15169
2   2001:67c:128c::60   2a00:1450:4007::/48 15169
3   2001:688:0:1::152a00:1450:4007::/48 15169
4   2001:688:0:1::642a00:1450:4007::/48 15169
5   2001:688:0:1::782a00:1450:4007::/48 15169
6   2001:4860:1:1::138  2a00:1450:4007::/48 15169
7   2001:4860:1:1::15e  2a00:1450:4007::/48 15169
8   2001:4860:1:1::160  2a00:1450:4007::/48 15169
9   2001:4860:1:1::832  2a00:1450:4007::/48 15169
10  2001:4860:1:1::868  2a00:1450:4007::/48 15169

Ca serait intéressant d'avoir l'explication de Google !

Le 13-09-2021 15:36, Pierre-E a écrit :

Hello,

Je viens de vérifier sur le lg de $job, et aucune route vers
2a00:1450:4007::/48.
Surement un problème côté Google…Je vais voir pour ouvrir un ticket
chez eux de mon côté.

On 13 Sep 2021, at 13:57, Stephane Bortzmeyer  
wrote:


Depuis au moins hier soir, certains préfixes Google comme le
2a00:1450:4007::/48 ne semblent plus joignables depuis Free (il y a un
pingable en 2a00:1450:4007:811::2004). Comme Google renvoie des
adresses dans ce préfixe aux abonnés Free, c'est ennuyeux.

Détails en . Quelqu'un a un
contact qui va bien pour ce genre de problèmes ?


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



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


--
Fabien VINCENT
_@beufanet_


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

Re: [FRnOG] [MISC] libreNMS

[Fabien VINCENT FrNOG via frnog]

Tout pareil en ce lundi matin :(

Malheureusement, c'est bien parfois ce qui ridiculise la communauté 
FrNOG. Des "vieux" qui savent tout mieux que tout le monde et des trolls 
de "djeuns" en pagaille (je ne m'exclue pas du raisonnement, je 
constate). C'est dommage car pas du tout à l'image de la qualité et 
compétence des gens en Fr, sur cette liste que je peux connaître. Et 
malheureux de voir que l'on ne trouve du répondant (en masse) que sur 
les sujets non-techs (j'ai peu de sujets techniques qui ont été suivis 
de manière qualitative sur cette liste).


C'est dommage, parce que je suis pour le troll et la possibilité de tout 
dire. Si c'était de l'humour il fallait probablement le préciser avec un 
smiley. Ou alors aller troller sur la plateforme qui est faite pour ça.


Le 29-11-2021 08:55, Antoine Meillet a écrit :
Outre le respect de l'autre qui a visiblement été oublié, j'espère 
qu'il
est sûr de la véracité et de la complétude de sa source (dernière mise 
à

jour en 2017)

On Mon 29 Nov 2021 at 08:49, Remi Desgrange 


wrote:


+1 avec Vincent.

On Mon, Nov 29, 2021 at 8:06 AM Vincent Bernat  
wrote:


>  ❦ 29 November 2021 03:17 GMT, Michel Py via frnog:
>
> >> Cécile Martron
> >> CCIE Datacenter
> >> Ingénieure Systéme Réseaux et Télécommunication
> >> +33 (0) 6 85 44 33 38
> >
> > Euh, juste par curiosité, c'est quoi ton numéro de CCIE ?
> >
> > Le mien, c'est #6673
> > https://www.cciehof.com/
> >
> > Gougleu "cecile martron ccie" : resultat zero sauf _une_ contrib sur
> > cette liste. C'est bien de se toucher le clitoris en rêvant qu'un jour
> > on va devenir CCIE, mais passer le lab c'est une autre histoire.
>
> Je suis toujours impressionné comment tu parviens à repousser
> régulièrement les limites de l'indécence sur cette liste.
> --
> Use the fundamental control flow constructs.
> - The Elements of Programming Style (Kernighan & Plauger)
>
>
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/
>


--
Cordialement, Rémi Desgrange

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



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


--
Fabien VINCENT
_@beufanet_


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

Re: [FRnOG] [MISC] Russie / Monde

[Fabien VINCENT FrNOG via frnog]

Heureusement qu'on est sur FrNOG et qu'on est des experts réseaux + 
fusion nucléaire.


Sans vouloir être désobligeant, faites vous un chat privé ou une autre 
ML. Pour le reste, il y a tout ce qui faut en réseaux sociaux non ?


(PS : la limite de la discussion intéressante étant bien sur les 
réseaux, si supposés qu'il y ait quelque chose de nouveau sur la Russie 
à ce niveau la).


Merci d'avance et bon vendredi.

Le 24-02-2022 17:44, frnog.kap...@antichef.net a écrit :
On jeudi 24 février 2022 17:15:14 CET David Ponzone - 
david.ponz...@gmail.com

wrote:
Non, pas du tout, j’essaie de savoir comment  tu arrives à déterminer 
un
truc aussi violent avec autant de certitude, alors que ça fait 
plusieurs

jours que j’écoute/lis des experts/spécialistes de toute bord en
géopolitique, en économie, globale ou de l’Ukraine en particulier, et
aucune n’a osé avoir une théorie aussi manichéenne.


On est d'accord que tout ne se résume pas uniquement au gaz, il y a 
sans aucun

doute d'autres éléments[1] mais le gaz semble être le principal.

Je ne suis pourtant ni expert, ni spécialiste mais la question du gaz 
ce n'est

pas un puzzle qui est difficile à assembler soi-même.

C'est pas vraiment nouveau, tu peux lire cet article du monde diplo:
Comment saboter un gazoduc, Forcing américain pour supplanter les 
livraisons

russes: https://www.monde-diplomatique.fr/2021/05/RIMBERT/63053
Ukraine, pourquoi la crise, Les Européens hors jeu:
https://www.monde-diplomatique.fr/2022/02/TEURTRIE/64373

Et ça a été rappelé en trame de fond depuis janvier:
par exemple:
https://www.latribune.fr/economie/international/les-etats-unis-premiers-exportateurs-mondial-de-gnl-disputent-le-marche-europeen-du-gaz-aux-russes-899738.html

ou plus récemment comment le président US a spécifiquement désigné le 
gazoduc

nord stream 2 dans les menaces si la Russie envahissait l'Ukraine:
https://www.lefigaro.fr/flash-eco/ukraine-biden-pret-a-condamner-nord-stream-2-scholz-reste-plus-evasif-20220207

[1]: par exemple la question du complexe militaro industriel et de la 
récente
relance de la course à l'armement, notamment nucléaire, ou du 
déploiement de

bases militaires.


> Le 24 févr. 2022 à 17:07, Stéphane Rivière  a écrit :
>
> Le 24/02/2022 à 17:05, David Ponzone a écrit :
>> C’est pas un peu complotiste ça ?
>
> Le problème avec ce genre de commentaire, c'est que ça ferme l'échange et
> la réflexion.
>
> Bonne soirée :)

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







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


--
Fabien VINCENT
_@beufanet_


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

Re: [FRnOG] [MISC] Russie / Monde

[Fabien VINCENT FrNOG via frnog]

C'est quand même génial tout ce spectacle sur les cables sous marins, là 
ou un simple clic sur une CLS suffit à couper. Heureusement qu'à chaque 
fois qu'un filet ou tout évènement arrache un cable sous marin, le monde 
ne part pas en guerre.


Bref, cette histoire, c'est du vrai spectacle. Je vois vraiment pas 
stratégiquement ce qui a de si fou la dedans, sachant que si tu veux 
couper l'accès à l'info, tu commences par autre chose.


La ou ca deviendrait intéressant cette histoire de cables, c'est sur du 
taping. Mais bon ca n'existe pas ;)


Le 27-02-2022 17:58, Nang Bat a écrit :

Pour ne parler que des cables, les russes ont un navire, le Yantar (et
deux sister-ships en construction) qui si on écoute les US pourraient
couper des cables en grand profondeur
(https://www.nytimes.com/2015/10/26/world/europe/russian-presence-near-undersea-cables-concerns-us.html?_r=0).
Et donc entre le positionnement dudit navire
(https://www.navalnews.com/naval-news/2021/08/russian-spy-ship-yantar-loitering-near-trans-atlantic-internet-cables/),
ce que le renseignement occidental prétend publiquement  et certaine
allégation récente
(https://lansinginstitute.org/2022/01/13/damage-to-svalsat-cable-proves-russia-further-upping-stakes/),
tout est imaginable... Après dans ce genre de circonstances s'imaginer
des trucs c'est clairement pas la meilleure solution pour se faire une
opinion sur la réalité des capacité technologique. Et concernant les
cables sous-marins entre l'ACMA et l'APMA, le nombre de câbliers
capable de faire des réparations qui couvrent la zone atlantique et la
diversité géographique des nouveaux cables (qui atterrissent en
Espagne et en France plutôt qu'en GB) il en faudrait du monde pour
réussir à saboter plus vite que les réparations (et que les
réparations sont standardisées - https://ujconsortium.com/).

Le dim. 27 févr. 2022 à 15:10, Stéphane Rivière  a 
écrit :


Le 27/02/2022 à 08:53, David Ponzone a écrit :
> La réplique russe tant crainte pourrait ne pas être ce qu’on croit:
>
> 
https://www.latribune.fr/economie/international/une-coupure-d-internet-par-la-russie-le-cauchemar-de-l-europe-904912.html
>
> Vous en pensez quoi ?

Regardant une carte de fibres sous-marines, la majorité des flux
semblent être EU <> GB <> USA <> ASIE. Les ficelles passent donc dans
deux océans contrôlés par les occidentaux.

Compte tenu du réseau d'hydrophones alliés dans ces océans et des
profondeurs qui rendent l'opération impossible sur l'essentiel du
trajet, les Russes devront alors intervenir sur des hauts fonds
particulièrement surveillés. Mais difficile ne veux pas dire 
impossible.


L'expression "cauchemar de l'Europe" pour des coupures de câbles sur 
un

réseau résilient semble donc assez sensationnaliste.

Émergeons des fonds sous-marins pour regarder les choses d'un peu plus
haut et voir où pourrait se situer le /vrai cauchemar pour l'Europe/.


D'un point de vue géostratégique et industriel, l'action de Poutine 
est

froidement pertinente.

Les étatsuniens n'auraient pas supporté de voir le Canada adhérer au
pacte de Varsovie.

Dans les accords de 1994 (de mémoire), les pays Baltes, la Pologne, la
Roumanie ou la Bulgarie s'interdisaient d'adhérer à l'OTAN. Après 
avoir

passé quelques décennies à hiberner, l'ours se Russe s'est réveillé.


Les européens, premier bloc économique et troisième bloc démographique
du monde, se complaisent à rester des nains politiques et militaires¹.

L'Europe politique n'a aucune légitimité démocratique et a bien 
démontré

son mépris pour son peuple et sa compromission financière la plus sale
avec les laboratoires qui ont engrangé plus de 130 Md € au jeu de la
peur primale. Le jackpot du siècle. D'ailleurs ça continue puisque 30 
M
doses sont commandées pour être vidées dans les bras des gens après 
des

élections - qui pourraient ne pas avoir lieu à la date prévue.

Les gens s'étant révélés prêt à tout pour retrouver la /mythique vie
d'avant/, on peut affirmer que l'acceptation de la /soumission/ et
l'appétence à l'/obéissance/ sont désormais, en Europe occidentale, 
des

sentiments majoritaires.


L'affaire étant réglée à l'intérieur, voilà que le chaos apparaît à
l'extérieur.

Poutine a observé la réaction des occidentaux covidisés. Ayant des 
amis

slaves (Roumains, Moldaves et Ukrainiens), j'affirme qu'ils n'ont pas
une bonne opinion de ce qui s'est passé ces deux dernières années chez
nous. Ils nous traitent (poliment) de /fous/. Au sens où ils ne
/comprennent pas/. D'autant plus qu'étant ni vaccinés ni morts mais
juste soignés avec des produits de base, ils ont "fact-checké" le 
story

telling de bigpharma puis continué leur vie.

La réaction stupéfiante des populations occidentales a pu apparaître
comme un blanc-seing. Avec Biden aux manettes, Poutine a peut-être
vraiment vu, à tord ou à raison, un open bar ukrainien.

C'est peut être même du billard à plusieurs bandes. Une certitude : 
les

étatsuniens ont, depuis longtemps, marre de raquer pour une Europe qui
ne 

Re: [FRnOG] [TECH] IOS XE et validation RPKI: Comportements étranges (bgp bestpath prefix-validate disable)

[Fabien VINCENT FrNOG via frnog]

Oui je crois que j'ai lu /répondu un peu vite à ton message.

En fait j'ai souvenir d'un truc que j'avais documenté sur IOS-XR qui 
m'avait déjà cassé les pieds. 
https://beufa.net/blog/rpki-use-routinator-rtr-cache-validator-cisco-ios-xr/


router bgp 64567
 !
 address-family ipv4 unicast
  bgp origin-as validation enable
  bgp bestpath origin-as use validity => ne semble pas dispo sur XE.
  bgp bestpath origin-as allow invalid
 !
 address-family ipv6 unicast
  bgp origin-as validation enable
  bgp bestpath origin-as use validity
  bgp bestpath origin-as allow invalid
 !

La seule doc que j'ai trouvé sur IOS-XE c'est assez vieux : 
https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/iproute_bgp/configuration/xe-3s/irg-xe-3s-book/bgp-origin-as-validation.pdf


Le comportement que tu rencontres est bien documenté :

During BGP best path selection, the default behavior, if neither of the 
above options is configured, is that the

system will prefer prefixes in the following order:
• Those with a validation state of valid.
• Those with a validation state of not found.
• Those with a validation state of invalid (which, by default, will not 
be installed in the routing table).
These preferences override metric, local preference, and other choices 
made during the bestpath computation.
The standard bestpath decision tree applies only if the validation state 
of the two paths is the same


Donc un valid c'est un tie breaker prioritaire sur le best selection 
path algorithm dans la selection BGP, ce qui est exactement ce que tu 
rencontres. Par contre effectivement, j'ai lu trop vite, mais si tu 
ajoutes le allow-invalid, ca va juste autoriser les invalid a être 
selected au lieu de drop dans le best path. Il manque donc le 
use-validity comme sur IOS-XR.


Sinon, ce que j'avais fait par le passé pour éviter les problèmes de BGP 
algorithm à la sauce cisco qui change sur des versions mineures (si,si) 
:

- route-map ou RPL
  - drop state invalid
  - 
  - if roa valid => local-pref ou med ++

et je désactive la feature de BGP best path selection n°1 qui tie break 
si ROV=valid>>>ROV=unknown


Bon courage, ca me rappelle pourquoi quelqu'un avait demandé la 
suppression des MAY dans les RFC :p


N'hésites pas à partager ta trouvaille.

Le 25-05-2022 16:20, Clement Cavadore a écrit :

Hello Fabien,

On Wed, 2022-05-25 at 09:30 +0200, Fabien VINCENT FrNOG via frnog

if the BGP—Origin AS Validation feature is
enabled, and you want to allow invalid prefixes
to be used as the best path, even if valid prefixes are available.
Thus, you have control over announcing invalid
networks, but preferring them less than valid and not-found
prefixes.
Also, the downstream peer can modify
path attributes based on a route map that matches invalid prefixes



Je ne suis pas devant mon cisco, mais pour le coup, ce ne sont pas des
"invalid" que je cherche à exploiter, juste des unknown. Il faudrait
que je regarde si la directive existe avec un "allow-unknown", pour le
coup, réponse ce soir :)

Merci,

Clément


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


--
Fabien VINCENT
_@beufanet_


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

Re: [FRnOG] [TECH] IOS XE et validation RPKI: Comportements étranges (bgp bestpath prefix-validate disable)

[Fabien VINCENT FrNOG via frnog]

Hola !

router bgp 
  address-family {ipv4 | ipv6} unicast
bgp bestpath prefix-validate allow-invalid

?

From the cisco doc :
Perform this task if the BGP—Origin AS Validation feature is enabled, 
and you want to allow invalid prefixes
to be used as the best path, even if valid prefixes are available. Thus, 
you have control over announcing invalid
networks, but preferring them less than valid and not-found prefixes. 
Also, the downstream peer can modify

path attributes based on a route map that matches invalid prefixes

Bon courage !

Le 25-05-2022 09:08, Clement Cavadore a écrit :

Hello,

Je suis confronté à un probleme étrange sur IOS XE. 

Voici le contexte:
- 1 ASR1002-X
- Qui fait de la validation RPKI sur les sessions eBGP (pas iBGP)
- Qui fait du peering sur un IXP
- Qui recoit ses routes du réseau depuis des RR (notamment des 
downstreams)


Par défaut, j'ai remarqué que l'état RPKI de la route était pris en
compte dans le BGP selection path, chose qui m'emmerde car si une route
recue en eBGP est valide, il la préfere à une route "unknown" recue en
IBGP, et ce même si la localpref est supérieure sur celle recue en
interne (car downstream):

Ici, en l'occurence, selon la localpref, il devrait plutot choisir la
premiere, mais par défaut, il choisit celle d'apres:


BGP routing table entry for 193.43.214.0/24, version 36202932
Paths: (8 available, best #7, table default)
 Advertised to update-groups:
16 17
 Refresh Epoch 1
 44097
   193.164.153.126 (metric 5020) from 193.164.153.2 (193.164.153.2)
 Origin incomplete, metric 500, localpref 600, valid, internal
 Community: 34019:44097 65512:20001
 Originator: 193.17.192.143, Cluster list: 193.164.153.2
 path 7F8057EB3658 RPKI State not found
 rx pathid: 0, tx pathid: 0
 Refresh Epoch 1
(...)
 43100 200780 44097
   91.206.52.207 from 91.206.52.252 (91.206.52.252)
 Origin IGP, metric 400, localpref 400, valid, external, best
 Community: 34019:65000 34019:65130 34019:65133 65512:20009
 unknown transitive attribute: flag 0xE0 type 0x20 length 0x24
   value  A5EC  FC00  000B  A5EC
  FC00  0015  A5EC  FC00
  001F
 path 7F805E0F0418 RPKI State valid
 rx pathid: 0, tx pathid: 0x0
 Refresh Epoch 1
(...)



Du coup, je me suis inspiré du lien suivant:
https://bgpfilterguide.nlnog.net/guides/reject_invalids/
... pour revoir ma conf, et rajouter "bgp bestpath prefix-validate
disable" dans la conf de mes address-family en BGP, en rajoutant un
statement dans mes route-map rejetant les rpki invalid, et ca semble...
juste désactiver RPKI. En effet, on ne voit plus du tout d'état RPKI,
alors que 1.1.1.0/24 est supposé être signé:



RPKI validation codes: V valid, I invalid, N Not found

 Network  Next HopMetric LocPrf Weight Path
*>   1.0.0.0/24   91.206.52.192  100400  0 13335 
i
*>   1.1.1.0/24   91.206.52.192  100400  0 13335 
i



BGP routing table entry for 1.1.1.0/24, version 27436194
Paths: (6 available, best #5, table default)
 Advertised to update-groups:
16 17
 Refresh Epoch 1
(...)
 13335, (aggregated by 13335 162.158.148.1)
   91.206.52.192 from 91.206.52.192 (162.158.148.1)
 Origin IGP, metric 100, localpref 400, valid, external, best
 Community: 34019:65000 34019:65130 34019:65131 65512:20009
 rx pathid: 0, tx pathid: 0x0
 Refresh Epoch 1


Une idée de comment faire en sorte que IOS XE fasse de la validation
RPKI proprement ?

A noter: Il n'est pas concevable de faire de la validation RPKI reçues
sur les routes en IBGP, car on reçoit des RR des more specific de nos
subnets (que l'on redistribue en BGP plutot qu'en ISIS), et il serait
contre productif de faire des ROA autorisant jusqu'au /32 + /128 de nos
supernets :)

Merci par avance pour vos lumières,


--
Fabien VINCENT
_@beufanet_


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