Saltar para o conteúdo principal
Português
Preços

A Lista de Verificação para Migrar de NAC Legado para NAC Nativo da Nuvem

Este guia de referência técnica e autoritário fornece uma lista de verificação estruturada em três fases para migrar do Network Access Control (NAC) legado para uma arquitetura nativa da nuvem. Ele equipa gestores de TI e arquitetos de rede com estratégias acionáveis para gerir a integração de identidades, a paridade de políticas e a conformidade sem interromper as operações do local.

📖 6 min de leitura📝 1,336 palavras🔧 2 exemplos práticos❓ 3 perguntas de prática📚 8 definições principais

Ouça este guia

Ver transcrição do podcast
The Checklist for Migrating from Legacy NAC to Cloud-Native NAC A Purple WiFi Intelligence Briefing — approximately 10 minutes --- INTRODUCTION AND CONTEXT — approximately 1 minute Welcome to the Purple WiFi Intelligence Briefing. I'm your host, and today we're tackling one of the most consequential infrastructure decisions facing network architects and IT directors right now: migrating away from legacy Network Access Control to a cloud-native NAC architecture. If you're running a hotel group, a retail estate, a stadium, or a public-sector campus, the odds are high that your current NAC deployment is either end-of-life, struggling to scale, or creating compliance headaches you simply cannot afford heading into the second half of this decade. GDPR enforcement is tightening. PCI DSS version 4 is fully in force. And your guest and staff WiFi estate is growing faster than your on-premises hardware can keep up with. So today I want to give you a practical, structured checklist — the kind of thing a senior solutions architect would walk you through before you sign any migration contract. We'll cover what to audit before you start, how to run a parallel deployment safely, where the real risks sit, and how to measure whether the migration has actually delivered value. Let's get into it. --- TECHNICAL DEEP-DIVE — approximately 5 minutes Let's start with the fundamentals. Legacy NAC — think Cisco ISE on ageing hardware, or a RADIUS server bolted onto a decade-old directory — was designed for a world where your network perimeter was well-defined, your devices were corporate-managed, and your guest traffic was an afterthought. That world is gone. Cloud-native NAC flips the model. Policy enforcement is decoupled from hardware. Your control plane lives in the cloud, your enforcement points are lightweight agents or API-integrated access points, and your identity store is federated — typically integrating with Azure Active Directory, Okta, or a purpose-built guest identity platform like Purple. So what does the checklist actually look like? I break it into three phases. Phase one is pre-migration assessment. Before you touch a single configuration, you need a complete inventory of your existing NAC infrastructure. That means every RADIUS server, every supplicant policy, every VLAN assignment, and every integration point — your SIEM, your ITSM ticketing system, your directory services. You need to know exactly what your legacy system is doing before you can replicate it in the cloud. Within that inventory, pay particular attention to three things. First, your IEEE 802.1X deployment. Document every EAP method in use — EAP-TLS, PEAP-MSCHAPv2, whatever you're running — because your cloud-native NAC needs to support the same methods or you'll have endpoint authentication failures on day one. Second, your guest WiFi flows. If you're running a captive portal today, understand exactly how it integrates with your NAC — is it inline, is it redirect-based, is it using a RADIUS CoA to change VLAN post-authentication? Purple's guest WiFi platform, for instance, handles this natively with cloud-based policy enforcement, but you need to map your current flow before you can migrate it. Third, your compliance posture. If you're in scope for PCI DSS, you need to document your current network segmentation — specifically how cardholder data environments are isolated from guest and staff networks. Cloud-native NAC can actually make this cleaner, but the migration itself is a change event that needs to be documented for your QSA. Phase two is the parallel run. This is where most migrations either succeed or fail. The right approach is to deploy your cloud-native NAC in shadow mode alongside your legacy system. You're not cutting over yet — you're validating policy parity. Every access decision your legacy system makes, you want to see the same decision from the cloud-native system. Run this for a minimum of two weeks, ideally four. Use a subset of real endpoints — a pilot group of staff devices, a single guest SSID at one venue — and compare authentication logs side by side. During the parallel run, there are three specific things to validate. One: latency. Cloud-native RADIUS authentication should be sub-100 milliseconds for the vast majority of requests. If you're seeing higher latency, check your RADIUS proxy configuration and your cloud region selection. Two: policy fidelity. Every role assignment, every VLAN tag, every access restriction — does the cloud system match the legacy system? Any divergence is a potential security gap or a user experience failure. Three: failover behaviour. What happens when the cloud control plane is temporarily unreachable? Your enforcement points need a defined fallback policy — typically either fail-open for guest traffic or fail-closed for staff and IoT. Document this explicitly. Phase three is full cutover and optimisation. Once you've validated policy parity, you cut over in a maintenance window. The key here is sequencing: cut over guest traffic first — it's the lowest risk and the easiest to roll back. Then staff SSIDs. Then wired 802.1X if applicable. Finally, IoT and operational technology networks, which often have the most brittle authentication configurations and need the most care. Post-cutover, your first thirty days are about optimisation. Cloud-native NAC gives you telemetry you simply didn't have before — per-device authentication rates, policy hit counts, anomalous behaviour flags. Use that data. Purple's WiFi analytics platform, for example, surfaces device dwell time, connection patterns, and authentication anomalies in a single dashboard, which is enormously useful for tuning your post-migration policies. One more technical point worth calling out: WPA3. If you're migrating your NAC, this is the right moment to also evaluate your encryption standard. WPA3-Enterprise with 192-bit mode is now the recommendation for high-security environments under the Wi-Fi Alliance's security certification programme. It's not mandatory for most guest WiFi deployments, but for staff and IoT networks handling sensitive data, the upgrade is worth the parallel effort. --- IMPLEMENTATION RECOMMENDATIONS AND PITFALLS — approximately 2 minutes Let me give you the three most common failure modes I see in NAC migrations, and how to avoid them. Failure mode one: underestimating the identity dependency. Cloud-native NAC is only as good as your identity infrastructure. If your Active Directory is poorly maintained — stale accounts, inconsistent group memberships, no MFA enforcement — you will replicate those problems in the cloud at scale and with greater visibility to attackers. Before you migrate your NAC, do an identity hygiene audit. Clean up stale accounts. Enforce MFA on all privileged identities. Federate your guest identity through a purpose-built platform rather than trying to bolt guests onto your corporate directory. Failure mode two: ignoring IoT. In hospitality and retail environments, IoT devices — door controllers, HVAC sensors, digital signage, POS terminals — often authenticate via MAC address bypass, which is a weak authentication method that legacy NAC has historically tolerated. Cloud-native NAC gives you the opportunity to enforce proper certificate-based authentication for IoT, but this requires a device certificate deployment project that many organisations underestimate. Budget for it separately. Failure mode three: treating the migration as a one-time project. Cloud-native NAC is not a set-and-forget deployment. The value is in the ongoing telemetry and policy automation. If you don't assign ownership of the platform post-migration — a named network security engineer or a managed service partner — you will drift back to the same compliance and visibility gaps you had with your legacy system within twelve months. --- RAPID-FIRE Q&A — approximately 1 minute A few questions I get asked regularly. "How long does a typical migration take?" For a single-site deployment, four to eight weeks from assessment to full cutover. For a multi-site estate — say, a hotel group with fifty properties — allow six to twelve months, running a rolling programme site by site. "Do we need to replace our access points?" Not necessarily. Most cloud-native NAC platforms support standard RADIUS authentication, so your existing 802.1X-capable APs will work. However, if your APs are more than five years old and don't support WPA3 or modern management APIs, the migration is a good catalyst to refresh the hardware simultaneously. "What about GDPR and guest data?" Cloud-native NAC, combined with a proper guest WiFi platform, actually improves your GDPR posture. You get centralised consent management, data residency controls, and automated retention policies — all of which are significantly harder to implement on legacy on-premises infrastructure. --- SUMMARY AND NEXT STEPS — approximately 1 minute To summarise: migrating from legacy NAC to cloud-native NAC is not just an infrastructure refresh — it's a strategic shift in how you manage network access, compliance, and guest intelligence at scale. The checklist is clear. Audit your existing infrastructure thoroughly before you start. Run a parallel deployment to validate policy parity. Cut over in a sequenced, low-risk order. And invest in the ongoing telemetry and policy automation that makes cloud-native NAC genuinely superior to what came before. If you're evaluating platforms, Purple's guest WiFi and analytics capabilities integrate natively with cloud-native NAC architectures, giving you a single pane of glass for guest identity, network policy, and venue analytics. It's worth a conversation with the team. Thanks for listening to the Purple WiFi Intelligence Briefing. Full technical documentation, architecture diagrams, and the written version of this checklist are available at purple.ai. Until next time.

