EVPN is inherently a Layer 2 technology. However, Layer 2 connectivity alone is insufficient for complex data center networks. To address this, RFC 9135 introduces Integrated Routing and Bridging (IRB), enabling both Layer 2 and Layer 3 functions on the same interface as needed. RFC 9135 outlines two IRB models: symmetric and asymmetric. In the symmetric IRB model, both ingress and egress Provider Edge (PE) devices apply identical processing logic, performing lookups in both MAC and IP VRF tables. This ensures consistent packet forwarding and routing decisions, regardless of traffic direction or entry point.

Given the scale of the topology, we tested more than one feature under it. We also verified the E-LAN and Proxy MAC-IP advertisement together with IRB in this topology.

E-LAN is a continuous function extension of E-Line and E-Tree. It extends the connection service to the multipoint-to-multipoint level. We verified the E-LAN service by simultaneously sending bridging and routing unicast traffic. Routing traffic was for IRB, and bridging traffic is for E-LAN.
Proxy MAC-IP functionality was enabled on Arista, HPE, and Ribbon multihomed devices to enhance resilience during peering failures. When a PE locally learns a MAC/IP for a host on a multihomed site, it advertises it using an EVPN MAC/IP route. Upon receiving this route, other PEs update their ARP/ND state. If a receiving PE is also connected to the same multihomed Ethernet segment and has not already learned the MAC/IP, it advertises the same MAC/IP with the same ESI as a proxy route, signaled by setting the P flag in the EVPN ARP/ND Extended Community (EC). However, we didn't test the interoperability between different vendor multihomed groups. We only verified that the P flag was correctly set in the BGP control plane.

Finally, we tested unicast traffic by sending from a site with a single PE to a remote site containing all the remaining PEs. The results showed no packet loss, and the load-balancing functioned as expected within the multihomed device group. Due to the complexity of the topology and limited time, failover scenarios were not tested in this round.
The E-LAN service worked properly, demonstrating that BGP EVPN RT-2 was functioning as expected. We had also configured multiple VLANs for BGP EVPN RT-5, including shared VLANs and vendor-unique VLANs. As the routed traffic worked properly, confirming that BGP EVPN RT-5 also worked as expected.
NOTE: Ericsson RAN Connect does not support EVPN RT-5, so the target for Ericsson is to export pure L3 routes via L3VPN routes. Therefore, the vendor-unique interface was not created, and touring to/from the vendor-unique subnets would work only when we receive the T5 as IPv4/6 L3VPN routes in the VRF.

We conducted the same tests on the EVPN-VXLAN domain, including E-LAN verification. The proxy MAC/IP feature was not enabled for this run. To assess routing and bridging, we sent full-mesh unicast traffic and observed no packet loss; both functions operated as expected. We confirmed BGP EVPN RT-2 and RT-5 worked properly with the same methodology as above. Failover testing was not performed in this round.