Re: [FRnOG] [TECH] DNS Load Balancer

[Brahim AGALMOUCHE]

 Hello,
Je crois Azure traffic manager peut être une bonne option également (très
facile à mettre en place et à tester, après faut voir le billing)...
Cordialement.


Le mar. 16 avr. 2024 à 12:28, Toussaint OTTAVI  a
écrit :

>
>
> Le 15/04/2024 à 19:10, Michel KOENIG via frnog a écrit :
> > Je n'avais pas précisé, mais la solution serait pour du flux TCP pour
> une application propriétaire et/ou des tunnels IPSEC
>
> Une solution simple est de mettre les deux IP en round-robin sur une
> seule entrée DNS A. Les deux IP seront donc utilisables simultanément,
> mais sans gestion de priorité. Ce n'est donc pas adapté à toutes les
> situations.
>
> S'il s'agit de tunnels IPSec, en ce qui me concerne, je monte deux
> tunnels, un sur chaque interface. Il n'y a plus de notion de lien normal
> / secours. Il y a deux liens, chacun avec des caractéristiques propres.
> La répartition des flux dans les deux tunnels se fait en interne sur le
> routeur / firewall, en fonction de ce que permet l'équipement. Par
> exemple : les flux de prod en priorité sur le lien 1, et tout le reste
> en priorité sur le lien 2.
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/
>

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

Re: [FRnOG] [BIZ] Recherche des switches Huawei reconditionnés

[Brahim AGALMOUCHE]

Je me suis trompé sur ça, j'ai dû croire que les ventilos sont pas asservis
dans cette référence, c'est pas le cas, la sens de dissipation de la
chaleur dépendra de la référence du module ventilo, faudra partir du coup
sur les fan : "*FAN-40EA-F*" pour le type front to back.

Brahim.


Le sam. 12 juin 2021 à 10:53, Nicolas  a écrit :

> On 6/11/21 6:33 PM, Michel Py via frnog wrote:
> >> Brahim AGALMOUCHE a écrit :
> >> Merci pour ta remarque, en effet le design du SW fait que les deux
> options
> >> front-to-back / back-to-front sont possibles et configurables depuis
> l'OS.
> >
> > On peut changer la direction du flux d'air par configuration ?
> >
>
> Mhh cela me paraît un peu trop pointu pour des ventilos, ou alors ils
> doivent être chers (faut l'électronique qui gère d’inversement de
> polarité ?).
>
> Sur les HPE Flexnetwork, il y a deux références de ventilo, une qui
> souffle vers l'avant, et l'autre vers l'arrière.
>
> Selon le type de ventilo installé, il faut ensuite modifier la config du
> switch pour l'informer du sens du flux d'air.
>
> Nicolas
>
> > Michel.
> >
> >
> > ---
> > Liste de diffusion du FRnOG
> > http://www.frnog.org/
> >
>
>
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/
>

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

Re: [FRnOG] [BIZ] Recherche des switches Huawei reconditionnés

[Brahim AGALMOUCHE]

Bonjour Laurent,

Merci pour ta remarque, en effet le design du SW fait que les deux options
front-to-back / back-to-front sont possibles et configurables depuis l'OS.

On est sur dans la région parisienne.
Brahim.

Le ven. 11 juin 2021 à 12:40, L-C FABRE  a écrit :

> Bonjour Brahim,
>
> je suis intéressé si tu identifies un bon brooker.
> Attention au sens de ventilation des switch (port side exhaust ou intake)
>
> Et pour info, vous êtes dans quelle région ?
>
> Laurent.
>
>
> > Le 11 juin 2021 à 12:33, Brahim AGALMOUCHE 
> a écrit :
> >
> > Bonjour,
> >
> > Je cherche des switches refurbished huawei,
> >
> > - 4 x CE6810-48S4Q-LI, avec double alimentation pour chaque SW.
> > - 4 x QSFP+,40G,High Speed Direct-attach de 1 mètre. (QSFP+ to QSFP+).
> > - 4 x QSFP+,40G,High Speed Direct-attach de 5 mètres. (QSFP+ to QSFP+).
> >
> > Merci d'avance.
> > Brahim AGALMOUCHE.
> >
> > ---
> > Liste de diffusion du FRnOG
> > http://www.frnog.org/
>
>

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

