Re: [FRnOG] [TECH]

[Jérôme Berthier via frnog]

Le 14/03/2024 à 17:59, donkish...@neuf.fr via frnog a écrit :
Existerait-il une solution de pont à base de wifi6(E) par exemple 
(j'aimerais bien dans les 1 à 10Gb/s stable sans latence pour 
l'interlink), qui serait un minimum orientable (pour ne pas trop 
perturber notre wifi d'entreprise) avec j'imagine un seul SSID pour 
maximiser les performances dans lequel nous pourrions faire passer les 
vlan de notre choix ?
Cela pourrait-il se faire avec une solution standard type Meraki pour 
un résultat satisfaisant similaire à une solution dédié en mettant 
juste une borne au plafond de chaque côté de la porte coup feu du 
plateau ? 


Salut,

Y a du passage au niveau de cette porte coupe feu ? elle est ouverte 
sauf détection incendie ? tu as suffisamment de hauteur pour mettre les 
AP en vis à vis sans obstacle dans leur champ (genre Michel de la compta 
avec ses trois mugs de café) ?


Je connais pas plus que ça mais Meraki semble bien proposer du bridging 
mesh : 
https://documentation.meraki.com/MR/Wi-Fi_Basics_and_Best_Practices/Extending_the_LAN_with_a_Wireless_Mesh_Link


Par curiosité, lu en travers (je connais pas :) ), il y a des 
dépendances entre la version soft et la possibilité de bridger plusieurs 
vlans sinon faut du L3 en aval du bridge et router sur l'uplink.


Pour le modèle de bornes, a priori, tous les modèles supportent le mesh 
: 
https://documentation.meraki.com/MR/Deployment_Guides/Mesh_Deployment_Guide#Access_Point_Capabilities


Il me semble qu'il vaut mieux éviter d'utiliser des AP standard avec 
antenne omni. Il faut des AP mesh avec antenne directionnelle (enfin ça 
parait préférable). En Wi-Fi 6E, tu as le modèle CW9166D1 qui intègre 
une antenne directionnelle.


Bon courage

--
Jérôme Berthier


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

Re: [FRnOG] [TECH] Configuration VPN sur Cisco

[Jérôme Berthier via frnog]

Le 12/03/2024 à 10:53, Lionel Giraudeau-Bocquet via frnog a écrit :
- trouver le moyen de récupérer le numéro du vlan en provenance de la 
MAC de la carte IPMI (et je suis certain que le switch a l'info 
quelque part, je ne sais juste pas comment lui faire cracher le morceau) 


Utiliser la fonction "Packet capture" intégrée au switch 3650 ?

https://www.cisco.com/c/en/us/td/docs/switches/lan/catalyst3650/software/release/37e/consolidated_guide/b_37e_consolidated_3650_cg/b_37e_consolidated_3650_cg_chapter_0110001.html

--
Jérôme Berthier


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

Re: [FRnOG] [TECH] UniFi - pilotage bornes légères UAP-AC-LITE

[Jérôme Berthier via frnog]

Le 22/01/2024 à 18:33, Vinz Jumpertz via frnog a écrit :
je vais poser la question qui fâche: quid de la RGPD? Est-ce vraiment 
nécessaire de collecter toutes ces données, car en cas de pépins ça va 
te retomber dessus. 


Je pense qu'on peut lancer une discussion dédiée. 

J'ai toujours entendu dire que fournir un accès Internet à un visiteur 
nécessite la traçabilité d'un opérateur fournissant le service équivalent.


Vrai ou pas, je trouve ça intéressant de pouvoir se dédouaner de 
certains usages s'ils étaient réalisés depuis une connexion à mon nom.


Pour avoir regarder un peu le RGPD pour d'autres contextes, sans être 
juriste donc sans garantie, je dirai que dans ce cas, la base légale est 
l'obligation légale du fournisseur de l'accès Wifi : 
https://www.cnil.fr/fr/les-bases-legales/obligation-legale


ça justifie la collecte qui doit effectivement être strictement limitée 
au nécessaire, pour la durée utile et être documentée d'un affichage 
l'expliquant y compris les recours possible pour accéder aux données 
récoltées.


En théorie, je crois qu'il faut aussi tenir un registre des traitements 
documentant pourquoi on stocke ces données et qui y a accès.  Bon, dans 
le cas d'un hébergement, des données y en a bien d'autres et tout le 
monde se fout de comment c'est géré... genre les copies de pièce 
d'identité, ça me fait toujours halluciner. Aparté, le service Filigrane 
est sympa pour ça : https://filigrane.beta.gouv.fr/


Pour en revenir au contenu à collecter, j'en suis resté décret 2006-358 
du 24 mars 2006 donc :


« a) Les informations permettant d’identifier l’utilisateur ;
« b) Les données relatives aux équipements terminaux de communication 
utilisés ;
« c) Les caractéristiques techniques ainsi que la date, l’horaire et la 
durée de chaque communication ;
« d) Les données relatives aux services complémentaires demandés ou 
utilisés et leurs fournisseurs ;
« e) Les données permettant d’identifier le ou les destinataires de la 
communication.


donc le triptyque user/MAC/accounting IP habituel...

Depuis je crois que ça a été confirmé par la (magnifique) loi n° 
2021-998 du 30 juillet 2021 relative à la prévention d'actes de 
terrorisme et au renseignement : 
https://www.legifrance.gouv.fr/codes/article_lc/LEGIARTI43887545


--
Jérôme Berthier


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

Re: [FRnOG] [TECH] UniFi - pilotage bornes légères UAP-AC-LITE

[Jérôme Berthier via frnog]

Le 22/01/2024 à 12:09, Pierre-Henry Muller via frnog a écrit :
Petit retour d'expérience, UI ne permet pas le niveau de détail que tu 
demandes.


Le réseau guest avec voucher ou avec portail, ne demande même pas les 
infos obligatoires que son nom / prénom / email, le portail ne peut 
être modifié sur ce point, seule les couleurs et les CGV peuvent être 
modifiées.


De plus même une dream machine qui fait office de firewall / routeur, 
lorsqu'on active le flux syslog vers un concentrateur, on ne reçoit 
pas le détail du traffic, assignation dhcp et autres infos 
intéressantes mais seulement les logs systèmes de la dream machine et 
des bornes ...



CQFD. Merci




Bilan on a viré notre wifi guest 


Oui mais en 2024, c'est pas une option pour des chambres d'hôtes. 

Je vais voir :

- soit pour intercaler un service de portail captif qui fera le job : 
Alcasar, CloudSpot, Ucopia (mais j'ai pas de canal d'achat) ou tout 
autre suggestion bienvenue


