Re: [FRnOG] [TECH] Souci chez Gigaset ?

2020-09-23 Par sujet Vincent Tondellier via frnog 
Le Wednesday 23 September 2020 21:35:19 David Ponzone a écrit :
> Oui je crois que c’est du RTX en OEM maintenant.

En effet ca ressemble beaucoup a du RTX, ou alors c'est vachement bien imité.
Le snom M700 c'est RTX8660, le M900 RTX8663, et on retrouve également toute la 
gamme des handset.

Reste a savoir ce que ca vaut a l'usage


> Y a même un distributeur de RTX sur la liste, je suis sûr qu’il va réagir :)
> > Le 23 sept. 2020 à 21:31, Daniel via frnog  a écrit :
> > 
> > Bonsoir
> > 
> > Le 23/09/2020 à 21:25, Vincent Tondellier via frnog a écrit :
> >> Bonsoir,
> >> 
> >> Il y a aussi les snom M900 qui ont l'air intéressantes sur le papier
> >> (multi- cell avec base/contrôleur hybride qui évite d'avoir un
> >> contrôleur dédié).
> >> 
> >> Quelqu'un a déjà testé ?
> > 
> > J'avais installé la 1ère série de SNOM Mx, une catastrophe. Peut être cela
> > a évolué.



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

[FRnOG] [BIZ] Housing / Colocation avec 2x10Gbps

2020-09-23 Par sujet Armel Chargé // frekences 
Bonsoir la liste,

Pour un projet, je dois chiffrer la colocation avec les infos suivantes :

• Paris ou Ile de France ou en région grand Ouest
• 1/4 de baie ( 10U environ )
• 1 ou 1.5kW avec 2 PDU distincts
• Connectivité internet 10Gbps et un autre circuit 10Gbps vers le réseau 
Ielo-Liazo
• A minima un pool /29 IPv4 et un /48 IPv6
• OOB apprécié
• Engagement 12 ou 36 mois

Si certains ont quelques U dont ils veulent se débarrasser, ca peut être 
l’occasion :)

Belle nuit à tous.

A.



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

Re: [FRnOG] [BIZ] grossiste Yealink

2020-09-23 Par sujet Kévin CHAILLY 
Alors le portier SIP,

Pour les cotés négatifs :
- Faut acheter le boitier d'encastrement a part. C'est petit monsieur GS.
- Si tu te foires sur les paramètres réseau tu peux le briquer (
théoriquement débricable en Wiegand )
- Jamais réussi a le faire parler sur un vlan taggé. du coup il a un port
voix untag.
- L'id principal d'un user de ton contrôle d'accès est le badge. Pas trop
possible de faire du digicode only. Je devrais pas le ranger en coté
négatif par ces temps de covid.
- Le lecteur interne est un 125Khz. Pas trop 2020 m'dame !

Pour les côtes positifs :
- une interface wiegand, ca devrait permettre d'adapter la plupart des
lecteurs de badge du marché. Pour les badges mifare desfire rapellez-vous
que le numéro de série est tournant pour éviter le piratage et tout ira
bien.
- ca juste marche.
- la documentation est bonne, ils ont inclus des jolis schémas avec
l'explication du fait de poser une diode de roue libre derrière un élément
inductif pour pas couler la carte par le fond. Belle attention.
- le système de câblage est bien fait.
- le produit a pas l'air cheap. Gros plus sinon invendable aux clients.
- possibilité de faire des http call sur événement. Contrôle d'accès sans
defoncage de porte avec une serrure type the keys pour un karma sans faute
- fonctionne en vrai poe RFC et pas avec la version wish en 12v ( coucou
konx je te surveille. )

Pour avoir eu à travailler avec d'autres produits, il est bien, au bon
prix, pensez bien a la diode de roue libre !

Si quelqu'un lui connaît un concurrent sérieux dans cette gamme de prix je
suis intéressé par des retours !

Kévin

Le mer. 23 sept. 2020 à 10:31, Stéphane Rivière  a écrit :