header_image.png

Resumo Executivo

A migração do Network Access Control (NAC) legado para uma arquitetura nativa da nuvem já não é uma atualização discricionária; é um requisito crítico para manter a segurança, escalabilidade e conformidade em ambientes empresariais modernos. Os sistemas legados, frequentemente dependentes de hardware on-premises envelhecido e estruturas de diretório rígidas, têm dificuldade em suportar o crescimento explosivo de dispositivos IoT, a mobilidade dinâmica do pessoal e as exigências rigorosas do acesso de convidados moderno. Para diretores de operações de locais e gestores de TI nos setores da hotelaria, retalho e público, a transição para um NAC nativo da nuvem mitiga os riscos de falha de hardware e fragmentação de políticas, ao mesmo tempo que permite a automação impulsionada por API.

Este guia de referência técnica fornece uma lista de verificação abrangente para executar esta migração. Ele descreve uma abordagem estruturada em três fases: Avaliação Pré-Migração, Execução Paralela e Validação, e Transição Completa e Otimização. Ao dissociar a aplicação de políticas do hardware e federar os armazenamentos de identidade, as organizações podem alcançar o provisionamento zero-touch, a aplicação robusta do IEEE 802.1X e a integração perfeita com ferramentas do ecossistema. Crucialmente, este guia detalha como alavancar plataformas como a Purple para unificar a identidade de convidados e a política de rede, garantindo que a migração oferece um ROI operacional imediato e uma postura de segurança aprimorada.