- soit pour ne pas compléter la base UniFi et partir sur autre chose qui 
ferait le job sans sortir des montagnes d'euro.


On me souffle TP-Link Omada (cité aussi mi décembre dans la discussion 
sur une problématique similaire). ça serait un équivalent de la logique 
UniFi mais les traces portail captif / trafic sont-elles correctes et 
exhaustives ?


--
Jérôme Berthier


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

Re: [FRnOG] [TECH] UniFi - pilotage bornes légères UAP-AC-LITE

[Jérôme Berthier via frnog]

Le 18/01/2024 à 23:01, David Ponzone a écrit :

Le 18 janv. 2024 à 22:52, Merwan Zenati  a écrit :

Hello

En effet les bornes sont managées avec un controller, pour du basique, si tu ne 
veux pas mettre de vrai firewall sur place, une cloud key fait amplement 
l’affaire (sinon tu peux héberger une vm Windows/linux avec un controller mais 
prix de l’instance + maintenance + gestion du fw si ip dynamique etc etc etc… 
prise de tête pour la taille)
Ce cloud key est manageable a distance (tu l’adopte dans console.ui.com si je 
dis pas de bêtise) donc c’est top.
Tu couple ça a un 8POE unifi (ou plus selon le besoin et le tour est joué)

Concernant ton wifi guest, unifi, c’est simple ! Tu setup ton lan guest sans « 
network », tu crée ton wifi dans « wifi » tu dis « c’est du guest » boom il 
isole lui même chaque périphérique connecté automatiquement…

Mais sauf erreur de ma part (j’ai éliminé tous les routeurs UI de la liste du 
possible il y a un moment), dans cette conf, tu n’as pas les logs des guests 
sur 12 mois.
C’est un produit US, donc ils connaissent pas trop nos petites contraintes UE 
(qui sont, il faut le dire, ubuesques).


Merci David pour cette remarque !

En relisant quelques docs et posts sur le forum UniFi, j'ai 
effectivement un gros doute aussi.


L'idée du déploiement est évidemment d'avoir la traçabilité entre le 
client (voucher hotspot) et son usage (terminal / trafic IP).


Il me faut donc la traçabilité :

- des connexions hotspot en pouvant faire le lien entre le 
client/voucher et son terminal (idéalement sur un an).


- du trafic en lien avec le terminal (idéalement le voucher donc le client)

Pour croiser tout ça, j'ai donc besoin des logs : sessions portail 
(client/voucher <-> MAC), MAC <-> DHCP, accounting IP (src / dst / 
ports...), translations NAT.


Je pensais que les gateways UniFi et la fonction Hotspot gérée dans 
Network Server permettaient d'avoir ça mais c'est franchement pas clair.


Je crois même comprendre le contraire en lisant le forum Community UniFi.

--
Jérôme Berthier

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

Re: [FRnOG] [TECH] UniFi - pilotage bornes légères UAP-AC-LITE

[Jérôme Berthier via frnog]

Le 14/01/2024 à 11:22, Paul Rolland (ポール・ロラン) a écrit :

5) y a des gateway qui intègrent UniFi Console qui permet d'instancier
UniFi Network Server ou de joindre le cloud UI

Oui. Ca peut d'ailleurs te permettre de recuperer une fonction "routeur"
(et donc la partie DHCP). Dans ta liste de materiel, tu as liste un switch
et les AP, mais pas de routeur... je suppose que tu prends celui qui vient
avec l'acces Internet ?



oui j'ai pas parlé de la partie routeur car par défaut, le gestionnaire 
pensait utiliser sa livebox.


Je lui ai exposé les limites de ça. Je pense qu'il a capté pourquoi ce 
serait utile de cloisonner un peu les usages.





IMHO, il te faut, pour etre bien:
  - un switch PoE, qui te fera l'alim de tes bornes. Et si il est Unifi, tu
le geres avec le reste dans ta console, genre le Lite 16PoE, qui te fait
16 ports, dont 8 avec PoE+, ce qui couvre tes 5 APs
  - une console on-site, qui te fera la brique "controleur", le DHCP, ...


OK grâce à vos différents retours, on a levé mes doutes sur l’enrôlement 
des bornes. Y a pas vraiment de contrôleur, c'est plutôt un manager. 
Chose plutôt pas mal, on peut remonter cette console locale dans le 
cloud UI, ce qui donne une vue distante de l'installation. ;)


On est rendu entre 6 et 8 APs selon les positionnements finaux 
(contraintes de pose). Elles sont POE standard, pas besoin de plus. Par 
contre, me faut un switch qui peut gérer quelques vlans.


On va donc effectivement ajouter une passerelle intermédiaire derrière 
sa box.


Au delà de la segmentation et adressage clients, je suppose que ça 
assure aussi la traçabilité des sessions IP ? et que ça remonte les logs 
dans la console ?


Pour la partie hotspot, c'est simpliste mais ça fait le job. Si en plus 
la passerelle fait l'accounting IP, ce sera parfait en terme de traçabilité.


Merci à tous pour les différents retours

--
Jérôme Berthier

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

Re: [FRnOG] [TECH] UniFi - pilotage bornes légères UAP-AC-LITE

[Jérôme Berthier via frnog]

Le 13/01/2024 à 16:32, Jérôme Berthier via frnog a écrit :
J'ai démarré une instance UniFi Network Server pour voir à quoi ça 
ressemble.


Je vois qu'on peut demander une fonction portail captif. Par contre, 
après l'avoir activé, je ne vois aucun menu de gestion des comptes 
guest. Ce n'est pas proposé ?? 


OK je pense avoir trouvé pour ce point.

Après avoir personnalisé le portail en activant l'authentification par 
voucher, un menu apparaît pour gérer les comptes. C'est très rudimentaire.


--
Jérôme Berthier


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

[FRnOG] [TECH] UniFi - pilotage bornes légères UAP-AC-LITE

[Jérôme Berthier via frnog]

Salut la liste,

Je file un coup de main pour une installation Wifi d'un petit 
établissement qui a des chambres d'hôtes.


C'est un rachat. Le proprio précédent a laissé du matos à installer : 
cinq APs UniFi UAP-AC-LITE et un switch POE Netgear non manageable 
(champagne !).


Je ne connais pas les solutions Unifi. Après un peu de lecture, si je 
pige bien :


1) ce sont des AP légères donc faut un contrôleur à part (même s'il 
semblerait possible de les paramétrer unitairement)


2) il faut donc l'application UniFi Network Server

4) soit on héberge ce service, soit on le consomme chez UI

