Module 5 Episode 2 Pt 2 - ACI Multipod Configuration, Verification & Testing (w/vMotion across pods)
Вставка
- Опубліковано 21 сер 2024
- In the second part of this chapter, we' will configure the Spines on Pod 1 and Pod 2 through the wizard and show how L2 is automatically extended through MP-BGP EVPN VXLAN across both Pods. We will also go through the verification process to confirm OSPF and MP-BGP EVPN VXLAN is functioning correctly.
And finally, we will test our configuration performing vMotion between Pods, extending the same subnet and policies under a single pane of glass.
These are the best videos on ACI I've found. Thank you very much!
Glad to see they are useful @nomoreospf
Every second of your videos is very helpful. Waiting for multisite module.
Thank you Rajat!
Amazing Explanation this video is like a Gold
Thanks Yayonaldo! Glad it helped!!
Haha. It seems that I'm the first one viewing this video. Your videos are very practical.
Thanks Felix!!!
Legend. Thanks for doing this
Amazing series I learned alot from these videos.
Is there any plan to develop mode videos for example on Multisite topology and multisite orchestrator..some introduction to nexus dashboard
Thank you! Yes, we are just waiting for Nexus Dashboard 3.2 to come out so that we can show the new installation model and the latest changes. There's some behavioral adjustments that are happening on ND as we speak, simplifying some things and accelerating others, so, we want to make sure that the video stays relevant for as long as possible
@@CiscoDataCenterMadeEasy Thanks for quick reply mate. Much appreciated.
great Videos thanks a lot !
Glad you like them!!
Cisco's Multi-pod whitepaper says pods will always use pod1's internal TEP Pool... but doesn't seem like it. 🤷♂
@GamjaField APICs always use Pod 1s internal TEP Pool (even if they are connected to switches on different Pods), but each Pod's switch will use a different TEP Pool. e.g.
TEP 1: 10.0.0.0/16
TEP 2: 10.1.0.0/16
APIC 1 and 2 in Pod 1 and APIC 3 in Pod 2 will always use the same TEP 10.0.0.0/16
Switches in Pod 1 will use 10.0.0.0/16
Switches in Pod 2 will use 10.1.0.0/16
Hope this helps
can we establish the IPN connectivity with an existing production pod-1 without any impact in a brownfield scenario?
If pod-1 is production-grade and it is part of a critical operation, I would not risk it. Having a maintenance window for any changes is a generic recommendation. Local traffic should not be impacted, but it is possible that a few packets could be lost while the network re-converges (GiPO/BD assignment extension through multicast based IPN, route exchange across EVPN VXLAN spines over BGP/OSPF, etc.) If that's acceptable, I would recommend you take a snapshot of your ACI environment the way it is (at the fabric level and/or at the infra tenant, where your Multi-Pod configuration will be automatically deployed once you complete the wizard) and then proceed with the changes. Hope this helps
very useful, is this serial will continue? , thanks a lot
Any topic in particular you are looking for? We mostly covered every fundamental topic already :)
1/53.4 you have used /30 subnet and Spine end you are configuring /24 , is it still working ?
Good catch! I realized this as I was editing the video. I used to have /30s in my lab before but then adjusted it to /24 to make it easier to follow, I think I left this from that version :)
I am cisco employee and I watched your almost 40 videos and every video information is more than expected. So I can say if anyone want to learn he/she go through your videos and learn any topic in less time. I have lab option so I have tested everything in Lab whatever you have shown in your videos.
Anyone can grab more knowledge in less time.
@@alokmisra248 Thank you Alok for your kind words! Definitely encouraging!
shouldn't the IPN MTU be the Spine MTU + 50B?
Not really. The fragmentation is based on the source endpoint transmission MTU. You can read more about it here: www.cisco.com/c/en/us/solutions/collateral/data-center-virtualization/application-centric-infrastructure/white-paper-c11-737855.html "This essentially implies that the MTU support required in the IPN becomes solely dependent on the maximum size of frames generated by the endpoints connected to the ACI leaf nodes (that is, it must be 50B higher than that value)." Thanks for the comment though :)
@@CiscoDataCenterMadeEasy ah, I see I was wrong; I was actually thinking +50B MTU on the IPN side to accomodate the VXLAN header. You've already set that in the other video to 9150B so it's all good.
Thanks a lot by the way for these series, they look very very good and I'm sure you've put a lot of effort in doing the animations.
@@ping-factory Sure! Thank you for your kind words!!!