Análise Técnica Detalhada

A mudança fundamental na transição de NAC legado para nativo da nuvem envolve a dissociação do plano de controlo do plano de dados. As arquiteturas legadas tipicamente dependem de servidores RADIUS monolíticos e dispositivos físicos implementados na extremidade ou agregados num centro de dados central. Este modelo cria gargalos, aumenta a latência para locais distribuídos e exige intervenção manual constante para manter a consistência das políticas.

O NAC nativo da nuvem abstrai o motor de políticas e o fornecedor de identidade (IdP) para um ambiente de nuvem escalável. A aplicação é empurrada para a extremidade, seja através de agentes de software leves ou integração direta de API com pontos de acesso e switches modernos. Esta arquitetura altera fundamentalmente a forma como a autenticação e a autorização são processadas.

Federação de Identidades e RADIUS

No centro da migração está a transição da gestão de identidades. O NAC legado frequentemente depende de ligações LDAP diretas a um Active Directory on-premises. As soluções nativas da nuvem favorecem integrações SAML ou OIDC com fornecedores de identidade na nuvem, como Azure AD ou Okta. Ao migrar, a infraestrutura RADIUS deve ser modernizada. Os serviços Cloud RADIUS gerem autenticações IEEE 802.1X (por exemplo, EAP-TLS, PEAP-MSCHAPv2) globalmente, reduzindo a latência ao encaminhar pedidos para o ponto de presença geográfico mais próximo.

É fundamental documentar cada método de Extensible Authentication Protocol (EAP) atualmente em uso. A falha em suportar os tipos de EAP existentes no novo ambiente resultará em falhas de autenticação imediatas para os endpoints. Além disso, para o acesso de convidados, a integração de uma plataforma robusta de Guest WiFi como a Purple permite a aplicação de políticas baseadas na nuvem, abstraindo a complexidade das atribuições de RADIUS Change of Authorisation (CoA) e VLAN do hardware local.

Segmentação de Rede e Conformidade

O NAC moderno não se trata apenas de acesso; trata-se de segmentação dinâmica. Em ambientes sujeitos a PCI DSS ou GDPR, a capacidade de atribuir dinamicamente VLANs ou aplicar políticas de microssegmentação com base na função do utilizador, postura do dispositivo e localização é primordial. O NAC nativo da nuvem avalia o contexto — quem, o quê, onde e quando — antes de conceder acesso.