5) y a des gateway qui intègrent UniFi Console qui permet d'instancier 
UniFi Network Server ou de joindre le cloud UI



Comme le tenancier n'est pas vraiment informaticien, je vais plutôt lui 
conseiller des éléments packagés qui "juste marchent".


Du coup, en regardant les boîtiers type gateway, pour pas trop cher, 
j'ai l'impression qu'il y aurait :


- le boîtier CloudKey+ UCK-G2-PLUS (console OnPrem)

- le boîtier UniFi Express UX (console Cloud UI) mais limité à quatre 
devices pilotés


- le boîtier Dream Router UDR (40W) (console Cloud UI)

Est-ce bien ça ?


J'ai démarré une instance UniFi Network Server pour voir à quoi ça 
ressemble.


Je vois qu'on peut demander une fonction portail captif. Par contre, 
après l'avoir activé, je ne vois aucun menu de gestion des comptes 
guest. Ce n'est pas proposé ??



Je vais aussi tenter de lui faire changer son parpaing POE pour avoir 
une gestion de vlan (histoire de séparer l'adressage des APs, le guest 
et surement un SSID privé). Une idée du modèle de switch UniFi (10 ports 
utiles) ?



Côté docs, j'ai du mal à trouver des réponses à mes questions...

Si une bonne âme veut bien m'aiguiller. 


Merci d'avance

Bon week-end

--
Jérôme Berthier


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

Re: [FRnOG] [ALERT] http SD* et cisco CVE-2023-20198

[Jérôme Berthier via frnog]

Le 19/10/2023 à 08:13, jehan procaccia INT a écrit :
Je m'interroge sur l'usage des interfaces [web|API|SD*]  prônées par 
les constructeurs


n'est-ce pas une exposition supplementaires majeure ? Ces outils (chez 
cisco DNA/Catalyst-center, SD-Acces/Wan ...)  utilisent-ils le service 
http/https ?


cf le CVE en cours qui semble faire de serieux degats :

https://www.it-connect.fr/cyberattaque-plus-de-34-000-equipements-cisco-pirates-avec-cette-nouvelle-faille-zero-day/ 



https://sec.cloudapps.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-iosxe-webui-privesc-j22SaA4z 



https://blog.talosintelligence.com/active-exploitation-of-cisco-ios-xe-software/ 





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


Bonjour,

Je pense qu'il ne faut pas mélanger.

Cette faille concerne la WebUI de management des équipements IOS-XE.

Elle est sensée ne pas être exposée n'importe comment (et même 
désactivée vu son peu d'utilité).


Sur SD-WAN, l'onboarding est fait de l'équipement (cEdge, vEdge) vers 
l'orchestrateur vBond (Validator) puis un contrôleur vSmart et le 
vManager sont découverts et le device s'y connecte.


A mon avis, s'il y a connexion entrante, elle est ensuite limitée aux 
contrôleurs (DTLS/OMP) et managers (SSH/NETCONF) validés et enrôlés par 
certificat. ça se passe sur des ports dédiés.


Toutefois, ce mécanisme reste faillible puisque là le point d'exposition 
est côté vBond Orchestrator (Validator exposé complètement pour recevoir 
l'onboarding et faire l'aiguillage) ou vSmart/vManage. Ils ont déjà eu 
leurs lots de failles critiques.


Pour SD-Access, à mon sens, c'est plus classique. DNA Center va venir 
découvrir les équipements en SNMP, SSH. Il y a sûrement aussi du ZTP 
possible (pas vérifié).


Bref, tout logiciel reste faillible donc quand tu exposes des points de 
découverte centralisée, ça peut forcément mal se passer.


--
Jérôme Berthier


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

Re: [FRnOG] [TECH] Recherche solution "PCAP -> IPFIX/NETFLOW"

[Jérôme Berthier via frnog]

Le 06/01/2023 à 17:54, sbu sbu a écrit :

Bonjour,
Je suis à la recherche d'une solution qui saurait prendre du PCAP en entrée
(10 x TAP optique 10G mono et multi) et le convertir en Flow. pour
l'envoyer vers un seul puits de stats.
J'ai bien pensé à prendre des switch mais ceux que j'ai, ont besoin d'une
licence pour le flow, que je n'ai pas, qui coûte un bras. Et je ne suis
même pas certain de pouvoir récupérer le flux des Tap et le NetFlowiser.
En gros l'idéal serait des Gigamon lite  pour ceux qui connaissent, sans
les fonctions des flux metadata et pour beaucoup mon cher.
Pour info ce constructeur me propal plus de 200k€ sur 3 ans (achat +
support de 2 boites)... (volume de data 10G en burste sur l'aggregation des
10 points de collecte)
Si quelqu'un à déjà utilisé d'autre techno basique ou on intervient
uniquement sur l'échantillonnage. Solution hardware, boîtier matriciel
comme les Gigamon ou single ou même une solution software qui fonctionne,
je suis preneur du retour d'expérience.
cdt
SBU

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


Bonjour,

Il me semble que nProbe et son évolution cento font ça chez ntop :

https://www.ntop.org/products/netflow/nprobe/

https://www.ntop.org/products/netflow/nprobe-cento/

Bonne journée

--
Jérôme Berthier


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

Re: [FRnOG] [BIZ] Fortinet augmentation tarif

[Jérôme Berthier via frnog]

Le 05/07/2022 à 18:55, David Ponzone a écrit :

Aux partenaires Forti,

Vous avez remarqué l’augmentation tarifaire de fou sur les licences depuis 12 
mois, surtout sur le FG201F ?
J’essaie de savoir d’où vient ce délire, dur d’avoir des réponses.

C’est peut-être le moment de chercher une alternative, parce que 40%, c’est pas 
de l’inflation.

David


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


C'est marrant à chaque fois que je parle avec Fortinet, ils me racontent 
que y a pas de licences chez eux, que toutes les fonctionnalités du 
boîtier sont utilisables directement. 


En tout cas, l'augmentation monstrueuse est vraie chez d'autres 
constructeurs. Tu sais celui où tu dois payer pour débloquer une limite 
de débit ou avoir le droit de faire de l'IPSEC (alors que tout ceci est 
déjà embarqué sur le routeur...).


Licence "pour le niveau de service OS qui t'intéresse" +70% sur un an

Licence IPSEC +150% sur un an

C'est absolument du racket y compris sur les maintenances.

Ils rattrapent leur marge, c'est tout. Moins de matos vendus et 
délivrés, coûts de fabrication en hausse donc ils lissent le manque à 
gagner entre le hardware et licensing.


