Re: [FRnOG] [ALERT] Perte du NR Rénater de Bordeaux

[Charles ENEL-REHEL]

Bon, l'alimentation du site universitaire qui héberge tout ça à Talence a
été migrée sur GE et va rester ainsi en autonomie électrique plusieurs
jours le temps nécessaire à ENEDIS pour réparer le transfo HTA de tête qui
a grillé.

La connectivité du NR Rénater est remontée depuis 07h20 environ.

Charles.

Le jeu. 1 juin 2023 à 07:09, Charles ENEL-REHEL 
a écrit :

> Hello la liste ;
>
> Le NR Rénater de Bordeaux ren-nr-bordeaux-rtr-091.noc.renater.fr est down
> depuis 02h12 la nuit dernière. Incident majeur confirmé par le NOC de
> Rénater.
>
> Origine : incidents d'alimentation électrique en cascade sur le site
> universitaire d'hébergement à Talence qui, par ailleurs, héberge
> historiquement un nœud majeur de tout le réseau de l'Université de Bordeaux.
>
> Pour tous les ayants droit Rénater en Nouvelle-Aquitaine et les
> universitaires bordelais, réveil difficile ce matin ...
>
> Charles.
>
>
>

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

[FRnOG] [ALERT] Perte du NR Rénater de Bordeaux

[Charles ENEL-REHEL]

Hello la liste ;

Le NR Rénater de Bordeaux ren-nr-bordeaux-rtr-091.noc.renater.fr est down
depuis 02h12 la nuit dernière. Incident majeur confirmé par le NOC de
Rénater.

Origine : incidents d'alimentation électrique en cascade sur le site
universitaire d'hébergement à Talence qui, par ailleurs, héberge
historiquement un nœud majeur de tout le réseau de l'Université de Bordeaux.

Pour tous les ayants droit Rénater en Nouvelle-Aquitaine et les
universitaires bordelais, réveil difficile ce matin ...

Charles.

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

Re: [FRnOG] [TECH] CISCO DHCP WAN port UP/DOWN

[Paul Rolland (ポール・ロラン)]

Hello,

On Wed, 31 May 2023 18:37:31 +0200
David Ponzone  wrote:

> Ouais, ça sent l’automatisme caché de ce style.
> C’est une des raisons qui font que Cisco comme CPE, je peux plus.

;)

Sebastien, une question pour toi sur ta conf: est-ce que, au lieu de forcer
le nat inside a renvoyer DHCP sur le WAN, tu peux ecrire la meme chose
differemment : faire ton ip nat inside sur tout sauf ca ?

Globalement, l'idee est de re-ecrire de maniere differente ce qui est fait,
pour que le traffic DHCP ne rentre pas dans les regles de ip nat inside,
plutot que de le laisser rentrer et lui faire suivre un chemin particulier.

Paul

-- 
Paul RollandE-Mail : rol(at)witbe.net
CTO - Witbe.net SA  Tel. +33 (0)1 47 67 77 77
18 Rue d'Arras, Bat. A11Fax. +33 (0)1 47 67 77 99
F-92000 NanterreRIPE : PR12-RIPE

Please no HTML, I'm not a browser - Pas d'HTML, je ne suis pas un
navigateur "Some people dream of success... while others wake up and work
hard at it" 

"I worry about my child and the Internet all the time, even though she's
too young to have logged on yet. Here's what I worry about. I worry that 10
or 15 years from now, she will come to me and say 'Daddy, where were you
when they took freedom of the press away from the Internet?'"
--Mike Godwin, Electronic Frontier Foundation 


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

Re: [FRnOG] [TECH] CISCO DHCP WAN port UP/DOWN

[David Ponzone]

Ouais, ça sent l’automatisme caché de ce style.
C’est une des raisons qui font que Cisco comme CPE, je peux plus.

