RE: [FRnOG] [TECH] Problème MTU sur Nexus 3064Pq

2019-12-26 Par sujet Michel Py
Bon finalement j’ai le temps de faire un lab avec çà :

[long et technique]

Le lab est toujours up, si quelqu'un veut que je fasse une bidouille 
différente, demandez.



n3k-spare# write erase

Warning: This command will erase the startup-configuration.

Do you wish to proceed anyway? (y/n)  [n] y

n3k-spare# reload

This command will reboot the system. (y/n)?  [n] y

2013 Dec  4 08:56:20 n3k-spare %$ VDC-1 %$ %PLATFORM-2-PFM_SYSTEM_RESET: Manual 
system restart from Command Line Interface

Press  ctrl L to go to loader prompt in 2 secs

Booting kickstart image: bootflash:/nxos.7.0.3.I4.6.bin



[...]

switch# conf t

Enter configuration commands, one per line. End with CNTL/Z.

switch(config)# no password strength-check

switch(config)# username admin password cisco role network-admin

switch(config)# hardware profile portmode 48x10G+4x40G

timezone PST -8 0

cWarning: This command will take effect only after saving the configuration and 
reload! Port configurations could get lost when port

mode is changed! We suggest you clean up the impacted interfaces config and 
redo them after boot up!

lock summer-time PDT 2 Sun Mar 02:00 1 Sun Nov 02:00 60

cli alias name wr copy running-config startup-config

banner motd ^

Nexus n3064PQ Spare

no IP

no VLANS

switch(config)# clock timezone PST -8 0

switch(config)# clock summer-time PDT 2 Sun Mar 02:00 1 Sun Nov 02:00 60

switch(config)# cli alias name wr copy running-config startup-config

switch(config)# banner motd ^

Enter TEXT message. End with the character '^'.

> Nexus n3064PQ Spare

> no IP

> no VLANS

> ^

switch(config)# host n3k-spare

n3k-spare# exit

n3k-spare# wr

[] 100%

Copy complete, now saving to disk (please wait)...

n3k-spare# reload



[...]

n3k-spare# sh ver

  BIOS: version 4.0.0

  NXOS image file is: bootflash:///nxos.7.0.3.I4.6.bin

Hardware

  cisco Nexus3064 Chassis

  Intel(R) Celeron(R) CPUP4505  @ 1.87GHz with 3903304 kB of memory.





Sans aucune surprise, une config par défaut relativement complète est installée 
automatiquement :



n3k-spare# sh run



!Command: show running-config

!Time: Wed Dec  4 09:14:32 2013



version 7.0(3)I4(6)

hostname n3k-spare

vdc n3k-spare id 1

  limit-resource vlan minimum 16 maximum 4094

  limit-resource vrf minimum 2 maximum 4096

  limit-resource port-channel minimum 0 maximum 104

  limit-resource u4route-mem minimum 128 maximum 128

  limit-resource u6route-mem minimum 96 maximum 96

  limit-resource m4route-mem minimum 58 maximum 58

  limit-resource m6route-mem minimum 8 maximum 8



feature lldp



no password strength-check

username admin password 5 $5$mnxxpAh/$l7R9Ow5xXr5rSiUHIHrXNtzETSkJgQzPq8ZpBdVBul

D  role network-admin



banner motd ^

Nexus c3064PQ Spare

no IP

no VLANS

^



ip domain-lookup

service unsupported-transceiver

ip access-list copp-system-acl-eigrp

  10 permit eigrp any 224.0.0.10/32

ipv6 access-list copp-system-acl-eigrp6

  10 permit eigrp any ff02::a/128

ip access-list copp-system-acl-icmp

  10 permit icmp any any

ip access-list copp-system-acl-igmp

  10 permit igmp any any

ip access-list copp-system-acl-ntp

  10 permit udp any any eq ntp

  20 permit udp any eq ntp any

ip access-list copp-system-acl-pimreg

  10 permit pim any any

ip access-list copp-system-acl-ping

  10 permit icmp any any echo

  20 permit icmp any any echo-reply

ip access-list copp-system-acl-routingproto1

  10 permit tcp any gt 1024 any eq bgp

  20 permit tcp any eq bgp any gt 1024

  30 permit udp any 224.0.0.0/24 eq rip

  40 permit tcp any gt 1024 any eq 639

  50 permit tcp any eq 639 any gt 1024

  70 permit ospf any any

  80 permit ospf any 224.0.0.5/32

  90 permit ospf any 224.0.0.6/32