> >> Par contre GS a un catalogue plus étendu. Beaucoup plus étendu. (
> >> coucou le portier SIP )
>
> Du coup, tu connais leur portier SIP GDS3705 ?
>
> Faudrait que j'en rentre quelques uns...
>
> Ce modèle a des options bien sympas, semble très complet, suivi et
> j'aime bien les bidules "penguin inside".
>
> Il semble aussiassez bien construit pour résister à la corrosion.
>
> --
> Be Seeing You
> Number Six
>
>
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/
>


-- 
Quand la fiction se heurte a la réalité, les rêves n'ont pas d'air-bag

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

Re: [FRnOG] [TECH] Souci chez Gigaset ?

2020-09-23 Par sujet David Ponzone 
Oui je crois que c’est du RTX en OEM maintenant.
Y a même un distributeur de RTX sur la liste, je suis sûr qu’il va réagir :)

> Le 23 sept. 2020 à 21:31, Daniel via frnog  a écrit :
> 
> Bonsoir
> 
> Le 23/09/2020 à 21:25, Vincent Tondellier via frnog a écrit :
>> Bonsoir,
>> 
>> Il y a aussi les snom M900 qui ont l'air intéressantes sur le papier (multi-
>> cell avec base/contrôleur hybride qui évite d'avoir un contrôleur dédié).
>> 
>> Quelqu'un a déjà testé ?
> J'avais installé la 1ère série de SNOM Mx, une catastrophe. Peut être cela a 
> évolué.


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

Re: [FRnOG] [TECH] Souci chez Gigaset ?

2020-09-23 Par sujet Daniel via frnog 

Bonsoir

Le 23/09/2020 à 21:25, Vincent Tondellier via frnog a écrit :

Bonsoir,

Il y a aussi les snom M900 qui ont l'air intéressantes sur le papier (multi-
cell avec base/contrôleur hybride qui évite d'avoir un contrôleur dédié).

Quelqu'un a déjà testé ?
J'avais installé la 1ère série de SNOM Mx, une catastrophe. Peut être 
cela a évolué.

Vincent

Le Wednesday 23 September 2020 05:31:57 Arthur Rodriguez via frnog a écrit :

Oui j’ai quelques client en w80
Pour le moment tout ce passe bien j’en entends pas parler .
Avec des w53h et w59r .
Après c’est le début , on en déploie d’autre le mois prochain a suivre .
N720 on en a une centaine en parc globalement ça va mais parfois j’ai des
phénomènes inexpliqué . N870 deux très gros client dessus ok et deux moyen
ou ça mèrde .



Le 23 sept. 2020 à 00:09, Wolf  a écrit :


N720, ça marche, tu touches plus.

ça marche pas... bon chance.

Arthur, tu as déjà testé les W80 ? ( ou quelqu'un d'autre )

Si il y a un produit non-spectralink qui fait bien le café, ce serait
plaisant.>

Le mar. 22 sept. 2020 à 18:54, Arthur Rodriguez via frnog
 a écrit : Bonjour
Effectivement gigaset c’est pas fou mais les nouvelles versions sont
encore pire On a des busy incohérent des bugs de codecs des tels qui ne
décroche pas . C’est un peux la foire gigaset
Yealink avec la w80 et le w59r va leur faire très mal si il ne réagisse
pas .


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


--
Daniel Huhardeaux
+33.368460...@tootai.net  sip:8...@sip.tootai.net
+41.445532...@swiss-itech.chtootaiNET


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

Re: [FRnOG] [TECH] Souci chez Gigaset ?

2020-09-23 Par sujet Vincent Tondellier via frnog 
Bonsoir,

Il y a aussi les snom M900 qui ont l'air intéressantes sur le papier (multi-
cell avec base/contrôleur hybride qui évite d'avoir un contrôleur dédié).

Quelqu'un a déjà testé ?


Vincent

