Contents

Introdução

Background

Abreviaturas:

Objetivo

Topologia

Desassociar Sites

Etapa 1. Desassociar Sites em Modelos

Etapa 2. Confirme se os objetos não são gerenciados pelo NDO em cada APIC

Etapa 3. Remover Modelos Vazios

Etapa 4. Remover Esquemas Vazios

Etapa 5. Desassociar Sites do Locatário

Etapa 6. Remover Espaço Vazio em NDO

Passo 7. Remover Aplicativo NDO no ND

Etapa 8. Remover o aplicativo NDO no ND

Introdução

Este documento descreve o procedimento para desassociar sites do Cisco Nexus Dashboard Orchestrator (NDO) e mantê-los gerenciados localmente em APICs.

Background

O objetivo é eliminar tanto ND quanto NDO.

Esse procedimento é útil quando os clientes estão buscando a desativação de um local e querem manter a configuração que foi inicialmente ampliada, como local, no local que continua.

Aviso: Este documento descreve as etapas para desassociar sites do Cisco Nexus Dashboard Orchestrator (NDO) e manter o gerenciamento local em APICs. Proceder com este procedimento sem a compreensão e cuidado adequados pode resultar em possíveis riscos ou complicações. É recomendável ter cautela e buscar orientação especializada antes de fazer qualquer alteração na configuração da rede.

Abreviaturas:

APIC: controlador de infraestrutura de política de aplicativos

ND: Painel do Nexus

NDO: Painel do Nexus

VRF: Roteamento e encaminhamento virtual

BD: Bridge Domain (Domínio da bridge)

EPG: Grupo EndPoint

AP: Perfil do aplicativo

Objetivo

A finalidade desse processo é desvincular totalmente objetos gerenciados do NDO e gerenciá-los individualmente de cada cluster APIC em cada malha.

Topologia

Para fins de demonstração, esta topologia é implantada:

Topologia proposta

Em NDO, a implantação é semelhante a esta:

- Nível de locatário: o locatário chamado Locatário1 é criado a partir do NDO e está associado a ambos os sites, chamados Site1 e Site2:

Validação da associação do locatário com 2 locais

Ele foi associado a 3 modelos:

Validação de associação de modelo para um espaço

- Nível do esquema: o esquema chamado Schema1 contém os 3 modelos:

Validação de modelos contidos em Stretched_Schema

- Nível do modelo:

- Stretched_Site1_Site2 é o modelo ampliado, onde o VRF ampliado, chamado VRF1, é definido e associado aos dois locais:

Validação de que o modelo Stretched_Site1_Site2 foi ampliado em 2 sites

- No modelo chamado Site1, associado somente ao Site1, o BD_Site1 local é definido e associado ao VRF1 ampliado; além disso, o AP_Site1 e o EPG_Site1 são definidos localmente neste modelo:

Validação de que o modelo Site1 é local para um único site

Validação de que o VRF para o BD local é o ampliado

- No modelo chamado Site2, associado apenas ao Site2, o BD_Site2 local é definido e associado ao VRF1 ampliado; além disso, o AP_Site2 e o EPG_Site2 são definidos localmente neste modelo:

Validação do site modelo 2 para confirmar se é local

Validação de que o VRF para o BD local é o ampliado

Para confirmar se os objetos foram implantados corretamente:

- No Site1:

O Locatário 1 é implantado e gerenciado pelo NDO, bem como VRF, AP, BD e EPG:

Validação de ampliação na GUI

Também é possível confirmar que todos os objetos do MIT têm a anotação definida como "orchestrator:msc", o que significa que são gerenciados a partir do NDO:

Usuário:

{

"totalCount": "1",

"imdata":

[

{

"fvTenant":

{

"attributes":

{

"annotation": "orchestrator:msc",

"descr": "",

"dn": "uni/tn-Tenant1",

"name": "Tenant1",

"nameAlias": "",

"ownerKey": "",

"ownerTag": "",

"userdom": ":all:"

}

}

}

]

}

