@AshSe ,
You need to learn the difference between IEEE standard terminology and Cisco's abuse of some of the IEEE's terms.
You are absolutely correct in saying that 802.1p describes a way of enabling QoS. But if we are going to be pedantic, 802.1p is NOT a standard (the lowercase "p" actually means that it is NOT a standard - all IEEE 803.n standards have UPPERCASE letters)
But when @raisuotis referred to "801.2p static port bindings" he was referring to the setting for a port when applying a static binding, where the choices are:
Notice Cisco's first abuse is that they have referred to 802.1p as 802.1P - indicating that it IS a standard. Furthermore, they refer to the encapsulation mode as Access (802.1P) when in fact the port will be in trunk mode. They have gone to a lot of trouble to confuse users.
So - what's the story?
Well, the 802.1p working group worked with the 802.1Q standard (which was later incorporated into the good old 802.1D standard)
The 802.1Q standard described a way of adding a 12bit field to a frame to carry a VLAN tag, and 3 more bits to give the 802.1p working group some scope to carry a "Priority Code Point" of 3 bits. One more bit called the Canonical Frame Indicator (which has an even more interesting history involving Token Ring VLANs was eventually changed to the "Drop Eligibility Indicator") made a total of 16 bits or two bytes that could be added to a frame. And of course, so that the frame could be identified as a tag-carrying frame and therefore potentially longer than the previously maximum frame size, another 2 bytes (carrying 0x8100) were added.
So - 802.1Q defined a way that you could
- Add a VLAN tag to a frame (12 bits)
- Add a PCP value to a frame (3 bits) - often referred to as 802.1p bits
- Add a DEI bit to the frame
But - what if you had a frame that was UNTAGGED but you wanted to add the PCP value? (and/or the DEI)?
Well, the standard allowed for that - you just had to put the entire 802.1Q header on, but leave the VLAN tag field as all zeros (remember you can't have a VLAN 0, so this all works)
Now when it came to implementing all this, Cisco decided that there would be:
- Access ports, that sent only Untagged frames and ignored the VLAN tag of any frames arriving with a VLAN Tag
- These port would classify arriving untagged frames into a VLAN (all frames on a given port had to be assigned to the same VLAN of course) - if no VLAN had been configured, VLAN 1 was assigned.
- Trunk ports, which could send and receive
- Frames with VLAN tags attached
- Untagged frames BUT
- these Untagged frames could also be classified into a VLAN too, much like access ports
- Cisco decided to call this Untagged VLAN on a TRUNK port a Native VLAN
Enter ACI
ACI needed a way of saying that a port was a Trunk Port, and that Untagged frames arriving on that port were to be classified into a VLAN - in Cisco speak - the Native VLAN - but Cisco decided they didn't want to use the term Native VLAN in ACI, and instead created the confusing term Access (802.1P) to define:
- a TRUNK port that
- accepted untagged frames and linked them to a VLAN internally
- sent frames for that VLAN - NOT untagged like the Native VLAN would - tagged with a VLAN tag of 0 - the VLAN tag reserved for the IEEE 802.1p working committee - hence the reason to stick 802.1P in the encapsulation mode name.
RedNectar Rant
I can kind of see why the term 802.1P was used (even if people immediately think of QoS and PCP bits), but why it was ever called an Access Port I'll never understand.
Sidenotes
- In version 1.0 of ACI the Access (802.1P) option was called Native - but that was never released to the public
- If you configure a port in ACI as Access (802.1P), then look at that port in the object browser
fvRsPathAtt, you'll see the mode listed as native - And while in the object browser, if you check the
fvRsDomAttattribute for the EPG (the link to the Physical Domain) you'll see the switchingMode listed as native and the untagged attribute shown as no
i @raisuotis ,
I see from your diagram that there are two ACI sites - so it could be multi-site (two sets of APICs + MSO NDO or multi-pod (one set of APICs)
It would be nice to know which it is.
You mentioned 802.1p static ports. Why? Is that a hint to suggest you are using IEEE MST rather than the Cisco proprietary PVRSTP? (Your later post suggesting testing on "Legacy switch running MSTP" would indicate the former)
And a final tip (I repeat this so often I have it stored as a macro):
When posting on the forum, add your pictures inline - i.e. PASTE your picture right where you want it. If it is a screenshot, you'll probably then want to click on the image and make the image large - like this.
This means you pictures are actually SEEN (a) in the email that gets sent to subscribers and (b) anyone who looks at this post in the future. Adding pictures as attachments... puts your submission into the TL;DR category.
So - back to your problem. Let's start by getting the diagram where it can be seen:
Assuming that this is Multi-pod rather than multi-site, the principles explained in the links to my earlier posts remain the same:
To successfully run MST, you'll have to ensure
- You create a VLAN pool with a VLAN in it that you will use globally as "the MST BPDU VLAN" - let's say it's VLAN 100
- That VLAN Pool must be linked to a physical Domain - let's say MST_PhysDom
- Any AAEP that contains ports that join external MST switches must be linked to the MST_PhysDom (they may will be linked to other Physical or VMM domains too, but to get the MST song to sing, you'll need to also include the MST_PhysDom)
- You create a special EPG to catch the MST BPDUs which will arrive untagged.
- That EPG must be linked to the MST_PhysDom
- The ports that join external MST switches must be added as static ports to this EPG using VLAN 100 and 802.1p encapsulation (which you say you've done)
- any external switch running MST and connecting to ACI must be in the same MST Region. Those external switches don't need to do anything special with VLAN 100 - that VLAN is just used internally by ACI
- You also have to configure your MST region in ACI and add any VLANs that you expect to traverse the links between ACI and the external MST switches.
Some things that can go wrong:
- External switches are not all in the same Region
- External switches must be sending tagged frames to ACI for every participating VLAN - i.e. they cannot be using the untagged VLAN (or [shudder] the VLAN called "native" by Cisco).
- External switches must have the ports set to
spanning-tree link-type shared
If you haven't looked at it already, Cisco Live presentation BRK-3101 has some good stuff
If I've assumed wrongly and you are running multi-site, rather than multi-pod then I'm not 100% sure that the topology shown is supported - although I'd be happy (delighted even) to be told that I'm wrong.