Le Wednesday 23 September 2020 05:31:57 Arthur Rodriguez via frnog a écrit :
> Oui j’ai quelques client en w80
> Pour le moment tout ce passe bien j’en entends pas parler .
> Avec des w53h et w59r .
> Après c’est le début , on en déploie d’autre le mois prochain a suivre .
> N720 on en a une centaine en parc globalement ça va mais parfois j’ai des
> phénomènes inexpliqué . N870 deux très gros client dessus ok et deux moyen
> ou ça mèrde .
> 
> 
> > Le 23 sept. 2020 à 00:09, Wolf  a écrit :
> > 
> > 
> > N720, ça marche, tu touches plus.
> > 
> > ça marche pas... bon chance.
> > 
> > Arthur, tu as déjà testé les W80 ? ( ou quelqu'un d'autre )
> > 
> > Si il y a un produit non-spectralink qui fait bien le café, ce serait
> > plaisant.> 
> >> Le mar. 22 sept. 2020 à 18:54, Arthur Rodriguez via frnog
> >>  a écrit : Bonjour
> >> Effectivement gigaset c’est pas fou mais les nouvelles versions sont
> >> encore pire On a des busy incohérent des bugs de codecs des tels qui ne
> >> décroche pas . C’est un peux la foire gigaset
> >> Yealink avec la w80 et le w59r va leur faire très mal si il ne réagisse
> >> pas .


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

Re: [FRnOG] [TECH] NAT et IP hors RFC-1918

2020-09-23 Par sujet David Ponzone 


> Le 23 sept. 2020 à 17:41, A Gaillard  a écrit :
> 
> Exact pour vos 2 remarques :
> 
>   1. En effet on ne pourra jamais régler le problème d'overlap pour ces
>   machines, mais j'aimerais bien trouver une solution pour que les machines
>   du réseau adressées normalement ne voient pas cet overlap : Ce n'est pas
>   l'objectif du DNS-NAT in fine ?

Qui doit accéder à qui ?
SI A est le réseau en overlap (genre 11.X.X.X)
Si B est le réseau normal

Si c’est juste A qui doit accéder à B, alors tu mets un NAT N->1 (ou 1->1) de A 
vers B et B ne verra qu’une IP source (ou plusieurs si 1->1).
Si B doit aussi accéder à A, alors pas le choix que de fait du NAT symétrique 
1<—>1 du type 11.X.X.X devient 10.X.X.X


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

[FRnOG] Re: [TECH] NAT et IP hors RFC-1918

2020-09-23 Par sujet A Gaillard 
Exact pour vos 2 remarques :

   1. En effet on ne pourra jamais régler le problème d'overlap pour ces
   machines, mais j'aimerais bien trouver une solution pour que les machines
   du réseau adressées normalement ne voient pas cet overlap : Ce n'est pas
   l'objectif du DNS-NAT in fine ?
   2. Tu as raison Stéphane, je retire la solution de double NAT de la
   liste pour éviter de devoir longer les murs dans les prochains jours !


Adrien.

Le mer. 23 sept. 2020 à 17:20, Stephane Bortzmeyer  a
écrit :

> On Wed, Sep 23, 2020 at 04:59:35PM +0200,
>  A Gaillard  wrote
>  a message of 49 lines which said:
>
> >- Trouver une solution à base de double NAT
>
> Attention, la personne qui viendra maintenir celà dans N années va
> vous maudire, et inventer le voyage dans le temps pour revenir dans le
> passé vous agresser.
>

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

[FRnOG] Re: [TECH] NAT et IP hors RFC-1918

2020-09-23 Par sujet Stephane Bortzmeyer 
On Wed, Sep 23, 2020 at 04:59:35PM +0200,
 A Gaillard  wrote 
 a message of 49 lines which said:

>- Trouver une solution à base de double NAT

Attention, la personne qui viendra maintenir celà dans N années va
vous maudire, et inventer le voyage dans le temps pour revenir dans le
passé vous agresser.


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

Re: [FRnOG] [TECH] NAT et IP hors RFC-1918

2020-09-23 Par sujet David Ponzone 


> Le 23 sept. 2020 à 16:59, A Gaillard  a écrit :
> 
> Bonjour à tous,
> 
> Au début de l'été je vous écrivais concernant une problématique d'IP hors
> RFC1918 adressées sur le LAN (derrière un MPLS) d'un de mes clients, et
> grâce à vous j'avais pu éclaircir le fonctionnement du mécanisme RTS en
> place chez mon client sur certains équipements !
> 
> Je creuse le sujet et je cherche des solutions pour gérer plus simplement
> le routage au sein du réseau de mon client :
> 
>   - Réadresser les machines en IP RFC1918 --> en effet sauf
>   qu'organisationnellement ça ne va pas être possible à court terme :)
>   - Continuer à utiliser le RTS --> en effet aussi, mais c'est assez
>   pénible à maintenir, et il y a toujours le problème d'overlap entre
>   l'adressage interne hors RFC1918 et quelques IP sur Internet