VRF:

"fvCtx":

{

"attributes":

{

"annotation": "orchestrator:msc-shadow:no",

"bdEnforcedEnable": "no",

"descr": "",

"ipDataPlaneLearning": "enabled",

"knwMcastAct": "permit",

"name": "VRF1",

"nameAlias": "",

"ownerKey": "",

"ownerTag": "",

"pcEnfDir": "ingress",

"pcEnfPref": "enforced",

"userdom": ":all:",

"vrfIndex": "0"

},

"children":

[

{

"fvSiteAssociated":

{

"attributes":

{

"annotation": "",

"descr": "",

"name": "",

"nameAlias": "",

"ownerKey": "",

"ownerTag": "",

"siteId": "1",

"userdom": ":all:"

},

"children":

[

{

"fvRemoteId":

{

"attributes":

{

"annotation": "",

"descr": "",

"name": "2",

"nameAlias": "",

"ownerKey": "",

"ownerTag": "",

"remoteCtxPcTag": "32770",

"remotePcTag": "2686983",

"siteId": "2",

"userdom": ":all:"

}

}

}

]

}

},

]

}

Para o VRF, pode ser visto que, além da anotação "orchestrator:msc", algumas propriedades filho também são vistas.

Para compreender melhor esses objetos filhos, é importante observar que no NDO, além do nome do site, uma ID de site exclusiva é associada a cada site no NDO. Para consultar as IDs, em NDO, navegue até Operate > Sites :

Validação de SiteID por site em NDO

Depois que essas informações são explicadas, os objetos filhos são:

1. fvSiteAssociated: mostra a ID do site local.

2. fvRemoteID: As IDs de local remoto nas quais o objeto também é ampliado. Esse objeto também é útil para conhecer a conversão de objetos entre sites; no caso desse VRF, o segmento e o ClassID podem ser vistos, correspondendo ao Site 2. Para confirmar, uma comparação pode ser feita no Site 2:

Validação de Segment e ClassID de objetos remotos

Como pode ser visto, o Segment e o ClassID do Site 2 estão contidos no fvRemoteID dentro do objeto VRF no Site 1.

BD:

"fvBD": { "attributes": { "OptimizeWanBandwidth": "yes", "annotation": "orchestrator:msc-shadow:no", "name": "BD_Site1", ... }, "children": [ ... { "fvSiteAssociated": { "attributes": { "annotation": "", "descr": "", "name": "msc-local", "nameAlias": "", "ownerKey": "", "ownerTag": "", "siteId": "1", "userdom": ":all:" } } }, ] }

AP e EPG:

"fvAp": { "attributes": { "annotation": "orchestrator:msc-shadow:no", "descr": "", "name": "APP_Site1", "nameAlias": "", "ownerKey": "", "ownerTag": "", "prio": "unspecified", "userdom": ":all:" }, "children": [ { "fvAEPg": { "attributes": { "annotation": "orchestrator:msc-shadow:no", "descr": "", "exceptionTag": "", "floodOnEncap": "disabled", "fwdCtrl": "", "hasMcastSource": "no", "isAttrBasedEPg": "no", "matchT": "None", "name": "EPG_Site1", "nameAlias": "", "pcEnfPref": "unenforced", "prefGrMemb": "exclude", "prio": "unspecified", "shutdown": "no", "userdom": ":all:" }, "children": [ { "fvSiteAssociated": { "attributes": { "annotation": "", "descr": "", "name": "msc-local", "nameAlias": "", "ownerKey": "", "ownerTag": "", "siteId": "1", "userdom": ":all:" } } }, ] } } ] }

Nos objetos BD, AP e EPG, não há objetos filho fvRemoteId, pois esses objetos são significativos localmente e não são ampliados.

- No local 2:

O site 2 tem saídas bastante semelhantes, alterando apenas os objetos remotos correspondentes, portanto, essas informações são omitidas.

Desassociar Sites

Recomenda-se fazer um backup em NDO, bem como um instantâneo no APIC antes de realizar este procedimento, caso seja desejável revertê-lo posteriormente.

Etapa 1. Desassociar Sites em Modelos

Esta etapa precisa ser executada em cada modelo. Da mesma forma que a lógica por trás das dependências de círculo, é necessário começar primeiro em modelos que têm dependências em outros modelos e, finalmente, desassociar os modelos que não têm nenhuma referência cruzada.

Na topologia usada neste documento, o último modelo a ser desassociado deve ser Stretched_Site1_Site2, isto é, porque os modelos Site1 e Site2 têm uma referência a ele.

Navegue até o modelo dentro do esquema, clique em Actions e navegue até Disassociate Site:

Como desassociar o modelo

Na próxima janela, escolha no menu suspenso site por site, já que a desassociação é feita uma por uma (caso o modelo tenha mais de 2 sites):

Seleção de site de onde desassociar modelo

Em seguida, clique em Disassociate.

Uma mensagem com a confirmação é exibida quando termina:

Mensagem de confirmação

Observação: como mencionado anteriormente, repita este procedimento para todos os modelos no esquema.

Etapa 2. Confirme se os objetos não são gerenciados pelo NDO em cada APIC

Para confirmar se os objetos ainda estão presentes nos APICs, agora com propriedades diferentes:

No APIC (exemplo no site 1):

Validação da GUI para manter a configuração.

Os objetos não mostram mais o ícone NDO de nuvem ao lado dele, apenas o Espaço ainda é gerenciado pelo NDO.

No JSON:

"fvTenant": { "attributes": { "annotation": "orchestrator:msc", "descr": "", "dn": "uni/tn-Tenant1", "name": "Tenant1", "nameAlias": "", "ownerKey": "", "ownerTag": "", "userdom": ":all:" }, "children": [ { "fvCtx": { "attributes": { "annotation": "", "bdEnforcedEnable": "no", "descr": "", "ipDataPlaneLearning": "enabled", "knwMcastAct": "permit", "name": "VRF1", "nameAlias": "", "ownerKey": "", "ownerTag": "", "pcEnfDir": "ingress", "pcEnfPref": "enforced", "userdom": ":all:", "vrfIndex": "0" }, "fvBD": { "attributes": { "OptimizeWanBandwidth": "yes", "annotation": "", "arpFlood": "yes", "descr": "", "epClear": "no", "epMoveDetectMode": "", "hostBasedRouting": "no", "intersiteBumTrafficAllow": "yes", "intersiteL2Stretch": "yes", "ipLearning": "yes", "ipv6McastAllow": "no", "limitIpLearnToSubnets": "yes", "llAddr": "::", "mac": "00:22:BD:F8:19:FF", "mcastARPDrop": "yes", "mcastAllow": "no", "multiDstPktAct": "bd-flood", "name": "BD_Site1", "nameAlias": "", "ownerKey": "", "ownerTag": "", "type": "regular", "unicastRoute": "yes", "unkMacUcastAct": "proxy", "unkMcastAct": "flood", "userdom": ":all:", "v6unkMcastAct": "flood", "vmac": "not-applicable" } ... "fvAp": { "attributes": { "annotation": "", "descr": "", "name": "APP_Site1", "nameAlias": "", "ownerKey": "", "ownerTag": "", "prio": "unspecified", "userdom": ":all:" }, "children": [ { "fvAEPg": { "attributes": { "annotation": "", "descr": "", "exceptionTag": "", "floodOnEncap": "disabled", "fwdCtrl": "", "hasMcastSource": "no", "isAttrBasedEPg": "no", "matchT": "None", "name": "EPG_Site1", "nameAlias": "", "pcEnfPref": "unenforced", "prefGrMemb": "exclude", "prio": "unspecified", "shutdown": "no", "userdom": ":all:" }, } } ] } } ] }

Assim como visto no APIC, o único objeto que ainda tem a anotação é o objeto de espaço, mas os objetos BD, VRF, AP e EPG agora têm a propriedade de anotação vazia. Isso confirma que os objetos não são removidos do APIC, eles agora são gerenciados por cada APIC.

Etapa 3. Remover Modelos Vazios

Agora que todos os modelos estão vazios e não estão associados a nenhum site:

Validação de modelos em um estado não associado

Esses modelos podem ser removidos com segurança. Para removê-los, clique em Actions e selecioneDelete Template como mostrado na imagem:

Supressão do modelo

Quando o esquema estiver vazio, salve as alterações:

Salvar alterações no esquema vazio

Etapa 4. Remover Esquemas Vazios

É hora de remover o esquema vazio. Navegue até Configure > Tenant Templates como mostrado na imagem:

Etapas para mover para o menu de espaço

E clique nos 3 pontos ao lado do esquema, e clique em Delete como mostrado na imagem:

Excluir esquema vazio associado ao modelo

Etapa 5. Desassociar Sites do Locatário

Quando não houver mais esquemas, o espaço deverá mostrar que não está mais associado a nenhum modelo. Para confirmar, navegue até Operate > Tenants:

Desassociar sites do Locatário

Confirmando se o Espaço não tem modelos associados

Como pode ser visto, o número de modelos associados ao Locatário1 é 0. Clique nos 3 pontos e selecione Editar:

Editar propriedades do locatário para remover sites

Agora, é necessário desmarcar os sites. Clique em Unselect items na parte superior da tabela de sites:

Desmarcar Sites associados ao locatário

Certifique-se de que a opção para excluir o espaço esteja desmarcada antes de confirmar:

Confirmar a operação sem a verificação

Quando ambos os sites estiverem desmarcados, salve as alterações. Depois que isso for feito, confirme se o Espaço em cada APIC permanece:

Validação da IGUI de que o espaço ainda está configurado, mas não gerenciado do NDO

Como esperado, agora a anotação está vazia:

"fvTenant": { "attributes": { "annotation": "", "descr": "", "dn": "uni/tn-Tenant1", "name": "Tenant1", "nameAlias": "", "ownerKey": "", "ownerTag": "", "userdom": ":all:" } }

Etapa 6. Remover Espaço Vazio em NDO

É hora de remover o Espaço. Para fazer isso, navegue até Operate > Tenants , clique nos 3 pontos e clique em Delete conforme mostrado na imagem:

Excluir espaço vazio

Confirme e verifique se o Objeto de Espaço permanece nos APICs.

Passo 7. Remover Aplicativo NDO no ND

Para remover NDO, o aplicativo precisa ser desabilitado primeiro.

no ND, navegue até Admin Console > Services. O aplicativo NDO é exibido aqui. Clique nos 3 pontos e selecione Disable:

Desabilitar aplicativo NDO

Pode levar alguns minutos para ser completamente desativado.

Em seguida, clique nos 3 pontos novamente e, desta vez, clique na opção  Delete .

Etapa 8. Remover o aplicativo NDO no ND

Finalmente, no ND, remova os Sites. Para poder remover os sites, eles não devem estar consumindo nenhum serviço, portanto, se qualquer outro aplicativo estiver instalado, ele também precisará ser removido:

Validação de que os sites não usam o serviço NDO

Para removê-lo, clique nos 3 pontos e escolha Remove Site como mostrado na imagem:

Remover locais no ND

Depois que os locais forem completamente removidos, cada malha será independente agora e o ND também poderá ser desativado.

Observação: quando os sites forem independentes, o L3out para entre sites no locatário inferior ainda estará presente. Ele pode ser removido manualmente, certifique-se de que seja apenas para conectividade entre sites.