[FRnOG] [BIZ] Recherche des switches Huawei reconditionnés

[Brahim AGALMOUCHE]

Bonjour,

Je cherche des switches refurbished huawei,

- 4 x CE6810-48S4Q-LI, avec double alimentation pour chaque SW.
- 4 x QSFP+,40G,High Speed Direct-attach de 1 mètre. (QSFP+ to QSFP+).
- 4 x QSFP+,40G,High Speed Direct-attach de 5 mètres. (QSFP+ to QSFP+).

Merci d'avance.
Brahim AGALMOUCHE.

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

Re: [FRnOG] [TECH] Personnalisation du port du serveur syslog sur les switch nexus

[Brahim AGALMOUCHE]

Rebonjour,

Apparemment c'est pas possible de le faire sur cette version, sur d'autres
versions en l'occurrence à partir du 7.0.3.I7.3 la commande pour spécifier
le port est bien présente.


Le jeu. 18 févr. 2021 à 09:50, Brahim AGALMOUCHE <
brahim.agalmou...@gmail.com> a écrit :

> Bonjour à tous,
>
> Je souhaite changer le port du serveur syslog (autre que le port par
> défaut 514) sur des SW nexus, je ne trouve pas de commande pour
> personnaliser ce port, sur les docs c'est nullement mentionné non plus
> (sauf si j'ai raté quelque chose) quelqu'un à pu réussir à le faire ?
>
> Pour info l'os est NX 6.0.2.U6.2a.
>
> Merci d'avance.
>
> Brahim AGALMOUCHE.
> ingénieur réseau backbone IP/MPLS.
>
>

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

[FRnOG] [TECH] Personnalisation du port du serveur syslog sur les switch nexus

[Brahim AGALMOUCHE]

Bonjour à tous,

Je souhaite changer le port du serveur syslog (autre que le port par défaut
514) sur des SW nexus, je ne trouve pas de commande pour personnaliser ce
port, sur les docs c'est nullement mentionné non plus (sauf si j'ai raté
quelque chose) quelqu'un à pu réussir à le faire ?

Pour info l'os est NX 6.0.2.U6.2a.

Merci d'avance.

Brahim AGALMOUCHE.
ingénieur réseau backbone IP/MPLS.

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

Re: [FRnOG] [TECH] Utilisation de 2 interfaces d'accès sur le EAS (RAD) d'un site d'extrémité accès fibre - Collecte Orange C2E

[Brahim AGALMOUCHE]

Bonjour,

Oui je confirme ca passe les 2 dialers sur la meme interfaces, la VRF lite
est bien supportée sur le 881.

Merci pour vos retours.


Le ven. 7 août 2020 à 16:20, Radu-Adrian Feurdean <
fr...@radu-adrian.feurdean.net> a écrit :

> On Thu, Aug 6, 2020, at 13:55, Brahim AGALMOUCHE wrote:
>
> > Pas possible d'attacher plusieurs dialers à la sous interface X.2900 pour
> > faire du VRF lite.
>
> Les 2 dialers sont *CERTAINEMENT* possibles, apres, pour le vrf-lite sur
> un 881, effectivement, il est possible que ca ne fonctionne pas. Mais
> d'autres routeurs de la gamme supportent quand-meme le vrf-lite.
>
> Apres, s'ils n'ont pas le meme plan d'adressage interne, il doit
> certainement etre possible de bricoler quelque-chose meme sans vrf-lite.
>
>
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/
>

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

Re: [FRnOG] [TECH] Utilisation de 2 interfaces d'accès sur le EAS (RAD) d'un site d'extrémité accès fibre - Collecte Orange C2E

[Brahim AGALMOUCHE]

Bonjour Guillaume,

La collecte ne supporte pas les C-VAN, le traffic doit etre tagué selon le
STAS en avec le S-VLAN 2900 donc pas possible de configurer plusieurs sous
interfaces avec différents VLAN clients.
Pas possible d'attacher plusieurs dialers à la sous interface X.2900 pour
faire du VRF lite.
Pour info mes CPE c'est des Cisco 881.

Le jeu. 6 août 2020 à 11:33, Guillaume Roux  a écrit :