Et au passage, je pense qu'ils se font peut être plaisir. Faudra pas 
qu'ils s'étonnent si leurs clients changent de stratégie...


--
Jérôme Berthier


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

Re: [FRnOG] [TECH] Les routeurs dépendent-ils du serveur de licence ?

[Jérôme BERTHIER via frnog]

Le 13/03/2022 à 14:27, Stephane Bortzmeyer a écrit :

Dans le cadre de la réflexion sur la robustesse de l'Internet au cas
où un russe / un chat / un chat russe couperait les câbles
transatlantiques, certains disent que les routeurs Cisco / Juniper /
etc cesseraient de fonctionner au bout de N jours s'ils ne peuvent pas
joindre leur serveur de licences.

Cela me parait fort de café (bien des routeurs sont dans des réseaux
fermés, sans accès à l'extérieur) mais avez-vous des informations
fiables à ce sujet ?


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


Bonjour Stéphane,

Chez Cisco, c'est la logique "Smart licensing" qui s'impose maintenant 
sur les branches logicielles récentes.


On se retrouve par exemple à migrer des routeurs de la branche IOS-XE 
3.16.x vers 17.3 Amsterdam. Là, le smart licensing est activé de facto 
et non débrayable.


Pour autant, les licences historiques installées localement dans 
l'équipement sont bien récupérées mais on voit que l'équipement est 
soumis à une politique qui l'oblige à tenter un rapport de licensing 
sous 365j :


Usage Reporting:
  Last ACK received: 
  Next ACK deadline: Dec 21 16:05:35 2022 MET
  Reporting push interval: 30  days
  Next ACK push check: 
  Next report push: Jan 06 15:44:01 2022 MET
  Last report push: 
  Last report file write: 


L'impact d'un manquement de cette échéance n'est pas bien clair. Cela 
semble surtout dépendre de la gamme concernée :


https://www.cisco.com/c/dam/en/us/products/collateral/software/smart-accounts/smart-licensing-product-details-external.xlsx

Si l'on en croit la colonne S, on voit par exemple que :

- les routeurs de gamme ASR1000 ou ISR4000 gardent des fonctionnalités 
"normales" en cas d'échec de communication.


- par contre, les serveurs de TOIP CUCM bloquent la gestion des 
utilisateurs et terminaux après 180j de grâce supplémentaire.


- et une appliance firewall virtuelle (ASAv) selon sa version OS : soit 
reboote et se retrouve bridée à 100kbps, soit ne change rien (ça a du 
râlé un peu...).


Bref, ça illustre bien la simplification annoncée par Cisco... 


Pas testé, mais il semble exister une méthode de déploiement 
complètement offline pour les équipements isolés :


https://www.cisco.com/c/en/us/products/software/smart-accounts/software-licensing.html#~deployment


Voilà si quelqu'un de Cisco veut nous éclairer, ce sera bienvenue.

Pour ma part, j'ai l'impression que c'est plus déclaratif qu'autre chose 
(en général et à ce stade).


Bonne journée

--
Jérôme BERTHIER


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

Re: [FRnOG] [TECH] gui cloisonnable sur firewall

[Jérôme BERTHIER via frnog]

Il me semble que les "tenant" sur les SRX Juniper répondent exactement à 
ça :


https://www.juniper.net/documentation/us/en/software/junos/logical-system-security/topics/topic-map/tenant-systems-overview.html

A+

--
Jérôme BERTHIER


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

Re: [FRnOG] [MISC] upgrade du routeur Cisco perso

[Jérôme BERTHIER via frnog]

Le 05/10/2021 à 06:37, Michel Py via frnog a écrit :

Comme il me semble que tu commences a avoir un peu de materiel Cecile, fais-toi 
un petit lab EIGRP pour t'amuser,
ca ne peut pas faire de mal... et avec les jours pluvieux qui approchent, ca 
occupe une bonne journee;)

D'autant plus ce n'est plus le monopole de Cisco et que FRR le fait, 
maintenant. Je n'ai jamais essayé, ceci dit.



Ah  justement je me demandais s'il y avait des implémentations autres et 
fiables suite au draft d'infos IETF de 2016...







Olivier Cochard-Labbé a écrit :
La seule fois ou j'ai croisé de l'EIGRP, c'était un réseau assez étendu 
géographiquement (centaine de sites au travers d'un
pays de montagne) qui avait un mélange de liens satellite et terrestres pas 
très stable (et avec des architectes très Cisco
fanboy). Et donc les métriques delay, relialibily, bandwidth  permettaient 
d'optimiser le routage dans ce cas très particulier.

Oui, c'était du "SD-WAN" déjà il y a 20 ans :P



Dans la rubrique "Software truc", ça propose de l'overlay vu que ça peut 
servir de control plane à une encapsulation LISP entre domaines (see 
EIGRP Over the Top).




Gougleu "eigrp unequal cost load balancing"
https://www.cisco.com/c/en/us/support/docs/ip/enhanced-interior-gateway-routing-protocol-eigrp/13677-19.html



La répartition de charge sur des liens asymétriques, c'est le 
différenciateur me semble-t-il. Vous connaissez autre chose qui fait ça 
nativement ?


La capacité à faire converger uniquement la partie de réseau qui est 
impactée par le changement de route est intéressante aussi sur une infra 
étendue (et peu segmentée).


Cela dit, j'ai jamais utilisé en prod. Le côté non interopérable reste 
un problème en terme d'évolutivité je trouve.


--
Jérôme BERTHIER

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

Re: [FRnOG] [TECH] Nom de domaine déjà pris.

[Jérôme BERTHIER via frnog]

Le 03/08/2021 à 22:42, Laurent Barme a écrit :


Il suffit de choisir un autre tld : par exemple, si barme.fr est déjà 
pris, je prends barme.tf



Et encore ça dépend peut être :

1) de qui a déjà pris le domaine. Si c'est une marque déposée 
mondialement, c'est un peu joueur de seulement changer de tld


2) dans quel pays est déposé l'entreprise et ou elle fait du business.

L'impact juridique du choix du tld est à analyser (probablement rester 
sur un tld à juridiction FR ou EU pour une boite française).


Prendre du .com ou .org, ça peut donner lieu à quelques complications 
unilatérales de la part des US ;)


https://arstechnica.com/tech-policy/2012/08/government-goes-0-2-admits-defeat-in-rojadirecta-domain-forfeit-case/




Cela dit, si le nom de ta startup ou de ton produit coïncide avec un 
nom de domaine déjà pris, c'est que tu t'es peut-être trompé de nom de 
startup ou de nom de produit car il est déjà pris :


+1 :)

Bonne journée

--
Jérôme BERTHIER


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