> Le 31 mai 2023 à 18:32, Paul Rolland (ポール・ロラン)  a écrit :
> 
> Hello,
> 
> On Wed, 31 May 2023 18:09:57 +0200
> David Ponzone  wrote:
> 
>> Oui je m’attendais à cette réponse.
>> Donc si le ping echo-reply passe pas parce que renvoyé vers le firewall,
>> je pige pas pourquoi le DHCP Offer ne subirait pas le même sort. Je pige
>> donc même pas comment le Cisco peut récupérer une IP en DHCP au départ.
> 
> Marrant, je me posais la meme question... 
> Interface down invalide les ip nat inside, et tant que l'interface n'a pas
> d'IP, ca n'est pas actif, et ca permet la premiere recup.
> Et apres, pas de DHCP recu -> Cisco fait tomber l'interface, ca invalide
> les ip nat (l'interface n'a pas d'IP :D) et on recommence le cycle...
> 
> Paul


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

Re: [FRnOG] [TECH] CISCO DHCP WAN port UP/DOWN

[Paul Rolland (ポール・ロラン)]

Hello,

On Wed, 31 May 2023 18:09:57 +0200
David Ponzone  wrote:

> Oui je m’attendais à cette réponse.
> Donc si le ping echo-reply passe pas parce que renvoyé vers le firewall,
> je pige pas pourquoi le DHCP Offer ne subirait pas le même sort. Je pige
> donc même pas comment le Cisco peut récupérer une IP en DHCP au départ.

Marrant, je me posais la meme question... 
Interface down invalide les ip nat inside, et tant que l'interface n'a pas
d'IP, ca n'est pas actif, et ca permet la premiere recup.
Et apres, pas de DHCP recu -> Cisco fait tomber l'interface, ca invalide
les ip nat (l'interface n'a pas d'IP :D) et on recommence le cycle...

Paul

-- 
Paul RollandE-Mail : rol(at)witbe.net
CTO - Witbe.net SA  Tel. +33 (0)1 47 67 77 77
18 Rue d'Arras, Bat. A11Fax. +33 (0)1 47 67 77 99
F-92000 NanterreRIPE : PR12-RIPE

Please no HTML, I'm not a browser - Pas d'HTML, je ne suis pas un
navigateur "Some people dream of success... while others wake up and work
hard at it" 

"I worry about my child and the Internet all the time, even though she's
too young to have logged on yet. Here's what I worry about. I worry that 10
or 15 years from now, she will come to me and say 'Daddy, where were you
when they took freedom of the press away from the Internet?'"
--Mike Godwin, Electronic Frontier Foundation 


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

Re: [FRnOG] [TECH] CISCO DHCP WAN port UP/DOWN

[David Ponzone]

> Le 31 mai 2023 à 18:02, Sébastien 65  a écrit :
> 
> 7200s => DHCP Addresses leased from a server (show dhcp lease)
> 
> Je n'ai pas essayé 1800s, mais une valeur plus haute que 7200s sans succès.

On s’embrouille là….

Je te demande si le 7200 est donné par le serveur.
Si oui, et si tu veux éviter un forcerenew provoqué par le serveur, tu dois 
mettre de ton côté une valeur X inférieure à 7200 pour contraindre le Cisco à 
faire un renew au bout de X secondes.

> Sur Google j'ai trouvé des problématiques identiques par exemple ici 
> https://community.cisco.com/t5/routing/interface-being-restarted-by-dhcp-1841/td-p/2359494
>  
> 
>  ou par ici 
> https://blog.ipspace.net/2009/09/expired-dhcp-lease-bounces-interface.html 
>  
> il y a une référence comme mon cas d'utilisation dans un commentaire plus bas.
> 
>> Le cisco avec ce ip nat inside, il arrive à pinger l’extérieur ?
> Non, le ping ne peut pas passer car le retour est forcé vers le firewall via 
> ip nat inside.
> Le Cisco envoi bien le ping mais cela rentrera vers le firewall qui lui ne 
> sait pas et va droper car il n'est pas l'initiateur/source du ping.

Oui je m’attendais à cette réponse.
Donc si le ping echo-reply passe pas parce que renvoyé vers le firewall, je 
pige pas pourquoi le DHCP Offer ne subirait pas le même sort.
Je pige donc même pas comment le Cisco peut récupérer une IP en DHCP au départ.

> Pour que le ping fonctionne il faut faire une ACL avec une IP autre en 
> Loopback ou avoir un subnet d'interco/mgmt. C'est une autre histoire.
> 
> De : David Ponzone mailto:david.ponz...@gmail.com>>
> Envoyé : mercredi 31 mai 2023 17:44
> À : Sébastien 65 mailto:sebastien...@live.fr>>
> Cc : frnog-t...@frnog.org   >
> Objet : Re: [FRnOG] [TECH] CISCO DHCP WAN port UP/DOWN
> 
> 7200, c’est quoi ? Le lease-time par défaut du serveur DHCP ?
> Si tu forces à 1800 de ton côté, ça aide pas ?
> 
> Jamais entendu parler d’un automatisme de ce genre chez Cisco à cause d’un ip 
> nat inside, mais je fais jamais ça.
> Je renvoie que les ports 1024-6535, 443 et 500.
> 
> Le cisco avec ce ip nat inside, il arrive à pinger l’extérieur ?
> 
> Le 31 mai 2023 à 17:23, Sébastien 65   >> a écrit :
> 
> David,
> 
> Pas si évident que ça  Comme j'ai dit dans le mail précédent le problème 
> n'est présent qu'avec l'utilisation du 'ip nat inside' pour pousser le flux 
> du WAN vers un autre équipement (équipement local type firewall connecté 
> derrière le CISCO).
> 
> De base la configuration du DHCP lease est de 7200s, dès que la commande 'ip 
> nat inside ...' est présente dans le routeur bin toutes les 2H j'ai droit à :
> 
> May 30 23:29:34.302: %DHCP-5-RESTART: Interface GigabitEthernet8 is being 
> restarted by DHCP
> 
> May 30 23:29:36.302: %LINK-5-CHANGED: Interface GigabitEthernet8, changed 
> state to administratively down
> May 30 23:29:37.302: %LINEPROTO-5-UPDOWN: Line protocol on Interface 
> GigabitEthernet8, changed state to down
> May 30 23:29:39.330: %LINK-3-UPDOWN: Interface GigabitEthernet8, changed 
> state to down
> May 30 23:29:42.938: %LINK-3-UPDOWN: Interface GigabitEthernet8, changed 
> state to up
> May 30 23:29:43.938: %LINEPROTO-5-UPDOWN: Line protocol on Interface 
> GigabitEthernet8, changed state to up
> May 30 23:29:46.522: %DHCP-6-ADDRESS_ASSIGN: Interface GigabitEthernet8 
> assigned DHCP address X.X.X.X, mask 255.255.255.0, hostname 892FSP-X
> 
> Sur le même principe de l'interface WAN en mode DHCP, j'ai des routeurs sur 
> lesquels le 'ip nat inside' n'est pas utilisé, magie ou pas aucun problème 
> sur le DOWN/UP du port WAN.
> J'ai un routeur qui a reboot il y a 2 jours, le show log indique la récup de 
> l'adresse DHCP le 29/05 et depuis rien de plus dans les logs... Pourtant même 
> serveur DHCP en face.
> 
> 
> Sébastien
> 
> 
> De : David Ponzone   >>
> Envoyé : mercredi 31 mai 2023 16:14
> À : Sébastien 65   >>
> Cc : frnog-t...@frnog.org 
>  >   >>
> Objet : Re: [FRnOG] [TECH] CISCO DHCP WAN port UP/DOWN
> 
> Seb,
> 
> Hmm dans mon monde à moi, le DHCP renew est à l’initiative du client, sauf si 
> le serveur implémente FORCERENEW, et que le Cisco l’honore.
> Donc tu devrais pas avoir de problème si tu forces un lease plus court sur le 
> Cisco avec « ip dhcp client lease 0 0 5 » 

RE: [FRnOG] [TECH] CISCO DHCP WAN port UP/DOWN

[Sébastien 65]

7200s => DHCP Addresses leased from a server (show dhcp lease)

Je n'ai pas essayé 1800s, mais une valeur plus haute que 7200s sans succès.

Sur Google j'ai trouvé des problématiques identiques par exemple ici 
https://community.cisco.com/t5/routing/interface-being-restarted-by-dhcp-1841/td-p/2359494
 ou par ici 
https://blog.ipspace.net/2009/09/expired-dhcp-lease-bounces-interface.html il y 
a une référence comme mon cas d'utilisation dans un commentaire plus bas.

>Le cisco avec ce ip nat inside, il arrive à pinger l’extérieur ?
Non, le ping ne peut pas passer car le retour est forcé vers le firewall via ip 
nat inside.
Le Cisco envoi bien le ping mais cela rentrera vers le firewall qui lui ne sait 
pas et va droper car il n'est pas l'initiateur/source du ping.

Pour que le ping fonctionne il faut faire une ACL avec une IP autre en Loopback 
ou avoir un subnet d'interco/mgmt. C'est une autre histoire.

De : David Ponzone 
Envoyé : mercredi 31 mai 2023 17:44
À : Sébastien 65 
Cc : frnog-t...@frnog.org 
Objet : Re: [FRnOG] [TECH] CISCO DHCP WAN port UP/DOWN

7200, c’est quoi ? Le lease-time par défaut du serveur DHCP ?
Si tu forces à 1800 de ton côté, ça aide pas ?

Jamais entendu parler d’un automatisme de ce genre chez Cisco à cause d’un ip 
nat inside, mais je fais jamais ça.
Je renvoie que les ports 1024-6535, 443 et 500.

Le cisco avec ce ip nat inside, il arrive à pinger l’extérieur ?

Le 31 mai 2023 à 17:23, Sébastien 65 
mailto:sebastien...@live.fr>> a écrit :

David,

Pas si évident que ça  Comme j'ai dit dans le mail précédent le problème n'est 
présent qu'avec l'utilisation du 'ip nat inside' pour pousser le flux du WAN 
vers un autre équipement (équipement local type firewall connecté derrière le 
CISCO).

De base la configuration du DHCP lease est de 7200s, dès que la commande 'ip 
nat inside ...' est présente dans le routeur bin toutes les 2H j'ai droit à :

May 30 23:29:34.302: %DHCP-5-RESTART: Interface GigabitEthernet8 is being 
restarted by DHCP

May 30 23:29:36.302: %LINK-5-CHANGED: Interface GigabitEthernet8, changed state 
to administratively down
May 30 23:29:37.302: %LINEPROTO-5-UPDOWN: Line protocol on Interface 
GigabitEthernet8, changed state to down
May 30 23:29:39.330: %LINK-3-UPDOWN: Interface GigabitEthernet8, changed state 
to down
May 30 23:29:42.938: %LINK-3-UPDOWN: Interface GigabitEthernet8, changed state 
to up
May 30 23:29:43.938: %LINEPROTO-5-UPDOWN: Line protocol on Interface 
GigabitEthernet8, changed state to up
May 30 23:29:46.522: %DHCP-6-ADDRESS_ASSIGN: Interface GigabitEthernet8 
assigned DHCP address X.X.X.X, mask 255.255.255.0, hostname 892FSP-X

Sur le même principe de l'interface WAN en mode DHCP, j'ai des routeurs sur 
lesquels le 'ip nat inside' n'est pas utilisé, magie ou pas aucun problème sur 
le DOWN/UP du port WAN.
J'ai un routeur qui a reboot il y a 2 jours, le show log indique la récup de 
l'adresse DHCP le 29/05 et depuis rien de plus dans les logs... Pourtant même 
serveur DHCP en face.


Sébastien


De : David Ponzone mailto:david.ponz...@gmail.com>>
Envoyé : mercredi 31 mai 2023 16:14
À : Sébastien 65 mailto:sebastien...@live.fr>>
Cc : frnog-t...@frnog.org 
mailto:frnog-t...@frnog.org>>
Objet : Re: [FRnOG] [TECH] CISCO DHCP WAN port UP/DOWN

Seb,

Hmm dans mon monde à moi, le DHCP renew est à l’initiative du client, sauf si 
le serveur implémente FORCERENEW, et que le Cisco l’honore.
Donc tu devrais pas avoir de problème si tu forces un lease plus court sur le 
Cisco avec « ip dhcp client lease 0 0 5 » ou un truc du genre.

> Le 31 mai 2023 à 15:52, Sébastien 65 
> mailto:sebastien...@live.fr>> a écrit :
>
> Bonjour à tous,
>
> Sur des routeurs CISCO (88X/89X/etc...) ayant le port WAN en mode DHCP et 
> utilisant la règle 'ip nat inside source static ip-lan-du-firewall 
> ip-wan-loopback extendable' lors de la fin du lease DHCP l'IOS fait tomber le 
> port WAN (Down/Up)...
>
> La commande 'ip nat inside source X X extendable' remplie bien la fonction 
> car tout ce qui arrive sur le port WAN est automatiquement renvoyé sur l'IP 
> indiquée. Aucun problème à ce niveau.
>
> Le problème est que dès que la renégo du DHCP arrive, la requête est 
> transférée sur l'équipement ip-lan-firewall et pas sur l'interface WAN du 
> CISCO. La conséquence est que l'IOS fait tomber le port UP/DOWN pour pouvoir 
> récupérer "enfin" une IP sur son interface WAN.
>
> J'ai essayé de forcer les requêtes provenant du serveur DHCP à rester sur 
> l'interface WAN (ici GE8) mais sans succès :
> ip nat inside source static udp X.X.X.X 67 interface GigabitEthernet8 67
> ip nat inside source static udp X.X.X.X 68 interface GigabitEthernet8 68
>
> Le phénomène est que toutes les 2H le port WAN GE8 fait DOWN/UP. La 
> modification du lease n'est pas la solution car cela reporte uniquement le 
> problème sans le résoudre...
>
> Est-ce que quelqu'un connait le phénomène et la 

Re: [FRnOG] [TECH] CISCO DHCP WAN port UP/DOWN

[David Ponzone]

7200, c’est quoi ? Le lease-time par défaut du serveur DHCP ?
Si tu forces à 1800 de ton côté, ça aide pas ?

Jamais entendu parler d’un automatisme de ce genre chez Cisco à cause d’un ip 
nat inside, mais je fais jamais ça.
Je renvoie que les ports 1024-6535, 443 et 500.

Le cisco avec ce ip nat inside, il arrive à pinger l’extérieur ?

> Le 31 mai 2023 à 17:23, Sébastien 65  a écrit :
> 
> David,
> 
> Pas si évident que ça  Comme j'ai dit dans le mail précédent le problème 
> n'est présent qu'avec l'utilisation du 'ip nat inside' pour pousser le flux 
> du WAN vers un autre équipement (équipement local type firewall connecté 
> derrière le CISCO).
> 
> De base la configuration du DHCP lease est de 7200s, dès que la commande 'ip 
> nat inside ...' est présente dans le routeur bin toutes les 2H j'ai droit à :
> 
> May 30 23:29:34.302: %DHCP-5-RESTART: Interface GigabitEthernet8 is being 
> restarted by DHCP
> 
> May 30 23:29:36.302: %LINK-5-CHANGED: Interface GigabitEthernet8, changed 
> state to administratively down
> May 30 23:29:37.302: %LINEPROTO-5-UPDOWN: Line protocol on Interface 
> GigabitEthernet8, changed state to down
> May 30 23:29:39.330: %LINK-3-UPDOWN: Interface GigabitEthernet8, changed 
> state to down
> May 30 23:29:42.938: %LINK-3-UPDOWN: Interface GigabitEthernet8, changed 
> state to up
> May 30 23:29:43.938: %LINEPROTO-5-UPDOWN: Line protocol on Interface 
> GigabitEthernet8, changed state to up
> May 30 23:29:46.522: %DHCP-6-ADDRESS_ASSIGN: Interface GigabitEthernet8 
> assigned DHCP address X.X.X.X, mask 255.255.255.0, hostname 892FSP-X
> 
> Sur le même principe de l'interface WAN en mode DHCP, j'ai des routeurs sur 
> lesquels le 'ip nat inside' n'est pas utilisé, magie ou pas aucun problème 
> sur le DOWN/UP du port WAN.
> J'ai un routeur qui a reboot il y a 2 jours, le show log indique la récup de 
> l'adresse DHCP le 29/05 et depuis rien de plus dans les logs... Pourtant même 
> serveur DHCP en face.
> 
> 
> Sébastien
> 
> De : David Ponzone 
> Envoyé : mercredi 31 mai 2023 16:14
> À : Sébastien 65 
> Cc : frnog-t...@frnog.org 
> Objet : Re: [FRnOG] [TECH] CISCO DHCP WAN port UP/DOWN
>  
> Seb,
> 
> Hmm dans mon monde à moi, le DHCP renew est à l’initiative du client, sauf si 
> le serveur implémente FORCERENEW, et que le Cisco l’honore.
> Donc tu devrais pas avoir de problème si tu forces un lease plus court sur le 
> Cisco avec « ip dhcp client lease 0 0 5 » ou un truc du genre.
> 
> > Le 31 mai 2023 à 15:52, Sébastien 65  a écrit :
> > 
> > Bonjour à tous,
> > 
> > Sur des routeurs CISCO (88X/89X/etc...) ayant le port WAN en mode DHCP et 
> > utilisant la règle 'ip nat inside source static ip-lan-du-firewall 
> > ip-wan-loopback extendable' lors de la fin du lease DHCP l'IOS fait tomber 
> > le port WAN (Down/Up)...
> > 
> > La commande 'ip nat inside source X X extendable' remplie bien la fonction 
> > car tout ce qui arrive sur le port WAN est automatiquement renvoyé sur l'IP 
> > indiquée. Aucun problème à ce niveau.
> > 
> > Le problème est que dès que la renégo du DHCP arrive, la requête est 
> > transférée sur l'équipement ip-lan-firewall et pas sur l'interface WAN du 
> > CISCO. La conséquence est que l'IOS fait tomber le port UP/DOWN pour 
> > pouvoir récupérer "enfin" une IP sur son interface WAN.
> > 
> > J'ai essayé de forcer les requêtes provenant du serveur DHCP à rester sur 
> > l'interface WAN (ici GE8) mais sans succès :
> > ip nat inside source static udp X.X.X.X 67 interface GigabitEthernet8 67
> > ip nat inside source static udp X.X.X.X 68 interface GigabitEthernet8 68
> > 
> > Le phénomène est que toutes les 2H le port WAN GE8 fait DOWN/UP. La 
> > modification du lease n'est pas la solution car cela reporte uniquement le 
> > problème sans le résoudre...
> > 
> > Est-ce que quelqu'un connait le phénomène et la solution ?
> > 
> > Merci 
> > 
> > Sébastien
> > 
> > 
> > 
> > 
> > ---
> > Liste de diffusion du FRnOG
> > http://www.frnog.org/ 

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

RE: [FRnOG] [TECH] CISCO DHCP WAN port UP/DOWN

[Sébastien 65]

David,

Pas si évident que ça  Comme j'ai dit dans le mail précédent le problème n'est 
présent qu'avec l'utilisation du 'ip nat inside' pour pousser le flux du WAN 
vers un autre équipement (équipement local type firewall connecté derrière le 
CISCO).

De base la configuration du DHCP lease est de 7200s, dès que la commande 'ip 
nat inside ...' est présente dans le routeur bin toutes les 2H j'ai droit à :

May 30 23:29:34.302: %DHCP-5-RESTART: Interface GigabitEthernet8 is being 
restarted by DHCP

May 30 23:29:36.302: %LINK-5-CHANGED: Interface GigabitEthernet8, changed state 
to administratively down
May 30 23:29:37.302: %LINEPROTO-5-UPDOWN: Line protocol on Interface 
GigabitEthernet8, changed state to down
May 30 23:29:39.330: %LINK-3-UPDOWN: Interface GigabitEthernet8, changed state 
to down
May 30 23:29:42.938: %LINK-3-UPDOWN: Interface GigabitEthernet8, changed state 
to up
May 30 23:29:43.938: %LINEPROTO-5-UPDOWN: Line protocol on Interface 
GigabitEthernet8, changed state to up
May 30 23:29:46.522: %DHCP-6-ADDRESS_ASSIGN: Interface GigabitEthernet8 
assigned DHCP address X.X.X.X, mask 255.255.255.0, hostname 892FSP-X

Sur le même principe de l'interface WAN en mode DHCP, j'ai des routeurs sur 
lesquels le 'ip nat inside' n'est pas utilisé, magie ou pas aucun problème sur 
le DOWN/UP du port WAN.
J'ai un routeur qui a reboot il y a 2 jours, le show log indique la récup de 
l'adresse DHCP le 29/05 et depuis rien de plus dans les logs... Pourtant même 
serveur DHCP en face.


Sébastien


De : David Ponzone 
Envoyé : mercredi 31 mai 2023 16:14
À : Sébastien 65 
Cc : frnog-t...@frnog.org 
Objet : Re: [FRnOG] [TECH] CISCO DHCP WAN port UP/DOWN

Seb,

Hmm dans mon monde à moi, le DHCP renew est à l’initiative du client, sauf si 
le serveur implémente FORCERENEW, et que le Cisco l’honore.
Donc tu devrais pas avoir de problème si tu forces un lease plus court sur le 
Cisco avec « ip dhcp client lease 0 0 5 » ou un truc du genre.

> Le 31 mai 2023 à 15:52, Sébastien 65  a écrit :
>
> Bonjour à tous,
>
> Sur des routeurs CISCO (88X/89X/etc...) ayant le port WAN en mode DHCP et 
> utilisant la règle 'ip nat inside source static ip-lan-du-firewall 
> ip-wan-loopback extendable' lors de la fin du lease DHCP l'IOS fait tomber le 
> port WAN (Down/Up)...
>
> La commande 'ip nat inside source X X extendable' remplie bien la fonction 
> car tout ce qui arrive sur le port WAN est automatiquement renvoyé sur l'IP 
> indiquée. Aucun problème à ce niveau.
>
> Le problème est que dès que la renégo du DHCP arrive, la requête est 
> transférée sur l'équipement ip-lan-firewall et pas sur l'interface WAN du 
> CISCO. La conséquence est que l'IOS fait tomber le port UP/DOWN pour pouvoir 
> récupérer "enfin" une IP sur son interface WAN.
>
> J'ai essayé de forcer les requêtes provenant du serveur DHCP à rester sur 
> l'interface WAN (ici GE8) mais sans succès :
> ip nat inside source static udp X.X.X.X 67 interface GigabitEthernet8 67
> ip nat inside source static udp X.X.X.X 68 interface GigabitEthernet8 68
>
> Le phénomène est que toutes les 2H le port WAN GE8 fait DOWN/UP. La 
> modification du lease n'est pas la solution car cela reporte uniquement le 
> problème sans le résoudre...
>
> Est-ce que quelqu'un connait le phénomène et la solution ?
>
> Merci 
>
> Sébastien
>
>
>
>
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/


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

Re: [FRnOG] [TECH] CISCO DHCP WAN port UP/DOWN

[David Ponzone]

Seb,

Hmm dans mon monde à moi, le DHCP renew est à l’initiative du client, sauf si 
le serveur implémente FORCERENEW, et que le Cisco l’honore.
Donc tu devrais pas avoir de problème si tu forces un lease plus court sur le 
Cisco avec « ip dhcp client lease 0 0 5 » ou un truc du genre.

> Le 31 mai 2023 à 15:52, Sébastien 65  a écrit :
> 
> Bonjour à tous,
> 
> Sur des routeurs CISCO (88X/89X/etc...) ayant le port WAN en mode DHCP et 
> utilisant la règle 'ip nat inside source static ip-lan-du-firewall 
> ip-wan-loopback extendable' lors de la fin du lease DHCP l'IOS fait tomber le 
> port WAN (Down/Up)...
> 
> La commande 'ip nat inside source X X extendable' remplie bien la fonction 
> car tout ce qui arrive sur le port WAN est automatiquement renvoyé sur l'IP 
> indiquée. Aucun problème à ce niveau.
> 
> Le problème est que dès que la renégo du DHCP arrive, la requête est 
> transférée sur l'équipement ip-lan-firewall et pas sur l'interface WAN du 
> CISCO. La conséquence est que l'IOS fait tomber le port UP/DOWN pour pouvoir 
> récupérer "enfin" une IP sur son interface WAN.
> 
> J'ai essayé de forcer les requêtes provenant du serveur DHCP à rester sur 
> l'interface WAN (ici GE8) mais sans succès :
> ip nat inside source static udp X.X.X.X 67 interface GigabitEthernet8 67
> ip nat inside source static udp X.X.X.X 68 interface GigabitEthernet8 68
> 
> Le phénomène est que toutes les 2H le port WAN GE8 fait DOWN/UP. La 
> modification du lease n'est pas la solution car cela reporte uniquement le 
> problème sans le résoudre...
> 
> Est-ce que quelqu'un connait le phénomène et la solution ?
> 
> Merci 
> 
> Sébastien
> 
> 
> 
> 
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/


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

[FRnOG] [TECH] CISCO DHCP WAN port UP/DOWN

[Sébastien 65]

Bonjour à tous,

Sur des routeurs CISCO (88X/89X/etc...) ayant le port WAN en mode DHCP et 
utilisant la règle 'ip nat inside source static ip-lan-du-firewall 
ip-wan-loopback extendable' lors de la fin du lease DHCP l'IOS fait tomber le 
port WAN (Down/Up)...

La commande 'ip nat inside source X X extendable' remplie bien la fonction car 
tout ce qui arrive sur le port WAN est automatiquement renvoyé sur l'IP 
indiquée. Aucun problème à ce niveau.

Le problème est que dès que la renégo du DHCP arrive, la requête est transférée 
sur l'équipement ip-lan-firewall et pas sur l'interface WAN du CISCO. La 
conséquence est que l'IOS fait tomber le port UP/DOWN pour pouvoir récupérer 
"enfin" une IP sur son interface WAN.

J'ai essayé de forcer les requêtes provenant du serveur DHCP à rester sur 
l'interface WAN (ici GE8) mais sans succès :
ip nat inside source static udp X.X.X.X 67 interface GigabitEthernet8 67
ip nat inside source static udp X.X.X.X 68 interface GigabitEthernet8 68

Le phénomène est que toutes les 2H le port WAN GE8 fait DOWN/UP. La 
modification du lease n'est pas la solution car cela reporte uniquement le 
problème sans le résoudre...

Est-ce que quelqu'un connait le phénomène et la solution ?

Merci 

Sébastien




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

[FRnOG] [BIZ] recherche revendeur RAD MiCLK ou ADVA OSA 5401

[Armel Chargé-Chauvet // frekences]

Bonjour la liste,

Je suis à la recherche d’un bon dealer pour solution de synchro réseau clock 
GNSS/GPS PtPv2 ( 1588 ) au format SFP type Adva OSA 5401 ou RAD MiCLK, ou toute 
autre référence qui ferait le job :)

D’ailleurs, si quelqu’un a une expérience heureuse ( ou malheureuse ) avec ce 
type d’équipement, je suis preneur également.

Merci d’avance et très belle journée

Armel

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

[FRnOG] [TECH] catalyst vs nexus dans DC spine / leaf

[jehan procaccia INT]

Bonjour,

nous souhaitons passer sur une architecture spine/leaf dans notre 
(modeste, 20 baies) DC .


nous connaissons bien par ailleurs (distributions prises batiments / 
acces) les catalyst 9500 en coeur et 9200/9300 en acces.


Maintenant coté DC , tout le monde chez cisco ne semble jurer que par la 
gamme Nexus . N'est il pas possible de faire du spine en catalyst 9500 
ou 9300, et des leaf en catalyst 9300 voire 9200 ? supportent t-ils 
l'achitecture spine/leaf - fabric IP / vxlan  , bref on aimerai se 
debaraser de notre vieille archi core / access en spanning tree dans le DC.


à la lecture des references ci-dessous [1] , j'en conclu ces differences 
majeures entre catalyst et nexus dans le DC :


1) de l'administration SD etendue entre Datanceters (ACI) vs peut-etre 
du DNA pour les CAT 9K

2) NX-OS vs IOS-XE
3) des performances de commutation optimale  => sub-microsecond vs 4us 
en CAT 9K
4) dispose de LSE (leaf-and-spine engine) ASIC avec buffering vs UADP 
3.0 ASIC et buffering equivalent en CAT

5) support de FCoE en Nexus vs ports Ethernet sur CAT 9k

Merci pour vos conseils et/ou retour d'experience sur ces 2 grandes 
familles de switch en DC .


Ps: chez nous pas besoin de FCOE et coté perf on a pas besoin de 
descendre à la micro-seconde de commutation, environement 
academique/recherche mono site , bref on aimerai pouvoir le faire en 
catalyst car plus naturel pour nous et a priori moins onereux .


[1]
https://www.reddit.com/r/Cisco/comments/mqe4yd/nexus_vs_catalyst_any_limitations_as_a_tor/ 



https://askanydifference.com/difference-between-cisco-catalyst-and-nexus-with-table/

https://www.cablesandkits.com/learning-center/cisco-catalyst-vs-nexus-switches



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