ip access-list copp-system-acl-routingproto2

  10 permit udp any 224.0.0.0/24 eq 1985

  20 permit 112 any 224.0.0.0/24

ip access-list copp-system-acl-snmp

  10 permit udp any any eq snmp

  20 permit udp any any eq snmptrap

ip access-list copp-system-acl-ssh

  10 permit tcp any any eq 22

  20 permit tcp any eq 22 any

ip access-list copp-system-acl-stftp

  10 permit udp any any eq tftp

  20 permit udp any any eq 1758

  30 permit udp any eq tftp any

  40 permit udp any eq 1758 any

  50 permit tcp any any eq 115

  60 permit tcp any eq 115 any

ip access-list copp-system-acl-tacacsradius

  10 permit tcp any any eq tacacs

  20 permit tcp any eq tacacs any

  30 permit udp any any eq 1812

  40 permit udp any any eq 1813

  50 permit udp any any eq 1645

  60 permit udp any any eq 1646

  70 permit udp any eq 1812 any

  80 permit udp any eq 1813 any

  90 permit udp any eq 1645 any

  100 permit udp any eq 1646 any

ip access-list copp-system-acl-telnet

  10 permit tcp any any eq telnet

  20 permit tcp any any eq 107

  30 permit tcp any eq telnet any

  40 permit tcp any eq 107 any

ipv6 access-list copp-system-acl-v6routingProto2

  10 permit udp any ff02::66/128 eq 2029

  20 permit udp any ff02::fb/128 eq 

RE: [FRnOG] [TECH] Problème MTU sur Nexus 3064Pq

2019-12-23 Par sujet MULLER Samuel
Hello Jérémy,

Quel type de lien utilises-tu ?
Je ne trouve pas de fournisseur capable de me fournir une MTU supérieure à 9000 
...
sauf si j'allume moi-même ma fibre, ce qui n'est pas possible en l'état.

Merci pour l'info,

Sam

-Message d'origine-
De : frnog-requ...@frnog.org [mailto:frnog-requ...@frnog.org] De la part de 
Jeremy
Envoyé : samedi 14 décembre 2019 14:23
À : frnog-tech
Objet : Re: [FRnOG] [TECH] Problème MTU sur Nexus 3064Pq

Bonjour,

Après un reload du switch qui pose problème, la MTU est ok.
Donc sachez le, sur certaines version de NXos, pas besoin de reload, 
mais en version 6 rev 5 et inférieur, il faut reload. Pas besoin sur les 
versions supérieures.

Excellent week end à tous,

Jérémy

Le 14/12/2019 à 00:38, Jeremy a écrit :
> On me glisse à l'oreille via un gazoulli qu'il faut impérativement 
> reload le switch en cas de changement de la Qos MTU à la volée.
> Bon bah caramba, on va prévenir les clients !
>
> J'indiquerais si cela résoud le problème ou non.
>
> Le 13/12/2019 à 22:45, Jeremy a écrit :
>> Bonjour les amis,
>>
>> Je viens ici pour trouver conseil sur un problème de MTU sur lequel 
>> je m'arrache les cheveux.
>> La typologie du réseau est simple. Un lien de transport L2L 
>> transparent opéré par TDF entre Lille et Valenciennes.
>> Tous les équipements sont des Nexus 3064PQ.
>>
>> Le chemin fait :
>> Nexus Lille > Nexus Valenciennes > Nexus Marly > Nexus Anzin
>>
>> Sur cette liaison, la MTU doit être à 9216 octets. J'ai pu 
>> l'appliquer sur tous les switchs sauf celui de Marly qui refuse 
>> toujours d'appliquer la Qos.
>>
>> En conf, j'ai appliqué ces commandes :
>> policy-map type network-qos jumbo
>>   class type network-qos class-default
>>     mtu 9216
>> system qos
>>   service-policy type network-qos jumbo
>>
>> Sans effet sur les ports.
>> J'ai donc appliqué une autre méthode glané sur le net, qui consiste à 
>> enlever le Trunk du port, passer un "no switchport", puis un "mtu 
>> 9216" puis repasser le port en mode Trunk. Ca a fonctionné sur celui 
>> de Valenciennes qui était récalcitrant aussi. L'interface devrait me 
>> dire ça (sur le switch de Valenciennes) :
>>
>> Ethernet1/48 is up
>>  Dedicated Interface
>>   Hardware: 100/1000/1 Ethernet, address: fc5b.39xx. (bia 
>> fc5b.39xx.)
>>   Description: Core: xxx-LILLE-to-MARLY59-xxx
>>   MTU 9216 bytes, BW 1000 Kbit, DLY 10 usec
>>
>> Mais elle me dis ça sur le switch de Marly:
>>
>> Ethernet1/48 is up
>>  Dedicated Interface
>>   Hardware: 100/1000/1 Ethernet, address: 6412.25xx. (bia 
>> 6412.25xx.)
>>   Description: Core: xxx-LILLE-via-NEXUS-3K-xxx
>>   MTU 1500 bytes, BW 1000 Kbit, DLY 10 usec
>>
>> Même version d'Os sur les deux switch :
>> Software
>> (...)
>>   system:    version 6.0(2)U6(8)
>>
>> Difficile de faire beaucoup de tests (shutdown, reload) car c'est en 
>> prod, et il faut shutdown tout le trafic et c'est pas toujours 
>> évident...
>> Est ce que quelqu'un aurait une idée lumineuse qui résoudrait ce 
>> casse tête ?
>>
>> Merci !
>> Jérémy
>>
>>
>> ---
>> 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/


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


