I'm doing some UCS studying and I'm trying to understand how private-vlans work within UCS, but there's surprisingly little documentation on the subject. So far, based mostly on trial-and-error, these seem to be the rules for using pvlans in UCSM:
- only isolated type is allowed
- no promiscuous ports within UCS
- a vNIC can carry the secondary vlan ID only (no other vlans can ride alongside it, including the primary)
- the primary vlan can never be used on a vNIC
Despite this, I cannot get a VM to speak to its upstream promiscuous port/gateway. One document I found suggested the vNIC should not set the secondary vlan as native, but that seems to have no effect either way (even looking at the veth config at the CLI). The same document suggested VMware should tag the traffic, which would require the 1000V. Based on the CLI configuration, I'm guessing that's not true, but I could easily be wrong.
Does anyone know of a good guide for this, or maybe could even point me in the right direction for getting pvlans to work within UCS? Thanks!
Well, nevermind, it seems I had a misconfiguration in VMware. User error :) Here's what I found:
- No tagging required from VMware. Port groups should remain untagged.
- The vNIC must be configured ONLY for the secondary/isolated vlan.
- It doesn't seem to matter whether it's native or not. The CLI configuration doesn't change, and pings work either way. I'm guessing the 'clean/proper' configuration is to leave it unmarked as native since it's not a trunk port.
- 1000V isn't required.
Strange that the FIs learn the VM's mac address within the secondary/isolated vlan, but the upstream Nexus switches learn it via the primary vlan. UCS seems to have a focus on the secondary vlan - again, I'm fairly certain you cannot use a vlan on a vNIC once it's labeled as primary.
So the 1000V isn't required, per se, but since VMware won't honor the pvlans within the host, it certainly has a benefit. The alternative to 1000V appears to be creating a pvlan-vNIC+vswitch per VM.
Topology & Design:
Two ACI fabrics
Stretching VLANs using OTV
Both fabrics are advertising BD subnets into same routing domain
Some BDs(or say VLANs) are stretched, but some are not.
Endpoints can move betwee...
VMware Trunk Port Group is supported from ACI version 2.1
VMM integration must be configured properly
ASA device package must be uploaded to APIC
ASAv version must be compatible with ACI and device package version
Topology &Design:Traffic flow within same fabric:Endpoint moves to Fabric-2Bounce Entry Times OutTraffic Black-holedSummarySolutionAppendix:
In the Previous articles of ACI Automation, we are using Postman/Newman a...