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/

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

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

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

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

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

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

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