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. 108
routes) such that the customer IP subnets can be re-advertised by the WAN IPVPN between the distant
sites.
With Fabric Extend the IP address provided by the WAN provider will become the Fabric Extend source IP
and will be used to originate and terminate all IP (VXLAN) tunnels. Thus the only IP traffic which will be
seen by the WAN provider will be VXLAN encapsulated traffic between the IP addresses it supplied. The
need to run an IP routing protocol with the provider goes away.
Because the WAN service becomes an underlay to Fabric Connect, it is necessary that any IP interfaces used by
Fabric Extend to build the IP tunnels should be isolated from any other IP interface used to carry VSN services
above the Fabric. The correct design approach is to allocate a VRF for Fabric Extend and use this VRF to
allocate the Fabric Extend IP interfaces used to send and receive traffic from the WAN.
This is illustrated in Figure 55. The Fabric Extend VRF should not be used to terminate any L3 VSN (via I-SID
assignment) and thus any IP routes used by Fabric Extend will remain isolated from IP service domains
running above the Fabric (IP Shortcuts and L3 VSNs).
Figure 55 Fabric Extend Deployment Model over WAN L3 IPVPN Service
Note
Use of the GRT (VRF-0) or an L3 VSN enabled VRF for terminating Fabric Extend tunnels
is technically feasible and supported. Such a deployment could be envisaged where there
is a need to preserve IP management to distant Fabric Extend equipment natively over the
WAN service or where Fabric Extend is deployed over a campus LAN architecture and
there is a need to preserve connectivity between the Fabric Extend overlay and the
campus IP routed underlay.
However, such designs should be avoided as they are fraught with additional complexity
to ensure that the IP routes necessary to form the Fabric Extend overlay tunnels must
never end up being replaced with IS-IS IP routes from the overlay, which would result in
the overlay falling apart.
Fabric Extend over the Public Internet with IPSec
The diagram in Figure 56 shows how Fabric Extend can be performed over the public Internet. Only the
Fabric Connect VPN software (e.g. running on XA1400 platforms) can be used in this mode as Fabric
Extend over the Internet requires IP fragmentation and, for security reasons, IPsec must be used to encrypt
the traffic.