2 votes

Endormissement des appareils Apple répondant aux requêtes ARP pour la passerelle par défaut

J'espère obtenir des informations sur un problème étrange qui a été observé dans quelques-uns de nos réseaux, ainsi que dans d'autres (d'après les messages de reddit et de NANOG). Le problème est que les appareils Apple (principalement les MacBooks ainsi que certains iMacs) qui sont dormant détourne l'adresse IP de la passerelle par défaut pour le VLAN sans fil dans lequel il se trouve et répond aux requêtes ARP demandant l'identité de la passerelle par défaut. Ce comportement fait apparaître dans le journal de l'AP le message suivant : "CAPWAP detected next hop MAC changed from correct_DG_mac_address to apple_mac_address."

Nous avons des tickets ouverts avec Cisco qui blâme Apple, et Apple qui déclare que nous avons besoin de logs qui sont totalement impossibles à obtenir car nous ne pouvons pas recréer ce comportement. La solution actuelle d'Apple ? Publier un script pour désactiver complètement la mise en veille sur tous les appareils Apple.

Plus de détails :

  • Ceci n'affecte que les WAP 3802i qui sont en mode flexconnect et les WAP 3802i qui sont en mode flexconnect. sur plusieurs sites, sur deux contrôleurs sans fil différents. différents. Les 3802i ne redémarrent pas - ils perdent la connectivité, Ils perdent la connectivité, se rétablissent et recommencent.

  • Les sous-réseaux sans fil sont généralement aussi grands que /20 et contiennent les AP's ainsi que tous les clients. Nous prévoyons de déplacer les AP vers un autre sous-réseau à titre de test. test, mais nous hésitons car si les AP ne se connectent plus, ils risquent d'avoir des problèmes de sécurité. plus le message CAPWAP/la chute de Prime - alors nous ne saurons pas quand ce comportement se produit, ce qui le rend plus difficile à suivre.

  • L'entrée ARP sur les commutateurs ne change JAMAIS. Pour cette raison, je DAI/DHCP snooping ne serait pas une solution efficace comme je l'ai vu comme je l'ai vu suggérer par d'autres.

  • Nous pensons que ce comportement peut être lié à une procuration du sommeil que l'on peut observer. avec les Apple TV prêtes à l'emploi, mais nous n'avons pas encore pu le prouver.

Ma question est la suivante : quelqu'un a-t-il déjà été confronté à ce type de comportement ? De plus, quelqu'un a-t-il des suggestions pour remédier à ce comportement afin qu'il ne se produise plus ?

1voto

mscwheat Points 11

Nous avons rencontré ce problème et nous utilisons le Cisco 3802 Flex Connect avec un WLC 8500.

Nous allons tenter le DIA ce week-end, mais Cisco et Apple nous disent qu'il n'y a pas grand-chose à faire. Cisco dit qu'ils auront un correctif pour le contrôleur sans fil pour introduire la sécurité ARP pour cela dans environ un mois et Apple ne veut pas divulguer au public quel est le problème ou quand leur correctif sortira pour le résoudre.

Quelques options qui nous ont été proposées comme solution temporaire -- rétrograder le WLC à la version 8.2 à partir de la version actuelle recommandée 8.5.140 -- Mise à jour du WLC vers la version 8.5.140.11, une version spéciale qui n'est pas fournie sans l'accord du support et qui nécessitera une réassociation DHCP sur chaque appareil en cas d'itinérance. Ce n'est pas un bon compromis. -- Supprimer Flex Connect et reconcevoir votre WLAN sur Central, ce qui permettrait d'acheminer le trafic ARP vers le WLC et d'utiliser la sécurité intégrée pour la protection ARP. "Nous n'allons pas faire cela

Ce que nous allons essayer ! Activez DIA sur la plateforme de commutation et enregistrez les chutes. L'espoir est que si cela provient d'un Macbook endormi, la chute n'aura pas d'importance et nous verrons une sorte de confinement.

C'est notre dernière option.

0voto

quakkels Points 2957

Il s'agit du document public de Cisco sur le sujet. https://www.cisco.com/c/en/us/support/docs/wireless/aironet-3800-series-access-points/214491-arp-responses-for-default-gateway-ip-add.html

Le problème est réel. J'en ai fait l'expérience à grande échelle. J'ai vu des captures de paquets réelles du comportement décrit dans l'article.

Les solutions énumérées permettent de résoudre le problème. Je les ai mises en œuvre directement à l'échelle.

La version 8.5.151 vient d'être publiée sur CCO le 21 juin.

-1voto

Muttley Points 1

Je rencontre exactement le même problème avec les AP meraiki.

Une mise à jour récente du micrologiciel a été effectuée. D'un autre côté, Apple fait des mises à jour tout le temps. Nous ne sommes donc pas sûrs qu'il s'agisse de la mise à jour du firmware à ce stade.

Meraiki 25.13 OSX 10.14.4

Nous avons réussi à atténuer le problème en activant l'isolation du client sur le SSID.

Muttley.

LesApples.com

LesApples est une communauté de Apple où vous pouvez résoudre vos problèmes et vos doutes. Vous pouvez consulter les questions des autres utilisateurs d'appareils Apple, poser vos propres questions ou résoudre celles des autres.

Powered by:

X