RE: [FRnOG] [TECH] Problème MTU sur Nexus 3064Pq

2019-12-20 Par sujet Michel Py
> Thierry Chich a écrit :
> D'un point de vue conceptuel, qu'est-ce qui justifie qu'on mêle QoS et MTU ? 
> Je trouve ça bizarre.

Pas du tout, c'est tout à fait logique. Par exemple la voix : pour éviter la 
gigue qui est l'ennemie de VOIP, c'est une très bonne idée de classifier la 
voix qui est des petits paquets dans une file prioritaire qui va se vider avant 
les paquets de 9 KO qui mettent plus de temps à être sérialisés.

Michel.


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


RE: [FRnOG] [TECH] Problème MTU sur Nexus 3064Pq

2019-12-20 Par sujet Thierry Chich
Hello

D'un point de vue conceptuel, qu'est-ce qui justifie qu'on mêle QoS et MTU ? Je 
trouve ça bizarre.  

Thierry

> -Message d'origine-
> De : frnog-requ...@frnog.org  De la part de
> Jérôme BERTHIER
> Envoyé : vendredi 20 décembre 2019 10:24
> À : Michel Py ; Jeremy
> ; frnog-tech 
> Objet : Re: [FRnOG] [TECH] Problème MTU sur Nexus 3064Pq
> 
> Salut,
> 
> Le 19/12/2019 à 22:48, Michel Py a écrit :
> > Le MTU renvoyé par l'interface, il est applicable dans quel cas ?
> 
> 
> Visiblement, en l'état par défaut, si tu n'appliques pas de Network QOS...
> 
> En fait, je pense que ça dépend des modèles et ça se complique sur ceux qui
> supportent la convergence SAN.
> 
> 
> Tu peux utiliser un MTU différent par classe de service donc au final le
> MTU de l'interface n'a pas vraiment d'application (sauf par défaut ?).
> 
> "MTU is specified per system class. The system class allows a different
> MTU for each class of traffic but they must be consistent on all ports
> across the entire switch. You cannot configure MTU on the interfaces."
> 
> "The show interface command always displays 1500 as the MTU. Because the
> Cisco Nexus device supports different MTUs for different QoS groups, it
> is not possible to represent the MTU as one value on a per interface level."
> 
> 
> Exemple Nexus 5600 :
> https://www.cisco.com/c/en/us/td/docs/switches/datacenter/nexus5600/s
> w/qos/7x/b_5600_QoS_Config_7x/b_6k_QoS_Config_7x_chapter_0110.htm
> l
> 
> 
> > Est-ce que çà ne serait pas plus glop de le supprimer au lieu de la 
> > confusion
> ?
> 
> 
> On est bien d'accord que ça crée une situation illisible. ça a l'air
> complètement dépendant du modèle.
> 
> Bref, au moins pour les 3000, il semble que la valeur soit adaptée
> correctement sur l'interface pour les versions NX-OS récentes :
> 
> "Note: When the Nexus 3000 is on code earlier than 7.0(3)I2(2a), check
> the MTU value with the show queueing interface ethernet x/x command.
> Nexus 3000 switches that run 7.0(3)I2(2a) and later show the MTU size on
> a per-port basis."
> 
> 
> A+
> 
> --
> Jérôme BERTHIER
> 
> 
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/


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


