In questo documento vengono descritti gli scenari di configurazione della mobilità che riguardano le topologie tra i Wireless LAN Controller (WLC) Catalyst 9800 e i WLC AireOS.
Cisco raccomanda la conoscenza dei seguenti argomenti:
Inter Release Controller Mobility (IRCM) speciali 8.5Le informazioni discusse in questo documento fanno riferimento a dispositivi usati in uno specifico ambiente di emulazione. Su tutti i dispositivi menzionati nel documento la configurazione è stata ripristinata ai valori predefiniti. Se la rete è operativa, valutare attentamente eventuali conseguenze derivanti dall'uso dei comandi.

Il nome del gruppo di mobilità su 9800 è predefinito.
In questo esempio di base viene descritto come configurare la mobilità tra due controller 9800. Viene in genere utilizzato per l'accesso guest (ancoraggio) o per consentire ai client di spostarsi tra i controller e mantenere l'identità del client.
Quando si configura la mobilità su C9800, è innanzitutto necessario scegliere il nome del gruppo di mobilità. Il nome del gruppo di mobilità precompilato è un valore predefinito, ma è possibile personalizzarlo in base al valore desiderato.
È necessario configurare lo stesso nome del gruppo di mobilità tra i controller quando un roaming veloce di layer 2 è simile a Fast Transition (FT) o Cisco Centralized Key Management (CCKM) è in uso.
Per impostazione predefinita, l'indirizzo MAC Ethernet di base dello chassis, come mostrato nella, show version viene riflesso sulla GUI per l'indirizzo MAC della mobilità. Nella CLI, per impostazione predefinita, il mac della mobilità è 0000.000.000 come mostrato nella show run all | inc mobility mac-address.
Nei casi in cui 9800 vengono accoppiati per High Availability (HA) Stateful Switchover (SSO):
Se la configurazione viene mantenuta per impostazione predefinita e l'indirizzo MAC dello chassis viene utilizzato per formare il tunnel di mobilità, lo chassis attivo e il tunnel di mobilità avranno esito negativo in caso di failover. Pertanto, è necessario configurare un indirizzo MAC di mobilità per la coppia C9800 HA.
Passaggio 1: Dalla GUI, selezionare Configuration > Wireless > Mobility > Global Configuration.

Dalla CLI:
# config t # wireless mobility mac-address <AAAA.BBBB.CCCC>
# wireless mobility group name <mobility-group-name>
Per entrambi i WLC, 9800, individuare Configuration > Wireless > Mobility > Global Configuration e prendere nota delleMobility Group Namee Mobility MAC Addressdel.
Dalla CLI:
#show wireless mobility summary Mobility Summary Wireless Management VLAN: 2652
Wireless Management IP Address: 172.16.51.88
Wireless Management IPv6 Address:
Mobility Control Message DSCP Value: 48
Mobility Keepalive Interval/Count: 10/3
Mobility Group Name: default
Mobility Multicast Ipv4 address: 0.0.0.0
Mobility Multicast Ipv6 address: ::
Mobility MAC Address: 001e.e67e.75ff
Mobility Domain Identifier: 0x34ac
Individuare Configuration > Wireless > Mobility > Peer Configuration e immettere le informazioni sul controller peer. Fate lo stesso per entrambi i WLC 9800.
Dalla GUI:


Dalla CLI:
# config t # wireless mobility group member mac-address <peer-mac-address> ip <peer-ip-address> group <group-name> [ data-link-encryption ]
Questo scenario è normale per le brownfield distribuzioni o durante la migrazione dei controller, in cui la rete viene suddivisa in un'area di punti di accesso (AP) controllata da un controller AireOS e un'altra da un 9800.
Si consiglia di distribuire gli access point tra i controller per area fisica o RF, in modo che i client eseguano il roaming solo tra i controller quando si spostano.
Evitare la salt and pepper distribuzione. Facoltativamente, questa topologia di mobilità può essere utilizzata anche per guest anchor i casi in cui 9800 funge da controller esterno e AireOS da controller di ancoraggio.