Re: [FRnOG] [TECH] [BGP] [Cisco]

[Jérôme BERTHIER via frnog]

Le 14/07/2021 à 22:18, Emmanuel DECAEN a écrit :
Dans ce cas, la distinction entre les deux liens ne se fait plus par 
l'IP, mais par l'interface utilisée sur l'équipement (Router Interface 
Address).


L'avantage, et pas des moindres, c'est que tu ajoutes autant 
d'interconnexions que tu veux, sans avoir à te poser de question 
d'adressage, il faut juste monter ton interface de routage (sans 
adresse IP) de chaque côté (et c'est tout).


Salut,

Question peut être bête mais comment gères-tu la détection rapide de 
dysfonctionnement d'un lien sans perte d'état de l'interface elle même ?


A priori, BFD ça ne marche pas avec l'IP unumbered sur Nexus :

https://www.cisco.com/c/en/us/td/docs/switches/datacenter/nexus9000/sw/7-x/interfaces/configuration/guide/b_Cisco_Nexus_9000_Series_NX-OS_Interfaces_Configuration_Guide_7x/b_Cisco_Nexus_9000_Series_NX-OS_Interfaces_Configuration_Guide_7x_chapter_0110.html#concept_FBA5494FBDAA4D599394E61823E16C07

Il reste que le tuning OSPF ?

Parce que sinon y a un bon risque que l'ECMP te fasse passer par le lien 
coupé le temps du dead timer , non ?


--
Jérôme BERTHIER


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

Re: [FRnOG] [TECH] [BGP] [Cisco]

[Jérôme BERTHIER via frnog]

Le 11/07/2021 à 20:57, Michel Py via frnog a écrit :

Moi ça ne me dérange pas, mais on est en 2021 et pour les jeunes padawan qui 
n'ont jamais connu classful, ça peut prêter à confusion.



Ou leur donner l'occasion de regarder ce qu'est CIDR.

C'est pas inintéressant de comprendre le concept. ;)




Est-ce que quelqu'un connait une ruse pour afficher le masque dans tous les cas 
? 3.0.0.0/8 au lieu de 3.0.0.0 ?


Non , je vois juste comment extraire ce qui n'est pas un réseau classful 
justement : sh bgp ipv4 uni cidr-only


En même temps, le routeur fait toujours la distinction dans sa table de 
routage. Sauf erreur, un préfixe classful est vu comme un "network" 
alors que tout préfixe hors masque de classe est vu comme "subnet" : sh 
ip ro sum



--
Jérôme BERTHIER


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

Re: [FRnOG] [ALERT] Re: OVH : SBG-2 en feu

[Jérôme BERTHIER via frnog]

Le 10/03/2021 à 13:24, Stéphane Rivière a écrit :

Avec le recul, on peut se dire que leur gestion du risque incendie est à revoir.

Un incendie de matos informatique est quasiment impossible à éteindre :
c'est comme un feu de pneus, ça dégage une chaleur démentielle en se
propageant à une vitesse phénoménale.


Une fois que ça a pris effectivement, c'est impressionnant mais on peut 
imaginer des dispositifs de détection et/ou extinction précoce...


Juste une remarque pour les zones les plus proches du sinistre, sauf 
erreur, le matos ou l'environnement DC contient souvent du PVC. La fumée 
de combustion du PVC contient de l'acide chlorhydrique.


Une fois mélangé à l'humidité ambiante (de l'eau envoyée à proximité), 
l'acide peut ensuite se déposer sur les éléments au refroidissement de 
ceux-ci.


Il faut espérer qu'il n'y ait pas eu de condensation au refroidissement 
après arrêt. Dans ce cas, c'est un bon risque d'oxydation ultérieure. 
Enfin, je crois.


Bon courage aux concernés

--
Jérôme BERTHIER


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

Re: [FRnOG] [TECH] Juniper, JTAC et EX4300 sont dans un bateau

[Jérôme BERTHIER via frnog]

Salut,

Le 02/11/2020 à 14:14, Maxime De Berraly a écrit :

est ce que cette liste est
uniquement "bug report driven"?


Clairement, je pense que c'est ça.

Il suffit de voir les aller-retour de recommandations qu'ils font parfois.

Mon impression est qu'ils statuent sur un niveau d'emmerdement minimum 
(ce qui explique la position conservatrice dans les branches choisies).


En même temps, quand on cherche la stabilité, c'est ce qu'il faut. :)

Bon courage

--
Jérôme BERTHIER


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

Re: [FRnOG] [MISC] Une tribune pour vous inviter à suivre un site intéressant…

[Jérôme BERTHIER via frnog]

Le 22/08/2020 à 17:22, Jérôme Nicolle a écrit :

Plop,

Datacenter Magazine vient de publier une ébauche de retour d'expérience
que j'ai commencé à travailler en début d'été. Vous pouvez lire le texte
là :

https://datacenter-magazine.fr/tribune-la-cyber-bombe-a-retardement-pourrait-etre-pire-que-la-crise-sanitaire/

Je vous invites à parcourir le site, leurs publications passées, il y a
plein de choses intéressantes dedans.

@+


Bonjour,

"Mais sincèrement, s’était-on déjà ‘vraiment’ posé la question de ce 
qu’une crise sanitaire telle que décrite dans des films comme 
“Contagion” (2011) ou “28 days later” (2002) pourrait avoir comme 
conséquence sur nos systèmes d’information ?"


Pas de zombies en mode furie qui courent aussi vite qu'Usain Bolt mais 
il y avait eu une vague invitation à y réfléchir avec l'aventure H1N1 en 
2009.


On trouve des restes de recommandations de l'époque :

https://travail-emploi.gouv.fr/IMG/pdf/DP_PCA_ASIEM_Journalistes.pdf

http://www.ariege.cci.fr/files/cci09/prevenir_les_difficultes/kitgrippeAentreprise.pdf


Même si tu as l'infra et les licences VPN, tu n'as pas forcément les 
terminaux, les casques... et surtout pas les habitudes chez tous les 
utilisateurs.


Oui, le SaaS, ça a une limite aussi. Je pense que certains DSI ont peut 
être regretté de ne pas avoir gardé sur un peu de sur-capacité "on 
premise" (en défendant les coûts associés)...


C'est un peu comme quand tu comptes uniquement sur des masques ou des 
médicaments fabriqués en Asie...


A la fin, il reste les IT heroes d'un jour que l'on oubliera aussi vite 
que les soignants...


A+

--
Jérôme BERTHIER


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

Re: [FRnOG] [TECH] SW_DAI-4-PACKET_RATE_EXCEEDED CISCO

