Este documento descreve os cenários de configuração de mobilidade que cobrem as topologias entre as controladoras Wireless LAN (WLCs) Catalyst 9800 e as WLCs AireOS.
A Cisco recomenda o conhecimento destes tópicos:
Inter Release Controller Mobility (IRCM) imagens 8.5 especiaisAs informações neste documento foram criadas a partir de dispositivos em um ambiente de laboratório específico. Todos os dispositivos utilizados neste documento foram iniciados com uma configuração (padrão) inicial. Se a rede estiver ativa, certifique-se de que você entenda o impacto potencial de qualquer comando.

O nome do grupo de mobilidade no 9800 é o padrão.
Este exemplo básico descreve como configurar a mobilidade em dois controladores 9800. Geralmente, é usado para acesso de convidado (âncora) ou para permitir que os clientes naveguem pelos controladores e preservem a identidade do cliente.
Quando você configura a mobilidade no C9800, a primeira coisa a escolher é o nome do grupo de mobilidade. O nome do grupo de mobilidade pré-preenchido é um padrão, mas você pode personalizá-lo para um valor desejado.
Você deve configurar o mesmo nome de grupo de mobilidade entre os controladores quando um roam rápido da camada 2 como Fast Transition (FT) ou Cisco Centralized Key Management (CCKM) está em uso.
Por padrão, o endereço MAC Ethernet base do chassi conforme visto na show version é refletido na GUI para o Endereço MAC de mobilidade. Na CLI, por padrão, o mac de mobilidade é 0000.0000.000 conforme visto na show run all | inc mobility mac-address.
Nos casos em que os 9800s estão emparelhados para High Availability (HA) Stateful Switchover (SSO):
Se a configuração for deixada como padrão e o endereço MAC do chassi for usado para formar o túnel de mobilidade, o chassi Ativo e o túnel de mobilidade falharão quando ocorrer failover. Portanto, é obrigatório que um endereço MAC de mobilidade seja configurado para o par HA C9800.
Passo 1: Na GUI, navegue até Configuration > Wireless > Mobility > Global Configuration.

Através do CLI:
# config t # wireless mobility mac-address <AAAA.BBBB.CCCC>
# wireless mobility group name <mobility-group-name>
Para ambas as 9800 WLCs, navegue Configuration > Wireless > Mobility > Global Configuration e anote seuMobility Group Namee Mobility MAC Address.
Através do 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
Navegue até Configuration > Wireless > Mobility > Peer Configuration e insira as informações do controlador par. Faça o mesmo para as duas 9800 WLCs.
Através da GUI:


Através do CLI:
# config t # wireless mobility group member mac-address <peer-mac-address> ip <peer-ip-address> group <group-name> [ data-link-encryption ]
Esse cenário é normal para brownfield implantações ou durante a migração do controlador, em que você divide a rede em uma área de access points (APs) controlados por um controlador AireOS e outro por um 9800.
É aconselhável que os APs sejam distribuídos entre os controladores por áreas físicas ou de RF, para que os clientes só façam roaming entre os controladores quando eles se moverem.
Evite a salt and pepper implantação. Opcionalmente, essa topologia de mobilidade também pode ser usada para guest anchor onde 9800 atua como estrangeiro e um AireOS como controlador âncora.

Se os controladores 9800 estiverem em High Availabilityoperação, verifique se você configurou o endereço MAC de mobilidade.
Através da GUI:
Navegue até Configuration > Wireless > Mobility > Global Configuration e anote seuMobility Group Namee Mobility MAC Address.

Através do 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
Através da GUI:
Navegue até CONTROLLER > Mobility Management > Mobility Groups > New.

Insira os valores e clique em Apply.

Através do 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
Através da GUI:
Inicie sessão na GUI do AireOS e navegue até CONTROLLER > Mobility Management > Mobility Groups o endereço MAC, o endereço IP e o nome do grupo e anote-os.

Através do 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
Através da GUI:
Navegue até Configuration > Wireless > Mobility > Peer Configuration > Add.

Insira as informações do AireOS WLC.

