Cheers,
Brad

Just came across this post. What it you have Palo – UCS 2100 – UCS 6100?
How do you manage VNTag-ing and prevent double tagging?
Does the UCS 2100 have a sort of bypass mode where it knows that upstream is doing the VNTag?

Cheers,
Brad

great great blog. This actually solved most of the doubts i had about the palo card. Just hope to find the budget to get one in my mini-DC.

thanks again. as Eng said above, your blogs really make readers visualise the virtual stuff, which is paramount.

- If there is a 3rd VM in the picture will I see a vEth 3 on the unified fabric?

- If this scenario is used with a UCS B series.
1- The Palo adapter will put a tag on the packet.
2- But as the packet is received by chassis FEX 2148 will puts it own VNTAG.

So in this case we will have a (Palo tag) tag in a (VNTAG) tag? Because all the material suggests that Palo tag will make its own veth interface on the 6100.

Thanks

First lets start with a simple baseline definition of “VN-Link”: Providing a means to connect a Virtual Machine directly to the Cisco network, resulting in a 1:1 relationship of a VM’s vnic with a virtual Ethernet port on the Cisco network with persistent and policy driven network & security properties.

(1) Yes, in case #1 the Virtual Machine’s vnic is connecting directly to the Nexus 1000V Cisco software switch. So this could be described as VN-Link in Software.

(2) Yes, as shown in the diagram in case #1, the virtual Ethernet adapters on the Palo will each use a unique VN-Tag as their virtual cable that connect it to their own virtual Ethernet port on the Fabric Interconnect. You can see the virtual Ethernet ports on the Fabric Interconnect with simple “show interface” commands. The VN-Tag #’s used are dynamically negotiated and managed by the Fabric Interconnect. You can dig with cli commands to find the VN-Tag # but it doesn’t really gain you anything to worry about this or attempt to keep track.

(3) Yes, that is correct. Please note that the (30) Palo vNIC’s for each VM will be created for you dynamically thanks to the Fabric Interconnect registering with vCenter as a Distributed Virtual Switch (DVS). When the server admin provisions a new VM and powers it on, the Fabric Interconnect will dynamically create the needed vNICs on Palo. When the VM is moved to another server, again the Fabric Interconnect will remove the dynamic Palo vNIC from the source machine and move it to the new destination machine anchored to the same persistent virtual Ethernet port on the Fabric Interconnect — from the network perspective its as if the VM never really moved.

Excellent questions!!

Cheers,
Brad

I have a few questions.

(1) Can i confirm that NIV use case #1 is known as VNlink in software?

(2) For NIV use case #1, from the Palo to the Fabric Interconnect, do you still see VNtag? I read the doc and it seems to say that only when you do VNlink in hardware (NIV use case #3) that VNtag will be used. I just want to make sure i get the concept right. Is there any show command on the nxos in fabric interconnect that i can see the VNtag?

(3) NIV use case #3 is also known as VNlink in hardware. In this case, the VM is like connected directly to the Fabric Interconnect. This also means that there is a one-to-one mapping between the VM and VNIC in Palo. If i have 30VMs, then i will need 30 vNIC in the palo. Is my understanding correct?

I like your post, it helps me to understand a lot much more than just reading the UCS configuration document. When you virtualise, you need to be able to visualise in order to understand.

Thanks again!
Eng Wee

we just bought a bunch of UCS blades with the palo adapter and are awaiting delivery in march.
Can you recommend some technical readings about the palo adapter? I’m specifically interested how failover in case of FI/FEX failure is handled and how the separation between Fabric A/B for storage is obtained.

Best Regards

Cristiano