> Salut Brahim,
>
> Vrf lite sur le cpe ? Et second dot-1-q côté collecte.
>
> La C2E supporte jusqu’à 3 dialers donc tu es bon avec ça normalement ;-)
>
> Guillaume
>
> Sent from my iPhone
>
> > On 6 Aug 2020, at 11:19, Brahim AGALMOUCHE 
> wrote:
> >
> > 
> > Bonjour à tous,
> >
> > J'ai deux clients que je souhaite desservir avec le même accès fibre
> Orange C2E, je ne souhaite pas utiliser un switch pour raccorder les 2 CPE
> des clients sur le RAD, je me demande si on peut exploiter 2 interfaces
> pour l'accès sur le RAD ?
> >
> > Sinon a-t--on d'autres solutions sans toucher aux équipements du
> backbone ?
> >
> > D'avance merci pour vos retours.
> >
> > Cordialement.
>

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

[FRnOG] [TECH] Utilisation de 2 interfaces d'accès sur le EAS (RAD) d'un site d'extrémité accès fibre - Collecte Orange C2E

[Brahim AGALMOUCHE]

Bonjour à tous,

J'ai deux clients que je souhaite desservir avec le même accès fibre Orange
C2E, je ne souhaite pas utiliser un switch pour raccorder les 2 CPE des
clients sur le RAD, je me demande si on peut exploiter 2 interfaces pour
l'accès sur le RAD ?

Sinon a-t--on d'autres solutions sans toucher aux équipements du backbone ?

D'avance merci pour vos retours.

Cordialement.

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

Re: [FRnOG] [TECH] - Priorisation des trames PPP LCP echo reply sortant du Mikrotik

[Brahim AGALMOUCHE]