Durante a migração, as atribuições de VLAN estáticas existentes devem ser mapeadas para políticas dinâmicas. Por exemplo, um terminal POS deve ser isolado da rede de convidados e da rede geral do pessoal. O motor de políticas da nuvem avalia o MAC address do dispositivo (ou, idealmente, um certificado de dispositivo) e instrui a infraestrutura de rede a colocá-lo na zona segura e compatível com PCI.

architecture_overview.png

Guia de Implementação

A execução da migração requer uma abordagem disciplinada e faseada para minimizar a interrupção em locais ativos e operações de negócio críticas.

Fase 1: Avaliação Pré-Migração

Antes de alterar quaisquer configurações, é obrigatório um inventário completo do ecossistema NAC existente. Isso inclui o mapeamento de todos os servidores RADIUS, configurações de suplicantes, esquemas de VLAN e integrações de terceiros (como plataformas SIEM ou ITSM).

  1. Auditar Fontes de Identidade: Identificar todos os diretórios e bases de dados utilizados para autenticação. Limpar contas obsoletas e aplicar MFA em identidades privilegiadas.
  2. Mapear Métodos EAP: Documentar todos os métodos IEEE 802.1X em uso em redes com e sem fios.
  3. Analisar Fluxos de Convidados: Documentar a integração atual do portal cativo. Avaliar como uma solução moderna de Guest WiFi pode otimizar este processo.
  4. Rever Dispositivos IoT: Identificar dispositivos que dependem de MAC Authentication Bypass (MAB) e planear a autenticação baseada em certificados sempre que possível.

Fase 2: Execução Paralela e Validação

A estratégia mais eficaz é implementar o NAC nativo da nuvem em modo sombra, em paralelo com o sistema legado. Isso permite a validação de políticas sem impactar o tráfego de produção.

  1. Implementar Cloud RADIUS: Configurar o NAC da nuvem para receber pedidos de autenticação em paralelo com o sistema legado.
  2. Validar Paridade de Políticas: Comparar as decisões de acesso (Função, VLAN, ACL) tomadas por ambos os sistemas. Qualquer divergência deve ser investigada e resolvida.
  3. Testar Latência: Garantir que os pedidos de autenticação na nuvem são concluídos dentro de limites aceitáveis (tipicamente abaixo de 100ms).
  4. Grupos Piloto: Migrar um pequenoum subconjunto de utilizadores (por exemplo, equipa de TI) ou um SSID específico não crítico para o novo sistema para validar a funcionalidade de ponta a ponta.

migration_phases_diagram.png

Fase 3: Transição Completa e Otimização

Uma vez confirmada a paridade, execute a transição durante uma janela de manutenção programada.

  1. Sequenciar a Transição: Comece pelas redes de menor risco. Migre primeiro as redes de convidados, seguidas pelas redes sem fios da equipa, 802.1X com fios e, finalmente, as redes IoT/OT.
  2. Monitorizar Telemetria: Utilize a visibilidade aprimorada da plataforma cloud para monitorizar as taxas de sucesso de autenticação e identificar comportamentos anómalos.
  3. Integrar Análise: Alimente a telemetria numa plataforma de Análise de WiFi para obter informações sobre o tempo de permanência do dispositivo, padrões de conexão e utilização espacial.
  4. Desativar Hardware Legado: Uma vez alcançada a estabilidade, apague e desative de forma segura os equipamentos NAC legados.

Melhores Práticas

Para garantir uma implementação resiliente e escalável, siga as seguintes melhores práticas da indústria:

  • Adote WPA3-Enterprise: Onde o hardware o suportar, torne obrigatório o WPA3-Enterprise com modo de 192 bits para redes altamente seguras (por exemplo, finanças, RH). Isto alinha-se com os mais recentes padrões de segurança da Wi-Fi Alliance. Para uma compreensão mais aprofundada dos padrões sem fios modernos, consulte o nosso guia sobre Frequências Wi-Fi: Um Guia para as Frequências Wi-Fi em 2026 .
  • Federar Identidade de Convidados: Não gira contas de convidados em diretórios corporativos. Utilize uma plataforma construída para o efeito, como a Purple, para gerir o onboarding de convidados, a gestão de consentimento e a residência de dados, garantindo a conformidade com o GDPR.
  • Implementar Princípios de Zero Trust: Afaste-se da confiança implícita baseada na localização da rede. Imponha uma avaliação contínua da postura para todos os endpoints antes de conceder acesso.
  • Automatizar o Onboarding de IoT: Transicione do MAB implementando o aprovisionamento automatizado de certificados para dispositivos sem interface.

