Forum Discussion

dirkf's avatar
dirkf
Level 1
2 months ago

Fabric APIv4, Connection to azure, Technical background vlanSTag in zSide

Hello,

I'd like to configure a redundant connection to Azure using dot1q encapsulation.

The documentation for migration from v3 to v4 states that we need to include

 

                    "linkProtocol": {
                        "type": "QINQ",
                        "vlanSTag": 2002
                    },

 

in the zSide definition. That was not necessary in the v3 API.

I'm not sure what the technical background for that value is.

Specifically: Can we always use the same VLAN ID in connections to different Azure environments when using unique VLAN IDs on the aSide?

Any help is appreciated.

Fabric APIs

2 Replies

Sort By
  • DavidMarquis's avatar
    DavidMarquis
    Equinix Product Manager
    2 months ago

    Hi dirkf !

    The reference in the migration from v3 to v4 documentation looks to have a typo. Instead of vlanSTag , this should be vlanCTag . Will flag this so we can get this corrected! Referring specifically the subsection "Redundant connections to Microsoft Azure ExpressRoute from DOT1Q ports" .

    The linkProtocol object containing the vlanCTag property on the zSide is optional.

     

     

                        "linkProtocol": {
                        "type": "QINQ",
                        "vlanCTag": 2002
                    },

     

     

     

    For Azure connections from Dot1Q (aSide) ports, Fabric allows users to define the inner tag of the Azure-facing (zSide) port as part of the connection provisioning.
    • If users provide the linkProtocol object containing the vlanCTag property as part of the connection request,  Fabric will use this cTag value to configure as the inner tag on the Azure (zSide) port. This automatically provisions the network on Fabric once the request is received. Users would have ensure to use the same cTag (VLAN) value when they configure the peering settings on Azure.
    • If users do not provide the linkProtocol object containing the vlanCTag as part of the connection request, then Fabric does not automatically provision the network, as it does not yet have an inner tag to configure on the Azure-facing (zSide) port. In this case users can configure any cTag (VLAN) value on the peering settings on Azure, which will get "synced back" to Fabric and then subsequently provisioned.
    dirkf wrote:

    Specifically: Can we always use the same VLAN ID in connections to different Azure environments when using unique VLAN IDs on the aSide?
    ---
    Whether you provide the vlanCTagvalue as part of the Fabric connection provisioning, or through the Azure peering configuration, the recommendation would be to use unique zSide VLAN IDs (cTags) for every pair of redundant connections to avoid any potential VLAN overlap on the Azure side of the connection. 

    e.g.:
    Redundant connection pair #1:
    Primary connection (zSide VLAN/cTag = 100)
    Secondary connection (zSide VLAN/cTag = 100)

    Redundant connection pair #2:
    Primary connection (zSide VLAN/cTag = 200)
    Secondary connection (zSide VLAN/cTag = 200)

     

    Azure peering configuration screenshot:

    Hope this helps!
    /David

     

  • ChrisR's avatar
    ChrisR
    Moderator
    2 months ago

    Hi dirkf! Thanks for the question. I've polled some colleagues and will get back to you soon with an update. Stay tuned!