[Jérôme BERTHIER via frnog]

Salut,

Le 25/05/2020 à 20:12, Sébastien 65 a écrit :

Salut Jérôme,


Tu sécurises quoi via ce port Gi0/1 ?

Valider que les @MAC/IP d'un VLAN sont bien celle qui doivent discuter avec le 
routeur !



OK mais ça laisse quand même la possibilité d'usurper une adresse MAC en 
aval, non ?


Du coup, le filtrage concentré sur ce port là devient possible à 
contourner (car si je comprend bien, tout le trafic L2 se concentre sur 
ce port).






Juste vérifier les correspondances MAC-IP via l'inspection DHCP snooping en 
parallèle ?

Oui, j'ai des access-list ARP qui autorise sur un VLAN un couple d'@ IP/MAC. Je 
n'ai pas de service DHCP qui tourne sur ce réseau.
!
arp access-list VLAN_101_ARP
  permit ip host 10.0.1.1 mac host cc2d.e0b2.6f1c
  permit ip host 10.0.1.2 mac host 7c69.f617.8e82
!


Je ne connais pas de méthode officielle mais je tenterai un doublement de 
valeur jusqu'à que le défaut ne revienne plus.

C'est quitte ou double et j'aime pas du tout... Tu vas être tranquille pendant 
un certain temps et le jours ou il y aura plus de monde ça va merder et hop 
port down !



Associé à un recovery auto de 30s + une analyse de logs , ça doit 
permettre d'être assez réactif.


La tranquillité du rate à none expose la CPU du switch donc c'est un peu 
sans filet si problème. J'aurais tendance à l'éviter.



Bonne journée




Bonne soirée !

De : frnog-requ...@frnog.org  de la part de Jérôme BERTHIER 
via frnog 
Envoyé : lundi 25 mai 2020 09:51
À : frnog@frnog.org 
Objet : Re: [FRnOG] [TECH] SW_DAI-4-PACKET_RATE_EXCEEDED CISCO

Salut,

Le 21/05/2020 à 08:50, Sébastien 65 a écrit :

Bonjour à tous,

Sur un switch j'ai activé Dynamic ARP Inspection, je me retrouve de temps en 
temps le port UPLINK en err-disable state.

Le port Gi0/1 est connecté en cascade sur différent switch du LAN qui n'ont pas 
de mécanisme DAI.


Du coup, la logique m'échappe.

Le spoofing peut avoir lieu sur n'importe quel switch aval dans ce cas.

Tu sécurises quoi via ce port Gi0/1 ? Juste vérifier les correspondances
MAC-IP via l'inspection DHCP snooping en parallèle ?

En théorie, les ports vers d'autres devices (attendus exécutant DAI)
sont à l'état trust donc il n'y a pas d'inspection (donc pas de rate
limiting nécessaire).



Le switch qui passe en err-disable est ensuite banché sur le routeur, le switch me permet 
de faire du "ménage" AVANT de passer sur le routeur...

J'utilise ip arp inspection validate src-mac dst-mac ip + ip arp inspection 
filter

*Mar  3 14:53:28.473: %SW_DAI-4-PACKET_RATE_EXCEEDED: 18 packets received in 16 
milliseconds on Gi0/1.
*Mar  3 14:53:28.473: %PM-4-ERR_DISABLE: arp-inspection error detected on 
Gi0/1, putting Gi0/1 in err-disable state
*Mar  3 14:53:29.513: %LINEPROTO-5-UPDOWN: Line protocol on Interface 
GigabitEthernet0/1, changed state to down
*Mar  3 14:53:30.553: %LINK-3-UPDOWN: Interface GigabitEthernet0/1, changed 
state to down

En regardant un peux les valeurs par défaut, je constate que CISCO  fixe ip arp 
inspection limit rate à 15 pps.

Je ne sais pas comment définir cette valeur à part de faire au pifomètre ou 
d'utiliser ip arp inspection limit none sur Gi0/1...

Si quelqu'un peut m'expliquer la méthode je suis preneur 


Je ne connais pas de méthode officielle mais je tenterai un doublement
de valeur jusqu'à que le défaut ne revienne plus.

Ou alors plus fin, tu captures le trafic pour te faire une idée du seuil
atteint mais bon, comme tous les seuils, ça va forcément devenir faux au
bout d'un moment...


Bonne journée



Merci



---
Liste de diffusion du FRnOG
https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.frnog.org%2Fdata=02%7C01%7C%7Cc4625a445bd64bc1ef3008d8008087ab%7C84df9e7fe9f640afb435%7C1%7C0%7C637259899310184386sdata=V3fmq%2FhXshiALZ6phOVljy81cqWZeJapXnKv4%2B14Vcw%3Dreserved=0


--
Jérôme BERTHIER


---
Liste de diffusion du FRnOG
https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.frnog.org%2Fdata=02%7C01%7C%7Cc4625a445bd64bc1ef3008d8008087ab%7C84df9e7fe9f640afb435%7C1%7C0%7C637259899310184386sdata=V3fmq%2FhXshiALZ6phOVljy81cqWZeJapXnKv4%2B14Vcw%3Dreserved=0

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



--
Jérôme BERTHIER


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

Re: [FRnOG] [TECH] SW_DAI-4-PACKET_RATE_EXCEEDED CISCO

[Jérôme BERTHIER via frnog]

Salut,

Le 21/05/2020 à 08:50, Sébastien 65 a écrit :

Bonjour à tous,

Sur un switch j'ai activé Dynamic ARP Inspection, je me retrouve de temps en 
temps le port UPLINK en err-disable state.

Le port Gi0/1 est connecté en cascade sur différent switch du LAN qui n'ont pas 
de mécanisme DAI.



Du coup, la logique m'échappe.

Le spoofing peut avoir lieu sur n'importe quel switch aval dans ce cas.

Tu sécurises quoi via ce port Gi0/1 ? Juste vérifier les correspondances 
MAC-IP via l'inspection DHCP snooping en parallèle ?


En théorie, les ports vers d'autres devices (attendus exécutant DAI) 
sont à l'état trust donc il n'y a pas d'inspection (donc pas de rate 
limiting nécessaire).




Le switch qui passe en err-disable est ensuite banché sur le routeur, le switch me permet 
de faire du "ménage" AVANT de passer sur le routeur...

J'utilise ip arp inspection validate src-mac dst-mac ip + ip arp inspection 
filter