Oui je peux saturer l'ADSL mais je perds pas systématiquement la sessions
PPP c'est en fait un peu aléatoire, du coup pour supprimer la doute et
garantir que les trames qui garantissent le maintient de la session PPP (en
l’occurrence l'échange PPP echo request/reply entre le CPE et le
concentrateur d'accès)

Ainsi on les PPP echo requests qui rentrent dans le mikro, et puis les PPP
echo replies qui sortent vers l'AC.

Mon objectif du coup c'est de prioriser via un mécanisme de QoS ses deux
types de trames.

Je ne sais pas si déja mon raisonnement tient ou peut être j'ai loupé
quelque chose ?

[image: Mailtrack]
<https://mailtrack.io?utm_source=gmail_medium=signature_campaign=signaturevirality5;>
Sender
notified by
Mailtrack
<https://mailtrack.io?utm_source=gmail_medium=signature_campaign=signaturevirality5;>
17/04/20
à 13:52:19

Le ven. 17 avr. 2020 à 13:32, David Ponzone  a
écrit :

> Je commencerais par un upgrade, sans garantir que ça règle quoi que ce
> soit, je vois rien à ce sujet dans les RN.
>
> Tu peux le reproduire en chargeant toi-même l’ADSL ?
> En saturant seulement l’entrant ?
> Seulement le sortant ?
>
>
> Le 17 avr. 2020 à 13:16, Brahim AGALMOUCHE 
> a écrit :
>
> Oui en effet la 3.41 c'été la version du firmware, la version du ROS est
> 6.41.3.
>
>
>
> [image: Mailtrack]
> <https://mailtrack.io/?utm_source=gmail_medium=signature_campaign=signaturevirality5;>
>  Sender
> notified by
> Mailtrack
> <https://mailtrack.io/?utm_source=gmail_medium=signature_campaign=signaturevirality5;>
>  17/04/20
> à 13:16:22
>
> Le ven. 17 avr. 2020 à 13:09, David Ponzone  a
> écrit :
>
>> Oui tu as raison, 5.9 minimum pour le 2011.
>>
>> Donc attendons que Brahim nous confirme la version d’OS (/system
>> resources print).
>>
>> Le 17 avr. 2020 à 13:04, Hugues Voiturier  a
>> écrit :
>>
>> Brahim parle peut-être de la version du firmware et non de RouterOS,
>> parce que je doute que le rb2011 supporte une aussi vieille version de rOS.
>>
>> Hugues
>> AS57199 - AS50628
>>
>> On 17 Apr 2020, at 12:59, David Ponzone  wrote:
>>
>> Ca me regarde pas, mais y a une raison de rester sur un RouterOS qui a 10
>> ans ?
>>
>> Le 17 avr. 2020 à 12:56, Brahim AGALMOUCHE 
>> a écrit :
>>
>> Le modèle en question est le RB2011UiAS, r2, avec le firmware ar9344,
>> v3.41.
>>
>> Concernant le CPU ça se surcharge pas, c'est uniquement le lien WAN
>> (ADSL) qui se sature (lorqu'on atteint la BP de la synchro), pour la piste
>> du fastpath/track, je crois que ca va pas changer grand chose vu que les
>> perfs du CPU ne sont pas impactés, et que ca reste uniquement un souci de
>> priorisation des trames sortantes.
>>
>>
>>
>> ---
>> Liste de diffusion du FRnOG
>> http://www.frnog.org/
>>
>>
>>
>>
>

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

Re: [FRnOG] [TECH] - Priorisation des trames PPP LCP echo reply sortant du Mikrotik

[Brahim AGALMOUCHE]

Oui en effet la 3.41 c'été la version du firmware, la version du ROS est
6.41.3.



[image: Mailtrack]
<https://mailtrack.io?utm_source=gmail_medium=signature_campaign=signaturevirality5;>
Sender
notified by
Mailtrack
<https://mailtrack.io?utm_source=gmail_medium=signature_campaign=signaturevirality5;>
17/04/20
à 13:16:22

Le ven. 17 avr. 2020 à 13:09, David Ponzone  a
écrit :

> Oui tu as raison, 5.9 minimum pour le 2011.
>
> Donc attendons que Brahim nous confirme la version d’OS (/system resources
> print).
>
> Le 17 avr. 2020 à 13:04, Hugues Voiturier  a
> écrit :
>
> Brahim parle peut-être de la version du firmware et non de RouterOS, parce
> que je doute que le rb2011 supporte une aussi vieille version de rOS.
>
> Hugues
> AS57199 - AS50628
>
> On 17 Apr 2020, at 12:59, David Ponzone  wrote:
>
> Ca me regarde pas, mais y a une raison de rester sur un RouterOS qui a 10
> ans ?
>
> Le 17 avr. 2020 à 12:56, Brahim AGALMOUCHE 
> a écrit :
>
> Le modèle en question est le RB2011UiAS, r2, avec le firmware ar9344,
> v3.41.
>
> Concernant le CPU ça se surcharge pas, c'est uniquement le lien WAN (ADSL)
> qui se sature (lorqu'on atteint la BP de la synchro), pour la piste du
> fastpath/track, je crois que ca va pas changer grand chose vu que les perfs
> du CPU ne sont pas impactés, et que ca reste uniquement un souci de
> priorisation des trames sortantes.
>
>
>
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/
>
>
>
>

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

Re: [FRnOG] [TECH] - Priorisation des trames PPP LCP echo reply sortant du Mikrotik

[Brahim AGALMOUCHE]

Le modèle en question est le RB2011UiAS, r2, avec le firmware ar9344, v3.41.

Concernant le CPU ça se surcharge pas, c'est uniquement le lien WAN (ADSL)
qui se sature (lorqu'on atteint la BP de la synchro), pour la piste du
fastpath/track, je crois que ca va pas changer grand chose vu que les perfs
du CPU ne sont pas impactés, et que ca reste uniquement un souci de
priorisation des trames sortantes.



[image: Mailtrack]
<https://mailtrack.io?utm_source=gmail_medium=signature_campaign=signaturevirality5;>
Sender
notified by
Mailtrack
<https://mailtrack.io?utm_source=gmail_medium=signature_campaign=signaturevirality5;>
17/04/20
à 12:40:36

Le ven. 17 avr. 2020 à 12:35, David Ponzone  a
écrit :

> C’est pas faux, et bon débarras le LCD du 3011 qui a jamais servi à rien,
> et merci pour le chassis métal qui fait quand même plus sérieux.
>
> Par contre, ça peut être un peu overkill pour un petit client, mais si le
> budget le permet….
>
> Le 17 avr. 2020 à 12:33, Hugues Voiturier  a
> écrit :
>
> Bonne règle qui peut être simplifiée par :
> - Prends un RB4011, en plus d’avoir de la patate, ça fait joli chez le
> client.
> Plus sérieusement, l’avantage avec le RB4011, c’est que si même avec lui
> ça merde, c’est que le souci est ailleurs :)
>
> Hugues
> AS57199 - AS50628
>
> On 17 Apr 2020, at 12:30, David Ponzone  wrote:
>
> Très surprenant, j’ai jamais vu ça.
>
> Quelle version de RouterOS ?
> T’as contrôlé le CPU quand ta liaison surcharge ?
> Il est assez fréquent de voir des CPE Mikrotik un peu sous-dimensionné,
> parce qu’on se fie un peu trop aux specs.
> Si tu désactives le fastpath par exemple, parce qu’il te gêne (et il gêne
> plein de trucs), ou si t’as oublié de l’activer, ça peut faire une grosse
> différence.
> Chez Mikrotik, je crois que la bonne règle quand on est pas sûr de soi
> c’est:
> -cherche le modèle qui supporte ton traffic avec des paquets de 512 octets
> et 25 filtres
> -prends le modèle au-dessus
>
> Le 17 avr. 2020 à 12:15, Brahim AGALMOUCHE 
> a écrit :
>
> Bonjour,
>
> Je sollicite votre aide concernant une problématique de maintien des
> sessions PPPoE sur les routeurs Mikrotik qu’on déploie chez nos clients.
>
> En effet en constate que suite à une surcharge/congestion sur le lien WAN
> sur le CPE Mikrotik, on perd la session PPPoE.
>
> Ainsi j'ai pensé à prioriser en sortie du Mikrotik les paquets PPP LCP
> echo reply, pour le faire on doit marquer ces trames pour les affecter à
> une Queue et leur réserver de la bande passante.
>
> Hors dans le Matcher du filtre bridge (Bridge contenant l’interface vers
> le modem ADSL) on a comme condition dans les matchers que le champ Type
> dans le header des trames Ethernet, ce qui fait qu’on arrive pas à matcher
> uniquement les trames LCP echo reply.
>
> La condition dans le matcher du filtre bridge (pour marquage des paquets) :
>
> 
> Le type de paquet qu’on souhaite marquer :
>
> 
>
> Est-ce qu’on a un moyen pour affiner les conditions sur matching des
> frames sur les routeurs Mikrotik ? sinon est-ce qu’on moyen pour résoudre
> cette problématique de maintien des sessions lors de la congestion WAN
> autrement ?
>
> D’avance merci pour vos retours.
> Cordialement.
>
>  <
> https://mailtrack.io/?utm_source=gmail_medium=signature_campaign=signaturevirality5;
> > Sender notified by
> Mailtrack <
> https://mailtrack.io/?utm_source=gmail_medium=signature_campaign=signaturevirality5;>
> 17/04/20 à 12:14:45
>
>
>
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/
>
>
>
>

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

[FRnOG] [TECH] - Priorisation des trames PPP LCP echo reply sortant du Mikrotik

[Brahim AGALMOUCHE]

Bonjour,

Je sollicite votre aide concernant une problématique de maintien des
sessions PPPoE sur les routeurs Mikrotik qu’on déploie chez nos clients.

En effet en constate que suite à une surcharge/congestion sur le lien WAN
sur le CPE Mikrotik, on perd la session PPPoE.

Ainsi j'ai pensé à prioriser en sortie du Mikrotik les paquets PPP LCP echo
reply, pour le faire on doit marquer ces trames pour les affecter à une
Queue et leur réserver de la bande passante.

Hors dans le Matcher du filtre bridge (Bridge contenant l’interface vers le
modem ADSL) on a comme condition dans les matchers que le champ Type dans
le header des trames Ethernet, ce qui fait qu’on arrive pas à matcher
uniquement les trames LCP echo reply.

La condition dans le matcher du filtre bridge (pour marquage des paquets) :

[image: image.png]
Le type de paquet qu’on souhaite marquer :

[image: image.png]

Est-ce qu’on a un moyen pour affiner les conditions sur matching des frames
sur les routeurs Mikrotik ? sinon est-ce qu’on moyen pour résoudre cette
problématique de maintien des sessions lors de la congestion WAN autrement ?

D’avance merci pour vos retours.
Cordialement.

[image: Mailtrack]

Sender
notified by
Mailtrack

17/04/20
à 12:14:45