Através do CLI:
# config t # wireless mobility group member mac-address <peer-mac-address> ip <ip-address> group <group-name>
Use esta seção para confirmar se a sua configuração funciona corretamente.
>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
Esta seção fornece informações usadas para solucionar problemas da sua configuração.
Para solucionar problemas de implementação do túnel de mobilidade, use estes comandos para depurar o processo:
Etapa 1. Ative as depurações de mobilidade.
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
Etapa 2. Reproduzir a configuração e verificar a saída
Exemplo de uma criação de túnel de mobilidade bem-sucedida em uma 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
Por padrão, os controladores 9800 registram continuamente as informações do processo sem a necessidade de qualquer procedimento especial de depuração.
Basta conectar-se ao controlador e recuperar os logs associados a qualquer componente sem fio para fins de solução de problemas. Os logs podem durar dias; isso depende do quão ocupado o controlador está.
Para simplificar a análise, extraia os registros com um intervalo de tempo ou para o último número de minutos (o tempo padrão é definido como 10 minutos) e você pode filtrar por endereços IP ou MAC.
Etapa 1. Verifique a hora atual na controladora para que você possa rastrear os registros no tempo de volta até quando o problema ocorreu.
# show clock
Etapa 2. Colete os logs da controladora caso haja alguma informação no Cisco IOS que possa estar relacionada ao problema.
# show logging
Etapa 3. Colete os rastreamentos de nível de aviso sempre ativo para um endereço específico. Você pode usar o peer de mobilidade IP ou MAC para filtrar.
# show logging profile wireless filter ipv4 to-file bootflash:ra-AAAA.BBBB.CCCC.txt
Esse comando gera logs para os últimos 10 minutos. É possível ajustar esse tempo com o comando show logging profile wireless last 1 hour filter mac AAAA.BBBB.CCCC to-file bootflash:ra-AAAA.BBBB.CCCC.txt.
Você pode exibir o conteúdo na sessão ou copiar o arquivo para um servidor TFTP externo.
# more bootflash:always-on-<FILENAME.txt>
or
# copy bootflash:always-on-<FILENAME.txt> tftp://a.b.c.d/path/always-on-<FILENAME.txt>
Se os logs sempre ativos não fornecerem informações suficientes para saber quais problemas acionados durante a configuração do túnel, você poderá ativar depurações condicionais e capturar Radio Active (RA) rastreamentos, o que fornecerá uma atividade de processo mais detalhada.
Etapa 1. Verificar se não há condições de depuração já habilitadas.
# show debugging IOSXE Conditional Debug Configs: Conditional Debug Global State: Stop IOSXE Packet Tracing Configs: Packet Infra debugs: Ip Address Port ------------------------------------------------------|----------
Se você vir qualquer condição que não esteja relacionada ao endereço que deseja monitorar, desative-a.
Para remover um endereço específico:
# no debug platform condition feature wireless { mac <aaaa.bbbb.cccc> | ip <a.b.c.d> }
Para remover todas as condições (maneira recomendada):
# clear platform condition all
Etapa 2. Adicione a condição de depuração para um endereço que você deseja monitorar.
# debug platform condition feature wireless ip <a.b.c.d>
Etapa 3. Faça com que a WLC 9800 inicie o monitoramento da atividade do endereço especificado.
# debug platform condition start
Etapa 4. Reproduza o problema ou o comportamento que você deseja monitorar.
Etapa 5. Pare as depurações.
# debug platform condition stop
Etapa 6. Colete a saída da atividade de endereço.
# show logging profile wireless filter ipv4 to-file bootflash:ra-AAAA.BBBB.CCCC.txt
Esse comando gera logs para os últimos 10 minutos. É possível ajustar esse tempo com o comando show logging profile wireless last 1 hour filter mac AAAA.BBB.CCCC to-file bootflash:ra-AAAA.BBBB.CCCC.txt.
Você pode copiar o FILENAME.txt para um servidor externo ou exibir a saída diretamente na tela.
Copie o arquivo para um servidor externo:
# copy bootflash:FILENAME.txt tftp://a.b.c.d/ra-FILENAME.txt
Mostre o conteúdo:
# more bootflash:ra-FILENAME.txt
Etapa 7. Se você ainda não conseguir encontrar o motivo de uma falha, colete o nível interno de logs. (Você não precisa depurar o cliente novamente. Use os logs que já foram armazenados internamente, mas colete uma faixa maior deles).
# show logging profile wireless internal filter ipv4 to-file bootflash:raInternal-AAAA.BBBB.CCCC.txt
Você pode copiar o FILENAME.txt para um servidor externo ou exibir a saída diretamente na tela.
Copie o arquivo para um servidor externo:
# copy bootflash:FILENAME.txt tftp://a.b.c.d/ra-FILENAME.txt
Mostre o conteúdo:
# more bootflash:ra-FILENAME.txt
Etapa 8. Remova as condições de depuração.
# clear platform condition all
Exemplo de criação bem-sucedida de túnel de mobilidade em uma 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
Na maioria das vezes, é muito útil verificar pacotes trocados entre WLCs. É especialmente útil filtrar capturas com o Access Control Lists (ACLs) a fim de limitar o tráfego capturado.
Este é um modelo de configuração para capturas incorporadas no CLI.
Etapa 1. Criar a ACL de 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
Etapa 2. Definir os parâmetros de captura:
monitor capture <CAPTURE_NAME> access-list <ACL_NAME> buffer size 10 control-plane both interface <INTERFACE_NAME> both limit duration 300
Etapa 3. Iniciar a captura:
monitor capture <CAPTURE_NAME> start
Etapa 4. Interrompa a captura:
monitor capture <CAPTURE_NAME> stop
Etapa 5. Navegue até Troubleshooting > Packet Capture na GUI para coletar o arquivo de captura de pacote.
Os próximos exemplos consistem em túneis formados entre 9800 WLCs.
Habilitar Always-On-Logs e Embedded packet captures fornecer informações adicionais para solução de problemas:
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
As capturas de pacotes são úteis para confirmar o comportamento.

