Como desassociar sites do Cisco Nexus Dashboard Orchestrator
Contents
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:
- fvSiteAssociated: mostra a ID do site local.
- 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 selecione Delete Template conforme 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 conforme 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 conforme 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 do quadro de sítios:
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 conforme 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.
Histórico de revisões
| Revisão | Data de publicação | Comentários |
|---|---|---|
1.0 |
30-Nov-2023 |
Versão inicial |
FeedbackContate a Cisco
- Abrir um caso de suporte
- (É necessário um Contrato de Serviço da Cisco)