Link Search Menu Expand Document
calendar_month 05-Sep-24

Overlay Networks

Multiple Overlay networks can be built on top of the Underlay network. Each Overlay exists as a separate VRF with unique L3 VNI, Route Target, and Route Distinguishers. Individual Overlay Networks can use some or all the switches in the Underlay network.

NetConductor provides the Fabrics overlay network workflow that automates building of the overlay networks including static VXLAN tunnels from stub switches to wireless gateways. DHCP relay is automatically configured for each overlay network within the wizard.

Within a fabric, the wizard configures iBGP EVPN on all switches leveraging route reflectors to reduce the required number of BGP peerings in the network. The wizard also configures VXLAN tunnels between all fabric devices as needed.

Each overlay network must have a dedicated VRF created on each fabric switch with a dedicated loopback interface used for DHCP relay and EVPN-VXLAN control plane messaging. Within each overlay network, multiple Layer 2 and Layer 3 network segments can be created to stretch subnets over the selected switches within the fabric effectively.

Layer 2 Segments

Layer 2 segments should be planned when the gateway for a subnet must exist on a device other than a device within the fabric, such as a third-party router or firewall. Traffic to other endpoints in the same subnet remains within the fabric, but traffic destined for the Internet or other internal subnets exit the fabric from a border switch to the device with the gateway which then handles required routing or filtering decisions.

Layer 3 Segments

For Layer 3 segments, a distributed Anycast gateway with common gateway IP and MAC address is created on some or all edge or stub switches in the fabric. Traffic destined outside the source subnet is routed at the source switch. In conjunction with role-based policies, this enables decentralized routing and policy enforcement, which can increase network performance and decrease costs.

Overlay Networks (VRFs)

Virtual Routing and Forwarding (VRF) allows multiple instances of routing table to coexist within the same switch hardware. Deployments can use VRFs to completely isolate and secure segments such as IT, OT, Guest and other devices while providing required services for each VRF. Traffic traversing within the fabric is VXLAN encapsulated carrying the VNI information to ensure that segmentation is maintained across all fabric enabled switches within the site.

External Connectivity

Clients connected to overlay networks (VRFs) require reachability to enterprise services such as data center, existing network, firewall, WAN, and SD-WAN networks. Certain overlay networks such as Guest (VRF) may require only access to limited services (DHCP, DNS, NAC) to onboard clients and the Internet. A Building Management System overlay network (VRF) may require access to only certain server hosted in the data center and shared services and must be inspected by firewall. Deployment may require firewall to host the gateway (SVI) and have the fabric build a layer 2 stretched VLANs across the network.

External connectivity configured between border device and upstream external device provides a method to connect campus fabric to the rest of the network. The external device can be a router, switch, firewall, SD-WAN, WAN or a Metro-feature-rich capable network device. Depending on the capabilities of the upstream external device, connectivity can be achieved with any of the methods mentioned below and must be configured using the Aruba Central MultiEdit tool.

  • Layer 3 connectivity to external device with OSPF or MP-BGP:

    • Use either sub-interface or VLAN with trunk/MLAG links to establish reachability.

    • If an upstream external device is not VRF capable, establish a routing neighborship from each overlay network (VRF) on the border to the external device configured with a single routing instance.

    • If an upstream external device is VRF capable, extend VRF segmentation from each overlay network (VRF) on the border to the external device with VRF configuration and establish a routing neighborship from each VRF.

    • Deployments using MP-BGP for external connectivity, it is recommended to deploy eBGP sessions between the border and external devices to avoid routing loops.

    • Deployments using OSPF for external connectivity, redistribute between BGP and OSPF on the border device.

  • Layer 3 Connectivity to external device with BGP EVPN VXLAN:

    • Configure point-to-point underlay reachability across loopback and establish BGP EVPN VXLAN neighborship with the external device.

    • Aruba EdgeConnect SD-WAN starting 9.4.1+ version supports BGP EVPN VXLAN allowing deployment to natively extended overlay network (VRF) with Aruba User Roles in the data plane from the campus fabric to SD-WAN fabric.

By default, BGP EVPN within the campus fabric uses host routes to track the edge device where the client is connected. When redistributing the campus fabric BGP EVPN routes to external domains, it is recommended to apply a route map (out direction) on the border device and advertise only prefix entries. On the external device, configure inter-VRF leaking with route maps filtering allowing only the required prefixes for each overlay network (VRF), to be shared to the campus fabric.

If the external device is a firewall, administrators can enable stateful inspection on each overlay network (VRF) and enable Inter-VRF leaking with selective route-filtering to advertise only required prefixes to campus fabric.

  • Layer 2 connectivity to external device:
    • Configure Trunk or Multi-Chassis LAG connectivity to external networks hosting the gateway for the Layer 2 segment in the campus fabric.
    • Enable spanning-tree on the border and external device to ensure network stability.

Layer 2 or Layer 3 external connectivity configuration must be provisioned on the border and on the external device using the Aruba Central MultiEdit tool.


Back to top

© Copyright 2024 Hewlett Packard Enterprise Development LP. The information contained herein is subject to change without notice. The only warranties for Hewlett Packard Enterprise products and services are set forth in the express warranty statements accompanying such products and services. Nothing herein should be construed as constituting an additional warranty. Hewlett Packard Enterprise shall not be liable for technical or editorial errors or omissions contained herein. Aruba Networks and the Aruba logo are registered trademarks of Aruba Networks, Inc. Third-party trademarks mentioned are the property of their respective owners. To view the end-user software agreement, go to Aruba EULA.