Re: [FRnOG] [TECH] Problème MTU sur Nexus 3064Pq

2019-12-20 Par sujet Jérôme BERTHIER

Salut,

Le 19/12/2019 à 22:48, Michel Py a écrit :

Le MTU renvoyé par l'interface, il est applicable dans quel cas ?



Visiblement, en l'état par défaut, si tu n'appliques pas de Network QOS...

En fait, je pense que ça dépend des modèles et ça se complique sur ceux 
qui supportent la convergence SAN.



Tu peux utiliser un MTU différent par classe de service donc au final le 
MTU de l'interface n'a pas vraiment d'application (sauf par défaut ?).


"MTU is specified per system class. The system class allows a different 
MTU for each class of traffic but they must be consistent on all ports 
across the entire switch. You cannot configure MTU on the interfaces."


"The show interface command always displays 1500 as the MTU. Because the 
Cisco Nexus device supports different MTUs for different QoS groups, it 
is not possible to represent the MTU as one value on a per interface level."



Exemple Nexus 5600 : 
https://www.cisco.com/c/en/us/td/docs/switches/datacenter/nexus5600/sw/qos/7x/b_5600_QoS_Config_7x/b_6k_QoS_Config_7x_chapter_0110.html




Est-ce que çà ne serait pas plus glop de le supprimer au lieu de la confusion ?



On est bien d'accord que ça crée une situation illisible. ça a l'air 
complètement dépendant du modèle.


Bref, au moins pour les 3000, il semble que la valeur soit adaptée 
correctement sur l'interface pour les versions NX-OS récentes :


"Note: When the Nexus 3000 is on code earlier than 7.0(3)I2(2a), check 
the MTU value with the show queueing interface ethernet x/x command. 
Nexus 3000 switches that run 7.0(3)I2(2a) and later show the MTU size on 
a per-port basis."



A+

--
Jérôme BERTHIER


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


RE: [FRnOG] [TECH] Problème MTU sur Nexus 3064Pq

