소개
이 문서에서는 Cisco Nexus NDO(Dashboard Orchestrator)에서 사이트의 연결을 해제하고 APIC에서 로컬로 관리하는 절차를 설명합니다.
배경
목표는 ND와 NDO를 모두 제거하는 것입니다.
이 절차는 고객이 사이트의 서비스 해제를 추구하면서 처음에 확장되었던 컨피그레이션을 로컬로 계속 진행되는 사이트에 유지하려는 경우에 유용합니다.
경고: 이 문서에서는 Cisco Nexus NDO(Dashboard Orchestrator)에서 사이트를 연결 해제하고 APIC에서 로컬 관리를 유지하는 단계를 간략하게 설명합니다. 적절한 이해와 주의 없이 이 절차를 진행하는 것은 잠재적인 위험이나 합병증을 초래할 수 있다. 네트워크 컨피그레이션을 변경하기 전에 주의하고 전문가의 지도를 받는 것이 좋습니다.
약어:
APIC: 애플리케이션 정책 인프라 컨트롤러
ND: Nexus 대시보드
NDO: Nexus 대시보드
VRF: 가상 라우팅 및 포워딩
BD: 브리지 도메인
EPG: 엔드포인트 그룹
AP: 애플리케이션 프로파일
목표
이 프로세스의 목적은 NDO에서 관리되는 객체의 링크를 완전히 해제하고 모든 패브릭의 각 APIC 클러스터에서 개별적으로 관리하는 것입니다.
토폴로지
데모용으로 이 토폴로지는 다음과 같이 구축됩니다.
토폴로지 제안
NDO에서 구축은 다음과 같습니다.
- 테넌트 레벨: Tenant1이라는 테넌트는 NDO에서 생성되며 Site1 및 Site2라는 두 사이트와 연결됩니다.
2개 사이트와의 테넌트 연결 확인
3개의 템플릿과 연결되었습니다.
테넌트에 대한 템플릿 연결 검증
- 스키마 레벨: Schema1이라는 스키마에는 다음 3개의 템플릿이 포함되어 있습니다.
Stretched_Schema에 포함된 템플릿 유효성 검사
- Stretched_Site1_Site2는 VRF1이라는 스트레치된 VRF가 정의되고 두 사이트와 연결되는 스트레치된 템플릿입니다.
Stretched_Site1_Site2 템플릿이 두 사이트에서 스트레치되는 검증
- Site1이라는 템플릿에서 Site1만 연결된 경우 로컬 BD_Site1이 정의되며 확장 VRF1과 연결됩니다. 또한 AP_Site1 및 EPG_Site1은 이 템플릿에서 로컬로 정의됩니다.
템플릿 Site1이 단일 사이트에 대해 로컬임을 검증합니다.
로컬 BD에 대한 VRF가 확장된 것임을 확인
- Site2라는 템플릿에서 Site2만 연결된 경우 로컬 BD_Site2가 정의되며 확장 VRF1과 연결됩니다. 또한 AP_Site2 및 EPG_Site2는 이 템플릿에서 로컬로 정의됩니다.
확인할 템플릿 사이트 2의 유효성 검사가 로컬입니다.
로컬 BD에 대한 VRF가 확장된 것임을 확인
객체가 올바르게 구축되었는지 확인하려면 다음을 수행합니다.
Tenant1은 NDO는 물론 VRF, AP, BD 및 EPG에 의해 구축 및 관리됩니다.
GUI의 확장 유효성 검사
또한 모든 MIT 객체의 주석이 "orchestrator:msc"로 설정되어 있음을 확인할 수 있습니다. 이는 NDO에서 관리됨을 의미합니다.
테넌트:
{
"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:"
}
}
}
]
}
},
]
}
VRF의 경우 "orchestrator:msc" 주석 외에도 일부 자식 속성이 표시됨을 알 수 있습니다.
이러한 하위 객체를 더 잘 이해하기 위해서는 NDO에서 사이트 이름 외에 고유한 사이트 ID가 NDO의 각 사이트와 연결되어 있다는 것을 알아야 합니다. ID를 쿼리하려면 NDO에서 다음으로 Operate > Sites 이동합니다.
NDO에서 사이트별 SiteID 검증
이 정보가 설명되면 하위 객체는 다음과 같습니다.
- fvSiteAssociated: 로컬 사이트의 사이트 ID를 표시합니다.
- fvRemoteID: 개체가 확장되는 원격 사이트 ID입니다. 이 개체는 사이트 간에 개체의 변환을 아는 데에도 유용합니다. 이 VRF의 경우, 사이트 2에 해당하는 세그먼트 및 ClassID를 볼 수 있습니다. 사이트 2에서 비교를 수행하여 확인할 수 있습니다.
원격 개체의 Segment 및 ClassID 검증
보이는 것처럼, 사이트 2의 세그먼트 및 ClassID는 사이트 1의 VRF 객체 내의 fvRemoteID에 포함되어 있습니다.
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 및 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:" } } }, ] } } ] }
BD, AP 및 EPG 객체에는 fvRemoteId 하위 객체가 없습니다. 이러한 객체는 로컬로 중요하며 확장되지 않기 때문입니다.
사이트 2는 출력이 상당히 유사하여 해당 원격 객체만 변경하므로 이 정보는 생략됩니다.
사이트 연결 해제
이 절차를 수행하기 전에 NDO에서 백업은 물론 APIC에서 스냅샷을 생성하는 것이 좋습니다. 나중에 롤백해야 할 경우에 대비하십시오.
1단계. 템플릿에서 사이트 연결 해제
이 단계는 각 템플릿에서 실행해야 합니다. 원 종속성에 대한 논리와 마찬가지로, 다른 템플릿에 대한 종속성이 있는 템플릿에서 먼저 시작하고, 마지막으로 상호 참조가 없는 템플릿의 연결을 끊어야 합니다.
이 문서에 사용된 토폴로지에서는 템플릿 Site1 및 Site2에 대한 참조가 있기 때문에 연결을 해제할 마지막 템플릿이 Stretched_Site1_Site2여야 합니다.
Actions 스키마 내의 템플릿으로 이동하여 을 누르고 Disassociate Site 다음으로 이동합니다.
템플릿 연결 해제 방법
연관이 해제되면 사이트별로 드롭다운 메뉴 사이트에서 선택합니다(템플릿에 사이트가 2개 이상인 경우).
템플릿 연결을 해제할 위치에서 사이트 선택
그런 다음 Disassociate(연결 해제)를 클릭합니다.
완료되면 확인 메시지가 표시됩니다.
확인 메시지
주: 앞에서 설명한 대로 스키마의 모든 템플리트에 대해 이 절차를 반복합니다.
2단계. 각 APIC에서 객체가 NDO에 의해 관리되지 않는지 확인합니다.
객체가 APIC에 여전히 있고 다른 등록 정보가 있는지 확인하려면 다음을 수행합니다.
APIC에서(사이트 1의 예):
컨피그레이션이 지속되는 GUI 검증입니다.
객체는 더 이상 옆에 클라우드 NDO 아이콘을 표시하지 않으며, 테넌트만 NDO에서 계속 관리됩니다.
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:" }, } } ] } } ] }
APIC에서 볼 수 있듯이 아직 주석이 있는 유일한 객체는 테넌트 객체이지만 BD, VRF, AP 및 EPG 객체는 이제 주석 속성이 비어 있습니다. 그러면 객체가 APIC에서 제거되지 않고 이제 각 APIC에서 관리됩니다.
3단계. 빈 템플릿 제거
이제 모든 템플릿이 비어 있으며 어떤 사이트와도 연결되지 않았습니다.
연결되지 않은 상태의 템플릿 검증
이러한 템플릿은 안전하게 제거할 수 있습니다. 제거하려면 를 클릭하고 Actions 이미지에 표시된 대로 선택합니다Delete Template.
템플릿 삭제
스키마가 비어 있으면 변경 내용을 저장합니다.
빈 스키마에 변경 내용 저장
4단계. 빈 스키마 제거
빈 스키마를 제거할 시간입니다. 이미지에 표시된 대로 Configure > Tenant Templates이동합니다.
테넌트 메뉴로 이동하는 단계
스키마 옆의 점 3개를 클릭하고 이미지에 표시된 대로 클릭합니다Delete.
템플릿과 연결된 빈 스키마 삭제
5단계. 테넌트에서 사이트 연결 해제
스키마가 더 이상 없으면 테넌트는 더 이상 어떤 템플릿과도 연결되지 않음을 나타내야 합니다. 확인하려면 다음으로 Operate > Tenants 이동합니다.
테넌트에서 사이트 연결 해제
테넌트에 연결된 템플릿이 없는지 확인
확인할 수 있듯이, Tenant1과 연결된 템플릿의 수는 0입니다. 3개의 점을 클릭하고 Edit(편집)를 선택합니다.
테넌트 속성을 편집하여 사이트 제거
이제 사이트 선택을 취소해야 합니다. 사이트 Unselect items 테이블 상단의 을 클릭합니다.
테넌트와 연결된 사이트 선택 취소
확인 전에 테넌트 삭제 옵션을 선택 취소했는지 확인합니다.
확인 없이 작업을 확인합니다.
두 사이트를 모두 선택 취소한 경우 변경 사항을 저장합니다. 이 작업이 완료되면 각 APIC의 테넌트가 해당 위치에 있는지 확인합니다.
테넌트가 여전히 구성되었지만 NDO에서 관리되지 않는다는 IGUI 검증
예상대로 이제 주석이 비어 있습니다.
"fvTenant": { "attributes": { "annotation": "", "descr": "", "dn": "uni/tn-Tenant1", "name": "Tenant1", "nameAlias": "", "ownerKey": "", "ownerTag": "", "userdom": ":all:" } }
6단계. NDO에서 빈 테넌트 제거
테넌트를 제거할 시간입니다. 이렇게 하려면 로 이동하고 Operate > Tenants 3개의 점을 클릭한 다음 이미지에 표시된 대로 를Delete 클릭합니다.
빈 테넌트 삭제
테넌트 객체가 APIC에 남아 있는지 확인하고 확인합니다.
7단계. ND에서 NDO 애플리케이션 제거
NDO를 제거하려면 먼저 앱을 비활성화해야 합니다.
nd에서 로 Admin Console > Services 이동합니다. NDO 애플리케이션이 표시됩니다. 3개의 점을 클릭하고 다음을 선택합니다Disable.
NDO 애플리케이션 비활성화
완전히 비활성화되는 데 몇 분 정도 걸릴 수 있습니다.
그런 다음 3개의 점을 다시 클릭하고 이번에는 옵션을 클릭합니다 Delete .
8단계. ND에서 NDO 앱 제거
마지막으로, ND에서 사이트를 제거합니다. 사이트를 제거하려면 어떤 서비스도 사용하지 않아야 하므로 다른 애플리케이션이 설치된 경우 해당 사이트도 제거해야 합니다.
사이트에서 NDO 서비스를 사용하지 않는다는 확인
제거하려면 3개의 점을 클릭하고 이미지에 표시된 Remove Site 대로 선택합니다.
ND에서 사이트 제거
사이트가 완전히 제거되면 이제 각 패브릭이 독립적이며 ND도 폐기할 수 있습니다.
참고: 사이트가 독립적이면 인프라 테넌트의 사이트 간 L3out은 여전히 존재합니다. 수동으로 제거할 수 있습니다. 사이트 간 연결에만 해당하는지 확인하십시오.