Tu peux faire tout ce que tu veux, tu ne pourras pas régler le problème 
d’overlap.

Si une machine est en 11.0.0.0/8, elle continuera de chercher à joindre 
11.123.111.1 sur son LAN, plutôt que d’envoyer le paquet à la DEFGW pour 
acheminement vers le DOD.


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

[FRnOG] [TECH] NAT et IP hors RFC-1918

2020-09-23 Par sujet A Gaillard 
Bonjour à tous,

Au début de l'été je vous écrivais concernant une problématique d'IP hors
RFC1918 adressées sur le LAN (derrière un MPLS) d'un de mes clients, et
grâce à vous j'avais pu éclaircir le fonctionnement du mécanisme RTS en
place chez mon client sur certains équipements !

Je creuse le sujet et je cherche des solutions pour gérer plus simplement
le routage au sein du réseau de mon client :

   - Réadresser les machines en IP RFC1918 --> en effet sauf
   qu'organisationnellement ça ne va pas être possible à court terme :)
   - Continuer à utiliser le RTS --> en effet aussi, mais c'est assez
   pénible à maintenir, et il y a toujours le problème d'overlap entre
   l'adressage interne hors RFC1918 et quelques IP sur Internet
   - Trouver une solution à base de double NAT --> est-ce que vous auriez
   des idées à ce sujet ?
   - Trouver une solution à base de DNS-NAT --> est-ce que vous auriez des
   idées à ce sujet ?
   - Est-ce que vous avez déjà expérimenté d'autres solutions pour ce genre
   de problème ?

Concrètement pour le double NAT et le DNS-NAT, est-ce que vous voyez des
solutions particulières qui permettraient de gérer ça "simplement" ? Et à
défaut, est-ce que vous savez s'il existe des services managés spécifiques
pour ce genre de solution ?

Toute réponse, même tâtonnante, m'aiderait beaucoup pour démêler mon sac de
noeuds ;)

Merci !
Adrien.

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

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

2020-09-23 Par sujet 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: any (default)

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

2020-09-23 Par sujet 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

Re: [FRnOG] [BIZ] grossiste Yealink

2020-09-23 Par sujet Stéphane Rivière 
>> Par contre GS a un catalogue plus étendu. Beaucoup plus étendu. (
>> coucou le portier SIP )

Du coup, tu connais leur portier SIP GDS3705 ?

Faudrait que j'en rentre quelques uns...

Ce modèle a des options bien sympas, semble très complet, suivi et
j'aime bien les bidules "penguin inside".

Il semble aussiassez bien construit pour résister à la corrosion.

-- 
Be Seeing You
Number Six


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

Re: [FRnOG] [BIZ] grossiste Yealink

2020-09-23 Par sujet Daniel via frnog 

Bonjour

Le 23/09/2020 à 00:03, Wolf a écrit :

Edox très bien,

De bons outils pour l'importation du catalogue et des stocks en 
direct, délais de livraison respectés, possibilité de dropshipping.


Pour de grosses quantités, tu peux peut-être contacter OneDirect, ce 
sont des voisins à nous. Une belle force de frappe en vente au détail, 
je ne sais pas si ils sont prêts à négocier pour de grosses quantités, 
mais en tout cas ils sont capables de livrer.


Je parle pour Yealink, si Daniel peut compléter pour GrandStream, ce 
serait super,

Edox fait aussi GrandStream


Yealink a de bonnes documentations, le support OpenVPN en natif ( peut 
être pas sur T19P ) toutes les fonctions du téléphone sont pilotables 
par provisioning, et le provisioning est développable en interne 
facilement si souhaité.

GS également.


Yealink a aussi une fonction très intéressante, peut être existante 
chez GS, le RPS,


