BUG ARP - "Duplicate IP Address 0.0.0.0"

[julien.roulland]

Bonjour,

Qui a plus d'informations sur ce bug ?

Ancien sujet déjà existant mais sans mise à jour depuis 2015.

https://www.cisco.com/c/en/us/support/docs/ios-nx-os-software/8021x/116529-problemsolution-product-00.html

Informations sur l'environnement : CISCO 2960x ios 15.2.2E7 en utilisant 802.1x et MAB

En fait, "Cette dernière commande CLI a été introduite par l'ID de bogue Cisco CSCtn27420 dans la version 15.2(2)E de Cisco IOS. Elle a été ajoutée afin de permettre une adresse IP source de demande ARP définie par l'utilisateur au lieu de l'exigence d'utiliser l'adresse IP source par défaut de 0.0.0.0. La nouvelle commande globale ip device tracking probe auto-source fallback 0.0.0.x 255.255.255.0 override permet à l'utilisateur d'utiliser l'adresse hôte de 0.0.0.x dans le sous-réseau afin d'éviter toute adresse IP en double. S'il n'y a pas de SVI pour un VLAN particulier, l'hôte-IP de secours sera utilisée pour la source de la sonde à la place."

Quel est l'impact de changer la source. L'erreur sera changée en "a conflit with 0.0.0.1" au lieu de 0.0.0.0 ?

Je ne comprends pas vraiment l'effet ? Pouvez-vous m'éclairer sur ce scénario s'il vous plait ?

Salutations

Texte d'origine:

Hello,

Who have more informations about this bug?
Old topic already existing but without update since 2015.
https://www.cisco.com/c/en/us/support/docs/ios-nx-os-software/8021x/116529-problemsolution-product-00.html

environnement Informations  :
CISCO 2960x     
ios 15.2.2E7
using 802.1x and MAB

In fact,
"This latest CLI command was introduced through Cisco bug ID CSCtn27420 in Cisco IOS Version 15.2(2)E. It was added in order to allow a user-defined ARP request source IP address instead of the requirement to use the default source IP address of 0.0.0.0. The new global command ip device tracking probe auto-source fallback 0.0.0.x 255.255.255.0 override allows the user to use the host address of 0.0.0.x in the subnet in order to avoid any duplicate IP address problems.  If there is no SVI for a particular VLAN the fallback host-ip will be used to source the probe instead."

What is the impact to change the source. The error will changed to "a conflit with 0.0.0.1" instaed of 0.0.0.0 ?
I don't understand really the effect? 
Please can you clarify to me this scenario?

Regards

[educruz]

Bonjour.

Les PC Microsoft Windows disposent d'un mécanisme pour détecter une adresse IP en double à l'aide de sondes ARP. La façon dont Cisco IOS envoie des sondes ARP afin de garder une trace des endpoints à des fins IPDT (réseau 0.0.0.0) peut entrer en conflit avec le mécanisme de Microsoft Windows.

Dès que nous changeons cette adresse 0.0.0.0 pour toute autre adresse IP, le conflit disparaît. Les PC Microsoft Windows recevront toujours un paquet mais avec une adresse de 0.0.0.x qui est ignorée par leur mécanisme d'adresse en double.

Cordialement,

Eduardo CRUZ

Consulting Engineer @ Cisco Systems France

[julien.roulland]

Hello Eduardo,

Merci de ton retour. J'avais essayé cette modification, mais l'autocom Alcatel en authentification MAB c'est mis en vrac direct en détectant un conflit d'IP. Je n'ai pas pu tester longtemps.

Mais effectivement, j'avais noté cette solution comme la seule viable. 

Donc, il n'y a aucun problème d'optimiser le tracking ip tel que ?

ip device tracking probe auto-source fallback 0.0.0.1 255.255.255.0 override

ou
 0.0.0.1 peut-être aussi 0.0.0.254 ? cela n'a pas d'impacte réel? Il change juste l'IP dans la trame ARP envoyée?

On garde aussi le paramètre  ?

ip device tracking probe delay 10

Je vais essayer de repasser ce paramètre.

@suivre 

Merci pour ton assistance

++

[educruz]

Hello Julien, 

Effectivement, une combinaison des commandes: ip device tracking probe auto-source fallback 0.0.0.1 255.255.255.0 override

et ip device tracking probe delay 10 devrait marcher pour éviter les conflicts. 

L'objectif est de s'assurer que lorsque les endpoints envoient leur sonde pour la détection de conflit d'adresses, ils ne reçoivent aucune réponse car nous avons retardé nos sondes ARP pour IPDT et parce qu'une adresse IP différente est utilisée pour ces sondes IPDT.

J'espère que cela peut aider mais n'hésitez pas à me contacter si vous avez toujours le problème. 

Merci,

Cordialement,

Eduardo CRUZ

Consulting Engineer @ Cisco Systems France