RE: [FRnOG] [TECH] Problème MTU sur Nexus 3064Pq
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 53
RE: [FRnOG] [TECH] Problème MTU sur Nexus 3064Pq
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
> 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
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
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
> 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
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
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
> 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
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
> 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
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
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/