Observe que a depuração e a WLC mostram que não há resposta aos pings de Controle ou Dados. Um cenário comum mostra que a conectividade IP é permitida, mas as portas 16666 ou 16667 não têm permissão para se comunicar pela rede.
Nesse caso, você confirmou a conectividade para todas as portas entre as WLCs, mas continua a notar que os keepalives não foram acessados.
Habilitar Always-On-Logs e Embedded packet captures fornecer informações adicionais para solução de problemas:
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
Os logs internos no par 172.16.55.28 ajudam a confirmar a incompatibilidade de configuração
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
A configuração incompatível comum inclui: nome de grupo incorreto, incompatibilidade no Data Link Encryption e endereço MAC de Mobilidade incorreto.
Log de incompatibilidade de grupo:
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.
Log de incompatibilidade de endereços MAC:
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.
Esse tipo de problema está relacionado aos estabelecimentos de túnel DTLS entre WLCs. Pode ser que o caminho de dados esteja ATIVADO, mas o caminho de controle permaneça DOWN.
Habilitar Always-On-Logs e Embedded packet captures fornecer informações adicionais para solução de problemas:
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
Use show wireless management trustpoint os show crypto pki trustpoints comandos e para verificar as informações do certificado.
Se você tiver controladores no par SSO de alta disponibilidade, há um problema importante a ser observado. O endereço MAC de mobilidade não é configurado por padrão e pode fazer com que o túnel de mobilidade fique inativo se ocorrer um failover.
O show wireless mobility summary fornece o MAC de mobilidade atual em uso, mas não é necessariamente configurado. Verifique se a configuração tem o MAC de mobilidade configurado com show run | i mobilidade.
Se o mac de mobilidade não estiver configurado na configuração de execução, ele será alterado no failover para o WLC em standby e isso causará a falha dos túneis de mobilidade.
A solução simples é navegar até a página Configuration > Wireless > Mobility da interface do usuário da Web e selecionar apply. Isso salva o MAC de mobilidade atual na configuração. O MAC então permanece o mesmo após o failover e os túneis de mobilidade são preservados.
Esse problema ocorre principalmente se você fizer a configuração de mobilidade por meio da linha de comando e esquecer de configurar o endereço MAC de mobilidade. A interface de usuário da Web salva automaticamente um endereço MAC de mobilidade quando você aplica as configurações.
Configurar o recurso de mobilidade de âncora de WLAN no Catalyst 9800
| Revisão | Data de publicação | Comentários |
|---|---|---|
5.0 |
04-Jun-2026
|
Título atualizado, Introdução, Texto alternativo, Títulos de contribuidor e Formatação. |
3.0 |
10-Nov-2022
|
Adicionada uma observação sobre o cenário de HA SSO |
2.0 |
04-Oct-2022
|
Alertas do CCW reparados, mascaramento de tradução automática, gramática, estrutura, pontuação. |
1.0 |
14-Sep-2021
|
Versão inicial |