Se i controller 9800 sono in High Availabilityuso, verificare di aver configurato l'indirizzo MAC per la mobilità.
Dalla GUI:
Individuare Configuration > Wireless > Mobility > Global Configuration e prendere nota delleMobility Group Namee Mobility MAC Address.

Dalla CLI:
#show wireless mobility summary Mobility Summary Wireless Management VLAN: 2652
Wireless Management IP Address: 172.16.51.88
Wireless Management IPv6 Address:
Mobility Control Message DSCP Value: 48
Mobility Keepalive Interval/Count: 10/3
Mobility Group Name: default
Mobility Multicast Ipv4 address: 0.0.0.0
Mobility Multicast Ipv6 address: ::
Mobility MAC Address: 001e.e67e.75ff
Mobility Domain Identifier: 0x34ac
# show wireless management trustpoint
Trustpoint Name : Jay-9800_WLC_TP
Certificate Info : Available
Certificate Type : SSC
Certificate Hash : d7bde0898799dbfeffd4859108727d3372d3a63d
Private key Info : Available
FIPS suitability : Not Applicable
Dalla GUI:
Passa a CONTROLLER > Mobility Management > Mobility Groups > New.

Immettere i valori e fare clic su Apply.

Dalla CLI:
>config mobility group member add <9800 mac-address> <9800 WLC-IP> <group-name> encrypt enable
>config mobility group member hash <9800 WLC-IP> <9800 WLC-Hash>
>config mobility group member data-dtls <9800 mac-address> disable
Dalla GUI:
Accedere alla GUI di AireOS e selezionare CONTROLLER > Mobility Management > Mobility Groups e prendere nota dell'indirizzo MAC, dell'indirizzo IP e del nome del gruppo.

Dalla CLI:
>show mobility summary Mobility Protocol Port........................... 16666 Default Mobility Domain.......................... TEST Multicast Mode .................................. Disabled Mobility Domain ID for 802.11r................... 0x6ef9 Mobility Keepalive Interval...................... 10 Mobility Keepalive Count......................... 3 Mobility Group Members Configured................ 2 Mobility Control Message DSCP Value.............. 48 Controllers configured in the Mobility Group MAC Address IP Address Group Name Multicast IP Status 08:96:ad:ac:3b:8f 10.88.173.72 TEST 0.0.0.0 Up
Dalla GUI:
Passa a Configuration > Wireless > Mobility > Peer Configuration > Add.

Immettere le informazioni sul WLC di AireOS.