2019-12-19 Par sujet Michel Py
> Jérôme BERTHIER a écrit :
> Certains supportent un MTU par port et la majorité nécessite une 
> application Network QOS (et ne change pas le MTU renvoyé par l'interface)

Le MTU renvoyé par l'interface, il est applicable dans quel cas ?
Est-ce que çà ne serait pas plus glop de le supprimer au lieu de la confusion ?

Michel.


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


Re: [FRnOG] [TECH] Problème MTU sur Nexus 3064Pq

2019-12-19 Par sujet Jérôme BERTHIER

Le 13/12/2019 à 22:45, Jeremy a écrit :
Sur cette liaison, la MTU doit être à 9216 octets. J'ai pu l'appliquer 
sur tous les switchs sauf celui de Marly qui refuse toujours 
d'appliquer la Qos.


En conf, j'ai appliqué ces commandes :
policy-map type network-qos jumbo
  class type network-qos class-default
    mtu 9216
system qos
  service-policy type network-qos jumbo

Sans effet sur les ports.
J'ai donc appliqué une autre méthode glané sur le net, qui consiste à 
enlever le Trunk du port, passer un "no switchport", puis un "mtu 
9216" puis repasser le port en mode Trunk. Ca a fonctionné sur celui 
de Valenciennes qui était récalcitrant aussi. L'interface devrait me 
dire ça (sur le switch de Valenciennes) :


Bonjour,

En fait, ça dépend du modèle Nexus.

Certains supportent un MTU par port et la majorité nécessite une 
application Network QOS (et ne change pas le MTU renvoyé par l'interface) :


https://www.cisco.com/c/en/us/support/docs/switches/nexus-9000-series-switches/118994-config-nexus-00.html#anc8

Je pense que ça explique pourquoi une partie de tes switchs affiche 
correctement le MTU modifié.


Pas de besoin de reload (heureusement).

Exemple sur un 5500 en prod sous NX-OS 7.3 :

sw1# sh int Eth1/1 | i MTU
  MTU 1500 bytes,  BW 1000 Kbit, DLY 10 usec

sw1# sh queuing int Eth1/1 | i MTU
    q-size: 469760, q-size-40g: 0, HW MTU: 9216 (9216 configured)

=> le MTU défini par Network QOS est bien appliqué

Bonne journée

--
Jérôme BERTHIER


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


Re: [FRnOG] [TECH] Problème MTU sur Nexus 3064Pq

2019-12-14 Par sujet Jeremy

Bonjour,

Après un reload du switch qui pose problème, la MTU est ok.
Donc sachez le, sur certaines version de NXos, pas besoin de reload, 
mais en version 6 rev 5 et inférieur, il faut reload. Pas besoin sur les 
versions supérieures.


Excellent week end à tous,

Jérémy

Le 14/12/2019 à 00:38, Jeremy a écrit :
On me glisse à l'oreille via un gazoulli qu'il faut impérativement 
reload le switch en cas de changement de la Qos MTU à la volée.

Bon bah caramba, on va prévenir les clients !

J'indiquerais si cela résoud le problème ou non.

Le 13/12/2019 à 22:45, Jeremy a écrit :

Bonjour les amis,

Je viens ici pour trouver conseil sur un problème de MTU sur lequel 
je m'arrache les cheveux.
La typologie du réseau est simple. Un lien de transport L2L 
transparent opéré par TDF entre Lille et Valenciennes.

Tous les équipements sont des Nexus 3064PQ.

Le chemin fait :
Nexus Lille > Nexus Valenciennes > Nexus Marly > Nexus Anzin

Sur cette liaison, la MTU doit être à 9216 octets. J'ai pu 
l'appliquer sur tous les switchs sauf celui de Marly qui refuse 
toujours d'appliquer la Qos.


En conf, j'ai appliqué ces commandes :
policy-map type network-qos jumbo
  class type network-qos class-default
    mtu 9216
system qos
  service-policy type network-qos jumbo

Sans effet sur les ports.
J'ai donc appliqué une autre méthode glané sur le net, qui consiste à 
enlever le Trunk du port, passer un "no switchport", puis un "mtu 
9216" puis repasser le port en mode Trunk. Ca a fonctionné sur celui 
de Valenciennes qui était récalcitrant aussi. L'interface devrait me 
dire ça (sur le switch de Valenciennes) :


Ethernet1/48 is up
 Dedicated Interface
  Hardware: 100/1000/1 Ethernet, address: fc5b.39xx. (bia 
fc5b.39xx.)

  Description: Core: xxx-LILLE-to-MARLY59-xxx
  MTU 9216 bytes, BW 1000 Kbit, DLY 10 usec

Mais elle me dis ça sur le switch de Marly:

Ethernet1/48 is up
 Dedicated Interface
  Hardware: 100/1000/1 Ethernet, address: 6412.25xx. (bia 
6412.25xx.)

  Description: Core: xxx-LILLE-via-NEXUS-3K-xxx
  MTU 1500 bytes, BW 1000 Kbit, DLY 10 usec

Même version d'Os sur les deux switch :
Software
(...)
  system:    version 6.0(2)U6(8)

Difficile de faire beaucoup de tests (shutdown, reload) car c'est en 
prod, et il faut shutdown tout le trafic et c'est pas toujours 
évident...
Est ce que quelqu'un aurait une idée lumineuse qui résoudrait ce 
casse tête ?


Merci !
Jérémy


---
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] [TECH] Problème MTU sur Nexus 3064Pq

2019-12-13 Par sujet Michel Py
> On est sur cette version car le broker a envoyé ça. Pas toujours façile 
> de trouver des version dont on est sur qu'il y a rien de chelou dedans.

Je suis en 7.0(3)I4(6) c'est ce que j'ai eu quand je les ai achetés.
Je me suis laissé dire que quand tu mets une nouvelle version, c'est parfois 
nécessaire de faire un write erase et de coller la config a la main.
C'est en général ce que je fais, il y a des fois ou il garde des trucs genre 
snmp-if-index qu'il vaut mieux remettre à zéro.

Michel.
 

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


Re: [FRnOG] [TECH] Problème MTU sur Nexus 3064Pq

2019-12-13 Par sujet Jeremy

Salut,

Tu es sur quelle version ? On a remarqué qu'on a ce bug sur une version 
bien particulière. On vient de reload (vu l'heure on pouvait se 
permettre), et la MTU n'est toujours pas bonne. Sur un autre switch, la 
version est la révision 6.0(5c) et sur l'autre on est en 6.0(8) et là ça 
affiche bien 9216 en MTU sur les ports.


On est sur cette version car le broker a envoyé ça. Pas toujours façile 
de trouver des version dont on est sur qu'il y a rien de chelou dedans.


Jérémy

Le 14/12/2019 à 01:07, Michel Py a écrit :

Jeremy a écrit :
policy-map type network-qos jumbo
   class type network-qos class-default
     mtu 9216
system qos
   service-policy type network-qos jumbo

Je viens d'essayer çà sur le miens, et les interfaces sont toujours à 1500.
Le reload c'est carrément pas pratique pour moi, va falloir que j'attende.

Par curiosité, pourquoi tu es encore en NXOS 6 ?

Michel.


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



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


RE: [FRnOG] [TECH] Problème MTU sur Nexus 3064Pq

2019-12-13 Par sujet Michel Py
> Jeremy a écrit :
> policy-map type network-qos jumbo
>   class type network-qos class-default
>     mtu 9216
> system qos
>   service-policy type network-qos jumbo

Je viens d'essayer çà sur le miens, et les interfaces sont toujours à 1500.
Le reload c'est carrément pas pratique pour moi, va falloir que j'attende.

Par curiosité, pourquoi tu es encore en NXOS 6 ?

Michel.


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


Re: [FRnOG] [TECH] Problème MTU sur Nexus 3064Pq

2019-12-13 Par sujet Jeremy
On me glisse à l'oreille via un gazoulli qu'il faut impérativement 
reload le switch en cas de changement de la Qos MTU à la volée.

Bon bah caramba, on va prévenir les clients !

J'indiquerais si cela résoud le problème ou non.

Le 13/12/2019 à 22:45, Jeremy a écrit :

Bonjour les amis,

Je viens ici pour trouver conseil sur un problème de MTU sur lequel je 
m'arrache les cheveux.
La typologie du réseau est simple. Un lien de transport L2L 
transparent opéré par TDF entre Lille et Valenciennes.

Tous les équipements sont des Nexus 3064PQ.

Le chemin fait :
Nexus Lille > Nexus Valenciennes > Nexus Marly > Nexus Anzin

Sur cette liaison, la MTU doit être à 9216 octets. J'ai pu l'appliquer 
sur tous les switchs sauf celui de Marly qui refuse toujours 
d'appliquer la Qos.


En conf, j'ai appliqué ces commandes :
policy-map type network-qos jumbo
  class type network-qos class-default
    mtu 9216
system qos
  service-policy type network-qos jumbo

Sans effet sur les ports.
J'ai donc appliqué une autre méthode glané sur le net, qui consiste à 
enlever le Trunk du port, passer un "no switchport", puis un "mtu 
9216" puis repasser le port en mode Trunk. Ca a fonctionné sur celui 
de Valenciennes qui était récalcitrant aussi. L'interface devrait me 
dire ça (sur le switch de Valenciennes) :


Ethernet1/48 is up
 Dedicated Interface
  Hardware: 100/1000/1 Ethernet, address: fc5b.39xx. (bia 
fc5b.39xx.)

  Description: Core: xxx-LILLE-to-MARLY59-xxx
  MTU 9216 bytes, BW 1000 Kbit, DLY 10 usec

Mais elle me dis ça sur le switch de Marly:

Ethernet1/48 is up
 Dedicated Interface
  Hardware: 100/1000/1 Ethernet, address: 6412.25xx. (bia 
6412.25xx.)

  Description: Core: xxx-LILLE-via-NEXUS-3K-xxx
  MTU 1500 bytes, BW 1000 Kbit, DLY 10 usec

Même version d'Os sur les deux switch :
Software
(...)
  system:    version 6.0(2)U6(8)

Difficile de faire beaucoup de tests (shutdown, reload) car c'est en 
prod, et il faut shutdown tout le trafic et c'est pas toujours évident...
Est ce que quelqu'un aurait une idée lumineuse qui résoudrait ce casse 
tête ?


Merci !
Jérémy


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




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


Re: [FRnOG] [TECH] Problème MTU sur Nexus 3064Pq

2019-12-13 Par sujet David Ponzone
Tu as vu ça ?
https://davidring.ie/2015/09/02/cisco-nexus-3064-configuring-jumbo-frames/

D’après lui, la valeur renvoyée par sh int est bidon, elle reste à 1500.
C’est donc étonnant que tu aies des 3000 sur lequel la valeur a changé.
Peut-être que le lien date.

> Le 13 déc. 2019 à 22:45, Jeremy  a écrit :
> 
> Sans effet sur les ports.
> J'ai donc appliqué une autre méthode glané sur le net, qui consiste à enlever 
> le Trunk du port, passer un "no switchport", puis un "mtu 9216" puis repasser 
> le port en mode Trunk. Ca a fonctionné sur celui de Valenciennes qui était 
> récalcitrant aussi. L'interface devrait me dire ça (sur le switch de 
> Valenciennes) :
> 
> Ethernet1/48 is up
>  Dedicated Interface
>   Hardware: 100/1000/1 Ethernet, address: fc5b.39xx. (bia 
> fc5b.39xx.)
>   Description: Core: xxx-LILLE-to-MARLY59-xxx
>   MTU 9216 bytes, BW 1000 Kbit, DLY 10 usec
> 
> Mais elle me dis ça sur le switch de Marly:
> 
> Ethernet1/48 is up
>  Dedicated Interface
>   Hardware: 100/1000/1 Ethernet, address: 6412.25xx. (bia 
> 6412.25xx.)
>   Description: Core: xxx-LILLE-via-NEXUS-3K-xxx
>   MTU 1500 bytes, BW 1000 Kbit, DLY 10 usec
> 
> Même version d'Os sur les deux switch :
> Software
> (...)
>   system:version 6.0(2)U6(8)
> 
> Difficile de faire beaucoup de tests (shutdown, reload) car c'est en prod, et 
> il faut shutdown tout le trafic et c'est pas toujours évident...
> Est ce que quelqu'un aurait une idée lumineuse qui résoudrait ce casse tête ?
> 
> Merci !
> Jérémy
> 
> 
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/


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


