Inclusive multicast routes provide for the extension of VLANs and bridge domains over tunnels, and MAC, MACIP, and prefix routes provide for signaling control plane routes for tenants. Forwarding across the tenants or toward the core takes place through VxLAN overlay tunnels. The flooding of BUM traffic is achieved by means of ingress replication.
Devices in the underlay Layer 3 Clos network can have the following distinct roles:
The underlay architecture in a Layer 3 Clos network can be based on iBGP or eBGP. The following topologies illustrate these options.
iBGP spine and leaf
With iBGP-based underlay, all spine and leaf nodes are in the same AS. Spine nodes act as route-reflectors and do not terminate any tunnel, whereas leaf nodes originate and terminate all of the tunnels and routes. The following figure illustrates this topology.
eBGP spine and leaf
With eBGP-based underlay, each leaf node is assigned a distinct AS number. Usually, the iBGP underlay architecture provides higher BGP scalability but with less control on the routes getting exchanged. On the other hand, eBGP underlay provides lower BGP scalability but with greater control on routes, as policy and filters can be applied on the originating AS numbers. The following figure illustrates this topology.
Border and service leaf
A border leaf is special leaf node, typically redundant, that sits at the edge of the data center and provides termination, hand-off, or control-plane extension towards the WAN or core. Similarly, that functionality is provided in the reverse direction, from the WAN/core toward the data center.
A border leaf can act as a transparent route-reflector/forwarder (iBGP/eBGP) or can terminate tunnels while providing reflection service. In the service-leaf model, a border leaf also acts as just another leaf node in the network and can extend Layer 2, Layer 3, or both services as illustrated in the following figure.
Co-located spine and border leaf
With a Layer 2 and Layer 3 control-plane extension model, a border leaf can provide just a route forwarding service, which is merely spine functionality. In the absence of a separate border leaf, spine nodes can themselves act as route reflectors toward the WAN or core.
An overlay gateway configuration must be present and should remain in the active state in order to exchange routes in the VxLAN overlay network. An example configuration follows.
overlay-gateway gateway1 type layer2-extension ip interface Loopback 1 map vni auto activate ! interface Loopback 1 ip address 192.168.32.10/32 no shutdown !
Note
Either automatic or manual VLAN mapping is supported. Hybrid mode is not supported.The following are criteria for accepting or originating routes in a VxLAN overlay network:
The preceding criteria affect only the exchange of routes between BGP neighbors with VXLAN encapsulation. When the overlay gateway is deactivated or unconfigured, all dynamic tunnels are deleted, EVPN routes received with VXLAN encapsulation are removed, and the RIBout of the BGP EVPN neighbors configured with VXLAN encapsulation is flushed.
Dynamic VTEP discovery is a configurable option. It can be enabled under BGP EVPN address-family configuration mode, as shown here.
Note
This feature is supported on static VXLAN tunnels with non-MCT nodes for regular VTEPs but not for logical VTEPs.router-bgp
address-family l2vpn evpn
vtep-discovery
!
By default VTEP discovery is enabled. When enabled, if a route with BGP encapsulation extended community as VxLAN type is imported into the MAC-VRF table, a VxLAN tunnel (if it does not already exist) is created in the system with the destination IP address as the next-hop IP address of the route. MAC learning in the forwarding plane on BGP-discovered VxLAN tunnels is automatically disabled.
When the preceding "vtep-discovery" is disabled, all dynamically discovered VxLAN tunnels are deleted from the system. VTEPs can be administratively configured, and they can be instructed to disable MAC learning in the forwarding plane and instead to use BGP, as in the following example.
overlay-gateway gateway1
type layer2-extension
...
site tunnel1
ip address 192.168.32.20
extend vlan add 10-100
extend bridge-domain add 10-100
!
activate
!
VLANs and BDs on static tunnels are not extended by BGP over inclusive-multicast routes received from remote nodes. They should be extended manually, as shown in the preceding configuration. Only when specific VLANs and BDs are extended does BGP download the corresponding EVPN routes pointing to the appropriate tunnel. A statically configured VxLAN tunnel overrides any dynamically discovered tunnel. Similarly, when a static tunnel is removed, a dynamic VTEP is created if a route with that next-hop IP address is present in the BGP MAC-VRF table.