Dalla CLI:
# config t # wireless mobility group member mac-address <peer-mac-address> ip <ip-address> group <group-name>
Fare riferimento a questa sezione per verificare che la configurazione funzioni correttamente.
>show mobility summary Mobility Protocol Port........................... 16666 Default Mobility Domain.......................... TEST Multicast Mode .................................. Disabled Mobility Domain ID for 802.11r................... 0x6ef9 Mobility Keepalive Interval...................... 10 Mobility Keepalive Count......................... 3 Mobility Group Members Configured................ 2 Mobility Control Message DSCP Value.............. 48 Controllers configured in the Mobility Group MAC Address IP Address Group Name Multicast IP Status 00:1e:e6:7e:75:ff 172.16.51.88 default 0.0.0.0 Up 08:96:ad:ac:3b:8f 10.88.173.72 TEST 0.0.0.0 Up
#show wireless mobility summary Mobility Summary Wireless Management VLAN: 2652 Wireless Management IP Address: 172.16.51.88 Mobility Control Message DSCP Value: 48 Mobility Keepalive Interval/Count: 10/3 Mobility Group Name: mb-kcg Mobility Multicast Ipv4 address: 0.0.0.0 Mobility Multicast Ipv6 address: :: Mobility MAC Address: 001e.e67e.75ff Controllers configured in the Mobility Domain: IP Public Ip Group Name Multicast IPv4 Multicast IPv6 Status PMTU ----------------------------------------------------------------------------------------------------------------------------------------------------------------------- 172.16.51.88 N/A default 0.0.0.0 :: N/A N/A 10.88.173.72 10.88.173.72 TEST 0.0.0.0 :: Up 1385
Le informazioni contenute in questa sezione permettono di risolvere i problemi relativi alla configurazione.
Per risolvere i problemi relativi all'implementazione del tunnel per la mobilità, utilizzare i seguenti comandi per eseguire il debug del processo:
Passaggio 1. Abilitare i debug relativi alla mobilità.
debug mobility handoff enable debug mobility error enable debug mobility dtls error enable debug mobility dtls event enable debug mobility pmtu-discovery enable debug mobility config enable debug mobility directory enable
Passaggio 2. Riprodurre la configurazione e verificare l'output
Esempio di creazione riuscita di un tunnel per la mobilità su un WLC AirOS.
*capwapPingSocketTask: Feb 07 09:53:38.507: Client initiating connection on 172.16.0.5:16667 <-> 172.16.0.21:16667 *capwapPingSocketTask: Feb 07 09:53:38.507: Sending packet to 172.16.0.21:16667 *capwapPingSocketTask: Feb 07 09:53:38.508: Received DTLS packet from mobility peer 172.16.0.21 bytes: 48 *capwapPingSocketTask: Feb 07 09:53:38.508: mm_dtls2_process_data_rcv_msg:1207 rcvBufLen 48 clr_pkt_len 2048 peer ac100015 *capwapPingSocketTask: Feb 07 09:53:38.508: Record : type=22, epoch=0, seq=0 *capwapPingSocketTask: Feb 07 09:53:38.508: Hndshk : type=3, len=23 seq=0, frag_off=0, frag_len=23 *capwapPingSocketTask: Feb 07 09:53:38.508: Handshake in progress for link 172.16.0.5:16667 <-> 172.16.0.21:16667 *capwapPingSocketTask: Feb 07 09:53:38.508: Sending packet to 172.16.0.21:16667 *capwapPingSocketTask: Feb 07 09:53:38.508: DTLS consumed packet from mobility peer 172.16.0.21 bytes: 48 ! !<--output-omited--> ! *capwapPingSocketTask: Feb 07 09:53:38.511: dtls2_cert_verify_callback: Forcing Certificate validation as success *capwapPingSocketTask: Feb 07 09:53:38.511: Peer certificate verified. *capwapPingSocketTask: Feb 07 09:53:38.511: Handshake in progress for link 172.16.0.5:16667 <-> 172.16.0.21:16667 *capwapPingSocketTask: Feb 07 09:53:38.511: Nothing to send on link 172.16.0.5:16667 <-> 172.16.0.21:16667 *capwapPingSocketTask: Feb 07 09:53:38.511: DTLS consumed packet from mobility peer 172.16.0.21 bytes: 503 *capwapPingSocketTask: Feb 07 09:53:38.511: Received DTLS packet from mobility peer 172.16.0.21 bytes: 56 *capwapPingSocketTask: Feb 07 09:53:38.511: mm_dtls2_process_data_rcv_msg:1207 rcvBufLen 56 clr_pkt_len 2048 peer ac100015 *capwapPingSocketTask: Feb 07 09:53:38.511: Record : type=22, epoch=0, seq=6 *capwapPingSocketTask: Feb 07 09:53:38.511: Hndshk : type=13, len=6 seq=3, frag_off=0, frag_len=6 *capwapPingSocketTask: Feb 07 09:53:38.523: Handshake in progress for link 172.16.0.5:16667 <-> 172.16.0.21:16667 *capwapPingSocketTask: Feb 07 09:53:38.523: Sending packet to 172.16.0.21:16667 *capwapPingSocketTask: Feb 07 09:53:38.523: Sending packet to 172.16.0.21:16667 *capwapPingSocketTask: Feb 07 09:53:38.523: Sending packet to 172.16.0.21:16667 *capwapPingSocketTask: Feb 07 09:53:38.523: Sending packet to 172.16.0.21:16667 *capwapPingSocketTask: Feb 07 09:53:38.523: Sending packet to 172.16.0.21:16667 *capwapPingSocketTask: Feb 07 09:53:38.524: Sending packet to 172.16.0.21:16667 *capwapPingSocketTask: Feb 07 09:53:38.524: Sending packet to 172.16.0.21:16667 *capwapPingSocketTask: Feb 07 09:53:38.524: DTLS consumed packet from mobility peer 172.16.0.21 bytes: 56 *capwapPingSocketTask: Feb 07 09:53:38.527: Received DTLS packet from mobility peer 172.16.0.21 bytes: 91 *capwapPingSocketTask: Feb 07 09:53:38.527: mm_dtls2_process_data_rcv_msg:1207 rcvBufLen 91 clr_pkt_len 2048 peer ac100015 *capwapPingSocketTask: Feb 07 09:53:38.527: Record : type=20, epoch=0, seq=8 *capwapPingSocketTask: Feb 07 09:53:38.527: Connection established for link 172.16.0.5:16667 <-> 172.16.0.21:16667 *capwapPingSocketTask: Feb 07 09:53:38.527: ciperspec 1 *capwapPingSocketTask: Feb 07 09:53:38.527: Nothing to send on link 172.16.0.5:16667 <-> 172.16.0.21:16667 *capwapPingSocketTask: Feb 07 09:53:38.527: DTLS consumed packet from mobility peer 172.16.0.21 bytes: 91 *mmMobility: Feb 07 09:53:38.527: DTLS Action Result message received *mmMobility: Feb 07 09:53:38.527: Key plumb succeeded *mmMobility: Feb 07 09:53:38.527: mm_dtls2_callback: Connection established with 172.16.0.21:16667 *mmMobility: Feb 07 09:53:38.527: mm_dtls2_db_status_up:895 Connections status up for entry 172.16.0.21:16667 *mmMobility: Feb 07 09:53:38.527: mm_dtls2_callback: DTLS Connection established with 172.16.0.21:16667, Sending update msg to mobility HB
Per impostazione predefinita, i controller 9800 registrano continuamente le informazioni di processo senza bisogno di una procedura di debug speciale.
È sufficiente connettersi al controller e recuperare i log associati a qualsiasi componente wireless per la risoluzione dei problemi. I log possono richiedere più giorni. a seconda di quanto è occupato il controller.
Per semplificare l'analisi, tirare i log con un intervallo di tempo o per l'ultimo numero di minuti (l'ora predefinita è impostata su 10 minuti) ed è possibile filtrare in base agli indirizzi IP o MAC.
Passaggio 1. Controllare l'ora corrente del controller in modo da poter tenere traccia dei log nel tempo che precede il momento in cui si è verificato il problema.
# show clock
Passaggio 2. Raccogliere i log del controller nel caso in cui vi siano informazioni a livello di Cisco IOS che potrebbero essere correlate al problema.
# show logging
Passaggio 3. Raccogliere le tracce del livello di notifica sempre attive per un indirizzo specifico. Per filtrare è possibile utilizzare l'indirizzo IP o MAC del peer per la mobilità.
# show logging profile wireless filter ipv4 to-file bootflash:ra-AAAA.BBBB.CCCC.txt
Questo comando genera registri per gli ultimi 10 minuti. È possibile regolare questo tempo con il comando show logging profile wireless last 1 hour filter mac AAAA.BBBB.CCCC to-file bootflash:ra-AAAA.BBBB.CCCC.txt.
È possibile visualizzare il contenuto nella sessione o copiare il file in un server TFTP esterno.
# more bootflash:always-on-<FILENAME.txt>
or
# copy bootflash:always-on-<FILENAME.txt> tftp://a.b.c.d/path/always-on-<FILENAME.txt>
Se i log sempre attivi non forniscono informazioni sufficienti per identificare i problemi che hanno causato la configurazione del tunnel, è possibile abilitare i debug condizionali e acquisire Radio Active (RA) le tracce, in modo da ottenere un'attività di processo più dettagliata.
Passaggio 1. Verificare che non vi siano condizioni di debug già abilitate.
# show debugging IOSXE Conditional Debug Configs: Conditional Debug Global State: Stop IOSXE Packet Tracing Configs: Packet Infra debugs: Ip Address Port ------------------------------------------------------|----------
Se viene visualizzata una condizione non correlata all'indirizzo che si desidera monitorare, disattivarla.
Per rimuovere un indirizzo specifico:
# no debug platform condition feature wireless { mac <aaaa.bbbb.cccc> | ip <a.b.c.d> }
Per rimuovere tutte le condizioni (metodo consigliato):
# clear platform condition all
Passaggio 2. Aggiungere la condizione di debug per un indirizzo che si desidera monitorare.
# debug platform condition feature wireless ip <a.b.c.d>
Passaggio 3. Richiedere al WLC 9800 di avviare il monitoraggio dell'attività dell'indirizzo specificata.
# debug platform condition start
Passaggio 4. Riprodurre il problema o il comportamento che si desidera monitorare.
Passaggio 5. Interrompere i debug.
# debug platform condition stop
Passaggio 6. Raccogliere l'output dell'impegno di tipo indirizzo.
# show logging profile wireless filter ipv4 to-file bootflash:ra-AAAA.BBBB.CCCC.txt
Questo comando genera registri per gli ultimi 10 minuti. È possibile regolare questo tempo con il comando show logging profile wireless last 1 hour filter mac AAAA.BBBB.CCCC to-file bootflash:ra-AAAA.BBBB.CCCC.txt.
È possibile copiare il FILENAME.txt file su un server esterno o visualizzare l'output direttamente sullo schermo.
Copiare il file su un server esterno:
# copy bootflash:FILENAME.txt tftp://a.b.c.d/ra-FILENAME.txt
Visualizzare il contenuto:
# more bootflash:ra-FILENAME.txt
Passaggio 7. Se non è ancora possibile individuare la causa dell'errore, raccogliere il livello interno dei log. Non è necessario eseguire di nuovo il debug del client. Utilizzare i registri già archiviati internamente, ma raccoglierne una gamma più ampia).
# show logging profile wireless internal filter ipv4 to-file bootflash:raInternal-AAAA.BBBB.CCCC.txt
È possibile copiare il FILENAME.txt file su un server esterno o visualizzare l'output direttamente sullo schermo.
Copiare il file su un server esterno:
# copy bootflash:FILENAME.txt tftp://a.b.c.d/ra-FILENAME.txt
Visualizzare il contenuto:
# more bootflash:ra-FILENAME.txt
Passaggio 8. Rimuovere le condizioni di debug.
# clear platform condition all
Esempio di creazione riuscita di un tunnel per la mobilità su un WLC 9800.
2021/09/28 10:20:50.497612 {mobilityd_R0-0}{1}: [errmsg] [26516]: (info): %MM_NODE_LOG-6-MEMBER_ADDED: Adding Mobility member (IP: IP: 172.16.55.28: default)
2021/09/28 10:20:52.595483 {mobilityd_R0-0}{1}: [mm-client] [26516]: (debug): MAC: 0000.0000.0000 Sending keepalive_data of XID (0) to (ipv4: 172.16.55.28 )
2021/09/28 10:20:52.595610 {mobilityd_R0-0}{1}: [mm-pmtu] [26516]: (debug): Peer IP: 172.16.55.28 PMTU size is 1385 and calculated additional header length is 148
2021/09/28 10:20:52.595628 {mobilityd_R0-0}{1}: [mm-client] [26516]: (debug): MAC: 0000.0000.0000 Sending keepalive_ctrl_req of XID (80578) to (ipv4: 172.16.55.28 )
2021/09/28 10:20:52.595686 {mobilityd_R0-0}{1}: [mm-keepalive] [26516]: (note): Peer IP: 172.16.55.28 keepalive data packet misssed, total missed packet = 1
2021/09/28 10:20:52.595694 {mobilityd_R0-0}{1}: [mm-keepalive] [26516]: (note): Peer IP: 172.16.55.28 keepalive ctrl packet misssed, total missed packet = 1
2021/09/28 10:21:02.596500 {mobilityd_R0-0}{1}: [mm-client] [26516]: (debug): MAC: 0000.0000.0000 Sending keepalive_data of XID (0) to (ipv4: 172.16.55.28 )
2021/09/28 10:21:02.596598 {mobilityd_R0-0}{1}: [mm-keepalive] [26516]: (note): Peer IP: 172.16.55.28 keepalive data packet misssed, total missed packet = 2
2021/09/28 10:21:02.598898 {mobilityd_R0-0}{1}: [mm-client] [26516]: (debug): MAC: 001e.e68c.5dff Received keepalive_data, sub type: 0 of XID (0) from (ipv4: 172.16.55.28 )
2021/09/28 10:21:12.597912 {mobilityd_R0-0}{1}: [mm-client] [26516]: (debug): MAC: 0000.0000.0000 Sending keepalive_data of XID (0) to (ipv4: 172.16.55.28 )
2021/09/28 10:21:12.598009 {mobilityd_R0-0}{1}: [mm-keepalive] [26516]: (note): Peer IP: 172.16.55.28 Data link set state to UP (was DOWN)
2021/09/28 10:21:12.598361 {mobilityd_R0-0}{1}: [errmsg] [26516]: (note): %MM_NODE_LOG-5-KEEP_ALIVE: Mobility Data tunnel to peer IP: 172.16.55.28 changed state to UP
! !<--output-omitted--> !
2021/09/28 10:21:22.604098 {mobilityd_R0-0}{1}: [ewlc-infra-evq] [26516]: (debug): DTLS record type: 22, handshake
2021/09/28 10:21:22.604099 {mobilityd_R0-0}{1}: [ewlc-infra-evq] [26516]: (info): DTLS client hello
2021/09/28 10:21:22.611477 {mobilityd_R0-0}{1}: [ewlc-infra-evq] [26516]: (debug): DTLS record type: 22, handshake
2021/09/28 10:21:22.611555 {mobilityd_R0-0}{1}: [ewlc-infra-evq] [26516]: (debug): DTLS record type: 22, handshake
2021/09/28 10:21:22.611608 {mobilityd_R0-0}{1}: [ewlc-infra-evq] [26516]: (debug): DTLS record type: 22, handshake
2021/09/28 10:21:22.611679 {mobilityd_R0-0}{1}: [ewlc-infra-evq] [26516]: (debug): DTLS record type: 22, handshake
2021/09/28 10:21:22.611933 {mobilityd_R0-0}{1}: [mm-dtls] [26516]: (note): Peer IP: 172.16.55.28 Port: 16666, Local IP: 172.16.51.88 Port: 16666 DTLS_SSC_HASH_VERIFY_CB: SSC hash validation success
2021/09/28 10:21:22.612163 {mobilityd_R0-0}{1}: [ewlc-dtls-sessmgr] [26516]: (info): Remote Host: 172.16.55.28[16666] Completed cert verification, status:CERT_VALIDATE_SUCCESS
! !<--output-omitted--> !
2021/09/28 10:21:52.603200 {mobilityd_R0-0}{1}: [mm-keepalive] [26516]: (note): Peer IP: 172.16.55.28 Control link set state to UP (was DOWN)
2021/09/28 10:21:52.604109 {mobilityd_R0-0}{1}: [errmsg] [26516]: (note): %MM_NODE_LOG-5-KEEP_ALIVE: Mobility Control tunnel to peer IP: 172.16.55.28 changed state to UP
Nella maggior parte dei casi, è molto utile controllare i pacchetti scambiati tra i WLC. È particolarmente utile filtrare le clip con Access Control Lists (ACLs) per limitare il traffico acquisito.
Questo è un modello di configurazione per le acquisizioni incorporate nella CLI.
Passaggio 1. Creare l'ACL di filtro:
conf t
ip access-list extended <ACL_NAME>
10 permit ip host <WLC_IP_ADDR> host <PEER_WLC_IP_ADDR>
20 permit ip host <PEER_WLC_IP_ADDR>host <WLC_IP_ADDR>
end
Passaggio 2. Definire i parametri di acquisizione:
monitor capture <CAPTURE_NAME> access-list <ACL_NAME> buffer size 10 control-plane both interface <INTERFACE_NAME> both limit duration 300
Passaggio 3. Avviare l'acquisizione:
monitor capture <CAPTURE_NAME> start
Passaggio 4. Interrompere l'acquisizione:
monitor capture <CAPTURE_NAME> stop
Passaggio 5. Per raccogliere il file di acquisizione dei pacchetti, selezionare Risoluzione dei problemi > Packet Capture sulla GUI.
Gli esempi seguenti sono i tunnel formati tra 9800 WLC.
Abilitare Always-On-Logs e Embedded packet captures fornire ulteriori informazioni per la risoluzione dei problemi:
2021/09/28 09:54:22.490625 {mobilityd_R0-0}{1}: [mm-client] [26516]: (debug): MAC: 0000.0000.0000 Sending keepalive_ctrl_req of XID (80552) to (ipv4: 172.16.55.28 )
2021/09/28 09:54:22.490652 {mobilityd_R0-0}{1}: [mm-keepalive] [26516]: (note): Peer IP: 172.16.55.28 keepalive data packet misssed, total missed packet = 29
2021/09/28 09:54:22.490657 {mobilityd_R0-0}{1}: [mm-keepalive] [26516]: (note): Peer IP: 172.16.55.28 keepalive ctrl packet misssed, total missed packet = 10
2021/09/28 09:54:32.491952 {mobilityd_R0-0}{1}: [mm-client] [26516]: (debug): MAC: 0000.0000.0000 Sending keepalive_data of XID (0) to (ipv4: 172.16.55.28 )
2021/09/28 09:54:32.492127 {mobilityd_R0-0}{1}: [mm-keepalive] [26516]: (note): Peer IP: 172.16.55.28 keepalive data packet misssed, total missed packet = 30
Le acquisizioni dei pacchetti sono utili per confermare il comportamento.

Si noti che sia il debug sia il WLC mostrano che non è presente alcuna risposta ai ping dei dati o dei controlli. In uno scenario comune la connettività IP è consentita, ma le porte 1666 o 1667 non possono comunicare attraverso la rete.
In questo caso, è stata confermata la connettività per tutte le porte tra i WLC, ma si continua a notare la mancata corrispondenza dei pacchetti keepalive.
Abilitare Always-On-Logs e Embedded packet captures fornire ulteriori informazioni per la risoluzione dei problemi:
2021/09/28 11:34:22.927477 {mobilityd_R0-0}{1}: [mm-client] [26516]: (debug): MAC: 0000.0000.0000 Sending keepalive_data of XID (0) to (ipv4: 172.16.55.28 )
2021/09/28 11:34:22.928025 {mobilityd_R0-0}{1}: [mm-pmtu] [26516]: (debug): Peer IP: 172.16.55.28 PMTU size is 1385 and calculated additional header length is 148
2021/09/28 11:34:22.928043 {mobilityd_R0-0}{1}: [mm-client] [26516]: (debug): MAC: 0000.0000.0000 Sending keepalive_ctrl_req of XID (80704) to (ipv4: 172.16.55.28 )
2021/09/28 11:34:22.928077 {mobilityd_R0-0}{1}: [mm-keepalive] [26516]: (note): Peer IP: 172.16.55.28 keepalive data packet misssed, total missed packet = 8
2021/09/28 11:34:22.928083 {mobilityd_R0-0}{1}: [mm-keepalive] [26516]: (note): Peer IP: 172.16.55.28 keepalive ctrl packet misssed, total missed packet = 3
I registri interni sul peer 172.16.55.28 consentono di confermare la mancata corrispondenza della configurazione
2021/09/28 17:33:22.963 {mobilityd_R0-0}{1}: [mm-keepalive] [27081]: (ERR): Peer IP: 172.16.51.88 Failed to validate endpoint: Invalid argument
2021/09/28 17:33:22.963 {mobilityd_R0-0}{1}: [errmsg] [27081]: (ERR): %MM_NODE_LOG-3-PING_DROPPED: Drop data ping from IP: 172.16.51.88. Failed to validate endpoint
La mancata corrispondenza della configurazione comune include: nome di gruppo errato, indirizzo MAC Mobility non Data Link Encryption corrispondente.
Registro di gruppo non corrispondente:
2021/09/28 17:33:22.963 {mobilityd_R0-0}{1}: [errmsg] [27081]: (ERR): %MM_INFRA_LOG-3-MSG_PROC_FAILED_GROUP_NAME_HASH: Pkt group name hash: 82FE070E6E9A37A543CEBED96DB0388F Peer group name hash: 3018E2A00F10176849AC824E0190AC86 Failed to validate endpoint. reason: Group name hash mismatch.
Registro indirizzi MAC non corrispondenti:
2021/09/28 19:09:33.455 {mobilityd_R0-0}{1}: [errmsg] [27081]: (ERR): %MM_INFRA_LOG-3-MSG_PROC_FAILED_MAC_ADDR: Pkt MAC: 001e.e67e.75fa Peer MAC: 001e.e67e.75ff Failed to validate endpoint. reason: MAC address mismatch.
Questo tipo di problema è correlato agli stabilimenti del tunnel DTLS tra i WLC. È possibile che il percorso dei dati sia attivo ma il percorso di controllo rimane DOWNattivo.
Abilitare Always-On-Logs e Embedded packet captures fornire ulteriori informazioni per la risoluzione dei problemi:
2021/09/28 19:30:23.534 {mobilityd_R0-0}{1}: [mm-msg] [27081]: (ERR): Peer IP: 172.16.51.88 Port: 16666 DTLS_MSG: DTLS message process failed. Error: Invalid argument
2021/09/28 19:30:23.534 {mobilityd_R0-0}{1}: [errmsg] [27081]: (warn): %MM_NODE_LOG-4-DTLS_HANDSHAKE_FAIL: Mobility DTLS Ctrl handshake failed for 172.16.51.88 HB is down, need to re-initiate DTLS handshake
2021/09/28 19:30:23.534 {mobilityd_R0-0}{1}: [ewlc-capwapmsg-sess] [27081]: (ERR): Source IP:172.16.51.88[16666], DTLS message process failed. length:52
Utilizzare show wireless management trustpoint i show crypto pki trustpoints comandi e per verificare le informazioni sul certificato.
Se si dispone di controller nella coppia High Availability SSO, è importante essere informati. L'indirizzo MAC di mobilità non è configurato per impostazione predefinita e può causare l'interruzione del tunnel di mobilità in caso di failover.
Il riepilogo mostra mobilità wireless fornisce l'indirizzo MAC per la mobilità corrente in uso, ma non è necessariamente configurato. Verificare se per la configurazione è stato configurato l'indirizzo MAC per la mobilità con show run | i mobilità.
Se il mac per la mobilità non è configurato nella configurazione in esecuzione, cambia in seguito al failover sul WLC in standby e ciò causa il malfunzionamento dei tunnel per la mobilità.
La soluzione semplice consiste nell'accedere alla pagina Configurazione > Wireless > Mobility Web UI e selezionare Applica. In questo modo l'attuale MAC per PC portatili viene salvato nella configurazione. Il MAC rimane quindi lo stesso anche dopo il failover e i tunnel di mobilità vengono mantenuti.
Questo problema si verifica principalmente se si esegue la configurazione della mobilità tramite la riga di comando e si dimentica di configurare l'indirizzo MAC della mobilità. L'interfaccia utente Web salva automaticamente un indirizzo MAC per dispositivi mobili quando si applicano le impostazioni.
Configurazione della funzione WLAN Anchor Mobility su Catalyst 9800
| Revisione | Data di pubblicazione | Commenti |
|---|---|---|
5.0 |
04-Jun-2026
|
Titolo, introduzione, testo alternativo, titoli collaboratori e formattazione aggiornati. |
3.0 |
10-Nov-2022
|
Aggiunta di una nota sullo scenario HA SSO |
2.0 |
04-Oct-2022
|
Riparati allarmi CCW, mascheramento traduzione automatica, grammatica, struttura, punteggiatura. |
1.0 |
14-Sep-2021
|
Versione iniziale |