*Mar  3 14:53:28.473: %SW_DAI-4-PACKET_RATE_EXCEEDED: 18 packets received in 16 
milliseconds on Gi0/1.
*Mar  3 14:53:28.473: %PM-4-ERR_DISABLE: arp-inspection error detected on 
Gi0/1, putting Gi0/1 in err-disable state
*Mar  3 14:53:29.513: %LINEPROTO-5-UPDOWN: Line protocol on Interface 
GigabitEthernet0/1, changed state to down
*Mar  3 14:53:30.553: %LINK-3-UPDOWN: Interface GigabitEthernet0/1, changed 
state to down

En regardant un peux les valeurs par défaut, je constate que CISCO  fixe ip arp 
inspection limit rate à 15 pps.

Je ne sais pas comment définir cette valeur à part de faire au pifomètre ou 
d'utiliser ip arp inspection limit none sur Gi0/1...

Si quelqu'un peut m'expliquer la méthode je suis preneur 



Je ne connais pas de méthode officielle mais je tenterai un doublement 
de valeur jusqu'à que le défaut ne revienne plus.


Ou alors plus fin, tu captures le trafic pour te faire une idée du seuil 
atteint mais bon, comme tous les seuils, ça va forcément devenir faux au 
bout d'un moment...



Bonne journée




Merci



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



--
Jérôme BERTHIER


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

Re: [FRnOG] [TECH] Policy-map output CISCO qui me rend fou !

[Jérôme BERTHIER via frnog]

Le 18/05/2020 à 09:36, Jérôme BERTHIER via frnog a écrit :

Bonjour,

Le 16/05/2020 à 11:37, Sébastien 65 a écrit :
Pourquoi le ping depuis le CPE ne passe pas la class OTHER_TRAFFIC ou 
bien class class-default ?


Parce qu'il faut lui appliquer une politique locale "ip local policy 
route-map map-tag " :


https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/iproute_pi/configuration/15-mt/iri-15-mt-book/iri-pbr.html#GUID-0BE1EBC5-C95F-43BE-92D1-0A341D6208A4 



Bonne journée


Oups j'ai fait un magnifique HS, désolé.

ça marche pour du PBR, pas du marking COS

Je vais reboire un café.

Bonne journée

--
Jérôme BERTHIER


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

Re: [FRnOG] [TECH] Policy-map output CISCO qui me rend fou !

[Jérôme BERTHIER via frnog]

Bonjour,

Le 16/05/2020 à 11:37, Sébastien 65 a écrit :

Pourquoi le ping depuis le CPE ne passe pas la class OTHER_TRAFFIC ou bien 
class class-default ?


Parce qu'il faut lui appliquer une politique locale "ip local policy 
route-map map-tag " :


https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/iproute_pi/configuration/15-mt/iri-15-mt-book/iri-pbr.html#GUID-0BE1EBC5-C95F-43BE-92D1-0A341D6208A4

Bonne journée

--
Jérôme BERTHIER


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

Re: [FRnOG] [TECH] vmware, firewall dmz

[Jérôme BERTHIER via frnog]

Bonjour,

Le 11/05/2020 à 15:20, Jerome Lien a écrit :

Actuellement nous avons plusieurs dmz, avec des vlan's, le tout passant par
un fortigate physique ... mais il faut avouer que remonter les vlan à
chaque fois, fortigate..., switch, vswitch ... c'est plutôt fatiguant.



Oui mais ça traite les bonnes fonctions sur un équipement qui le fait bien.



Du coups, on réfléchi à monter un firewall en VM, par exemple un pfsense,
opnsense  pour gérer ces mini dmz et n'avoir qu'un lien propre vers
l’extérieur.


Si ça reste de la segmentation par vlan / préfixe, je ne comprend pas en 
quoi s'appuyer sur un firewall en VM va améliorer la situation.


ça a l'air même pire puisque ça crée du steering entre hyperviseurs. Il 
faut gérer le HA donc deux VMs... Bref, ça déplace le problème.


A la rigueur dans l'univers VMWare, NSX aurait un intérêt dans ce cas en 
faisant de la microsegmentation.


Un seul vlan / préfixe + NSX qui gère la segmentation par VM au niveau 
de l'hyperviseur, ça ressemble à ce qui est recherché.


Par contre, en dehors , de cas récurrents (pour faire de la masse), 
c'est plutôt très chiant à gérer pour des flux très hétérogènes (du 
moins de que j'en ai vu lors d'un POC qui date de 3 ans maintenant...).


Bonne fin de journée

--
Jérôme BERTHIER


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

[FRnOG] Re: [TECH] Question résolution DNS ... particulière ...

[Jérôme BERTHIER via frnog]

Le 15/04/2020 à 13:46, Stephane Bortzmeyer a écrit :

On Wed, Apr 15, 2020 at 08:51:19AM +0200,
  Pierrick CHOVELON  wrote
  a message of 21 lines which said:


Je ne sais pas encore en ce qui concerne les résolveurs. Faut-il
mieux avoir un slave/resolver ou alors bien distinguer les deux ?

Distinguer 


S'il faut que les resolvers puissent résoudre uniquement certains 
sous-domaines (pour tenir compte de l'application du NAT) mais par 
défaut , puissent interroger la zone domaine.fr publique, il y aurait au 
moins deux pistes sur Bind :


1) assigner chaque sous-domaine "xxx.domaine.fr" (de manière exhaustive) 
à une zone type forward pointant vers les serveurs faisant autorité en 
interne avec la directive "forward only"


2) assigner le domaine complet "domaine.fr" à une zone type forward 
pointant vers les serveurs faisant autorité en interne mais avec la 
directive "forward first" (par défaut a priori) pour initier une 
résolution récursive classique sur non réponse



La méthode 1 limite le renvoi aux domaines listés.

La méthode 2 renvoie par défaut les requêtes concernant "domaine.fr" 
mais déclenche une requête récursive si pas de réponse fournie.


Le mix des deux doit fonctionner mais n'a pas trop d'intérêt a priori.


Je n'ai pas testé. :-)

--
Jérôme BERTHIER


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

[FRnOG] Re: [TECH] Question résolution DNS ... particulière ...

[Jérôme BERTHIER via frnog]

Bonjour,

Le 15/04/2020 à 13:45, Stephane Bortzmeyer a écrit :

Pourquoi un outil spécifique alors que cette fonction est dans tous
les serveurs DNS depuis toujours, et est normalisée
  ?


ça reste juste une possibilité.

On est d'accord que le transfert de zone fait le travail parfaitement.

--
Jérôme BERTHIER


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

Re: [FRnOG] [TECH] Re: Routage inter-vrf Cisco

[Jérôme BERTHIER via frnog]

Bonjour,

Le 12/04/2020 à 23:09, Quentin Leconte via frnog a écrit :

