O conjunto de documentação deste produto faz o possível para usar uma linguagem imparcial. Para os fins deste conjunto de documentação, a imparcialidade é definida como uma linguagem que não implica em discriminação baseada em idade, deficiência, gênero, identidade racial, identidade étnica, orientação sexual, status socioeconômico e interseccionalidade. Pode haver exceções na documentação devido à linguagem codificada nas interfaces de usuário do software do produto, linguagem usada com base na documentação de RFP ou linguagem usada por um produto de terceiros referenciado. Saiba mais sobre como a Cisco está usando a linguagem inclusiva.
A Cisco traduziu este documento com a ajuda de tecnologias de tradução automática e humana para oferecer conteúdo de suporte aos seus usuários no seu próprio idioma, independentemente da localização. Observe que mesmo a melhor tradução automática não será tão precisa quanto as realizadas por um tradutor profissional. A Cisco Systems, Inc. não se responsabiliza pela precisão destas traduções e recomenda que o documento original em inglês (link fornecido) seja sempre consultado.
Este documento descreve o processo para identificar cenários diferentes para recarregamentos do Plano do Usuário (UP) com base nos sintomas para solucionar o problema.
RCM - Gerenciador de Configuração de Redundância
SSD - Mostrar detalhes de suporte
UPF/UP - Função do plano do usuário
VPP - Processamento de pacotes vetoriais
BFD - Detecção de encaminhamento bidirecional
Abordagem para identificar sintomas de cenários de recarga de UP:
Em uma configuração CUPS, cenários de recarregamento UP frequentemente encontram desafios, exigindo identificação eficaz de sintomas e Troubleshooting subsequente.
Para iniciar o processo, examine o tempo de atividade do sistema para identificar a hora exata da última reinicialização do UP. Essas informações facilitam uma análise focalizada dos logs do RCM correspondentes ao evento de recarregamento.
Use este comando para verificar o tempo de atividade do sistema da seguinte maneira:
******** show system uptime *******
Friday July 22 09:28:14 IST 2022
System uptime: 0D 0H 6M
Observação: verifique se os timestamps RCM e UP estão sincronizados com o mesmo fuso horário. Se houver uma discrepância, faça as correlações necessárias. Por exemplo, se a hora de ATIVAÇÃO estiver em IST e a hora de RCM estiver em UTC, observe que a hora de RCM está consistentemente 5:30 horas atrasada em relação à hora de ATIVAÇÃO.
Verifique se ocorreram falhas durante o tempo de recarregamento. Você pode usar este comando para verificar ocorrências de travamento:
******** show crash list *******
Sunday January 23 12:12:14 IST 2022
=== ==================== ======== ========== =============== =======================
# Time Process Card/CPU/ SW HW_SER_NUM
PID VERSION VPO / Crash Card
=== ==================== ======== ========== =============== =======================
1 2022-Jan-14+13:16:40 sessmgr 01/0/11287 21.25.5 NA
2 2022-Jan-19+20:51:01 sessmgr 01/0/16142 21.25.5 NA
3 2022-Jan-22+15:51:55 vpp 01/0/07307 21.25.5 NA
4 2022-Jan-22+15:52:08 sessmgr 01/0/27011 21.25.5 NA
5 2022-Jan-22+16:07:43 sessmgr 01/0/13528 21.25.5 NA
Nesta etapa, você precisa examinar se ocorreram travamentos, como travamentos vpp/sessmgr. Se um travamento de vpp for detectado, o UP será recarregado imediatamente devido ao travamento, solicitando ao RCM que inicie um switchover para outro UP.
Se houver uma sequência consistente de travamentos do sessmgr, ele pode potencialmente disparar um travamento de VPP, resultando em uma recarga do UP.
Sempre que você encontrar tais falhas, certifique-se de reunir os arquivos principais para vpp/sessmgr.
Observação: no caso de vpp, um minicore pode estar acessível em vez de um arquivo de núcleo completo.
Plano de ação: depois de obter o arquivo principal ou minicore, a próxima etapa é executar a depuração do arquivo principal para identificar a causa raiz do travamento.
Os erros encontrados em syslogs relacionados a falhas de monitoramento de BFD são explicados aqui.
Esses erros surgem quando há uma oscilação de BFD ou perda de pacotes entre RCM e UP, especialmente nos casos em que a ACI está envolvida na conexão entre eles.
Essencialmente, um temporizador é configurado para monitorar pacotes BFD. Se, por qualquer razão mencionada, esse temporizador expirar, ele acionará uma falha de monitoramento. Esse evento solicita que o RCM inicie um switchover.
Jan 22 15:51:55 <NODENAME> evlogd: [local-60sec55.823] [bfd 170500 error] [1/0/9345 <bfdlc:0> bfd_network.c:1798] [software internal system] <bfdctx:7> Session(1/-1260920720) DOWN control detection timer expired
Jan 22 15:51:55 <NODENAME> evlogd: [local-60sec55.856] [bfd 170500 error] [1/0/9345 <bfdlc:0> bfd_network.c:1798] [software internal system] <bfdctx:5> Session(2/1090521080) DOWN control detection timer expired
Jan 22 15:51:55 <NODENAME> evlogd: [local-60sec55.859] [srp 84220 error] [1/0/10026 <vpnmgr:7> pnmgr_rcm_bfd.c:704] [context: rcmctx, contextID: 7] [software internal system syslog] BFD down, closing TCP.
Jan 22 15:51:56 <NODENAME> evlogd: [local-60sec55.979] [srp 84220 error] [1/0/10026 <vpnmgr:7> pnmgr_rcm_bgp.c:428] [context: rcmctx, contextID: 7] [software internal system syslog] Cannot inform RCM about BGP monitor failure as TCP connection with RCM down.
Para resolver esse problema, é importante realizar um exame abrangente do sistema e identificar quaisquer problemas em potencial que possam ter causado o flap do BFD. Se um carimbo de data/hora problemático for identificado, será necessário coordenar com a ACI para investigar se houve falhas ou problemas em sua extremidade correspondentes a esse carimbo de data/hora.
Flaps de BGP ou falhas de monitoramento dentro do UP podem disparar um switchover iniciado pelo RCM. Esses erros específicos são caracterizados conforme descrito aqui.
Mar 21 09:10:37 <NODENAME> evlogd: [local-60sec37.482] [vpn 5572 info] [1/0/10038 <vpnmgr:7> pnmgr_rcm_bgp.c:392] [context: rcmctx, contextID: 7] [software internal system critical-info syslog] BGP monitor group 3 down.
Mar 21 09:10:37 <NODENAME> evlogd: [local-60sec37.482] [vpn 5572 info] [1/0/10038 <vpnmgr:7> pnmgr_rcm_bgp.c:392] [context: rcmctx, contextID: 7] [software internal system critical-info syslog] BGP monitor group 4 down.
Mar 21 09:10:37 <NODENAME> evlogd: [local-60sec37.482] [srp 84220 error] [1/0/10038 <vpnmgr:7> pnmgr_rcm_bgp.c:423] [context: rcmctx, contextID: 7] [software internal system syslog] Informed RCM about BGP monitor failure.
Possíveis fatores que contribuem para oscilações de BGP e métodos para identificá-los. As interceptações SNMP podem revelar erros que sinalizam ocorrências de oscilação de BGP:
Wed Jan 18 10:30:03 2023 Internal trap notification 1289 (BGPPeerSessionIPv6Down) vpn upf-in ipaddr abcd:ab:cd:abc::def
Wed Jan 18 10:30:09 2023 Internal trap notification 1288 (BGPPeerSessionIPv6Up) vpn upf-in ipaddr abcd:ab:cd:abc::def
Wed Jan 18 10:30:19 2023 Internal trap notification 1289 (BGPPeerSessionIPv6Down) vpn upf-in ipaddr abcd:ab:cd:abc::def
Wed Jan 18 10:30:03 2023 Internal trap notification 1289 (BGPPeerSessionIPv6Down) vpn upf-in ipaddr abcd:ab:cd:abc::def
Wed Jan 18 10:30:09 2023 Internal trap notification 1288 (BGPPeerSessionIPv6Up) vpn upf-in ipaddr abcd:ab:cd:abc::defInitiate the process by identifying the context associated with the error that indicates BGP flaps, utilizing the context ID. With the context established, you can precisely determine the particular service involved and retrieve the corresponding IP details.
Tanto nas configurações CUPS baseadas em RCM quanto nas configurações CUPS baseadas em ICSR, contextos individuais são criados dentro dos UPs. Por exemplo, em uma configuração RCM, o contexto "rcm" é estabelecido dentro do UP, enquanto uma configuração ICSR envolve a criação do contexto "srp". Aqui está um exemplo de configuração para CUPS baseado em RCM:
******** show rcm info *******
Thursday March 17 20:51:40 IST 2022
Redundancy Configuration Module:
-------------------------------------------------------------------------------
Context: rcm
Bind Address: <UPF IP binding with RCM controller>
Chassis State: Active
Session State: SockActive
Route-Modifier: 30
RCM Controller Address: <RCM controller IP>
RCM Controller Port: 9200
RCM Controller Connection State: Connected
Ready To Connect: Yes
Management IP Address: <UPF management IP>
Host ID: Active7
SSH IP Address: (Deactivated)
SSH IP Installation: Enabled
redundancy-configuration-module rcm
rcm controller-endpoint dest-ip-addr <Destination RCM controller IP> port 9200 upf-mgmt-ip-addr <UPF management IP> node-name <Nodename>
bind address <UPF IP binding with RCM controller>
monitor bfd peer X.X.X.X
monitor bgp failure reload active
monitor bgp context GnS5S8-U X.X.X.X group 1
monitor bgp context GnS5S8-U X.X.X.X group 1
monitor bgp context GnS5S8-U abcd:defc:c:f::XXXX group 2
monitor bgp context GnS5S8-U defg:abcg:c:f::XXXX group 2
monitor bgp context SGi Z.Z.Z.Z group 3
monitor bgp context SGi G.G.G.G group 3
monitor bgp context SGi XXXX:YYYY:c:f::aaaa group 4
monitor bgp context SGi XXXX:YYYY:c:f::bbbb group 4
monitor bgp context Li XXXX:YYYY:c:f::cccc group 5
monitor bgp context Li XXXX:YYYY:c:f::dddd group 5
monitor sx context GnS5S8-U bind-address XXXX:YYYY:c:f::eeee peer-address XXXX:YYYY:c:f::ffff
#exit
Sample config for ICSR based CUPs without RCM
******** show srp info *******
Sunday April 23 04:39:49 JST 2023
Service Redundancy Protocol:
-------------------------------------------------------------------------------
Context: SRP
Local Address: <UP IP>
Chassis State: Active
Chassis Mode: Backup
Chassis Priority: 10
Local Tiebreaker: FA-02-1B-E8-C1-7E
Route-Modifier: 3
Peer Remote Address: <UP IP>
Peer State: Standby
Peer Mode: Primary
Peer Priority: 1
Peer Tiebreaker: FA-02-1B-13-31-D1
Peer Route-Modifier: 6
Last Hello Message received: Sun Apr 23 04:39:47 2023 (2 seconds ago)
Peer Configuration Validation: Complete
Last Peer Configuration Error: None
Last Peer Configuration Event: Sun Apr 23 04:21:10 2023 (1119 seconds ago)
Last Validate Switchover Status: None
Connection State: Connected
service-redundancy-protocol
monitor bfd context SRP <bfd peer IP> chassis-to-chassis
monitor bfd context SRP <bfd peer IP> chassis-to-chassis
monitor bgp context SAEGW-U-1 <IP> group 1
monitor bgp context SAEGW-U-1 <IP> group 1
monitor bgp context SAEGW-U-1 <IP> group 2
monitor bgp context SAEGW-U-1 <IP> group 2
monitor bgp context SAEGW-U-1 <IP> group 3
monitor bgp context SAEGW-U-1 <IP> group 3
monitor bgp context SGI-1 <IP> group 4
monitor bgp context SGI-1 <IP> group 4
monitor system vpp delay-period 30
peer-ip-address <IP>
bind address <IP>
#exit
Em ambas as configurações, o monitoramento é implementado para BGP (semelhante ao monitoramento para BFD) dentro de seus respectivos contextos.
Cada instância de monitoramento recebe um número de grupo exclusivo e serviços distintos recebem números de grupos separados. Por exemplo, no contexto RCM, "SGi" está associado ao grupo número 3, "SGi IPv6" está vinculado ao grupo número 4 e "Li" está conectado ao grupo número 5.
Usando a configuração fornecida como uma base, a configuração RCM envolve o monitoramento dos links BGP especificados dentro deste contexto. A monitoração pode encontrar falhas se qualquer um desses enlaces BGP apresentar oscilação ou se houver dificuldades na detecção do enlace BGP. Em uma configuração ICSR, onde o RCM UP está ausente, o monitoramento de link BGP é conduzido pelo SRP. Esse mecanismo funciona de forma semelhante à explicação descrita neste ponto.
O objetivo principal é supervisionar os links. Ao encontrar esses erros de monitoramento, a etapa inicial é verificar os motivos por trás dos links que não estão sendo monitorados. As causas possíveis podem incluir oscilações de BGP, discrepâncias de configuração nos IPs inscritos para monitoramento versus os IPs especificados em seus respectivos contextos ou problemas de perda de pacotes.
Da mesma forma, como explicado para oscilações de BGP, a monitoração para oscilações de Sx entre CP e UP é implementada. Se um flap Sx for detectado, o RCM inicia um switchover de acordo.
Errors for Sx flap which can be seen from snmp traps
Thu Apr 28 15:22:55 2022 Internal trap notification 1382 (SxPathFailure) Context Name:gwctx, Service Name:sx-srvc-cp, Self-IP:X.X.X.X, Peer-IP:Y.Y.Y.Y, Old Recovery Timestamp:3854468847, New Recovery Timestamp
Registros do controlador RCM:
Monitoring failure for BFD
{"log":"2022/11/12 13:33:31.138 [ERROR] [red.go:2144] [rcm_ctrl.control.main] [handleUpfActiveToDownAction]: UPF 'X.X.X.X' monitor failure, reason UpfMonitor_BFD\n",
Monitoring failure for BGP
{"log":"2022/11/12 15:34:27.644 [ERROR] [red.go:2144] [rcm_ctrl.control.main] [handleUpfActiveToDownAction]: UPF 'X.X.X.X' monitor failure, reason UpfMonitor_BGP\n"
Monitoring failure for Sx
{"log":"2022/11/12 15:34:46.763 [ERROR] [red.go:2144] [rcm_ctrl.control.main] [handleUpfActiveToDownAction]: UPF 'X.X.X.X' monitor failure, reason UpfMonitor_SX\n"
Saídas do comando RCM:
rcm show-status
(to check RCM in Master or Backup state)
rcm show-statistics configmgr
(to check number of UPs connected to this configmgr and current stat of about which are the active UPs and standby UPs )
rcm show-statistics controller
(to check number of UPs connected to this controller and current stat of about which are the active UPs and standby UPs )
rcm show-statistics switchover
rcm show-statistics switchover-verbose
(to check which UP got switchovered to which UP and at what time and with what reason)
Exemplos da saída do comando:
root@Nodename:
[unknown] ram# ram show-status
message :
{"status”: “MASTER"}
[unknown] rcm# rcm show-statistics switchover
message :
{
"stats_history": [
{
"status": "Success",
"started": "Mar 21 03:40:37.480",
"ended": "Mar 21 03:40:41.659",
"switchoverreason": "BGP Failure",
"source_endpoint": "X.X.X.X",
"destination_endpoint": "Y.Y.Y.Y"
}
],
"num_switchover": 1
}
É importante obter os registros do controlador e analisá-los cuidadosamente em relação a qualquer cenário de switchover, conforme discutido anteriormente. Esta análise visa garantir que o processo de transição foi executado de forma transparente e sem quaisquer problemas.
{"log":"2022/05/10 00:30:48.553 [INFO] [events.go:87] [rcm_ctrl_ep.events.bfdmgr] eventsDbSetCallBack: endpoint X.X.X.X : STATE_UP -\u003e STATE_DOWN\n","stream":"stdout","time":"2022-05-10T00:30:48.553622344Z"}
--------------------Indication of active UP bfd went down
{"log":"2022/05/10 00:30:48.553 [DEBUG] [control.go:2920] [rcm_ctrl.control.main] [stateMachine]: Received Event Endpoint: groupId: 1 endpoint: X.X.X.X status: STATE_DOWN\n","stream":"stdout","time":"2022-05-10T00:30:48.553654666Z"}
{"log":"\n","stream":"stdout","time":"2022-05-10T00:30:48.553661415Z"}
{"log":"2022/05/10 00:30:48.553 [INFO] [red.go:2353] [rcm_ctrl.control.main] [upfHandlUpfAction]: StateChange: UPFAction_ActiveToDown\n","stream":"stdout","time":"2022-05-10T00:30:48.553670033Z"}
{"log":"2022/05/10 00:30:48.553 [ERROR] [red.go:2103] [rcm_ctrl.control.main] [handleUpfActiveToDownAction]: UPF 'X.X.X.X' monitor failure, reason UpfMonitor_BFD\n","stream":"stdout","time":"2022-05-10T00:30:48.55368269Z"}
{"log":"2022/11/12 13:33:27.759 [ERROR] [red.go:2144] [rcm_ctrl.control.main] [handleUpfActiveToDownAction]: UPF 'Z.Z.Z.Z' monitor failure, reason UpfMonitor_BGP\n",
----------- Indication of BFD/BGD timer expired and there is a monitoring failure
{"log":"2022/05/10 00:30:48.553 [WARN] [red.go:2256] [rcm_ctrl.control.main] [handleUpfActiveToDownAction]: upf X.X.X.X Switch over to Y.Y.Y.Y\n","stream":"stdout","time":"2022-05-10T00:30:48.553696821Z"}
---------- Indication of switchover initiated by RCM
{"log":"2022/05/10 00:32:03.555 [DEBUG] [control.go:3533] [rcm_ctrl.control.main] [snmpThread]: SNMP trap raised for : SwitchoverComplete\n","stream":"stdout","time":"2022-05-10T00:32:03.556753903Z"}
{"log":"2022/05/10 00:32:03.603 [DEBUG] [control.go:1885] [rcm_ctrl.control.main] [handleUpfStateMsg]: endpoint: Y.Y.Y.Y State: UpfMsgState_Active RouteModifier: 28 HostID 'Active3'\n","stream":"stdout","time":"2022-05-10T00:32:03.60379131Z"}
{"log":"2022/05/10 00:32:03.603 [DEBUG] [control.go:2048] [rcm_ctrl.control.main] [handleUpfStateMsg]: endpoint: Y.Y.Y.Y OldState: UPFState_Active NewState: UPFState_Active\n","stream":"stdout","time":"2022-05-10T00:32:03.603847124Z"}
---------- Indication of switchover completed and other UP became Active
{"log":"2022/05/10 00:32:03.646 [INFO] [control.go:1054] [rcm_ctrl.control.main] [handleUpfActiveAckMsg]: Subscriber data / Sx messages flowing towards UP 'Y.Y.Y.Y'\n","stream":"stdout","time":"2022-05-10T00:32:03.646883813Z"}
-------------- Traffic routed towards other Active UP
{"log":"2022/05/10 00:32:53.861 [INFO] [red.go:859] [rcm_ctrl.control.main] [handleUpfSetStandby]: Assigning PEND_STANDBY state to UPF 'X.X.X.X'. Notifies Configmgr, NSO and Redmgrs after receiving State Ack from UPF.\n","stream":"stdout","time":"2022-05-10T00:32:53.862051117Z"}
{"log":"2022/05/10 00:32:53.861 [INFO] [red.go:1681] [rcm_ctrl.control.main] [sendStateToUpf]:send state UpfMsgState_Standby to upf X.X.X.X \n","stream":"stdout","time":"2022-05-10T00:32:53.862059689Z"}
{"log":"2022/05/10 00:32:53.890 [INFO] [red.go:1176] [rcm_ctrl.control.main] [handleUpfNotifyMgrs]: Received UpfMsgState_Standby ACK from UPF 'X.X.X.X'. Notifying Configmgr and Redmgrs.\n","stream":"stdout","time":"2022-05-10T00:32:53.890712421Z"}
---------------------- Switchovered UP became Standby
Durante um switchover de um UP para outro UP iniciado pelo RCM, a configuração necessária é enviada pelo RCM. Para garantir que essa configuração seja aplicada com êxito, o RCM define um temporizador para concluir o processo.
Uma vez que a configuração é enviada e armazenada no caminho do UP, o UP executa a configuração dentro do intervalo de tempo especificado definido pelo RCM.
Quando o UP conclui a execução da configuração, ele envia um sinal ao RCM. Esse sinal é indicado por uma entrada do registro de eventos nos syslogs, confirmando a conclusão bem-sucedida do envio da configuração.
Nov 13 12:01:09 <NODENAME> evlogd: [local-60sec9.041] [cli 30000 debug] [1/0/10935 <cli:1010935> cliparse.c:571] [context: local, contextID: 1] [software internal system syslog] CLI command [user rcmadmin, mode [local]INVIGJ02GNR1D1UP12CO]: rcm-config-push-complete
Nov 13 12:01:09 <NODENAME> evlogd: [local-60sec9.041] [cli 30000 debug] [1/0/10935 <cli:1010935> cliparse.c:571] [context: local, contextID: 1] [software internal system syslog] CLI command [user rcmadmin, mode [local]INVIGJ02GNR1D1UP12CO]: rcm-config-push-complete end-of-config
rcm-config-push-complete end-of-config
Identificar CLIs com problemas no arquivo de configuração enviado, que pode ser determinado a partir dos logs do ConfigMgr do RCM.
Problemas relacionados ao SFTP podem ocorrer quando o RCM tenta enviar a configuração, mas enfrenta dificuldades para estabelecer uma conexão com o UP. Esses desafios podem ser originados de complicações de senha ou outros fatores que afetam as operações de SFTP.
A revisão dos logs do ConfigMgr permite o monitoramento do status do SFTP e a identificação de erros de configuração. Aqui está uma representação de exemplo de instâncias de erro típicas.
Logs SFTP em logs do ConfigMgr do RCM aparecem como:
{"log":"2022/11/12 23:53:09.066 rcm-configmgr [DEBUG] [sshclient.go:395] [rcm_grpc_ep.msg-process.Int] Initiate a sftp connection to host: X.X.X.X \n","stream":"stdout","time":"2022-11-12T23:53:09.067894173Z"}
{"log":"2022/11/12 23:53:09.066 rcm-configmgr [DEBUG] [sftpClient.go:26] [rcm_grpc_ep.grpc.Int] Conneting to host X.X.X.X for sftp with src path: /cfg/ConfigMgr/upfconfig10-103-108-154_22.cfg and dst path: /sftp/10-103-108-154_22.cfg \n","stream":"stdout","time":"2022-11-12T23:53:09.067903156Z"}
{"log":"2022/11/12 23:53:09.203 rcm-configmgr [DEBUG] [sftpClient.go:58] [rcm_grpc_ep.grpc.Int] Successfully opened the file%!(EXTRA string=/cfg/ConfigMgr/upfconfig10-103-108-154_22.cfg)\n","stream":"stdout","time":"2022-11-12T23:53:09.203698078Z"}
{"log":"2022/11/12 23:53:09.211 rcm-configmgr [DEBUG] [sftpClient.go:66] [rcm_grpc_ep.grpc.Int] Total bytes copied 405933: \n","stream":"stdout","time":"2022-11-12T23:53:09.212063509Z"}
Expiração da senha durante o SFTP observado nos syslogs UP:
2022-May-16+17:45:02.834 [cli 30005 info] [1/0/14263 <cli:1014263> _commands_cli.c:1474] [software internal system syslog] CLI session ended for Security Administrator admin on device /dev/pts/5
2022-May-16+17:45:02.834 [cli 30024 error] [1/0/14263 <cli:1014263> cli.c:1657] [software internal system syslog] Misc error: Password change required rc=0
2022-May-16+17:45:02.834 [cli 30087 info] [1/0/14263 <cli:1014263> cli.c:1352] [software internal system critical-info syslog] USER user 'admin' password has expired beyond grace period
2022-May-16+17:45:02.594 [cli 30004 info] [1/0/14263 <cli:1014263> cli_sess.c:164] [software internal system syslog] CLI session started for Security Administrator admin on device /dev/pts/5 from X.X.X.X
2022-May-16+17:45:02.537 [cli 30028 debug] [1/0/9816 <vpnmgr:1> luser_auth.c:1598] [context: local, contextID: 1] [software internal system syslog] Login attempt failure for user admin IP address X.X.X.X - Access type ssh/sftp
Se surgirem problemas de SFTP com senhas, considere a geração de uma nova senha ou a extensão do período de expiração da senha.
Se problemas de senha forem descartados, examine o número de sessões SFTP simultâneas, pois um número excessivo de sessões pode levar a interrupções do SFTP.
Revisão | Data de publicação | Comentários |
---|---|---|
1.0 |
14-Aug-2023 |
Versão inicial |