Ethernet VPN (EVPN) is a new technology that is used to extend Ethernet circuits across Data Center and Service Provider networks. It is expected to succeed other L2VPN transport methods such as BGP-based L2VPN (RFC6624), LDP-Based L2VPN (RFC4906) and VPLS.
EVPN introduces a set of new features that were not available in L2VPN and VPLS environments, most noticeable of which are All-Active Multi-homing across multiple PE devices and more efficient handling of L2 Multicast traffic.
Section 16 of EVPN RFC7432 defines the mechanism for forwarding multicast traffic within EVPN networks. Ingress Replication and/or P2MP LSPs may be used for Multicast forwarding. The major shortcoming of Multicast forwarding approach defined in RFC7432 is the lack of per-group multicast trees, meaning that Multicast traffic is getting forwarded to all PE devices participating in a given EVPN instance, regardless of presence of interested receivers. Continue reading “Need for IGMP and MLD Proxy in EVPN Environment”
In this article, we will review EVPN MPLS Port-Based VLAN-Aware Bundle Service configuration example using Juniper MX devices. As per Port-Based VLAN-Aware service definition in RFC7432, all of the VLANs on the port are part of the same service and are mapped to a single bundle without any VID translation.
EVPN Type 5 route that is proposed in ‘IP Prefix Advertisement in EVPN’ draft is a mechanism to carry IPv4 and IPv6 advertisements in EVPN-only networks. While EVPN Type 2 routes allow to carry both MAC addresses and IP addresses, tight coupling of specific IP addresses with IP Prefixes might not be desirable. Section 2.2 of the draft discusses different scenarios where such coupling is nor desirable.
With this service interface, an EVPN instance consists of only a single broadcast domain (e.g., a single VLAN). Therefore, there is a one-to-one mapping between a VID on this interface and a MAC-VRF. Since a MAC-VRF corresponds to a single VLAN, it consists of a single bridge table corresponding to that VLAN.