C'est ça, et mes VLAN en question ont chacun une VRF à eux. C'est bien le Cisco 
qui fera le NAT.
1 vlan = 1 vrf = 1 ip publique à bridger sur le WAN (dont l'interface physique 
n'est dans aucune VRF).


Chaque IP publique appartient au même préfixe ? qui est celui de 
l'interco WAN ?


--
Jérôme BERTHIER


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

Re: [FRnOG] [TECH] Question résolution DNS ... particulière ...

[Jérôme BERTHIER via frnog]

Bonjour,

Le 14/04/2020 à 09:08, Pierrick CHOVELON a écrit :
-> 1 master avec plusieurs slaves qui partagerait une VIP histoire 
d'avoir de la redondances ?



Déjà dit par Phil Regnauld, une unique VIP sur un service DNS faisant 
autorité , c'est plutôt des contraintes inutiles à mon sens aussi.




-> 1 seul master avec 1 seul slave ?



oui par exemple (ou 1 master + n slaves sur n préfixes différents) ou un 
outil qui génère le contenu de la zone et le pousse directement sur tous 
les serveurs...


Si j'ai bien compris, ce serait une zone à visibilité purement interne 
de votre entité (pour modifier les entrées de celles proposées par le 
client).


Dans ce cas, la répartition multi-préfixes / AS parait moins critique 
mais ça reste nécessaire de cibler des infra différenciées pour avoir de 
la résilience...



-> Faut-il plutôt gérer une zone/*domaine.fr */ ou 
plutôt à chaque fois gérer la zone spéfifique /*application.domaine.fr 
*/ ? J'aurai tendance à dire la 
première. C'est ce que j'ai fait sur mes tests : j'arrivais à résoudre 
/application.domaine.fr / mais pas 
/domain.fr /. Probablement une mauvaise conf.



Je dirai que ça dépend si tout le contenu de domaine.fr est à visibilité 
interne uniquement ou si des enregistrements restent publics.


ça peut devenir ingérable d'avoir à faire le tri entre les 
enregistrements gérés par le client et d'autres par votre instance. Il 
vaut mieux cibler au plus restreint possible selon le cas.


Comment ce sera géré sur les resolvers ? ils seront slaves ? ou 
utiliseront-ils un forward ?



-> Des outils pour gérer tous les fichiers de zones ? Des astuces pour 
rendre cette gestion le plus logique/simple possible ?


PowerAdmin (ou phpIPAM par exemple) + PowerDNS pour gérer le SOA et 
alimenter le master Bind ?


ou plus simple une gestion de fichiers plat de zones orchestrée via 
puppet ou ansible par exemple ?



Bon courage

--
Jérôme BERTHIER


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

Re: [FRnOG] [TECH] Question résolution DNS ... particulière ...

[Jérôme BERTHIER via frnog]

Bonjour,

Le 09/04/2020 à 10:35, Pierrick CHOVELON a écrit :

- Ajouter un sous-domaine en interne pour accéder à ces applications ->
mais gestion de deux certificats côté appli
- Récupérer les infos sur le DNS client avec une délégation -> mais se
pose le problème du NAT



ça parait être le plus simple.

Dans le cas où vous avez un NAT entre vous, il faudrait que le serveur 
faisant autorité côté client vous renvoie des enregistrements adaptés 
(depuis une zone différenciée du même domaine interne donc soit un 
serveur dédié, soit une gestion de vue).


sinon j'ai jamais testé (et ça fait pas rêver) mais certains pare-feux 
proposent un truc appelé "DNS doctoring" basé sur l'inspection DNS. En 
gros, si une IP est concernée par du NAT, le pare-feu modifie la réponse 
DNS :


- Cisco ASA : 
https://www.cisco.com/c/en/us/support/docs/security/asa-5500-x-series-next-generation-firewalls/115753-dns-doctoring-asa-config.html


- Juniper SRX : 
https://www.juniper.net/documentation/en_US/junos/topics/topic-map/security-dns-algs.html#id-understanding-dns-and-ddns-doctoring




- Déporter la résolution DNS chez le client en utilisant un proxy web
configuré au même endroit que l'appli -> très contraignant à l'utilisation
- Rester sur la modif de notre fichier /etc/hosts à la main ... ... ...


Quitte à maintenir des entrées manuellement alors autant déclarer une 
zone pour le domaine client sur un serveur faisant autorité de votre 
côté (avec copie sur vos resolvers ou forward) et maintenir le mapping 
pour les cas où il y a du NAT, non ?



Bonne journée

--
Jérôme BERTHIER


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

Re: [FRnOG] [MISC] L'étrange licensing des ASR1001X

[Jérôme BERTHIER via frnog]

Salut,

J'ai deux cas d'ASR1001-X activés 20G + carte SPA pour avoir un 
troisième port 10G.


Voici le contenu pour info (avec chiffrement):

Cisco ASR1001-X Chassis, 6 built-in GE, Dual P/S, 8GB DRAM             
(ASR1001-X)
Cisco ASR 1000 Advanced Enterprise Services License                 
(SLASR1-AES)

IPSEC License for ASR1000 Series                             (FLSASR1-IPSEC)
2.5G to 20Gbps upgrade License for ASR 1001-X, Built-in 2x10         
(FLSA1-1X-2.5-20G)
Cisco 1-Port 10GE LAN-PHY Shared Port Adapter                 
(SPA-1X10GE-L-V2)



Évidemment, ce contenu active bien le débit 20G :

Index 31 Feature: throughput_20g
    Period left: Life time
    License Type: Permanent
    License State: Active, In Use
    License Count: Non-Counted
    License Priority: Medium


Pour ton bundle ASR1001X-20G-K9, c'est vrai que vu de ce document, ça 
parait incroyable que ça n'inclut pas le débit 20G :


https://www.cisco.com/c/en/us/products/collateral/routers/asr-1000-series-aggregation-services-routers/guide-c07-731639.html

Si on fait le parallèle avec le 1002-X, il manquerait la ligne 
"Performance Upgrade License: FLSA1-1X-2.5-20G" dans ce qui est inclus



Bon courage

--
Jérôme BERTHIER


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

Re: [FRnOG] [TECH] [MISC] Vibration DC

[Jérôme BERTHIER via frnog]

Le 07/03/2020 à 17:06, Stéphane Rivière a écrit :

La boite de base c'est Vibrachoc (a équipé des décennies de matos mili),
désormais Hutchinson-Paulstrahttps://www.paulstra-industry.com


Dans la même idée :

https://www.mecanocaucho.com/fr-FR/

Bonne fin de journée

--
Jérôme BERTHIER


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