Para mais informações sobre a evolução da segurança de rede, reveja O Futuro da Segurança Wi-Fi: NAC Impulsionado por IA e Deteção de Ameaças e a sua versão em espanhol, El Futuro de la Seguridad Wi-Fi: NAC Impulsado por IA y Detección de Amenazas .

Resolução de Problemas e Mitigação de Riscos

As migrações inerentemente comportam riscos. Antecipar modos de falha comuns é crítico para uma transição suave.

Modo de Falha: Problemas de Sincronização de Identidade Se o IdP cloud falhar ao sincronizar com os diretórios no local, a autenticação falhará. Mitigação: Implemente monitorização robusta nos agentes de sincronização de diretórios. Configure conectores de sincronização redundantes em diferentes locais físicos.

Modo de Falha: Alta Latência de Autenticação Encaminhar o tráfego RADIUS para uma região cloud distante pode causar timeouts no suplicante do endpoint. Mitigação: Selecione uma região cloud geograficamente próxima dos locais. Implemente proxies RADIUS locais ou equipamentos de filial resilientes para locais críticos como grandes lojas de Retalho ou instalações de Saúde .

Modo de Falha: Perda de Conectividade IoT Dispositivos IoT legados frequentemente têm configurações de rede codificadas ou não suportam métodos EAP modernos. Mitigação: Mantenha um SSID dedicado e isolado com fallback MAB especificamente para dispositivos IoT legados até que possam ser substituídos. Garanta que esta VLAN tem ACLs rigorosas que limitam o movimento lateral.

ROI e Impacto no Negócio

A transição para um NAC nativo da cloud oferece valor de negócio mensurável para além da segurança melhorada.

  • Eficiência Operacional: O aprovisionamento zero-touch e a gestão centralizada de políticas reduzem drasticamente as horas de engenharia necessárias para movimentos, adições e alterações (MACs).
  • Poupança de Hardware: A desativação de equipamentos no local elimina os custos associados de energia, refrigeração e contratos de manutenção.
  • Experiência de Convidado Aprimorada: A integração do NAC com uma plataforma moderna de Guest WiFi reduz o atrito no onboarding, levando a taxas de adesão mais altas e a uma recolha de dados mais rica para as equipas de marketing nos setores de Hotelaria e Transportes .
  • Redução de Risco: A geração de relatórios de conformidade automatizada e a segmentação dinâmica reduzem a probabilidade e o impacto potencial de uma violação de dados, diminuindo os prémios de seguro cibernético e protegendo a reputação da marca.

Definições Principais

Network Access Control (NAC)

A security solution that enforces policy on devices and users attempting to access a network.

Essential for ensuring only authorised, compliant devices connect to corporate or guest networks.

Cloud-Native Architecture

Designing applications specifically to leverage cloud computing models, typically using microservices and APIs.

Allows NAC to scale infinitely and decouple policy management from local hardware constraints.

RADIUS (Remote Authentication Dial-In User Service)

A networking protocol that provides centralised Authentication, Authorization, and Accounting (AAA) management.

The core protocol used by network switches and APs to communicate with the NAC policy engine.

IEEE 802.1X

An IEEE Standard for port-based Network Access Control, providing an authentication mechanism to devices wishing to attach to a LAN or WLAN.

The gold standard for secure, enterprise-grade network authentication for staff devices.

MAC Authentication Bypass (MAB)

A method of granting network access based on the device's MAC address rather than a username/password or certificate.

Commonly used for headless IoT devices (printers, cameras) that cannot support 802.1X, though it is inherently less secure.

Dynamic Segmentation

The ability to assign network access policies (like VLANs or ACLs) dynamically based on user identity, device type, or context.

Crucial for isolating different types of traffic (e.g., keeping POS terminals separate from guest WiFi).

Identity Provider (IdP)

A system entity that creates, maintains, and manages identity information for principals and provides authentication services.

Cloud-native NAC relies on modern IdPs (Azure AD, Okta) rather than legacy on-premise LDAP servers.

Change of Authorisation (CoA)

A RADIUS extension that allows the NAC server to dynamically change the access permissions of an active session.

Used extensively in guest WiFi portals to switch a user from a restricted pre-authentication VLAN to a full access VLAN after they accept terms.

