Network Virtualization using Extreme Fabric Connect
Table Of Contents
- Table of Contents
- Table of Contents
- Table of Contents
- Table of Figures
- Table of Figures
- Table of Tables
- Conventions
- Introduction
- Reference Architecture
- Guiding Principles
- Architecture Components
- User to Network Interface
- Network to Network Interface
- Backbone Core Bridge
- Backbone Edge Bridge
- Customer MAC Address
- Backbone MAC Address
- SMLT-Virtual-BMAC
- IS-IS Area
- IS-IS System ID
- IS-IS Overload Function
- SPB Bridge ID
- SPBM Nick-name
- Dynamic Nick-name Assignment
- Customer VLAN
- Backbone VLAN
- Virtual Services Networks
- I-SID
- Inter-VSN Routing
- Fabric Area Network
- Fabric Attach / Auto-Attach
- FA Server
- FA Client
- FA Proxy
- FA Standalone Proxy
- VPN Routing and Forwarding Instance
- Global Router Table
- Distributed Virtual Routing
- Zero Touch Fabric (ZTF)
- Foundations for the Service Enabled Fabric
- IP Routing and L3 Services over Fabric Connect
- L2 Services Over SPB IS-IS Core
- Fabric Attach
- IP Multicast Enabled VSNs
- Extending the Fabric Across the WAN
- Distributed Virtual Routing
- Quality of Service
- Consolidated Design Overview
- High Availability
- Fabric and VSN Security
- Fabric as Best Foundation for SDN
- Glossary
- Reference Documentation
- Revisions
Network Virtualization Using Extreme Fabric Connect
© 2019 Extreme Networks, Inc. All rights reserved. 136
QoS Considerations with Fabric Extend
When using Fabric Extend with IP (VXLAN) encapsulation, we are yet again adding an additional packet
header to transparently cross a WAN provider cloud. In terms of QoS, every time a new encapsulation is
added, there is a need to reflect the QoS of the packet payload in that new header because that new
header will be used by downstream routers to forward the packet and we need to ensure a consistent PHB.
Note
The Fabric Extend L2 mode does not add any additional encapsulation. Instead it performs
VLAN tag translation on the existing Mac-in-Mac encapsulation. Therefore, the Fabric
Extend L2 mode is not applicable to this discussion.
In the Extreme Fabric Extend IP (VXLAN), implementation the p-bits in the Backbone VLAN Q-tag are
automatically re-mapped to IP DSCP values with a consistent PHB.
Note
Fabric Extend QoS mappings are as follows:
p-bit 0 ➔ dscp 0, p-bit 1 ➔ dscp 0, p-bit 2 ➔ dscp 10, p-bit 3 ➔ dscp 18,
p-bit 4 ➔ dscp 26, p-bit 5 ➔ dscp 34, p-bit 6 ➔ dscp 46, p-bit 7 ➔ dscp 46
Caution
Currently Fabric Extend IP (VXLAN) QoS mappings are static and cannot be changed.
It is worth noting that the WAN provider may or may not even look at the IP DSCP marking for the traffic it
receives. This will depend on the Service Level Agreement (SLA) in place and the capabilities of the WAN
provider equipment. The WAN provider will typically use an MPLS backbone to deliver WAN services to
their customers of which they will have many. All their customers will be transported over their same
backbone but not all customers will have the same SLA. The WAN provider will most likely allocate each of
their customers into one of their own QoS levels, but this classification will be independent of any DSCP
marking present in the packets sent to them.
Where the customer DSCP marking may come to play is if the WAN provider is able to use more complex
hierarchical QoS queueing in their equipment, which would allow them to maintain two levels of QoS
granularity across their equipment. In practice, this complexity is often avoided and it is best practice for
the customer to egress shape their connection to the WAN provider to match whatever bandwidth has
been purchased for the service. Any traffic in excess of purchased WAN bandwidth can thus be queued in
the customer’s Fabric Extend egress logical IS-IS Ethernet port where any drops will be QoS aware based
on the customer’s own application marking.