User Tools

Site Tools


virtualization:evpnvxlan

This is an old revision of the document!



VXLAN NOTES

vni
(vxlan)
vtep
---->{[mac][ip][mac][ip]}

MAC addresses conveyed via bgp. Datacenter. At the end of the day these are knobs to avoid using L3!.

  • ESI—An Ethernet segment must have a unique nonzero identifier, called the Ethernet segment identifier (ESI). The ESI is encoded as a 10-octet integer. When manually configuring an ESI value, the most significant octet, known as the type byte, must be 00. When a single-homed CE device is attached to an Ethernet segment, the entire ESI value is zero. The Ethernet segment of the multihomed Device CE1 has an ESI value of 00:11:22:33:44:55:66:77:88:99 assigned. The single-homed Device CE2 has an ESI value of 0.
  • EVI—An EVPN instance (EVI) is an EVPN routing and forwarding instance spanning all the PE routers participating in that VPN. An EVI is configured on the PE routers on a per-customer basis. Each EVI has a unique route distinguisher and one or more route targets.An EVI is configured on Routers PE1, PE2, and PE3.

Forward BUM traffic:

  • Multicast replication (underlay): todo
  • Ingress Replication (aka Headend Replication): Is a unicast approach to handle multi-destination trafffic. Handling BUM traffic in a network using ingress replication involves an ingress device replicating every BUM packet and sending them as a separate unicast to the remote egress devices. Enable via Route Type 3 (RT3). See LINK

EVPN NOTES - RFC 7432
Simplifying to the maximum, we can say that EVPN is like L3VPN but for layer 2 (mac information). EVPN can be seen as a way to fix L2VPN problem with L3VPN techniques (proper mac learning (no bum flooding) and so on)
https://my.ipspace.net/bin/list?id=EVPN
It uses MP-BGP mechanism and defines a new sub-address family, EVPN address family, in the L2VPN address family.

Summary:

  • RT-2 for endpoint reachability. /32-MAC addresses.
  • RT-3 for ‘flooding’ (replication lists)
  • RT-4 for multihoming (more than 1 leave for one vtep)
  • RT-5 for external networks (external routes and ‘unlearned’ hosts (ie those not know by the fabric but connected to the fabric))
Underlay/Ovelay - rule of thumb:
  1. OSPF for underlay unless scalability requirements (ebgp with 1 asn per spine); then iBGP for overlay
  2. If scalability important, do ebgp for the underlay (with one single asn for spines) then iBGP for overlay : spines to have allow-as

Design Goals

Aggregate on the ToRs only. Use single, not dual tor.

If we want to grow further (ie: we run out of ports), we use multi-planar clos topologies. Full meshed 'pods' connect to planes

Use BFD and be sure is lag and lacp aware


LEAF AND SPINE WITH ARISTA SWITCHES

Arista Validated Designs

show interfaces vxlan1
show vxlan address-table
show vxlan vni
show bgp evpn detail    # to see the evpn routes 
show bgp evpn route-type mac-ip/imet/ip-prefix    # to see the evpn rtypes 2,3,5

Note that, in evpn-vxlan, 85% of the configuration is community settings and its route maps. Automation helps a lot here.

Also MRAI is covenient to be 0. Some implementation are still 30 seconds (specially for Internet) but we don't want that in the DC

Models

Try: DCS 7280, 7500, and 7800


LEAF AND SPINE WITH NEXUS SWITCHES

Models
  • Leaf: N9364C
  • Spine: N93240YC
virtualization/evpnvxlan.1697392451.txt.gz · Last modified: (external edit)