Tu déclares tes MAC dans le "master-server" de Yealink, si pas 
d'option 66 sur le DHCP du réseau ou c'est branché, ils vont chercher 
leur serveur de prov chez Yealink, ce qui, pour faire du dropshipping 
ou ton revendeur t'annonce les MAC à l'avance fait grave le taff.


Par contre GS a un catalogue plus étendu. Beaucoup plus étendu. ( 
coucou le portier SIP ) Pas eu l'occasion de tester le GXP 1615 qui 
serait le concurrent du T19P, quelqu'un a déjà comparé les deux ?

Non


Kévin

Le mar. 22 sept. 2020 à 15:22, Daniel via frnog > a écrit :


Je plussoie pour Edox. Ceci dit je fuis Yealink (qui est chinois) et
préfère GrandStream pour du low cost.

Le 22/09/2020 à 14:45, Arthur BENOIT a écrit :
> Hello,
>
> Dans le cadre d'un projet de téléphonie "low cost", nous sommes à la
> recherche d'un grossiste Yealink.
>
> On ne cherche pas un grossiste à valeur ajoutée ou de la
livraison directe
> chez les clients finaux, un fournisseur à l'étranger n'est donc
pas un
> problème pour nous.
>
> Avez-vous une adresse sympa sous le coude?
>
> Arthur.
>
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/

-- 
Daniel Huhardeaux

+33.368460...@tootai.net 
sip:8...@sip.tootai.net 
+41.445532...@swiss-itech.ch 
          tootaiNET


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



--
Quand la fiction se heurte a la réalité, les rêves n'ont pas d'air-bag


--
Daniel Huhardeaux
+33.368460...@tootai.net  sip:8...@sip.tootai.net
+41.445532...@swiss-itech.chtootaiNET


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

RE: [FRnOG] [TECH] Souci chez Gigaset ?

2020-09-23 Par sujet Gérald Vannier 
Meme expérience, on passe par le grossiste.
Dans l'ensemble pas trop de soucis. N870 OK, mais les N510 étaient plus 
"fragiles" en terme de comportements.


-Original Message-
From: frnog-requ...@frnog.org  On Behalf Of Alexandre 
Poncini via frnog
Sent: mardi 22 septembre 2020 18:49
To: Lionel RIVIERE 
Cc: frnog-t...@frnog.org
Subject: Re: [FRnOG] [TECH] Souci chez Gigaset ?

Bonjour à tous, 

Je confirme, il n'y a plus aucun contact sur la division Pro. 
Même les mails à la direction de GIGASET France restent sans réponse.

La hotline en Allemagne n'est pas très réactive et il faut impérativement 
passer par le grossiste qui fait passe-plat...
Les soucis que j'ai chez un client, ont été escaladé à la R en Allemagne... 
Wait and see...

Cdt, 

Le 22/09/2020 18:43, « frnog-requ...@frnog.org au nom de Lionel RIVIERE » 
 a écrit :

Bonjour à tous

Avez-vous également des soucis avec les produits gigaset N720 / N870 ?
Plus aucun contact technique ni commercial en France
Hotline exclusive en Allemagne via le grossiste et un fichier Excel 
rédhibitoire

A vous lire

L.RIVIERE


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


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

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

[FRnOG] [TECH] RFC 8906: A Common Operational Problem in DNS Servers: Failure To Communicate

2020-09-23 Par sujet Stephane Bortzmeyer 
Normalement, le protocole DNS est très simple : le client écrit au
serveur, posant une question, et le serveur répond. Il peut répondre
qu'il ne veut pas ou ne sait pas répondre, mais il le dit
explicitement. Cela, c'est la théorie. En pratique, beaucoup de
serveurs DNS bogués (ou, plus fréquemment, situés derrière une
middlebox boguée) ne répondent pas du tout, laissant le client
perplexe se demander s'il doit réeessayer différemment ou pas. Ce
nouveau RFC documente le problème et ses conséquences. Il concerne
surtout la question des serveurs faisant autorité. Bref, si vous en
gérez, testez vos serveurs faisant autorité, vérifiez qu'ils répondent
bien (même si la réponse est « Zut ».

Mon résumé : https://www.bortzmeyer.org/8906.html

PS : j'ai testé très vite mais le domaine frnog.org semble OK.


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