[FRnOG] [TECH] Problème MTU sur Nexus 3064Pq

2019-12-13 Par sujet Jeremy

Bonjour les amis,

Je viens ici pour trouver conseil sur un problème de MTU sur lequel je 
m'arrache les cheveux.
La typologie du réseau est simple. Un lien de transport L2L transparent 
opéré par TDF entre Lille et Valenciennes.

Tous les équipements sont des Nexus 3064PQ.

Le chemin fait :
Nexus Lille > Nexus Valenciennes > Nexus Marly > Nexus Anzin

Sur cette liaison, la MTU doit être à 9216 octets. J'ai pu l'appliquer 
sur tous les switchs sauf celui de Marly qui refuse toujours d'appliquer 
la Qos.


En conf, j'ai appliqué ces commandes :
policy-map type network-qos jumbo
  class type network-qos class-default
    mtu 9216
system qos
  service-policy type network-qos jumbo

Sans effet sur les ports.
J'ai donc appliqué une autre méthode glané sur le net, qui consiste à 
enlever le Trunk du port, passer un "no switchport", puis un "mtu 9216" 
puis repasser le port en mode Trunk. Ca a fonctionné sur celui de 
Valenciennes qui était récalcitrant aussi. L'interface devrait me dire 
ça (sur le switch de Valenciennes) :


Ethernet1/48 is up
 Dedicated Interface
  Hardware: 100/1000/1 Ethernet, address: fc5b.39xx. (bia 
fc5b.39xx.)

  Description: Core: xxx-LILLE-to-MARLY59-xxx
  MTU 9216 bytes, BW 1000 Kbit, DLY 10 usec

Mais elle me dis ça sur le switch de Marly:

Ethernet1/48 is up
 Dedicated Interface
  Hardware: 100/1000/1 Ethernet, address: 6412.25xx. (bia 
6412.25xx.)

  Description: Core: xxx-LILLE-via-NEXUS-3K-xxx
  MTU 1500 bytes, BW 1000 Kbit, DLY 10 usec

Même version d'Os sur les deux switch :
Software
(...)
  system:    version 6.0(2)U6(8)

Difficile de faire beaucoup de tests (shutdown, reload) car c'est en 
prod, et il faut shutdown tout le trafic et c'est pas toujours évident...
Est ce que quelqu'un aurait une idée lumineuse qui résoudrait ce casse 
tête ?


Merci !
Jérémy


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