Exemplos Práticos

A 500-room hotel is migrating to a cloud-native NAC. They currently use a legacy on-premises RADIUS server for staff 802.1X (PEAP) and a basic captive portal for guests. They have 200 IoT devices (smart TVs, door locks) authenticating via MAB. How should they sequence the migration to minimise guest disruption?

  1. Deploy the cloud NAC and integrate it with the existing IdP for staff. 2. Integrate Purple Guest WiFi with the cloud NAC for guest access. 3. Phase 1 Cutover: Migrate the Guest SSID to the new captive portal flow. This is low risk and provides immediate marketing ROI. 4. Phase 2 Cutover: Migrate staff 802.1X. Ensure the new RADIUS server certificate is trusted by staff endpoints to prevent warnings. 5. Phase 3 Cutover: Migrate IoT devices. Create a specific policy in the cloud NAC for MAB, ensuring these devices are placed in an isolated VLAN.
Comentário do Examinador: This sequenced approach isolates risk. Moving guests first provides a quick win and validates the cloud architecture. Leaving IoT until last allows time to meticulously map MAC addresses and ensure the new MAB policies are correctly configured before cutover.

A large retail chain with 150 stores is experiencing high latency (over 500ms) during the parallel run phase of their cloud NAC migration, causing POS terminals to timeout during authentication.

The latency is likely caused by the geographical distance between the stores and the cloud RADIUS region, or inefficient directory lookups. The solution is to: 1. Verify the cloud NAC tenant is hosted in the optimal geographic region. 2. Deploy a lightweight RADIUS proxy or survivable edge appliance in regional hubs to cache authentications and handle local EAP terminations. 3. Ensure the IdP integration is using fast, indexed lookups (e.g., native Azure AD integration rather than querying an on-prem LDAP server over a VPN).

Comentário do Examinador: Retail environments are highly sensitive to latency, especially for POS systems. The solution correctly identifies the need to move the authentication decision closer to the edge, either geographically or via local caching, which is a standard architectural pattern for distributed enterprises.

Perguntas de Prática

Q1. Your organisation is migrating from Cisco ISE to a cloud-native NAC. During the parallel run, you notice that a specific group of older barcode scanners in your warehouse are failing authentication on the cloud NAC, but succeeding on ISE. What is the most likely cause and how should you address it?

Dica: Consider how older devices handle encryption and protocol negotiation.

Ver resposta modelo

The most likely cause is a mismatch in supported EAP methods or cipher suites. The cloud NAC may have deprecated older, less secure protocols (like TLS 1.0 or specific weak ciphers) that the legacy ISE server still permitted. To address this, you must either update the firmware/supplicant on the barcode scanners to support modern protocols, or, if that is not possible, configure a specific, isolated policy in the cloud NAC to temporarily permit the older protocol strictly for that device group, mitigating the security risk via strict network segmentation.

Q2. A university campus wants to implement WPA3-Enterprise for its staff network alongside the NAC migration. However, 15% of staff laptops are running older wireless NICs that do not support WPA3. How should the network architect design the SSIDs?

Dica: Consider transition modes and the impact on security posture.

Ver resposta modelo

The architect should configure the staff SSID to use WPA3-Enterprise Transition Mode. This allows capable devices to connect using WPA3-Enterprise, while older devices fall back to WPA2-Enterprise. Alternatively, if strict security compliance is required for specific departments, a dedicated WPA3-only SSID can be created for compliant devices, leaving the legacy SSID active until the remaining hardware is refreshed.

Q3. During Phase 1 (Pre-Migration Assessment), you discover that the current guest WiFi relies heavily on RADIUS CoA to move users from a walled-garden VLAN to an internet-access VLAN. The new cloud APs do not reliably support CoA over the WAN. What is the recommended architectural change?

Dica: Consider how modern guest platforms handle policy enforcement without relying on complex local VLAN switching.

Ver resposta modelo

The recommended approach is to shift away from local VLAN switching and utilize a cloud-managed guest WiFi platform (like Purple). In this model, the AP places all guest traffic into a single guest VLAN. The captive portal and policy enforcement (bandwidth limiting, content filtering, session time) are handled either by the AP's built-in firewall or a cloud gateway, abstracting the need for RADIUS CoA entirely and simplifying the edge configuration.