4. VXLAN EVPN BUM Traffic Handling: Route Type 3

what is VXLAN EVPN?

Method1: enable Multicast Routing in Underlay Network

In the first method, which is also recommended, we need to enable multicast routing in the underlay network. Sometimes it is not possible, because part of the network is out of our control. For example, in data centers with multiple sites, the communication network between sites is not necessarily under our control.

If we enable multicast routing on the underlay network, only one copy of the BUM traffic will be forwarded to multiple destinations. With this method, a unique multicast group address is defined for each VNI in the VXLAN network. The BUM traffic for each VNI is forwarded to the group address configured for the VNI, and all leaf switches with that VNI listen to that group. So they get BUM traffic.

In this topology we have three leaf switches and three VNI, VNI 5000, VNI 6000 and VNI 7000. VNI 5000 exist in every three leaf switches. VNI 6000 exists in leaf1 and leaf2 switches. VNI 7000 exists in leaf2 and leaf3 switches.

For each VNI, a multicast group is configured in the leaf switches to which they participate. 239.5.5.5, 239.6.6.6 and 239.7.7.7 are configured in order for VNI 5000, VNI 6000 and VNI 7000.

interface nve1
  member vni 5000
    mcast-group 239.5.5.5
  member vni 6000
    mcast-group 239.6.6.6
  member vni 7000
    mcast-group 239.7.7.7

Thus, a multicast tree is automatically generated for each VNI, and BUM traffic for each VNI is forwarded in the corresponding tree, which forwards traffic to multiple leaf switches that are involved in that VNI.

To better understand, suppose that server1 with MAC address, MAC1 exist in VNI 5000 and it sends a broadcast traffic. Also suppose that V1, V2 and V3 are VTEP address of leaf1, leaf2 and leaf3 switches. When leaf1 receive the broadcast frame, it encapsulate the original broadcast frame into VXLAN packet with VNI 5000. Source of the VXLAN packet is V1, VTEP address of leaf1, and destination is 239.5.5.5, which is multicast group considered for VNI 5000.

This is a multicast packet and it is multicast routed to every destination listening on the multicast group address 239.5.5.5. Since VNI 5000 is present in all three switches, we expect that all leaf switches will listen to this group address and receive broadcast traffic.

Just to summarize , when multicast routing is enabled on the underlay network, only a single copy of the BUM traffic is forwarded and it is forwarded only to the leaf switches participating in the same VNI as BUM Traffic.

Method2: enable Ingress Replication in Overlay Network

In the second method of forwarding BUM traffic, which is called “Ingress Replication”, multicast routing is not enabled on the underlay network. Therefore, multiple copies of the BUM traffic are replicated to the leaf switches with the respective VNI. So this method requires more bandwidth for the BUM traffic and is not recommended. It is used when it is not possible to enable multicast routing in the underlay network.

With this method, each leaf switch announces its membership at each VNI with MP-BGP EVPN route type 3 to other leaf switches. So that every leaf switch knows to which leaf switches, the BUM traffic has to be forwarded. Then a copy of each BUM traffic is sent to all other leaf switches participating in the VNI.

In this topology, route type 3 was shown as an example, which is announced by Leaf1 and Leaf2 to other leaf switches. Leaf1 announces membership of its VTEP address to VNI 5000 and VNI 6000. That means, if other switches need to forward BUM traffic in VNI 5000 and VNI 6000, BUM traffic must also be replicated to the V1 address.

In this topology, when BUM traffic is received in Leaf1 in VNI 5000, two copies of the traffic must be generated. One for the destination Leaf2 with VTEP address V2 and the other for Leaf3 with VTEP address V3. Both Leaf2 and Leaf3 participate in VNI 5000.

For enabling ingress replication, we have to configure “ingress-replication protocol bgp” in every VNI.

interface nve1
  member vni 5000
    ingress-replication protocol bgp
  member vni 6000
    ingress-replication protocol bgp
  member vni 7000
    ingress-replication protocol bgp

We will implement two main scenarios for VXLAN EVPN, one with multicast routing and the other with ingress replication in the next few videos. Just to have an overview, let’s look at an example of MP-BGP EVPN route type 3 content without going into any deeper configuration.

In the follwoing output Label 50140 is L2 VNI in my configured scenario.

leaf1(config-if-nve-vni)# show bgp l2vpn evpn 192.168.15.12
BGP routing table information for VRF default, address family L2VPN EVPN
Route Distinguisher: 192.168.0.11:32907    (L2VNI 50140)
BGP routing table entry for [3]:[0]:[32]:[192.168.15.12]/88, version 2113
Paths: (1 available, best #1)
Flags: (0x000012) (high32 00000000) on xmit-list, is in l2rib/evpn, is not in HW

  Advertised path-id 1
  Path type: internal, path is valid, is best path, no labeled nexthop
             Imported from 192.168.0.12:32907:[3]:[0]:[32]:[192.168.15.12]/88 
  AS-Path: NONE, path sourced internal to AS
    192.168.15.12 (metric 81) from 192.168.0.1 (192.168.0.1)
      Origin IGP, MED not set, localpref 100, weight 0
      Extcommunity: RT:65000:50140 ENCAP:8
      Originator: 192.168.0.12 Cluster list: 192.168.0.1 
      PMSI Tunnel Attribute:
        flags: 0x00, Tunnel type: Ingress Replication
        Label: 50140, Tunnel Id: 192.168.15.12
....